c

Ê
 

O conceito de Normalização e formas normais é sem dúvidas um dos

conceitos mais importantes do Modelo Relacional. O conceito de normalização foi
introduzido por E.F.Codd em 1970 (primeira forma normal). Esta técnica é um
processo matemático que tem seus fundamentos na teoria dos conju ntos. Através
deste processo pode-se, gradativamente, substituir um conjunto de entidades e
relacionamentos por um outro, o qual se apresenta 
 em relação às
anomalias de atualização (inclusão, alteração e exclusão) as quais podem causar
certos problemas, tais como: grupos repetitivos (atributos multivalorados) de dados,
dependências parciais em relação a uma chave concatenada, redundância
desnecessária de dados, dificuldade na representação de fatos da realidade
observada e dependências transitivas entre atributos.

‘
 r

‰

‘

O objetivo da normalização é evitar os problemas provocados por falhas no

Projeto da Base de Dados, bem como eliminar a ü


 ‘ e as
correspondentes repetições desnecessárias de dados. Uma Regra de Ouro que
devemos observar quando do Projeto de uma Base de Dados baseada no Modelo
Relacional de dados é a de X





 
 
X . Por
exemplo, na Tabela Clientes devemos colocar somente campos relacionados com o
assunto Clientes. Não devemos misturar campos relacionados com outros assuntos,
tais como Pedidos, Produtos, etc. Essa "Mistura de Assuntos" em uma mesma
tabela acaba por gerar repetição desnecessária dos dados bem como inconsistência
dos dados. O Processo de Normalização aplica uma série de Regras sobre as
Tabelas de uma Base de Dados, para verificar se estas estão corretamente
projetadas. Embora existam cinco formas normais (ou regras de Normalização), na
prática usamos um conjunto de três Formas Normais. Normalmente após a
aplicação das Regras de Normalização, algumas tabelas acabam sendo divididas
em duas ou mais tabelas, o que no final gera um número maior de tabelas do que o
originalmente existente. Este processo causa a simplificação dos atributos de uma
tabela, colaborando significativamente para a estabilidade do modelo de dados,
reduzindo-se consideravelmente as necessidades de manutenção. Vamos entender
o Processo de Normalização na Prática, através de exemplos.

a

 ‘ ‘
 ‘

Num.
 

 
          
Ped.
c 
     c !  c"!! !!"!! #$$"!!
c 
     !    !"!! !"!! #$$"!!
c 
     c %& ! '( "!! !"!! #$$"!!
c 
     #) %& c!
* !"!! c!!"!! #$$"!!
c 
     $! !
 "!! !"!! #$$"!!
c 
     c %& 
(+*, "!! $"!! #$$"!!
r! -  #  c c c! . c"!! !!"!!
r! -  #  c #) %& #
* !"!! #c"!! rc!"!!
r! -  #  c  %& ! & c"!! c"!! rc!"!!
r! -  #  c $) c  /+ c"!! !"!! rc!"!!
r! -  #  c $! c
 "!! !"!! rc!"!!
r! -  #  c   ! * "!! !"!! rc!"!!
r! -  #  c c ' ! &0 "!! !"!! rc!"!!
r! -  #  c rc c + )"!! !"!! rc!"!!
r! -  #  c c  ! ' "!! r!"!! rc!"!!
r! -  #  c #  ! ( ! "!! !"!! rc!"!!

'&+  1 2*-  '*+3  

 #

Formulário de Pedido (Atributos)

‡ Número do pedido ‡ Quantidade do produto

‡ Descrição do produto ‡ Prazo de entrega
‡ Valor unitário do produto ‡ Valor total do produto
‡ Valor total do pedido ‡ Código do vendedor
‡ Nome do vendedor ‡ Cliente
‡ Endereço ‡ Cidade
‡ UF ‡ CNPJ
‡ Inscrição Estadual ‡ Código do produto
‡ Unidade do produto
Caso esta entidade fosse implementada como uma tabela em um banco de dados,
as seguintes anomalias iriam aparecer:
± Anomalia de inclusão: ao ser incluído um novo cliente, o mesmo tem que estar
relacionado a uma venda;
± Anomalia de exclusão: ao ser excluído um cliente, os dados referentes as suas
compras serão perdidos;
± Anomalia de alteração: caso algum fabricante de produto altere a faixa de preço de
uma determinada classe de produtos, será preciso percorrer toda a entidade para se
realizar múltiplas alterações.

 


 
 Ê

‡ Em uma determinada realidade, às vezes encontramos algumas informações que

se repetem (atributos multivalorados), retratando ocorrências de um mesmo fato
dentro de uma única linha e vinculadas a sua chave primária;
‡ Ao observarmos a entidade PEDIDO, apresentada anteriormente, visualizamos que
um certo grupo de atributos (produtos solicitados) se repete (número de ocorrências
não definidas) ao longo do processo de entrada de dados na entidade;
‡ A 1FN diz que: cada ocorrência da chave primária deve corresponder a uma e
somente uma informação de cada atributo, ou seja, a entidade não deve conter
grupos repetitivos (multivalorados);
‡ Para se obter entidades na 1FN, é necessário decompor cada entida de não
normalizada em tantas entidades quanto for o número de conjuntos de atributos
repetitivos. Nas novas entidades criadas, a chave primária é a concatenação da
 )

