ACC: Database Normalization Basics

Traduções de Artigos Traduções de Artigos
Artigo: 100139 - Ver produtos para os quais este artigo se aplica.
Principiante: Requer conhecimentos da interface do utilizador em computadores individuais.

Expandir tudo | Reduzir tudo

Nesta página

Sumário

Este artigo explica as noções básicas da terminologia de normalização de base de dados. Uma compreensão básica desta terminologia é útil quando estiverem a debater a estrutura de uma base de dados relacional.

Nota : a Microsoft também disponibiliza uma WebCast que explica os princípios básicos de normalização de base de dados. Para visualizar esta WebCast, visite o seguinte Web site da Microsoft:
http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1
Nota : para ver estas informações para o Microsoft Access 2000, consulte o seguinte artigo na base de dados de conhecimento da Microsoft:
209534ACC2000: Database Normalization Basics

Mais Informação

Descrição de normalização

Normalização é o processo de organizar dados numa base de dados. Este envolve a criação de tabelas e o estabelecimentos de relações entre essas tabelas, de acordo com regras concebidas para proteger os dados e para tornar a base de dados mais flexível eliminando dois factores: redundância e dependência inconsistente.

Dados redundantes desperdiçam espaço em disco e criam problemas de manutenção. Se devem ser alterados dados em mais do que um local, os dados devem ser alterados exactamente da mesma forma em todas as localizações. Uma alteração de endereço do cliente é muito mais fácil de implementar se esses dados estiver armazenados apenas numa tabela clientes e nowhere pessoa na base de dados.

O que é uma "dependência inconsistente"? Enquanto é intuitivo para um utilizador procura na tabela clientes para o endereço de um determinado cliente, poderá não fazer sentido procurar existe o salário do funcionário que as chamadas na qual o cliente. Salário o empregado relacionadas com o, ou dependentes, o empregado e que assim deve ser movido para a tabela de empregados. As dependências inconsistentes podem dificultar dados para acesso; o caminho para localizar os dados pode estar em falta ou interrompido.

Existem algumas regras de normalização de base de dados. Cada regra é chamada "forma normal". Se a primeira regra é respeitada, diz-se a base de dados que está a ser "primeira forma normal". Se as três primeiras regras são observadas, a base de dados é considerada na "terceira forma normal". Apesar de outros níveis de normalização serem possíveis, terceira forma normal é considerada o nível mais elevado necessário para a maioria das aplicações.

Como com várias regras formais e especificações, cenários reais não são sempre permitida para conformidade com. Em geral, normalização requer tabelas adicionais e alguns clientes localizar este complicado. Se decidir violar uma das três primeiras regras da normalização, certifique-se de que a aplicação antecipa quaisquer problemas que poderá ocorrer, tais como dados redundantes e dependências inconsistentes.

Nota : as descrições seguintes incluem exemplos.

Primeira forma normal

  • Elimine grupos de repetição em tabelas individuais.
  • Crie uma tabela separada para cada conjunto de dados relacionados.
  • Identificar cada conjunto de dados relacionados com uma chave primária.
Não utilize vários campos numa única tabela para armazenar dados semelhantes. Por exemplo, para controlar um item de inventário que pode vir de duas origens possíveis, um registo de inventário pode de conter campos para fornecedor código 1 e 2 do código de fornecedor.

Mas o que acontece quando adicionar um terceiro fornecedor? Adicionar um campo não é a resposta; requer modificações do programa e tabela e não bom acomodar um número dinâmico de fornecedores. Em vez disso, coloque todas as informações de fornecedor numa tabela separada denominada fornecedores e inventário de ligação a fornecedores com uma chave de número de produto ou fornecedores para inventário com uma chave de código do fornecedor.

Segundo forma normal

  • Crie tabelas separadas para conjuntos de valores que se aplicam a vários registos.
  • Relacione estas tabelas com uma chave externa.
Registos não devem depender diferente de chave primária de uma tabela (uma chave composta, se necessário). Por exemplo, considere o endereço do cliente num sistema de gestão de contas. O endereço é necessário pela tabela clientes, mas também pelas tabelas Encomendas, envio, facturas, contas a receber e colecções. Em vez de armazenar o endereço do cliente como uma entrada separada em cada uma destas tabelas, guarde-a num local, na tabela clientes ou numa tabela endereços separada.

Terceira forma normal

  • Elimine campos que não dependam da chave.
Valores de um registo que não fazem parte da chave do registo não pertencem na tabela. Em geral, sempre que o conteúdo de um grupo de campos pode aplicar para mais do que um único registo na tabela, deverá considerar colocar esses campos numa tabela separada.

Por exemplo, numa tabela Recrutamento de funcionários, um candidato Universidade nome e endereço poderão ser incluídos. Mas necessita de uma lista completa de universidades para mensagens de correio de grupo. Se Universidade informações são armazenadas na tabela candidatos, não existe nenhuma forma de lista de universidades com sem candidatos actuais. Criar uma tabela Universidades separada e ligue-o à tabela de candidatos com uma chave de código de universidade.

