Fundamentos do design de banco de dados

Fundamentos do design de banco de dados

Importante :  Este artigo foi traduzido por um sistema de tradução automática, leia o aviso de isenção de responsabilidade. Para sua referência, veja a versão em inglês deste artigo aqui.

Um banco de dados projetado corretamente oferece acesso às informações de atualizados e precisos. Como um design correto é essencial para atingir as metas em trabalhar com um banco de dados, investir o tempo necessário para aprender os princípios de um bom design faz sentido. No final, você é muito mais provável terminar com um banco de dados que atenda às suas necessidades e pode acomodar facilmente a alteração.

Este artigo fornece diretrizes para planejar um banco de dados da área de trabalho. Você aprenderá como decidir quais informações necessárias, como dividir essas informações em apropriado tabelas e colunas e como essas tabelas se relacionam entre si. Você deve ler este artigo antes de criar seu primeiro banco de dados da área de trabalho.

Importante : Access fornece experiências de design que permitem criar aplicativos de banco de dados para a Web. Várias considerações de design são diferentes ao criar para a Web. Este artigo não aborda design de aplicativo de banco de dados da Web. Para obter mais informações, consulte o artigo criar um banco de dados para compartilhar na Web.

Neste artigo

Alguns termos de banco de dados saber

O que é o design de banco de dados bom?

O processo de design

Determinar a finalidade do seu banco de dados

Localizando e organizando as informações necessárias

Dividir as informações em tabelas

Transformar itens de informações em colunas

Especificando chaves primárias

Criando as relações de tabela

Refinar o design

Aplicando as regras de normalização


Alguns termos de banco de dados saber

Access organiza as informações em tabelas: listas de linhas e colunas que lembra teclado de um contador ou uma planilha. Em um banco de dados simple, você pode ter apenas uma tabela. Para a maioria dos bancos de dados será necessário mais de um. Por exemplo, você pode ter uma tabela que armazena informações sobre produtos, outra tabela que armazena informações sobre pedidos e outra tabela com informações sobre clientes.

Imagem mostrando três tabelas em folhas de dados

Cada linha é chamada mais corretamente um registroe cada coluna, um campo. Um registro é uma maneira consistente e significativa para combinar informações sobre algo. Um campo é um único item de informações — um tipo de item que aparece em cada registro. Na tabela produtos, por exemplo, cada linha ou registro seria armazenar informações sobre um produto. Cada coluna ou campo contém algum tipo de informação sobre o produto, como seu nome ou o preço.

Início da página

O que é um bom design de banco de dados?

Certos princípios orientam o processo de design de banco de dados. O primeiro princípio é que informações duplicadas (também chamadas de dados redundantes) são ruins, porque ela desperdiça espaço e aumenta a probabilidade de erros e inconsistências. O segundo princípio é que a correção e a integridade de informações importantes. Se seu banco de dados contém informações incorretas, todos os relatórios extraem informações do banco de dados também conterá informações incorretas. Como resultado, qualquer decisões que você tomar que são baseadas nesses relatórios, em seguida, serão mal-informado.

Um design de banco de dados BOM é, portanto, um que:

  • Divide suas informações em tabelas baseadas em assunto para reduzir dados redundantes.

  • Fornece acesso com as informações que ele necessita para unir as informações nas tabelas conforme necessário.

  • Ajuda de suporte e garantir a precisão e a integridade de suas informações.

  • Acomoda seu processamento de dados e necessidades de relatório.

Início da página

O processo de design

O processo de design consiste as seguintes etapas:

  • Determinar a finalidade do seu banco de dados   

    Isso ajuda a prepará-lo para as etapas restantes.

  • Localizar e organizar as informações necessárias   

    Colete todos os tipos de informações que você talvez queira gravar no banco de dados, como o número de nome e ordem de produto.

  • Dividir as informações em tabelas   

    Divida seus itens de informações em entidades principais ou assuntos, como produtos ou pedidos. Cada assunto então se torna a uma tabela.

  • Transformar itens de informações em colunas   

    Decida quais informações você deseja armazenar em cada tabela. Cada item se torne um campo e é exibido como uma coluna na tabela. Por exemplo, uma tabela Funcionários pode conter campos como sobrenome e data de contratação.

  • Especificar chaves primárias   

    Escolha a chave primária de cada tabela. A chave primária é uma coluna que é usada para identificar exclusivamente cada linha. Um exemplo pode ser ID do produto ou ID do pedido.

  • Configurar as relações de tabela   

    Examine cada tabela e decidir como os dados em uma tabela estão relacionados a dados em outras tabelas. Adicionar campos a tabelas ou criar novas tabelas para esclarecer as relações, conforme necessário.

  • Refine sua estrutura   

    Analise o design de erros. Criar tabelas e adicione alguns registros de dados de exemplo. Veja se você pode obter os resultados desejados de suas tabelas. Fazer ajustes no design, conforme necessário.

  • Aplicar as regras de normalização   

    Aplique as regras de normalização de dados para ver se suas tabelas são estruturadas corretamente. Fazer ajustes as tabelas, conforme necessário.

