Tabelas - Forma Normal

Tabelas - Forma Normal 

A disciplina Análise de Sistemas abordará detalhadamente esta importante metodologia para definição das tabelas que irão compor a base de dados, que aqui apenas citaremos. 

Primeira Forma Normal: 

Uma relação se encontra na primeira forma normal se todos os domínios de atributos possuem apenas valores atômicos (simples e indivisíveis), e que os valores de cada atributo na tupla seja um valor simples. Assim sendo todos os atributos compostos devem ser divididos em atributos atômicos. 

Segunda Forma Normal: 

Uma relação se encontra na segunda forma normal quando estiver na primeira forma normal e todos os atributos que não participam da chave primária são dependentes desta. 

Assim devemos verificar se todos os atributos são dependentes da chave primária e retirar-se da relação todos os atributos de um grupo não dependente que dará origem a uma nova relação, que conterá esse atributo como não chave. 

Desta maneira, na segunda forma normal evita inconsistências devido a duplicidades. 

Terceira Forma Normal: 

Uma relação estará na terceira forma normal, quando estiver na primeira forma norma e todos os atributos que não participam da chave primária são dependentes desta porém não transitivos. 

Assim devemos verificar se existe um atributo que não depende diretamente da chave, retirá-lo criando uma nova relação que conterá esse grupo de atributos, e defina com a chave, os atributos dos quais esse grupo depende diretamente. 

O processo de normalização deve ser aplicado em uma relação por vez, pois durante o processo de normalização vamos obtendo quebras, e por conseguinte, novas relações. 

No momento em que o sistema estiver satisfatório, do ponto de vista do analista, este processo iterativo é interrompido. 

De fato existem literaturas indicando quarta, quinta formas normais, que não nos parece tão importante, nem mesmo academicamente. 

A normalização para formas apoiadas em dependências funcionais evita inconsistências, usando para isso a própria construção da Base. 

Se a mesma consistência for passível de ser garantida pelo aplicativo, a normalização pode ser evitada com ganhos reais no desempenho das pesquisas. No caso da consistência não ser importante, também podemos não normalizar totalmente uma Base de Dados. 

Exemplo: Normalizar os seguintes atributos: 

Nº do Pedido, Nome do Cliente, Nome dos Produtos, Quantidades Nº do Pedido, Código do Cliente, Nome dos Produtos, Quantidades Código do Cliente, Nome do Cliente Nº do Pedido, Código do Cliente, Código dos Produtos, Quantidades Código do Cliente, Nome do Cliente Código do Produto, Nome do Produto Nº do Pedido, Código do Cliente Código do Cliente, Nome do Cliente Código do Produto, Nome do Produto Nº do Pedido, Código do Produto, Quantidade Cliente Pedido Item Produto CliCodi PedNume PedNume ProCodi CliNome CliCodi ProCodi ProNome IteQtde 

O esquema apresentado anteriormente poderia ser inferido diretamente, usando metodologia tipicamente apresentada em Organização e Método. 

Se soubermos, por hipótese, que um profissional habilitado desenhou o pedido da empresa, e que esta o está utilizando com sucesso, poderíamos basear nosso modelo de dados neste formulário. 

Devemos notar que muitos Analistas de Sistemas não adotam estes procedimentos, por preferirem os métodos convencionais para elaboração do Modelo de Dados. 

Considerando qualquer formulário de pedidos podemos notar que o Número do Pedido geralmente tem destaque e sempre é único, ou seja encontramos nossa chave primária da Tabela de Pedidos, como sabemos que um cliente pode fazer mais de uma compra, achamos nossa Tabela de Clientes, que pode ter um Código, portanto achamos sua chave primária, que por conseguinte será a chave estrangeira da Tabela de Pedidos. 

Um ponto delicado, diz respeito aos itens do pedido, que formam geralmente um espaço destacado dentro do formulário de pedidos. Geralmente, e este é um dos casos, estas áreas em separado dos formulários darão origem a tabelas filhas, como é o caso típico das duplicatas em notas fiscais, ou dos dependentes na ficha de funcionários. 

Portanto achamos nossa Tabela de Itens que será ligada à Tabela de Pedidos através do Número do Pedido, que é ao mesmo tempo chave primária e chave estrangeira para a Tabela de Itens. 

Finalmente podemos perceber, que da mesma forma como os clientes se repetem em relação a Tabela de Pedidos, os produtos podem se repetir na tabela de itens (observe que não obstante não termos nenhum pedido com o mesmo item grafado duas vezes, este item pode ser adquirido em outro pedido). 

Assim descobrimos nossa quarta tabela, a Tabela de Produtos e a chave primária Código do Produto.