Atenção: esse artigo tem um vídeo complementar. Clique e assista!
O artigo descreve um guia para as 5 formas normais que podem ser aplicadas na estrutura de um banco de dados a fim de reduzir, principalmente, redundância nos dados e prover uma melhor estrutura para recuperação das informações em um banco de dados relacional.
Para que serve
Para DBAs que precisam aplicar estratégias de normalização em bancos de dados relacionais a fim de prover melhorias através da redução de redundância entre os dados.
Em que situação o tema é útil
Bancos de dados relacionais são as tecnologias mais utilizadas para armazenamento de dados hoje em dia, de forma a possibilitar o armazenamento de um volume grande de dados. Neste cenário, normalização se apresenta como uma das principais técnicas de modelagem a serem aplicadas a fim de prover melhorias no gerenciamento de dados através da minimização da sua redundância.
Resumo DevMan
As regras de normalização são projetadas para prevenir anomalias e inconsistência de dados. Neste sentido, este artigo descreve um guia para as 5 formas normais que podem ser aplicadas na estrutura de um banco de dados a fim de reduzir, principalmente, redundância nos dados e prover uma melhor estrutura para recuperação das informações em um banco de dados relacional.
As formas normais definidas na teoria de banco de dados relacional representam diretrizes para projeto de como as informações ficarão organizadas no banco. As diretrizes correspondentes da primeira à quinta formas normais são apresentadas no artigo, de forma a não exigir um entendimento da teoria relacional. As diretrizes de projeto são significativas mesmo se não estivermos usando um sistema de banco de dados relacional. As diretrizes são apresentadas sem se referir aos conceitos do modelo relacional para enfatizar sua generalidade, e também para facilitar seu entendimento.
As regras de normalização são projetadas para prevenir anomalias e inconsistência de dados. Com respeito à contrapartida no desempenho, essas diretrizes são enviesadas supondo que todos os campos que não são chaves serão atualizados frequentemente. Elas tendem a penalizar recuperações de dados, pois os dados a serem recuperados a partir de um registro em um projeto não normalizado pode ter que ser recuperado a partir de vários registros na forma normalizada. Por este motivo, não existe obrigação por normalizar completamente todos os registros quando os requisitos de desempenho da aplicação são levados em conta.
A primeira forma normal
A primeira forma normal lida com a “forma” de um tipo de registro.
Sob a primeira forma normal, todas as ocorrências de um tipo de registro devem conter os mesmos números de campos.
A primeira forma normal exclui variáveis repetindo campos e grupos. Isso não chega a ser uma diretriz de projeto em sua definição, pois na teoria de banco de dados relacional não são tratados registros que possuam um número variável de campos.
Segunda e terceira formas normais
A segunda e terceira forma normal lidam com o relacionamento entre campos não-chaves e aqueles que são chaves.
Sob segunda e terceira forma normal, um campo não-chave deve prover um relacionamento (fato) com a chave, sendo toda ela, e nada além. Além disso, o registro deve satisfazer à primeira forma normal.
Nós lidamos agora apenas com fatos "simplesmente-valorados". O fato pode ser um relacionamento do tipo um-para-muitos, tal como o departamento de um funcionário, ou um relacionamento um-para-um, tal como a/o esposa/esposo de um funcionário. Assim, a frase "Y é um fato sobre X" significa um relacionamento um-para-um ou um-para-muitos entre Y e X. No caso geral, Y pode ser composto de um ou mais campos, assim como X. No exemplo mais à frente neste artigo, QUANTIDADE é um fato sobre a combinação de PEÇA e ARMAZÉM.
A segunda forma normal
A segunda forma normal é violada quando um campo não-chave é um fato sobre um subconjunto de uma chave. Isso é relevante quando a chave é composta, ou seja, é formada por vários campos. Considere o seguinte registro de inventário apresentado na Listagem 1.
Listagem 1. Campos formando um Registro de Inventário
--------------------------------------------------
| PECA | ARMAZEM | QUANTIDADE | ENDERECO-ARMAZEM |
--------------------------------------------------A chave neste registro é formada pelos campos PECA e ARMAZEM juntos, mas ENDERECO-ARMAZEM é um fato sobre o campo ARMAZEM sozinho. Os problemas básicos com este projeto são:
• O endereço do armazém é repetido em todo registro que se refere a uma peça armazenada no armazém.
• Se o endereço do armazém mudar, todos os registros se referindo a uma peça armazenada neste armazém devem ser atualizados.
• Por causa da redundância, os dados podem se tornar inconsistentes, com diferentes registros mostrando diferentes endereços para o mesmo armazém.
• Se em algum momento não existirem peças armazenadas no armazém, pode não haver registros que mantenha o endereço do armazém.
...
