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 dados na forma não normalizada (o menos normalizado) e visando atingir o mais alto nível 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 fosse satisfeita e assim por diante na ordem mencionada acima, até que os dados estivessem em conformidade com a sexta forma normal.
No entanto, é importante notar que os formulários normais além do 4NF são principalmente de interesse acadêmico, pois os problemas que eles existem para resolver raramente aparecem na prática.
Observe que os dados no exemplo a seguir foram intencionalmente projetado para contradizer a maioria das formas normais. Na vida real, é perfeitamente 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.
DataEdit inicial
Deixe uma tabela de banco de dados com a seguinte estrutura:
| Título | Autor | Nacionalidade do autor | Formato | Preço | Assunto | Páginas | Espessura | Editora | País da editora | Tipo de publicação | ID do gênero | Nome do gênero |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Início do projeto e otimização do banco de dados MySQL | Chad Russell | Americano | Capa dura | 49,99 | MySQL,
Banco de dados, Design |
520 | Grosso | Apress | EUA | E-book | 1 | Tutorial |
Presumimos neste exemplo que cada livro tem apenas um autor.
Satisfazendo 1NFEdit
Para satisfazer 1NF, os valores em cada coluna de uma tabela devem ser atômicos. Na tabela inicial, Assunto contém um conjunto de valores de assunto, o que significa que não está em conformidade.
Uma maneira de obter o 1NF seria separar as duplicidades em várias colunas usando grupos repetidos Assunto:
| Título | Formato | Autor | Nacionalidade do autor | Preço | Assunto 1 | Assunto 2 | Assunto 3 | Páginas | Espessura | Editora | País da editora | ID do gênero | Nome do gênero |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Início do projeto e otimização do banco de dados MySQL | Capa dura | Chad Russell | Americano | 49,99 | MySQL | Banco de dados | Design | 520 | Espesso | Apress | EUA | 1 | Tutorial |
Embora agora a tabela esteja formalmente em conformidade com o 1NF (é atômica), o problema com esta solução é óbvio – se um livro tem mais de três assuntos, não pode ser adicionado à base de dados sem alterar a sua estrutura.
Para resolver o problema de uma forma mais elegante, é necessário identificar as entidades representadas na tabela e separá-las em suas próprias tabelas. Nesse caso, resultaria nas tabelas Livro, Assunto e Editor:
| Título | Formato | Autor | Nacionalidade do autor | Preço | Páginas | Thickness | ID do gênero | Nome do gênero | ID do editor |
|---|---|---|---|---|---|---|---|---|---|
| MySQL inicial Design e otimização de banco de dados | Capa dura | Chad Russell | Americano | 49.99 | 520 | Grosso | 1 | Tutorial | 1 |
|
|
Simplesmente separar os dados iniciais em várias tabelas quebraria a conexão entre os dados. Isso significa que os relacionamentos entre as tabelas recém-introduzidas precisam ser determinados. Observe que a coluna ID do editor na tabela do livro é uma chave estrangeira que realiza a relação muitos-para-um entre um livro e uma editora.
Um livro pode caber em muitos assuntos, assim como um assunto pode correspondem a muitos livros. Isso significa também que um relacionamento muitos para muitos precisa ser definido, obtido através da criação de uma tabela de links:
|
Em vez de uma tabela na forma não normalizada, agora existem 4 tabelas em conformidade com o 1NF.
Satisfying 2NFEdit
A tabela Book tem uma chave candidata (que é, portanto, a chave primária), a chave composta {Title, Format}. Considere o seguinte fragmento de tabela:
| Título | Formato | Autor | Nacionalidade do autor | Preço | Páginas | Espessura | ID do gênero | Nome do gênero | ID do editor |
|---|---|---|---|---|---|---|---|---|---|
| Design e otimização do banco de dados MySQL inicial | Capa dura | Chad Russell | Americano | 49,99 | 520 | Grosso | 1 | Tutorial | 1 |
| Iniciando o design e otimização do banco de dados MySQL | E-book | Chad Russell | Americano | 22,34 | 520 | Grosso | 1 | Tutorial | 1 |
| O modelo relacional para gerenciamento de banco de dados: Versão 2 | E-book | EFCodd | Britânico | 13,88 | 538 | Espesso | 2 | Ciência popular | 2 |
| O modelo relacional para Database Ma nagement: Versão 2 | Brochura | EFCodd | Britânica | 39,99 | 538 | Espesso | 2 | Ciência popular | 2 |
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 do Formato possa ser preservada:
|
|
Agora, a tabela Book está em conformidade com 2NF.
Satisfying 3NFEdit
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}). Portanto, a tabela Book não está em 3NF. Para torná-lo 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:
| Título | Autor | Páginas | Espessura | ID do gênero | ID do editor |
|---|---|---|---|---|---|
| Projeto inicial do banco de dados MySQL e Otimização | Chad Russell | 520 | Grosso | 1 | 1 |
| O modelo relacional para gerenciamento de banco de dados: Versão 2 | EFCodd | 538 | Grosso | 2 | 2 |
|
| Autor | Nacionalidade do autor |
|---|---|
| Chad Russell | Americano |
| EFCodd | Britânico |
| Gen re ID | Nome do gênero |
|---|---|
| 1 | Tutorial |
| 2 | Ciência popular |
EKNFEdit satisfatório
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 (nomeadamente, que 3NF é “muito indulgente” e BCNF é “sujeito a complexidade computacional”). Uma vez que raramente é mencionado na literatura, não está incluído neste exemplo.
Satisfying 4NFEdit
Suponha que o banco de dados seja propriedade de uma franquia de um varejista de livros que tenha vários franqueados que possuem lojas em locais diferentes.E, portanto, o varejista decidiu adicionar uma tabela que contém dados sobre a disponibilidade dos livros em diferentes locais:
| ID do franqueado | Título | Local |
|---|---|---|
| 1 | Início do projeto e otimização do banco de dados MySQL | Califórnia |
| 1 | Início do projeto e otimização do banco de dados MySQL | Flórida |
| 1 | Início do projeto e otimização do banco de dados MySQL | Texas |
| 1 | O modelo relacional para gerenciamento de banco de dados: Versão 2 | Califórnia |
| 1 | O modelo relacional para gerenciamento de banco de dados: versão 2 | Flórida |
| 1 | O modelo relacional para gerenciamento de banco de dados: versão 2 | Texas |
| 2 | Início do projeto e otimização do banco de dados MySQL | Califórnia |
| 2 | Início do projeto e otimização do banco de dados MySQL | Flórida |
| 2 | Início do projeto e otimização do banco de dados MySQL | Texas |
| 2 | O modelo relacional para gerenciamento de banco de dados: versão 2 | Califórnia |
| 2 | O modelo relacional para gerenciamento de banco de dados: Versão 2 | Flórida |
| 2 | O modelo relacional para gerenciamento de banco de dados: Versão 2 | Texas |
| 3 | Início do projeto e otimização do banco de dados MySQL | Texas |
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á no BCNF (e, portanto, também satisfaz todas as formas normais anteriores). No entanto, se presumirmos que todos os livros disponíveis são oferecidos em cada área, poderemos notar que o Título não está vinculado de forma inequívoca 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:
|
|
||||||||||||
| ID do franqueado | Localização | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Califórnia | ||||||||||||
| 1 | Flórida | ||||||||||||
| 1 | Texas | ||||||||||||
| 2 | Califórnia | ||||||||||||
| 2 | Flórida | ||||||||||||
| 2 | Texas | ||||||||||||
| 3 | Texas |
Agora, cada registro é inequivocamente identificado por uma superchave, portanto, 4NF está satisfeito.
ETNFEdit satisfatório
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 certo fornecedor fornece um certo 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.
| ID do fornecedor | Título | ID do franqueado |
|---|---|---|
| 1 | Design e otimização do banco de dados MySQL inicial | 1 |
| 2 | O modelo relacional para gerenciamento de banco de dados: Versão 2 | 2 |
| 3 | Aprendizado de SQL | 3 |
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, fornecedor EU IA}}.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.
5NFEdit satisfatório
Para localizar uma tabela que não satisfaz o 5NF, geralmente é necessário examinar os dados completamente. Suponha a tabela do exemplo 4NF com uma pequena modificação nos dados e vamos examinar se ela satisfaz o 5NF:
| ID do franqueado | Título | Local |
|---|---|---|
| 1 | Início do projeto e otimização do banco de dados MySQL | Califórnia |
| 1 | Aprendizado de SQL | Califórnia |
| 1 | O modelo relacional para gerenciamento de banco de dados: Versão 2 | Texas |
| 2 | O modelo relacional para gerenciamento de banco de dados: versão 2 | Califórnia |
Se decompormos esta tabela, diminuiremos as redundâncias e obteremos as duas tabelas a seguir:
|
|
O que acontecerá se tentarmos unir essas tabelas? A consulta retornaria os seguintes dados:
| ID do franqueado | Título | Local |
|---|---|---|
| 1 | Projeto inicial do banco de dados MySQL e Otimização | Califórnia |
| 1 | Aprendizado de SQL | Califórnia |
| 1 | O modelo relacional para gerenciamento de banco de dados: Versão 2 | Califórnia |
| 1 | O modelo relacional para gerenciamento de banco de dados: versão 2 | Texas |
| 1 | Aprendizado de SQL | Texas |
| 1 | Início do projeto e otimização do banco de dados MySQL | Texas |
| 2 | O modelo relacional para gerenciamento de banco de dados: Versão 2 | Califórnia |
Aparentemente, o JOIN retorna três linhas a mais do que deveria – vamos tentar adicionar um ano outra tabela para esclarecer a relação.Terminamos com 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 – Localização do livro sem perda de dados, portanto a tabela já satisfaz 5NF.
CJ Date argumentou que apenas um banco de dados em 5NF é verdadeiramente “normalizado”.
DKNFEdit satisfatório
Vamos dar uma olhada na tabela Livro dos exemplos anteriores e ver se ela satisfaz a forma normal de chave de domínio:
| Título | Páginas | Espessura | ID do gênero | ID do editor | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Design e otimização do banco de dados MySQL inicial | 520 | Espesso | 1 | 1 | ||||||||||||||||||||||||||
| O modelo relacional para gerenciamento de banco de dados: Versão 2 | 538 | Grosso | 2 | 2 | ||||||||||||||||||||||||||
| Aprendizado de SQL | 338 | Slim | 1 | 3 | ||||||||||||||||||||||||||
| SQL Cookbook | 636 | Espesso | 1 | 3 |
|
|
Dessa forma, a violação de integridade do domínio foi eliminada e a tabela está em DKNF.
Satisfazendo 6NFEdit
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
| Publisher_ID | Nome | País |
|---|---|---|
| 1 | Apress | EUA |
precisa ser mais longe decomposto em duas tabelas:
|
|
A desvantagem óbvia de 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. Por este motivo, em bancos de dados destinados a atender às necessidades de processamento de transações online, 6NF não deve ser usado.
No entanto, em data warehouses, que não permitem atualizações interativas e que são especializados para consulta rápida em grandes volumes de dados , certos DBMSs 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, no entanto, o designer do banco de dados não tem que 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 determinada tabela.