Início da página

Determinar a finalidade do seu banco de dados

É uma boa ideia Anote a finalidade do banco de dados em papel — sua finalidade, como você pretende usá-lo e quem o utilizará. Para um banco de dados pequeno para uma empresa com base inicial, por exemplo, você poderá escrever algo simples como "o banco de dados do cliente mantém uma lista de informações do cliente para produzir correspondências e relatórios." Se o banco de dados é mais complexo ou é usado por muitas pessoas, como geralmente ocorre em uma configuração corporativa, a finalidade poderia facilmente ser um parágrafo ou mais e deve incluir quando e como cada pessoa usarão o banco de dados. A ideia é ter uma missão bem desenvolvido que pode ser referenciada em todo o processo de design. Tendo tal uma instrução ajuda a enfocar suas metas ao tomar decisões.

Início da página

Localizando e organizando as informações necessárias

Para localizar e organizar as informações necessárias, comece com suas informações existentes. Por exemplo, você pode gravar ordens de compra em uma razão ou manter informações de cliente em formulários de papel em um arquivo de gabinete. Coletar esses documentos e listar cada tipo de informação mostrado (por exemplo, cada caixa que você deseja preencher um formulário). Se você não tiver formulários existentes, em vez disso, imagine que você precisa criar um formulário para gravar as informações do cliente. Quais informações você colocou no formulário? Quais caixas Fill-in você criaria? Identifique e liste cada um desses itens. Por exemplo, suponha que você atualmente manter a lista de clientes em cartões de índice. Examinar esses cartões pode mostrar que cada cartão contém um nome de clientes, endereço, cidade, estado, CEP e número de telefone. Cada um desses itens representa uma coluna possível em uma tabela.

Como preparar esta lista, não se preocupe obtendo-perfeito a primeira. Em vez disso, cada item que vem à mente de lista. Se alguém usarão o banco de dados, pedir suas ideias, também. Você pode ajustar a lista mais tarde.

Em seguida, considere os tipos de relatórios ou correspondências que talvez você queira produzir do banco de dados. Por exemplo, convém um relatório de vendas de produto para mostrar as vendas por região ou um relatório de resumo de inventário que mostra os níveis de estoque de produtos. Você também pode querer gerar cartas enviar aos clientes que anunciar um evento de venda ou oferece um premium. Criar o relatório de ideia e imagine como ele ficaria. Quais informações você colocar no relatório? Cada item de lista. Faça o mesmo para a letra do formulário e para qualquer outro relatório que você prevê criando.

uma pessoa imaginando um relatório de inventário de produto

Concedendo considerados os relatórios e correspondências que talvez você queira criar ajuda você a identificar os itens que você precisará em seu banco de dados. Por exemplo, suponha que você dar aos clientes a oportunidade de optar por usar em para (ou ausência) atualizações de email periódicos e você deseja imprimir uma listagem de aqueles que aceitaram. Para registrar essas informações, você adicionar uma coluna "Enviar email" à tabela de cliente. Para cada cliente, você pode definir o campo para Sim ou não.

O requisito de enviar mensagens de email aos clientes sugere outro item para gravar. Quando você souber que um cliente deseja receber mensagens de email, você também precisa saber o endereço de email para a qual enviá-los. Portanto, você precisa gravar um endereço de email para cada cliente.

Faz sentido boa para construir um protótipo de cada relatório ou listagem de saída e considerar os itens que você precisará gerar o relatório. Por exemplo, quando você examinar uma carta modelo, algumas coisas que talvez vêm à mente. Se você deseja incluir uma saudação adequada — por exemplo, a cadeia "SR.", "Sra." ou "MS." que inicia uma saudação, será necessário criar um item de saudação. Além disso, você normalmente pode iniciar uma carta com "Caro SR. Silva" em vez de "caro. SR. Sylvester Silva". Isso sugere que você geralmente deseja armazenar o sobrenome separado do primeiro nome.

