Fundamentos do design de banco de dados

Um banco de dados criado adequadamente fornece acesso a informações atualizadas e precisas. Como um design correto é essencial para alcançar as metas de um trabalho com banco de dados, é importante investir o tempo necessário no aprendizado dos princípios de um bom design. Ao final, é mais provável que você obtenha um banco de dados que atenda suas necessidades e que aceite alterações com facilidade.

Este artigo oferece diretrizes para o planejamento de um banco de dados da área de trabalho. Você aprenderá como optar pelas informações de que necessita, como dividir essas informações em tabelas e colunas apropriadas, e como essas tabelas são inter-relacionadas. Leia este artigo antes de criar seu primeiro banco de dados da área de trabalho.

 Importante   O Microsoft Access 2010 oferece uma nova experiência de design que permite a você criar aplicativos de banco de dados para a Web. Muitas considerações de design são diferentes quando o design é feito para a Web. Este artigo não discute o 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 a serem conhecidos

O Access 2010 organiza suas informações em tabelas: listas de linhas e colunas que lembram as linhas e as colunas do livro razão ou de uma planilha. Em um banco de dados simples talvez haja apenas uma tabela. Na maioria dos bancos de dados é necessária mais de uma. Por exemplo, pode haver uma tabela que armazene informações sobre produtos, uma outra que armazene informações sobre pedidos e uma outra tabela com informações sobre clientes.

Imagem mostrando três tabelas em folhas de dados

Cada linha é mais corretamente chamada de registro, e cada coluna de campo. Um registro é uma forma significativa e coerente de combinar informações sobre algo. Um campo é um item único de informação — um tipo de item que aparece em cada um dos registros. Na tabela Produtos, por exemplo, cada linha ou registro guardaria informações sobre um produto. Cada coluna ou campo mantém algum tipo de informação sobre esse produto, como nome ou preço.

Início da página Início da página

O que é um bom design de banco de dados?

Certos princípios guiam o processo de design do banco de dados. O primeiro princípio é que informações duplicadas (também denominadas dados redundantes) são ruins porque consomem espaço e aumentam a possibilidade de erros e inconsistências. O segundo princípio é que a correção e completitude das informações é importante. Se o banco de dados contiver informações incorretas, todos os relatórios que empregam informações do banco de dados também conterão informações incorretas. Como resultado, todas as decisões tomadas a partir desses relatórios serão errôneas.

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

  • Divide as informações em tabelas baseadas em tópicos, visando reduzir a redundância de dados.
  • Fornece ao Access os dados essenciais à junção de informações nas tabelas, conforme necessário.
  • Ajuda a oferecer suporte e assegurar a precisão e a integridade das informações.
  • Atende às suas necessidades de processamento de dados e de relatórios.

Início da página Início da página

O processo do design

O processo do design consiste nas 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     

Reunir todos os tipos de informações que você possa desejar gravar no banco de dados, como nome de produto e número de pedido.

  • Dividir as informações em tabelas    

Dividir os itens de informações em entidades ou tópicos principais, como Produtos ou Pedidos. Cada tópico torna-se então uma tabela.

  • Transformar informações em colunas    

Opte pelas informações que deseja armazenar em cada uma das tabelas. Cada item torna-se um campo que é exibido como coluna da tabela. Por exemplo, uma tabela Funcionários pode incluir campos como Sobrenome e Data de Contratação.

  • Especificar as chaves primárias    

Escolher a chave primária de todas as tabelas. A chave primária é uma coluna usada unicamente para identificar cada linha. Um exemplo pode ser Código de Produto ou Código de Pedido.

  • Configurar as relações de tabelas    

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

  • Refinar o design    

Analisar o design com relação aos erros. Criar as tabelas e adicionar alguns novos registros de dados de exemplo. Observe se os resultados esperados das tabelas são obtidos. Faça ajustes no design, conforme necessário.

  • Aplicar as regras de normalização    

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

Início da página Início da página

Determinando a finalidade do banco de dados

