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

A primeira forma normal assegura que não existam repetições de valores nos atributos nem grupos repetidos de atributos das entidades de um modelo de dados.

Em uma determinada realidade, às vezes encontramos algumas informações que se repetem, retratando ocorrências de um mesmo fato dentro de uma única linha e vinculada a sua chave primária.

O objetivo da primeira forma normal é eliminar o aninhamento de tabelas para que cada tabela tenha informações de um único assunto.
Não podemos ter mais de um assunto em uma tabela.

Ao observarmos a entidade PEDIDO, apresentada acima, 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.
Entretanto, a 1FN diz que a tabela não deve conter mais de um assunto, nem grupos repetitivos de atributos ( atributos multivalorados ).

Para se obter uma tabela na primeira forma normal ( 1FN ), é necessário decompor a tabela não normalizada em tantas tabelas quanto for o número de conjuntos de atributos repetitivos.
Ou seja, deve ser criada uma tabela para a tabela nao-normalizada e uma tabela para cada tabela aninhada na tabela não-normalizada.

Nas novas entidades criadas, a chave primária é a concatenação da chave primária original mais os atributos do grupo repetitivo visualizados como chave primária deste grupo.

Para Tabela não normalizada PEDIDO temos:

Ao aplicarmos a 1FN sobre a tabela PEDIDO, obtemos mais uma tabela chamada ITEM-DE-PEDIDO, que herdará os atributos repetitivos e destacados da tabela PEDIDO.
Um PEDIDO possui no mínimo 1 e no máximo N ocorrências em ITEM-DE-PEDIDOS e um ITEM-DE-PEDIDOS pertence a 1 e somente 1 PEDIDO, logo o relacionamento POSSUI é do tipo 1:M (OU 1:N).

Dependência Funcional

Dada uma tabela qualquer, dizemos que uma coluna ou conjunto de colunas A é dependente funcional de um outra coluna B, se a cada valor de B existir nas linhas da tabela um único valor de A.
Em outras palavras, A depende funcionalmente de B.

Exemplo:

Na tabela PEDIDO, a coluna PRAZO-DE-ENTREGA depende funcionalmente da coluna NÚMERO-DO-PEDIDO.
Em outras palavras, o NÚMERO-DO-PEDIDO determina o PRAZO-DE-ENTREGA.

Dependência Funcional Total

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 primaria concatenada quando para cada valor da chave está associado um valor para cada atributo.

Como exemplo de dependência funcional total temos na entidade ITEM-DO-PEDIDO, o atributo QUANTIDADE-DO-PRODUTO depende de forma total da chave primária concatenada ( NÚMERO-DO-PEDIDO + CÓDIGO-DO-PRODUTO ).

A dependencia Total só ocorre quando a chave primária for concatenada, composta por várias colunas e quando existe um ou mais colunas que dependem da chave primária.

Dependência Funcional Parcial

Quando uma coluna ou conjunto de colunas A depende de outra coluna B que faz parte da chave primária concatenada dizemos que há uma dependencia funcional parcial A em relação a B.
Para cada valor da coluna B existe um valor associado para a coluna A.

A dependência funcional parcial só existe quando a tabela possui chave primária composto por mais de uma coluna.

Como exemplo de dependência funcional Parcial temos na entidade ITEM-DO-PEDIDO, as colunas NOME_PRODUTO, PREÇO_UNITARIO que dependem de forma parcial da chave primária concatenada ( NÚMERO-DO-PEDIDO + CODIGO_PRODUTO ) através da coluna CODIGO-PRODUTO.

Dependência Funcional Transitiva

Quando uma coluna ou conjunto de colunas A depende de outra coluna B, que não pertence à chave primária, dizemos que A é dependente transitivo de B

Como exemplo de dependência funcional transitiva temos que na tabela PEDIDO, as colunas NOME DO CLIENTE, ENDERECO, CIDADE, UF, CGC e INSCRICAO ESTADUAL são dependentes da coluna CNPJ que não pertence à chave primária da tabela PEDIDO.
Ainda na tabela PEDIDO, o atributo NOME DO VENDEDOR é dependente transitivo do atributo CODIGO DO VENDEDOR que também não faz parte da chave primária da tabela PEDIDO.

A segunda forma normal assegura que não exista dependência funcional parcial no modelo de dados.

Para aplicarmos a segunda forma formal em uma tabela devemos observar se a tabela possui chave primária composta e verificar se existe alguma coluna com dependência parcial em relação a alguma coluna da chave primária concatenada.

