Descrição das noções básicas de normalização do banco de dados

Este artigo explica a terminologia de normalização do banco de dados para iniciantes. Uma compreensão básica dessa terminologia é útil ao discutir o design de um banco de dados relacional.

Descrição da normalização

Normalização é o processo de organização de dados em um banco de dados. Isso inclui a criação de tabelas e o estabelecimento de relações entre essas tabelas de acordo com as regras projetadas para proteger os dados e tornar o banco de dados mais flexível, eliminando a redundância e a dependência inconsistente.

Dados redundantes desperdiçam espaço em disco e criam problemas de manutenção. Se os dados existentes em mais de um local devem ser alterados, eles devem ser alterados exatamente da mesma maneira em todos os locais. Uma alteração de endereço do cliente é mais fácil de implementar se esses dados forem armazenados apenas na tabela Clientes e em nenhum outro lugar no banco de dados.

O que é uma "dependência inconsistente"? Embora seja intuitivo para um usuário procurar na tabela Clientes o endereço de um determinado cliente, talvez não faça sentido procurar o salário do funcionário que chama esse cliente. O salário do funcionário está relacionado ou depende do funcionário e, portanto, deve ser movido para a tabela Funcionários. As dependências inconsistentes podem dificultar o acesso aos dados porque o caminho para encontrar os dados pode estar ausente ou quebrado.

Há algumas regras para normalização do banco de dados. Cada regra é chamada de "forma normal". Se a primeira regra for observada, diz-se que o banco de dados está na "primeira forma normal ". Se as três primeiras regras forem observadas, o banco de dados será considerado na "terceira forma normal". Embora outros níveis de normalização sejam possíveis, a terceira forma normal é considerada o nível mais alto necessário para a maioria dos aplicativos.

Assim como muitas regras e especificações formais, os cenários do mundo real nem sempre permitem a conformidade perfeita. Em geral, a normalização requer tabelas adicionais e alguns clientes acham isso complicado. Se você decidir violar uma das três primeiras regras de normalização, certifique-se de que seu aplicativo preveja qualquer problema que possa ocorrer, como dados redundantes e dependências inconsistentes.

As descrições a seguir incluem exemplos.

Primeiro formulário normal

• Eliminar grupos repetidos em tabelas individuais.
• Crie uma tabela separada para cada conjunto de dados relacionados.
• Identifique cada conjunto de dados relacionados com uma chave primária.

Não use vários campos em uma única tabela para armazenar dados semelhantes. Por exemplo, para rastrear um item de inventário que pode vir de duas fontes possíveis, um registro de inventário pode conter campos para o Código do Fornecedor 1 e o Código do Fornecedor 2.

O que acontece quando você adiciona um fornecedor terceiro? Adicionar um campo não é a resposta; isso exige modificações de programa e tabela e não acomoda facilmente um número dinâmico de fornecedores. Em vez disso, coloque todas as informações do fornecedor em uma tabela separada chamada Fornecedores e vincule o inventário a fornecedores com uma chave de número de item ou fornecedores para inventariá-los com uma chave de código de fornecedor.

Segundo formulário normal

• Crie tabelas separadas para conjuntos de valores que se aplicam a vários registros.
• Relacione essas tabelas com uma chave estrangeira.

Os registros não devem depender de nada além da chave primária de uma tabela (uma chave composta, se necessário). Por exemplo, considere o endereço de um cliente em um sistema de contabilidade. O endereço é necessário para a tabela Clientes, mas também para as tabelas Pedidos, Envio, Faturas, Contas a Receber e Coleções. Em vez de armazenar o endereço do cliente como uma entrada separada em cada uma dessas tabelas, armazene-o em um só lugar, na tabela Clientes ou em uma tabela Endereços separada.

Terceira forma normal

• Elimine campos que não dependem da chave.