Recomenda-se anotar a finalidade do banco de dados em um papel — sua finalidade, como se espera usá-lo e quem o usará. Com relação a um banco de dados pequeno e de empresa caseira, por exemplo, você escreveria algo como "O banco de dados cliente mantém uma lista de informações de clientes com a finalidade de produzir malas diretas e relatórios". Se o banco de dados for mais complexo ou usado por diversas pessoas, como ocorre frequentemente em um ambiente empresarial, a finalidade poderia ser contida em um simples parágrafo ou mais, devendo incluir quando e como cada pessoa irá usar o banco de dados. A ideia é ter uma declaração de missão bem desenvolvida, à qual se possa referir durante todo o processo de design. Ter uma declaração como essa ajuda a focar nas metas no momento da tomada de decisões.

Início da página Início da página

Localizando e organizando as informações necessárias

Para localizar e organizar as informações requeridas, comece pelas informações existentes. Por exemplo, é possível registrar os pedidos de compra em um livro razão ou manter as informações do cliente em formulários de papel em um gabinete de arquivos. Reúna esses documentos e liste cada um dos tipos de informações mostrados (por exemplo, cada caixa preenchida em um formulário). Se não houver formulários, imagine que será necessário criar um formulário para registrar as informações do cliente. Que informações você colocaria no formulário? Que caixas de preenchimento você criaria? Identifique e liste todos esses itens. Por exemplo, supondo que você atualmente mantém a lista de clientes em cartões de índice. O exame desses cartões demonstra que cada cartão contém um nome, endereço, cidade, estado, cep e número de telefone de cliente. Cada um desses itens representa uma coluna potencial em uma tabela.

À medida que prepara a lista, não se preocupe em conseguir uma lista perfeita na primeira tentativa. Em vez disso, liste todos os itens que lhe vierem à mente. Se outras pessoas usarem o banco de dados, peça sugestões também. Você poderá refinar posteriormente a lista.

Em seguida, considere os tipos de relatórios ou de listas de distribuição a serem produzidos com o banco de dados. Por exemplo, você poderá gerar um relatório de vendas de produto que apresente as vendas por região, ou um relatório de resumo de inventário mostrando os níveis de inventário do produto. É igualmente possível gerar cartas modelo para enviar aos clientes, que divulguem um evento de vendas ou que ofereçam um brinde. Crie o relatório ideal e imagine sua aparência. Que informações você colocaria no relatório? Liste todos os itens. Faça o mesmo com a carta formulário e com todos os relatórios cuja criação você antevê.

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

Pensar nos relatórios e listas de distribuição a serem criados ajuda na identificação dos itens necessários ao banco de dados. Por exemplo, supondo que você dê aos clientes a chance de optar por (ou não) por atualizações periódicas via email, e que deseja imprimir uma listagem dos que optaram pela opção. Para registrar essas informações, adicione uma coluna "Enviar email" à tabela do cliente. É possível configurar o campo como Sim ou Não com relação a todos os clientes.

A necessidade de enviar mensagens de email aos clientes sugere que um outro item seja registrado. Após saber se o cliente deseja receber mensagens de email, será também necessário saber o endereço de email para os quais as mensagens serão enviadas. Portanto, é necessário registrar um endereço de email para cada um dos clientes.

Há sentido em construir um protótipo de cada relatório ou listagem de saída, e pensar nos itens necessários à produção do relatório. Por exemplo, ao examinar uma carta formulário, algumas coisas podem vir à sua mente. Para incluir uma saudação adequada  — por exemplo, a sequência de caracteres "Sr.", "Srta." ou "Sra.", que inicia uma saudação, será preciso criar um item de saudação. Da mesma forma, é possível começar normalmente uma carta com “Prezado Sr. Silva”, em vez de “Prezado Edmundo Silva”. Isso quer dizer que você deseja armazenar regularmente o sobrenome em separado do nome.

Um ponto essencial a ser lembrado é que todas as partes da informação devem ser quebradas em suas partes úteis menores. No caso de nome, para disponibilizar prontamente o sobrenome, quebre-o em duas partes — Nome e Sobrenome. Para classificar um relatório pelo último nome, por exemplo, é útil armazenar separadamente o sobrenome do cliente. Em geral, quando se deseja classificar, pesquisar, calcular ou criar um relatório com base em um item de informações, deve-se inserir esse item em seu próprio campo.