Um ponto importante a lembrar é que você deve dividir cada parte das informações em suas menores partes úteis. No caso de um nome, para disponibilizar o sobrenome prontamente, você desconectará o nome em duas partes — nome e sobrenome. Para classificar um relatório por sobrenome, por exemplo, ele ajuda a ter o nome do cliente último armazenado separadamente. Em geral, se você deseja classificar, pesquisar, calcular ou relatório baseado em um item de informação, você deve colocar o item no seu próprio campo.

Pense sobre as perguntas que você pode querer o banco de dados para responder. Por exemplo, quantas vendas do produto em destaque fechar último mês? Onde os seus melhores clientes ao vivo? Quem é o fornecedor de seus produtos mais vendidos? Antecipar essas perguntas ajuda a zero em itens adicionais para gravar.

Depois de reunir essas informações, você está pronto para a próxima etapa.

Início da página

Dividir as informações em tabelas

Para dividir as informações em tabelas, escolha os principais entidades ou assuntos. Por exemplo, após localizar e organizar as informações para um banco de dados de vendas do produto, na lista preliminar talvez esta aparência:

Itens de informações manuscritas agrupados em assuntos

As principais entidades mostradas aqui estão os produtos, fornecedores, clientes e pedidos. Portanto, faz sentido para começar com esses quatro tabelas: uma para fatos sobre produtos, para fatos sobre fornecedores, uma para fatos sobre clientes e outra para fatos sobre pedidos. Embora isso não concluir a lista, é um bom ponto de partida. Você pode continuar a refinar esta lista até que você tenha um design que funciona bem.

Ao revisar a lista preliminar de itens pela primeira vez, você poderá ficar tentado colocá-los em uma única tabela, em vez de quatro mostradas na ilustração anterior. Você aprenderá Veja por que isso é uma ideia incorreta. Considere por um momento, a tabela mostrada aqui:

Uma imagem mostrando uma tabela com produtos e fornecedores

Nesse caso, cada linha contém informações sobre o produto e seus fornecedores. Como você pode ter vários produtos do mesmo fornecedor, as informações de nome e endereço do fornecedor deve ser repetidas várias vezes. Isso desperdiça espaço em disco. Registrar as informações de fornecedor apenas uma vez em uma tabela de fornecedores separada e, em seguida, vinculando dessa tabela à tabela produtos, é uma solução muito melhor.

Um segundo problema com este design vem quando você precisa modificar informações sobre o fornecedor. Por exemplo, suponha que você precisa alterar o endereço do fornecedor. Como ele aparece em vários lugares, talvez você acidentalmente alterar o endereço em um só lugar mas esquecer alterá-lo em outros. Endereço do fornecedor de gravação somente em um local resolve o problema.

Quando você cria seu banco de dados, tente sempre gravar cada fato apenas uma vez. Se você achar que se repetindo as mesmas informações em mais de um lugar, como o endereço de um determinado fornecedor, coloque essas informações em uma tabela separada.

Finalmente, suponha que há apenas um produto fornecido pelo Vinícola Coho e você quiser excluir o produto, mas manter as informações de nome e endereço do fornecedor. Como você faria excluir o registro de produto sem perder também as informações de fornecedor? Não é possível. Como cada registro contém fatos sobre um produto, bem como fatos sobre um fornecedor, você não pode excluir um sem excluir o outro. Para manter esses fatos separados, você deverá dividir uma tabela em dois: uma tabela para obter informações de produto e outra tabela para obter informações de fornecedor. Excluir um registro de produto deve excluir somente os fatos sobre o produto, não fatos sobre o fornecedor.

Depois que você escolheu o assunto que é representado por uma tabela, colunas na tabela devem armazenar fatos apenas sobre o assunto. Por exemplo, a tabela produto deve armazenar fatos apenas sobre produtos. Porque o endereço do fornecedor é um fato sobre fornecedor e não um fato sobre o produto, ele pertence na tabela fornecedor.

Início da página

Transformar itens de informações em colunas

