ACC2000: Conceitos básicos de normalização de bases de dados

Este artigo explica as noções básicas da terminologia de normalização de bases de dados para utilizadores inexperientes. A compreensão básica desta terminologia pode ser útil para a discussão do projecto de uma base de dados relacional. NOTA: A Microsoft também disponibiliza uma WebCast que explica as noções básicas de normalização de bases de dados. Para visualizar esta WebCast, visite o seguinte Web site da Microsoft: NOTA: Para visualizar estas informações para uma versão anterior do Microsoft Access, consulte o seguinte artigo na Microsoft Knowledge Base:

Descrição de normalização

Normalização é o processo de organizar dados numa base de dados. Este processo 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, através da eliminação da redundância e da dependência inconsistente.

Os dados redundantes desperdiçam espaço em disco e criam problemas de manutenção. Se é necessário alterar dados que existem em mais do que um local, esses dados têm de ser alterados exactamente do mesmo modo em todos os locais. Uma alteração de morada de um cliente é muito mais fácil de implementar se esses dados estiverem apenas armazenados na tabela Clientes e em mais nenhum local da base de dados.

O que é uma "dependência inconsistente"? Apesar de ser intuitivo para um utilizador procurar o endereço de um determinado cliente na tabela Clientes, poderá não fazer sentido procurar, nessa tabela, o salário do funcionário que trabalha com esse cliente. O salário do funcionário está relacionado com o (ou depende do) funcionário, pelo que deve ser movido para a tabela Funcionários. As dependências inconsistentes podem dificultar o acesso aos dados, visto que o caminho para localizar os dados pode estar em falta ou interrompido.

Existem algumas regras para a normalização de bases de dados. Cada regra é chamada "formula normal". Se a primeira regra é respeitada, diz-se que a base de dados está na "primeira formula normal". Se as três primeiras regras são observadas, considera-se que a base de dados está na "terceira formula normal". Apesar de ser possível existirem outros níveis de normalização, considera-se que a terceira formula normal corresponde ao nível mais alto necessário para a maior parte das aplicações.

Tal como acontece com outras regras e especificações formais, os cenários reais nem sempre permitem uma concordância exacta. De um modo geral, a normalização requer mais tabelas e alguns clientes acham este procedimento confuso. Se decidir violar uma das três primeiras regras da normalização, certifique-se de que a sua aplicação antecipa quaisquer problemas que possam ocorrer, tais como a existência de dados redundantes e dependências inconsistentes.

As descrições seguintes incluem exemplos.

Primeira formula normal

• Eliminar grupos repetitivos em tabelas individuais.
• Criar uma tabela separada para cada conjunto de dados relacionados.
• Identificar cada conjunto de dados relacionados com uma chave primária.

Não utilizar múltiplos campos numa só tabela para armazenar dados semelhantes. Por exemplo, para controlar um item de inventário que pode ser proveniente de duas origens possíveis, um registo de inventário pode conter campos para Código de fornecedor 1 e Código de fornecedor 2.

O que irá acontecer se adicionar um terceiro fornecedor? Adicionar um campo não é a resposta; requer modificações ao programa e às tabelas e não acomoda suavemente um número dinâmico de fornecedores. Em vez disso, todas as informações sobre os fornecedores devem ser colocadas numa tabela chamada Fornecedores; em seguida, o inventário deve ser ligado ao fornecedores através de uma chave de número de item ou os fornecedores devem ser ligados ao inventário através de uma chave de código de fornecedor.

Segunda formula normal

• Criar tabelas separadas para conjuntos de valores que são aplicáveis a múltiplos registos.
• Relacionar estas tabelas com uma chave externa.

Os registos só devem depender da chave primária de uma tabela (uma chave composta, se for necessário). Por exemplo, vamos tomar em consideração o endereço de um cliente num sistema contabilístico. O endereço é requerido pela tabela Clientes, mas também pelas tabelas Encomendas, Expedição, Contas a receber e Conjuntos. Em vez de armazenar o endereço do cliente sob a forma de uma entrada separada em cada uma destas tabelas, armazene-o num só local, quer seja na tabela Clientes quer numa tabela Endereços separada.

Terceira formula normal

• Eliminar campos que não dependam da chave.

Os valores existentes num registo que não fazem parte da chave desse registo não devem estar na tabela. De um modo geral, sempre que o conteúdo de um grupo de campos pode ser aplicado a mais do que um registo da tabela, deve pensar em colocar esses campos numa tabela separada.