Pense nas perguntas que você deseja que o banco de dados responda. Por exemplo, quantas vendas do produto em destaque foram fechadas mês passado? Onde vivem seus melhores clientes? Quem é o fornecedor de seu produto de maior vendagem? A antecipação dessas perguntas ajuda a que você se concentre nos outros itens a serem registrados.

Após reunir essas informações, você estará pronto para a próxima etapa.

Início da página Início da página

Dividir as informações em tabelas

Para dividir as informações em tabelas, escolha as maiores entidades ou tópicos. Por exemplo, após localizar e organizar informações relativas a um banco de dados de venda de produto, a lista preliminar deve ter a seguinte aparência:

Itens de informações manuscritas agrupados em assuntos

As maiores entidades mostradas aqui são os produtos, os fornecedores, os clientes e os pedidos. Assim, há sentido em começar pelas seguintes tabelas: uma de fatos sobre produtos, uma de fatos sobre fornecedores, uma de fatos sobre clientes, e uma de fatos sobre pedidos. Embora essas tabelas não completem a lista, são um ponto de partida. Continue e refinar essa lista até ter um design que funcione bem.

Ao examinar pela primeira vez a lista de itens, você talvez se sinta tentado a colocá-los todos em uma única tabela, em vez de ter quatro, como mostrado na ilustração anterior. Você saberá aqui por que isso não é recomendado. Pense um momento na tabela mostrada a seguir:

Uma imagem mostrando uma tabela com produtos e fornecedores

Nesse caso, cada linha contém informações sobre o produto e seu fornecedor. Como pode haver vários produtos de um mesmo fornecedor, o nome e o endereço do fornecedor deverão ser repetidos inúmeras vezes. Isso consome espaço em disco. Gravar as informações do fornecedor uma única vez em uma tabela Fornecedores separada e, em seguida, vincular essa tabela à tabela Produtos, é uma solução muito melhor.

Um segundo problema com esse design advém da necessidade de se modificarem as informações sobre o fornecedor. Por exemplo, supondo seja necessário alterar o endereço de um fornecedor. Como o endereço aparece em vários lugares, você talvez altere acidentalmente o endereço em um local, porém se esqueça de alterá-lo nos outros. Gravar o endereço do fornecedor em apenas um local resolve esse problema.

Ao criar seu banco de dados, tente sempre registrar cada fato apenas uma vez. Quando se pegar repetindo a mesma informação em mais de um local, como o endereço de determinado fornecedor, coloque a informação em uma tabela separada.

Finalmente, suponhamos que haja apenas um produto fornecido pela Coho Winery, e que você deseje excluir o produto, retendo, porém, o nome do fornecedor e as informações de endereço. Como excluir o registro do produto sem também perder as informações do fornecedor? Isso não é possível. Como cada registro contém fatos sobre um produto, assim como fatos sobre o fornecedor, não é possível excluir um sem eliminar o outro. Para manter esses fatos de maneira distinta, separe essa tabela em duas: uma tabela de informações sobre o produto, e uma outra tabela de informações sobre o fornecedor. A exclusão do registro do produto deve eliminar apenas os fatos sobre o produto, não os fatos sobre o fornecedor.

Após a seleção do tópico a ser representado na tabela, as colunas da tabela só devem armazenar fatos sobre esse tópico. Por exemplo, a tabela de produto só deve armazenar fatos sobre produtos. Como o endereço do fornecedor é um fato sobre o fornecedor, e não um fato sobre o produto, pertence à tabela do fornecedor.

Início da página Início da página

Transformando itens de informações em colunas

Para determinar as colunas de uma tabela, opte pelas informações que você necessita controlar sobre o tópico registrado na tabela. Por exemplo, com relação à tabela Cliente, Nome, Endereço, Cidade-Estado-CEP, Email para envio de correspondência, Saudação e Endereço de email constituem uma lista de colunas que é um bom começo. Cada registro da tabela contém o mesmo conjunto de colunas, de modo que é possível armazenar informações sobre o Nome, Endereço, Cidade-Estado-CEP, Email para envio de correspondência, Saudação e endereço de email de todos os registros. Por exemplo, a coluna de endereço contém os endereços dos clientes. Cada registro contém dados sobre um cliente, e o campo de endereço contém o endereço do cliente.

