Os artigos dessa edição estão disponíveis somente através do formato HTML.
Clique aqui para ler todos os artigos desta edição
Dicas de modelagem de dados
A grande maioria dos desenvolvedores, mesmo não desempenhando formalmente o papel de DBA ou Analista de Dados, normalmente encontra-se envolvido com situações de modelagem de dados. Neste sentido, com o intuito de auxiliar o trabalho destes desenvolvedores, este artigo apresenta um conjunto bastante abrangente de dicas de modelagem.
Muitos dos problemas encontrados após a implementação de um banco de dados têm sua origem em uma modelagem de dados feita sem uma análise mais profunda do escopo do projeto. Outro fator que colabora para uma má modelagem é o desconhecimento de técnicas como a normalização e desnormalização de tabelas, bem como a não adoção de integridade referencial, que auxiliam na definição mais ajustada do modelo à realidade que irá atender.
Agora vamos às dicas!
Modelagem de dados: projeto conceitual
1. Sempre faça modelagem de dados, isso ajuda no entendimento do problema e no planejamento de uma solução mais aderente aos seus objetivos. O objetivo do modelo conceitual é a definição do problema, não da solução.
2. Existem diferentes terminologias para modelagem conceitual. Os exemplos da Figura 1 representam diferentes notações para um relacionamento 1:N, sendo as mais comuns de serem implementadas pelas atuais ferramentas CASE. A primeira notação, de Peter Chen, é a mais utilizada para a construção do modelo conceitual enquanto a segunda, do Pé de Galinha, é a mais utilizada para a construção do modelo lógico.
Figura 1. Notações para modelagem de dados.
3. Elimine qualquer redundância de dados. Redundâncias permitidas são aquelas relativas a chaves estrangeiras, que fazem referência à chave primária de outra tabela. Por exemplo, não se deve repetir o nome do cliente em seus pedidos, pois ele pode ser facilmente obtido através do relacionamento.
4. Utilize um padrão para dar nomes a entidades. Normalmente, nomes de entidades são no singular.
5. Dê nomes significativos a entidades, atributos e relacionamentos. Nomes que não representam seu real objetivo dificultam a compreensão do modelo.
6. Deve-se determinar os relacionamentos e, decidir como é a relação de dependência entre cada entidade é sempre importante. Os tipos de relacionamento podem ser:
· 0:1 (mínimo: nenhum – máximo: um);
· 0:N (mínimo: nenhum – máximo: muitos);
· 1:1 (mínimo: um – máximo: um);
· 1:N (mínimo: um – máximo; muitos);
· N:N (mínimo: muitos – máximo: muitos).
7. Relacionamentos não obrigatoriamente precisam ter nomes, mas é uma boa prática de modelagem nomeá-los, pois facilita o entendimento. Assim, utilize nomes significativos para os relacionamentos, como apresentado na Figura 2 para o relacionamento Lotação.
Figura 2. Nomeando relacionamentos.
8. Relacionamentos N:N ou que possuem atributos normalmente geram novas tabelas no modelo lógico. O nome do relacionamento pode ser utilizado como nome da tabela e deve ser cuidadosamente escolhido, como exemplificado na Figura 3.
Figura 3. Gerando tabelas a partir de relacionamentos.
9. Ao dar nomes a atributos determinantes, coloque sempre algo que identifique a entidade que está sendo relacionada. Por exemplo, um atributo chave cod_cliente é melhor do que simplesmente código. Lembre-se que, no modelo lógico, este atributo será repetido como chave estrangeira nas entidades relacionadas. Percebe-se na Figura 4 que, se o nome da chave primária da entidade Cliente for apenas codigo, quando repetida na entidade Pedido para representar o relacionamento, seu nome não será representativo, ou seja, não se pode observar facilmente a qual entidade está associado. Se o atributo tivesse sido chamado de cod_cliente, esta associação seria muito mais fácil. Este problema seria mais grave se a entidade Pedido estivesse associada à outra cujo nome de sua chave primária também fosse codigo. Teríamos mais de um atributo com o mesmo nome, que as ferramentas CASE costumam modificar atribuindo uma seqüência numérica, o que dificulta enormemente a compreensão do modelo.
Figura 4. Nomeando atributos chave.
10. Procure padronizar os nomes dos atributos de seu diagrama entidade relacionamento. Por exemplo, ao ver o atributo num_pedido percebe-se facilmente que seu tipo é numérico. A padronização garante um bom entendimento dos atributos perante a equipe de desenvolvimento, garantindo eficiência na fase de desenvolvimento da aplicação.
11. Atenção para entidades desconectadas no diagrama. Podem não ser um problema, mas precisam ser verificadas. Por exemplo, é comum que entidades que representem parâmetros estejam soltas no diagrama.
12. Cuidado com relacionamentos com participação total em ambos os lados de um relacionamento (obrigatoriedade dos dois lados). Isso pode provocar uma situação onde uma entidade dependa da outra recursivamente. Além disso, deve-se estar atentos a situações onde o banco de dados ainda está vazio e precisa-se cadastrar registros em apenas uma das entidades. Observe o exemplo abaixo da Figura 5. Um Cliente possui um ou mais Pedidos e um Pedido é obrigatoriamente de um Cliente. Devido à obrigatoriedade em ambos os lados do relacionamento, esta situação impede que Clientes sejam cadastrados sem Pedidos e que Pedidos sejam feitos sem Clientes.
Figura 5. Relacionamento com participação total em ambos os lados.
Modelagem de dados: projeto lógico
13. Muitas vezes costuma-se “pular” a etapa de modelo conceitual de dados e passa-se diretamente para o modelo lógico. Em grande parte pode-se creditar isso a muitas ferramentas CASE, que partem diretamente do modelo lógico. Considera-se isso perigoso. A modelagem conceitual foi criada para atender às necessidades do usuário, sem limitações tecnológicas. Desta forma, no primeiro modelo, não se deve preocupar com chaves primárias e estrangeiras. As chaves são necessárias uma vez que é assim que os SGBDs trabalham, mas isso não faz parte das necessidades do usuário. O mesmo pode ser dito com relação ao tipo e tamanho de dados, e ainda mais do mapeamento de relacionamentos 1:1 e n:n. O objetivo do projeto lógico é a definição da solução.
14. Vale lembrar que nem todo modelo lógico de dados é a cópia fiel do modelo conceitual de dados.
15. Toda entidade do modelo conceitual vira uma tabela no modelo lógico.
16. Deve-se relacionar diretamente cada coluna ao escopo da tabela: se um campo descreve o assunto de uma tabela diferente, este campo deve pertencer à outra tabela.
17. Elimine colunas repetidas no modelo: se uma informação se repete em diversas tabelas, é um indício de que existem colunas desnecessárias. Deve-se buscar a tabela que faça mais sentido para conter a coluna em questão.
18. Dimensione corretamente os tipos de dados em função de seus conteúdos para diminuir o espaço de armazenamento.
19. Campos de texto com tamanho variável tendem a consumir menos espaço de armazenamento.
20. Defina corretamente a obrigatoriedade para atributos das entidades de forma a retratar o objetivo da entidade. Por exemplo, o nome do cliente deve ser obrigatório, pois não faz sentido cadastrar um cliente sem seu nome. Muitas vezes, preocupa-se apenas com a obrigatoriedade para os atributos chave, mas esta questão é importante para todos os atributos, tomando-se o devido cuidado de não impor restrições demais que impeçam que novos registros possam ser inseridos.
21. Elimine atributos derivados ou calculados: não é recomendado armazenar o resultado de cálculos nas tabelas. O correto é que o cálculo seja gerado sob demanda, normalmente em uma consulta.
22. Toda tabela deve ter uma chave primária, que pode ser simples ou composta. A chave primária é o identificador do registro e deve ser única dentro de uma tabela.
23. Ao determinar a chave primária, deve-se escolher, em cada tabela, quais colunas formarão a chave primária. Para uma coluna ser candidata à chave primária, deverá atender aos principais requisitos:
· Deverá ser a menor possível;
· O seu valor deverá ser diferente de vazio ou zero (not null);
· Deverá ser de preferência numérica;
· O seu valor deverá ser único para toda a tabela.
24. Chaves estrangeiras devem corresponder a chaves primárias da relação associada ou ser nulas, quando não for um campo obrigatório.
25. Crie chaves cegas (Blind Key) toda vez que não for possível identificar a chave primária, ou quando esta for muito complexa, composta por muitos atributos. Esses tipos de atributos geralmente são conhecidos por atributos falsos, ou seja, não fazem parte de forma explícita da regra de negócio, porém foram criados para garantir flexibilidade ou integridade ao modelo de dados desenvolvido. Por exemplo, um funcionário pode ter diversos dependentes, que possuem nome e data de nascimento. Nenhum destes atributos, nem mesmo a concatenação deles, garante uma chave primária única. Uma solução é a criação de um novo atributo determinante, como cod_dependente.
26. Refine os relacionamentos uma vez que alguns destes poderão gerar novos elementos que complementarão o modelo, sendo estes:
· Relação de Herança (mutuamente exclusivo ou não): por exemplo, numa hierarquia de Funcionario contendo especializações Gerente e Engenheiro, um determinado funcionário pode ser Gerente e Engenheiro ao mesmo tempo?;
· Entidade Associativa: gerada quando informações que necessitam ser armazenadas não podem ser colocadas numa das entidades do relacionamento. Acontece em situações de relacionamentos com atributos ou relacionamentos N:N.
...
