Fundamentos do design de banco de dados

Fundamentos do design de banco de dados

Um banco de dados projetado corretamente fornece acesso às informações atualizadas e precisas. Como um design correto é essencial para alcançar suas metas em trabalhar com um banco de dados, investindo o tempo necessário para aprender os princípios de design bom faz sentido. Ao final, você tem muito mais probabilidade de acabar com um banco de dados que atenda às suas necessidades e pode facilmente acomodar as alterações.

Este artigo fornece diretrizes para planejar um banco de dados da área de trabalho. Você aprenderá a decidir quais informações são necessárias, como dividir essas informações nas tabelas e colunas apropriadas e como essas tabelas se relacionam umas com as outras. Você deve ler este artigo antes de criar seu primeiro banco de dados de área de trabalho.

Importante: Access fornece experiências de design que permitem criar aplicativos de banco de dados para a Web. Muitas considerações de design são diferentes quando você cria uma estrutura para a Web. Este artigo não aborda o design do 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 a serem conhecidos

O que é um bom design de banco de dados?

O processo de design

Como 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 tabelas

Refinar o design

Aplicando as regras de normalização


Alguns termos de banco de dados a serem conhecidos

Access organiza suas informações em tabelas: listas de linhas e colunas Reminiscent do painel de um contador ou de uma planilha. Em um banco de dados simples, você pode ter apenas uma tabela. Para a maioria dos bancos de dados, você precisará de 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 está mais corretamente chamada de registro, e cada coluna, um campo. Um registro é uma maneira significativa e consistente de combinar informações sobre algo. Um campo é um único item de informação — um tipo de item que aparece em todos os registros. Na tabela Produtos, por exemplo, cada linha ou registro teria as informações sobre um produto. Cada coluna ou campo contém algum tipo de informação sobre o produto, por exemplo, nome ou preço.

Início da Página

O que é um bom design de banco de dados?

Certos princípios orientam o processo de design do banco de dados. O primeiro princípio é que as informações duplicadas (também chamadas de dados redundantes) são ruins, porque desperdiça espaço e aumenta a probabilidade de erros e inconsistências. O segundo princípio é que a exatidão e a integridade das informações são importantes. Se o banco de dados contiver informações incorretas, os relatórios que receberem informações do banco de dados também conterá informações incorretas. Como resultado, todas as decisões feitas com base nesses relatórios serão informadas de forma incorreta.

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

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

  • Fornece acesso às informações necessárias para incluir as informações nas tabelas juntas, conforme necessário.

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

  • Acomoda suas necessidades de processamento de dados e relatórios.

Início da Página

O processo de design

O processo de design consiste nas seguintes etapas:

  • Determinar a finalidade do seu banco de dados    

    Isso ajuda a preparar você para as etapas restantes.

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

    Reúna todos os tipos de informações que você pode querer gravar no banco de dados, como nome do produto e número do pedido.

  • Dividir as informações em tabelas    

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

  • Transformar itens de informações em colunas    

    Decida quais informações você deseja armazenar em cada tabela. Cada item se torna um campo e é exibido como uma coluna na tabela. Por exemplo, uma tabela funcionários pode incluir 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 a ID do produto ou a ID do pedido.

  • Configurar relações de tabela    

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

  • Refine seu design    

    Analise seu design em busca de erros. Crie as tabelas e adicione alguns registros de dados de exemplo. Veja se você pode obter os resultados desejados de suas tabelas. Faça ajustes no design, conforme necessário.

  • Aplicar as regras de normalização    

    Aplique as regras de normalização de dados para ver se as tabelas estão estruturadas corretamente. Faça ajustes nas tabelas, conforme necessário.

Início da Página

Como determinar a finalidade do seu banco de dados