Os valores em um registro que não fazem parte da chave desse registro não pertencem à tabela. Em geral, sempre que o conteúdo de um grupo de campos pode se aplicar a mais de um único registro na tabela, considere colocar esses campos em uma tabela separada.

Por exemplo, em uma tabela de Recrutamento de Funcionários, o nome da universidade e o endereço de um candidato podem ser incluídos. Mas você precisa de uma lista completa de universidades para envios de mensagens em grupo. Se as informações da universidade forem armazenadas na tabela Candidatos, não haverá como listar universidades sem candidatos atuais. Crie uma tabela de Universidades separada e vincule-a à tabela Candidatos com uma chave de código da universidade.

EXCEÇÃO: a adesão à terceira forma normal, embora teoricamente desejável, nem sempre é prática. Se você tiver uma tabela Clientes e quiser eliminar todas as possíveis dependências entre campos, deverá criar tabelas separadas para cidades, CEPs, representantes de vendas, classes de clientes e qualquer outro fator que possa ser duplicado em vários registros. Em teoria, vale a pena buscar a normalização. No entanto, muitas tabelas pequenas podem degradar o desempenho ou exceder as capacidades abertas de arquivo e memória.

Pode ser mais viável aplicar a terceira forma normal apenas aos dados que mudam com frequência. Se alguns campos dependentes permanecerem, projete seu aplicativo para exigir que o usuário verifique todos os campos relacionados quando qualquer um deles for alterado.

Outros formulários de normalização

A quarta forma normal, também chamada de BCNF (Boyce Codd Normal Form), e a quinta forma normal existem, mas raramente são consideradas no design prático. Ignorar essas regras pode resultar em não mais que um design de banco de dados perfeito, mas não deve afetar a funcionalidade.

Normalização de uma tabela de exemplo

Estas etapas demonstram o processo de normalização de uma tabela de alunos fictícios.

1. Tabela não normalizada:

   Student#	Advisor	Adv-Room	Class1	Class2	Class3
   1022	Jones	412	101-07	143-01	159-02
   4123	Smith	216	101-07	143-01	179-04

2. Primeira forma normal: sem grupos repetidos

   As tabelas devem ter apenas duas dimensões. Como um aluno tem várias classes, elas devem ser listadas em uma tabela separada. Os campos Class1, Class2 e Class3 nos registros acima são indicações de problemas de design.

   As planilhas geralmente usam a terceira dimensão, mas as tabelas não. Outra maneira de ver esse problema é com uma relação um-para-muitos, não coloque o lado único e vários lados na mesma tabela. Em vez disso, crie outra tabela na primeira forma normal eliminando o grupo repetido (Class#), conforme no seguinte exemplo:

   Student#	Advisor	Adv-Room	Class#
   1022	Jones	412	101-07
   1022	Jones	412	143-01
   1022	Jones	412	159-02
   4123	Smith	216	101-07
   4123	Smith	216	143-01
   4123	Smith	216	179-04

3. Segunda forma normal: eliminar dados redundantes

   Observe os vários valores Class# para cada valor Student# na tabela acima. Class# não depende funcionalmente de Student# (chave primária), portanto, essa relação não está na segunda forma normal.

   As tabelas a seguir demonstram a segunda forma normal:

   Alunos:

   Student#	Advisor	Adv-Room
   1022	Jones	412
   4123	Smith	216

   Registro:

   Student#	Class#
   1022	101-07
   1022	143-01
   1022	159-02
   4123	101-07
   4123	143-01
   4123	179-04

4. Terceira forma normal: eliminar dados não dependentes da chave

   No último exemplo, Adv-Room (o número do escritório do consultor) é funcionalmente dependente do atributo Advisor. A solução é mover esse atributo da tabela Alunos para a tabela Docentes, conforme mostrado abaixo:

   Alunos:

   Student#	Advisor
   1022	Jones
   4123	Smith

   Docentes:

   Nome	Room	Depto
   Jones	412	42
   Smith	216	42