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 igura 1 representam diferentes nota!es
para um relacionamento 1"#, sendo as mais comuns de serem implementadas pelas atuais ferramentas $%SE. % primeira
notao, de &eter $'en, a mais utili(ada para a construo do modelo conceitual en)uanto a segunda, do & de *alin'a, a
mais utili(ada para a construo do modelo l+gico.

igura 1. #ota!es para modelagem de dados.

,. Elimine )ual)uer redund-ncia de dados. .edund-ncias permitidas so a)uelas relativas a c'aves estrangeiras, )ue
fa(em refer/ncia 0 c'ave prim1ria de outra tabela. &or exemplo, no se deve repetir o nome do cliente em seus pedidos, pois
ele pode ser facilmente obtido atravs do relacionamento.
2. 3tili(e um padro para dar nomes a entidades. #ormalmente, nomes de entidades so no singular.
4. 5/ nomes significativos a entidades, atributos e relacionamentos. #omes )ue no representam seu real objetivo
dificultam a compreenso do modelo.
6. 5eve7se determinar os relacionamentos e, decidir como a relao de depend/ncia entre cada entidade sempre
importante. Os tipos de relacionamento podem ser"
8 9"1 :m;nimo" nen'um < m1ximo" um=>
8 9"# :m;nimo" nen'um < m1ximo" muitos=>
8 1"1 :m;nimo" um < m1ximo" um=>
1
8 1"# :m;nimo" um < m1ximo> muitos=>
8 #"# :m;nimo" muitos < m1ximo" muitos=.
?. .elacionamentos no obrigatoriamente precisam ter nomes, mas uma boa pr1tica de modelagem nome17los, pois
facilita o entendimento. %ssim, utili(e nomes significativos para os relacionamentos, como apresentado na igura 2 para o
relacionamento @otao.

igura 2. #omeando relacionamentos.

A. .elacionamentos #"# ou )ue possuem atributos normalmente geram novas tabelas no modelo l+gico. O nome do
relacionamento pode ser utili(ado como nome da tabela e deve ser cuidadosamente escol'ido, como exemplificado na igura
,.
igura ,. *erando tabelas a partir de relacionamentos.

B. %o dar nomes a atributos determinantes, colo)ue sempre algo )ue identifi)ue a entidade )ue est1 sendo relacionada. &or
exemplo, um atributo c'ave codCcliente mel'or do )ue simplesmente c+digo. @embre7se )ue, no modelo l+gico, este atributo
ser1 repetido como c'ave estrangeira nas entidades relacionadas. &ercebe7se na igura 2 )ue, se o nome da c'ave prim1ria
da entidade $liente for apenas codigo, )uando repetida na entidade &edido para representar o relacionamento, seu nome no
ser1 representativo, ou seja, no se pode observar facilmente a )ual entidade est1 associado. Se o atributo tivesse sido
c'amado de codCcliente, esta associao seria muito mais f1cil. Este problema seria mais grave se a entidade &edido
estivesse associada 0 outra cujo nome de sua c'ave prim1ria tambm fosse codigo. Der;amos mais de um atributo com o
mesmo nome, )ue as ferramentas $%SE costumam modificar atribuindo uma se)E/ncia numrica, o )ue dificulta
enormemente a compreenso do modelo.
igura 2. #omeando atributos c'ave.

19. &rocure padroni(ar os nomes dos atributos de seu diagrama entidade relacionamento. &or exemplo, ao ver o atributo
numCpedido percebe7se facilmente )ue seu tipo numrico. % padroni(ao garante um bom entendimento dos atributos
perante a e)uipe de desenvolvimento, garantindo efici/ncia na fase de desenvolvimento da aplicao.
11. %teno para entidades desconectadas no diagrama. &odem no ser um problema, mas precisam ser verificadas. &or
exemplo, comum )ue entidades )ue representem par-metros estejam soltas no diagrama.
2
12. $uidado com relacionamentos com participao total em ambos os lados de um relacionamento :obrigatoriedade dos dois
lados=. Fsso pode provocar uma situao onde uma entidade dependa da outra recursivamente. %lm disso, deve7se estar
atentos a situa!es onde o banco de dados ainda est1 va(io e precisa7se cadastrar registros em apenas uma das entidades.
Observe o exemplo abaixo da igura 4. 3m $liente possui um ou mais &edidos e um &edido obrigatoriamente de um $liente.
5evido 0 obrigatoriedade em ambos os lados do relacionamento, esta situao impede )ue $lientes sejam cadastrados sem
&edidos e )ue &edidos sejam feitos sem $lientes.