excepção de : respeite ao formulário normal em terceiro lugar, enquanto teoricamente desejável, nem sempre é prático. Se tiver uma tabela clientes e pretender eliminar todas as possíveis dependências interfield, tem de criar tabelas separadas para cidades, códigos postais, representantes de vendas, classes de cliente e qualquer outro factor que pode ser duplicado em múltiplos registos. Em teoria, normalização vale perseguir; no entanto, muitas tabelas pequenas podem diminuir o desempenho ou exceder ficheiros abertos e capacidades de memória.

Poderá ser possível aplicar a terceira forma normal apenas aos dados que altera frequentemente. Se permanecerem alguns campos dependentes, crie a aplicação requerem que o utilizador verificar que todos os campos relacionados quando é alterado algum.

Outros formulários de normalização

Quarta forma normal, também designado por BCNF (Boyce Codd Normal forma) e quinta forma normal existem, mas raramente são considerados na concepção prática. Disregarding estas regras pode resultar na estrutura de base de dados menos perfeita, mas não deverá afectar a funcionalidade.
               **********************************
                 Examples of Normalized Tables
               **********************************

 Normalization Examples:

 Unnormalized table:

    Student#   Advisor   Adv-Room  Class1   Class2   Class3
    -------------------------------------------------------
    1022       Jones      412      101-07   143-01   159-02
    4123       Smith      216      201-01   211-02   214-01
				
  1. Primeira forma normal: Não REPEATING grupos

    Tabelas devem ter apenas duas dimensões. Uma vez que um estudante tem várias classes, estas classes deverão ser listadas numa tabela separada. Os campos Aula1, Aula2, & Aula3 do registo acima são indicações de problemas de concepção.

    Folhas de cálculo utilizam frequentemente a terceira dimensão, mas tabelas não devem. Outra forma de observar este problema: com uma relação um-para-muitos, não coloque um lado e o lado do muitos na mesma tabela. Em vez disso, crie outra tabela na primeira forma normal através da eliminação do grupo de repetição (classe #), conforme é ilustrado abaixo:
           Student#   Advisor   Adv-Room    Class#
           ---------------------------------------
           1022      Jones      412       101-07
           1022      Jones      412       143-01
           1022      Jones      412       159-02
           4123      Smith      216       201-01
           4123      Smith      216       211-02
           4123      Smith      216       214-01
    					
  2. Segundo forma normal: Eliminar dados REDUNDANTES

    Repare nos múltiplos classe # valores para cada aluno # valor na tabela acima. Classe # não está funcionalmente dependente para estudantes # (chave primária), pelo que esta relação não está no segundo formulário normal.

    Duas tabelas seguintes demonstram segundo formulário normal:
        Students:   Student#    Advisor   Adv-Room
                    ------------------------------
                    1022        Jones       412
                    4123        Smith       216
    
        Registration:   Student#    Class#
                        ------------------
                        1022        101-07
                        1022        143-01
                        1022        159-02
                        4123        201-01
                        4123        211-02
                        4123        214-01
    					
  3. Terceira forma normal: Eliminar dados não dependentes ON KEY

    Do último exemplo é funcionalmente dependente o atributo de classificação do avançado-sala (número de escritório de classificação). A solução é mover esse atributo da tabela estudantes para a tabela corpo docente, conforme é ilustrado abaixo:
        Students:   Student#    Advisor
                    -------------------
                    1022        Jones
                    4123        Smith
    
        Faculty:    Name    Room    Dept
                    --------------------
                    Jones   412     42
                    Smith   216     42
    					

Referências

Para obter informações adicionais sobre como estruturar uma base de dados, clique no número de artigo existente abaixo para visualizar o artigo na base de dados de conhecimento da Microsoft:
234208ACC2000: "Noções sobre a estrutura de base de dados relacional" documentos disponíveis no Centro de transferências
"FoxPro 2 A Developers Guide," AL. do Hamilton M. Ahlo Jr. et, páginas 220-225, livros do M & T, 1991

"Utilizar o Access para Windows, Roger Jennings, páginas 799-800, Corporation, 1993

Propriedades

Artigo: 100139 - Última revisão: 18 de janeiro de 2007 - Revisão: 2.1
A informação contida neste artigo aplica-se a:
  • Microsoft Access 1.0 Standard Edition
  • Microsoft Access 1.1 Standard Edition
  • Microsoft Access 2.0 Standard Edition
  • Microsoft Access 95 Standard Edition
  • Microsoft Access 97 Standard Edition
Palavras-chave: 
kbmt kbinfo kbusage KB100139 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine translation ou MT), não tendo sido portanto revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática? erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 100139
Exclusão de Responsabilidade para Conteúdo sem Suporte na KB
Este artigo foi escrito sobre produtos para os quais a Microsoft já não fornece suporte. Por conseguinte, este artigo é oferecido "tal como está" e deixará de ser actualizado.

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com