Para determinar as colunas em uma tabela, decida quais informações você precisa controlar sobre o assunto registrado na tabela. Por exemplo, para a tabela clientes, nome, endereço, City-State-Zip, enviar email, saudação e endereço de email compreendem uma boa lista inicial das colunas. Cada registro na tabela contém o mesmo conjunto de colunas, para que você pode armazenar nome, endereço, City-State-Zip, enviar um email, email e saudação informações de endereço para cada registro. Por exemplo, a coluna de endereços contém endereços dos clientes. Cada registro contém dados sobre um cliente e o campo Endereço contém o endereço do cliente.

Depois de ter determinado conjunto inicial de colunas para cada tabela, você pode refinar as colunas. Por exemplo, faz sentido para armazenar o nome do cliente como duas colunas separadas: nome e sobrenome, para que você possa classificar, pesquisar e indexar em apenas as colunas. Da mesma forma, o endereço consiste em cinco componentes separados, endereço, cidade, estado, CEP e país/região, e também faz sentido armazená-las em colunas separadas. Se você quiser realizar uma pesquisa, a operação de filtragem ou classificação por estado, por exemplo, você precisa das informações de estado armazenadas em uma coluna separada.

Você também deve considerar se o banco de dados conterá informações de origem doméstica somente ou internacional, também. Por exemplo, se você planeja armazenar endereços internacionais, é melhor ter uma coluna de região em vez de estado, pois esse tipo de coluna pode acomodar estados domésticos e as regiões de outros países/regiões. Da mesma forma, o código Postal faz mais sentido que CEP, se você fizer para armazenar endereços internacionais.

A lista a seguir mostra algumas dicas para determinar as colunas.

  • Não inclua dados calculados   

    Na maioria dos casos, você não deve armazenar o resultado dos cálculos em tabelas. Em vez disso, você pode ter acesso executam os cálculos quando desejar ver o resultado. Por exemplo, suponha que existe em um relatório de produtos em ordem que exibe o subtotal de unidades na ordem para cada categoria de produto no banco de dados. No entanto, não há nenhuma coluna subtotal unidades na ordem em qualquer tabela. Em vez disso, a tabela de produtos inclui uma coluna de unidades na ordem que armazena as unidades na ordem para cada produto. Usando dados, Access calcula o subtotal sempre que você imprimir o relatório. Subtotal em si não deve ser armazenado em uma tabela.

  • Armazenar informações em suas menores partes lógicas   

    Você pode ficar tentado tenham um único campo para nomes completos ou para nomes de produto junto com descrições de produto. Se você combinar mais de um tipo de informações em um campo, é difícil recuperar fatos individuais posteriormente. Tente dividir informações em partes lógicas; Por exemplo, crie campos separados para nome e sobrenome ou por nome de produto, categoria e descrição.

Imagem mostrando itens de informações durante o processo de design

Quando você tiver refinado as colunas de dados em cada tabela, você estará pronto para escolher a chave primária de cada tabela.

Início da página

Especificando chaves primárias

Cada tabela deve incluir uma coluna ou um conjunto de colunas que identifica exclusivamente cada linha armazenada na tabela. Isso geralmente é um número de identificação exclusivo, como um número de ID do funcionário ou um número de série. Na terminologia de banco de dados, essas informações são chamadas de chave primária da tabela. Access usa campos de chave primária para associar dados de várias tabelas rapidamente e reunir os dados para você.

Se você já tiver um identificador exclusivo para uma tabela, como um número de produto que identifica exclusivamente cada produto em seu catálogo, você pode usar esse identificador como chave primária da tabela — mas apenas se os valores desta coluna sempre será diferentes para cada registro. Você não pode ter valores duplicados em uma chave primária. Por exemplo, não use nomes de pessoas como uma chave primária, pois os nomes não são exclusivos. Você poderia facilmente ter duas pessoas com o mesmo nome na mesma tabela.

Uma chave primária sempre deve ter um valor. Se o valor de uma coluna pode se tornar sem alocação ou desconhecido (um valor ausente) em algum momento, ele não pode ser usado como um componente em uma chave primária.

Você deve sempre selecionar uma chave primária cujo valor não mudará. Em um banco de dados que usa mais de uma tabela, chave primária de uma tabela pode ser usada como uma referência em outras tabelas. Se a chave primária for alterado, a alteração deve também ser aplicada todos os lugares em que a chave é referenciada. Usando uma chave primária que não serão alteradas reduz a chance de que a chave primária poderá ficar fora de sincronia com outras tabelas que fazem referência a ele.