igura 4. .elacionamento com participao total em ambos os lados.
Godelagem de dados" projeto l+gico
1,. Guitas ve(es costuma7se HpularI a etapa de modelo conceitual de dados e passa7se diretamente para o modelo l+gico. Em
grande parte pode7se creditar isso a muitas ferramentas $%SE, )ue partem diretamente do modelo l+gico. $onsidera7se isso
perigoso. % modelagem conceitual foi criada para atender 0s necessidades do usu1rio, sem limita!es tecnol+gicas. 5esta
forma, no primeiro modelo, no se deve preocupar com c'aves prim1rias e estrangeiras. %s c'aves so necess1rias uma ve(
)ue assim )ue os S*J5s trabal'am, mas isso no fa( parte das necessidades do usu1rio. O mesmo pode ser dito com
relao ao tipo e taman'o de dados, e ainda mais do mapeamento de relacionamentos 1"1 e n"n. O objetivo do projeto l+gico
a definio da soluo.
12. Kale lembrar )ue nem todo modelo l+gico de dados a c+pia fiel do modelo conceitual de dados.
14. Doda entidade do modelo conceitual vira uma tabela no modelo l+gico.
16. 5eve7se relacionar diretamente cada coluna ao escopo da tabela" se um campo descreve o assunto de uma tabela
diferente, este campo deve pertencer 0 outra tabela.
1?. Elimine colunas repetidas no modelo" se uma informao se repete em diversas tabelas, um ind;cio de )ue existem
colunas desnecess1rias. 5eve7se buscar a tabela )ue faa mais sentido para conter a coluna em )uesto.
1A. 5imensione corretamente os tipos de dados em funo de seus conteLdos para diminuir o espao de arma(enamento.
1B. $ampos de texto com taman'o vari1vel tendem a consumir menos espao de arma(enamento.
29. 5efina corretamente a obrigatoriedade para atributos das entidades de forma a retratar o objetivo da entidade. &or
exemplo, o nome do cliente deve ser obrigat+rio, pois no fa( sentido cadastrar um cliente sem seu nome. Guitas ve(es,
preocupa7se apenas com a obrigatoriedade para os atributos c'ave, mas esta )uesto importante para todos os atributos,
tomando7se o devido cuidado de no impor restri!es demais )ue impeam )ue novos registros possam ser inseridos.
21. Elimine atributos derivados ou calculados" no recomendado arma(enar o resultado de c1lculos nas tabelas. O correto
)ue o c1lculo seja gerado sob demanda, normalmente em uma consulta.
22. Doda tabela deve ter uma c'ave prim1ria, )ue pode ser simples ou composta. % c'ave prim1ria o identificador do registro
e deve ser Lnica dentro de uma tabela.
2,. %o determinar a c'ave prim1ria, deve7se escol'er, em cada tabela, )uais colunas formaro a c'ave prim1ria. &ara uma
coluna ser candidata 0 c'ave prim1ria, dever1 atender aos principais re)uisitos"
8 5ever1 ser a menor poss;vel>
8 O seu valor dever1 ser diferente de va(io ou (ero :not null=>
8 5ever1 ser de prefer/ncia numrica>
8 O seu valor dever1 ser Lnico para toda a tabela.
3

22. $'aves estrangeiras devem corresponder a c'aves prim1rias da relao associada ou ser nulas, )uando no for um
campo obrigat+rio.
24. $rie c'aves cegas :Jlind MeN= toda ve( )ue no for poss;vel identificar a c'ave prim1ria, ou )uando esta for muito
complexa, composta por muitos atributos. Esses tipos de atributos geralmente so con'ecidos por atributos falsos, ou seja, no
fa(em parte de forma expl;cita da regra de neg+cio, porm foram criados para garantir flexibilidade ou integridade ao modelo
de dados desenvolvido. &or exemplo, um funcion1rio pode ter diversos dependentes, )ue possuem nome e data de
nascimento. #en'um destes atributos, nem mesmo a concatenao deles, garante uma c'ave prim1ria Lnica. 3ma soluo a
criao de um novo atributo determinante, como codCdependente.
26. .efine os relacionamentos uma ve( )ue alguns destes podero gerar novos elementos )ue complementaro o modelo,
sendo estes"
8 .elao de Oerana :mutuamente exclusivo ou no=" por exemplo, numa 'ierar)uia de uncionario contendo
especiali(a!es *erente e Engen'eiro, um determinado funcion1rio pode ser *erente e Engen'eiro ao mesmo tempoP>
8 Entidade %ssociativa" gerada )uando informa!es )ue necessitam ser arma(enadas no podem ser colocadas numa
das entidades do relacionamento. %contece em situa!es de relacionamentos com atributos ou relacionamentos #"#.
2?. .elacionamentos so representados por c'aves estrangeiras, ou oreign MeN :M=, atributos correspondentes 0 c'ave
prim1ria de outra relao, estabelecendo a base para a integridade referencial. #o exemplo da igura 6, o atributo codCcliente,
c'ave prim1ria da tabela $liente, foi repetido na tabela &edido para representar o relacionamento. 5esta forma, um &edido
possui um cliente )ue necessariamente deve estar presente na tabela $liente :atravs de seu c+digo=.


igura 6. $'aves estrangeiras representando relacionamentos.

2A. .elacionamentos 1"1 podem ser mapeados numa Lnica tabela :)uando possuem a mesma c'ave prim1ria=, em duas
tabelas :)uando as c'aves prim1rias so diferentes e um dos lados do relacionamento obrigat+rio= ou em tr/s tabelas
:)uando o relacionamento opcional em ambos os lados=. #o exemplo da igura ?, tem7se as tr/s situa!es representadas.
#a primeira situao, uncionario e Endereco teriam a mesma c'ave prim1ria :matriculaCfuncionario= e puderam ser
unificadas. #a segunda situao, as c'aves prim1rias so diferentes e optou7se por colocar a c'ave estrangeira na tabela
5epartamento, uma ve( )ue este possui obrigatoriamente um c'efe, associado ao fato de )ue nem todo funcion1rio ocupa um
cargo de c'efia. #a terceira e Lltima situao, novamente as c'aves so diferentes mas no existe obrigatoriedade em
nen'um dos lados do relacionamento, no determinando assim o lado da c'ave estrangeira. Esta situao pode ser resolvida
com uma nova tabela, como a tabela $'efia do exemplo.
4

