Artigo SQL Magazine 32 - + de 90 Dicas de modelagem de dados

Dicas de modelagem de dados Modelagem de dados: projeto conceitual 1. Sempre faa modelagem de dados, isso ajuda no entendimento do problema e no planejamento de uma soluo mais aderente aos seus objetivos. O objetivo do modelo conceitual a definio do problema, no da soluo. 2. Existem diferentes terminologias para modelagem conceitual. Os exemplos da Figura 1 representam diferentes notaes para um relacionamento 1:N, sendo as mais comuns de serem implementadas pelas atuais ferramentas CASE. A primeira notao, de Peter Chen, a mais utilizada para a construo do modelo conceitual enquanto a segunda, do P de Galinha, a mais utilizada para a construo do modelo lgico.

Figura 1. Notaes para modelagem de dados.

3. Elimine qualquer redundncia de dados. Redundncias permitidas so aquelas relativas a chaves estrangeiras, que fazem referncia chave primria de outra tabela. Por exemplo, no se deve repetir o nome do cliente em seus pedidos, pois ele pode ser facilmente obtido atravs do relacionamento. 4. Utilize um padro para dar nomes a entidades. Normalmente, nomes de entidades so no singular.

5. D nomes significativos a entidades, atributos e relacionamentos. Nomes que no representam seu real objetivo dificultam a compreenso do modelo. 6. Deve-se determinar os relacionamentos e, decidir como a relao de dependncia entre cada entidade sempre importante. Os tipos de relacionamento podem ser: 0:1 (mnimo: nenhum mximo: um);

0:N (mnimo: nenhum mximo: muitos); 1:1 (mnimo: um mximo: um);

1:N (mnimo: um mximo; muitos); N:N (mnimo: muitos mximo: muitos).

7. Relacionamentos no obrigatoriamente precisam ter nomes, mas uma boa prtica de modelagem nome-los, pois facilita o entendimento. Assim, utilize nomes significativos para os relacionamentos, como apresentado na Figura 2 para o relacionamento Lotao.

Figura 2. Nomeando relacionamentos.

8. Relacionamentos N:N ou que possuem atributos normalmente geram novas tabelas no modelo lgico. 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 cdigo. Lembre-se que, no modelo lgico, este atributo ser repetido como chave estrangeira nas entidades relacionadas. Percebe-se na Figura 4 que, se o nome da chave primria da entidade Cliente for apenas codigo, quando repetida na entidade Pedido para representar o relacionamento, seu nome no ser representativo, ou seja, no se pode observar facilmente a qual entidade est associado. Se o atributo tivesse sido chamado de cod_cliente, esta associao seria muito mais fcil. Este problema seria mais grave se a entidade Pedido estivesse associada outra cujo nome de sua chave primria tambm fosse codigo. Teramos mais de um atributo com o mesmo nome, que as ferramentas CASE costumam modificar atribuindo uma seqncia numrica, o que dificulta enormemente a compreenso 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 numrico. A padronizao garante um bom entendimento dos atributos perante a equipe de desenvolvimento, garantindo eficincia na fase de desenvolvimento da aplicao. 11. Ateno para entidades desconectadas no diagrama. Podem no ser um problema, mas precisam ser verificadas. Por exemplo, comum que entidades que representem parmetros estejam soltas no diagrama.

12. Cuidado com relacionamentos com participao total em ambos os lados de um relacionamento (obrigatoriedade dos dois lados). Isso pode provocar uma situao onde uma entidade dependa da outra recursivamente. Alm disso, deve-se estar atentos a situaes 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 situao impede que Clientes sejam cadastrados sem Pedidos e que Pedidos sejam feitos sem Clientes.