chave primária original mais o(s) atributo(s) do grupo repetitivo visualizado(s) como
chave primária deste grupo. Uma tabela está na Primeira Forma Normal quando
seus atributos não contém grupos de repetição. Por isso dissemos que uma tabela
que possui grupos de repetição não está na 1FN. Considere a estrutura da tabela
Indicada na próxima figura:

Figura 2 - Tabela que não está na 1FN.

Uma tabela com esta estrutura apresentaria diversos problemas. Por
exemplo, se um casal tiver mais de um filho, teremos que digitar o Nome do Pai e da
Mãe diversas vezes, tantas quantos forem os filhos. Isso forma um Grupo de
Repetição. Além do mais pode ser que por erro de digitação o Nome dos Pais não
seja digitado exatamente igual todas as vezes, o que pode acarretar problemas na
hora de fazer pesquisas ou emitir relatórios. Este problema ocorre porque
X
 
X
em uma mesma tabela. Colocamos as informações dos
pais e dos filhos em uma mesma tabela. A solução para este problema é simples:
Criamos uma tabela separada para a Informação dos Pais e Relacionamos a tabela
Pais com a tabela filhos através de um relacionamento do tipo um para vários, ou
seja, um casal da pais pode ter vários filhos. Observe na figura abaixo as duas
tabelas: pais e filhos, já normalizadas:

Figura 3 ± Tabela Normalizada.

 $

Voltando a nossa tabela Formulário de Pedido temos o seguinte:

Ao aplicarmos a 1FN sobre a entidade PEDIDO, obtemos mais uma entidade

chamada ITEM-DE-PEDIDO, que herdará os atributos repetitivos e destacados da
entidade PEDIDO; Um PEDIDO possui no mínimo 1 e no máximo N elementos em
ITEM-DEPEDIDO e um ITEM-DE-PEDIDO pertence a 1 e somente 1 PEDIDO.



‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘‘ ‘|


| 

‡ Número do pedido ‡ Número do pedido

‡ Prazo de entrega ‡ Código do produto
‡ Cliente ‡ Quantidade do produto
‡ Endereço ‡ Descrição do produto
‡ Cidade ‡ Valor unitário do produto
‡ UF ‡ Valor total do produto
‡ CGC
‡ Inscrição Estadual
‡ Valor total do pedido
‡ Valor total do pedido
‡ Código do vendedor
‡ Nome do vendedor

´ 




Para descrevermos as próximas formas normais, se faz necessária a

introdução do conceito de dependência funcional, sobre o qual a maior parte da
teoria de normalização foi baseada.
‡ Dada uma entidade qualquer, dizemos que um atributo ou conjunto de atributos A é
dependente funcional de um outro atributo B contido na mesma entidade, se a cada
valor B existir nas linhas da entidade em que aparece, um único valor de A. Em
outras palavras, A depende funcionalmente de B;
‡ Na entidade PEDIDO, o atributo PRAZO-DE-ENTREGA depende funcionalmente
de NUMERO-DO-PEDIDO;
‡ O exame das relações existentes entre os atributos de uma entidade deve ser feito
a partir do conhecimento (conceitual) que tem sobre a realidade a ser modelada.
´ Ê