Após determinar o conjunto inicial de colunas de cada tabela, você poderá refinar as colunas. Por exemplo, é recomendado armazenar o nome do cliente em duas colunas separadas: o nome e o sobrenome, de modo que se possa classificar, pesquisar e indexar apenas nessas duas colunas. Da mesma forma, o endereço na verdade consiste em cinco componentes distintos: endereço, cidade, estado, cep e país/região. É igualmente recomendado armazená-los em colunas diferentes. Se você deseja realizar uma operação de pesquisa, filtro ou classificação por estado, por exemplo, será necessário armazenar a informação de estado em uma coluna separada.

Verifique se o banco de dados conterá somente informações de origem doméstica, ou se, além disso, conterá informações internacionais. Por exemplo, se você planeja armazenar endereços internacionais, deve haver uma coluna de Região em vez de Estado, porque essa coluna aceita os estados domésticos e as regiões de outros países/outras regiões. Semelhantemente, o código de endereçamento postal tem mais sentido que o CEP se você pretende armazenar endereços internacionais.

A lista a seguir mostra algumas dicas sobre a determinação de colunas.

  • Não inclusão de dados calculados    

Na maior parte dos casos, o resultado de cálculos não deve ser armazenado em tabelas. Em vez disso, é possível fazer com que o Access realize cálculos quando se deseja exibir o resultado. Por exemplo, supondo que haja um relatório de Produtos do Pedido que exiba o subtotal de unidades do pedido por categoria de produto no banco de dados. Contudo, não há coluna de subtotal de Unidades no Pedido em nenhuma tabela. Em vez disso, a tabela de Produtos inclui uma coluna Unidades do Pedido que armazena as unidades do pedido com relação a cada um dos produtos. Usando esses dados, o Access calcula o subtotal cada vez que o relatório é impresso. O próprio subtotal não pode ser armazenado na tabela.

  • Armazenar as menores partes lógicas das informações    

Você pode ficar tentado a ter um único campo para nomes completos, ou para nomes de produtos juntamente com descrições de produto. Se você combinar mais de um tipo de informação em um só campo, será difícil recuperar posteriormente os fatos individuais. Tente quebrar as informações em partes lógicas, por exemplo, criando campos distintos para nome e sobrenome, ou por nome, categoria e descrição de produto.

Lista de itens de informações durante o processo de design

Apos refinar as colunas de dados de cada tabela, você estará pronto para escolher a chave primária de cada tabela.

Início da página Início da página

Especificando chaves primárias

Toda tabela deve incluir uma coluna ou conjunto de colunas que identifica com exclusividade cada linha armazenada na tabela. Trata-se, em geral, de um número de identificação exclusivo, como o número de identificação de um funcionário ou um número de série. Na terminologia de banco de dados, essas informações são denominadas chave primária da tabela. O Access usa os campos de chave primária para associar rapidamente os dados de várias tabelas e passar a você as informações consolidadas.

Se já houver um identificador exclusivo para a tabela, como um número de produto que identifica exclusivamente cada produto do seu catálogo, você poderá usar esse identificador como chave primária da tabela — porém, apenas se os valores da coluna forem sempre diferentes com relação a todos os registros. Não é possível duplicar valores em uma chave primária. Por exemplo, não use nomes de pessoas como chave primária, porque nomes não são exclusivos. É fácil encontrar duas pessoas com o mesmo nome em uma mesma tabela.

A chave primária deve sempre conter um valor. Se o valor de uma coluna pode se tornar sem alocação ou desconhecido (valor faltante) em dado momento, não poderá ser usado como componente de chave primária.

Escolha sempre uma chave primária cujo valor não se altere. Em um banco de dados que utiliza 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 se alterar, a alteração precisa também ser aplicada a todos os locais em que a chave é citada. Usar uma chave primária que não se altera reduz a possibilidade de que a chave primária fique fora de sincronia com outras tabelas que fazem referência a ela.