Por exemplo, numa tabela Recrutamento de funcionários é possível incluir o nome e o endereço da universidade dos candidatos. No entanto, é necessária uma lista completa de universidades para o envio de mailings. Se as informações sobre as universidades estiverem armazenadas na tabela Candidatos, não existe nenhuma maneira de listar as universidades sem candidatos actuais. Neste caso, deve ser criada uma tabela Universidades separada e ligá-la à tabela Candidatos através de uma chave de código de universidade.

Excepção: A concordância com a terceira formula normal, apesar de ser teoricamente desejável, nem sempre é prática. Se tiver uma tabela Clientes e pretender eliminar todas as dependências possíveis entre campos, tem de criar tabelas separadas para cidades, códigos postais, representantes de vendas, classes de clientes e qualquer outro factor que possa ser duplicado em múltiplos registos. Teoricamente, a normalização é um objectivo a atingir. No entanto, a existência de muitas tabelas pequenas pode diminuir o desempenho ou exceder as capacidades de número de ficheiros abertos e de memória.

Pode ser mais prático aplicar a terceira formula normal apenas aos dados que sejam frequentemente alterados. Se permanecerem alguns campos dependentes, conceba a sua aplicação de modo a requerer que o utilizador verifique todos os campos relacionados quando apenas um campo é alterado.

Outras formulas de normalização

Existe uma quarta formula normal, também chamado BCNF (Boyce Codd Normal Form), e uma quinta formula normal, mas são raramente tidos em consideração na concepção prática de uma base de dados. O facto de estas regras serem ignoradas pode produzir uma base de dados menos perfeita mas não deve afectar o respectivo desempenho.

Normalizar uma tabela de exemplo

Estes passos demonstram o processo de normalização de uma tabela de estudantes fictícia.

1. Tabela não normalizada:
   
   
   Reduzir esta tabelaExpandir esta tabela

   1022	Chaves	412	101-07	143-01	159-02
   4123	Silva	216	201-01	211-02	214-01

2. Primeira formula normal: Eliminar os grupos repetitivos
   
   As tabelas só devem ter duas dimensões. Visto que um estudante tem várias aulas, estas aulas devem ser listadas numa tabela separada. Os campos Aula1, Aula2 e Aula3 dos registos acima apresentados são indicações de problemas de concepção da tabela.
   
   As folhas de cálculo utilizam frequentemente a terceira dimensão, mas as tabelas não o devem fazer. Outro modo de observar este problema é através de uma relação um-para-muitos, onde o lado do um e o lado do muitos não são colocados na mesma tabela. Em vez disso, crie outra tabela na Primeira formula normal através da eliminação do gripo repetitivo (N.º Aula), conforme ilustrado abaixo:
   
   
   Reduzir esta tabelaExpandir esta tabela

   1022	Chaves	412	101-07
   1022	Chaves	412	143-01
   1022	Chaves	412	159-02
   4123	Silva	216	201-01
   4123	Silva	216	211-02
   4123	Silva	216	214-01

3. Segunda formula normal: Eliminar os dados redundantes
   
   Repare nos múltiplos valores de N.º aula relativos a cada N.º Est. na tabela acima. N.º aula não é funcionalmente dependente de N.º est. (chave primária), pelo que esta relação não se enquadra na segunda formula normal.
   
   As duas tabelas seguintes demonstram a segunda formula normal:
   
   Estudantes:
   
   
   Reduzir esta tabelaExpandir esta tabela

   1022	Chaves	412
   4123	Silva	216

   
   
   Registo:
   
   
   Reduzir esta tabelaExpandir esta tabela

   1022	101-07
   1022	143-01
   1022	159-02
   4123	201-01
   4123	211-02
   4123	214-01

4. Terceira formula normal: Eliminar os dados que não dependam da chave
   
   No último exemplo, Sala cons. (o número da sala do conselheiro) é funcionalmente dependente do atributo Cons.. A solução é mover esse atributo da tabela Estudantes para a tabela Faculdade, conforme ilustrado abaixo:
   
   Estudantes:
   
   
   Reduzir esta tabelaExpandir esta tabela

   1022	Chaves
   4123	Silva

   
   
   Faculdade:
   
   
   Reduzir esta tabelaExpandir esta tabela

   Chaves	412	42
   Silva	216	42

FoxPro 2 A Developer's Guide , Hamilton M. Ahlo Jr. et al., págs. 220-225, M & T Books, 1991

Using Access for Windows , Roger Jennings, págs. 799-800, Que Corporation, 1993