Normalização do banco de dados - Database normalization

A normalização de banco de dados é o processo de estruturação de um banco de dados , geralmente um banco de dados relacional , de acordo com uma série de formas chamadas normais , a fim de reduzir a redundância de dados e melhorar a integridade dos dados . Foi proposto pela primeira vez por Edgar F. Codd como parte de seu modelo relacional .

A normalização envolve organizar as 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" baseada na lógica de primeira ordem . ( SQL é um exemplo de uma sublinguagem de dados, embora uma que Codd tenha considerado seriamente falha.)

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

1. Para liberar a coleção 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 coleção de relações, conforme novos tipos de dados são introduzidos, e assim aumentar a vida útil dos programas aplicativos.
3. Para tornar o modelo relacional mais informativo para os usuários.
4. Para tornar a coleção de relações neutras para as estatísticas da consulta, onde essas estatísticas são suscetíveis de mudar com o passar do tempo.

-  EF Codd, "Normalização Adicional do Modelo Relacional da Base de Dados"

Uma anomalia de atualização . O funcionário 519 é mostrado como tendo endereços diferentes em registros diferentes.

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

Uma anomalia de exclusão . Todas as informações sobre o Dr. Giddens serão perdidas se ele deixar temporariamente de ser atribuído a qualquer curso.

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

• Atualizar anomalia. A mesma informação pode ser expressa em várias linhas; portanto, atualizações na relação podem resultar em inconsistências lógicas. Por exemplo, cada registro em uma relação "Habilidades dos funcionários" pode conter um ID do funcionário, endereço do funcionário e habilidade; portanto, 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 for 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 à pergunta sobre qual é o endereço desse funcionário em particular. Este fenômeno é conhecido como anomalia de atualização.
• Anomalia de inserção. Existem circunstâncias em que certos fatos não podem ser registrados. Por exemplo, cada registro em uma relação "Corpo Docente e seus Cursos" pode conter uma ID do Corpo Docente, Nome do Corpo Docente, Data de Contratação do Corpo Docente e Código do Curso. Portanto, os detalhes de qualquer membro do corpo docente que ministre pelo menos um curso podem ser registrados, mas um membro do corpo docente recém-contratado que ainda não foi designado para ministrar nenhum curso não pode ser registrado, exceto definindo o Código do Curso como nulo . Este fenômeno é conhecido como anomalia de inserção.
• Anomalia de exclusão. Em certas circunstâncias, a exclusão de dados que representam certos fatos exige a exclusão de dados que representam fatos completamente diferentes. A relação "Docente e seus Cursos" descrita no exemplo anterior sofre desse tipo de anomalia, pois se um docente deixar temporariamente de ser atribuído a algum curso, o último dos registros em que esse docente consta deve ser apagado, efetivamente também excluindo o membro do corpo docente, a menos que o campo Código do curso seja definido como nulo. Esse fenômeno é conhecido como anomalia de exclusão.

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.

As relações normalizadas e a relação entre uma relação normalizada e outra refletem 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 atender à terceira forma normal. A maioria das relações 3NF está livre de anomalias de inserção, atualização e exclusão.

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

	UNF (1970)	1NF (1970)	2NF (1971)	3NF (1971)	EKNF (1982)	BCNF (1974)	4NF (1977)	ETNF (2012)	5NF (1979)	DKNF (1981)	6NF (2003)
Chave primária (sem tuplas duplicadas )
Colunas atômicas (as células não podem ter tabelas como valores)
Cada dependência funcional não trivial não começa com um subconjunto adequado de uma chave candidata ou termina com um atributo principal (sem dependências funcionais parciais de atributos não principais em chaves candidatas)
Cada dependência funcional não trivial começa com uma superchave ou termina com um atributo principal (sem dependências funcionais transitivas de atributos não principais em chaves candidatas)
Cada dependência funcional não trivial começa com uma superchave ou termina com um atributo primário elementar											N / D
Cada dependência funcional não trivial começa com uma superchave											N / D
Cada dependência multivalorada não trivial começa com uma superchave											N / D
Cada dependência de junção tem um componente superchave											N / D
Cada dependência de junção tem apenas componentes de superchave											N / D
Cada restrição é uma consequência de restrições de domínio e restrições de chave
Cada dependência de junção é trivial

Exemplo de uma normalização passo a passo

A 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 com o objetivo de atingir o nível mais alto de normalização, a primeira etapa seria garantir a conformidade com a primeira forma normal , a segunda etapa seria garantir que a segunda forma normal seja satisfeita, e assim por diante na ordem mencionada acima, até que os dados estejam em conformidade com a sexta forma normal .

No entanto, é importante notar que as formas normais além do 4NF são principalmente de interesse acadêmico, uma vez que os problemas que existem para resolver raramente aparecem na prática.

Observe que os dados no exemplo a seguir foram projetados intencionalmente para contradizer a maioria das formas normais. Na vida real, é 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 é comum que consertar uma violação de uma forma normal também conserte 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 no final deste processo de exemplo, ainda pode haver algumas tabelas que não satisfazem a forma normal mais alta.

Dados iniciais

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

Para este exemplo, presume-se que cada livro tenha 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 número ISBN identifica exclusivamente um livro, por isso pode ser usado como a chave primária:

