Skip to content

Normalizando seu banco de dados: Primeira forma normal (1FN)

8 de maio de 2021

First Normal Form (1NF) define as regras básicas para um banco de dados organizado:

  • Elimine colunas duplicadas da mesma tabela.
  • Crie tabelas separadas para cada grupo de dados relacionados e identifique cada linha com uma coluna exclusiva (a chave primária).

O que essas regras significam ao contemplar o design prático de um banco de dados? Na verdade, é muito simples.

Elimine Duplicação

A primeira regra determina que não devemos duplicar dados na mesma linha de uma tabela. Na comunidade de banco de dados, esse conceito é conhecido como atomicidade de uma tabela. As tabelas que obedecem a esta regra são consideradas atômicas. Vamos explorar esse princípio com um exemplo clássico: uma tabela em um banco de dados de recursos humanos que armazena o relacionamento gerente-subordinado. Para fins de nosso exemplo, imporemos a regra de negócios de que cada gerente pode ter um ou mais subordinados, enquanto cada subordinado pode ter apenas um gerente. Intuitivamente, ao criar uma lista ou planilha para rastrear essas informações, podemos criar uma tabela com os seguintes campos:

  • Gerente
  • Subordinado1
  • Subordinado 2
  • Subordinado 3
  • Subordinado 4

No entanto, lembre-se da primeira regra imposta por 1NF: Elimine colunas duplicadas da mesma tabela. Claramente, as colunas Subordinate1-Subordinate4 são duplicadas. Reserve um momento e pondere os problemas levantados por este cenário. Se um gerente tem apenas um subordinado, as colunas Subordinate2-Subordinate4 são simplesmente espaço de armazenamento desperdiçado (uma mercadoria preciosa do banco de dados). Além disso, imagine o caso em que um gerente já tem 4 subordinados – o que acontece se ele contratar outro funcionário? Toda a estrutura da tabela exigiria modificação. Nesse ponto, uma segunda ideia brilhante geralmente ocorre para os novatos em banco de dados: não queremos mais de uma coluna e queremos permitir uma quantidade flexível de armazenamento de dados. Vamos tentar algo assim:

  • Gerente
  • Subordinados

E o campo Subordinados conteria várias entradas no formulário “Mary, Bill, Joe”. Esta solução está mais próxima, mas também está aquém do alvo. A coluna subordinada ainda é duplicada e não atômica. O que acontece quando precisamos adicionar ou remover um subordinado? Precisamos ler e escrever todo o conteúdo da tabela. Isso não é grande coisa nesta situação, mas e se um gerente tivesse cem funcionários? Além disso, complica o processo de seleção de dados do banco de dados em consultas futuras. Aqui está uma tabela que satisfaz a primeira regra de 1NF:

  • Gerente
  • Subordinar

Nesse caso, cada subordinado tem uma única entrada, mas os gerentes podem ter várias entradas.

Identifique a chave primária

Agora, e quanto à segunda regra: identifique cada linha com uma coluna ou conjunto de colunas exclusivo (a chave primária). Você pode dar uma olhada na tabela acima e sugerir o uso da coluna subordinada como uma chave primária. Na verdade, a coluna subordinada é uma boa candidata a uma chave primária devido ao fato de que nossas regras de negócios especificam que cada subordinado pode ter apenas um gerente. No entanto, os dados que escolhemos armazenar em nossa tabela tornam essa solução menos do que ideal. O que acontecerá se contratarmos outro funcionário chamado Jim? Como armazenamos seu relacionamento gerente-subordinado no banco de dados? É melhor usar um identificador verdadeiramente único (como um ID de funcionário) como chave primária. Nossa mesa final seria assim:

  • ID de gerente
  • ID subordinado

Agora, nossa mesa está na primeira forma normal! Além disso, existem opções para colocar seu banco de dados na segunda forma normal, bem como na terceira forma normal, se você estiver animado com ainda mais organização.