Simplificando a normalização de banco de dados
O que é normalização de dados? A normalização de dados é um conjunto de regras para organizar os dados em um banco de dados relacional, que tornar o banco mais flexível, menos redundante de informações, reduz a inconsistência dos dados e também minimiza os custos de manutenção nesse banco, garantindo assim a integridade e a eficiência do sistema.
A normalização é dividida em diferentes etapas, como falado nas aulas aqui da DIO sobre banco de dados relacional, existem seis formas normais e as mais comuns são: Primeira Forma Normal (1NF), Segunda Forma Normal (2NF), Terceira Forma Normal (3NF).
Primeira Forma Normal (1NF)
Primeira forma normal serve para gente eliminar os objetos compostos.
E o que que é um atributo composto? Um atributo composto é aquele que você pode quebrar em diversos outros atributos menores. Vamos exemplificar usando os exemplos das aulas: Você tem no seu banco de dados, uma tabela de usuário com: Nome, email, data de nascimento e endereço.
Observe que o endereço é composto por: nome da rua, número, bairro, cidade, pais e cep. Agora você precisa fazer uma busca de quantas pessoas moram em uma determinada rua ou cidade, fica difícil saber se o atributo endereço é uma String que contêm todo o endereço.
Assim a primeira forma normal separa esses atributos, para que cada um tenha sua própria coluna, ou mesmo uma nova tabela, dependendo de como é aplicado seu banco de dados, ou a forma que você acha melhor.
Resumindo, nesta forma, cada coluna em uma tabela deve conter valores atômicos, ou seja, valores únicos e indivisíveis. Além disso, cada coluna deve ter um nome único e cada célula da tabela deve conter apenas um valor.
Segunda Forma Normal (2NF)
Para chegar na segunda forma, a tabela já precisa estar na primeira forma normal. Quando nós falamos sobre segunda forma normal, nós estamos falando de independência entre os atributos, ou seja, os atributos de cada tabela, precisam ser independentes entre si.
Resumindo, todos os atributos devem depender da sua chave primaria e não de outra coluna, se você tem uma chave primária composta essa chave precisa determinar o todo. Não podemos ter um atributo dependendo apenas de parte dessa chave primária.
Conforme exemplo acima:
Eu tenho duas chaves primeiras: func_ident e proj_numero, na qual a coluna horas depende das duas chaves, que seria então uma dependência funcional, ela depende de todas as duas chaves.
Também tenho outra dependência funcional da chave func_ident que leva apenas a func_nome, func_nome não depende da chave proj_numero, então essa coluna é dependente de parte dessa chave composta. Mesma coisa de proj_nome e proj_localizacao que dependem apenas da chave proj_numero e não de func_ident.
Para aplicar a segunda forma, seria então criada três tabelas partindo dessa primeira e deixando então de usar a primeira tabela.
A chave primária será composta por duas colunas: func_ident e proj_numero. Isso significa que a combinação dessas duas colunas será usada para identificar unicamente cada registro na tabela. Assim, aplicamos a segunda forma normal.
Terceira Forma Normal (3NF)
A Terceira Forma Normal (3NF) lida com a eliminação de dependências transitivas. Todos os atributos não-chave devem depender apenas da chave primária e não de outros atributos não-chave. Por exemplo, considere a tabela de vendas com as colunas: cod_venda, num_nota_fical, cod_vendedor, nome_vendedor, cod_produto, nome_produto.
Observando, conseguimos ver que a chave primeira seria o código da venda (cod_venda), ele leva as outras colunas, porém com o código do vendedor (cod_vendedor) eu consigo saber o nome do vendedor (nome_vendedor) e com o código do produto (cod_produto) eu consigo saber o nome do produto (nome_produto), então esses campos nome_vendedor e nome_produto não depende explicitamente da chave primaria cod_venda, podendo então serem separados em novas tabelas exclusivas para cada um, uma tabela com código e nome do vendedor e outra com código e nome do produto, deixando da tabela principal apenas as chaves estrangeiras dessas novas tabelas: cod_vendedor e cod_produto.
Conclusão
Na primeira forma normal organize os dados em tabelas com colunas(atributo) e linhas (tuplas), e certifique-se de que cada coluna contém apenas valores atômicos.
Na segunda forma normal garanta que todos os atributos não-chave dependam totalmente da chave primária inteira.
Na terceira forma normal certifique-se de que não existam dependências entre atributos não-chave; cada atributo não-chave deve depender apenas da chave primária.
Aplicando as formas normais resulta em melhor desempenho nas consultas, menor redundância de dados e maior consistência das informações armazenadas. Portanto, a normalização é uma prática fundamental para qualquer projeto de banco de dados robusto e bem estruturado.
Referencias:
Medium. O basicão de normalização de banco de dados. Disponível em: https://medium.com/@sebastiorogerio/o-basic%C3%A3o-de-normaliza%C3%A7%C3%A3o-de-banco-de-dados-12e185f1d0cf
Anomalias e Normalização. Disponivel em: http://galileu.coltec.ufmg.br/fantini/hp/CursoBD/Curso/Mysql_XX_Projetos_Parte05_Anomalia_Normalizacao.php
Aulas da Dio sobre Normalização.
Aulas da Univesp sobre Normalização.
