Descrição das noções básicas de normalização de base de dados

O suporte para o Office 2003 terminou

A Microsoft terminou o suporte para o Office 2003 em 8 de Abril de 2014. Esta alteração afetou as suas atualizações de software e opções de segurança. Aprenda o que isto significa para si e como pode ficar protegido.

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: 283878
Principiante: Requer conhecimentos da interface do utilizador em computadores individuais.

Para obter uma versão do Microsoft Access 2000 deste artigo, consulte 209534.
Para um Microsoft Access 95 ou uma versão do Microsoft Access 97 deste artigo, consulte 100139.
Sumário
Este artigo explica a terminologia de normalização de base de dados para os principiantes. Uma compreensão básica desta terminologia é útil quando discussão do projecto de base de dados relacional.

Nota: a Microsoft também disponibiliza uma WebCast que explica as noções básicas de normalização de base de dados. Para visualizar esta WebCast, visite o seguinte Web site da Microsoft:
Mais Informação

Descrição de normalização

Normalização é o processo de organizar dados numa base de dados. Isto inclui a criação de tabelas e estabelecer relações entre essas tabelas, de acordo com regras concebidas para proteger os dados e para tornar a base de dados mais flexível, através da eliminação da redundância e dependência inconsistente.

Dados redundantes desperdiçam espaço em disco e criam problemas de manutenção. Se os dados que existe mais do que um local tem de ser alterados, os dados devem ser alterados no 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 são armazenados apenas na tabela clientes e em base de dados de mais nenhum local.

O que é uma "dependência inconsistente"? Apesar de ser intuitivo para um utilizador procurar a tabela de clientes para o endereço de um determinado cliente, poderá não fazer sentido procurar, nessa tabela, o salário do funcionário que trabalha com esse cliente. O salário do funcionário está relacionado com, ou a cargo, o empregado e, por conseguinte, deve ser movido para a tabela Empregados. As dependências inconsistentes podem dificultar dados ao access porque o caminho para localizar os dados pode estar em falta ou interrompido.

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

Tal como acontece com muitas regras e especificações formais, cenários reais nem sempre permitem uma concordância. Em geral, a normalização requer mais tabelas e alguns clientes acham este procedimento confuso. Se decidir violar uma das três primeiras regras da normalização, certifique-se de que a sua aplicação antecipa quaisquer problemas que possam ocorrer, tais como dados redundantes e dependências inconsistentes.

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.
  • Identifica 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 monitorizar um item de inventário que pode ser proveniente de duas origens possíveis, um registo de inventário pode conter campos para código de fornecedor 1 e do código de fornecedor 2.

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

Segunda forma Normal

  • Crie tabelas separadas para conjuntos de valores que se aplicam os registos de tomultiple.
  • Relacionar estas tabelas com uma chave externa.
Os registos não devem depender de algo que não a 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. É necessário o endereço da 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, armazene-o num só 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 desse registo não pertencem na tabela. Em geral, sempre que o conteúdo de um grupo de campos pode aplicar a mais do que um único registo na tabela, considere a hipótese de colocar esses campos numa tabela separada.

Por exemplo, numa tabela de recrutamento de funcionários, nome da universidade e o endereço de um candidato podem ser incluídos. Mas tem uma lista completa de universidades para mensagens de grupo. Se informações sobre as universidades estiverem armazenado na tabela de candidatos, não é possível listar as universidades sem candidatos actuais. Criar uma tabela de universidades separada e ligá-lo para a tabela de candidatos com uma chave de código de universidade.

EXCEPÇÃO: A cumprir a terceira forma normal, embora teoricamente desejável, nem sempre é prática. Se tiver uma tabela clientes e pretender eliminar todas as dependências possíveis entre campos, tem de criar tabelas separadas para cidades, códigos postais, representantes de vendas, classes de clientes e qualquer outro factor que possa ser duplicado em múltiplos registos. Em teoria, a normalização é um objectivo a atingir. No entanto, muitas tabelas pequenas podem degradar o desempenho ou exceder o ficheiro aberto e capacidades de memória.

Poderá ser mais prático aplicar a terceira forma normal apenas aos dados que sejam frequentemente alterados. Se permanecerem alguns campos dependentes, Conceba a sua aplicação para requerer que o utilizador verificar se que todos os campos relacionados quando um campo é alterado.

Outros formulários de normalização

Quarta forma normal, também designada por Forma Normal de Boyce Codd (BCNF) e apesar da quinta forma normal existir, esta raramente é tida em consideração na concepção prática. Não tendo em conta estas regras podem resultar na estrutura de base de dados menos perfeita, mas não deve afectar a funcionalidade.

Normalizar uma tabela de exemplo

Estes passos demonstram o processo de normalização de uma tabela de estudantes fictícia.
  1. Tabela não normalizada:

    Estudante #AssistenteCons. Sala consClass1Aula2Class3
    1022Jones412101-07143-01159 02
    4123Silva216201-01211-02214-01
  2. Primeira forma Normal: Grupos repetitivos

    Tablesshould ter apenas duas dimensões. Uma vez que um estudante tem várias aulas, theseclasses devem ser listadas numa tabela separada. Campos Class1, Aula2 e Class3in dos registos acima são indicações de problemas de concepção.

    Spreadsheetsoften utilizar a terceira dimensão, mas não devem tabelas. Outra forma de procurar o problema de atthis com uma relação um-para-muitos, não coloque o lado um de e o lado do muitos na mesma tabela. Em vez disso, crie outra tabela na primeira normalform através da eliminação do grupo de repetição (classe #), conforme é ilustrado abaixo:

    Estudante #AssistenteCons. Sala consClasse #
    1022Jones412101-07
    1022Jones412143-01
    1022Jones412159 02
    4123Silva216201-01
    4123Silva216211-02
    4123Silva216214-01
  3. Segundo formulário Normal: Eliminar os dados redundantes

    Nota vários aula valores para cada aluno # valor na tabela acima. Classe # não is funcionalmente dependente de n (chave primária), pelo que este relationshipis não no segundo formulário normal.

    A seguintes duas tabelas demonstratesecond forma normal:

    Alunos:

    Estudante #AssistenteCons. Sala cons
    1022Jones412
    4123Silva216


    Registo:

    Estudante #Classe #
    1022101-07
    1022143-01
    1022159 02
    4123201-01
    4123211-02
    4123214-01
  4. Terceira forma Normal: Eliminar dados OnKey não dependente

    O último exemplo, isfunctionally (número de office o advisor) Cons. sala dependente no atributo classificação. A solução consiste em mover thatattribute a partir da tabela de estudantes para a tabela de universidades, tal como shownbelow:

    Alunos:

    Estudante #Assistente
    1022Jones
    4123Silva


    Faculdade:

    NomeSalaDept.
    Jones41242
    Silva21642
Modelo normal de relacional BCNF normalizar ACC2002 ACC2003

Aviso: Este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 283878 - Última Revisão: 02/02/2016 03:23:00 - Revisão: 10.0

Microsoft Office Access 2007, Microsoft Office Access 2003, Microsoft Access 2002 Standard Edition

  • kbinfo kbdesign kbdatabase kbhowto kbmt KB283878 KbMtpt
Comentários