DetailPage-MSS-KB

Base de Dados de Conhecimento

ID do artigo: 209534 - Última revisão: sexta-feira, 6 de agosto de 2004 - Revisão: 2.2

 
Iniciante: Requer conhecimento da interface do usuário em computadores de usuário único.

Para uma versão deste artigo do Microsoft Access 97, consulte 100139  (http://support.microsoft.com/kb/100139/EN-US/ ) .
Para uma versão deste artigo do Microsoft Access 2002, consulte 283878  (http://support.microsoft.com/kb/283878/EN-US/ ) .

Nesta página

Sumário

Este artigo explica terminologia de normalização de banco de dados para iniciantes. 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 (http://support.microsoft.com/?scid=http%3a%2f%2fsupport.microsoft.com%2fservicedesks%2fwebcasts%2fwc060600%2fwc060600.asp%3ffr%3d1)
Para obter informações adicionais sobre esse tópico em uma versão anterior do Access, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
100139  (http://support.microsoft.com/kb/100139/ ) Noções básicas sobre normalização de banco de dados

Mais Informações

Descrição da normalização

Normalização é o processo de organizar dados em um banco de dados. Isso inclui a criação de tabelas e estabelecer relacionamentos entre essas tabelas acordo com a regras projetadas para proteger os dados e tornar o banco de dados mais flexíveis, eliminando 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 porque 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.

As seguintes descrições 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.

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.

Segunda forma normalizada

  • 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, ou no Customers tabela ou em um endereços separada da tabela.

Terceira forma normalizada

  • 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 um funcionário recrutamento tabela, Universidade nome 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, a normalização vale pursing. 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.

Outras formas 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.

Normalizando uma tabela de exemplo

Essas etapas demonstram o processo de normalizando uma tabela de aluno fictícios.
  1. Tabela unnormalized:
    Recolher esta tabelaExpandir esta tabela
    Aluno #SupervisorSala avançadosClass1Classe2Class3
    1022Jones412101-07143-01159-02
    4123Smith216201-01211-02214-01
  2. Primeiro formulário normal: Nenhuma repetição grupos

    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 e Class3 nos registros 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. Em vez disso, crie outra tabela na primeira forma normalizada, eliminando o grupo de repetição (classe #), como mostrado abaixo:
    Recolher esta tabelaExpandir esta tabela
    Aluno #SupervisorSala avançadosClasse #
    1022Jones412101-07
    1022Jones412143-01
    1022Jones412159-02
    4123Smith216201-01
    4123Smith216211-02
    4123Smith216214-01
  3. Segundo formulário normal: Eliminar dados redundantes

    Observe os valores classe # vários para cada aluno # valor na tabela acima. Classe # não está funcionalmente dependentes aluno # (chave primária), portanto, essa relação não está no formulário segundo normal.

    Duas tabelas a seguir demonstram o segundo formulário normal:

    Alunos

    Recolher esta tabelaExpandir esta tabela
    Aluno #SupervisorSala avançados
    1022Jones412
    4123Smith216

    Registro

    Recolher esta tabelaExpandir esta tabela
    Aluno #Classe #
    1022101-07
    1022143-01
    1022159-02
    4123201-01
    4123211-02
    4123214-01
  4. Terceira forma normal: Eliminar dados não dependentes na chave

    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:

    Alunos

    Recolher esta tabelaExpandir esta tabela
    Aluno #Supervisor
    1022Jones
    4123Smith

    Corpo docente

    Recolher esta tabelaExpandir esta tabela
    NomeSalaDEP
    Jones41242
    Smith21642

Referências

Ahlo, Granada M., Brown Randy e Peter Colclough. FoxPro 2: guia do desenvolvedor A: guia de especialista para programação de nível industrial . John Wiley & Sons, outubro de 1991. 220 Páginas-225.

Jennings, Roger. usando o Access 1.1 para Windows . Corporation, julho de 1993. 799 Páginas-800.

A informação contida neste artigo aplica-se a:
  • Microsoft Access 2000 Standard Edition
Palavras-chave: 
kbmt kbdatabase kbdesign kbinfo kbusage KB209534 KbMtpt
Tradução automáticaTraduçã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: 209534  (http://support.microsoft.com/kb/209534/en-us/ )
Compartilhar
Opções de suporte adicionais
Fóruns de Suporte do Microsoft Community
Contate-nos diretamente
Localize um parceiro certificado da Microsoft
Microsoft Store