View
6
Download
0
Category
Preview:
Citation preview
17/09/13 Como evitar erros comuns em bancos de dados
www.devmedia.com.br/como-evitar-erros-comuns-em-bancos-de-dados/28972 1/10
favoritar marcar como lido inserir nota pessoal
Como evitar erros comunsem bancos de dadosEste artigo apresentada uma situação hipotética, porém comum,
onde o profissional de bando de dados é orientado a como
proceder para que o sistema obtenha eficiência.
Artigo do tipo Exemplos Práticos
Recursos especiais neste artigo:
Artigo no estilo mentoring
Cenário
O projeto de um banco de dados é uma tarefa desafiadora. Desde as tarefas mais complexas
como identificar tabelas e seus relacionamentos até as mais simples como definir um nome de
uma coluna ou seu tipo merecem bastante atenção. É este cenário que será discutido neste
artigo. Veremos como decisões, muitas vezes simples, se tomadas de forma equivocada, podem
jogar por água abaixo todo um trabalho cuidadoso. Exemplificaremos com o uso da coluna “ID”
em todas as tabelas de um banco de dados fictício e os problemas provenientes desta decisão
considerando duas situações: junções entre duas tabelas e passagem de contexto entre
programas dependentes.
Em que situação o tema é útil
Durante a modelagem de dados, algumas decisões tomadas para, aparentemente, poupar
esforços de digitação e economizar algum espaço de armazenamento, podem gerar um impacto
extremamente negativo e ocasionar retrabalhos ou mesmo esforços extra para contornar o
problema causado pela “economia” mal analisada. Para evitar este tipo de problema é que o
tema se mostra bastante útil.
Existem três tipos de profissionais de banco de dados:
17/09/13 Como evitar erros comuns em bancos de dados
www.devmedia.com.br/como-evitar-erros-comuns-em-bancos-de-dados/28972 2/10
· O Novato: alguém que não sabe nada, mas sabe que não sabe nada e está disposto a
aprender;
· O Ninja: alguém que já viu de tudo, tentou de tudo, sabe quais métodos são melhores que
outros, e sabe quando um “pequeno conselho" não vale o papel higiênico que é impresso.
Alguém que tem a inteligência para questionar cada teoria e a corajem para rejeitar aquelas que
considera inúteis. Um pragmático que questiona toda regra que não produz um resultado
aceitável e, se necessário, quer reescrever as regras ou descartá-las completamente. Um ninja
tem real conhecimento que vem da experiência. Um ninja é um inovador, e não um imitador. Um
ninja é um líder, não um seguidor;
· O Sabe-Tudo: alguém que sabe muito pouco, mas acha que sabe tudo. Alguém que pensa que
sabe mais que os outros e se recusa a ouvir qualquer crítica. Alguém que ouviu falar sobre um
determinado método e acredita que este é o “único” método. Alguém que não reconheceria uma
boa ideia mesmo que estivesse debaixo de seu nariz. Um dogmático que segue as regras que lhe
foram impostas cegamente e sem questionar, e assume que os resultados, bons ou ruins, devem
ser aceitáveis. Alguém cujo pseudo-conhecimento é tudo de segunda mão. Alguém que é um
imitador, e não um inovador. Alguém que é um seguidor, não um líder.
Este artigo trata de uma seção de mentoring, onde é apresentada uma situação hipotética,
porém comum, onde o profissional de bando de dados é orientado a como proceder para que o
sistema obtenha eficiência. O cenário montado para este artigo prevê uma implementação que
pode ser considerada como tendo sido feita pelo terceiro tipo de profissional ou até mesmo pelo
primeiro, mas que provavelmente foi orientado pelo terceiro. A implementação consiste em
adicionar uma coluna chamada “ID” em todas as tabelas do banco de dados.
17/09/13 Como evitar erros comuns em bancos de dados
www.devmedia.com.br/como-evitar-erros-comuns-em-bancos-de-dados/28972 3/10
Coluna “ID” em todas as tabelas
Imagine uma implementação em que todas as tabelas do esquema possuem uma coluna
chamada “ID” que é alimentada através da geração automática de sequências. Bem comum de
acontecer, não é mesmo?
Ter uma coluna chamada “ID” aparecendo em todas as tabelas quebra, logo de saída, uma regra
básica que diz que “para conteúdos diferentes, utilize nomes diferentes”.
Os mais curiosos e estudiosos já devem ter visto os esquemas de exemplos presentes na
documentação do Sistema de Gerenciamento de Banco de Dados (SGBD) que utiliza. Nesta
documentação, tradicionalmente em inglês, o leitor encontrará colunas como “PRODUCT_ID”,
“CUSTOMER_ID” ou ainda “PART_ID”, mas nunca encontrará uma única tabela com uma coluna
chamada simplesmente de “ID”.
Ao utilizar simplesmente a coluna com o nome “ID”, um novato pode lhe dizer: “ Esta prática evita
a duplicação ao digitar consultas. Por que usar “PRODUCT.PRODUCT_ID” quando se pode
escrever menos usando “PRODUCT.ID’?”
17/09/13 Como evitar erros comuns em bancos de dados
www.devmedia.com.br/como-evitar-erros-comuns-em-bancos-de-dados/28972 4/10
Um novato pode pensar que isso é uma boa idéia, mas um ninja sabe que essa “economia” vem
com várias “pegadinhas”.
Pegadinha #1: junções entre várias tabelas
O que o novato não percebeu foi que, quando o banco de dados retorna um conjunto de
resultados, nenhum dos nomes das colunas é qualificado com o nome de tabela. Isso pode não
importar muito com uma consulta em uma única tabela, mas o que acontece com uma junção
entre várias tabelas? Veja a consulta apresentada na Listagem 1.
Listagem 1. Consulta que efetua junção entre várias tabelas.
01. SELECT *
02. FROM PEDIDO AS PE
03. LEFT JOIN TRANSACAO AS T ON (PE.ID_TRANSACAO = T.ID)
04. LEFT JOIN CLIENTE AS C ON (T.ID_CLIENTE = C.ID)
05. LEFT JOIN ENDERECO AS E ON (PE.ID_ENDERECO = E.ID)
06. LEFT JOIN FORNECEDOR AS F ON (T.ID_FORNECEDOR = F.ID)
07. LEFT JOIN PRECO AS PR ON (PR.ID_FORNECEDOR = F.ID)
08. LEFT JOIN PRODUTO AS P ON (F.ID_PRODUTO = P.ID)
09. WHERE PE.STATUS = 'A';
A consulta da Listagem 1 faz referência a sete tabelas, o que significa que o resultado irá conter
sete referências para uma coluna chamada “ID”.
Isso já é ruim o suficiente quando se olha para o resultado em um programa cliente de SQL, como
o SQL*Plus do Oracle por exemplo, e percebe que é impossível relacionar cada ocorrência de “ID”
com a tabela de origem, mas quando o resultado é disponibilizado para a aplicação não serão
apresentados vários valores para esta coluna, pois todos os nomes das colunas serão, na
verdade, o mesmo. Isto significa que haverá apenas um valor para cada nome da coluna, ou seja,
cada valor separado para a coluna “ID” vai substituir o valor anterior, portanto o valor para a
coluna “ID” no conjunto de resultados será o que for retornado pela última tabela na consulta.
Então o que acontece quando se desejar o valor de “ID” para uma tabela específica que pode ou
não ser a último na consulta? A única solução é especificar um alias (apelido) na lista de seleção,
como mostra a Listagem 2.
Listagem 2. Utilização de alias para identificar o campo “ID” de cada tabela.
01. SELECT *, PE.ID AS ID_PEDIDO, T.ID AS ID_TRANSACAO,
02. C.ID AS ID_CLIENTE, E.ID AS ID_ENDERECO,
03. P.ID AS ID_PRODUTO, ...
Se observar bem, perceberá que o esforço extra necessário para contornar o problema causado
pelo uso do nome universal de “ID” é maior do que as economias que foram consideradas em
primeiro lugar. A economia de NÃO incluir o nome da tabela no nome da chave primária é
totalmente desprezada quando é preciso modificar as consultas para incluir aliases que incluem o
17/09/13 Como evitar erros comuns em bancos de dados
www.devmedia.com.br/como-evitar-erros-comuns-em-bancos-de-dados/28972 5/10
nome da tabela.
Então, o ganho obtido numa economia sem muito sentido, foi gasto em dobro para remendar a
situação.
Apesar de um ser humano poder ser capaz de lidar com o esforço extra necessário para
contornar essa “economia”, com um framework (ver BOX 1) adequado o número de consultas
recodificadas manualmente deve ser pequena ou mesmo inexistente, mas um gerador de
consulta automático pode encontrar maiores dificuldades em lidar com tais violações das
convenções de nomenclatura adequada.
Se o leitor acha que a ideia anterior foi inteligente, há ainda aqueles que usam a coluna “NOME”
de maneira universal junto com a coluna “ID”. Isto significa que a instrução SELECT tem de ser
aumentada ainda mais, como mostra a Listagem 3.
Listagem 3. Utilização de alias para identificar o campo “ID” e “NOME” de cada tabela.
01. SELECT *, PE.ID AS ID_PEDIDO, T.ID AS ID_TRANSACAO,
02. C.ID AS ID_CLIENTE, C.NOME AS NOME_CLIENTE,
03. E.ID AS ID_ENDERECO,
04. P.ID AS ID_PRODUTO, P.NOME AS NOME_PRODUTO, ...
Resumo: assim como há a necessidade de especificar aliases para cada coluna “ID”, agora é
necessário dobrar o esforço, incluindo aliases para cada coluna “NOME”.
BOX 1. Framework.
Na programação, um framework de software é uma abstração na qual softwares que
fornecem funcionalidades genéricas podem ser seletivamente alterados por códigos
adicionais escritos pelo usuário, proporcionando assim software de aplicação específicos.
Um framework de software é uma plataforma de softwares reutilizáveis e universal para
desenvolver aplicações, produtos e soluções. Frameworks incluem programas de apoio,
compiladores, bibliotecas de código, conjuntos de ferramentas e interfaces de programação
de aplicativos (APIs) que reúnem todos os diferentes componentes para permitir o
desenvolvimento de um projeto ou solução.
Frameworks contêm características fundamentais que os separam das bibliotecas normais:
- Inversão de Controle: em um framework, ao contrário de bibliotecas ou aplicações de
usuários normais, o fluxo global de controle do programa não é definido pelo chamador, mas
pelo framework;
- Comportamento Padrão: um framework tem um comportamento padrão. Esse
comportamento padrão deve ser algum comportamento útil e não uma série de sequências
de instruções;
17/09/13 Como evitar erros comuns em bancos de dados
www.devmedia.com.br/como-evitar-erros-comuns-em-bancos-de-dados/28972 6/10
- Extensibilidade: um framework pode ser estendido pelo usuário geralmente por
seletividade de código ou especializada pelo código do usuário para fornecer uma
funcionalidade específica;
- Código de Framework Não Modificável: o código do framework, em geral, não é passível de
ser modificado, exceto extensibilidade. Os usuários podem estender o framework, mas não
modificar seu código.
Frameworks normalmente possuem clareza considerável e código útil, a fim de ajudar as
aplicações de usuários do programa de inicialização, mas geralmente o foco está em
domínios de problemas específicos, tais como:
- Desenho artístico, composição musical e CAD mecânico;
- Compiladores para diferentes linguagens de programação;
- Aplicações de modelagem financeira;
- Sistemas de apoio à tomada de decisão;
- Reprodução de mídia e criação;
- Aplicações Web;
- Middleware;
- Computação científica de alto desempenho.
Pegadinha #2: passagem de contexto entre programas
dependentes
Da mesma forma que há a necessidade de modificar as consultas para lidar com várias colunas
que têm o mesmo nome, um ninja vai pontuar um sério problema ao tentar usar um framework
que passa contextos (critérios de seleção) de um programa para outro. Imagine que o banco de
dados tenha duas tabelas chamadas “CLIENTE” e “PEDIDO”, em que a tabela “PEDIDO” tem uma
chave estrangeira que aponta para uma entrada na tabela “CLIENTE”. A aplicação terá, portanto,
dois programas chamados “LISTAR CLIENTES” e “LISTAR PEDIDOS”. Caso nenhum critério de
seleção seja informado para o programa “LISTAR PEDIDOS”, ele irá retornar todos os pedidos no
sistema, independentemente do cliente.
Agora, suponha que no programa “LISTAR CLIENTES” seja possível selecionar um cliente e, em
seguida, pressionar um botão para ir para o programa “LISTAR PEDIDOS” para mostrar apenas
os pedidos que estão associados a esse cliente. O programa “LISTAR CLIENTES” tem que passar
os critérios de seleção relevantes para o programa “LISTAR PEDIDOS” para que ele possa
recuperar os registros desejados.
17/09/13 Como evitar erros comuns em bancos de dados
www.devmedia.com.br/como-evitar-erros-comuns-em-bancos-de-dados/28972 7/10
Pelo fato dessas duas tabelas estarem relacionadas, a chave primária na tabela “CLIENTE”
também é uma chave estrangeira na tabela “PEDIDO”, então o contexto (critérios de seleção),
que é passado do “LISTAR CLIENTES” para o programa “LISTAR PEDIDOS” é a chave primária do
registro do cliente selecionado.
Esse contexto pode ser passado como um simples string no formato <nome_pk>=’<cod_cliente>’
como, por exemplo, ID_CLIENTE=’12345’. Uma vez que o(s) nome(s) da(s) coluna(s) da chave
primária é(são) “exatamente” o(s) mesmo(s) que o(s) nome(s) da(s) coluna(s) da chave
estrangeira, então o programa receptor pode usar o contexto passado sem a necessidade de
qualquer processamento adicional.
Todo esse processo se torna mais complicado se o(s) nome(s) da(s) coluna(s) não é(são)
“exatamente” o(s) mesmo(s), por exemplo, quando todas as colunas de chave primária de cada
tabela tem o mesmo nome. Isto significa que a coluna “ID” na tabela “CLIENTE” não pode ser
utilizada como a coluna “ID” na tabela “PEDIDO”, pois uma contém a identidade do cliente
enquanto a outra contém a identidade do pedido.
O programa dependente que recebe o contexto de um outro programa agora necessita de um
código adicional para traduzir o(s) nome(s) da(s) coluna(s), portanto, neste exemplo, a coluna
“ID” tem de ser traduzida em “ID_CLIENTE”. Este processo de conversão geralmente significa um
trabalho extra para o programador, uma vez que não seria possível de ser automatizado, a
menos que o programa receptor tenha as seguintes informações:
· O nome da tabela a partir da qual a chave primária foi gerada;
· Detalhes do relacionamento com essa tabela, de modo que o(s) nome(s) da(s) coluna(s) da
chave primária possa(m) ser traduzida(s) para a(s) coluna(s) de chave estrangeira
correspondente.
Esta informação não está geralmente disponível e, por consequência, o processo não pode ser
facilmente automatizado.
Este é um caso típico em que o esforço necessário para implementar a solução manual é muito
maior do que a “economia” gerada pela decisão original da modelagem.
Mas e agora? Ainda continua achando que a ideia original em economizar no nome das colunas
foi realmente uma ideia brilhante?
Conclusão
Como demonstrei neste pequeno tutorial, muitas vezes ideias aparentemente geniais no
momento da modelagem do banco de dados podem se transformar em verdadeiras dores de
cabeça.
São armadilhas que não “pegarão” um profissional experiente (um ninja) ou, ao menos, um
profissional disposto a contestar, pesquisar, analisar, testar e concluir.
Sim, concordo plenamente que não é necessário reinventar a roda e boas práticas devem ser
17/09/13 Como evitar erros comuns em bancos de dados
www.devmedia.com.br/como-evitar-erros-comuns-em-bancos-de-dados/28972 8/10
sempre consideradas, mas isso não significa seguir as regras cegamente sem ao menos analisar
se esta regra se aplica de maneira eficaz ao caso em que se está trabalhando.
Este foi apenas um caso apresentado em que, uma simples decisão de simplificar o(s) nome(s) de
coluna(s) pode gerar um impacto realmente grande.
A mensagem que deixo é que SEMPRE alguém (ou alguma coisa) vai ter que pagar um preço. Há
uma frase célebre que uso sempre com meus alunos: “There’s no free lunch!” ou “Ninguém almoça
de graça!”. É DEVER dos DBAs e DAs se preocupar com o impacto que qualquer implementação
possa gerar tanto para os desenvolvedores quanto para a aplicação e também para o banco de
dados.
Um administrador de banco de dados (DBA) é uma pessoa responsável pela instalação,
configuração, atualização, administração, monitoramento e manutenção de bases de dados em
uma organização.
O papel inclui o desenvolvimento e concepção de estratégias de banco de dados, monitoramento
do sistema e melhorar o desempenho e a capacidade do banco de dados, e planejamento para
as necessidades de expansão futura. Eles também podem planejar, coordenar e implementar
medidas de segurança para proteger o banco de dados.
DBAs também são conhecidos como Coordenador do Banco de Dados ou Programador de Banco
de Dados, embora um programador de banco de dados requer habilidades mais avançadas em
programação SQL que um DBA precise ter, e um programador de banco de dados pode não ter e
não requer as habilidades de administração de banco de dados, backup, restauração,
monitoramento ou ajustes de desempenho.
O papel está intimamente relacionado com as funções de Analista de Banco de Dados, Modelador
de Banco de Dados, Analista Programador e Gerente de Sistemas.
Algumas organizações consideram um nível hierárquico de administradores de banco de dados,
da seguinte forma:
- Analista de dados / designer de consulta;
- DBA Júnior;
- DBA Pleno;
- DBA Sênior;
- DBA Consultor;
- Gerente / Diretor de Administração de Banco de Dados / Tecnologia da Informação.
Já um arquiteto de dados (DA) em é um profissional responsável por garantir que os dados de
uma organização sejam apoiados por uma arquitetura de dados que auxilia a organização a
alcançar seus objetivos estratégicos. A arquitetura de dados deve cobrir os bancos de dados,
integração de dados e os meios para obter os dados. Normalmente, o arquiteto de dados alcança
Recommended