Muitas vezes, um número aleatório de exclusivo é usado como chave primária. Por exemplo, você pode atribuir cada pedido um número de ordem exclusivo. Única finalidade do número ordem é identificar um pedido. Depois de atribuir, nunca é alterado.

Se você não tiver em mente uma coluna ou um conjunto de colunas que podem fazer com uma boa chave primária, considere o uso de uma coluna que tem o tipo de dados numeração automática. Quando você usa o tipo de dados numeração automática, o Access atribuirá automaticamente um valor para você. Tal identificador é factless; ele contém nenhuma informação reais descrevendo a linha que ele representa. Identificadores factless são ideais para ser usado como uma chave primária, pois elas não forem alterados. Uma chave primária que contém fatos sobre uma linha — um número de telefone ou um cliente nome, por exemplo — é mais provável alterar, porque as informações reais em si podem mudar.

Imagem mostrando tabela Produtos com um campo de chave primária

1. uma coluna definida para o tipo de dados numeração automática geralmente faz uma boa chave primária. Sem IDs de produto de dois são os mesmos.

Em alguns casos, talvez você queira usar dois ou mais campos que, juntas, oferecem a chave primária de uma tabela. Por exemplo, uma tabela Detalhes do pedido que armazena itens de linha para pedidos usaria duas colunas em sua chave primária: ID do pedido e ID do produto. Quando uma chave primária utiliza mais de uma coluna, ele também é chamado de chave composta.

Para o banco de dados de vendas do produto, você pode criar uma coluna de numeração automática para cada uma das tabelas para servir como chave primária: ProductID da tabela de produtos, CódigoDoPedido para as ordens de tabela, CustomerID para a tabela clientes e CódigoDoFornecedor para a tabela de fornecedores.

Imagem mostrando itens de informações durante o processo de design


Início da página

Criando as relações de tabela

Agora que você tiver dividido suas informações em tabelas, você precisa de uma maneira de reunir as informações novamente em sentido. Por exemplo, o seguinte formulário inclui informações de várias tabelas.

O formulário de Pedido

1. As informações desse formulário são originárias da tabela Clientes...

2. … tabela de funcionários aumentam...

3.... tabela de pedidos de aumentam...

4.... aumentam tabela de produtos...

5.... e tabela Detalhes do pedido.

Acesso é um sistema de gerenciamento de banco de dados relacional. Em um banco de dados relacional, divida as informações em tabelas separadas, com base no assunto. Você usar relações de tabela para reunir as informações conforme necessário.

Início da página

Criar uma relação um-para-muitos

Considere este exemplo: as tabelas fornecedores e produtos no produto ordens de banco de dados. Um fornecedor pode fornecer qualquer número de produtos. Ela segue que para qualquer fornecedor representado na tabela fornecedores, pode haver vários produtos representados na tabela produtos. A relação entre a tabela fornecedores e a tabela Produtos é, portanto, uma relação um-para-muitos.

conceitual um para vários

Para representar uma relação um-para-muitos em seu design de banco de dados, faça a chave primária no lado "um" da relação e adicioná-lo como uma coluna adicional ou colunas à tabela no lado "muitos" da relação. Nesse caso, por exemplo, você adicionar a coluna ID do fornecedor da tabela fornecedores à tabela produtos. Access, em seguida, pode usar o número de identificação de fornecedor na tabela Produtos para localizar o fornecedor correto para cada produto.

A coluna ID do fornecedor na tabela Produtos é chamada de chave estrangeira. Uma chave estrangeira é a chave primária de outra tabela. A coluna de ID de fornecedor na tabela Produtos é uma chave estrangeira porque ele também é a chave primária na tabela fornecedores.

Imagem mostrando itens de informações durante o processo de design

Fornecem a base para ingressar em tabelas relacionadas, estabelecendo pares de chaves primárias e chaves estrangeiras. Se você não tiver certeza de quais tabelas devem compartilhar uma coluna comum, identificar uma relação um-para-muitos garante que as duas tabelas envolvidas, na verdade, exigirá uma coluna compartilhada.

Início da página

Criando um relacionamento muitos-para-muitos

Considere a relação entre a tabela de produtos e a tabela Pedidos.

