ACC: Database Normalization Basics

Este artigo explica as noções básicas da terminologia de normalização de base de dados. Uma compreensão básica desta terminologia é útil quando estiverem a debater a estrutura de uma base de dados relacional.

Nota : a Microsoft também disponibiliza uma WebCast que explica os princípios básicos de normalização de base de dados. Para visualizar esta WebCast, visite o seguinte Web site da Microsoft: Nota : para ver estas informações para o Microsoft Access 2000, consulte o seguinte artigo na base de dados de conhecimento da Microsoft:

Descrição de normalização

Normalização é o processo de organizar dados numa base de dados. Este envolve a criação de tabelas e o estabelecimentos de relações entre essas tabelas, de acordo com regras concebidas para proteger os dados e para tornar a base de dados mais flexível eliminando dois factores: redundância e dependência inconsistente.

Dados redundantes desperdiçam espaço em disco e criam problemas de manutenção. Se devem ser alterados dados em mais do que um local, os dados devem ser alterados exactamente da mesma forma em todas as localizações. Uma alteração de endereço do cliente é muito mais fácil de implementar se esses dados estiver armazenados apenas numa tabela clientes e nowhere pessoa na base de dados.

O que é uma "dependência inconsistente"? Enquanto é intuitivo para um utilizador procura na tabela clientes para o endereço de um determinado cliente, poderá não fazer sentido procurar existe o salário do funcionário que as chamadas na qual o cliente. Salário o empregado relacionadas com o, ou dependentes, o empregado e que assim deve ser movido para a tabela de empregados. As dependências inconsistentes podem dificultar dados para acesso; o caminho para localizar os dados pode estar em falta ou interrompido.

Existem algumas regras de normalização de base de dados. Cada regra é chamada "forma normal". Se a primeira regra é respeitada, diz-se a base de dados que está a ser "primeira forma normal". Se as três primeiras regras são observadas, a base de dados é considerada na "terceira forma normal". Apesar de outros níveis de normalização serem possíveis, terceira forma normal é considerada o nível mais elevado necessário para a maioria das aplicações.

Como com várias regras formais e especificações, cenários reais não são sempre permitida para conformidade com. Em geral, normalização requer tabelas adicionais e alguns clientes localizar este complicado. Se decidir violar uma das três primeiras regras da normalização, certifique-se de que a aplicação antecipa quaisquer problemas que poderá ocorrer, tais como dados redundantes e dependências inconsistentes.

Nota : as descrições seguintes incluem exemplos.

Primeira forma normal

• Elimine grupos de repetição em tabelas individuais.
• Crie uma tabela separada para cada conjunto de dados relacionados.
• Identificar cada conjunto de dados relacionados com uma chave primária.

Não utilize vários campos numa única tabela para armazenar dados semelhantes. Por exemplo, para controlar um item de inventário que pode vir de duas origens possíveis, um registo de inventário pode de conter campos para fornecedor código 1 e 2 do código de fornecedor.

Mas o que acontece quando adicionar um terceiro fornecedor? Adicionar um campo não é a resposta; requer modificações do programa e tabela e não bom acomodar um número dinâmico de fornecedores. Em vez disso, coloque todas as informações de fornecedor numa tabela separada denominada fornecedores e inventário de ligação a fornecedores com uma chave de número de produto ou fornecedores para inventário com uma chave de código do fornecedor.

Segundo forma normal

• Crie tabelas separadas para conjuntos de valores que se aplicam a vários registos.
• Relacione estas tabelas com uma chave externa.

Registos não devem depender diferente de chave primária de uma tabela (uma chave composta, se necessário). Por exemplo, considere o endereço do cliente num sistema de gestão de contas. O endereço é necessário pela tabela clientes, mas também pelas tabelas Encomendas, envio, facturas, contas a receber e colecções. Em vez de armazenar o endereço do cliente como uma entrada separada em cada uma destas tabelas, guarde-a num local, na tabela clientes ou numa tabela endereços separada.

Terceira forma normal

• Elimine campos que não dependam da chave.

Valores de um registo que não fazem parte da chave do registo não pertencem na tabela. Em geral, sempre que o conteúdo de um grupo de campos pode aplicar para mais do que um único registo na tabela, deverá considerar colocar esses campos numa tabela separada.

