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).

1
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.

2
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.

3
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
4
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.

5
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.

6
 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.

7
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.

8
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.

9
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.

10
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.

11
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, cria-se 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
12
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

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

13
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.

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

14
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, 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.

15
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.

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

16
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.

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.

17
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:

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;
18
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;

Salva os arquivos em formato XML;

Importa modelos gerados por algumas outras ferramentas;

19
 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.

20