Instituto Livramento

Curso Tcnico de Informtica

Anlise de Sistemas


http://blog.rafaelamorim.com.br amorim@rafaelamorim.com.br
Verso 02/2011
30
NORMALIZACAO DE TABELAS

Atualmente, comum verificarmos organizaes com bases de dados da ordem dos
terabytes. Alm disso, sabido que a necessidade de informaes por parte dos gestores enorme e
vem crescendo diariamente. Isto porque a tomada de decises, com base em informaes, torna-se
muito precisa. E, para que estas informaes sejam geradas com qualidade, necessrio um bom
projeto de banco de dados.
Sabemos que o objetivo de um projeto de BD obter um conjunto de esquemas de tabelas
que nos permita armazenar dados sem REDUNDNCIA e que as informaes possam ser geradas
facilmente. Para verificar se um projeto de BD atende a estes pressupostos, podemos aplicar algumas
regras aos projetos em questo. A estas regras damos o nome de FORMAS NORMAIS.
Originalmente, Edgar Codd definiu trs formas normais (Primeira, Segunda e Terceira Forma
Normal), mas hoje existe algumas outras (Forma Normal de Boyce-Codd, Quarta e Quinta Forma
Normal) como veremos mais adiante. Muitos autores dizem que aplicando as trs formas normais
definidas por Codd, o projeto do BD j estar livre de redundncias e inconsistncias.
Entretanto, outros autores definem como de extrema importncia a aplicao das outras
formas normais.
As formas normais devem ser aplicadas ao modelo de dados definido pelo profissional. Ao
final da aplicao, podemos dizer que o projeto de Banco de Dados est livre de redundncia e
conseqentemente de inconsistncias.
Neste momento podemos definir NORMALIZAO como sendo uma srie de passos que se
segue no projeto de um banco de dados que permite um armazenamento consistente e um eficiente
acesso aos dados em um banco de dados relacional.
Esses passos evitam a redundncia de dados e as chances dos dados se tornarem
inconsistentes. Devemos fazer uso destes passos sempre que estivermos projetando nossas solues
de BD, salvo casos especficos onde trabalhamos com o conceito de desnormalizao.

Conceitos

Dependencia Funcional: relacionamento entre dois ou mais atributos de forma que o valor de um
atributo identifique o valor para cada um dos outros atributos, ou seja, um atributo est relacionado
a outro.
Ex: A => B
Instituto Livramento
Curso Tcnico de Informtica
Anlise de Sistemas


http://blog.rafaelamorim.com.br amorim@rafaelamorim.com.br
Verso 02/2011
31
Onde B dependente do atributo A, ou seja, precisamos saber o valor de A para descobrir o valor de
B.
CodCliente => NomeCliente
Dependencia Funcional Parcial: ocorre quando os atributos no chave no dependam
funcionalmente de toda a chave primria quando esta for composta.
Ex: AB => C,D
Considera-se que o atributo C dependa funcionalmente de A, mas no necessariamente de B.
Dependencia Funcional Transitiva: ocorre quando um atributo no depende diretamente da chave
primria ou de parte dela, mas sim depende de outro atributo que no chave primria.
Atributos Multivalorados: so atributos que podem conter mais de um valor par a um mesmo
registro.
Atributos Compostos: so atributos que podem ser subdivididos em vrios atributos.
Atributos Atmicos: so atributos que no podem ser subdivididos e tambm no so
multivalorados. Por exemplo: CPF,CNPJ.
Dependncia Funcional Multivalorada: ocorre quando para cada valor de um atributo A, h um
conjunto de valores para outros atributos B e C que esto associados a ele, porm independente
entre si.
Dependncia Funcional Cclica: ocorre quando temos dependncias como: A => B ; B => C ; C => A.
SuperChave: qualquer conjunto de atributos contendo uma chave, seja ela primria ou candidata.
Chave Candidata: atributo que tem a propriedade de identificar unicamente um registro. Poder vir a
ser uma chave primria. Tambm chamada de chave alternativa. Por ex: Codigo e CPF.
Chave Primria: chave que identifica o registro dentro de uma tabela.

1 Forma Normal (1FN)

Uma tabela se encontra na 1FN se todos os atributos possurem apenas valores atmicos
(simples e indivisves) e os valores de cada atributo no registro tambm deve ser um valor simples
(ou seja, o atributo no composto). Desta forma, caso existam atributos compostos, estes devem
ser divididos em atributos atmicos. Caso existam atributos multivalorados, estes devem fazer parte
de outra tabela, que estar relacionada com a tabela original. Para exemplificar, veja a tabela abaixo.

Instituto Livramento
Curso Tcnico de Informtica
Anlise de Sistemas


http://blog.rafaelamorim.com.br amorim@rafaelamorim.com.br
Verso 02/2011
32

Codigo Nome Telefone Endereo
1 Ary 55-32224543
55-32224544
55-32234545
Av.Getulio Vargas 43, apto 321 Centro - Santana Do
Livramento RS
2 Tatiana 53-32234646
53-32245654
Av.Brasil 123 Centro Bag RS
3 Ana 11-43222231 Rua Minas 100 Centro So Paulo SP
4 Joo 11-43221543 Praa da Liberdade 21, Bairro Esperana So Paulo
SP

Perceba que a referida tabela no est na 1FN, pois possui um atributo multivalorado
(Telefone) e um atributo composto (Endereo).
Como deixar esta tabela na 1FN?

2 Forma Normal (2FN)

Uma tabela se encontra na 2FN se estiver na 1FN e no possuir dependncia funcional
parcial.
Caso existam atributos que no dependam integralmente da chave primria, devemos retirar
da tabela todos eles e dar origem a uma nova tabela.
Para exemplificar, vejamos a tabela abaixo.
Nro Codp Nomep Vunit Qdade Vtot
1 1 Sabo em p 5,50 2 11,00
2 2 Sabonete 1,10 5 5,50
3 1 Sabo em p 5,50 3 16,50
4 2 Sabonete 1,10 2 2,20