É uma boa ideia anotar a finalidade do banco de dados em papel — sua finalidade, como você espera usá-lo e quem vai usá-lo. Para um banco de dados pequeno para uma empresa com base em casa, por exemplo, você pode escrever algo simples, como "o banco de dados do cliente mantém uma lista das informações do cliente para a finalidade de produzir correspondências e relatórios." Se o banco de dados for mais complexo ou for usado por muitas pessoas, como ocorre geralmente em uma configuração corporativa, a finalidade pode ser um parágrafo ou mais, e deve incluir quando e como cada pessoa usará o banco de dados. A ideia é ter uma declaração de missão bem desenvolvida que possa ser referida durante todo o processo de design. Ter tal instrução ajuda você a se concentrar em seus objetivos quando 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 registrar pedidos de compra em um razão ou manter informações do cliente em formulários em papel em um gabinete de arquivos. Reúna esses documentos e liste cada tipo de informação mostrado (por exemplo, cada caixa que você preencher em um formulário). Se você não tiver formulários existentes, imagine, em vez disso, você precisa criar um formulário para registrar as informações do cliente. Quais informações você colocaria no formulário? Quais caixas de preenchimento você criaria? Identifique e liste cada um desses itens. Por exemplo, suponha que você atualmente mantenha a lista de clientes em cartões de índice. Examinar esses cartões pode mostrar que cada cartão contém um nome de cliente, endereço, cidade, estado, CEP e número de telefone. Cada um desses itens representa uma coluna potencial em uma tabela.

À medida que você prepara esta lista, não se preocupe em fazê-la perfeita a princípio. Em vez disso, liste cada item que chega a mente. Se outra pessoa estiver usando o banco de dados, solicite suas ideias também. Você pode ajustar a lista mais tarde.

Em seguida, considere os tipos de relatórios ou correspondências que você pode querer produzir a partir do banco de dados. Por exemplo, talvez você queira um relatório de vendas de produtos para mostrar as vendas por região ou um relatório de resumo do estoque que mostre os níveis de estoque de produtos. Você também pode gerar cartas de formulário para enviar aos clientes que anunciarem um evento de venda ou oferecer uma gratificação. Projete o relatório em mente e imagine o que ele teria como aparência. Quais informações você colocaria no relatório? Listar cada item. Faça o mesmo para a carta do formulário e para qualquer outro relatório que você prevê criar.

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

Dar pensado aos relatórios e correspondências que você pode querer criar ajuda a identificar os itens que você precisará no seu banco de dados. Por exemplo, suponhamos que você ofereça aos clientes a oportunidade de optar por fazer (ou sair de) atualizações periódicas por email e deseja imprimir uma listagem daqueles que optaram por você. Para gravar essas informações, adicione uma coluna "enviar email" à tabela do cliente. Para cada cliente, você pode definir o campo como Sim ou não.

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

Faz sentido construir um protótipo de cada listagem de relatório ou saída e considerar quais itens você precisará para produzir o relatório. Por exemplo, quando você examina uma carta-formulário, algumas coisas podem chegar à mente. Se quiser incluir uma saudação adequada — por exemplo, a cadeia de caracteres "Sr.", "Sra." ou "MS." que inicia uma saudação, você precisará criar um item de saudação. Além disso, você pode iniciar uma carta com "Prezado Sr. Smith", em vez de "Prezado. Sr. Sylvester Smith ". Isso sugere que você normalmente deseja armazenar o sobrenome separado do primeiro nome.

Um ponto importante a ser lembrado é que você deve dividir cada informação em suas menores partes úteis. No caso de um nome, para disponibilizar o último nome rapidamente, você irá quebrar o nome em duas partes: nome e sobrenome. Para classificar um relatório por sobrenome, por exemplo, ele ajuda a ter o sobrenome do cliente armazenado separadamente. Em geral, se você deseja classificar, Pesquisar, calcular ou relatar com base em um item de informação, deve colocá-lo em seu próprio campo.

Pense nas perguntas que você pode querer que o banco de dados responda. Por exemplo, quantas vendas do produto em destaque você fechou no último mês? Onde estão os melhores clientes ao vivo? Quem é o fornecedor do produto de melhor venda? Antecipar essas perguntas ajuda você a fazer zero em itens adicionais para gravar.

Depois de reunir essas informações, você estará 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 as entidades principais ou entidades. Por exemplo, depois de localizar e organizar informações para um banco de dados de vendas de produtos, a lista preliminar pode ter esta aparência:

Itens de informações manuscritas agrupados em assuntos

As principais entidades mostradas aqui são os produtos, fornecedores, clientes e pedidos. Portanto, faz sentido começar com essas quatro tabelas: uma para fatos sobre produtos, um para fatos sobre fornecedores, um para fatos sobre clientes e outro para fatos sobre pedidos. Embora isso não Complete a lista, é um bom ponto de partida. Você pode continuar a refinar esta lista até ter um design que funcione bem.