Figura 5. Relacionamento com participao total em ambos os lados. Modelagem de dados: projeto lgico 13. Muitas vezes costuma-se pular a etapa de modelo conceitual de dados e passa-se diretamente para o modelo lgico. Em grande parte pode-se creditar isso a muitas ferramentas CASE, que partem diretamente do modelo lgico. Considera-se isso perigoso. A modelagem conceitual foi criada para atender s necessidades do usurio, sem limitaes tecnolgicas. Desta forma, no primeiro modelo, no se deve preocupar com chaves primrias e estrangeiras. As chaves so necessrias uma vez que assim que os SGBDs trabalham, mas isso no faz parte das necessidades do usurio. O mesmo pode ser dito com relao ao tipo e tamanho de dados, e ainda mais do mapeamento de relacionamentos 1:1 e n:n. O objetivo do projeto lgico a definio da soluo. 14. Vale lembrar que nem todo modelo lgico de dados a cpia fiel do modelo conceitual de dados. 15. Toda entidade do modelo conceitual vira uma tabela no modelo lgico. 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 informao se repete em diversas tabelas, um indcio de que existem colunas desnecessrias. Deve-se buscar a tabela que faa mais sentido para conter a coluna em questo. 18. Dimensione corretamente os tipos de dados em funo de seus contedos para diminuir o espao de armazenamento. 19. Campos de texto com tamanho varivel tendem a consumir menos espao 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 obrigatrio, pois no faz sentido cadastrar um cliente sem seu nome. Muitas vezes, preocupa-se apenas com a obrigatoriedade para os atributos chave, mas esta questo importante para todos os atributos, tomando-se o devido cuidado de no impor restries demais que impeam que novos registros possam ser inseridos. 21. Elimine atributos derivados ou calculados: no recomendado armazenar o resultado de clculos nas tabelas. O correto que o clculo seja gerado sob demanda, normalmente em uma consulta. 22. Toda tabela deve ter uma chave primria, que pode ser simples ou composta. A chave primria o identificador do registro e deve ser nica dentro de uma tabela. 23. Ao determinar a chave primria, deve-se escolher, em cada tabela, quais colunas formaro a chave primria. Para uma coluna ser candidata chave primria, dever atender aos principais requisitos: Dever ser a menor possvel; O seu valor dever ser diferente de vazio ou zero (not null); Dever ser de preferncia numrica; O seu valor dever ser nico para toda a tabela.

24. Chaves estrangeiras devem corresponder a chaves primrias da relao associada ou ser nulas, quando no for um campo obrigatrio. 25. Crie chaves cegas (Blind Key) toda vez que no for possvel identificar a chave primria, ou quando esta for muito complexa, composta por muitos atributos. Esses tipos de atributos geralmente so conhecidos por atributos falsos, ou seja, no fazem parte de forma explcita da regra de negcio, porm foram criados para garantir flexibilidade ou integridade ao modelo de dados desenvolvido. Por exemplo, um funcionrio pode ter diversos dependentes, que possuem nome e data de nascimento. Nenhum destes atributos, nem mesmo a concatenao deles, garante uma chave primria nica. Uma soluo a criao de um novo atributo determinante, como cod_dependente. 26. Refine os relacionamentos uma vez que alguns destes podero gerar novos elementos que complementaro o modelo, sendo estes: Relao de Herana (mutuamente exclusivo ou no): por exemplo, numa hierarquia de Funcionario contendo especializaes Gerente e Engenheiro, um determinado funcionrio pode ser Gerente e Engenheiro ao mesmo tempo?; Entidade Associativa: gerada quando informaes que necessitam ser armazenadas no podem ser colocadas numa das entidades do relacionamento. Acontece em situaes de relacionamentos com atributos ou relacionamentos N:N. 27. Relacionamentos so representados por chaves estrangeiras, ou Foreign Key (FK), atributos correspondentes chave primria de outra relao, estabelecendo a base para a integridade referencial. No exemplo da Figura 6, o atributo cod_cliente, chave primria da tabela Cliente, foi repetido na tabela Pedido para representar o relacionamento. Desta forma, um Pedido possui um cliente que necessariamente deve estar presente na tabela Cliente (atravs de seu cdigo).

Figura 6. Chaves estrangeiras representando relacionamentos.

28. Relacionamentos 1:1 podem ser mapeados numa nica tabela (quando possuem a mesma chave primria), em duas tabelas (quando as chaves primrias so diferentes e um dos lados do relacionamento obrigatrio) ou em trs tabelas (quando o relacionamento opcional em ambos os lados). No exemplo da Figura 7, tem-se as trs situaes representadas. Na primeira situao, Funcionario e Endereco teriam a mesma chave primria (matricula_funcionario) e puderam ser unificadas. Na segunda situao, as chaves primrias so diferentes e optou-se por colocar a chave estrangeira na tabela Departamento, uma vez que este possui obrigatoriamente um chefe, associado ao fato de que nem todo funcionrio ocupa um cargo de chefia. Na terceira e ltima situao, novamente as chaves so diferentes mas no existe obrigatoriedade em nenhum dos lados do relacionamento, no determinando assim o lado da chave estrangeira. Esta situao pode ser resolvida com uma nova tabela, como a tabela Chefia do exemplo.

Figura 7. Mapeamento de relacionamentos 1:1.

29. Em relacionamentos 1:1, a chave pode ser migrada para qualquer entidade envolvida, contudo, bom observar os seguintes critrios: havendo clara necessidade de recuperao de informao para um dos lados, migra-se o atributo para o lado da recuperao; Priorize colocar a chave estrangeira referenciando a obrigatoriedade do relacionamento, se existir.