igura ?. Gapeamento de relacionamentos 1"1.

2B. Em relacionamentos 1"1, a c'ave pode ser migrada para )ual)uer entidade envolvida, contudo, bom observar os
seguintes critrios"
8 'avendo clara necessidade de recuperao de informao para um dos lados, migra7se o atributo para o lado da
recuperao>
8 &riori(e colocar a c'ave estrangeira referenciando a obrigatoriedade do relacionamento, se existir.

,9. Se 'ouver necessidade do arma(enamento de 'ist+rico, pode ser adotada como soluo a criao de uma nova tabela
)ue mapear1 todos os elementos associados. &or exemplo, considere o modelo apresentado na igura A. #ele temos o
relacionamento de 1"1 entre funcion1rio e departamento. Optou7se pela criao de uma terceira tabela )ue mapear1 todos os
funcion1rios )ue foram gerentes dos departamentos da empresa. &erceba a incluso dos atributos dataCinicio e dataCfim,
representando o per;odo )ue determinado funcion1rio c'efiou um departamento. %lm disso, o atributo dataCinicio foi colocado
como parte da c'ave prim1ria para permitir )ue um funcion1rio c'efie o mesmo departamento em per;odos distintos.

igura A. Exemplo de arma(enamento de 'ist+rico.

,1. .elacionamentos 1"# so mapeados de forma )ue a c'ave prim1ria do lado H1I seja representada do lado H#I como c'ave
estrangeira. Fsso se deve ao fato do modelo relacional no permitir atributos multivalorados. %ssim, a soluo representar o
lado H1I do relacionamento. % igura 6 exemplifica esta situao.
,2. .elacionamentos #"# devem virar novas rela!es, associadas atravs de dois relacionamentos 1"n. Fsso se deve ao fato
de, no modelo relacional, no serem permitidos atributos multivalorados. #este caso, a entidade criada possui como c'ave
prim1ria a concatenao das c'aves das duas entidades relacionadas, formando uma c'ave composta. #o exemplo da igura
B, supondo )ue as c'aves prim1rias das entidades uncionario e 5epartamento sejam matricula e codCdepartamento,
respectivamente, a c'ave da entidade resultante @otacao seria a unio das duas c'aves.
5

igura B. Dransformao de relacionamento n"n em dois relacionamentos 1"n.

,,. 3m conjunto de passos pode ser seguido para identificar a cardinalidade de um relacionamento entre duas entidades.
5eve7se ter em mente )ue a an1lise de todo relacionamento entre entidades bidirecional. %ssim, deve7se analisar como
determinada a cardinalidade existente entre, por exemplo, as entidades $liente e &edido :ver igura 19=.

igura 19. Entidades $liente e &edido.

8 &asso 1" o primeiro passo ser1 determinar a cardinalidade existente entre $liente e &edido. $onsiderando a
navegabilidade no sentido $liente 0 &edido, reali(a7se a seguinte pergunta" 3m cliente pode fa(er )uantos pedidosP %
resposta " 1 cliente pode reali(ar v1rios pedidos. Ento, a cardinalidade existente ser1 de 1"#, pois a palavra Hv1riosI em
modelagem relacional identificada pela letra # :ver igura 11=.
igura 11. Entidades $liente e &edido < &asso 1.

8 &asso 2" para reali(ar o segundo passo necess1rio inverter a pergunta. #este caso, determina7se a cardinalidade
existente entre &edido e $liente. &ercebe7se )ue se inverte a navegabilidade e reali(a7se a seguinte pergunta" um &edido pode
possuir )uantos clientesP % resposta " 1 pedido pode possuir 1 cliente. 5essa forma, a cardinalidade existente ser1 1"1 :ver
igura 12=.
igura 12. Entidades $liente e &edido < &asso 2.

6
8 &asso ," agora se tem em mos a cardinalidade completa, ou seja, nas duas dire!es. O pr+ximo passo identificar a
cardinalidade m1xima para cada entidade definindo assim o relacionamento entre elas. #a posio vertical :identificada pelas
elipses na igura 1,=, tem7se a cardinalidade encontrada para cada entidade. #o caso de $liente, a maior cardinalidade ser1 1
e para &edido ser1 #.

igura 1,. Entidades $liente e &edido < &asso ,.

8 &asso 2" por fim, na igura 12 exibe7se o relacionamento final existente entre as duas entidades. %)ui temos uma dica
importante" ap+s a implementao do modelo f;sico, o atributo codCcliente ser1 HduplicadoI na tabela &edido, garantindo assim
o relacionamento entre as duas entidades. Fsso )uer di(er )ue um cliente no poder1 ser eliminado en)uanto seus respectivos
pedidos tambm no forem. Essa a terminologia padro, porm pode ser ajustada a cada caso.

igura 12. Entidades $liente e &edido < inal.

,2. .elacionamentos do tipo *enerali(aoQEspeciali(ao possuem, no modelo l+gico, a mesma c'ave prim1ria em todas as
entidades participantes da 'ierar)uia. % igura 14 representa uma 'ierar)uia de funcion1rios, onde todas as entidades
possuem a mesma c'ave prim1ria :matriculaCfuncionario=. R comum )ue a entidade mais genrica :uncionario= ten'a um
atributo )ue represente o tipo dos funcion1rios para facilitar )ue a 'ierar)uia seja percorrida.

