Examinamos vários aspectos da normalização de uma tabela de banco de dados. Primeiro, discutimos os princípios básicos da normalização do banco de dados. Na última vez, exploramos os requisitos básicos estabelecidos pela primeira forma normal (1NF). Agora, vamos continuar nossa jornada e cobrir os princípios da segunda forma normal (2NF).
Os requisitos gerais do 2NF
- Remova subconjuntos de dados que se aplicam a várias linhas de uma tabela e coloque-os em tabelas separadas.
- Crie relacionamentos entre essas novas tabelas e seus predecessores através do uso de chaves estrangeiras.
Essas regras podem ser resumidas em uma declaração simples: 2NF tenta reduzir a quantidade de dados redundantes em uma tabela, extraindo-a, colocando-a em nova (s) tabela (s) e criando relacionamentos entre essas tabelas.
Vamos ver um exemplo. Imagine uma loja online que mantém as informações do cliente em um banco de dados. Eles podem ter uma única tabela chamada Customers com os seguintes elementos:
- CustNum
- Primeiro nome
- Último nome
- Endereço
- Cidade
- Estado
- fecho eclair
Uma breve olhada nesta tabela revela uma pequena quantidade de dados redundantes. Estamos armazenando as entradas "Sea Cliff, NY 11579" e "Miami, FL 33157" duas vezes cada. Agora, isso pode não parecer muito armazenamento adicional em nosso exemplo simples, mas imagine o espaço desperdiçado se tivéssemos milhares de linhas em nossa tabela. Além disso, se o código postal do Sea Cliff fosse alterado, precisaríamos fazer essa alteração em muitos lugares em todo o banco de dados.
Em uma estrutura de banco de dados compatível com 2NF, essa informação redundante é extraída e armazenada em uma tabela separada. Nossa nova tabela (vamos chamá-lo ZIPs) pode ter os seguintes campos:
- fecho eclair
- Cidade
- Estado
Se quisermos ser super eficientes, podemos até preencher essa tabela com antecedência - a agência postal fornece um diretório de todos os códigos postais válidos e seus relacionamentos cidade / estado. Certamente, você encontrou uma situação em que esse tipo de banco de dados foi utilizado. Alguém que recebesse um pedido poderia ter solicitado primeiro o seu código postal e, em seguida, conhecer a cidade e o estado de onde você estava ligando. Esse tipo de disposição reduz o erro do operador e aumenta a eficiência.
Agora que removemos os dados duplicados da tabela Clientes, satisfizemos a primeira regra do segundo formulário normal. Ainda precisamos usar uma chave estrangeira para unir as duas tabelas. Usaremos o código postal (a chave primária da tabela ZIPs) para criar esse relacionamento. Aqui está nossa nova tabela de clientes:
- CustNum
- Primeiro nome
- Último nome
- Endereço
- fecho eclair
Agora minimizamos a quantidade de informações redundantes armazenadas no banco de dados e nossa estrutura está na segunda forma normal.
