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