Descrição das noções básicas de normalização da base de dados

Este artigo explica a terminologia de normalização de bases de dados para principiantes. É útil ter uma compreensão básica desta terminologia na discussão da estrutura de uma base de dados relacional.

Descrição da normalização

A normalização é o processo de organização de dados numa base de dados. Inclui a criação de tabelas e o estabelecimento de relações entre essas tabelas de acordo com regras concebidas para proteger os dados e tornar a base de dados mais flexível, eliminando redundância e dependência inconsistente.

Os dados redundantes ocupam espaço em disco e criam problemas de manutenção. Se os dados existentes em mais do que um local precisarem de ser alterados, os dados têm de ser alterados exatamente da mesma forma em todas as localizações. 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 na base de dados.

O que é uma "dependência inconsistente"? Embora seja intuitivo que um utilizador procure na tabela Clientes o endereço de um determinado cliente, pode não fazer sentido procurar o salário do colaborador que chama esse cliente. O salário do empregado está relacionado com, ou dependente do empregado, pelo que deve ser movido para a tabela Empregados. As dependências inconsistentes podem dificultar o acesso aos dados porque o caminho para encontrar os dados pode estar em falta ou pode estar danificado.

Existem algumas regras para a normalização de bases de dados. Cada regra é denominada "formulário normal". Se a primeira regra for observada, diz-se que a base de dados está na "primeira forma normal". Se forem observadas as três primeiras regras, considera-se que a base de dados está na "terceira forma normal". Embora sejam possíveis outros níveis de normalização, a terceira forma normal é considerada o nível mais elevado necessário para a maioria das aplicações.

Tal como acontece com muitas regras e especificações formais, os cenários do mundo real nem sempre permitem uma conformidade perfeita. Em geral, a normalização requer tabelas adicionais e alguns clientes consideram isto complicado. Se optar por violar uma das primeiras três regras de normalização, certifique-se de que a sua aplicação prevê quaisquer problemas que possam ocorrer, como dados redundantes e dependências inconsistentes.

As descrições seguintes incluem exemplos.

Primeira forma normal

  • Elimine 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 utilize vários campos numa única tabela para armazenar dados semelhantes. Por exemplo, para seguir um item de inventário que possa ter duas origens possíveis, um registo de inventário pode conter campos para o Código do Fornecedor 1 e o Código do Fornecedor 2.

O que acontece quando adiciona um terceiro fornecedor? Adicionar um campo não é a resposta; requer modificações de programas e tabelas e não acomoda sem problemas um número dinâmico de fornecedores. Em vez disso, coloque todas as informações dos fornecedores numa tabela separada chamada Fornecedores e, em seguida, ligue o inventário aos fornecedores com uma chave de número de item ou os fornecedores ao inventário com uma chave de código de fornecedor.

Segunda forma normal

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

Os registos 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 num sistema de contabilidade. O endereço é necessário pela tabela Clientes, mas também pelas tabelas Encomendas, Envio, Faturas, Contas A receber e Coleções. Em vez de armazenar o endereço do cliente como uma entrada separada em cada uma destas tabelas, armazene-o num único local, quer seja na tabela Clientes ou numa tabela Endereços separada.

Terceira forma normal

  • Elimine campos que não dependem da chave.

Os valores num registo que não fazem parte da chave desse registo não pertencem à tabela. Em geral, sempre que os conteúdos de um grupo de campos possam ser aplicados a mais do que um único registo na tabela, considere colocar esses campos numa tabela separada.

Por exemplo, numa tabela de Recrutamento de Empregados, pode ser incluído o nome e o endereço da universidade de um candidato. Mas precisa de uma lista completa de universidades para enviar correio para grupos. Se as informações sobre a universidade forem armazenadas na tabela Candidatos, não há forma de listar universidades sem candidatos atuais. Crie uma tabela Universidades separada e ligue-a à tabela Candidatos com uma chave de código de universidade.

EXCEÇÃO: aderir à terceira forma normal, embora teoricamente desejável, nem sempre é prático. Se tiver uma tabela Clientes e pretender eliminar todas as dependências entre campos possíveis, deverá criar tabelas separadas para cidades, códigos postais, representantes de vendas, classes de clientes e qualquer outro fator que possa ser duplicado em múltiplos registos. Em teoria, vale a pena prosseguir a normalização. No entanto, muitas tabelas pequenas podem afetar o desempenho ou exceder as capacidades de ficheiros abertos e de memória.

Poderá ser mais viável aplicar a terceira forma normal apenas aos dados que são alterados frequentemente. Se forem mantidos alguns campos dependentes, programe a sua aplicação para requerer que o utilizador verifique todos os campos relacionados quando um deles for alterado.

Outras formas de normalização

A quarta forma normal, também denominada Boyce-Codd Formulário Normal (BCNF), e a quinta forma normal existem, mas raramente são consideradas em design prático. Ignorar estas regras pode resultar numa estrutura de base de dados menos do que perfeita, mas não deve afetar a funcionalidade.

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:

    Estudante# Assistente Adv-Room Turma1 Turma2 Turma3
    1022 Jonas 412 101-07 143-01 159-02
    4123 Silva 216 101-07 143-01 179-04
  2. Primeira forma normal: Sem grupos de repetição

    As tabelas devem ter apenas duas dimensões. Uma vez que um estudante tem várias turmas, estas turmas deverão estar listadas numa tabela separada. Os campos Turma1, Turma2 e Turma3 nos registos acima são indicações de problemas de estrutura.

    Muitas vezes, as folhas de cálculo utilizam a terceira dimensão, mas as tabelas não devem. Outra forma de ver este problema é com uma relação um-para-muitos, não coloque o lado um e os muitos lados na mesma tabela. Em vez disso, crie outra tabela na primeira forma normal ao eliminar o grupo de repetição (Classe#), conforme mostrado no exemplo seguinte:

    Estudante# Assistente Adv-Room Turma#
    1022 Jonas 412 101-07
    1022 Jonas 412 143-01
    1022 Jonas 412 159-02
    4123 Silva 216 101-07
    4123 Silva 216 143-01
    4123 Silva 216 179-04
  3. Segunda forma normal: Eliminar dados redundantes

    Tenha em atenção os múltiplos valores class# para cada valor de Student# na tabela acima. A classe# não depende funcionalmente de Student# (chave primária), pelo que esta relação não está na segunda forma normal.

    As tabelas seguintes demonstram a segunda forma normal:

    Estudantes:

    Estudante# Assistente Adv-Room
    1022 Jonas 412
    4123 Silva 216

    Registo:

    Estudante# Turma#
    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 de chave

    No último exemplo, o Adv-Room (o número do escritório do assistente) está funcionalmente dependente do atributo Assistente. A solução é mover esse atributo da tabela Estudantes para a tabela Corpo Docente, conforme apresentado abaixo:

    Estudantes:

    Estudante# Assistente
    1022 Jonas
    4123 Silva

    Corpo Docente:

    Name Sala Dept
    Jonas 412 42
    Silva 216 42