Em geral, um número exclusivo arbitrário é usado como chave primária. Por exemplo, é possível atribuir um número exclusivo de pedido a todos os pedidos. A finalidade do número de pedido é identificá-lo. Após atribuído, ele não é mais alterado.

Se você não estiver visando uma coluna ou um conjunto de colunas que possam consistir em chave primária adequada, pense em usar uma coluna que tenha um tipo de dados de Numeração Automática. Quando você usa tipo de dados de Numeração Automática, o Access atribui automaticamente um valor para você. Esse identificador é isento de fatos; não contém informações factuais que descrevam a linha que representam. Os identificadores isentos de fatos são ideais para se usar como chave primária porque não se alteram. Uma chave primária que contenha fatos a respeito de uma linha — número de telefone ou nome de cliente, por exemplo — tem mais probabilidade de se alterar porque as próprias informações factuais podem se modificar.


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

Texto explicativo 1 Uma coluna definida com o tipo de dados de Numeração Automática consiste, em geral, em uma chave primária adequada. Jamais dois códigos de produto serão idênticos.

Em alguns casos, é preferível usar dois ou mais campos que, juntos, forneçam a chave primária para uma tabela. Por exemplo, uma tabela de Detalhes do Pedido que armazene itens de linha de pedidos usaria duas colunas em sua chave primária: Código de Pedido e Código de Produto. Quando uma chave primária emprega mais de uma coluna, é também denominada chave composta.

Com relação ao banco de dados de vendas de produto, é possível criar uma coluna de Numeração Automática para cada uma das tabelas, para servir como chave primária: CódigoDoProduto para a tabela Produtos, CódigoDoPedido para as tabelas 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 Início da página

Criando os relacionamentos de tabela

Agora que as informações estão divididas em tabelas, há necessidade de uma forma de reunir as informações novamente, com um sentido. Por exemplo, o formulário a seguir engloba informações de várias tabelas.


O formulário de Pedido

Texto explicativo 1 As informações desse formulário são originárias da tabela Clientes...
Texto explicativo 2 ...da tabela Funcionários...
Texto explicativo 3 ...da tabela Pedidos...
Texto explicativo 4 ...da tabela Produtos...
Texto explicativo 5 ...e da tabela Detalhes do Pedido.

O Access é um sistema de gerenciamento de banco de dados relacional. Em um banco de dados relacional, as informações são divididas em tabelas distintas, baseadas em tópicos. São então utilizadas as relações de tabelas para reunir informações, à medida que se tornem necessárias.

Início da página Início da página

Criando uma relação um-para-muitos

Examine este exemplo: as tabelas Fornecedores e Produtos do banco de dados de pedidos de produto. Um fornecedor pode fornecer qualquer número de produtos. Consequentemente, 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 um design de banco de dados, tome a chave primária do lado "um" da relação e adicione-a como coluna ou colunas adicionais à tabela do lado "muitos" da relação. Nesse caso, por exemplo, a coluna Código do Fornecedor da tabela Fornecedores é adicionada à tabela Produtos. O Access pode, em seguida, usar o número do código do fornecedor da tabela Produtos para localizar o fornecedor correto de todos os produtos.

A coluna Código do Fornecedor da tabela Produtos é denominada chave estrangeira. A chave estrangeira é uma chave primária de outra tabela. A coluna Código do Fornecedor da tabela Produtos é uma chave estrangeira porque é também a chave primária da tabela Fornecedores.

Lista de itens de informações durante o processo de design

As bases para a junção de tabelas relacionadas são fornecidas pelo estabelecimento da união de chaves primárias com chaves estrangeiras. Quando não se está certo sobre quais tabelas devem compartilhar uma coluna comum, identificar uma relação um-para-muitos assegura que as duas tabelas envolvidas exigirão verdadeiramente uma coluna compartilhada.

Início da página Início da página

Criando uma relação muitos-para-muitos

Examine a relação entre a tabela Produtos e a Tabela Pedido.

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 registros na tabela Pedidos. Esse tipo de relação é denominado relação muitos-para-muitos porque com relação a todos os produtos pode haver vários pedidos, e para todos os pedidos pode haver vários produtos. Observe que para detectar relações muitos-para-muitos entre as tabelas é importante considerar ambos os lados da relação.