Uma única ordem pode incluir mais de um produto. Por outro lado, um único produto pode aparecer em muitos pedidos. Portanto, para cada registro na tabela Pedidos, pode haver muitos registros na tabela produtos. E para cada registro na tabela produtos, pode haver muitos registros na tabela Pedidos. Esse tipo de relação é chamado uma relação muitos-para-muitos porque qualquer produto, pode haver vários pedidos; e para qualquer ordem, pode haver vários produtos. Observe que para detectar relações de muitos-para-muitos entre suas tabelas, é importante considerar a ambos os lados da relação.

Os assuntos das duas tabelas — Pedidos e produtos — têm uma relação muitos-para-muitos. Isso apresenta um problema. Para entender o problema, imagine o que acontecerá se você tentou criar a relação entre as duas tabelas adicionando o campo de ID do produto para a tabela Orders. Para ter mais de um produto por ordem, você precisa de mais de um registro na tabela Pedidos por ordem. Você prefere repetindo informações do pedido para cada linha que se relacionam com uma única ordem — resulta em um design ineficaz que pode levar a dados incorretos. Você enfrentar o mesmo problema se você colocar o campo ID do pedido na tabela produtos — você teria mais de um registro da tabela de produtos para cada produto. Como resolver esse problema?

A resposta é criar uma terceira tabela, muitas vezes chamada de uma tabela de junção, que divide a relação de muitos-para-muitos em dois relacionamentos um-para-muitos. Insira a chave primária de cada uma das duas tabelas na terceira tabela. Como resultado, a terceira tabela registros cada ocorrência ou instância da relação.

a many-to-many relationship

Cada registro na tabela Detalhes do pedido representa um item de linha em uma ordem. Chave primária da tabela Detalhes do pedido consiste em dois campos — as chaves externas das tabelas Pedidos e as produtos. Usando o campo de ID do pedido sozinho não funciona como chave primária desta tabela, como um pedido pode ter muitos itens de linha. A ID do pedido será repetido para cada item de linha em uma ordem, para que o campo não contiver valores exclusivos. Usando o campo de ID do produto sozinho não funcionará, porque um produto pode aparecer em muitos pedidos diferentes. Mas juntos, os dois campos sempre produzem um valor exclusivo para cada registro.

No banco de dados de vendas do produto, a tabela Pedidos e a tabela produtos não estão relacionados entre si diretamente. Em vez disso, elas estão relacionadas indiretamente por meio de tabela Detalhes do pedido. A relação de muitos-para-muitos entre pedidos e produtos é representada no banco de dados usando dois relacionamentos um-para-muitos:

  • A tabela Pedidos e a tabela Detalhes do pedido têm uma relação um-para-muitos. Cada pedido pode ter mais de um item de linha, mas cada item de linha está conectado a apenas um pedido.

  • A tabela Produtos e tabela Detalhes do pedido têm uma relação um-para-muitos. Cada produto pode ter muitos itens de linha associados a ele, mas cada item de linha se refere a apenas um produto.

Na tabela Detalhes do pedido, você pode determinar todos os produtos em uma ordem específica. Você também pode determinar todos os pedidos de um produto específico.

Após incorporar tabela Detalhes do pedido, a lista de tabelas e campos poderia ser algo parecido com isto:

Imagem mostrando itens de informações durante o processo de design


Início da página

Criando um relacionamento de um-para-um

Outro tipo de relação é o relacionamento de um para um. Por exemplo, suponha que você precise gravar algumas informações de produto suplementares especial que você precisará raramente ou que se aplica somente a alguns produtos. Como as informações muitas vezes não é necessário, e armazenar as informações na tabela Produtos resultaria em um espaço vazio para cada produto para que ele não se aplica, coloque-o em uma tabela separada. Como a tabela de produtos, você pode usar o ProductID como chave primária. A relação entre essa tabela complementar e a tabela produto é um relacionamento individual. Para cada registro na tabela Product, existe um único registro correspondente na tabela complementar. Quando você identificar tal relação, ambas as tabelas devem compartilhar um campo comum.

Quando você detectar a necessidade de um relacionamento individual em seu banco de dados, considere se você pode colocar as informações das duas tabelas juntos em uma tabela. Se você não quiser fazer isso por algum motivo, talvez porque resultaria em um lote de espaço vazio, a lista a seguir mostra como você faria representam a relação em seu design:

  • Se as duas tabelas com o mesmo assunto, você pode provavelmente configurar a relação usando a mesma chave primária nas tabelas.

  • Se as duas tabelas tem assuntos diferentes com diferentes chaves primárias, escolha uma das tabelas (uma das duas) e inserir sua chave primária em outra tabela como chave estrangeira.