igura 14. Oierar)uia de entidades.
7

,4. *enerali(aoQEspeciali(ao podem ser mapeadas em uma Lnica tabela, em uma tabela para cada especiali(ao ou
uma tabela para cada entidade envolvida, dependendo da situao. % igura 16 apresenta as situa!es de mapeamento. #a
situao 1, todos os atributos da 'ierar)uia foram agrupados numa Lnica tabela, fa(endo com )ue atributos fi)uem
eventualmente va(ios em funo do tipo do funcion1rio. % situao 2 representa apenas as especiali(a!es, fa(endo com )ue
os atributos da generali(ao sejam repetidos. % situao , apresenta uma tabela para cada entidade da 'ierar)uia,
eliminando atributos repetidos, mas fa(endo com )ue o acesso a um funcion1rio ten'a )ue agrupar dados de mais de uma
tabela.

igura 16. *enerali(ao Q Especiali(ao.

,6. .elacionamentos com atributos devem virar novas rela!es. Fsso em funo de no existir o conceito de relacionamento
no projeto l+gico. %ssim, os atributos devem ser transferidos para uma relao. % igura , exemplifica esta situao.
,?. % c'ave prim1ria de uma entidade fraca deve ser formada pela c'ave prim1ria da entidade forte e mais algum outro campo
)ue diferencie os registros. % igura 1? apresenta a entidade fraca Ftem&edido, cuja c'ave prim1ria formada pela c'ave de
sua entidade forte :numCpedido= acrescida de um atributo pr+prio :numCitemCpedido=.
igura 1?. Gapeamento de entidade fraca.

,A. Entidades fracas indicam )ue, ao eliminar a entidade forte correspondente, devem ser eliminadas todas as ocorr/ncias das
entidades fracas, uma ve( )ue a c'ave prim1ria da entidade forte comp!e a c'ave prim1ria da entidade fraca, e no pode virar
nulo.
8
,B. %teno para relacionamentos com grau maior do )ue 2. Estes relacionamentos geram novas tabelas cujas c'aves
prim1rias referem7se 0s c'aves das rela!es participantes ou cria7se uma nova c'ave prim1ria conforme exemplo da igura
1A. #este exemplo, o relacionamento #"# entre &edido e &roduto dever1 ser decomposto em outros dois relacionamentos 1"#.

igura 1A. Gapeamento de relacionamento tern1rio.

29. %grega!es normalmente originam novas tabelas. % igura 1B representa uma agregao entre produtos e promo!es,
onde cada item de um pedido possui um produto em uma determinada promoo.

igura 1B. Gapeamento de agregao.

21. %uto7relacionamentos do tipo 1"# geram um atributo de ligao na pr+pria tabela, como demonstrado na igura 29. Esta
representa )ue um cliente pode indicar v1rios clientes mas, por outro lado, um cliente s+ pode ser indicado por um outro.
Sendo do tipo n"n, geram novas tabelas.

igura 29. Gapeamento de auto7relacionamento.
#ormali(ao
22. aa sempre normali(ao dos dados. R uma forma de verificar sua )ualidade, diminuindo redund-ncias e incoer/ncias no
modelo de dados. O processo de normali(ao aplica uma srie de regras sobre as tabelas de um modelo para verificar se
9
estas esto corretamente projetadas. Embora existam seis formas normais, ou regras de normali(ao :so cinco ormas
#ormais e a orma #ormal de JoNce7$odd=, normalmente utili(am7se apenas as tr/s primeiras formas normais.
2,. 3ma das preocupa!es da &rimeira orma #ormal refere7se a eliminar atributos compostos. %ssim, atributos como
Endereo devem ser decompostos em @ogradouro, #Lmero, $omplemento, Jairro, $idade, Estado, $E&, exemplificado na
igura 21.

igura 21. %n1lise da primeira forma normal < atributo composto.

22. Se a &rimeira orma #ormal no for obedecida, corre7se o risco de perda de informa!es. &or exemplo, se o atributo
Endereo no for decomposto, como saber se algum mora na cidade do .io de Saneiro ou na .ua .io de Saneiro em Jelo
Oori(onteP
24. % &rimeira orma #ormal tambm se refere a eliminar atributos multivalorados. % igura 22 exemplifica a normali(ao do
atributo Delefones, )ue deve ser decomposto em diversos telefones, como comercial, celular e residencial :situao 1=, ou
ento virar uma nova tabela :situao 2=.

igura 22. %n1lise da primeira forma normal < atributo multivalorado.

26. #a &rimeira orma normal deve7se observar se todas as rela!es possuem sua c'ave prim1ria definida. Fsto importante
pois as formas normais seguintes baseiam7se na definio da c'ave prim1ria.
2?. %ntes de reali(ar a an1lise da Segunda orma #ormal, deve7se garantir )ue todas as rela!es estejam na &rimeira orma
#ormal.
2A. % Segunda orma #ormal determina )ue atributos no c'ave devem ser funcionalmente dependentes apenas da c'ave
prim1ria. Ou seja, deve7se analisar se todo atributo )ue no c'ave prim1ria depende totalmente dela. %ssim, no
necess1rio se preocupar com esta forma normal para tabelas )ue ten'am c'aves prim1rias simples, com apenas um atributo.
10
2B. $onsidere a relao entre &edido e Ftem&edido conforme demonstrada inicialmente na igura 2,. Fmagine )ue o atributo
dataCpedido tivesse sido colocado na tabela Ftem&edido. %travs da an1lise da Segunda orma #ormal nesta tabela :)ue
possui c'ave prim1ria composta=, pode7se verificar )ue a dataCpedido depende apenas de parte da c'ave prim1ria, o
numCpedido, e no da c'ave prim1ria completa, composta por numCpedido e numCitemCpedido. Sem esta an1lise, a data do
pedido seria repetida para todos os itens de um mesmo pedido. % verificao da Segunda orma #ormal, neste exemplo,
determina )ue o atributo dataCpedido deva ser transferido para outra entidade.

igura 2,. %n1lise da segunda forma normal.

49. Outras implica!es no exemplo da dica anterior seriam relativas a anomalias de incluso, alterao e excluso. &ara
anomalia de incluso, pode7se verificar )ue no poss;vel inserir a data do pedido en)uanto no se registra um item do
pedido. &ara anomalia de excluso, se forem exclu;dos todos os itens do pedido, perde7se a data do mesmo. &ara anomalia de
alterao, se a data do pedido precisar mudar, deve7se mudar a mesma em todos os seus itens.
41. %ntes de proceder com a an1lise da Derceira orma #ormal, deve7se garantir )ue todas as rela!es estejam na Segunda
orma #ormal.
42. % Derceira orma #ormal refere7se a atributos no c'ave mutuamente independentes, ou seja, )ue no dependam um do
outro. 5esta forma, verificado se existe depend/ncia funcional entre atributos no c'ave.
4,. $onsidere a relao uncionario conforme apresentada inicialmente na igura 22. &ode7se verificar )ue esta relao est1
na &rimeira e Segunda ormas #ormais. Entretanto, existe um atributo no c'ave :nomeCdepartamento= )ue depende de outro
atributo no c'ave :codCdepartamento=. Este o tipo de problema de )ue trata a Derceira orma #ormal. &ara resolv/7lo, cria7
se uma nova relao, no caso 5epartamento, contendo os atributos relacionados e mantm7se na relao original apenas
a)uele )ue determina o outro como c'ave estrangeira.

