Normalização do banco de dados

Normalização de banco de dados ou normalização de banco de dados (ver diferenças ortográficas) é o processo de estruturar um banco de dados relacional de acordo com uma série de chamados formas normais para reduzir a redundância de dados e melhorar a integridade dos dados. Foi proposto pela primeira vez pelo cientista da computação britânico Edgar F. Codd como parte de seu modelo relacional.

A normalização envolve a organização das colunas (atributos) e tabelas (relações) de um banco de dados para garantir que suas dependências sejam devidamente aplicadas pelas restrições de integridade do banco de dados. Isso é realizado aplicando algumas regras formais por um processo de síntese (criando um novo design de banco de dados) ou decomposição (melhorando um design de banco de dados existente).

Objetivos

Um objetivo básico da primeira forma normal definida por Codd em 1970 era permitir que os dados fossem consultados e manipulados usando uma "sub-linguagem de dados universal" baseado na lógica de primeira ordem. Um exemplo de tal linguagem é o SQL, embora seja uma que Codd considerasse seriamente falha.

Os objetivos da normalização além da 1NF (primeira forma normal) foram declarados por Codd como:

1. Para liberar a coleta de relações de dependências indesejáveis de inserção, atualização e exclusão.
2. Para reduzir a necessidade de reestruturação da coleta de relações, como novos tipos de dados são introduzidos, e assim aumentar a vida útil dos programas de aplicação.
3. Tornar o modelo relacional mais informativo aos usuários.
4. Para tornar a coleta de relações neutra às estatísticas de consulta, onde essas estatísticas são susceptíveis de mudar conforme o tempo passa.

—E.F. Codd, "Mais Normalização do Modelo Relacional da Base de Dados"

Um anomalia de inserção. Até que o novo membro do corpo docente, Dr. Newsome, seja designado para ensinar pelo menos um curso, seus detalhes não podem ser gravados.

Um atualização da anomalia. Employee 519 é mostrado como tendo endereços diferentes em diferentes registros.

A anomalia de exclusão. Todas as informações sobre o Dr. Giddens são perdidas se deixarem temporariamente de ser atribuídas a quaisquer cursos.

Quando é feita uma tentativa de modificar (atualizar, inserir ou excluir) uma relação, os seguintes efeitos colaterais indesejáveis podem surgir em relações que não foram suficientemente normalizadas:

• Anomalia de inserção. Há circunstâncias em que certos fatos não podem ser registrados. Por exemplo, cada registro em uma relação "Faculdade e seus cursos" pode conter um ID da Faculdade, Nome da Faculdade, Data de Contratação da Faculdade e Código do Curso. Portanto, os detalhes de qualquer membro do corpo docente que ensina pelo menos um curso podem ser registrados, mas um membro do corpo docente recém-contratado que ainda não foi designado para ensinar quaisquer cursos não pode ser registrado, exceto definindo o Código do Curso para null.
• Atualize a anomalia. A mesma informação pode ser expressa em várias linhas; portanto, atualizações para a relação podem resultar em inconsistências lógicas. Por exemplo, cada registro em uma relação "As Habilidades dos Empregadores" pode conter um ID de Funcionário, Endereço de Funcionário e Habilidade; assim, uma mudança de endereço para um determinado funcionário pode precisar ser aplicada a vários registros (um para cada habilidade). Se a atualização é apenas parcialmente bem sucedida – o endereço do funcionário é atualizado em alguns registros, mas não em outros – então a relação é deixada em um estado inconsistente. Especificamente, a relação fornece respostas conflitantes para a questão do que é o endereço deste funcionário particular.
• Anomalia de exclusão. Em certas circunstâncias, a exclusão de dados que representam certos fatos requer a exclusão de dados que representam fatos completamente diferentes. A relação "Faculdade e Seus Cursos" descrita no exemplo anterior sofre deste tipo de anomalia, porque se um membro do corpo docente temporariamente deixa de ser atribuído a quaisquer cursos, o último dos registros em que esse membro do corpo docente aparece deve ser excluído, efetivamente também excluir o corpo docente, a menos que o campo Código do Curso é definido como nulo.