30. Se houver necessidade do armazenamento de histrico, pode ser adotada como soluo a criao de uma nova tabela que mapear todos os elementos associados. Por exemplo, considere o modelo apresentado na Figura 8. Nele temos o relacionamento de 1:1 entre funcionrio e departamento. Optou-se pela criao de uma terceira tabela que mapear todos os funcionrios que foram gerentes dos departamentos da empresa. Perceba a incluso dos atributos data_inicio e data_fim, representando o perodo que determinado funcionrio chefiou um departamento. Alm disso, o atributo data_inicio foi colocado como parte da chave primria para permitir que um funcionrio chefie o mesmo departamento em perodos distintos.

Figura 8. Exemplo de armazenamento de histrico.

31. Relacionamentos 1:N so mapeados de forma que a chave primria do lado 1 seja representada do lado N como chave estrangeira. Isso se deve ao fato do modelo relacional no permitir atributos multivalorados. Assim, a soluo representar o lado 1 do relacionamento. A Figura 6 exemplifica esta situao. 32. Relacionamentos N:N devem virar novas relaes, associadas atravs de dois relacionamentos 1:n. Isso se deve ao fato de, no modelo relacional, no serem permitidos atributos multivalorados. Neste caso, a entidade criada possui como chave primria a concatenao das chaves das duas entidades relacionadas, formando uma chave composta. No exemplo da Figura 9, supondo que as chaves primrias das entidades Funcionario e Departamento sejam matricula e cod_departamento, respectivamente, a chave da entidade resultante Lotacao seria a unio das duas chaves.

Figura 9. Transformao de relacionamento n:n em dois relacionamentos 1:n.

33. Um conjunto de passos pode ser seguido para identificar a cardinalidade de um relacionamento entre duas entidades. Deve-se ter em mente que a anlise de todo relacionamento entre entidades bidirecional. Assim, deve-se analisar como determinada a cardinalidade existente entre, por exemplo, as entidades Cliente e Pedido (ver Figura 10).

Figura 10. Entidades Cliente e Pedido.

Passo 1: o primeiro passo ser determinar a cardinalidade existente entre Cliente e Pedido. Considerando a navegabilidade no sentido Cliente Pedido, realiza-se a seguinte pergunta: Um cliente pode fazer quantos pedidos? A resposta : 1 cliente pode realizar vrios pedidos. Ento, a cardinalidade existente ser de 1:N, pois a palavra vrios em modelagem relacional identificada pela letra N (ver Figura 11).

Figura 11. Entidades Cliente e Pedido Passo 1.

Passo 2: para realizar o segundo passo necessrio inverter a pergunta. Neste caso, determina-se a cardinalidade existente entre Pedido e Cliente. Percebe-se que se inverte a navegabilidade e realiza-se a seguinte pergunta: um Pedido pode possuir quantos clientes? A resposta : 1 pedido pode possuir 1 cliente. Dessa forma, a cardinalidade existente ser 1:1 (ver Figura 12).

Figura 12. Entidades Cliente e Pedido Passo 2.

 Passo 3: agora se tem em mos a cardinalidade completa, ou seja, nas duas direes. O prximo passo identificar a cardinalidade mxima para cada entidade definindo assim o relacionamento entre elas. Na posio vertical (identificada pelas elipses na Figura 13), tem-se a cardinalidade encontrada para cada entidade. No caso de Cliente, a maior cardinalidade ser 1 e para Pedido ser N.

Figura 13. Entidades Cliente e Pedido Passo 3.

Passo 4: por fim, na Figura 14 exibe-se o relacionamento final existente entre as duas entidades. Aqui temos uma dica importante: aps a implementao do modelo fsico, o atributo cod_cliente ser duplicado na tabela Pedido, garantindo assim o relacionamento entre as duas entidades. Isso quer dizer que um cliente no poder ser eliminado enquanto seus respectivos pedidos tambm no forem. Essa a terminologia padro, porm pode ser ajustada a cada caso.

Figura 14. Entidades Cliente e Pedido Final.

34. Relacionamentos do tipo Generalizao/Especializao possuem, no modelo lgico, a mesma chave primria em todas as entidades participantes da hierarquia. A Figura 15 representa uma hierarquia de funcionrios, onde todas as entidades possuem a mesma chave primria (matricula_funcionario). comum que a entidade mais genrica (Funcionario) tenha um atributo que represente o tipo dos funcionrios para facilitar que a hierarquia seja percorrida.

Figura 15. Hierarquia de entidades.