Determinar os relacionamentos entre tabelas ajuda você a garantir que você tenha certas tabelas e colunas. Quando existe uma relação de um para um ou um-para-muitos, as tabelas envolvidas necessário compartilhar um ou mais colunas comuns. Quando existe uma relação muitos-para-muitos, uma terceira tabela é necessária para representar a relação.

Início da página

Refinar o design

Quando você tiver as tabelas, campos e relações necessárias, você deve criar e preencher suas tabelas com dados de exemplo e tente trabalhar com as informações: criação de consultas, adicionar novos registros e assim por diante. Isso ajuda a destacar possíveis problemas — por exemplo, talvez você precise adicionar uma coluna que você esqueceu de inserir durante a fase de design, ou você pode ter uma tabela que deve ser dividida em duas tabelas para remover a duplicação.

Ver se você pode usar o banco de dados para obter as respostas que deseja. Crie rascunhos de seus formulários e relatórios e veja se eles apresentam os dados que você espera. Procure por duplicação desnecessária de dados e, quando você encontrar qualquer, alterar seu design para eliminá-lo.

Conforme você experimentar o seu banco de dados inicial, você provavelmente descobrirá melhorar. Aqui estão algumas coisas para verificar:

  • Você esqueceu quaisquer colunas? Em caso afirmativo, as informações pertencem as tabelas existentes? Se for informações sobre algo, você talvez precise criar outra tabela. Crie uma coluna para cada item de informações que você precisa acompanhar. Se as informações não podem ser calculadas de outras colunas, é provável que você precisará de uma nova coluna para ele.

  • São quaisquer colunas desnecessários porque eles podem ser calculados a partir de campos existentes? Se um item de informações pode ser calculado a partir de outras colunas existentes — desconto calculado a partir do preço de varejo, por exemplo — é geralmente melhor fazer isso e evitar a criação de nova coluna.

  • É você repetidamente inserindo informações duplicadas em uma de suas tabelas? Nesse caso, você provavelmente precisará dividir a tabela em duas tabelas que têm uma relação um-para-muitos.

  • Você tem tabelas com muitos campos, um número limitado de registros e muitos campos vazios nos registros individuais? Em caso afirmativo, pense redimensionando a tabela para que ele tenha menos campos e registros mais.

  • Cada item de informações foi dividida em suas menores partes útil? Se você precisar de relatórios, classificar, pesquisar ou calcular em um item de informação, coloque esse item em sua própria coluna.

  • Cada coluna que contém um fato sobre o assunto da tabela? Se uma coluna não contiver informações sobre o assunto da tabela, ele pertence em uma tabela diferente.

  • São todas as relações entre tabelas representadas, por campos comuns ou por uma terceira tabela? Relações individual e um-para-muitos exigem colunas em comum. Relações de muitos-para-muitos exigem uma terceira tabela.

Refinar a tabela produtos

Suponha que cada produto do banco de dados de vendas de produto esteja em uma categoria geral, como Bebidas, Condimentos ou frutos. A tabela Produtos pode incluir um campo que mostra a categoria de cada produto.

Suponha que após examinando e refinar o design do banco de dados, você decidir armazenar uma descrição da categoria junto com seu nome. Se você adicionar um campo de descrição de categoria à tabela produtos, você precisa repetir a descrição de cada categoria para cada produto que está sob a categoria — isso não é uma boa solução.

Uma solução melhor é fazer um novo assunto do banco de dados para acompanhar, com sua própria tabela e sua própria chave primária de categorias. Em seguida, você pode adicionar a chave primária da tabela categorias à tabela produtos como chave estrangeira.

As tabelas de categorias e produtos têm uma relação um-para-muitos: uma categoria pode incluir mais de um produto, mas um produto pode pertencer a apenas uma categoria.

Ao revisar suas estruturas de tabela, fique atento para grupos de repetição. Por exemplo, considere uma tabela que contém as seguintes colunas:

  • ID do Produto (Product ID)

  • Nome

  • ID1 de produto

  • Nome1

  • ID2 do produto

  • Nome2

  • ID3 de produto

  • Nome3

Aqui, cada produto é um grupo de repetição de colunas que é diferente dos outros apenas adicionando um número para o final do nome da coluna. Quando você vir colunas numeradas dessa maneira, você deve verificar o design.