Minimize o redesenho ao estender a estrutura do banco de dados

Um banco de dados totalmente normalizado permite que sua estrutura seja estendida para acomodar novos tipos de dados sem alterar muito a estrutura existente. Como resultado, os aplicativos que interagem com o banco de dados são minimamente afetados.

Relações normalizadas e a relação entre uma relação normalizada e outra espelham os conceitos do mundo real e suas inter-relações.

Formas normais

Codd introduziu o conceito de normalização e o que agora é conhecido como a primeira forma normal (1NF) em 1970. Codd passou a definir a segunda forma normal (2NF) e a terceira forma normal (3NF) em 1971, e Codd e Raymond F. Boyce definiu a forma normal de Boyce-Codd (BCNF) em 1974.

Informalmente, uma relação de banco de dados relacional é frequentemente descrita como "normalizada" se satisfaz a terceira forma normal. A maioria das relações 3NF são livres de anomalias de inserção, atualização e exclusão.

As formas normais (do menos normalizado ao mais normalizado) são:

Restrição (descrição informal em parênteses)	UNF (1970)	1NF (1970)	2NF (1971)	3NF (1971)	EKNF (1982)	BCNF (1974)	4NF (1977)	ETNF (2012)	5NF (1979)	DKNF (1981)	6NF (2003)
Linhas únicas (sem registros duplicados)
Colunas Scalar (colunas não podem conter relações ou valores compostos)
Cada atributo non-prime tem uma dependência funcional completa de uma chave do candidato (atributos dependem da completo chave primária)
Cada dependência funcional não trivial começa com um superkey ou termina com um atributo primo (atributos dependem apenas na chave primária)
Cada dependência funcional não trivial começa com um superkey ou termina com um atributo primário elementar (uma forma mais rigorosa de 3NF)											—
Cada dependência funcional não trivial começa com um superkey (uma forma mais rigorosa de 3NF)											—
Cada dependência multivalorizada não trivial começa com um superkey											—
Cada dependência de junção tem um componente superkey											—
Cada dependência de junção tem apenas componentes superkey											—
Cada restrição é uma consequência de restrições de domínio e restrições-chave
Cada dependência de junção é trivial

Exemplo de normalização passo a passo

Normalização é uma técnica de design de banco de dados, que é usada para projetar uma tabela de banco de dados relacional até a forma normal superior. O processo é progressivo e um nível mais alto de normalização do banco de dados não pode ser alcançado a menos que os níveis anteriores tenham sido satisfeitos.

Isso significa que, tendo os dados na forma não normalizada (a menos normalizada) e visando alcançar o maior nível de normalização, o primeiro passo seria garantir a conformidade com a primeira forma normal, o segundo passo seria garantir a segunda forma normal for satisfeito, e assim por diante na ordem acima mencionada, até que os dados estejam em conformidade com a sexta forma normal.

No entanto, vale a pena notar que as formas normais além da 4NF são principalmente de interesse acadêmico, pois os problemas que existem para resolver raramente aparecem na prática.

Os dados no exemplo a seguir foram projetados intencionalmente para contradizer a maioria das formas normais. Na vida real, é bem possível pular algumas das etapas de normalização porque a tabela não contém nada que contradiga a forma normal fornecida. Também ocorre comumente que corrigir uma violação de uma forma normal também corrige uma violação de uma forma normal superior no processo. Além disso, uma tabela foi escolhida para normalização em cada etapa, o que significa que, ao final deste processo de exemplo, ainda pode haver algumas tabelas que não atendem à forma normal mais alta.

Dados iniciais

Deixe existir uma tabela de banco de dados com a seguinte estrutura:

Para este exemplo, assume-se que cada livro tem apenas um autor.

Como pré-requisito para estar em conformidade com o modelo relacional, uma tabela deve ter uma chave primária, que identifica exclusivamente uma linha. Dois livros podem ter o mesmo título, mas um ISBN identifica exclusivamente um livro, portanto, pode ser usado como chave primária:

Satisfazendo 1NF