Os tópicos 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 duas tabelas adicionando o campo Código do Produto à tabela Pedidos. Para ter mais de um produto por pedido, é necessário mais de um registro na tabela Pedidos por pedido. Você repetiria as informações do pedido em cada uma das linhas relativas a um único pedido — o que resultaria em um design ineficaz que poderia resultar em dados imprecisos. O mesmo problema é enfrentado quando se coloca o campo Código do Pedido na tabela Produtos — haveria mais de um registro na tabela Produtos para cada produto. Como resolver esse problema?

A solução é criar uma terceira tabela, em geral denominada tabela de junção, que divide as diversas relações muitos-para-muitos em duas relações um-para-muitos. Insira a chave primária de cada uma das duas tabelas em uma terceira tabela. Consequentemente, a terceira tabela registra todas as ocorrências ou instâncias da relação.

Um relacionamento muitos-para-muitos

Cada registro da tabela de Detalhes do Pedido representa um item de linha do pedido. A chave primária da tabela Detalhes do Pedido consiste em dois campos — as chaves estrangeiras das tabelas Pedidos e Produtos. Usar somente o campo Código do Pedido não funciona como chave primária dessa tabela, porque um único pedido pode conter vários itens de linha. O Código do Pedido repete-se em cada item de linha em um pedido, de modo que o campo não possa conter valores únicos. Usar apenas o campo Código do Produto não funciona também, porque um mesmo produto pode surgir em diversos pedidos diferentes. Em conjunto, porém, os dois campos podem sempre produzir um valor único para cada registro.

No banco de dados de vendas de produto a tabela Pedidos e a tabela Produtos não estão relacionadas entre si de forma direta. Em vez disso, são relacionadas indiretamente através da tabela Detalhes do Pedido. A relação muitos-para-muitos entre pedidos e produtos é representada no banco de dados por meio de duas relações um-para-muito:

  • A tabela Pedidos e a tabela Detalhes tem uma relação um-para-muitos. Todos os pedidos podem ter mais de um item de linha, porém todo item de linha é conectado a apenas um pedido.
  • A tabela Produtos e a tabela Pedidos tem uma relação um-para-muitos. Cada produto pode ter vários itens de linha associados a ele, mas cada item de linha se refere a apenas um produto.

Da tabela de Detalhes do Pedido, é possível determinar todos os produtos em um pedido particular. É possível também determinar que todos os pedidos de um produto particular.

Após incorporar a tabela de Detalhes do Pedido, a lista de tabelas e campos pode ter a seguinte aparência:

Lista de itens de informações durante o processo de design

Início da página Início da página

Criando uma relação um-para-um

Um outro tipo de relação é a relação um-para-um. Por exemplo, suponhamos que haja necessidade de registrar algumas informações especiais e complementares de um produto, que serão raramente usadas ou que se só aplicam a uns poucos produtos. Como essas informações não são exigidas com frequência, e como armazenar informações na tabela Produtos resultaria em espaço vazio para todos os produtos aos quais elas não se aplicam, coloque essas informações em uma tabela distinta. Assim como a tabela Produtos, utilize o CódigoDoProduto como chave primária. A relação entre essa tabela complementar e a tabela Produto é uma relação um-para-um. Para cada registro da tabela Produto, existe apenas um registro correspondente na tabela complementar. Quando essa relação é identificada, ambas as tabelas devem compartilhar um campo comum.

Quando a necessidade de uma relação um-para-um é detectada no banco de dados, considere colocar as informações das duas tabelas juntas em uma só tabela. Se houver um motivo para não o fazer, talvez porque isso resulte em uma série de espaços vazios, a lista a seguir mostra como representar a relação no design:

  • Se as duas tabelas tiverem o mesmo tópico, você poderá provavelmente configurar a relação por meio da mesma chave primária em ambas as tabelas.
  • Se as duas tabelas tiverem tópicos diferentes com chaves primárias diversas, escolha uma das tabelas (qualquer uma) e insira a chave primária na outra tabela como chave estrangeira.