35. Generalizao/Especializao podem ser mapeadas em uma nica tabela, em uma tabela para cada especializao ou uma tabela para cada entidade envolvida, dependendo da situao. A Figura 16 apresenta as situaes de mapeamento. Na situao 1, todos os atributos da hierarquia foram agrupados numa nica tabela, fazendo com que atributos fiquem eventualmente vazios em funo do tipo do funcionrio. A situao 2 representa apenas as especializaes, fazendo com que os atributos da generalizao sejam repetidos. A situao 3 apresenta uma tabela para cada entidade da hierarquia, eliminando atributos repetidos, mas fazendo com que o acesso a um funcionrio tenha que agrupar dados de mais de uma tabela.

Figura 16. Generalizao / Especializao.

36. Relacionamentos com atributos devem virar novas relaes. Isso em funo de no existir o conceito de relacionamento no projeto lgico. Assim, os atributos devem ser transferidos para uma relao. A Figura 3 exemplifica esta situao. 37. A chave primria de uma entidade fraca deve ser formada pela chave primria da entidade forte e mais algum outro campo que diferencie os registros. A Figura 17 apresenta a entidade fraca ItemPedido, cuja chave primria formada pela chave de sua entidade forte (num_pedido) acrescida de um atributo prprio (num_item_pedido).

Figura 17. Mapeamento de entidade fraca.

38. Entidades fracas indicam que, ao eliminar a entidade forte correspondente, devem ser eliminadas todas as ocorrncias das entidades fracas, uma vez que a chave primria da entidade forte compe a chave primria da entidade fraca, e no pode virar nulo.

39. Ateno para relacionamentos com grau maior do que 2. Estes relacionamentos geram novas tabelas cujas chaves primrias referem-se s chaves das relaes participantes ou cria-se uma nova chave primria conforme exemplo da Figura 18. Neste exemplo, o relacionamento N:N entre Pedido e Produto dever ser decomposto em outros dois relacionamentos 1:N.

Figura 18. Mapeamento de relacionamento ternrio.

40. Agregaes normalmente originam novas tabelas. A Figura 19 representa uma agregao entre produtos e promoes, onde cada item de um pedido possui um produto em uma determinada promoo.

Figura 19. Mapeamento de agregao.

41. Auto-relacionamentos do tipo 1:N geram um atributo de ligao na prpria tabela, como demonstrado na Figura 20. Esta representa que um cliente pode indicar vrios clientes mas, por outro lado, um cliente s pode ser indicado por um outro. Sendo do tipo n:n, geram novas tabelas.

Figura 20. Mapeamento de auto-relacionamento. Normalizao 42. Faa sempre normalizao dos dados. uma forma de verificar sua qualidade, diminuindo redundncias e incoerncias no modelo de dados. O processo de normalizao aplica uma srie de regras sobre as tabelas de um modelo para verificar se

estas esto corretamente projetadas. Embora existam seis formas normais, ou regras de normalizao (so cinco Formas Normais e a Forma Normal de Boyce-Codd), normalmente utilizam-se apenas as trs primeiras formas normais. 43. Uma das preocupaes da Primeira Forma Normal refere-se a eliminar atributos compostos. Assim, atributos como Endereo devem ser decompostos em Logradouro, Nmero, Complemento, Bairro, Cidade, Estado, CEP, exemplificado na Figura 21.

Figura 21. Anlise da primeira forma normal atributo composto.

44. Se a Primeira Forma Normal no for obedecida, corre-se o risco de perda de informaes. Por exemplo, se o atributo Endereo no for decomposto, como saber se algum mora na cidade do Rio de Janeiro ou na Rua Rio de Janeiro em Belo Horizonte? 45. A Primeira Forma Normal tambm se refere a eliminar atributos multivalorados. A Figura 22 exemplifica a normalizao do atributo Telefones, que deve ser decomposto em diversos telefones, como comercial, celular e residencial (situao 1), ou ento virar uma nova tabela (situao 2).

Figura 22. Anlise da primeira forma normal atributo multivalorado.

46. Na Primeira Forma normal deve-se observar se todas as relaes possuem sua chave primria definida. Isto importante pois as formas normais seguintes baseiam-se na definio da chave primria. 47. Antes de realizar a anlise da Segunda Forma Normal, deve-se garantir que todas as relaes estejam na Primeira Forma Normal. 48. A Segunda Forma Normal determina que atributos no chave devem ser funcionalmente dependentes apenas da chave primria. Ou seja, deve-se analisar se todo atributo que no chave primria depende totalmente dela. Assim, no necessrio se preocupar com esta forma normal para tabelas que tenham chaves primrias simples, com apenas um atributo.

10

49. Considere a relao entre Pedido e ItemPedido conforme demonstrada inicialmente na Figura 23. Imagine que o atributo data_pedido tivesse sido colocado na tabela ItemPedido. Atravs da anlise da Segunda Forma Normal nesta tabela (que possui chave primria composta), pode-se verificar que a data_pedido depende apenas de parte da chave primria, o num_pedido, e no da chave primria completa, composta por num_pedido e num_item_pedido. Sem esta anlise, a data do pedido seria repetida para todos os itens de um mesmo pedido. A verificao da Segunda Forma Normal, neste exemplo, determina que o atributo data_pedido deva ser transferido para outra entidade.