Por exemplo, numa tabela Recrutamento de funcionários, um candidato Universidade nome e endereço poderão ser incluídos. Mas necessita de uma lista completa de universidades para mensagens de correio de grupo. Se Universidade informações são armazenadas na tabela candidatos, não existe nenhuma forma de lista de universidades com sem candidatos actuais. Criar uma tabela Universidades separada e ligue-o à tabela de candidatos com uma chave de código de universidade.

excepção de : respeite ao formulário normal em terceiro lugar, enquanto teoricamente desejável, nem sempre é prático. Se tiver uma tabela clientes e pretender eliminar todas as possíveis dependências interfield, tem de criar tabelas separadas para cidades, códigos postais, representantes de vendas, classes de cliente e qualquer outro factor que pode ser duplicado em múltiplos registos. Em teoria, normalização vale perseguir; no entanto, muitas tabelas pequenas podem diminuir o desempenho ou exceder ficheiros abertos e capacidades de memória.

Poderá ser possível aplicar a terceira forma normal apenas aos dados que altera frequentemente. Se permanecerem alguns campos dependentes, crie a aplicação requerem que o utilizador verificar que todos os campos relacionados quando é alterado algum.

Outros formulários de normalização

Quarta forma normal, também designado por BCNF (Boyce Codd Normal forma) e quinta forma normal existem, mas raramente são considerados na concepção prática. Disregarding estas regras pode resultar na estrutura de base de dados menos perfeita, mas não deverá afectar a funcionalidade.

1. Primeira forma normal: Não REPEATING grupos
   
   Tabelas devem ter apenas duas dimensões. Uma vez que um estudante tem várias classes, estas classes deverão ser listadas numa tabela separada. Os campos Aula1, Aula2, & Aula3 do registo acima são indicações de problemas de concepção.
   
   Folhas de cálculo utilizam frequentemente a terceira dimensão, mas tabelas não devem. Outra forma de observar este problema: com uma relação um-para-muitos, não coloque um lado e o lado do muitos na mesma tabela. Em vez disso, crie outra tabela na primeira forma normal através da eliminação do grupo de repetição (classe #), conforme é ilustrado abaixo:

          Student#   Advisor   Adv-Room    Class#
          ---------------------------------------
          1022      Jones      412       101-07
          1022      Jones      412       143-01
          1022      Jones      412       159-02
          4123      Smith      216       201-01
          4123      Smith      216       211-02
          4123      Smith      216       214-01
   					

2. Segundo forma normal: Eliminar dados REDUNDANTES
   
   Repare nos múltiplos classe # valores para cada aluno # valor na tabela acima. Classe # não está funcionalmente dependente para estudantes # (chave primária), pelo que esta relação não está no segundo formulário normal.
   
   Duas tabelas seguintes demonstram segundo formulário normal:

       Students:   Student#    Advisor   Adv-Room
                   ------------------------------
                   1022        Jones       412
                   4123        Smith       216
   
       Registration:   Student#    Class#
                       ------------------
                       1022        101-07
                       1022        143-01
                       1022        159-02
                       4123        201-01
                       4123        211-02
                       4123        214-01
   					

3. Terceira forma normal: Eliminar dados não dependentes ON KEY
   
   Do último exemplo é funcionalmente dependente o atributo de classificação do avançado-sala (número de escritório de classificação). A solução é mover esse atributo da tabela estudantes para a tabela corpo docente, conforme é ilustrado abaixo:

       Students:   Student#    Advisor
                   -------------------
                   1022        Jones
                   4123        Smith
   
       Faculty:    Name    Room    Dept
                   --------------------
                   Jones   412     42
                   Smith   216     42
   					

Para obter informações adicionais sobre como estruturar uma base de dados, clique no número de artigo existente abaixo para visualizar o artigo na base de dados de conhecimento da Microsoft: "FoxPro 2 A Developers Guide," AL. do Hamilton M. Ahlo Jr. et, páginas 220-225, livros do M & T, 1991

"Utilizar o Access para Windows, Roger Jennings, páginas 799-800, Corporation, 1993