Caros leitores. Estou de volta com a ultima parte desta série, onde falarei sobre Normalização.

Normalização é um processo baseado nas chamadas “formais normais”. Uma forma normal é uma regra de deve ser aplicada na construção das tabelas do banco de dados para que estas fiquem bem projetadas. Segundo autores, existem 4 formas normais. Neste artigo vou falar sobre as 3 primeiras, sendo as principais.

Com o banco de dados construído, devem-se aplicar as 3 formas normais em cada tabela, ou grupo de tabelas relacionadas. As formas têm uma ordem e são dependentes, isto é, para se aplicar a segunda norma, deve-se obrigatoriamente ter aplicado a primeira e assim por diante.

Então, vamos ás normas:

1ª Forma Normal: Verificação de Tabelas Aninhadas.

Para uma tabela estar na primeira forma normal ela não deve conter tabelas aninhadas. Um jeito fácil de verificar esta norma é fazer uma leitura dos campos das tabelas fazendo a pergunta: “Este campo depende de qual?”.

Vamos exemplificar, com a tabela Venda. Este é o esquema relacional da tabela:

Venda(Codvenda, Cliente, Endereco, Cep, Cidade, Estado, Telefone, Produto, Quantidade, Valorunitario, Valorfinal).

O raciocínio é o seguinte: A tabela Venda, deve armazenar informações da venda. Pois bem, verificando o campo “Cliente”, sabemos que ele depende de convinda, afinal para cada Venda há um cliente. Vendo o campo “Endereço”, podemos concluir que ele não depende de Codvenda, e sim de “Cliente”, pois é uma informação referente particularmente ao cliente. Não existe um endereço de venda, existe sim um endereço do cliente para qual se fez a venda.

Nisso podemos ver uma tabela aninhada. Os campos entre colchetes, são referentes ao cliente e não á venda.

Venda (Codvenda, [Cliente, Endereço, Cep, Cidade, Estado, Telefone], Produto, Quantidade, Valorunitario, Valorfinal).

A solução é extrair estes campos para uma nova tabela, adicionar uma chave-primária à nova tabela e relaciona-la com a tabela Venda criando uma chave-estrangeira.

Ficaria desta forma:

Cliente (Codcliente, Nome, Endereço, Cep, Cidade, Estado, Telefone).

Venda (Codvenda, Codcliente, Produto, Quantidade, Valorunitario, Valorfinal).

Agora aplicamos novamente á primeira forma normal as 2 tabelas geradas. Uma situação comum em tabelas de cadastro é o caso “Cidade-Estado”. Analisando friamente pela forma normal, o Estado na tabela Cliente, depende de Cidade. No entanto Cidade, também depende de Estado, pois no caso de a cidade ser “Curitiba” o estado sempre deverá ser “Paraná”, porém se o Estado for “Paraná”, a cidade também poderá ser “Londrina”. Isso é o que chamamos de Dependência funcional: é onde aparentemente, uma informação depende da outra. No caso Cidade-Estado a solução é simples:

Extraímos Cidade e Estado, de Cliente e geramos uma nova tabela. Em seguida, o mesmo processo feito anteriormente: adicionar uma chave-primária à nova tabela e relaciona-la criando uma chave-estrangeira na antiga tabela.

Cidade (Codcidade, Nome, Estado).

Cliente (Codcliente, Codcidade, Nome, Endereço, Cep, Telefone).

Venda (Codvenda, Codcliente, Codcidade, Produto, Quantidade, Valorunitario, Valorfinal).

Seguindo com o exemplo, a tabela Cliente encontra-se na 1ª forma normal, pois não há mais tabelas aninhadas. Verificando Venda, podemos enxergar mais uma tabela aninhada. Os campos entre colchetes são referente á mesma coisa: Produto de Venda

Venda (Codvenda, Codcliente, Codcidade, [Produto] Quantidade, [Valorunitario], Valorfinal).

Na maioria das situações, produtos têm um valor previamente especificado. O Valorunitário depende de Produto. Já a Quantidade (campo entre Produto e Valorunitario) não depende do produto e sim da Venda.

Cidade (Codcidade, Nome, Estado).

Cliente (Codcliente, Codcidade, Nome, Endereço, Cep, Telefone).

Produto (Codproduto, Nome, Valorunitario).

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

Passando a tabela Venda pela primeira forma normal, obtivemos 3 tabelas. Vamos á próxima forma