Figura 23. Anlise da segunda forma normal.

50. Outras implicaes no exemplo da dica anterior seriam relativas a anomalias de incluso, alterao e excluso. Para anomalia de incluso, pode-se verificar que no possvel inserir a data do pedido enquanto no se registra um item do pedido. Para anomalia de excluso, se forem excludos todos os itens do pedido, perde-se a data do mesmo. Para anomalia de alterao, se a data do pedido precisar mudar, deve-se mudar a mesma em todos os seus itens. 51. Antes de proceder com a anlise da Terceira Forma Normal, deve-se garantir que todas as relaes estejam na Segunda Forma Normal. 52. A Terceira Forma Normal refere-se a atributos no chave mutuamente independentes, ou seja, que no dependam um do outro. Desta forma, verificado se existe dependncia funcional entre atributos no chave. 53. Considere a relao Funcionario conforme apresentada inicialmente na Figura 24. Pode-se verificar que esta relao est na Primeira e Segunda Formas Normais. Entretanto, existe um atributo no chave (nome_departamento) que depende de outro atributo no chave (cod_departamento). Este o tipo de problema de que trata a Terceira Forma Normal. Para resolv-lo, criase uma nova relao, no caso Departamento, contendo os atributos relacionados e mantm-se na relao original apenas aquele que determina o outro como chave estrangeira.

Figura 24. Anlise da terceira forma normal.

54. Ao no se obedecer a Terceira Forma Normal, corre-se os mesmos riscos apresentados na Segunda Forma Normal. Por exemplo, no se pode inserir um departamento antes que se tenha um funcionrio alocado nele. A eliminao de todos os funcionrios de um departamento acarreta na eliminao das informaes do prprio departamento. No caso de um departamento mudar de nome, esta modificao deve ser tratada em todos os funcionrios. Desnormalizao

11

55. O processo inverso normalizao chamado de desnormalizao. Nesse processo, uma ou mais entidades do modelo conceitual so aglutinadas em uma nica tabela de um esquema. A princpio, a nica razo para a aplicao da desnormalizao a de eliminar o custo das junes em operaes de seleo sobre as tabelas envolvidas. Entretanto, uma anlise superficial dessa frase pode levar o leitor a concluir que a desnormalizao sempre aumenta o desempenho no processamento de consultas de seleo. O raciocnio (errneo) para essa concluso seria o seguinte: se a quantidade de tabelas maior em um esquema relacional normalizado, ento haver um maior nmero de operaes de juno para a obteno do resultado das consultas nesse esquema do que em um esquema desnormalizado correspondente (operaes de juno so sabidamente bastante custosas do ponto de vista computacional). Conseqentemente, o custo da execuo de selees em um esquema normalizado sempre maior do que o custo sobre o esquema desnormalizado correspondente. 56. Considerando as junes, pode-se constatar que a sobrecarga de processamento necessria para manter a integridade dos dados pode no compensar o ganho de desempenho obtido com a desnormalizao. De fato, a manuteno da integridade pode necessitar das mesmas operaes de juno que a desnormalizao se propunha a eliminar! Para exemplificar, considere uma verso desnormalizada da tabela Pedido contendo as colunas das tabelas ItemPedido e Produto (ver Figura 25). Para obter informaes sobre pedidos, itens de pedidos e produtos, a utilizao dessa tabela desnormalizada realmente produz uma execuo mais eficiente. Afinal de contas, todos os dados necessrios esto armazenados em uma nica tabela, o que normalmente leva o SGBD a posicionar essas informaes em blocos de disco contguos. No entanto, o que acontece quando um nome de produto atualizado? Uma das operaes que devem ser realizadas para garantir que os dados permaneam consistentes atualizar todos os registros em que o produto em questo est contemplado. Deixa-se como exerccio para o leitor verificar que h tambm problemas quando da excluso e incluso de registros nessa tabela. Todos esses problemas provenientes da sua desnormalizao!

Figura 25. Tabela desnormalizada.