A aplicação da segunda forma normal ( 2FN ) sobre a tabela em observação gera novas tabelas, que herdarão a chave parcial e todos os atributos que dependem parcialmente da chave primária, ou seja, uma entidade para estar na 2FN não pode ter atributos com dependência funcional parcial em relação à chave primária.

Exemplo:

A entidade ITEM-DO-PEDIDO apresenta uma chave primária concatenada e por observação, notamos que os atributos UNIDADE, DESCRICAO-DO-PRODUTO e VALOR-UNITÁRIO dependem de forma parcial do atributo CODIGO-DOPRODUTO, que faz parte da chave primária.

Logo, devemos aplicar a 2FN sobre esta entidade. Quando aplicamos a 2FN sobre ITEM-DO-PEDIDO, será criada a entidade PRODUTO que herdará os atributos UNIDADE, DESCRICAO-DO-PRODUTO e VALOR-UNITARIO e terá como chave primária CODIGO-DO-PRODUTO.
Imaginem se for preciso cadastrar um novo produto, sem que o mesmo não possua nenhum item de pedido, como poderia ser feito ?

A terceira forma normal assegura que nenhuma tabela do modelo relacional possui atributos com dependência transitiva.

Uma tabela está na 3FN se nenhuma coluna possui dependência transitiva em relação a outra coluna que não participe da chave primária.
Ao retirarmos a dependência funcional transitiva, devemos criar uma nova entidade que contenha as colunas que dependem transitivamente de outra coluna que não faz parte da chave primária.
A chave primária desta nova tabela é composta pela coluna que causou esta dependência.

Além de não conter colunas com dependência funcional transitiva, as tabelas na 3FN não devem conter colunas derivados que sejam o resultado de algum cálculo sobre outro coluna, o que de certa forma pode ser entendido como uma dependência funcional transitiva.

Toda coluna derivada a partir de outra coluna deve ser retirada do modelo dados.
O mesmo é válido para colunas que representam cálculos realizados com base em outras colunas da tabela.

Observação importante:

Porém este é um conceito que deve ser analisado com calma. Em muitos sistemas de informação existe a necessidade de se armazenar o resultado de cálculos, totais e valores consolidados. Sobretudo, em sistemas gerenciais ( SIG ) e sistemas de apoio a tomada de decisão ( SAD ).

Exemplo:

Na tabela PEDIDO, a coluna VALOR-TOTAL é calculada a partir do produto entre as colunas PREÇO-UNITÁRIO e QUANTIDADE.
Desta forma, VALOR-TOTAL depende tanto de PREÇO-UNITÁRIO quanto de QUANTIDADE o que constitui uma dependência funcional transitiva.
Para eliminar essa anomalia devemos remover esta coluna da tabela.

Um outro exemplo, ainda na tabela PEDIDO, podemos observar que a coluna NOME-DO-VENDEDOR depende transitivamente da coluna CODIGO-DO-VENDEDOR que não pertence a chave primária.
Para eliminarmos esta anomalia devemos criar a tabela VENDEDOR com seus colunas.
Da mesma forma e pelo mesmo motivo, também criaremos a tabela CLIENTE com suas colunas, cada tabela com seu assunto especifico.

Veja abaixo como fica o modelo relacional após o processo de normalização das tabelas:

As definições da 2Fn e 3FN, propostas por Codd, não cobriam certos casos.
O Prof. Raymond Boyce apontou situações não cobertas em 1974.
Os casos não cobertos pelas formas normais de Codd somente ocorrem quando 3 condições são satisfeitas:

• A entidade possui várias chaves candidatas
• As chaves candidatas são concatenadas
• As chaves candidatas compartilham pelo menos um atributo em comum

Na verdade a FNBC é um aperfeiçoamento 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 faz parte de uma chave ( primária ou candidata ) de uma entidade ele não é tratado pelas 2FN e 3FN.

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.

Veja o exemplo abaixo:
Considere a entidade FILHO que possui os atributos nome, endereco, data nascimento, nome escola, sala, nome professor.

Vamos considerar que um professor possa estar associado a mais de uma escola e uma sala o que normalmente acontece na vida real.
Veja que para que se possa identificar o professor precisamos de uma chave concatenada pois somente o nome do professor não é suficiente para garantir a identificação do professor.
Assim temos como chaves candidatas NOME ESCOLA + SALA ou NOME ESCOLA + NOME PROFESSOR.
Veja que esta entidade atende às três condições para a FNBC:

