ACC: Conceitos básicos de normalização de dados

Traduções deste artigo Traduções deste artigo
ID do artigo: 100139 - Exibir os produtos aos quais esse artigo se aplica.
Iniciante: Requer conhecimento da interface do usuário em computadores de usuário único.

Expandir tudo | Recolher tudo

Neste artigo

Sumário

Este artigo explica as noções básicas sobre terminologia de normalização de banco de dados. Noções básicas sobre essa terminologia é útil ao abordar o design de um banco de dados relacional.

Observação : a Microsoft também oferece um WebCast aborda as noções básicas da normalização de banco de dados. Para exibir este WebCast, por favor visite o seguinte site:
http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1
Observação : para ver essas informações para o Microsoft Access 2000, consulte o seguinte artigo na Base de dados de Conhecimento da Microsoft:
209534ACC2000: Conceitos básicos de normalização de dados

Mais Informações

Descrição da normalização

Normalização é o processo de organizar dados em um banco de dados. Isso inclui criar tabelas e estabelecer relacionamentos entre essas tabelas de acordo com regras projetadas para proteger os dados e tornar o banco de dados mais flexíveis, eliminando dois fatores: redundância e dependência inconsistente.

Dados redundantes desperdiça espaço em disco e cria problemas de manutenção. Se dados que existe em mais de um local devem ser alterados, os dados devem ser alterados no exatamente da mesma maneira em todos os locais. Uma alteração de endereço do cliente é muito mais fácil de implementar se que dados estiverem armazenados somente na tabela clientes e outra no banco de dados nem.

O que é uma "dependência inconsistente"? Embora seja intuitivo para um usuário procurar na tabela de clientes para o endereço de um determinado cliente, pode não fazer sentido para procurar o salário do funcionário que chama esse cliente não existe. Salário do funcionário está relacionado, ou dependentes, o funcionário e, portanto, deve ser movido para a tabela Funcionários. Dependências inconsistentes podem dificultar dados para acesso; o caminho para localizar os dados pode estar faltando ou dividido.

Existem algumas regras para normalização de banco de dados. Cada regra é chamada de um "formulário normal". Se a primeira regra é observada, o banco de dados é considerado em "primeira forma normalizada". Se as três primeiras regras forem observadas, o banco de dados é considerado na "terceira forma normalizada". Embora outros níveis de normalização sejam possíveis, a terceira forma normalizada é considerada o nível mais alto necessário para a maioria dos aplicativos.

Como com muitas regras formais e especificações, cenários do mundo real não permitem sempre para conformidade perfeita. Em geral, normalização requer tabelas adicionais e alguns clientes localizar este complicado. Se você decidir violar uma das três primeiras regras de normalização, certifique-se de que seu aplicativo prevê quaisquer problemas que podem ocorrer, como dados redundantes e dependências inconsistentes.

Observação : as seguintes descrições de incluem exemplos.

Primeiro formulário 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 use vários campos em uma única tabela para armazenar dados similares. Por exemplo, para rastrear um item de estoque que pode ser provenientes duas fontes possíveis, um registro de estoque pode conter campos para código de fornecedor 1 e 2 do código de fornecedor.

Mas o que acontece quando você adiciona um fornecedor terceiro? Adicionar um campo não é a resposta; ele requer modificações de programa e a tabela e não acomoda suavemente um número dinâmico de fornecedores. Em vez disso, coloque todas as informações de fornecedor em uma tabela separada denominada fornecedores, inventário de link para fornecedores com uma chave de número de itens ou fornecedores de estoque 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 externa.
Registros não devem depender algo diferente de chave primária de uma tabela (uma chave composta, se necessário). Por exemplo, considere o endereço do cliente em um sistema de estatísticas. O endereço é necessário pela tabela de clientes, mas também por tabelas Pedidos, remessa, 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, armazená-lo em um local, na tabela Customers ou em uma tabela endereços separada.

Terceira forma normal

  • Elimine campos que não dependem da chave.
Valores em um registro que não fazem parte da chave do Registro não fazem parte da tabela. Em geral, sempre que o conteúdo de um grupo de campos pode aplicar 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ário, nome da Universidade e endereço de um candidato podem ser incluídos. Mas você precisa uma lista completa de universidades para correspondências de grupo. Se as informações de Universidade estiver armazenadas na tabela de candidatos, não é possível a lista de universidades com candidatos não atuais. Criar uma tabela separada universidades e vincule-a tabela de candidatos com uma chave de código Universidade.

exceção : obedecer ao formulário terceiro normal, embora, teoricamente, é desejável, nem sempre é prático. Se você tiver uma tabela clientes e deseja eliminar todos os possíveis dependências interfield, você deve criar tabelas separadas para cidades, CEPs, representantes de vendas, classes de cliente e qualquer outro fator que pode ser duplicado em vários registros. Em teoria, normalização vale conquistar; no entanto, muitas tabelas pequenas podem degradar o desempenho ou exceder o arquivo aberto e capacidades de memória.

Talvez seja mais viável para aplicar a terceira forma normalizada somente a dados que as alterações freqüentes. Se alguns campos dependentes permanecerem, crie seu aplicativo para exigir que o usuário verificar que todos os campos relacionados quando qualquer um é alterado.

Outros formulários de normalização

Quarto formulário normal, também chamado Boyce Codd Normal formulário (BCNF) e quinto formulário normal existem, mas raramente são considerados no design prático. Desconsiderando essas regras pode resultar em design de banco de dados menor perfeito, mas não deve afetar 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 formar normal: NO grupos de REPEATING

    Tabelas devem ter apenas duas dimensões. Como um aluno tem várias classes, essas classes devem estar listadas em uma tabela separada. Campos Class1, Classe2, & Class3 no registro acima são indicações de problemas de design.

    As planilhas geralmente usam a dimensão de terceiro, mas tabelas não devem. Outra maneira de examinar esse problema: com um relacionamento um-para-muitos, não coloque um lado e no lado muitos na mesma tabela. Criar em vez disso, outra tabela no primeiro formulário normal, eliminando o grupo de repetição (classe #), como mostrado 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 formulário normal: Eliminar dados REDUNDANTES

    Observe os valores classe # vários para cada aluno # valor na tabela acima. Classe # não é funcionalmente dependente aluno # (chave primária), portanto, esta relação não está na segunda forma normalizada.

    Duas tabelas a seguir demonstram a segunda forma normalizada:
        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 em KEY

    No último exemplo, avançados-sala (número do escritório do Supervisor) é funcionalmente dependente de atributo Supervisor. A solução é mover esse atributo da tabela Students para a tabela de professores, como mostrado 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 criar um banco de dados, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
234208ACC2000: "Noções básicas sobre design de banco de dados relacional" documento disponível no Centro de download
"Guia do desenvolvedor do FoxPro 2 A", Granada M. Ahlo Jr. et al páginas 220-225, catálogos de M & T, 1991

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

Propriedades

ID do artigo: 100139 - Última revisão: quinta-feira, 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 traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 100139
Aviso de Isenção de Responsabilidade sobre Conteúdo do KB Aposentado
Este artigo trata de produtos para os quais a Microsoft não mais oferece suporte. Por esta razão, este artigo é oferecido "como está" e não será mais atualizado.

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