57. Um eventual benefcio obtido pela desnormalizao (aumento do desempenho em uma determinada consulta de seleo) tem seu preo: uma tabela desnormalizada fica vulnervel ao surgimento de anomalias quando manipulaes (atualizaes, incluses ou inseres) so realizadas sobre ela, e a integridade dos dados fica ameaada. 58. A sobrecarga necessria para manuteno da integridade dos dados no o nico fator a considerar quando o desenvolvedor estiver pensando em desnormalizar um esquema. H um outro aspecto menos bvio. Considere novamente os dados da tabela Pedido (ver Figura 25). Essa tabela armazena dados sobre trs conceitos distintos: pedidos, itens de pedidos e produtos. O que acontece quando aplicaes de bancos de dados precisam obter acesso a esses dados separadamente? Por exemplo, digamos que o departamento de logstica precisa fazer um levantamento sobre os produtos em estoque. Provavelmente, essa tarefa envolveria uma consulta sobre a tabela Produto para resgatar somente os dados relativos quantidade em estoque por produto. Como esses dados esto em uma tabela que possui diversas outras colunas no relacionadas a produtos, a quantidade de informaes sobre produtos por bloco de disco ser menor do que se houvesse uma tabela armazenando somente dados sobre produtos. Conseqentemente, o SGBD levar mais tempo para resgatar os dados necessrios para montar o relatrio de estoque ao utilizar a tabela desnormalizada. Perceba que esse ponto acaba indo de encontro ao citado anteriormente neste artigo, ou seja, um dos benefcios da desnormalizao (o no uso de junes) acaba sendo prejudicado em outras situaes. 59. De uma forma geral, se for tomada a deciso de aglutinar dados de duas ou mais tabelas em uma nica tabela (ou seja, desnormalizar), as aplicaes que necessitam ter acesso aos dados, que do contrrio estariam em uma tabela separada, tero agora que ler desnecessariamente outras informaes. E a leitura dessas outras informaes desnecessrias aumenta o tempo de processamento das consultas de seleo.

12

60. Vamos agora a um exemplo em que o uso da desnormalizao pode ser benfico. Imagine uma situao em que tenhamos as tabelas Produto e GrupoProduto (ver Figura 26). A tabela GrupoProduto possui uma classificao fixa para categorizar os diferentes produtos (ou seja, o nome dos grupos no muda). Neste caso, poderamos colocar o campo nome_grupo na tabela Produto para facilitar, por exemplo, a gerao de relatrios.

Figura 26. Exemplo de desnormalizao.

61. Imagine uma situao em que voc precise constantemente retornar um valor de um campo calculado. Pode ser interessante criar um campo valor_pedido do pedido na tabela Pedido para que, toda vez que precisar calcular o valor do pedido no seja necessrio percorrer seus itens e depois, os produtos, para chegar neste valor (ver Figura 27). Entretanto, temos tambm uma desvantagem: a cada mudana no pedido, este campo precisa ser recalculado e armazenado. Teoricamente, campos deste tipo (calculados), no precisariam ser armazenados.

Figura 27. Exemplo de desnormalizao.

62. Outra situao interessante de uso da desnormalizao a criao de histrico. No exemplo da Figura 28 pode-se perceber que se repete o valor do produto na tabela item_pedido. Isso pode ser interessante, pois, caso o valor do produto mude (na tabela Produto), mantm-se o histrico do valor praticado naquele item_pedido. Vale ressaltar que isso contraria a Terceira Forma Normal, pois o valor do produto depende do cdigo mas, em funo do histrico, justificvel.

Figura 28. Exemplo de desnormalizao.

63. Uma outra situao de uso para desnormalizao a eliminao de uma tabela quando pudermos pr-determinar os tipos de valores que ela contm, juntando na tabela original. No exemplo da Figura 29, como os tipos de telefones so conhecidos,

13

justifica-se eliminar a tabela Telefone e agrupar estes dados em Funcionrio (neste caso estamos considerando apenas um telefone por tipo).

Figura 29. Exemplo de desnormalizao. Modelagem de dados: projeto fsico 64. O projeto fsico se preocupa com questes de desempenho, criao de ndices, particionamento, paralelismo e tuning, dentre outros. Assim, diversas caractersticas do projeto fsico esto associadas a um SGBD especfico. 65. A criao de ndices para chaves estrangeiras tendem a melhorar o desempenho de consultas complexas ou que envolvam muitas tabelas ou ainda tabelas com muitos registros. 66. Verificar a necessidade de chaves artificiais (Surrogate Key): em alguns casos depara-se com certas tabelas que no possuem uma chave primria natural, o que far com que haja a necessidade de se criar uma nova coluna para ser a chave primria. Neste caso, temos a criao de um novo campo nico que represente sua chave, como um seqencial, por exemplo. 67. Validao do modelo: antes de gerar os scripts de criao do banco de dados, fundamental verificar o modelo para identificar se este responde aos resultados esperados. 68. Atente para as configuraes necessrias a serem realizadas nas ferramentas CASE antes da gerao do script. Muitas delas trazem opes especficas para cada SGBD. 69. No utilize muitos atributos nas chaves nas tabelas: apesar de muitas vezes isso acontecer no modelo lgico, quando se implementa no banco de dados um modelo com muitos atributos na chave complica-se desnecessariamente a programao. A sugesto a criao de chaves alternativas que facilitam o acesso aos dados. Fragmentao de relaes 70. Para desenvolver um projeto de banco de dados adequado, o projetista, dentre as muitas decises que deve tomar para o sucesso ou fracasso do projeto, deve decidir tambm se os dados sero distribudos pelo local de uso ou sero centralizados e acessados via rede pelos usurios. Essa deciso envolve custos de infra-estrutura, perda ou melhoria de desempenho no acesso aos dados, interferindo tambm na disponibilidade imediata ou posterior desses dados.