As chaves candidatas para a entidade FILHO são:
NOME FILHO + ENDERECO ou NOME FILHO + SALA ou NOME FILHO + NOME PROFESSOR

As três chaves apresentam mais de um atributo, são portanto concatenadas

As três chaves compartilham um mesmo atributo NOME FILHO

Neste exemplo, ao aplicar a FNBC, a entidade FILHO deve ser dividida em duas entidades, uma que contem todos os atributos que designam um professor a uma sala de uma escola e uma outra entidade que contem os atributos que descrevem o FILHO.

Assim temos duas entidades
FILHO = { nome, endereco, data nascimento, nome escola, sala}
SALA = { nome escola, sala, nome professor }
Temos duas entidades agora, uma para descrever o filho e outra para descrever o professor que trabalha em uma sala de aula de uma escola.

A quinta forma normal trata do conceito de dependencia de junção, quando a noção de normalização é aplicada à decomposição e aplicada na reconstrução ( engenharia reversa ) devido a uma junção.

A 5FN trata de casos particulares que ocorrem com pouca frequencia na modelagem de dados e que são os relacionamentos múltiplos ( ternários, quaternários, ... , n-nários ).
Ela fala que uma entidade está na sua 5FN quando o conteudo desta entidade nao puder ser reconstruído a partir de outras entidades menores, extraídas desta entidade.
Ou seja, ao se fazer a decomposição de uma entidade em outras entidades perde-se o conteúdo, a informação da entidade original, pois as entidades geradas pela decomposição não conseguem representar a informação original.

Vejamos um exemplo que ilustra o que foi explicado:

Uma empresa construi equipamentos a partir de desenhos de projeto desses equipamentos.
Para cada projeto são feitos documentos de requisições de materiais, necessários para a construção desses equipamentos.
Cada requisição de material dá origem a um ou mais pedidos de compra.

A tabela abaixo representa o relacionamento ternário acima que associa as 3 entidades MATERIAL, REQUISICAO e PEDIDO DE COMPRA.

No caso acima precisamos verificar se é possível substituir o relacionamento ternário por relacionamentos binários sem que ocorra perda de informação.
Podemos dizer que geralmente não é possível fazer esta decomposição sem perda da informação, armazenada no relacionamento ternário.
Isto porque os relacionamentos criados pela decomposição não são capazes de representar todo o conceito do relacionamento original.
Assim ao se tentar recompor o relacionamento original ocorre perda de informação.

Vejamos um exemplo abaixo de como seria a decomposição do relacionamento ternário acima em três relacionamentos binários:

O primeiro relacionamento associa a entidade MATERIAL à entidade PEDIDO COMPRA, criando a relacao 1 conforme abaixo:

O segundo relacionamento associa a entidade PEDIDO COMPRA à entidade REQUISICAO, criando a relação 2 conforme abaixo:

Finalmente temos o ultimo relacionamento binário que associa a entidade MATERIAL e a entidade REQUISICAO, criando a relacao 3:

Se iniciarmos um processo de recomposição destas relações, teremos a seguinte situação:

Primeiro, vamos recompor a relacao 1 com a relacao 2 através do atributo pedido compra.
Obtemos então a relacao 4, mostrada abaixo:

Perceba que o registro apontado pela seta não existia na tabela original, ou seja, foi criado pela junção das tabelas parciais.
Devemos juntar a relação 4, resultante das relações 1 e 2, com a outra relação 3, através dos campos material e requisicao.
Após esta composição temos a relação 5, mostrada abaixo:

Como se pode notar, ao se recompor as 3 relações, fruto da decomposição do relacionamento ternário, as informações originais foram preservadas.
Isto significa que o relacionamento PROJETO não está na 5FN, sendo necessário decompo-lo em relacionamentos binários que não permitam a recomposição com as informações originais.

A definição da 5FN diz que: uma relação de 4FN está na 5FN quando seu conteúdo não puder ser reconstruído, existindo perda de informação, a partir das relações criadas pela decomposição da relação original.
Esta forma normal trata especificamente dos casos de perda de informação, quando da decomposição de relacionamentos múltiplos.

Com a 5FN algumas redundancias podem ser retiradas, como a informação de que o ROTOR 1BW está presente na requisição R3192, será armazenada uma única vez, a qual na forma não normalizada pode ser repetida inúmeras vezes.