Para satisfazer a primeira forma normal, cada coluna de uma tabela deve ter um único valor. Não são permitidas colunas que contenham conjuntos de valores ou registros aninhados.

Na tabela inicial, Assunto contém um conjunto de valores de assunto, o que significa que não está em conformidade.

Para resolver o problema, os assuntos são extraídos em uma tabela Assunto separada:

Uma coluna de chave estrangeira é adicionada à tabela Assunto, que se refere à chave primária da linha da qual o assunto foi extraído. A mesma informação é, portanto, representada, mas sem o uso de domínios não simples.

Em vez de uma tabela em formato não normalizado, agora existem duas tabelas em conformidade com a 1NF.

Satisfazendo 2NF

Se uma tabela tiver uma chave primária de coluna única, ela atende automaticamente à 2NF, mas se uma tabela tiver uma chave composta ou multicoluna, ela pode não atender à 2NF.
A tabela Livro abaixo tem uma chave composta de {Title, Format} (indicada pelo sublinhado), portanto, pode não satisfazer 2NF. Neste ponto do nosso projeto, a chave não está finalizada como a chave primária, por isso é chamada de chave candidata. Considere a seguinte tabela:

Todos os atributos que não fazem parte da chave candidata dependem de Título, mas apenas Preço também depende de Formato. Para estar em conformidade com a 2NF e remover duplicidades, todo atributo de chave não candidata deve depender de toda a chave candidata, não apenas de parte dela.

Para normalizar esta tabela, torne {Title} uma (simples) chave candidata (a chave primária) para que cada atributo de chave não candidata dependa de toda a chave candidata e remova Price em uma tabela separada para que sua dependência de Format possa ser preservada:

Agora, a tabela Book está em conformidade com a 2NF.

Satisfazendo 3NF

A tabela Livro ainda possui uma dependência funcional transitiva ({Author Nationality} depende de {Author}, que depende de {Title}). Existe uma violação semelhante para gênero ({Genre Name} depende de {Genre ID}, que depende de {Title}). Portanto, a tabela Book não está na 3NF. Para fazê-lo na 3NF, vamos utilizar a seguinte estrutura de tabelas, eliminando assim as dependências funcionais transitivas colocando {Author Nationality} e {Genre Name} em suas respectivas tabelas:

Satisfazendo o EKNF

A forma normal de chave elementar (EKNF) fica estritamente entre 3NF e BCNF e não é muito discutida na literatura. Pretende-se "capturar as qualidades salientes de ambos 3NF e BCNF", evitando os problemas de ambos (ou seja, que 3NF é "muito indulgente" e BCNF é "propenso à complexidade computacional"). Como raramente é mencionado na literatura, não está incluído neste exemplo.

Satisfazendo 4NF

Suponha que o banco de dados seja propriedade de uma franquia de uma livraria que possui vários franqueados que possuem lojas em diferentes locais. E por isso o lojista decidiu adicionar uma tabela que contém dados sobre a disponibilidade dos livros em diferentes locais:

Como esta estrutura de tabela consiste em uma chave primária composta, ela não contém nenhum atributo não-chave e já está em BCNF (e, portanto, também satisfaz todas as formas normais anteriores). No entanto, supondo que todos os livros disponíveis sejam oferecidos em cada área, o Título não está inequivocamente vinculado a um determinado Local e, portanto, a tabela não satisfaz a 4NF.

Isso significa que, para satisfazer a quarta forma normal, esta tabela também precisa ser decomposta:

Agora, cada registro é identificado inequivocamente por uma superchave, portanto 4NF é satisfeito.

Atendendo a ETNF

Suponha que os franqueados também possam encomendar livros de diferentes fornecedores. Suponha que a relação também esteja sujeita à seguinte restrição:

• Se um certo fornecedor fornece um certo título
• e o título é fornecido ao franchisado
• e o franchisado está sendo fornecido pela fornecedor,
• então o fornecedor fornecimentos título ao franchisado.