Algumas razes para no realizar a fragmentao 71. Quando no houver necessidade de deixar os dados prximos aos usurios: neste caso, no deve haver a necessidade de grandes operaes de manipulao de dados por parte dos usurios; 72. Quando a fragmentao gerar muita duplicidade trazendo problemas de consistncias: muitas vezes ao realizarmos a fragmentao, precisamos realizar a duplicao de alguns registros. Quando a poltica de replicao e/ou sincronizao for um problema, evite fragmentar sua base de dados; 73. Quando houver restries tecnolgicas que impeam a fragmentao; 74. Quando houver dificuldade em manter a distribuio otimizada dentro de um cenrio de mudana de aplicaes: este tpico tambm diz respeito aos processos de replicao e sincronizao. Ambos no so, na maioria das vezes, triviais de serem realizados, portanto, tenha isso em mente.

14

Algumas razes para fragmentar 75. Quando os dados precisam estar prximos dos seus usurios: isso ocorre quando h necessidade de grandes operaes de manipulao de dados por parte dos usurios. Se os dados no estiverem localizados no ambiente operacional, estas operaes se tornaro bastante custosas e, a depender do caso, bastante lentas; 76. Quando a decomposio de uma relao em fragmentos permitir um maior nmero de transaes em execuo concorrente. 77. Dessa forma, devemos considerar a realizao da fragmentao quando a distribuio dos dados traz vantagens considerando, principalmente a localizao dos dados e o desempenho das operaes de manipulao de dados. Alm destes tpicos, pode-se ainda ter a necessidade de realizar a fragmentao por questes estratgicas da organizao. Por exemplo, parte dos dados de uma base podem ser fundamentais para o sucesso do negcio, ao invs de mant-los juntos aos outros dados, podemos fragmentar a base de forma que estes dados mais sensveis sejam colocados em outro servidor com polticas mais severas de segurana.

Tcnicas bsicas de fragmentao

Fragmentao vertical 78. A fragmentao vertical ocorre quando colunas da mesma tabela so separadas em locais diferentes. Conforme pode ser visto no exemplo da Tabela 1, todas as colunas esto centralizadas em uma nica tabela e nas Tabelas 2 e 3 as colunas esto fragmentadas de forma vertical. Essa fragmentao ser vantajosa quando os aplicativos dos diversos usurios puderem atuar de forma separada em cada fragmento minimizando desta forma o tempo de processamento.

Tabela 1. Relao Cliente sem fragmentao.

Tabela 2. Fragmento vertical da Relao Cliente sem o atributo Limite.

15

Tabela 3. Fragmento vertical da Relao Cliente contendo apenas a chave e o limite.

79. importante ressaltar que se uma relao for decomposta verticalmente em outras, ento qualquer registro existente na primeira relao tambm deve ser encontrado nas demais, para que haja a correta reconstruo do registro.

Fragmentao horizontal 80. A fragmentao horizontal ocorre quando registros de uma mesma tabela so separados em fragmentos diferentes. Conforme pode ser visto no exemplo mais adiante, cada filial armazenar os dados sobre os seus clientes. 81. A questo que se deve ter em mente ao optar por uma fragmentao horizontal : as consultas tm vises locais dos dados? Em caso afirmativo, com certeza haver melhora de desempenho ao se evitar ler dados de clientes de outras filiais e evitar acesso remoto desnecessrio. Alm disso, haver aumento no nmero de transaes concorrentes. A tabela base para nosso exemplo novamente a Tabela 1 sem fragmentao. Nas Tabelas 4, 5 e 6 temos os fragmentos horizontais da tabela Cliente onde os clientes so separados por filial.

Tabela 4. Fragmento horizontal da tabela Cliente contendo somente dados da Filial Belo Horizonte.

Tabela 5. Fragmento da tabela Cliente contendo somente da Filial Curitiba.

Tabela 6. Fragmento da tabela Cliente contendo somente da Filial So Paulo.

Para que a fragmentao ocorra de forma adequada, alguns critrios importantes devem ser considerados:

16