Na ocorrência de uma chave primária concatenada, dizemos que um atributo

ou conjunto de atributos depende de forma completa ou total desta chave primária
concatenada, se e somente se, a cada valor da chave (e não parte dela), está
associado um valor para cada atributo, ou seja, um atributo não se apresenta com
 !

dependência completa ou total quando só depende de parte da chave primária

concatenada e não dela como um todo;
‡ Dependência total ± na entidade ITEM-DOPEDIDO, o atributo QUANTIDADE-
DOPRODUTO depende de forma total ou completa da chave primária concatenada
(NÚMERO-DO-PEDIDO + CÓDIGO-DOPRODUTO);
‡ A dependência total ou completa só ocorre quando a chave primária for composta
por vários atributos, ou seja, em uma entidade de chave primária composta de um
único atributo não ocorre este tipo de dependência.
´ 








Quando um atributo ou conjunto de atributos A depende de outro atributo B

que não pertence à chave primária, mas é dependente funcional desta, dizemos que
A é dependente transitivo de B.
‡ Dependência transitiva ± na entidade PEDIDO, os atributos ENDEREÇO, CIDADE,
UF, CNPJ e INSCRIÇÃO ESTADUAL são dependentes transitivos do atributo
CLIENTE. Nesta mesma entidade, o atributo NOME -DO VENDEDOR é dependente
transitivo do atributo CÓDIGO-DO VENDEDOR;
‡ Com base na teoria sobre as dependências funcionais entre atributos de uma
entidade, podemos continuar com a apresentação das outras formas normais.


 
 


Devemos observar se alguma entidade possui chave primária concatenada, e

para aquelas que satisfizerem esta condição, analisar se existe algum atributo ou
conjunto de atributos com dependência parcial em relação a algum elemento da
chave primária concatenada;
Com a finalidade de tornar a inda mais estável o modelo de dados, a aplicação
da 2FN sobre as entidades em observação geram novas entidades, que herdarão a
chave parcial e todos os atributos que dependem desta chave parcial, ou seja, uma
entidade para estar na 2FN não pode ter atributos com dependência parcial em
relação à chave primária.
A entidade ITEM-DO-PEDIDO apresenta uma chave primária concatenada e
por observação, notamos que os atributos UNIDADE-DO-PRODUTO, DESCRIÇÃO-
DO-PRODUTO e VALOR-UNITÁRIO dependem de forma parcial do atributo
CÓDIGO-DO-PRODUTO, que faz parte da chave primária. Logo devemos aplicar a
2FN sobre esta entidade. Quando aplicarmos a 2FN sobre ITEM-DO-PRODUTO,
será criada a entidade PRODUTO que herdará os atributos UNIDADE -
 

DOPRODUTO, DESCRIÇÃO-DO-PRODUTO e VALORUNITÁRIO e terá como

‘
chave primária o CÓDIGO-DOPRODUTO. Um PRODUTO participa de no mínimo 0
e no máximo N elementos de ITEM-DEPEDIDO e um ITEM-DE-PEDIDO só pode
conter 1 somente 1 PRODUTO.
r 

 
 


Uma entidade está na 3FN se nenhum de seus atributos possui dependência