igura 22. %n1lise da terceira forma normal.

42. %o no se obedecer a Derceira orma #ormal, corre7se os mesmos riscos apresentados na Segunda orma #ormal. &or
exemplo, no se pode inserir um departamento antes )ue se ten'a um funcion1rio alocado nele. % eliminao de todos os
funcion1rios de um departamento acarreta na eliminao das informa!es do pr+prio departamento. #o caso de um
departamento mudar de nome, esta modificao deve ser tratada em todos os funcion1rios.
5esnormali(ao
11
44. O processo inverso 0 normali(ao c'amado de desnormali(ao. #esse processo, uma ou mais entidades do modelo
conceitual so aglutinadas em uma Lnica tabela de um es)uema. % princ;pio, a Lnica ra(o para a aplicao da
desnormali(ao a de eliminar o custo das jun!es em opera!es de seleo sobre as tabelas envolvidas. Entretanto, uma
an1lise superficial dessa frase pode levar o leitor a concluir )ue a desnormali(ao sempre aumenta o desempen'o no
processamento de consultas de seleo. O racioc;nio :errTneo= para essa concluso seria o seguinte" Hse a )uantidade de
tabelas maior em um es)uema relacional normali(ado, ento 'aver1 um maior nLmero de opera!es de juno para a
obteno do resultado das consultas nesse es)uema do )ue em um es)uema desnormali(ado correspondente :opera!es de
juno so sabidamente bastante custosas do ponto de vista computacional=. $onse)Eentemente, o custo da execuo de
sele!es em um es)uema normali(ado sempre maior do )ue o custo sobre o es)uema desnormali(ado correspondenteI.
46. $onsiderando as jun!es, pode7se constatar )ue a sobrecarga de processamento necess1ria para manter a integridade
dos dados pode no compensar o gan'o de desempen'o obtido com a desnormali(ao. 5e fato, a manuteno da
integridade pode necessitar das mesmas opera!es de juno )ue a desnormali(ao se propun'a a eliminarU &ara
exemplificar, considere uma verso desnormali(ada da tabela &edido contendo as colunas das tabelas Ftem&edido e &roduto
:ver igura 24=. &ara obter informa!es sobre pedidos, itens de pedidos e produtos, a utili(ao dessa tabela desnormali(ada
realmente produ( uma execuo mais eficiente. %final de contas, todos os dados necess1rios esto arma(enados em uma
Lnica tabela, o )ue normalmente leva o S*J5 a posicionar essas informa!es em blocos de disco cont;guos. #o entanto, o
)ue acontece )uando um nome de produto atuali(adoP 3ma das opera!es )ue devem ser reali(adas para garantir )ue os
dados permaneam consistentes atuali(ar todos os registros em )ue o produto em )uesto est1 contemplado. 5eixa7se
como exerc;cio para o leitor verificar )ue '1 tambm problemas )uando da excluso e incluso de registros nessa tabela.
Dodos esses problemas provenientes da sua desnormali(aoU

igura 24. Dabela desnormali(ada.

4?. 3m eventual benef;cio obtido pela desnormali(ao :aumento do desempen'o em uma determinada consulta de seleo=
tem seu preo" uma tabela desnormali(ada fica vulner1vel ao surgimento de anomalias )uando manipula!es :atuali(a!es,
inclus!es ou inser!es= so reali(adas sobre ela, e a integridade dos dados fica ameaada.
4A. % sobrecarga necess1ria para manuteno da integridade dos dados no o Lnico fator a considerar )uando o
desenvolvedor estiver pensando em desnormali(ar um es)uema. O1 um outro aspecto menos +bvio. $onsidere novamente os
dados da tabela &edido :ver igura 24=. Essa tabela arma(ena dados sobre tr/s conceitos distintos" pedidos, itens de pedidos
e produtos. O )ue acontece )uando aplica!es de bancos de dados precisam obter acesso a esses dados separadamenteP
&or exemplo, digamos )ue o departamento de log;stica precisa fa(er um levantamento sobre os produtos em esto)ue.
&rovavelmente, essa tarefa envolveria uma consulta sobre a tabela &roduto para resgatar somente os dados relativos 0
)uantidade em esto)ue por produto. $omo esses dados esto em uma tabela )ue possui diversas outras colunas no
relacionadas a produtos, a )uantidade de informa!es sobre produtos por bloco de disco ser1 menor do )ue se 'ouvesse uma
tabela arma(enando somente dados sobre produtos. $onse)Eentemente, o S*J5 levar1 mais tempo para resgatar os dados
necess1rios para montar o relat+rio de esto)ue ao utili(ar a tabela desnormali(ada. &erceba )ue esse ponto acaba indo de
encontro ao citado anteriormente neste artigo, ou seja, um dos benef;cios da desnormali(ao :o no uso de jun!es= acaba
sendo prejudicado em outras situa!es.
4B. 5e uma forma geral, se for tomada a deciso de aglutinar dados de duas ou mais tabelas em uma Lnica tabela :ou seja,
desnormali(ar=, as aplica!es )ue necessitam ter acesso aos dados, )ue do contr1rio estariam em uma tabela separada, tero
agora )ue ler desnecessariamente outras informa!es. E a leitura dessas outras informa!es desnecess1rias aumenta o
tempo de processamento das consultas de seleo.
12
69. Kamos agora a um exemplo em )ue o uso da desnormali(ao pode ser benfico. Fmagine uma situao em )ue
ten'amos as tabelas &roduto e *rupo&roduto :ver igura 26=. % tabela *rupo&roduto possui uma classificao fixa para
categori(ar os diferentes produtos :ou seja, o nome dos grupos no muda=. #este caso, poder;amos colocar o campo
nomeCgrupo na tabela &roduto para facilitar, por exemplo, a gerao de relat+rios.

igura 26. Exemplo de desnormali(ao.

61. Fmagine uma situao em )ue voc/ precise constantemente retornar um valor de um campo calculado. &ode ser
interessante criar um campo valorCpedido do pedido na tabela &edido para )ue, toda ve( )ue precisar calcular o valor do
pedido no seja necess1rio percorrer seus itens e depois, os produtos, para c'egar neste valor :ver igura 2?=. Entretanto,
temos tambm uma desvantagem" a cada mudana no pedido, este campo precisa ser recalculado e arma(enado.
Deoricamente, campos deste tipo :calculados=, no precisariam ser arma(enados.

igura 2?. Exemplo de desnormali(ao.

62. Outra situao interessante de uso da desnormali(ao a criao de 'ist+rico. #o exemplo da igura 2A pode7se
perceber )ue se repete o valor do produto na tabela itemCpedido. Fsso pode ser interessante, pois, caso o valor do produto
mude :na tabela &roduto=, mant/m7se o 'ist+rico do valor praticado na)uele itemCpedido. Kale ressaltar )ue isso contraria a
Derceira orma #ormal, pois o valor do produto depende do c+digo mas, em funo do 'ist+rico, justific1vel.

igura 2A. Exemplo de desnormali(ao.

6,. 3ma outra situao de uso para desnormali(ao a eliminao de uma tabela )uando pudermos pr7determinar os tipos
de valores )ue ela contm, juntando na tabela original. #o exemplo da igura 2B, como os tipos de telefones so con'ecidos,
13
justifica7se eliminar a tabela Delefone e agrupar estes dados em uncion1rio :neste caso estamos considerando apenas um
telefone por tipo=.

igura 2B. Exemplo de desnormali(ao.
Godelagem de dados" projeto f;sico
62. O projeto f;sico se preocupa com )uest!es de desempen'o, criao de ;ndices, particionamento, paralelismo e tuning,
dentre outros. %ssim, diversas caracter;sticas do projeto f;sico esto associadas a um S*J5 espec;fico.
64. % criao de ;ndices para c'aves estrangeiras tendem a mel'orar o desempen'o de consultas complexas ou )ue
envolvam muitas tabelas ou ainda tabelas com muitos registros.
66. Kerificar a necessidade de c'aves artificiais :Surrogate MeN=" em alguns casos depara7se com certas tabelas )ue no
possuem uma c'ave prim1ria natural, o )ue far1 com )ue 'aja a necessidade de se criar uma nova coluna para ser a c'ave
prim1ria. #este caso, temos a criao de um novo campo Lnico )ue represente sua c'ave, como um se)Eencial, por exemplo.
6?. Kalidao 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.
6A. %tente para as configura!es necess1rias a serem reali(adas nas ferramentas $%SE antes da gerao do script. Guitas
delas tra(em op!es espec;ficas para cada S*J5.
6B. #o utili(e muitos atributos nas c'aves nas tabelas" apesar de muitas ve(es isso acontecer no modelo l+gico, )uando se
implementa no banco de dados um modelo com muitos atributos na c'ave complica7se desnecessariamente a programao. %
sugesto a criao de c'aves alternativas )ue facilitam o acesso aos dados.
ragmentao de rela!es
?9. &ara desenvolver um projeto de banco de dados ade)uado, o projetista, dentre as muitas decis!es )ue deve tomar para o
sucesso ou fracasso do projeto, deve decidir tambm se os dados sero distribu;dos pelo local de uso ou sero centrali(ados e
acessados via rede pelos usu1rios. Essa deciso envolve custos de infra7estrutura, perda ou mel'oria de desempen'o no
acesso aos dados, interferindo tambm na disponibilidade imediata ou posterior desses dados.

%lgumas ra(!es para no reali(ar a fragmentao
?1. Vuando no 'ouver necessidade de deixar os dados pr+ximos aos usu1rios" neste caso, no deve 'aver a necessidade de
grandes opera!es de manipulao de dados por parte dos usu1rios>
?2. Vuando a fragmentao gerar muita duplicidade tra(endo problemas de consist/ncias" muitas ve(es ao reali(armos a
fragmentao, precisamos reali(ar a duplicao de alguns registros. Vuando a pol;tica de replicao eQou sincroni(ao for um
problema, evite fragmentar sua base de dados>
?,. Vuando 'ouver restri!es tecnol+gicas )ue impeam a fragmentao>
?2. Vuando 'ouver dificuldade em manter a distribuio otimi(ada dentro de um cen1rio de mudana de aplica!es" este
t+pico tambm di( respeito aos processos de replicao e sincroni(ao. %mbos no so, na maioria das ve(es, triviais de
serem reali(ados, portanto, ten'a isso em mente.

14
%lgumas ra(!es para fragmentar
?4. Vuando os dados precisam estar pr+ximos dos seus usu1rios" isso ocorre )uando '1 necessidade de grandes opera!es
de manipulao de dados por parte dos usu1rios. Se os dados no estiverem locali(ados no ambiente operacional, estas
opera!es se tornaro bastante custosas e, a depender do caso, bastante lentas>
?6. Vuando a decomposio de uma relao em fragmentos permitir um maior nLmero de transa!es em execuo
concorrente.
??. 5essa forma, devemos considerar a reali(ao da fragmentao )uando a distribuio dos dados tra( vantagens
considerando, principalmente a locali(ao dos dados e o desempen'o das opera!es de manipulao de dados. %lm destes
t+picos, pode7se ainda ter a necessidade de reali(ar a fragmentao por )uest!es estratgicas da organi(ao. &or exemplo,
parte dos dados de uma base podem ser fundamentais para o sucesso do neg+cio, ao invs de mant/7los juntos aos outros
dados, podemos fragmentar a base de forma )ue estes dados mais sens;veis sejam colocados em outro servidor com pol;ticas
mais severas de segurana.

Dcnicas b1sicas de fragmentao

ragmentao vertical
?A. % fragmentao vertical ocorre )uando colunas da mesma tabela so separadas em locais diferentes. $onforme pode ser
visto no exemplo da Dabela 1, todas as colunas esto centrali(adas em uma Lnica tabela e nas Dabelas 2 e , as colunas esto
fragmentadas de forma vertical. Essa fragmentao ser1 vantajosa )uando os aplicativos dos diversos usu1rios puderem atuar
de forma separada em cada fragmento minimi(ando desta forma o tempo de processamento.

Dabela 1. .elao $liente sem fragmentao.
Dabela 2. ragmento vertical da .elao $liente sem o atributo @imite.
15
Dabela ,. ragmento vertical da .elao $liente contendo apenas a c'ave e o limite.

?B. R importante ressaltar )ue se uma relao for decomposta verticalmente em outras, ento )ual)uer registro existente na
primeira relao tambm deve ser encontrado nas demais, para )ue 'aja a correta reconstruo do registro.

ragmentao 'ori(ontal
A9. % fragmentao 'ori(ontal ocorre )uando registros de uma mesma tabela so separados em fragmentos diferentes.
$onforme pode ser visto no exemplo mais adiante, cada filial arma(enar1 os dados sobre os seus clientes.
A1. % )uesto )ue se deve ter em mente ao optar por uma fragmentao 'ori(ontal " as consultas t/m vis!es locais dos
dadosP Em caso afirmativo, com certe(a 'aver1 mel'ora de desempen'o ao se evitar ler dados de clientes de outras filiais e
evitar acesso remoto desnecess1rio. %lm disso, 'aver1 aumento no nLmero de transa!es concorrentes. % tabela base para
nosso exemplo novamente a Dabela 1 sem fragmentao. #as Dabelas 2, 4 e 6 temos os fragmentos 'ori(ontais da tabela
$liente onde os clientes so separados por filial.

Dabela 2. ragmento 'ori(ontal da tabela $liente contendo somente dados da ilial Jelo Oori(onte.

Dabela 4. ragmento da tabela $liente contendo somente da ilial $uritiba.

Dabela 6. ragmento da tabela $liente contendo somente da ilial So &aulo.

&ara )ue a fragmentao ocorra de forma ade)uada, alguns critrios importantes devem ser considerados"
16
A2. #o caso de fragmentao 'ori(ontal, se um registro da tabela est1 em um fragmento, no poder1 estar tambm em outro
fragmento.
A,. Se 'ouver uma tabela )ue dependa diretamente de outra, os registros relacionados devem ficar no mesmo local.
A2. &ara efetuar uma fragmentao 'ori(ontal, devemos considerar" a cardinalidade das tabelas> os critrios de sele!es por
aplicao> a )uantidade de registros recuperados por aplicao e por local> a fre)E/ncia de busca dos registros por aplicao e
por local.
A4. 5eve7se considerar para cada fragmento a cardinalidade dos fragmentos e o taman'o de cada registro por fragmento>
A6. 5eve7se considerar para cada aplicao os fragmentos acessados, os critrios de seleo de registros e )uantidade de
registros selecionados por acesso de leitura, atuali(a!es em registros, fre)E/ncia de execuo por local de ativao e tempo
m1ximo de resposta esperado>
A?. 5eve7se considerar para cada estao servidora, a capacidade de processamento e grau de utili(ao e tambm a
capacidade de arma(enamento e grau de utili(ao>
AA. 5eve7se considerar para a rede de comunicao, a capacidade da banda e grau de utili(ao da rede.
AB. .a(!es de restri!es tecnol+gicas tambm exigiro )ue sejam feitas escol'as de atuali(a!es )ue mel'or se adaptem 0
infra7estrutura de cada organi(ao. Essa escol'a pode envolver atuali(a!es ass;ncronas )ue so a)uelas atuali(a!es )ue
ocorrem em 'or1rios espec;ficos para no prejudicar a performance do banco de dados, ou s;ncronas onde as atuali(a!es
ocorrem em v1rios locais simultaneamente. Essa escol'a, como j1 foi dito, trar1 conse)E/ncias sobre a performance do banco
de dados e por isso dever1 ser extremamente criteriosa. % seguir so apresentadas algumas tcnicas de atuali(ao de
bancos de dados distribu;dos"
8 Extratos" so c+pias )ue nunca sero atuali(adas. Wteis em situa!es )ue exigem apenas consultas. O extrato feito
com ajuda de comandos SV@. So utili(adas, por exemplo, em sistemas de apoio 0 deciso. Esses extratos podem ter ou no
o registro do momento de sua criao, dependendo da necessidade desse tipo de informao.
8 Extrato com substituio peri+dica" neste caso a c+pia substitu;da em intervalos de tempos pr7definidos. So
utili(adas, por exemplo, em sistemas de suporte a deciso e sistemas distribu;dos )ue utili(am dados atuali(ados com
periodicidade bem definida.
8 .plicas com aplicao ass;ncrona de atuali(a!es" as atuali(a!es so feitas nas c+pias e no banco de dados original.
&eriodicamente, os bancos de dados so re7sincroni(ados. &odem ser usadas em sistemas onde as altera!es dos bancos de
dados sejam feitos por inclus!es em )ual)uer um dos locais.
8 .plicas com aplicao s;ncrona de atuali(a!es" as atuali(a!es so feitas nas c+pias e no J5 original no momento de
sua ocorr/ncia. &odem ser utili(adas em sistemas onde as altera!es dos bancos de dados sejam pouco fre)Eentes e possam
ser feitas em )ual)uer um dos locais.
erramentas de modelagem
B9. 3tili(e uma ferramenta $%SE para modelagem de dados. $aso contr1rio, o modelo tender1 a ficar desatuali(ado
rapidamente, pois dificilmente as modifica!es )ue so necess1rias no es)uema de dados so refletidas para a documentao
sem o aux;lio de uma ferramenta apropriada.
B1. %t pouco tempo atr1s, a reali(ao das atividades de modelagem era dificultada para a)ueles )ue no possu;am
recursos financeiros para comprar ferramentas de modelagem comerciais. icava assim dif;cil reali(ar atividades de
modelagem. $om o advento da Fnternet e do softXare de c+digo aberto essa realidade foi se transformando e 'oje j1 poss;vel
encontrar algumas destas ferramentas gratuitas para modelagem de dados. 3m bom exemplo disso a ferramenta
5J5esigner 2 :ver igura ,9=. Eis algumas das caracter;sticas )ue a tornam uma boa opo"
8 %presenta uma interface de f1cil utili(ao>
8 %tende aos S*J5s" GNSV@, Oracle, SV@ Server, SV@ite, e todos outros )ue suportem acesso via O5J$>
8 &ossui engen'aria reversa>
17
8 Salva os ar)uivos em formato YG@>
8 Fmporta modelos gerados por algumas outras ferramentas>
8 *era relat+rios em ODG@>
8 Suporte atravs do f+rum dispon;vel no site do 5J5esigner>
8 .eali(a sincronia no banco de dados a partir das altera!es no modelo>
8 R multi7plataforma.

&ara reali(ar o doXnload, basta entrar no site .
igura ,9. 5J5esigner 2.
onclus!o
#este artigo procuramos fa(er uma colet-nea de dicas de modelagem conceitual, contando com a colaborao de profissionais
da 1rea. %s dicas envolvem )uest!es de modelagem de dados, tanto em n;vel de modelo conceitual, l+gico e f;sico, )uanto
tcnicas de normali(ao e desnormali(ao. Dambm foram apresentadas dicas relativas 0 fragmentao de dados e
ferramentas $%SE gratuitas de modelagem de dados. Esperamos )ue estas dicas sejam Lteis a todos a)ueles envolvidos com
modelagem de bancos de dados.
18