A determinação das relações entre tabelas ajuda a assegurar que se tenham as tabelas e colunas corretas. Quando existe uma relação um-para-um ou um-para-muitos, as tabelas envolvidas exigem o compartilhamento de uma coluna ou colunas comuns. Quando existe uma relação muitos-a-muitos, uma terceira tabela é necessária para representar a relação.

Início da página Início da página

Refinando o design

Quando tiver as tabelas, campos e relações necessários, crie e preencha as tabelas com dados de exemplo e tente trabalhar com as informações: criação de consultas, adição de novos registros, entre outros. Fazer isso ajuda a levantar os problemas potenciais — por exemplo, pode ser necessário adicionar uma coluna que se esqueceu de inserir durante a fase de design, ou pode haver uma tabela que deva ser dividida em duas tabelas para remover duplicação.

Confirme se é possível usar o banco de dados para obter as respostas desejadas. Crie rascunhos dos seus formulários e relatórios, e veja se eles apresentam os dados esperados. Procure por duplicações de dados desnecessárias e, quando encontrar alguma, altere o design para eliminá-la.

À medida que você faz experiências com o banco de dados inicial, provavelmente descobrirá espaço para melhoramentos. Seguem algumas coisas a serem verificadas:

  • Você esqueceu de alguma coluna? Se esqueceu, as informações pertenciam a tabelas existentes? Se se trata de informações sobre alguma outra coisa, será necessário criar uma outra tabela. Crie uma coluna para cada item de informação que necessita de controle. Se as informações não podem ser calculadas a partir de outras colunas, é provável que exijam uma outra coluna.
  • Existe alguma coluna desnecessária que possa ser calculada a partir de campos existentes? Se um item de informação puder ser calculado de outras colunas existentes — um preço descontado calculado do preço de varejo, por exemplo — em geral é melhor fazer exatamente isso e evitar criar uma nova coluna.
  • Informações duplicadas são repetidamente inseridas em uma das tabelas? Em caso afirmativo, talvez seja necessário dividir a tabela em duas tabelas que tenham a relação um-para-muitos.
  • Existem tabelas com vários campos, um número limitado de registros e vários campos vazios em registros individuais? Se for o caso, pense em criar novamente a tabela de modo que passe a ter menos campos e mais registros.
  • Todos os itens de informações foram quebrados em partes úteis menores? Se for necessário criar relatório, classificar, pesquisar ou calcular um item de informação, coloque esse item em sua própria coluna.
  • Cada coluna contém um fato sobre o tópico da tabela? Quando uma coluna não contém informações sobre o tópico da tabela é porque pertence a uma tabela diferente.
  • Todas as relações entre tabelas são representadas tanto por campos comuns como por uma terceira tabela? As relações um-para-um ou um-para-muitos requerem colunas comuns. As relações muitos-para-muitos requerem uma terceira tabela.

Refinando a tabela Produtos

Suponhamos que cada produto no banco de dados de vendas de produto incida sobre uma categoria geral, como bebidas, condimentos ou frutos do mar. A tabela Produtos poderia incluir um campo que apresente a categoria de cada produto.

Suponhamos que após examinar e refinar o design do banco de dados você decida armazenar uma descrição de categoria juntamente com o nome da categoria. Quando se adiciona um campo Descrição de Categoria à tabela Produtos, é preciso repetir todas as descrições de categoria de cada produto que incida nessa categoria — o que não é uma boa solução.

Uma solução mais adequada é transformar Categorias em um tópico novo para controle do banco de dados, com sua própria tabela e sua própria chave primária. Adicione então a chave primária da tabela Categorias à tabela Produtos como chave estrangeira.

As tabelas Categorias e Produtos têm uma relação um-para-muitos: uma categoria pode incluir mais de um produto, porém um produto só pode pertencer a uma categoria.

No momento de examinar as estruturas da tabela, preste atenção a grupos repetidos. Por exemplo, considere uma tabela contendo as seguintes colunas:

  • Código do Produto
  • Nome
  • Código de Produto1
  • Nome1
  • Código de Produto2
  • Nome2
  • Código de Produto3
  • Nome3

