Elisa Maria Pivetta UFSM/CAFW

BANCO DE DADOS
Modelagem de Dados Normalizao
Objetivo:
Eliminar redundncias e inconsistncias de um banco de dados, com
reorganizao mnima dos dados.
Sub-Fases:
Identificao das redundncias e outros problemas
Reorganizao do banco de dados
Normalizao um processo baseado nas chamadas formas normais.
Uma forma normal uma regra de deve ser aplicada na construo das tabelas do banco
de dados para que estas fiquem bem projetadas. Segundo autores, existem 5 formas
normais. Vamos trabalhar com as 3 primeiras, sendo as principais.
Devemos aplicar as 3 formas normais em cada tabela, ou grupo de tabelas
relacionadas. As formas tm uma ordem e so dependentes, isto , para se aplicar a
segunda norma, deve-se obrigatoriamente ter aplicado a primeira e assim por diante.
1 - Forma Normal: Verificao de Tabelas Aninhadas 1FN
Uma relao estar na Primeira forma normal 1FN, se e somente se todos os
domnios bsicos contiverem somente valores atmicos (no contiver grupos
repetitivos). Em outras palavras podemos definir que a primeira forma normal no
admite repeties ou campos que tenha mais que um valor.
Para uma tabela estar na primeira forma normal ela no deve conter tabelas
aninhadas. Um jeito fcil de verificar esta norma fazer uma leitura dos campos das
tabelas fazendo a pergunta: Este campo depende de qual?
Procedimentos:
Identificar a chave primria da entidade;
Identificar o grupo repetitivo e remov-lo da entidade;
Criar uma nova entidade com o grupo repetitivo.
Vamos exemplificar, com a tabela Venda. Este o esquema relacional da tabela:
Venda(Codvenda, Cliente, Endereco, Cep, Cidade, Estado, Telefone, Produto,
Quantidade, Valorunitario, Valorfinal).
O raciocnio o seguinte: A tabela Venda, deve armazenar informaes da
venda. Pois bem, verificando o campo Cliente, sabemos que ele depende de CodVenda,
afinal para cada Venda h um cliente. Vendo o campo Endereo, podemos concluir que

Elisa Maria Pivetta UFSM/CAFW
ele no depende de Codvenda, e sim de Cliente, pois uma informao referente
particularmente ao cliente. No existe um endereo de venda, existe sim um endereo
do cliente para qual se fez a venda. Nisso podemos ver uma tabela aninhada.
Venda (Codvenda, Cliente, Endereo, Cep, Cidade, Estado, Telefone, Produto,
Quantidade, Valorunitario, Valorfinal).
A soluo extrair estes campos para uma nova tabela, adicionar uma chave-primria
nova tabela e relacion-la com a tabela Venda criando uma chave-estrangeira.
Ficaria desta forma:
Cliente (Codcliente, Nome, Endereo, Cep, Cidade, Estado, Telefone).
Venda (Codvenda, Codcliente, Produto, Quantidade, Valorunitario, Valorfinal).
Agora aplicamos novamente primeira forma normal as 2 tabelas geradas. Uma
situao comum em tabelas de cadastro o caso Cidade-Estado. Analisando friamente
pela forma normal, o Estado na tabela Cliente, depende de Cidade. No entanto Cidade,
tambm depende de Estado, pois no caso de a cidade ser Curitiba o estado sempre
dever ser Paran, porm se o Estado for Paran, a cidade tambm poder ser Londrina.
Isso o que chamamos de Dependncia funcional: onde aparentemente, uma
informao depende da outra. No caso Cidade-Estado a soluo simples:
Extramos Cidade e Estado, de Cliente e geramos uma nova tabela. Em seguida,
o mesmo processo feito anteriormente: adicionar uma chave-primria nova tabela e
relaciona-la criando uma chave-estrangeira na antiga tabela.
Cidade (Codcidade, Nome, Estado).
Cliente (Codcliente, Codcidade, Nome, Endereo, Cep, Telefone).
Venda (Codvenda, Codcliente, Codcidade, Produto, Quantidade, Valorunitario,
Valorfinal).
Seguindo com o exemplo, a tabela Cliente encontra-se na 1 forma normal, pois
no h mais tabelas aninhadas. Verificando Venda, podemos enxergar mais uma tabela
aninhada.
Venda (Codvenda, Codcliente, Codcidade, Produto, Quantidade, Valorunitario,
Valorfinal).
Na maioria das situaes, produtos tm um valor previamente especificado. O
Valorunitrio depende de Produto. J a Quantidade (campo entre Produto e
Valorunitario) no depende do produto e sim da Venda.
Cidade (Codcidade, Nome, Estado).
Cliente (Codcliente, Codcidade, Nome, Endereo, Cep, Telefone).

