Organizando um banco de dados usando as formas normais

A normalização de banco de dados é o processo de organizar um banco de dados relacional de acordo com uma série de formas normais para reduzir a redundância de dados e melhorar a integridade dos dados.

As regras de normalização foram propostas pelo cientista da computação britânico Edgar F. Codd como parte de seu modelo relacional. O objetivo principal da primeira forma normal (1NF) definida por Codd em 1970 era permitir que os dados fossem consultados e manipulados usando uma "sub-linguagem universal de dados" baseada na lógica de primeira ordem, como a linguagem SQL.

Além da 1NF, existem outras formas normais que são usadas para alcançar diferentes níveis de organização e eficiência no banco de dados. As principais formas normais são:

Primeira Forma Normal (1NF): Elimina grupos repetitivos e garante que cada valor em uma tabela seja atômico.
Segunda Forma Normal (2NF): Elimina dependências parciais e garante que todos os atributos de uma tabela dependam totalmente da chave primária.
Terceira Forma Normal (3NF): Elimina dependências transitivas, garantindo que os atributos não chave não dependam uns dos outros.
Quarta Forma Normal (4NF) e além: Lidam com dependências multivaloradas e outras complexidades para alcançar maior eficiência e organização.

A normalização de banco de dados tem vários objetivos, incluindo:

Livrar a coleção de relações de dependências indesejáveis de inserção, atualização e exclusão.
Reduzir a necessidade de reestruturar a coleção de relações quando novos tipos de dados são introduzidos, aumentando assim a vida útil dos programas de aplicativos.
Tornar o modelo relacional mais informativo para os usuários.
Tornar a coleção de relações neutra em relação às estatísticas de consulta, pois essas estatísticas podem mudar ao longo do tempo.

A normalização é realizada aplicando regras formais de forma sintética (criando um novo design de banco de dados) ou por meio da decomposição (melhorando um design de banco de dados existente).

A normalização de banco de dados é essencial para evitar anomalias, como inserções, atualizações e exclusões indesejáveis nos dados do banco de dados, garantindo a integridade, eficiência e consistência dos dados. É uma prática importante para garantir que os bancos de dados sejam projetados de forma otimizada e confiável.

Agora vamos ver alguns exemplos dessas formas normais de construir um banco de dados.

1a FORMA NORMAL

A primeira forma normal (1NF) é o primeiro nível de normalização e possui os seguintes critérios:

Cada célula na tabela deve conter apenas um valor (atomicidade).
A tabela deve ter uma chave primária para identificação única de cada registro.
Não pode haver duplicação de linhas ou colunas.
Cada coluna deve ter apenas um valor para cada registro na tabela.

Um exemplo de uma tabela que atende aos critérios da 1NF seria uma tabela de alunos de uma escola, com as seguintes colunas: ID do aluno (chave primária), nome do aluno, data de nascimento, endereço e número de telefone. Cada aluno teria uma entrada única na tabela, identificado pelo seu ID, e todas as informações seriam armazenadas em células separadas, sem repetições.

Suponha que tenhamos a seguinte tabela representando os alunos de uma escola na primeira forma normal (1NF):

Nessa tabela, cada registro representa um aluno diferente, identificado pelo seu ID único. Cada coluna contém apenas um valor para cada registro. Entretanto caso o aluno tivesse mais de um telefone, estaríamos violando a regra de atomicidade (apenas 1 valor) para a célula, como esta seria necessário inserir o 2o telefone usando uma / ou | para separar o números, o que torna mais complicado operar sobre estas tabelas, neste caso o ideal seria criarmos uma tabela AlunoTelefone, usando como chave estrangeira o id do aluno, logo teríamos as tabelas da seguinte forma:

2a FORMA NORMAL

Considere agora as seguintes tabelas

TABELA DE VENDAS:

TABELA DE PRODUTOS:

Nesse exemplo, temos uma tabela de "Vendas" que registra os pedidos realizados, com informações sobre os produtos, quantidades, valores unitários e subtotal de cada item. Também temos uma tabela "Produtos" que contém informações detalhadas sobre cada produto, como a descrição.

Analisando a tabela de "Vendas", percebemos que o atributo "Produto" não é completamente dependente da chave primária "N_pedido". O nome do produto está repetido em diferentes linhas, o que é uma indicação de que a tabela não está na Segunda Forma Normal (2FN).

Para normalizar essa tabela, precisamos criar uma nova tabela para armazenar as informações sobre os produtos, evitando redundância de dados. Vamos chamar essa nova tabela de "ItensVenda".

TABELA ITENS VENDA:

Agora, na tabela "Vendas", mantemos apenas as informações sobre o pedido, como o número do pedido e outros detalhes específicos do pedido que não se relacionam diretamente com os produtos.

TABELA VENDAs (após normalização):

Com essa reorganização, agora temos a tabela "ItensVenda" que armazena apenas os detalhes dos itens vendidos, evitando a repetição do nome do produto. Isso atende à Segunda Forma Normal (2FN) e evita anomalias na manutenção dos dados, como a necessidade de alterar em várias linhas caso haja mudanças nos nomes dos produtos.

A normalização do banco de dados é importante para garantir a integridade dos dados, evitar redundâncias e inconsistências, e facilitar a manipulação dos dados de forma eficiente.

Lembre-se de que a normalização é um processo contínuo e pode haver outras formas normais, como a Terceira Forma Normal (3FN), que devem ser aplicadas em cenários mais complexos.

3a FORMA NORMAL

Para exemplificar a Terceira Forma Normal (3FN), vamos utilizar uma tabela com dados de funcionários e seus departamentos em uma empresa fictícia:

TABELA FUNCIONÁRIO:

Nesta tabela, temos informações sobre os funcionários, como seu ID, nome e cargo, bem como informações sobre o departamento ao qual estão vinculados, incluindo o ID, nome e localização do departamento.

Agora, para atender à Terceira Forma Normal (3FN), devemos remover as colunas que possuam valores que podem ser obtidos a partir da combinação de valores de outras colunas na mesma tabela.

Nesse caso, podemos identificar que as colunas "Nome_Departamento" e "Localizacao_Departamento" são funcionalmente dependentes do atributo "ID_Departamento". Ou seja, o nome e a localização do departamento podem ser obtidos a partir do ID do departamento.

Para alcançar a 3FN, devemos criar uma nova tabela para armazenar as informações sobre os departamentos separadamente, removendo essas informações da tabela "Funcionario". Além disso, precisamos adicionar uma chave primária à nova tabela "Departamento".

TABELA DEPARTAMENTO:

e tabela funcionário após a normalização:

Dessa forma, alcançamos a Terceira Forma Normal (3FN). A tabela "Funcionario" agora não possui informações redundantes sobre o nome e a localização do departamento, pois esses detalhes estão armazenados na tabela "Departamento" e são referenciados pelo ID do departamento na tabela "Funcionario". Isso ajuda a evitar a redundância de dados e a garantir a consistência e a integridade das informações no banco de dados.

Finalmente, a quarta forma normal (4FN) é uma etapa adicional de normalização utilizada em bancos de dados para eliminar problemas relacionados a dependências multivaloradas. Essa forma normal foi introduzida por Ronald Fagin em 1977 e surge após a forma normal de Boyce-Codd (BCNF). Enquanto as formas normais de segunda e terceira ordem, assim como a BCNF, lidam com dependências funcionais, a 4FN aborda um tipo mais geral de dependência conhecida como dependência multivalorada.

Uma tabela está na quarta forma normal (4FN) somente se, para cada uma de suas dependências multivaloradas não triviais X -> Y, X for uma superchave, ou seja, X é uma chave candidata ou um superset dela. Uma dependência multivalorada ocorre quando, para um conjunto de colunas X, houver múltiplas ocorrências de valores em outra coluna Y, independentemente dos valores de uma terceira coluna Z.

Por exemplo, considerando uma tabela que relaciona pizzarias com variedades de pizzas que entregam em diferentes áreas, pode haver uma dependência multivalorada entre a pizzaria, a variedade de pizza e a área de entrega, indicando que uma determinada pizzaria oferece todas as variedades de pizza em todas as áreas que atende. Nesse caso, a presença da coluna de área não acrescenta informações úteis para limitar os possíveis valores da variedade de pizza.

É importante ressaltar que a 4FN nem sempre precisa ser aplicada, pois nem todas as situações geram problemas com esse tipo de dependência. A decisão de aplicá-la dependerá das necessidades específicas do banco de dados e do modelo de negócio.

Dessa forma, a 4FN é uma etapa adicional de normalização que visa eliminar redundâncias e garantir maior integridade e eficiência nas tabelas de banco de dados que possuem dependências multivaloradas. Sua aplicação pode ser relevante em alguns contextos específicos, especialmente quando se lida com dados complexos e relacionamentos entre entidades.