82. No caso de fragmentao horizontal, se um registro da tabela est em um fragmento, no poder estar tambm em outro fragmento. 83. Se houver uma tabela que dependa diretamente de outra, os registros relacionados devem ficar no mesmo local. 84. Para efetuar uma fragmentao horizontal, devemos considerar: a cardinalidade das tabelas; os critrios de selees por aplicao; a quantidade de registros recuperados por aplicao e por local; a freqncia de busca dos registros por aplicao e por local. 85. Deve-se considerar para cada fragmento a cardinalidade dos fragmentos e o tamanho de cada registro por fragmento; 86. Deve-se considerar para cada aplicao os fragmentos acessados, os critrios de seleo de registros e quantidade de registros selecionados por acesso de leitura, atualizaes em registros, freqncia de execuo por local de ativao e tempo mximo de resposta esperado; 87. Deve-se considerar para cada estao servidora, a capacidade de processamento e grau de utilizao e tambm a capacidade de armazenamento e grau de utilizao; 88. Deve-se considerar para a rede de comunicao, a capacidade da banda e grau de utilizao da rede. 89. Razes de restries tecnolgicas tambm exigiro que sejam feitas escolhas de atualizaes que melhor se adaptem infra-estrutura de cada organizao. Essa escolha pode envolver atualizaes assncronas que so aquelas atualizaes que ocorrem em horrios especficos para no prejudicar a performance do banco de dados, ou sncronas onde as atualizaes ocorrem em vrios locais simultaneamente. Essa escolha, como j foi dito, trar conseqncias sobre a performance do banco de dados e por isso dever ser extremamente criteriosa. A seguir so apresentadas algumas tcnicas de atualizao de bancos de dados distribudos: Extratos: so cpias que nunca sero atualizadas. teis em situaes que exigem apenas consultas. O extrato feito com ajuda de comandos SQL. So utilizadas, por exemplo, em sistemas de apoio deciso. Esses extratos podem ter ou no o registro do momento de sua criao, dependendo da necessidade desse tipo de informao. Extrato com substituio peridica: neste caso a cpia substituda em intervalos de tempos pr-definidos. So utilizadas, por exemplo, em sistemas de suporte a deciso e sistemas distribudos que utilizam dados atualizados com periodicidade bem definida. Rplicas com aplicao assncrona de atualizaes: as atualizaes so feitas nas cpias e no banco de dados original. Periodicamente, os bancos de dados so re-sincronizados. Podem ser usadas em sistemas onde as alteraes dos bancos de dados sejam feitos por incluses em qualquer um dos locais. Rplicas com aplicao sncrona de atualizaes: as atualizaes so feitas nas cpias e no BD original no momento de sua ocorrncia. Podem ser utilizadas em sistemas onde as alteraes dos bancos de dados sejam pouco freqentes e possam ser feitas em qualquer um dos locais. Ferramentas de modelagem 90. Utilize uma ferramenta CASE para modelagem de dados. Caso contrrio, o modelo tender a ficar desatualizado rapidamente, pois dificilmente as modificaes que so necessrias no esquema de dados so refletidas para a documentao sem o auxlio de uma ferramenta apropriada. 91. At pouco tempo atrs, a realizao das atividades de modelagem era dificultada para aqueles que no possuam recursos financeiros para comprar ferramentas de modelagem comerciais. Ficava assim difcil realizar atividades de modelagem. Com o advento da Internet e do software de cdigo aberto essa realidade foi se transformando e hoje j possvel encontrar algumas destas ferramentas gratuitas para modelagem de dados. Um bom exemplo disso a ferramenta DBDesigner 4 (ver Figura 30). Eis algumas das caractersticas que a tornam uma boa opo: Apresenta uma interface de fcil utilizao; Atende aos SGBDs: MySQL, Oracle, SQL Server, SQLite, e todos outros que suportem acesso via ODBC; Possui engenharia reversa;

17

Salva os arquivos em formato XML; Importa modelos gerados por algumas outras ferramentas; Gera relatrios em HTML; Suporte atravs do frum disponvel no site do DBDesigner; Realiza sincronia no banco de dados a partir das alteraes no modelo; multi-plataforma.

Para realizar o download, basta entrar no site .

Figura 30. DBDesigner 4. Concluso Neste artigo procuramos fazer uma coletnea de dicas de modelagem conceitual, contando com a colaborao de profissionais da rea. As dicas envolvem questes de modelagem de dados, tanto em nvel de modelo conceitual, lgico e fsico, quanto tcnicas de normalizao e desnormalizao. Tambm foram apresentadas dicas relativas fragmentao de dados e ferramentas CASE gratuitas de modelagem de dados. Esperamos que estas dicas sejam teis a todos aqueles envolvidos com modelagem de bancos de dados.

18