Elisa Maria Pivetta UFSM/CAFW
Produto (Codproduto, Nome, Valorunitario).
Venda (Codvenda, Codcliente, Codcidade, Codproduto, Quantidade, Valorfinal).
Passando a tabela Venda pela primeira forma normal, obtivemos 3 tabelas.
Vamos prxima forma.
2 Forma Normal: Verificao de Dependncias Parciais 2FN
Uma tabela est na Segunda Forma Normal 2FN se ela estiver na 1FN e todos os
atributos no chave forem totalmente dependentes da chave primria (dependente de
toda a chave e no apenas de parte dela).
Procedimentos:
Identificar os atributos que no so funcionalmente dependentes de toda a chave
primria;
Remover da entidade todos esses atributos identificados;
Criar uma nova entidade com eles.
Para uma tabela estar na segunda formal, alm de estar na primeira forma ela
no deve conter dependncias parciais. Um jeito de verificar esta norma refazer a
leitura dos campos fazendo a pergunta: Este campo depende de toda a chave? Se no,
temos uma dependncia parcial.
Vimos antes o caso Cidade-Estado que gerava uma dependncia funcional.
preciso entender este conceito para que voc entenda o que Dependncia Parcial.
Aps a normalizao da tabela Venda, acabamos com uma chave composta de 4
campos:
Venda (Codvenda, Codcliente, Codcidade, Codproduto, Quantidade, Valorfinal).
A questo agora verificar se cada campo no-chave depende destas 4 chaves.
O raciocnio seria assim:
1. O primeiro campo no-chave Quantidade.
2. Quantidade depende de Codvenda, pois para cada venda h uma quantidade
especfica de itens.
3. Quantidade depende de Codvenda e Codcliente, pois para um cliente podem ser
feitas vrias vendas, com quantidades diferentes.
4. Quantidade no depende de Cidade. Quem depende de Cidade Cliente. Aqui
est uma dependncia parcial.
5. Quantidade depende de Codproduto, pois para cada produto da Venda uma
quantidade certa.
Quantidade depende de 3 campos, dos 4 que compe a chave de Venda. Quem
sobrou nessa histria foi Codcidade. A tabela Cidade j est ligada com Cliente, que j
est ligado com Venda. A chave Codcidade em Venda redundante, portanto podemos
elimin-la.

Elisa Maria Pivetta UFSM/CAFW
Venda (Codvenda, Codcliente, Codproduto, Quantidade, Valorfinal).
O prximo campo no-chave Valorfinal. Verificando Valorfinal, da mesma
forma que Quantidade, ele depende de toda a chave de Venda. Portanto vamos
prxima norma.
3 Forma Normal: Verificao de Dependncias Transitivas 3FN
Uma tabela est na Terceira Forma Normal 3FN se ela estiver na 2FN e se
nenhuma coluna no-chave depender de outra coluna no-chave.
Na terceira forma normal temos de eliminar aqueles campos que podem ser
obtidos pela equao de outros campos da mesma tabela.
Procedimentos:
Identificar todos os atributos que so funcionalmente dependentes de outros
atributos no chave;
Remov-los.
A chave primria da nova entidade ser o atributo do qual os atributos removidos
so funcionalmente dependentes.
Para uma tabela estar na segunda formal, alm de estar na segunda forma ela no
deve conter dependncias transitivas. Um jeito de verificar esta norma refazer a leitura
dos campos fazendo a pergunta: Este campo depende de outro que no seja a chave?
Se Sim, temos uma dependncia transitiva..
No exemplo de Venda, temos um caso de dependncia transitiva:
Na tabela Venda, temos Valorfinal. Este campo o resultado do valor unitrio
do produto multiplicado pela quantidade, isto , para um valor final existir ele
DEPENDE de valor unitrio e quantidade. O Valorunitrio est na tabela Produto,
relacionada Venda e Quantidade est na prpria Venda. Valorfinal depende destes 2
campos e eles no so campos-chave, o que nos leva a pensar: Se temos valor unitrio e
quantidade, porque teremos valor final? O valor final nada mais que o resultado de um
clculo de dados que j est no banco, o que o torna um campo redundante.
Quando for necessrio ao sistema obter o valor final, basta selecionar o valor
unitrio e multiplicar pela quantidade. No h porque guardar o valor final em outro
campo. Aqui a soluo eliminar o campo Valorfinal.
Cidade (Codcidade, Nome, Estado).
Cliente (Codcliente, Codcidade, Nome, Endereco, Cep, Telefone).
Produto (Codproduto, Nome, Valorunitario).
Venda (Codvenda, Codcliente, Codproduto, Quantidade).

Elisa Maria Pivetta UFSM/CAFW
Em tese, agora temos todas as tabelas normalizadas. Ainda restou o caso do
campo Estado na tabela Cidade, que poder posteriormente ser normalizado. Porm o
objetivo aqui mostrar conceitualmente o processo de normalizao do banco de dados.
muito comum, no processo de normalizao enxergamos todas as formas
normais ao mesmo tempo. Enquanto separamos as tabelas aninhadas, j conseguimos
ver as dependncias transitivas e logo mais encontramos uma dependncia parcial, tudo
assim, ao mesmo tempo. Isso normal. S tome cuidado, para no deixar nada passar
nada.