Aqui, cada produto é um grupo separado de colunas que diferem entre si apenas pela adição de um algarismo ao final do nome da coluna. Quando colunas numeradas dessa forma aparecerem, reexamine o design.

Esse tipo de design tem várias falhas. Com relação aos iniciantes, força a colocação de um limite superior no número de produtos. Tão logo você exceda esse limite, será preciso adicionar um novo grupo de colunas à estrutura da tabela, o que é uma tarefa administrativa essencial.

Um outro problema é que os fornecedores com número de produtos inferior ao máximo irão desperdiçar espaço, uma vez que as colunas adicionais estarão vazias. A maior falha com relação a esse design é que isso torna várias tarefas difíceis de desempenhar, como a classificação ou indexação da tabela por código ou nome de produto.

Sempre que forem exibidos grupos repetidos, examine detalhadamente o design, visando a dividir a tabela em dois. No exemplo acima é melhor usar duas tabelas, uma para fornecedores e uma para produtos, vinculadas por código de fornecedor.

Início da página Início da página

Aplicando as regras de normalização

É possível aplicar as regras de normalização de dados (também chamadas simplesmente regras de normalização) como próxima etapa do design. Use essas regras para ver se as tabelas estão corretamente estruturadas. O processo de aplicação de regras ao design do banco de dados é denominado normalização de banco de dados, ou apenas normalização.

A normalização é muito mais útil após a representação de todos os itens de informações e da obtenção de um design preliminar. A ideia é ajudar a assegurar que você distribua os itens de informações pelas tabelas corretas. O que a normalização não pode fazer é assegurar que se tenham todos os itens de dados corretos de início.

Aplique as regras em sequência, assegurando a cada etapa que o seu design chegue ao que é conhecido como "formas normalizadas". Cinco formas normalizadas são amplamente aceitas  — da primeira forma normalizada à quinta forma normalizada. Este artigo se expande nas três primeiras, porque elas são tudo o que se exige para a maior parte dos bancos de dados.

Primeira forma normalizada

A primeira forma normalizada declara que a cada interseção de linha e coluna da tabela existe um valor único e nunca uma lista de valores. Por exemplo, não é possível ter um campo denominado Preço, em que se insira mais de um Preço. Quando se entende cada interseção de linhas e colunas como uma célula, cada célula poderá manter apenas um valor.

Segunda forma normalizada

A segunda forma normalizada requer que cada coluna não-chave seja totalmente dependente de toda a chave primária, não apenas de parte da chave. Essa regra aplica-se quando se tem uma chave primária que consiste em mais de uma coluna. Por exemplo, supondo que haja uma tabela contendo as colunas a seguir, onde Código do Pedido e Código do Produto formam a chave primária:

  • Código do Pedido (chave primária)
  • Código de Produto (chave primária)
  • Nome de Produto

Esse design desrespeita a segunda forma normalizada, uma vez que o Nome do Produto é dependente do Código do Produto, mas não do Código do Pedido, portanto, não depende de toda a chave primária. É preciso remover o Nome do Produto da tabela. Ele pertence a uma tabela diferente (Produtos).

Terceira forma normalizada

A terceira forma normalizada exige que não apenas todas as colunas não-chave sejam dependentes de toda a chave primária, mas que as colunas não-chave sejam independentes entre si.

Uma outra forma de dizer isso é que cada coluna não-chave seja dependente da chave primária e somente da chave primária. Por exemplo, na hipótese de haver uma tabela contendo as seguintes colunas:

  • CódigoDeProduto (chave primária)
  • Nome
  • SRP
  • Desconto

Suponha que Desconto dependa do SRP (suggested retail price, preço a varejo sugerido). Essa tabela desrespeita a terceira forma normalizada, porque uma coluna não chave, Desconto, depende de uma outra comuna não-chave, SRP. A independência da coluna significa que é possível alterar todas as colunas não-chave sem afetar nenhuma outra coluna. Se você alterar um valor do campo SRP, Desconto seria pertinentemente alterada, o que infringiria a regra. Nesse caso, Desconto seria movida para uma outra tabela chaveada em SRP.

Início da página Início da página

 
 
Aplica-se a:
Access 2010