transitiva em relação a outro atributo da entidade que não participe da chave
primária, ou seja, não exista nenhum atributo intermediário entre a chave primária e
o próprio atributo observado;
‡ Ao retirarmos a dependência transitiva, devemos criar uma nova entidade que
contenha os atributos que dependem transitivamente de outro e a sua chave
primária é o atributo que causou esta dependência;
‡ Além de não conter atributos com dependência transitiva, entidades na 3FN não
devem conter atributos que sejam o resultado de algum cálculo sobre outro atributo,
que de certa forma pode ser encarada como uma dependência funcional.
Na entidade PEDIDO, podemos observar que o atributo NOME -DOVENDEDOR
depende transitivamente do atributo CÓDIGO -DOVENDEDOR que não pertence à
chave primária. Para eliminarmos esta anomalia devemos criar a entidade
VENDEDOR, com o atributo NOMEDO-VENDEDOR e tendo como chave primária o
atributo CÓDIGO-DOVENDEDOR. Encontramos ainda o conjunto de atributos
formados por ENDEREÇO,CIDADE, UF, CNPJ e INSCRIÇÃO ESTADUAL que
dependem transitivamente do atributo CLIENTE. Neste caso, devemos criar a
entidade CLIENTE que conterá os atributos ENDEREÇO, CIDADE, UF, CNPJ e
INSCRIÇÃO ESTADUAL. Para chave primária desta entidade vamos criar um
atributo chamado CÓDIGO-DO-CLIENTE que funcionará melhor como chave
primária do que NOME-DO-CLIENTE, deixando este último como simples atributo da
‘
entidade CLIENTE. Um PEDIDO só é feito por um e somente um CLIENTE e um
CLIENTE pode fazer de 0 até N elementos de PEDIDO. Um PEDIDO só é tirado por
um e somente um VENDEDOR e VENDEDOR pode tirar de 0 a N elementos de
PEDIDO.
¦
 
 

 

As definições da 2FN e 3FN, desenvolvidas por Codd, não cobriam certos

casos. Esta inadequação foi apontada por Boyce em 1974. Os casos não cobertos
pelas definições de Codd somente ocorrem quando três condições aparecem juntas:
 

± A entidade tenha várias chaves candidatas;

± Estas chaves candidatas sejam concatenadas (mais de um atributo);
± As chaves concatenadas compartilham pelo menos um atributo comum;
Na verdade, a FNBC é uma extensão da 3FN, que não resolvia certas anomalias
presentes na informação contida em uma entidade. O problema foi observado
porque a 2FN e a 3FN só tratavam dos casos de dependência parcial e transitiva de
atributos fora de qualquer chave, porém quando o atributo observado estiver contido
em uma chave, ele não é captado pela verificação da 2FN e 3FN.
Considere a seguinte entidade FILHO:

 


!

"


!

Data de Nascimento
Nome da Escola
Número da Sala
Nome do Professor

Por hipótese, vamos assumir que um professor possa estar associado a mais de
uma escola e uma sala. Sob esta suposição, tanto a chave (candidata) concatenada
NOME-DA-ESCOLA + SALA-DA-ESCOLA bem como NOME-DA-ESCOLA + NOME-
DO-PROFESSOR podem ser determinantes. Logo esta entidade atende às três
condições relacionadas anteriormente.
± As chaves candidatas para a entidade FILHO são: NOME -DO-FILHO
ENDEREÇO-DO-FILHO, NOME-DO-FILHO + NÚMERO-DA-SALA e
NOME-DO-FILHO + NOME-DO-PROFESSOR;
± Todas as três chaves apresentam mais de um atributo (concatenados);
± Todas as três chaves compartilham um mesmo atributo: NOME-DOFILHO.
A definição da FNBC é a seguinte: uma entidade está na FNBC se e somente se
todos os determinantes forem chaves candidatas. Notem que esta definição é em
termos de chaves candidatas e não sobre chaves primárias. Neste exemplo, NOME-
DOPROFESSOR não é completamente dependente funcional do NÚMERO-DA-
SALA, nem NÚMERO-DASALA é completamente dependente funcional do NOME -
DO-PROFESSOR. Neste caso, NOME-DOPROFESSOR é realmente
completamente dependente funcional da chave candidata concatenada NOME -
 

FILHO + NÚMERO-DASALA ou NÚMERO-DASALA é completamente dependente

funcional da chave candidata concatenada NOME-DOFILHO + NOME-
DOPROFESSOR. Ao se aplicar a FNBC, a entidade FILHO deve ser dividida em
duas entidades, uma que contém os atributos que designam um professor em uma
particular escola e número de sala.

 


!

"


!

 


Data de Nascimento
% 


Nome da Escola
Nome do Professor Número da Sala

ù
#
 
 
´

Na maioria dos casos, as entidades normalizadas até a 3FN são fáceis de