Esta tabela está na 4NF, mas o ID do Fornecedor é igual à junção de suas projeções: {{ID do Fornecedor, Título}, {Título, ID do Franqueado}, {ID do Franqueado, ID do Fornecedor}}. Nenhum componente dessa dependência de junção é uma superchave (a única superchave é o título inteiro), então a tabela não satisfaz o ETNF e pode ser decomposta posteriormente:

A decomposição produz conformidade ETNF.

Satisfazendo 5NF

Para identificar uma tabela que não satisfaça a 5NF, geralmente é necessário examinar os dados minuciosamente. Suponha a tabela do exemplo 4NF com uma pequena modificação nos dados e vamos examinar se ela satisfaz 5NF:

A decomposição desta tabela diminui as redundâncias, resultando nas duas tabelas a seguir:

A consulta juntando essas tabelas retornaria os seguintes dados:

O JOIN retorna três linhas a mais do que deveria; adicionar outra tabela para esclarecer a relação resulta em três tabelas separadas:

O que o JOIN retornará agora? Na verdade, não é possível juntar essas três tabelas. Isso significa que não foi possível decompor o Franqueado - Livro - Localização sem perda de dados, portanto a tabela já atende a 5NF.

C. J. Date argumentou que apenas um banco de dados em 5NF é verdadeiramente "normalizado".

Satisfazendo o DKNF

Vamos dar uma olhada na tabela Book dos exemplos anteriores e ver se ela satisfaz a forma normal da chave de domínio:

Logicamente, a Espessura é determinada pelo número de páginas. Isso significa que depende de Páginas, que não é uma chave. Vamos definir um exemplo de convenção dizendo que um livro de até 350 páginas é considerado "fino" e um livro com mais de 350 páginas é considerado "grosso".

Essa convenção é tecnicamente uma restrição, mas não é uma restrição de domínio nem uma restrição de chave; portanto, não podemos confiar em restrições de domínio e restrições de chave para manter a integridade dos dados.

Em outras palavras – nada nos impede de colocar, por exemplo, "Grosso" para um livro com apenas 50 páginas – e isso faz com que a tabela viole DKNF.

Para resolver isso, uma tabela contendo uma enumeração que define a Espessura é criada e essa coluna é removida da tabela original:

Desta forma, a violação de integridade do domínio foi eliminada e a tabela está em DKNF.

Satisfazendo 6NF

Uma definição simples e intuitiva da sexta forma normal é que "uma tabela está na 6NF quando a linha contém a Chave Primária e, no máximo, um outro atributo".

Isso significa, por exemplo, a tabela Publisher projetada durante a criação da 1NF

precisa ser decomposto em duas tabelas:

A desvantagem óbvia do 6NF é a proliferação de tabelas necessárias para representar as informações em uma única entidade. Se uma tabela na 5NF tiver uma coluna de chave primária e N atributos, representar a mesma informação na 6NF exigirá N tabelas; atualizações de vários campos para um único registro conceitual exigirão atualizações para várias tabelas; e inserções e exclusões também exigirão operações em várias tabelas. Por este motivo, em bases de dados destinadas a atender necessidades de Processamento de Transações Online, a 6NF não deve ser utilizada.

No entanto, em data warehouses, que não permitem atualizações interativas e são especializados para consultas rápidas em grandes volumes de dados, alguns SGBDs usam uma representação 6NF interna – conhecida como armazenamento de dados colunar. Em situações em que o número de valores exclusivos de uma coluna é muito menor do que o número de linhas na tabela, o armazenamento orientado a coluna permite uma economia significativa de espaço por meio da compactação de dados. O armazenamento colunar também permite a execução rápida de consultas de intervalo (por exemplo, mostra todos os registros em que uma determinada coluna está entre X e Y ou menor que X).

Em todos esses casos, no entanto, o projetista do banco de dados não precisa executar a normalização 6NF manualmente criando tabelas separadas. Alguns DBMSs especializados em armazenamento, como o Sybase IQ, usam armazenamento colunar por padrão, mas o designer ainda vê apenas uma única tabela com várias colunas. Outros DBMSs, como o Microsoft SQL Server 2012 e posterior, permitem que você especifique um "índice de coluna" para uma determinada tabela.

Notas e referências