Ao examinar pela primeira vez a lista preliminar de itens, você pode ficar tentado a colocá-los em uma única tabela, em vez de nos quatro exibidos na ilustração anterior. Você aprenderá aqui, por que essa é uma boa ideia. Considere 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 seu fornecedor. Como você pode ter muitos produtos do mesmo fornecedor, as informações de nome e endereço do fornecedor devem ser repetidas muitas vezes. Isso desperdiça espaço em disco. Gravar as informações do fornecedor apenas uma vez em uma tabela fornecedores separada e, em seguida, vinculá-la à tabela produtos, é uma solução muito melhor.

Um segundo problema com este design se refere a um caso em que você precisa modificar as informações sobre o fornecedor. Por exemplo, suponha que você precise alterar o endereço de um fornecedor. Como ele aparece em vários lugares, talvez você acidentalmente altere o endereço em um só lugar, mas esqueça de alterá-lo em outros. A gravação do endereço do fornecedor em apenas um local resolve o problema.

Ao projetar seu banco de dados, tente sempre gravar cada fato de uma só vez. Se você estiver repetindo as mesmas informações em mais de um local, como o endereço de um fornecedor específico, coloque essas informações em uma tabela separada.

Por fim, suponha que há apenas um produto fornecido pela Coho Winery, e você deseja excluir o produto, mas manter as informações de nome e endereço do fornecedor. Como você excluiria o registro de produto sem também perder as informações do fornecedor? Isso 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ê deve dividir a tabela em duas: uma tabela para obter informações do produto e outra tabela para obter informações sobre o fornecedor. A exclusão de um registro de produto deve excluir apenas os fatos sobre o produto, não os fatos sobre o fornecedor.

Depois de escolher o assunto que é representado por uma tabela, as colunas nessa tabela devem armazenar fatos somente sobre o assunto. Por exemplo, a tabela de produto deve armazenar fatos apenas sobre produtos. Como o endereço do fornecedor é um fato sobre o fornecedor, e não um fato sobre o produto, ele pertence à tabela de fornecedores.

Início da Página

Transformar itens de informações em colunas

Para determinar as colunas em uma tabela, decida quais informações são necessárias para acompanhar o assunto registrado na tabela. Por exemplo, para a tabela clientes, nome, endereço, cidade-estado-CEP, enviar email, saudação e endereço de email, você compreende uma boa lista inicial de colunas. Cada registro na tabela contém o mesmo conjunto de colunas, portanto, você pode armazenar nome, endereço, cidade-estado-CEP, enviar email, saudação e informações de endereço de email para cada registro. Por exemplo, a coluna endereço contém os 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 determinar o conjunto inicial de colunas para cada tabela, você pode refinar ainda mais as colunas. Por exemplo, faz sentido armazenar o nome do cliente como duas colunas separadas: primeiro nome e sobrenome, para que você possa classificar, Pesquisar e indexar apenas essas colunas. Da mesma forma, o endereço consiste de cinco componentes separados, endereço, cidade, estado, código postal e país/região, e também faz sentido armazená-los em colunas separadas. Se você quiser executar uma operação de pesquisa, filtro 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 manterá as informações de origem doméstica somente, ou internacionais, também. Por exemplo, se você planeja armazenar endereços internacionais, é melhor ter uma coluna Region em vez de State, porque tal coluna pode acomodar ambos os Estados domésticos e as regiões de outros países/regiões. Da mesma forma, o código postal faz mais sentido do que CEP se você for armazenar endereços internacionais.

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

  • Não incluir dados calculados    

    Na maioria dos casos, você não deve armazenar o resultado de cálculos em tabelas. Em vez disso, você pode fazer o Access executar os cálculos quando quiser ver o resultado. Por exemplo, suponha que há um relatório de produtos em ordem que exibe o subtotal de unidades em ordem para cada categoria de produto no banco de dados. No entanto, não há unidades na coluna de subtotal do pedido em qualquer tabela. Em vez disso, a tabela produtos inclui uma coluna de unidades em ordem que armazena as unidades em ordem para cada produto. Usando esses dados, o Access calcula o SUBTOTAL toda vez que você imprimir o relatório. O SUBTOTAL em si não deve ser armazenado em uma tabela.

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

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

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