Suponha que a chave primria desta tabela seja os atributos Nro e Codp. Logo, trata-se de
uma chave primria composta. Assim, iremos verificar se esta tabela encontra-se na 2FN.
O primeiro passo verificar se a tabela vendas encontra-se na 1FN. Podemos verificar que
no existem atributos compostos ou multivalorados nesta tabela.
Instituto Livramento
Curso Tcnico de Informtica
Anlise de Sistemas


http://blog.rafaelamorim.com.br amorim@rafaelamorim.com.br
Verso 02/2011
33
Posteriormente, precisamos verificar se existe dependnca parcial de chave. Note que na
tabela vendas, existe a dependncia funcional parcial; Codp => NomeP,Vunit, ou seja, Nome do
Produto e Valor Unitrio so determinados pelo Cdigo do Produto. Desta forma, existem atributos
que no dependem integralmente da chave primria, ento, a tabela vendas no est na 2FN.
Para que possamos adequar a tabela 2FN, devemos separar a tabela vendas em duas
tabelas: vendas e produtos. Os atributos da dependncia parcial devem fazer da tabela Produtos.
Desta forma, com estas duas novas tabelas, verificamos a adequao 2FN. Percebemos que
para verificar a adequao 2FN, podemos seguir alguns passos:
1) Se existirem apenas atributos atmicos, as tabelas se encontram na 1FN.
2) Caso no existam chaves primrias compostas, no h como existir dependncia funcional
parcial e as tabelas encontram-se na 2FN.
3) Caso existam chaves primrias compostas, deve-se verificar a dependncia funcional
parcial.

3 Forma Normal (3FN)

Uma tabela est na 3FN se estiver na 2FN e no possuir nenhuma dependncia funcional
transitiva.
Para exemplificar, vejamos a tabela abaixo:
Matricula NomeFuncionario CodCargo NomeCargo SalarioCargo
1 Ary 1 Professor 7500
2 Tatiana 2 Advogado 6900
3 Ana 3 Secretaria 1550
4 Rodrigo 1 Professor 7500

Nesta tabela, a chave primria o nmero da matrcula do funcionrio (atributo matricula).
O primeiro passo para verificar se esta tabela encontra-se na 3FN verificar se ela est na
2FN. Podemos perceber que a tabela funcionrio encontra-se porque existem apenas atributos
atmicos e no existe dependncia funcional parcial, uma vez que a chave primria da tabela no
composta.
Aps verificar que a tabela encontra-se na 2FN, vamos verificar a existncia de dependncia
funcional transitiva em tabela chave primria. Neste momento, verificamos que nesta tabela existe
a seguinte dependncia: CodCargo => NomeCargo,SalarioCargo.
Instituto Livramento
Curso Tcnico de Informtica
Anlise de Sistemas


http://blog.rafaelamorim.com.br amorim@rafaelamorim.com.br
Verso 02/2011
34
Perceba que CodCargo no chave primria e os atributos CargoNome e SalarioCargo esto
dependendo dele. Logo, a tabela funcionrios no se encontra na 3FN
Para resolver a dependncia funcional transitiva, precisamos separar em duas ou mais
tabelas de forma a eliminar tal dependncia. Neste caso, podemos dividir a tabela funcionrio em
duas tabelas: funcionrios e cargo.

Roteiro para chegar at a 3FN




Instituto Livramento
Curso Tcnico de Informtica
Anlise de Sistemas


http://blog.rafaelamorim.com.br amorim@rafaelamorim.com.br
Verso 02/2011
35
Exerccios de fixao

1) Defina:
a. Dependncia funcional;
b. Atributo multivalorado;
c. Atributo atmico;
d. Atributo composto;
e. Chave Primria;

2) Aplicar as Formas Normais cabveis, nas questes abaixo. Voc deve transformar os
esquemas abaixo em conjuntos de esquemas que estejam na 2NF, 3NF e, justificar sua
normalizao de acordo com suas dependncias funcionais.
a. Ordem de Compra (cd_ordem_compra, dt_emisso, cd_fornecedor,
nome_fornecedor, endereo_fornecedor, cod_material (n vezes), descrio_material
(n vezes), qt_comprada (n vezes), vlr_unitrio (n vezes), vlr_total_item (n vezes),
vl_total_ordem).
b. Notas Fiscais (Num_NF, Srie, Data emisso, Cod. Cliente, Nome cliente, Endereo
completo cliente, CGC cliente, telefone cliente (n nmeros), Cdigo Mercadoria,
Descrio Mercadoria, Quantidade vendida, Preo de venda, Total da venda da
Mercadoria e Total Geral da Nota). Lembrando que cada nota pode ter mais do que
uma mercadoria.

3) O processo de normalizao pode ser executado sobre qualquer tipo de representao de
dados. Pode partir da descrio de um arquivo em computador, do layout de um relatrio,
de uma tela do sistema, etc.
Veja abaixo:

Instituto Livramento
Curso Tcnico de Informtica
Anlise de Sistemas


http://blog.rafaelamorim.com.br amorim@rafaelamorim.com.br
Verso 02/2011
36
Para cada projeto, so informados o cdigo, a descrio e o tipo do projeto, bem como os
empregados que atuam no projeto. J para cada empregado do projeto, so informados o
seu numero, nome, categoria funcional, data em que o empregado foi alocado no projeto e o
tempo pelo qual o empregado foi alocado no projeto.
Desenvolva a engenharia reversa necessria e logo aps, coloque na 3 FN, justificando cada
passo efetuado.