Satisfazendo 1NF

Para satisfazer a primeira forma normal , cada coluna de uma tabela deve ter um único valor. Colunas que contêm conjuntos de valores ou registros aninhados não são permitidas.

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 indivíduos são extraídos para um separado Objecto tabela:

É adicionada uma coluna de chave estrangeira à 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 na forma não normalizada , agora existem duas tabelas em conformidade com a 1NF.

Satisfazendo 2NF

A tabela Book tem uma chave candidata (que é, portanto, a chave primária ), a chave composta {Título, Formato} . Considere o seguinte fragmento de tabela:

Todos os atributos que não fazem parte da chave candidata dependem do Título , mas apenas o Preço também depende do Formato . Para estar em conformidade com 2NF e remover duplicidades, cada 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 chave candidata (simples) (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 Formato possa ser preservado:

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

Satisfazendo 3NF

A tabela Book ainda tem uma dependência funcional transitiva ({Author Nationality} é dependente de {Author}, que é dependente de {Title}). Existe uma violação semelhante para o gênero ({Genre Name} depende de {Genre ID}, que depende de {Title}). Conseqüentemente, a tabela Book não está em 3NF. Para fazer isso em 3NF, vamos usar a seguinte estrutura de tabela, eliminando assim as dependências funcionais transitivas, colocando {Author Nationality} e {Genre Name} em suas respectivas tabelas:

Satisfazendo EKNF

A forma normal da 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 (nomeadamente, que 3NF é “muito indulgente” e BCNF é “sujeito a complexidade computacional”). Como raramente é mencionado na literatura, não está incluído neste exemplo.

Satisfazendo 4NF

Suponha que o banco de dados seja de propriedade de uma franquia de livraria que possui vários franqueados que possuem lojas em diferentes locais. E, portanto, o varejista 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 é inequivocamente vinculado a um determinado local e, portanto, a tabela não satisfaz 4NF .

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

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

Satisfazendo ETNF

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

• Se um determinado fornecedor fornece um determinado título
• e o título é fornecido ao franqueado
• e o franqueado está sendo fornecido pelo fornecedor,
• então, o fornecedor fornece o título ao franqueado .

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

A decomposição produz conformidade com o ETNF.

Satisfazendo 5NF

Para localizar uma tabela que não satisfaça o 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 o 5NF :

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

A consulta que une essas tabelas retornaria os seguintes dados:

O JOIN retorna três linhas a mais do que deveria; adicionar outra tabela para esclarecer os resultados da relação 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 - Local do Livro sem perda de dados, pois a tabela já atende a 5NF .

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

Satisfazendo DKNF

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

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

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

Ou seja - nada nos impede de colocar, por exemplo, "Thick" para um livro com apenas 50 páginas - e isso faz com que a tabela viole a DKNF .

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

Dessa forma, a violação da 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á em 6NF quando a linha contém a chave primária e, no máximo, um outro atributo" .

Isso significa, por exemplo, a tabela do editor projetada durante a criação do 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 em 5NF tiver uma coluna de chave primária e N atributos, representar as mesmas informações em 6NF exigirá N tabelas; as atualizações de vários campos para um único registro conceitual exigirão atualizações para várias tabelas; e as inserções e exclusões exigirão operações em várias tabelas da mesma forma. Por esse motivo, em bancos de dados destinados a atender às necessidades de processamento de transações online , o 6NF não deve ser usado.

No entanto, em armazéns de dados , que não permitem atualizações interativas e que são especializados para consulta rápida 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 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 onde uma determinada coluna está entre X e Y, ou menor que X).

Em todos esses casos, entretanto, o designer do banco de dados não precisa realizar a normalização 6NF manualmente criando tabelas separadas. Alguns DBMSs especializados em armazenamento, como 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 columnstore" para uma tabela específica.

Veja também

• Desnormalização
• Refatoração de banco de dados

• Decomposição de junção sem perdas

Notas e referências

Leitura adicional

• Date, CJ (1999), An Introduction to Database Systems (8ª ed.). Addison-Wesley Longman. ISBN  0-321-19784-4 .
• Kent, W. (1983) A Simple Guide to Five Normal Forms in Relational Database Theory , Communications of the ACM, vol. 26, pp. 120-125
• H.-J. Schek, P. Pistor Data Structures for an Integrated Data Base Management and Information Retrieval System

links externos

• Kent, William (fevereiro de 1983). "Um Guia Simples para Cinco Formas Normais na Teoria de Banco de Dados Relacional" . Comunicações da ACM . 26 (2): 120–125. doi : 10.1145 / 358024.358054 . S2CID  9195704 .
• Fundamentos de normalização de banco de dados por Mike Chapple (About.com)
• Introdução à normalização do banco de dados , parte 2
• Uma introdução à normalização de banco de dados por Mike Hillyer.
• Um tutorial sobre as 3 primeiras formas normais por Fred Coulson
• Descrição dos fundamentos de normalização do banco de dados pela Microsoft
• Normalização em DBMS por Chaitanya (beginnersbook.com)
• Um guia passo a passo para normalização de banco de dados
• ETNF - forma normal de tupla essencial