Normalização - As 3 Primeiras Formas Normais

As Formas Normais, definidas na teoria de bancos de dados relacional, representam diretrizes, "regras", de como as informações ficarão organizadas no banco de dados (independente do banco, desde que seja relacional, certo!).

A correta utilização das FN (Formas Normais) possibilita que evitemos anomalias e inconsistências no banco de dados. Na minha opinião, um banco de dados perfeito, trabalha sob as FN de maneira a facilitar e organizar a lógica obtenção e manipulação dos dados no banco de dados.

Bem, agora, vamos conhecer as 3 Formas Normais!

1ª Forma Normal - 1FN

Segundo a 1FN, todas as ocorrências de um registro devem conter os mesmos números de campos.

A 1FN não admite repetições, ou campos que contém mais de um valor. Observe o exemplo:

Neste caso, para realizar a completa normalização, seguindo a 1FN, teríamos as seguintes tabelas:

Neste exemplo, os telefones ficaram separados, por haver a possibilidade de um dos registros possuír mais de um telefone, o que, se cadastrado na mesma tabela, ocasionaria a “desnormalização” dos dados. Quanto ao CEP, encontra-se em um campo separado do Endereço, bem como o Bairro e os registros estão, assim, de forma aninhada. 

2ª Forma Normal - 2FN

Podemos dizer que uma tabela está na 2FN se ela estiver na 1FN e todos os atributos não chave forem totalmente dependentes da chave primária (dependente de toda a chave e não apenas de parte dela – em caso de chaves compostas).

Entenda: se o nome do cliente já existe na tabela Clientes, então, ele não é necessário na tabela Atendimentos. É disso que a 2FN trata, dessas anomalias, redundâncias no banco de dados.

 Veja um exemplo, com um cenário de vendas de produtos:

  

De fato, isto está errado, uma vez, que os produtos são cadastrados em outra tabela (a tabela de produtos) onde, no ato do cadastro, já informamos seu nome. O correto seria assim:

 

Observe que só é necessário fazer referência a chave primária (ao código) do produto, e nada mais!

3ª Forma Normal - 3FN

Sabemos que uma tabela está na 3FN se ela estiver na 2FN e se nenhuma coluna não-chave depender de outra coluna não-chave.

Basicamente, o objetivo é eliminar os  campos que podem ser obtidos pela equação (cálculo matemático ou lógico) de outros campos da mesma tabela.

A chave primária da nova entidade será o atributo do qual os atributos removidos são funcionalmente dependentes.

Vamos considerar a seguinte tabela:

Observe que o valor da coluna “Subtotal” pode (e deve), tranquilamente ser obtido através do cálculo do valor da coluna “Quant” multiplicado pelo valor da coluna “Valor_unit”. Isso eliminaria da nossa tabela (da tabela acima) a coluna “Subtotal”, deixando-a assim: