O que é normalização de banco de dados?

A normalização do banco de dados é um processo de design de banco de dados que organiza os dados em estruturas de tabela específicas. Isso ajuda a melhorar a integridade dos dados, evitar anomalias de dados, minimizar a redundância de dados e melhorar o desempenho das consultas.

A normalização otimiza as tabelas em sistemas de gerenciamento de banco de dados (DBMS) para atender ao que é conhecido como formas normais: conjuntos de regras que regem como os atributos são organizados em uma tabela. Essas regras baseiam-se amplamente nas relações entre atributos (colunas), incluindo as chaves usadas para identificar linhas de forma exclusiva.

Em sua essência, a normalização de banco de dados, também conhecida como normalização de dados, ajuda empresas e instituições a organizar, consultar e manter grandes volumes de dados complexos, inter-relacionados e dinâmicos de forma mais eficaz. Embora as empresas agora gerem e armazenem dados em uma escala sem precedentes, a necessidade de normalização de banco de dados não é nova. É anterior ao armazenamento em nuvem e até mesmo à invenção dos data warehouses.

Desde a década de 1960, as corporações têm lutado para gerenciar grandes conjuntos de dados. Na década de 1970, Edgar F. Codd, matemático da IBM conhecido por seu artigo de referência Introdução aos bancos de dados relacionais, propôs que a normalização do banco de dados poderia evitar dependências "indesejáveis" entre atributos (colunas) e os problemas que podem criar.

Em outras palavras, quando os registros de dados estão relacionados entre si em uma estrutura de banco de dados, as alterações em valores únicos ou linhas em uma tabela grande e complicada podem produzir consequências não intencionais, como inconsistência e perda de dados. A normalização do banco de dados foi projetada para minimizar esses riscos.

Os benefícios da normalização do banco de dados são:

A normalização de estruturas de dados pode evitar três tipos principais de anomalias:

Anomalias de inserção: Uma anomalia de inserção ocorre quando um registro de dados não pode ser inserido em uma tabela porque faltam valores exigidos por uma ou mais colunas na tabela.

Anomalias de exclusão: uma anomalia de exclusão ocorre quando a exclusão de um registro resulta nos resultados não intencionais de dados importantes incluídos nesse registro.

Anomalias de atualização: uma anomalia de atualização ocorre quando uma instância de dados é atualizada em um local em um banco de dados, mas não em outros locais onde esse valor de dados também é armazenado, resultando na falta de consistência dos dados.

Em bancos de dados relacionais, uma chave é uma coluna ou uma coleção ordenada de colunas utilizada para identificar linhas de dados em uma tabela. As chaves nos modelos relacionais também estabelecem associações entre tabelas relacionadas. Esses recursos suportam consultas bem-sucedidas e eficientes no SQL database. As chaves que têm uma figura de destaque nas regras de normalização do banco de dados são:

• Chaves primárias
• Teclas compostas
• Chaves do candidato
• Chaves estrangeiras
• Superchaves

Uma chave primária é uma coluna ou colunas de uma tabela de banco de dados com valores que servem como identificadores exclusivos de cada linha ou registro. Por exemplo, uma coluna de ID de aluno pode ser uma chave primária em uma tabela de informações de alunos. As características definidoras das chaves primárias são a exclusão de valores nulos, não têm valores duplicados e podem consistir em colunas únicas ou em várias colunas.

Chaves que consistem em duas ou mais colunas são chamadas de chaves compostas. Quando as chaves primárias são chaves compostas, podem ser chamadas de chaves primárias compostas.

Uma chave candidata é uma coluna ou grupo de colunas que possui as características de uma chave primária, mas que não recebeu o status de chave primária.

Uma chave estrangeira de uma tabela refere-se a uma chave primária específica em outra tabela para definir um relacionamento entre essas tabelas. Quando tabelas maiores são divididas em tabelas menores durante a normalização, as chaves externas e primárias estabelecem uma associação entre as novas tabelas.

As superchaves, embora semelhantes às chaves primárias compostas, também consistem em mais colunas do que o necessário para identificar registros de forma exclusiva.

Várias restrições de normalização de banco de dados são baseadas nas relações (também conhecidas como dependências) entre chaves primárias e colunas que não são chaves primárias nem candidatas. Estes últimos são conhecidos como atributos não chave ou atributos não principais.

As relações entre atributos em bancos de dados onde um atributo (o determinante) determina o valor de outro atributo são conhecidas como dependências funcionais. Os tipos de dependências funcionais entre atributos incluem dependência parcial, dependência transitiva, dependência multivalorada e dependência de participação. Essas relações são melhor compreendidas quando discutidas no contexto de conjuntos relevantes de regras de normalização ou formas normais.

A execução da normalização em modelos de dados envolve o projeto de tabelas para se adequarem a um ou mais níveis de normalização, também conhecidos como formas normais. Os formulários comuns são:

• Primeira forma normal
• Segunda forma normal
• Terceira forma normal e forma normal de Boyce-Codd
• Quarta forma normal
• Quinta forma normal

A primeira forma normal, o critério mais básico de normalização de banco de dados, exige que um esquema de tabela de banco de dados inclua uma chave primária, excluindo a repetição entre colunas. Para ser mais específico, uma tabela na primeira forma normal não deve conter campos com matrizes de valores, como uma única célula com três nomes diferentes, nem conter grupos repetidos, que são colunas diferentes que armazenam o mesmo tipo de dado.

Para entender melhor a primeira forma normal, vamos usar o seguinte conjunto de colunas como exemplo:¹

As colunas compõem uma tabela de um grupo de pais, incluindo seus nomes, aniversários, aniversários de casamento, e-mails e nomes de crianças.

Essa tabela viola a primeira forma normal porque contém três colunas separadas que armazenam o mesmo tipo de informação: nomes de crianças. Nesse caso em particular, a estrutura da tabela pode abrir a porta para erros de inserção. Por exemplo, no mundo real, muitos pais têm menos de três filhos.

Em nossa tabela de exemplo não é possível adicionar os registros desses pais à tabela. Além disso, consultar o nome de uma criança nessa tabela seria ineficiente, exigindo dados de pesquisa em três colunas diferentes em cada linha.

Para obter a primeira forma normal dos dados na tabela, é necessário separar a tabela original em duas. Uma tabela incluiria a maioria dos atributos da tabela original, enquanto a outra se concentraria nos filhos.

TABELA 1

TABELA 2

rec_num         child_name

Neste exemplo, as novas tabelas permanecem vinculadas por meio da coluna "rec_num", que é a chave primária na Tabela 1 e é referenciada pela coluna "rec_num" da Tabela 2, que serve como uma chave estrangeira.

Embora atender à primeira forma normal possa não reduzir os dados redundantes (os valores “rec_num” aparecerão em várias linhas da Tabela 2 quando os pais tiverem mais de um filho), a eliminação de grupos repetidos pode simplificar as consultas.

Na segunda forma normal, nenhum atributo que não for chave tem dependência parcial da chave primária na tabela. Em outras palavras, se uma chave primária for uma chave composta, o atributo que não for chave deverá depender de cada coluna nessa chave composta.

Por exemplo, considere uma tabela de inventário que possui registros de quantidades de peças específicas armazenadas em armazéns específicos. A figura a seguir mostra os atributos da entidade de inventário.²

Neste exemplo, as colunas “part” e “warehouse” formam uma chave primária composta. Entretanto, o atributo “warehouse_address” depende apenas do valor de “warehouse”, então a tabela viola a segunda forma normal.

Essa tabela também é propensa à redundância de dados, com o valor para warehouse_address listado cada vez que um registro de uma peça do mesmo warehouse aparece na tabela. Isso aumenta o risco de erros de atualização caso o endereço seja alterado em uma linha e não nas demais. Um erro de exclusão também pode ocorrer se qualquer armazém parar de armazenar peças—se os registros dessas peças forem excluídos, o endereço do armazém também seria excluído.

Para satisfazer a segunda forma normal e reduzir a probabilidade de erros, os dados podem ser distribuídos entre duas novas tabelas:

TABELA 1

TABELA 2

armazém endereço do armazém

Uma tabela na terceira forma normal satisfaz tanto a primeira quanto a segunda forma normal, ao mesmo tempo em que evita situações em que atributos não chave dependem de outros atributos não chave em vez de chaves primárias. Quando atributos não chave dependem de outros atributos não chave, isso é conhecido como dependência transitiva — uma violação da terceira forma normal.

Considere a seguinte tabela com informações sobre os funcionários:³

Nesta tabela, a chave primária é a coluna "emp_num". No entanto, a coluna “dept_name” depende da coluna “dept_num”, um atributo que não é chave. Portanto a tabela não atende à terceira forma normal e aumenta o risco de erros, como anomalias de atualização — se um nome de departamento, como “sistema de fabricação”, fosse alterado, ele teria que ser atualizado em mais de uma linha no esquema atual da tabela.

A organização dos dados na terceira forma normal em um banco de dados normalizado pode evitar esses erros. Nesse caso, o processo envolveria a estruturação dos dados em três tabelas separadas: EMPLOYEE, DEPARTMENT e EMPLOYEE_DEPARTMENT ⁴

Tabela EMPLOYEE

Tabela DEPARTMENT

Tabela EMPLOYEE_DEPARTMENT

A Forma Normal de Boyce-Codd, ou BCNF, é uma forma normal considerada uma versão mais rigorosa ou mais forte da terceira forma normal. A BCNF exige o uso de superchaves.

Uma tabela está na quarta forma normal se não tiver dependências de vários valores. As dependências de múltiplos valores ocorrem quando os valores de duas ou mais colunas são independentes uns dos outros e dependem apenas da chave primária.

Um exemplo comumente citado em tutoriais centra-se em tabelas de funcionários listando habilidades e idiomas. Um funcionário pode ter várias habilidades e falar vários idiomas. Há duas relações: uma entre funcionários e habilidades e outra entre funcionários e idiomas.

Uma tabela não está na quarta forma normal se representar ambos os relacionamentos. A conversão dos dados para o quarto formato normal exigiria sua estruturação em duas tabelas, uma para habilidades dos funcionários e outra para idiomas.

Comumente considerado o nível mais alto de normalização, a quinta forma normal é um critério centrado na dependência de junção. Na dependência de junção, depois que uma tabela é dividida em tabelas menores, é possível reconstituir a tabela original reunindo as novas tabelas novamente, tudo sem perder nenhum dado nem criar acidentalmente novas linhas de dados. É comparável a um quebra-cabeça completo que, quando dividido, pode ser reunido em sua forma original.

Na quinta forma normal, uma tabela deve ser dividida em tabelas menores somente quando a dependência de junção for possível. No entanto, se as tentativas de reconstituir a tabela original a partir de tabelas menores levarem involuntariamente à criação de uma tabela ligeiramente diferente, a decomposição da tabela original não deverá ocorrer. Voltando à nossa analogia do quebra-cabeça, seria como montar um quebra-cabeça novamente, apenas para descobrir que uma peça está faltando ou que uma peça extra apareceu.

Apesar de todos os benefícios, a normalização do banco de dados traz vantagens e desvantagens. Por exemplo, antes da normalização, um usuário que busca dados específicos talvez precise consultar somente uma tabela. No entanto, se um banco de dados tiver mais tabelas após uma normalização, o usuário poderá ter que consultar várias tabelas, o que pode ser um processo mais lento e mais caro.

Além disso, mesmo que a normalização simplifique as tabelas individuais, pode aumentar a complexidade do banco de dados em geral, exigindo experiência significativa por parte dos designers e administradores de banco de dados para garantir a implementação adequada.