Normalização De Bancos De Dados

Normalização de banco de dados

Segundo Heuser (2001), uma forma normal (FN) é uma regra que deve ser obedecida por uma tabela para que ela seja considerada “bem projetada”. Existem inúmeras formas normais, ou seja, diversas regras, cada vez mais rígidas, para verificar tabelas em banco de dados relacionais. No entanto, pelo menos 3 FNs são consideradas essenciais para a construção de um bom projeto de banco de dados.

1FN (Primeira Forma Normal)

Primeira forma normal (1FN) = diz

que uma tabela está na primeira forma normal quando ela não contém tabelas aninhadas

Considere a planilha a seguir:

A planilha acima representada em um modelo relacional não normalizado (ÑN) ficaria assim:

Segundo a definição da 1FN, para normalizar a tabela acima, é necessário decompô-la em duas:

Proj(CodProj, Tipo, Descr);

Emp(CodProj, CodEmp, Nome, Cat, Sal, DataIni, TempAl);

Ou seja:

* As colunas destacadas em cinza compõem as chaves primárias.

** Vale ressaltar que se houvesse a restrição de que um funcionário só pudesse participar de exatamente 1 projeto, a chave-primária da tabela ProjEmp poderia ser composta unicamente de CodEmp.

2FN (Segunda Forma Normal)

Observando a tabela ProjEmp acima, é possível identificar que os dados do funcionário Mário se repetem em duas tuplas. É esse tipo de redundância que a 2FN visa eliminar.

Segunda Forma Normal (2FN) = uma tabela encontra-se na segunda forma normal, quando, além de estar na 1FN, não contem dependências parciais.

Dependência parcial = uma dependência parcial ocorre quando uma coluna depende apenas de parte de uma chave primária composta.

A partir das definições acima, podemos concluir que a tabela Proj já se encontra na 2FN, pois todos seus atributos dependem exclusivamente de sua chave primária, já a tabela ProjEmp não. Verifique, em ProjEmp, que atributos como Nome, Cat, Sal dependem somente de CodEmp, enquanto que DataIni, TempAl dependem da chave primária composta por inteiro (tal fato se justifica porque pode ser necessário identificar a data em que determinado usuário ingressou em um projeto). Sendo assim, para que a tabela ProjEmp fique de acordo com a 2FN, é necessário decompô-la em duas outras (ProjEmp e Emp). O projeto então fica como segue:

3FN (Terceira Forma Normal)

Observando o modelo gerado aplicando-se as regras da 2FN e supondo que o salário de um empregado é determinado por sua categoria funcional (Cat), podemos notar que ainda restam dados redundantes na tabela Emp; todos os empregados da categoria A1 e A2 possuem salário 4 e B1 possuem salário 9. A 3FN visa eliminar esse tipo de redundância.

Terceira Forma Normal (3FN) = uma tabela encontra-se na terceira forma normal, quando, além de estar na 2FN, não contém dependências transitivas

Dependência transitiva = uma dependência funcional transitiva ocorre quando uma coluna, além de depender da chave primária da tabela, depende de outra coluna ou conjunto de colunas da tabela

Sendo assim, a tabela Emp obtida pela aplicação da 2FN, que contém os dados redundantes, pode ser decomposta em outras duas (Emp e Cat). O modelo fica como segue:

Resumo

1FN

1. Cria-se uma tabela na 1FN referente à tabela ÑN e que contém apenas colunas com valores atômicos, isto é, sem as tabelas aninhadas;

2. Para cada tabela aninhada, cria-se uma tabela na 1FN compostas pelas seguintes colunas:

a. A chave primária de uma das tabelas na qual a tabela em questão está aninhada

b. As colunas da própria tabela