Você já ouviu falar nas 5 Regras de Normalização dos Bancos de Dados Relacionais?
A normalização de bancos de dados é um processo sistemático que organiza os dados de forma a minimizar redundâncias e melhorar a integridade dos dados. Esse processo segue um conjunto de regras conhecidas como formas normais, desenvolvidas por Edgar F. Codd, o criador do modelo relacional.
Mas você deve estar se perguntando o por quê devemos utilizar tais regras em nos banco de dados.
Então te dou 5 bons motivos:
- Redução de Redundâncias: Evita a repetição desnecessária de dados e consequentemente otimiza o espaço de armazenamento.
- Eliminação de Anomalias: Minimiza inconsistências em inserções, atualizações e deleções.
- Melhor Manutenção: Torna o banco de dados mais fácil de atualizar e escalar.
- Eficiência de Armazenamento: Reduz o uso de espaço, armazenando dados de forma mais compacta.
- Integridade dos Dados: Garante a consistência e precisão das informações.
A normalização é um processo essencial, especialmente em projetos onde a integridade e o desempenho do banco de dados são fundamentais. Cá entre nós, esses atributos são fundamentais em qualquer projeto.
Neste artigo, explicaremos as cinco primeiras formas normais, acompanhadas de exemplos práticos.
1ª Forma Normal (1FN)
A primeira forma normal exige que uma tabela:
- Tenha colunas atômicas (ou indivisíveis).
- Não contenha grupos repetidos ou colunas que armazenem listas de valores.
Exemplo: Considere a tabela abaixo:
| id_cliente | nome | telefones |
|---|---|---|
| 1 | João Silva | 1234, 5678 |
| 2 | Maria Santos | 9876 |
A coluna "telefones" viola a 1FN porque armazena múltiplos valores em uma única célula. Para corrigir, dividimos os dados:
| id_cliente | nome | telefone |
|---|---|---|
| 1 | João Silva | 1234 |
| 1 | João Silva | 5678 |
| 2 | Maria Santos | 9876 |
Em suma, a primeira forma visa eliminar dados repetidos, garantindo que cada coluna contenha apenas valores indivisíveis e que cada linha seja única.
2ª Forma Normal (2FN)
A segunda forma normal requer que a tabela:
- Esteja na 1FN.
- Não contenha dependências parciais, ou seja, cada atributo não-chave deve depender da chave primária inteira.
Exemplo: Considere uma tabela que armazena informações de pedidos:
| id_pedido | id_produto | nome_produto | quantidade | preco_unitario |
|---|---|---|---|---|
| 1 | A1 | Caneta | 10 | 1.50 |
| 1 | A2 | Caderno | 5 | 10.00 |
Aqui, "nome_produto" e "preco_unitario" dependem apenas de "id_produto", não de "id_pedido". Para corrigir, dividimos a tabela em duas:
Tabela Pedidos:
| id_pedido | id_produto | quantidade |
|---|---|---|
| 1 | A1 | 10 |
| 1 | A2 | 5 |
Tabela Produtos:
| id_produto | nome_produto | preco_unitario |
|---|---|---|
| A1 | Caneta | 1.50 |
| A2 | Caderno | 10.00 |
Com a remoção das dependências parciais, garantimos que todos os atributos não-chave (secundários), dependam apenas da key ou chave, evitando redundância associadas às dependências parciais.
3ª Forma Normal (3FN)
A terceira forma normal requer que a tabela:
- Esteja na 2FN.
- Não contenha dependências transitivas, ou seja, nenhum atributo não-chave deve depender de outro atributo não-chave.
Exemplo: Considere uma tabela de vendas:
| id_venda | id_cliente | nome_cliente | cidade |
|---|---|---|---|
| 1 | 101 | João Silva | São Paulo |
| 2 | 102 | Maria Santos | Rio de Janeiro |
Aqui, "nome_cliente" e "cidade" dependem de "id_cliente", não de "id_venda". Para corrigir, dividimos em duas tabelas:
Tabela Vendas:
| id_venda | id_cliente |
|---|---|
| 1 | 101 |
| 2 | 102 |
Tabela Clientes:
| id_cliente | nome_cliente | cidade |
|---|---|---|
| 101 | João Silva | São Paulo |
| 102 | Maria Santos | Rio de Janeiro |
A remoção das dependências transitivas visa minimizar ainda mais as redundâncias, tornando as tabelas mais simples de compreender e manter.
4ª Forma Normal (4FN)
A quarta forma normal trata das dependências multivaloradas. Ela exige que:
- Esteja na 3FN.
- Não existam dependências multivaloradas, ou seja, cada fato independente deve estar representado em sua própria tabela.
Exemplo: Considere uma tabela que armazena habilidades de empregados e idiomas falados:
| id_empregado | habilidade | idioma |
|---|---|---|
| 1 | Programar | Inglês |
| 1 | Programar | Espanhol |
| 1 | Design | Inglês |
| 1 | Design | Espanhol |
Aqui, habilidades e idiomas são informações independentes. Para corrigir, dividimos em duas tabelas:
Tabela Habilidades:
| id_empregado | habilidade |
|---|---|
| 1 | Programar |
| 1 | Design |
Tabela Idiomas:
| id_empregado | idioma |
|---|---|
| 1 | Inglês |
| 1 | Espanhol |
Implementando a quarta forma, evitamos combinações redundantes de dados e organizamos as tabelas com relacionamentos complexos de forma objetiva.
5ª Forma Normal (5FN)
A quinta forma normal, também conhecida como forma normal de projeção e junção, exige que:
- Esteja na 4FN.
- Nenhum dado possa ser reconstruído a partir de tabelas menores de forma que a divisão cause perda de informação.
Exemplo: Considere uma tabela de fornecedores, produtos e clientes:
| id_fornecedor | id_produto | id_cliente |
|---|---|---|
| F1 | P1 | C1 |
| F1 | P1 | C2 |
| F2 | P1 | C1 |
Se houver uma relação direta entre fornecedores, produtos e clientes, dividir essas informações em tabelas menores pode gerar perda de dados. A 5FN assegura que todos os dados só sejam separados se cada fato puder ser representado independentemente sem ambiguidade. A quinta forma assegura que os dados sejam armazenados de forma modular e que todas as suas dependências sejam explícitas.
Conclusão
A normalização melhora a organização dos dados e a integridade do banco, embora possa aumentar a complexidade das consultas. O uso adequado depende do contexto e do equilíbrio entre desempenho e consistência.
Agora que você já conhece as 5FN e seus benefícios, que tal implementá-las?
Referências:
- Codd, E. F. "A Relational Model of Data for Large Shared Data Banks" (1970).
- Silberschatz, A., Korth, H., & Sudarshan, S. "Database System Concepts".
- Date, C. J. "An Introduction to Database Systems".
Top comments (0)