Primeira Forma Normal (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 é bem simples.
Eliminar Duplicação
A primeira regra determina que não devemos duplicar dados na mesma linha de uma tabela. Dentro da comunidade de banco de dados, esse conceito é chamado de atomicidade de uma tabela. Tabelas que atendem a essa regra são consideradas atômicas. Vamos explorar esse princípio com um exemplo clássico: uma tabela dentro de um banco de dados de recursos humanos que armazena o relacionamento gerente-subordinado. Para os propósitos do 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 acompanhar essas informações, podemos criar uma tabela com os seguintes campos:
- Gerente
- Subordinado1
- Subordinado2
- Subordinado3
- Subordinado4
No entanto, lembre-se da primeira regra imposta pelo 1NF: Elimine colunas duplicadas da mesma tabela. Claramente, as colunas Subordinate1-Subordinate4 são duplicadas. Pare um pouco e pondere sobre os problemas levantados por esse cenário. Se um gerente tiver apenas um subordinado, as colunas Subordinate2-Subordinate4 serão simplesmente um espaço de armazenamento desperdiçado (uma mercadoria de banco de dados preciosa). Além disso, imagine o caso em que um gerente já tem 4 subordinados - o que acontece se ela assumir outro funcionário? Toda a estrutura da tabela exigiria modificação.
Neste ponto, uma segunda ideia brilhante geralmente ocorre aos novatos do banco de dados: Não queremos ter 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 fica aquém da marca. A coluna de subordinados ainda é duplicativa 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 nessa 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 futuras consultas.
Aqui está uma tabela que satisfaz a primeira regra do 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 a segunda regra: identifique cada linha com uma única coluna ou conjunto de colunas (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 para uma chave primária, devido ao fato de que nossas regras de negócios especificaram que cada subordinado pode ter apenas um gerente. No entanto, os dados que escolhemos armazenar em nossa tabela tornam essa solução menos que ideal. O que acontece se contratarmos outro funcionário chamado Jim? Como podemos armazenar seu relacionamento gerente-subordinado no banco de dados?
É melhor usar um identificador verdadeiramente exclusivo (como um ID de funcionário) como chave primária. Nossa mesa final ficaria assim:
- ID do gerente
- ID subordinado
Agora, nossa mesa está na primeira forma normal! Além disso, há opções para colocar seu banco de dados no Second Normal Form, bem como no Third Normal Form, se você estiver animado com uma organização ainda maior.