Depois de refinar 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. 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 do banco de dados, essas informações são chamadas de chave primária da tabela. O Access usa os campos de chave primária para associar rapidamente dados de várias tabelas e trazer os dados juntos 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 a chave primária da tabela, mas somente se os valores nessa coluna sempre serão diferentes para cada registro. Não é possível ter valores duplicados em uma chave primária. Por exemplo, não use os nomes das pessoas como uma chave primária, porque os nomes não são exclusivos. Você pode ter facilmente duas pessoas com o mesmo nome na mesma tabela.

Uma chave primária deve sempre ter um valor. Se o valor de uma coluna pode ser não atribuído 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 escolher uma chave primária cujo valor não será alterado. Em um banco de dados que usa mais de uma tabela, a chave primária de uma tabela pode ser usada como referência em outras tabelas. Se a chave primária for alterada, a alteração também deve ser aplicada a qualquer lugar em que a chave é referenciada. Usar uma chave primária que não será alterada reduz a chance de que a chave primária se torne dessincronizada com outras tabelas que fazem referência a ela.

Geralmente, um número exclusivo arbitrário é usado como a chave primária. Por exemplo, você pode atribuir a cada pedido um número de pedido exclusivo. O único objetivo do número do pedido é identificar um pedido. Uma vez atribuída, ele nunca muda.

Se você não tiver em mente uma coluna ou um conjunto de colunas que podem fazer uma boa chave primária, considere usar uma coluna com o tipo de dados numeração automática. Quando você usa o tipo de dados numeração automática, o Access atribui automaticamente um valor para você. Tal identificador não é de fato; Ele não contém nenhuma informação factual descrevendo a linha que ela representa. Identificadores sem fatos são ideais para uso como uma chave primária, pois eles não são alterados. Uma chave primária que contém fatos sobre uma linha — um número de telefone ou um nome de cliente, por exemplo, é mais provável de mudar, pois as informações factual podem mudar.

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

1. uma coluna definida como o tipo de dados numeração automática geralmente faz uma boa chave primária. Não há duas IDs de produto iguais.

Em alguns casos, talvez você queira usar dois ou mais campos que, juntos, fornecem 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 emprega mais de uma coluna, ela também é chamada de chave composta.

Para o banco de dados de vendas do produto, você pode criar uma coluna numeração automática para cada uma das tabelas para servirem como chave primária: ProductID para a tabela produtos, NúmeroDoPedido para a tabela pedidos, CódigoDoCliente para a tabela clientes e CódigoDoFornecedor para a tabela fornecedores.

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


Início da Página

Criando as relações de tabelas

Agora que você dividiu suas informações em tabelas, você precisa de uma maneira de reunir as informações novamente de maneira significativa. Por exemplo, o formulário a seguir 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... a tabela funcionários...

3... a tabela pedidos...

4... a tabela produtos...

5... e a tabela detalhes do pedido.

O Access é um sistema de gerenciamento de banco de dados relacional. Em um banco de dados relacional, você divide as informações em tabelas separadas com base em assunto. Em seguida, use relações de tabela para reunir as informações conforme necessário.

Início da Página

Criando uma relação um-para-muitos

Considere este exemplo: as tabelas fornecedores e produtos no banco de dados de pedidos de produto. Um fornecedor pode fornecer qualquer número de produtos. Ele segue que, para qualquer fornecedor representado na tabela fornecedores, pode haver muitos 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, pegue a chave primária no lado "um" da relação e adicione-a como uma coluna ou colunas adicionais à tabela no lado "muitos" da relação. Nesse caso, por exemplo, adicione a coluna ID do fornecedor da tabela fornecedores à tabela produtos. O Access pode usar o número de identificação do 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 ID do fornecedor na tabela produtos é uma chave estrangeira porque também é a chave primária na tabela fornecedores.

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

Você fornece 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, a identificação de uma relação um-para-muitos garantirá que as duas tabelas envolvidas irão realmente exigir uma coluna compartilhada.

Início da Página

Criando uma relação muitos-para-muitos

Considere a relação entre a tabela produtos e a tabela pedidos.

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

Os assuntos das duas tabelas (pedidos e produtos) têm uma relação muitos-para-muitos. Isso representa um problema. Para entender o problema, imagine o que aconteceria se você tentasse criar a relação entre as duas tabelas adicionando o campo product ID à tabela Orders. Para ter mais de um produto por pedido, você precisa de mais de um registro na tabela Orders por pedido. Você pode estar repetindo informações de pedidos para cada linha que se relaciona a um único pedido, resultando em um design ineficiente que pode levar a dados imprecisos. Você terá o mesmo problema se colocar o campo ID do pedido na tabela produtos — você teria mais de um registro na tabela produtos para cada produto. Como resolver esse problema?

