2ª Forma Normal: Verificação de Dependências Parciais

Para uma tabela estar na segunda formal, além de estar na primeira forma ela não deve conter dependências parciais. Um jeito de verificar esta norma é refazer a leitura dos campos fazendo a pergunta: “Este campo depende de toda a chave? Se não, temos uma dependência parcial.”.

Vimos antes o caso “Cidade-Estado” que gerava uma dependência funcional. É preciso entender este conceito para que você entenda o que é Dependência Parcial.

Após a normalização da tabela Venda, acabamos com uma chave composta de 4 campos:

Venda (Codvenda, Codcliente, Codcidade, Codproduto, Quantidade, Valorfinal).

A questão agora é verificar se cada campo não-chave depende destas 4 chaves. O raciocínio seria assim:

            O primeiro campo não-chave é Quantidade.

- Quantidade depende de Codvenda, pois para cada venda há uma quantidade específica de itens.

- Quantidade depende de Codvenda e Codcliente, pois para um cliente podem ser feitas várias vendas, com quantidades diferentes.

- Quantidade não depende de Cidade. Quem depende de Cidade é Cliente. Aqui está uma dependência parcial.

- Quantidade depende de Codproduto, pois para cada produto da Venda á uma quantidade certa.

Quantidade depende de 3 campos, dos 4 que compõe a chave de Venda. Quem sobrou nessa história 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.

Venda (Codvenda, Codcliente, Codproduto, Quantidade, Valorfinal).

O próximo campo não-chave é Valorfinal. Verificando Valorfinal, da mesma forma que Quantidade, ele depende de toda a chave de Venda. Portanto vamos á próxima norma.

3ª Forma Normal: Verificação de Dependências Transitivas

Para uma tabela estar na segunda formal, além de estar na segunda forma ela não deve conter dependências transitivas. Um jeito de verificar esta norma é refazer a leitura dos campos fazendo a pergunta: “Este campo depende de outro que não seja a chave? Se Sim, temos uma dependência transitiva.”.

No exemplo de Venda, temos 1 caso de dependência transitiva:

Na tabela Venda, temos Valorfinal. Este campo é o resultado do valor unitário do produto multiplicado pela quantidade, isto é, para um valor final existir ele DEPENDE de valor unitário e quantidade. O Valorunitário está na tabela Produto, relacionada à Venda e Quantidade está na própria Venda. Valorfinal depende destes 2 campos e eles não são campos-chave, o que nos leva a pensar: “Se temos valor unitário e quantidade, porque teremos valor final?” O valor final nada mais é que o resultado de um cálculo de dados que já está estão no banco, o que o torna um campo redundante.

Quando for necessário ao sistema obter o valor final, basta selecionar o valor unitário e multiplicar pela quantidade. Não há porque guardar o valor final em outro campo. Aqui a solução é eliminar o campo Valorfinal.

Cidade (Codcidade, Nome, Estado).

Cliente (Codcliente, Codcidade, Nome, Endereco, Cep, Telefone).

Produto (Codproduto, Nome, Valorunitario).

Venda (Codvenda, Codcliente, Codproduto, Quantidade).

Em tese, agora temos todas as tabelas normalizadas. Ainda restou o caso do campo Estado na tabela Cidade, mas eu deixarei para uma outra ocasião, pois o objetivo aqui é mostrar conceitualmente o processo de normalização do banco de dados.

É muito comum, no processo de normalização enxergamos todas as formas normais ao mesmo tempo. Enquanto separamos as tabelas aninhadas, já conseguimos ver as dependências transitivas e logo mais encontramos uma dependência parcial, tudo assim, ao mesmo tempo. Isso é normal. Só tome cuidado, para não deixar nada passar batido.

Reforçando o recado do artigo anterior: tem muito mais a ser visto sobre as etapas que eu mostrei nessa série. Aqui foi só uma demonstração do que se deve levar em conta ao modelar e construir um banco de dados íntegro, correto e que aproveita os dados da forma mais eficiente possível.

Um abraço á todos e até o próximo artigo!