entender, atualizar e de se recuperar dados. Mas às vezes podem surgir problemas
com relação a algum atributo não chave, que recebe valores múltiplos para um
mesmo valor de chave. Esta nova dependência recebe o nome de dependência
multivalorada que existe somente se a entidade contiver no mínimo três atributos;
‡ Uma entidade que esteja na 3FN também está na 4FN, se ela não contiver mais do
que um fato multivalorado a respeito da entidade descrita. Esta dependência não é o
mesmo que uma associação M:N entre atributos, geralmente descrita desta forma
em algumas literaturas.
‡ Dada a entidade hipotética a seguir:

$



$


"
$


 

11111111111 BA3 113

11111111111 CJ10 113
11111111111 88A 435
11111111111 BA3 537

Como podemos observar, esta entidade tenta conter dois fatos multivalorados: as
diversas peças compradas e os diversos compradores. Com isto apresenta uma
dependência multivalorada entre CÓDIGO -FORNECEDOR e o CÓDIGO-PEÇA e
 

entre CÓDIGO-FORNECEDOR e o CÓDIGOCOMPRADOR. Embora esteja na 3FN,

ao conter mais de um fato multivalorado, torna a sua atualização muito difícil, bem
como a possibilidade de ocorrer problemas relativos ao espaço físico de
armazenamento, causados pela ocupação desnecessária de área de memória . Para
passarmos a entidade acima para a 4FN, é necessária a realização de uma divisão
da entidade original, em duas outras, ambas herdando a chave CÓDIGO-
FORNECEDOR e concatenado, em cada nova entidade, com os atributos CÓDIGO-
PEÇA e CÓDIGO-COMPRADOR.

$




$




$


"

$


 

&
#

 
 

Uma tabela está na 5FN se estiver na 4FN e um relacionamento triplo não

puder ser decomposto em relacionamentos binários sem geração de informação
incorreta.
Caso especial: Relacionamento envolvendo Chaves primárias de 3 tabelas, que nem
sempre é possível decomposição correta. Exemplo: relacionamento Agente -
Companhia-Produto.


 !



João Ford Carro

João GM Caminhão

Formato necessário quando existem apenas algumas combinações entre os 3

atributos (tabela c/ tripla).
Situação: Se um agente vende um certo produto e ele representa uma companhia,
então ele vende um produto fabricado por esta companhia . Todos os pares se
combinam!


 !



João Ford Carro

João Ford Caminhão
João GM Carro
João GM Caminhão
Carlos Ford Carro
 c

Neste caso, é possível decompor uma tripla em três relações binárias com
eliminação de certas redundâncias. As três relações abaixo estão na 5FN:





 !

João Carro  !



João Ford João Caminhão Ford Carro

João GM Carlos Carro Ford Caminhão
Carlos Ford GM Carro

GM Caminhão

Eliminação de certas redundâncias:

- Apenas uma vez está dito que Ford produz carros;
- Apenas uma vez está dito que João é agente da GM.
Apesar do aumento no número de tabelas, o número total de tuplas na forma
normalizada é menor.

 r

 

Projetar um banco de dados sem lançar mão das ferramentas disponíveis,

tais como as ´formas normais´ pode acarretar sérios problemas posteriormente. O
estudo das formas normais é sem dúvida um dos mais importantes em Banco de
Dados.‘A normalização de dados é provavelmente um dos aspectos mais abordados
em modelagem de banco de dados. Antes de construirmos um modelo de dados a
ser utilizado em uma aplicação, devemos tratar alguns pontos sobre sua
normalização. Esses pontos estão relacionados a se usamos ou não as formas
normais, qual dessas formas usar em uma aplicação e quando devemos
desnormalizar o modelo. Tudo depende do projetista do banco de dados. Aqui,
tratamos brevemente do conceito de formas normais, já que seu estudo é vasto
mas, suas vantagens são excepcionalmente notórias.
 #





'


DATE,C.J.
"




 





ÊÊ

Ê 7ª Edição.

Editora Campus, 2000.

KROENKE,David M.



 



 "
 

6ª Edição. Editora LTC, 1999.

http://www.poli.usp.br/d/pmr2490/Curso%20SQL -1-PMR.pdf
(








http://www.aprendercomastics.net/tic/materiaisapoio/Normalizacao.pdf (

 
"