A resposta é criar uma terceira tabela, muitas vezes chamada de tabela de junção, que divide a relação de muitos para muitos em relações de 2 1 para muitos. Insira a chave primária de cada uma das duas tabelas na terceira tabela. Como resultado, a terceira tabela registra cada ocorrência ou ocorrência da relação.

Um relacionamento muitos-para-muitos

Cada registro na tabela detalhes do pedido representa um item de linha em um pedido. A chave primária da tabela detalhes do pedido consiste em dois campos — as chaves estrangeiras das tabelas pedidos e produtos. Usar o campo ID do pedido sozinha não funciona como a chave primária desta tabela, porque um pedido pode ter muitos itens de linha. A ID do pedido é repetida para cada item de linha em um pedido, portanto, o campo não contém valores exclusivos. Usar o campo product ID sozinha também não funciona 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 relacionadas umas às outras diretamente. Em vez disso, eles estão relacionados indiretamente pela tabela detalhes do pedido. A relação muitos-para-muitos entre pedidos e produtos é representada no banco de dados usando relações de 2 1 a 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 a tabela detalhes do pedido têm uma relação um-para-muitos. Cada produto pode ter vários itens de linha associados a ele, mas cada item de linha refere-se 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 determinado produto.

Após a incorporação da tabela detalhes do pedido, a lista de tabelas e campos pode ter uma aparência semelhante a esta:

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 é a relação um-para-um. Por exemplo, suponha que você precise gravar informações complementares de produtos complementares que precisará raramente ou que só se apliquem a alguns produtos. Como você não precisa das informações com frequência e, como armazenar as informações na tabela produtos resultava em espaço vazio para cada produto ao qual ele não se aplica, você deve colocá-lo em uma tabela separada. Assim como a tabela produtos, você usa o ProductID como a chave primária. A relação entre esta tabela complementar e a tabela de produtos é uma relação um-para-um. Para cada registro na tabela de produtos, existe um único registro correspondente na tabela complementar. Quando você identifica esse tipo de relação, ambas as tabelas devem compartilhar um campo em comum.

Ao detectar a necessidade de uma relação um-para-um em seu banco de dados, considere se você pode colocar as informações das duas tabelas juntas em uma tabela. Se você não quiser fazer isso por algum motivo, talvez porque isso resultaria em muito espaço vazio, a lista a seguir mostra como você representaria a relação no seu design:

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

  • Se as duas tabelas tiverem diferentes assuntos com chaves primárias diferentes, escolha uma das tabelas (qualquer uma) e insira sua chave primária na outra tabela como uma chave estrangeira.

Determinar as relações entre tabelas ajuda a garantir que você tenha as tabelas e as colunas certas. Quando há uma relação um-para-um ou um-para-muitos, as tabelas envolvidas precisam compartilhar uma coluna ou 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

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

Veja se você pode usar o banco de dados para obter as respostas desejadas. Crie rascunhos de seus formulários e relatórios e veja se eles mostram os dados que você espera. Procure duplicação desnecessária de dados e, quando encontrar algum, altere o design para eliminá-lo.

Ao experimentar seu banco de dados inicial, você provavelmente encontrará espaço para melhorias. Aqui estão algumas coisas a serem verificadas:

  • Você esqueceu alguma coluna? Em caso afirmativo, as informações pertencem às tabelas existentes? Se for informações sobre outra coisa, talvez seja necessário criar outra tabela. Crie uma coluna para cada item de informação que você precisa controlar. Se as informações não puderem ser calculadas a partir de outras colunas, é provável que você precise de uma nova coluna para ela.

  • As colunas são desnecessárias porque podem ser calculadas a partir de campos existentes? Se um item de informação puder ser calculado a partir de outras colunas existentes, um preço com desconto será calculado do preço de varejo, por exemplo, geralmente é melhor fazer isso e evitar a criação de uma nova coluna.

  • Você está inserindo várias informações duplicadas em uma de suas tabelas? Em caso afirmativo, provavelmente você precisa 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 em registros individuais? Em caso afirmativo, pense em redesenhar a tabela para ter menos campos e mais registros.

  • Cada item de informação foi quebrado em suas menores partes úteis? Se você precisar relatar, classificar, Pesquisar ou calcular em um item de informações, coloque esse item em sua própria coluna.

  • Cada coluna contém um fato sobre o assunto da tabela? Se uma coluna não contiver informações sobre o assunto da tabela, ela pertencerá a uma tabela diferente.

  • Todas as relações entre tabelas são representadas por campos comuns ou por uma terceira tabela? Relações um-para-um e um para muitos exigem colunas comuns. Relações muitos para muitos exigem uma terceira tabela.