Como um design possui várias falhas. Para começar, ele força você a colocar um limite superior no número de produtos. Assim que você exceder esse limite, é necessário adicionar um novo grupo de colunas para a estrutura da tabela, que é uma tarefa administrativa principal.

Outro problema é que esses fornecedores que têm menos do número máximo de produtos perderá espaço, desde que as colunas adicionais estará em branco. A falha mais séria com tal um design é que ela torna muitas tarefas difíceis de executar, como classificação ou a tabela por ID do produto ou nome de indexação.

Sempre que você consulte grupos Revise o projeto estreitamente com atenção na divisão a tabela em duas de repetição. No exemplo acima é melhor usar duas tabelas, uma para fornecedores e outra para produtos, vinculadas por ID de fornecedor.

Início da página

Aplicando as regras de normalização

Você pode aplicar as regras de normalização de dados (às vezes chamadas regras de normalização) como a próxima etapa no design. Você pode usar essas regras para ver se suas tabelas são estruturadas corretamente. O processo de aplicar as regras para o design do banco de dados é chamado Normalizando o banco de dados, ou apenas normalização.

Normalização é mais útil depois de ter representados todos os itens de informações e chegou a um design preliminar. A ideia é para ajudá-lo a garantir que você tenha dividido seus itens de informações em tabelas apropriadas. Quais normalização não pode fazer é garantir que você tenha começar com todos os itens de dados corretos.

Você aplicar as regras sucessivamente, cada etapa assegurar que seu design chega em um dos quais é conhecido como os "formulários normais". Cinco formulários normais são amplamente aceitas — o primeiro formulário normal por meio do quinto formulário normal. Este artigo explica as três primeiras, porque eles são tudo o que é necessário para a maioria dos designs de banco de dados.

Primeiro formulário normal

Primeiro formulário normal informa que em cada interseção de linha e coluna na tabela, existe um único valor e nunca uma lista de valores. Por exemplo, você não pode ter um campo denominado preço nas quais você colocar mais de um preço. Se você acha de cada interseção de linhas e colunas como uma célula, cada célula pode conter apenas um valor.

Segundo formulário normal

Segundo formulário normal requer que cada coluna não-chave seja totalmente dependentes em toda a chave primária, não em apenas uma parte da chave. Essa regra se aplica quando você tem uma chave primária consiste em mais de uma coluna. Por exemplo, suponha que você tenha uma tabela que contém as seguintes colunas, onde ID do pedido e ID do produto formam a chave primária:

  • ID do pedido (chave primária)

  • ID do produto (chave primária)

  • Nome do produto

Este design viola segunda forma normal, porque o nome do produto depende em ID do produto, mas não em ID do pedido, portanto, não é dependente da chave primária inteira. Você deve remover o nome de produto da tabela. Ele pertence em uma tabela diferente (produtos).

Terceira forma normal

Terceira forma normal requer que não apenas cada coluna não-chave ser dependente toda a chave primária, mas que colunas não chave ser independentes uns dos outros.

Outra maneira de dizer isso é que cada coluna não-chave deve ser dependente na chave primária e nada, mas a chave primária. Por exemplo, suponha que você tenha uma tabela que contém as seguintes colunas:

  • ID do produto (chave primária)

  • Nome

  • SRP

  • Desconto

Suponha que desconto depende o preço de varejo sugerido (SRP). Esta tabela viola terceiro normal do formulário como uma coluna não-chave, desconto, depende de outra coluna de não-chave, SRP. Independência de coluna significa que você deve ser capaz de alterar qualquer coluna não-chave sem afetar qualquer outra coluna. Se você alterar um valor no campo SRP, o desconto altere adequadamente, portanto violar dessa regra. Nesse caso desconto deve ser movido para outra tabela que é configurada no SRP.

Início da página

Observação : Aviso de Isenção de Tradução Automática: Este artigo foi traduzido por computador, sem intervenção humana. A Microsoft oferece essas traduções automáticas para ajudar as pessoas que não falam inglês a aproveitar os textos escritos sobre produtos, serviços e tecnologias da Microsoft. Como este artigo foi traduzido automaticamente, é possível que contenha erros de vocabulário, sintaxe ou gramática.

Expanda suas habilidades
Explore o treinamento
Obtenha novos recursos primeiro
Ingressar no Office Insider

Essas informações foram úteis?

Obrigado por seus comentários!

Agradecemos pelos seus comentários! Parece que pode ser útil conectar você a um de nossos agentes de suporte do Office.

×