Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo explica a terminologia de normalização do banco de dados para iniciantes. Uma compreensão básica dessa terminologia é útil ao discutir o design de um banco de dados relacional.
Descrição da normalização
A normalização é o processo de organização de dados em um banco de dados. Ele inclui a criação de tabelas e o estabelecimento de relações entre essas tabelas de acordo com as regras projetadas tanto para proteger os dados quanto para tornar o banco de dados mais flexível eliminando a redundância e a dependência inconsistente.
Dados redundantes desperdiçam espaço em disco e criam problemas de manutenção. Se os dados existentes em mais de um local precisarem ser alterados, os dados deverão ser alterados exatamente da mesma maneira em todos os locais. Uma alteração de endereço do cliente será mais fácil de implementar se esses dados forem armazenados apenas na tabela Clientes e em nenhum outro lugar do banco de dados.
O que é uma "dependência inconsistente"? Embora seja intuitivo que um usuário procure na tabela Clientes o endereço de um cliente específico, talvez não faça sentido procurar o salário do funcionário que chama esse cliente. O salário do funcionário está relacionado ao, ou dependente do, funcionário e, portanto, deve ser movido para a tabela Funcionários. Dependências inconsistentes podem dificultar o acesso aos dados porque o caminho para localizar os dados pode estar ausente ou quebrado.
Há algumas regras para normalização do banco de dados. Cada regra é chamada de "forma normal". Se a primeira regra for observada, o banco de dados será dito estar em "primeira forma normal". Se as três primeiras regras forem observadas, o banco de dados será considerado em "terceira forma normal". Embora outros níveis de normalização sejam possíveis, o terceiro formulário normal é considerado o nível mais alto necessário para a maioria dos aplicativos.
Assim como acontece com muitas regras e especificações formais, cenários do mundo real nem sempre permitem uma conformidade perfeita. Em geral, a normalização requer tabelas adicionais e alguns clientes acham isso complicado. Se você decidir violar uma das três primeiras regras de normalização, verifique se o aplicativo prevê problemas que possam ocorrer, como dados redundantes e dependências inconsistentes.
As descrições a seguir incluem exemplos.
Primeiro formulário normal
- Elimine grupos repetidos em tabelas individuais.
- Crie uma tabela separada para cada conjunto de dados relacionados.
- Identifique cada conjunto de dados relacionados com uma chave primária.
Não use vários campos em uma única tabela para armazenar dados semelhantes. Por exemplo, para acompanhar um item de inventário que pode vir de duas fontes possíveis, um registro de inventário pode conter campos para Código do Fornecedor 1 e Código do Fornecedor 2.
O que acontece quando você adiciona um terceiro fornecedor? Adicionar um campo não é a resposta; ele requer modificações de programa e tabela e não acomoda sem problemas um número dinâmico de fornecedores. Em vez disso, coloque todas as informações do fornecedor em uma tabela separada chamada Fornecedores e, em seguida, vincule o inventário aos fornecedores com uma chave de número de item, ou os fornecedores ao inventário com uma chave de código do fornecedor.
Segundo formulário normal
- Crie tabelas separadas para conjuntos de valores que se aplicam a vários registros.
- Relacione essas tabelas com uma chave estrangeira.
Os registros não devem depender de nada além da chave primária de uma tabela (uma chave composta, se necessário). Por exemplo, considere o endereço de um cliente em um sistema contábil. O endereço é necessário para a tabela Clientes, mas também pelas tabelas Pedidos, Envio, Faturas, Contas a Receber e Coleções. Em vez de armazenar o endereço do cliente como uma entrada separada em cada uma dessas tabelas, armazene-o em um só lugar, na tabela Clientes ou em uma tabela Endereços separada.
Terceira forma normal
- Elimine os campos que não dependem da chave.
Valores em um registro que não fazem parte da chave desse registro não pertencem à tabela. Em geral, sempre que o conteúdo de um grupo de campos puder ser aplicado a mais de um único registro na tabela, considere colocar esses campos em uma tabela separada.
Por exemplo, em uma tabela de Recrutamento de Funcionários, o nome e o endereço da universidade de um candidato podem ser incluídos. Mas você precisa de uma lista completa de universidades para correspondências de grupos. Se as informações da universidade forem armazenadas na tabela Candidatos, não haverá como listar universidades sem candidatos atuais. Crie uma tabela de Universidades separada e vincule-a à tabela Candidatos com uma chave de código da universidade.
EXCEÇÃO: Aderir à terceira forma normal, embora teoricamente desejável, nem sempre é prático. Se você tiver uma tabela Clientes e quiser eliminar todas as dependências de intercampo possíveis, deverá criar tabelas separadas para cidades, CEP, representantes de vendas, classes de clientes e qualquer outro fator que possa ser duplicado em vários registros. Em teoria, vale a pena perseguir a normalização. No entanto, muitas tabelas pequenas podem degradar o desempenho ou exceder as capacidades de arquivo aberto e memória.
Pode ser mais viável aplicar o terceiro formulário normal apenas aos dados que são alterados com frequência. Se alguns campos dependentes permanecerem, projete seu aplicativo para exigir que o usuário verifique todos os campos relacionados quando qualquer um for alterado.
Outros formulários de normalização
Quarta forma normal, também chamada de BCNF (Formulário Normal) Boyce-Codd, e quinta forma normal existem, mas raramente são consideradas em design prático. Desconsiderar essas regras pode resultar em um design de banco de dados menos que perfeito, mas não deve afetar a funcionalidade.
Normalizando uma tabela de exemplo
Essas etapas demonstram o processo de normalização de uma tabela de alunos fictícia.
Tabela não desnormalizada:
Estudante# Conselheiro Adv-Room Classe1 Classe2 Classe3 1022 Jones 412 101-07 143-01 159-02 4123 Smith 216 101-07 143-01 179-04 Primeira forma normal: sem grupos repetidos
As tabelas devem ter apenas duas dimensões. Como um aluno tem várias aulas, essas classes devem ser listadas em uma tabela separada. Campos Classe1, Classe2 e Classe3 nos registros acima são indicações de problemas de design.
As planilhas geralmente usam a terceira dimensão, mas as tabelas não devem. Outra maneira de olhar para esse problema é com uma relação um-para-muitos: não se deve colocar o lado único e os lados múltiplos na mesma tabela. Em vez disso, crie outra tabela na primeira forma normal eliminando o grupo de repetição (Classe#), conforme mostrado no exemplo a seguir:
Estudante# Conselheiro Adv-Room Classe# 1022 Jones 412 101-07 1022 Jones 412 143-01 1022 Jones 412 159-02 4123 Smith 216 101-07 4123 Smith 216 143-01 4123 Smith 216 179-04 Segunda forma normal: eliminar dados redundantes
Observe os vários valores class# para cada valor Student# na tabela acima. A classe# não depende funcionalmente do Student# (chave primária), portanto, essa relação não está na segunda forma normal.
As tabelas a seguir demonstram a segunda forma normal:
Estudantes:
Estudante# Conselheiro Adv-Room 1022 Jones 412 4123 Smith 216 Inscrição:
Estudante# Classe# 1022 101-07 1022 143-01 1022 159-02 4123 101-07 4123 143-01 4123 179-04 Terceiro formulário normal: eliminar dados não dependentes da chave
No último exemplo, Adv-Room (o número do escritório do assistente) depende funcionalmente do atributo Advisor. A solução é mover esse atributo da tabela Alunos para a tabela Docente, conforme mostrado abaixo:
Estudantes:
Estudante# Conselheiro 1022 Jones 4123 Smith Faculdade:
Nome Sala Departamento Jones 412 42 Smith 216 42