Refinar a tabela produtos

Suponha que cada produto do banco de dados de vendas de produtos cai em uma categoria geral, como bebidas, condiments ou frutos do mar. A tabela produtos pode incluir um campo que mostra a categoria de cada produto.

Suponhamos que, após examinar e refinar o design do banco de dados, você decida armazenar uma descrição da categoria juntamente com seu nome. Se você adicionar um campo Descrição da categoria à tabela produtos, será necessário repetir cada descrição da categoria para cada produto que se enquadram na categoria – essa não é uma boa solução.

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

As tabelas 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.

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

  • ID do Produto

  • Nome

  • ID1 de produto

  • Nome1

  • ID2 de produto

  • Nome2

  • ID3 do produto

  • Name3

Aqui, cada produto é um grupo de repetição de colunas que difere dos outros somente ao adicionar um número ao final do nome da coluna. Quando você vir colunas numeradas dessa maneira, você deve revisitar seu design.

Tal design tem várias falhas. Para iniciantes, ele obriga você a colocar um limite superior no número de produtos. Assim que exceder esse limite, você deverá adicionar um novo grupo de colunas à estrutura da tabela, que é uma tarefa administrativa importante.

Outro problema é que os fornecedores que têm menos do que o número máximo de produtos perderão algum espaço, pois as colunas adicionais ficarão em branco. A falha mais séria com um design tão importante é que isso dificulta a realização de várias tarefas, como classificar ou indexar a tabela por ID do produto ou nome.

Sempre que você vir grupos de repetição, examine atentamente o design com um olho na divisão da tabela em dois. 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 apenas a regras de normalização) como a próxima etapa do seu design. Use essas regras para ver se as suas tabelas estão estruturadas corretamente. O processo de aplicação das regras ao design do seu banco de dados é chamado de normalização do banco de dados ou apenas normalização.

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

Você aplica as regras sucessivamente em cada etapa, garantindo que o design chegue em um dos itens conhecidos como "formulários normais". Cinco formulários normais são amplamente aceitos, o primeiro formulário normal por meio do quinto formato normal. Este artigo se expande nas três primeiras, porque elas são necessárias para a maioria dos designs de banco de dados.

Primeiro formulário normal

Primeiro o 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, não é possível ter um campo com o nome de preço no qual você coloca mais de um preço. Se você pensar em cada interseção de linhas e colunas como uma célula, cada célula poderá armazenar apenas um valor.

Segundo formulário normal

Segundo formato normal requer que cada coluna não-chave dependa totalmente da chave primária inteira, e não de apenas parte da chave. Esta regra se aplica quando você tem uma chave primária que 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

Esse design viola a segunda forma normal, porque o nome do produto depende da ID do produto, mas não na ID do pedido, para que ele não dependa da chave primária inteira. Você deve remover o nome do produto da tabela. Ele pertence a uma tabela diferente (produtos).

Terceiro formulário normal

O terceiro formato normal requer que não apenas todas as colunas que não sejam de chave dependam da chave primária inteira, mas essas colunas não-chave são independentes umas das outras.

Outra maneira de dizer isso é que cada coluna não-chave deve depender da chave primária e nada, mas da chave primária. Por exemplo, suponha que você tenha uma tabela que contenha as seguintes colunas:

  • ProductID (chave primária)

  • Nome

  • SRP

  • Desconto

Assuma que o desconto dependa do preço de varejo sugerido (SRP). Esta tabela viola a terceira forma normal porque uma coluna sem chave, desconto, depende de outra coluna 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 mudará de acordo com a regra que violasse essa regra. Nesse caso, o desconto deve ser movido para outra tabela que seja inserida no SRP.

Início da Página

Precisa de mais ajuda?

Expanda suas habilidades no Office
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.

×