Princípios básicos da estrutura de bases de dados

Uma base de dados concebida correctamente fornece-lhe acesso a informações actualizadas e precisas. Uma vez que é essencial uma estrutura correcta para atingir os seus objectivos de trabalho com uma base de dados, é essencial investir algum tempo para aprender os princípios de concepção de uma estrutura adequada. No final, terá uma base de dados que satisfaz as suas necessidades e que acomoda facilmente alterações.

Este artigo fornece directrizes para planeamento de uma base de dados. Obterá informações sobre como decidir quais as informações de que necessita, como dividir essas informações nas tabelas e colunas apropriadas, bem como essas tabelas se relacionam entre si. Deverá ler este artigo antes de criar a sua primeira base de dados.

Neste artigo


Alguns termos de base de dados que deverá conhecer

O Microsoft Office Access 2007 organiza as informações em tabelas: listas de linhas e colunas provenientes de um bloco de notas ou uma folha de cálculo do Microsoft Office Excel 2007 de um utilizador. Numa base de dados simples, poderá ter apenas uma tabela. Na maioria das tabelas é necessária mais do que uma. Por exemplo, poderá ter uma tabela que armazena informações sobre produtos, outra tabela que armazena informações sobre encomendas e uma outra com informações sobre os clientes.

Imagem que ilustra três tabelas em folhas de dados

Cada linha é designada também por registo e cada coluna é também designada por campo. Um registo consiste numa forma útil e consistente de combinar informações sobre um determinado tema. Um campo consiste num item de informações individual: um tipo de item que aparece em todos os registos. Na tabela Produtos, por exemplo, cada linha ou registo teria informações sobre um produto. Cada coluna ou campo tem um tipo de informações sobre esse produto como, por exemplo, o nome ou o preço.

Início da Página Início da Página

O que é uma estrutura de base de dados adequada?

Existem determinados princípios que orientam o processo de estruturação da base de dados. O primeiro princípio dita que as informações duplicadas (também denominadas por dados redundantes) são um aspecto negativo, porque ocupam espaço e aumentam a probabilidade de erros e inconsistências. O segundo princípio diz que a exactidão e a integralidade dos dados são importantes. Se a base de dados incluir informações incorrectas, todos os relatórios que utilizem as informações da base de dados também incluirão informações incorrectas. Deste modo, todas as decisões tomadas com base nesses relatórios serão erradas.

Assim, uma estrutura de base de dados adequada é aquela que:

  • Divide as informações em tabelas com base em assuntos, de forma a reduzir a quantidade de dados redundantes.
  • Fornece ao Access as informações de que necessita para agregar as informações em tabelas conjuntas de acordo com o necessário.
  • Ajuda a suportar e a garantir a exactidão e integridade das informações.
  • Acomoda as necessidades de processamento de dados e de geração de relatórios.

Início da Página Início da Página

O processo de estruturação

O processo de estruturação consiste nos seguintes passos:

  • Determinar o objectivo da base de dados    

Este passo ajuda-o a preparar-se para os seguintes.

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

Recolher todos os tipos de informações que pretende registar na base de dados, como, por exemplo, o nome do produto e o número da encomenda.

  • Dividir as informações em tabelas    

Dividir os itens de informações em entidades ou assuntos mais abrangentes, como, por exemplo, Produtos ou Encomendas. Assim, cada assunto transforma-se numa tabela.

  • Transformar os itens de informações em colunas    

Decidir quais as informações que pretende armazenar em cada tabela. Cada item transforma-se num campo e é apresentado como uma coluna na tabela. Por exemplo, uma tabela Empregados poderá incluir campos, como, por exemplo, Apelido e Data de Admissão.

  • Especificar chaves primárias    

Escolher a chave primária de cada tabela. A chave primária é uma coluna que é utilizada para identificar exclusivamente cada linha. Um exemplo poderá ser o Código do Produto ou o Código da Encomenda.

  • Configurar as relações entre tabelas    

Observar cada tabela e decidir de que forma os dados de uma tabela se relacionam com os dados de outras tabelas. Adicionar campos a tabelas ou criar novas tabelas para clarificar as relações, se necessário.

  • Optimizar a estrutura    

Analisar a existência de erros na estrutura. Criar as tabelas e adicionar alguns registos de dados de exemplo. Verificar se obtém os resultados pretendidos das tabelas. Efectuar ajustes na estrutura, se necessário.

  • Aplicar as regras de normalização    

Aplicar as regras de normalização de dados para verificar se as tabelas estão estruturadas correctamente. Efectuar ajustes nas tabelas, se necessário.

Início da Página Início da Página

Determinar o objectivo da base de dados

É aconselhável anotar num papel o objectivo da base de dados — o objectivo, como espera utilizá-la e quem a irá utilizar. Por exemplo, numa base de dados reduzida de um negócio doméstico, poderá escrever algo como "A base de dados de clientes mantém uma lista de informações sobre os clientes para geração de correio e relatórios." Se a base de dados for mais complexa ou se for utilizada por várias pessoas, como acontece normalmente numa empresa, o objectivo poderá ocupar um parágrafo ou mais e deve incluir quando e como cada pessoa utilizará a base de dados. A ideia é criar uma instrução bem delineada sobre a missão, que possa ser consultada durante o processo de estruturação. Este tipo de instrução ajuda-o a centrar-se nos objectivos quando toma decisões.

Início da Página Início da Página

Localizar e organizar as informações necessárias

Para localizar e organizar as informações necessárias, comece com as informações existentes. Por exemplo, pode registar ordens de compra num razão ou manter as informações do cliente em formulários em papel num arquivo de ficheiros. Recolha esses documentos e liste cada tipo de informações mostrado (por exemplo, cada caixa que preenche num formulário). Se não tiver formulários existentes, imagine que os tem para estruturar um formulário para registar as informações do cliente. Que informações incluiria no formulário? Que caixas de preenchimento criaria? Identifique e liste cada um destes itens. Por exemplo, supondo que mantém actualmente a lista de clientes em cartões de índice. A análise destes cartões pode mostrar que cada cartão contém um nome de cliente, morada, localidade, distrito, código postal e número de telefone. Cada um destes itens representa uma coluna potencial numa tabela.

Quando preparar esta lista, não se preocupe em fazê-la perfeita à primeira. Em vez disso, liste cada item que lhe vier à ideia. Se a base de dados se destinar a mais utilizadores, solicite-lhes também as suas ideias. Pode optimizar a lista mais tarde.

Em seguida, considere os tipos de relatórios ou correio que poderá pretender criar a partir da base de dados. Por exemplo, pode pretender um relatório de vendas de um produto para mostrar as vendas por região ou o resumo de um inventário que mostre os níveis do inventário do produto. Também poderá pretender criar cartas de formulário para enviar aos clientes anunciando um acontecimento de vendas ou a oferta de um prémio. Crie a estrutura do relatório mentalmente e imagine qual o aspecto que terá. Que informações incluiria no relatório? Liste todos os itens. Faça o mesmo para a carta de formulário e para todos os relatórios que prevê criar.

Uma pessoa a imaginar um relatório do inventário de um produto

Os relatórios e correio que pode pretender criar ajudam-no a identificar itens de que irá necessitar na base de dados. Por exemplo, supondo que concede aos cliente a opção de receberem (ou não receberem) actualizações periódicas por correio electrónico e que pretende imprimir uma lista dos clientes que optaram por receber. Para registar essas informações, adiciona uma coluna “Enviar correio electrónico” à tabela de clientes. Para cada cliente, pode definir o campo para Sim ou Não.

O requisito de envio de mensagens de correio electrónico para clientes sugere outro item para registo. Depois de saber que um cliente pretende receber mensagens de correio electrónico, também tem de saber o respectivo endereço de correio electrónico para o qual as enviar. Por esse motivo, tem de registar um endereço de correio electrónico para cada cliente.

É aconselhável construir um protótipo de cada relatório ou lista de resultados e considerar quais os itens que necessitará para criar o relatório. Por exemplo, quando examina uma carta de formulário, poderão ocorre-lhe determinadas hipóteses. Se pretender incluir um saudação adequada — por exemplo, a cadeia "Sr.", "Sra." ou "Dr." que inicia uma saudação, terá de criar um item de saudação. Também poderá iniciar uma carta por “Exm.º Sr. Martins”, em vez de “Exm.º Sr. Paulo Martins”. Isto indica que pretende armazenar o apelido em separado do nome próprio.

Um ponto chave a lembrar é que deve dividir cada parte das informações em elementos úteis mais pequenos. No caso de um nome, para disponibilizar prontamente o apelido, divide-o em dois elementos — Nome Próprio e Apelido. Para ordenar por apelido, por exemplo, deve armazenar o apelido do cliente em separado. De forma geral, se pretender ordenar, procurar, calcular ou criar um relatório com base num item de informações, deve colocar esse item no seu próprio campo.

Pense nas questões a que pretende que a base de dados responda. Por exemplo, quantas vendas do seu produto fechou no mês anterior? Onde vivem os seus melhores clientes? Qual o fornecedor do produto com mais procura? A antecipação destas questões ajuda-o a identificar os itens adicionais a registar.

Depois de recolher estas informações, está pronto para o passo seguinte.

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 entidades ou assuntos mais importantes. Por exemplo, depois de localizar e organizar as informações de uma base de dados de vendas de um produto, a lista preliminar poderá ter o seguinte aspecto:

Itens de informações manuscritas agrupados por assuntos

As entidades mais importantes aqui mostradas são os produtos, os fornecedores, os clientes e as encomendas. Como tal, é aconselhável começar com estas quatro tabelas: uma para os factos sobre os produtos, uma para os factos sobre os fornecedores, uma para os factos sobre os clientes e uma para os factos sobre as encomendas. Embora a lista não fique completa, é um bom ponto de partida. Pode continuar a optimizar esta lista até obter uma estrutura que funcione correctamente.

Quando examina pela primeira vez a lista preliminar de itens, poderá ficar tentado em colocá-las numa única tabela, em vez das quatro mostradas na ilustração anterior. Irá descobrir por que motivo não é uma boa ideia. Considere por alguns momentos a tabela aqui mostrada:

Imagem que mostra uma tabela que contém produtos e fornecedores

Neste caso, cada linha contém informações sobre o produto e o respectivo fornecedor. Uma vez que pode ter vários produtos do mesmo fornecedor, as informações do nome e da morada do fornecedor têm de ser repetidas várias vezes. Desta forma, ocupa demasiado espaço em disco. O registo das informações do fornecedor apenas uma vez numa coluna em separado e, em seguida, a respectiva associação à tabela Produtos, é uma solução mais eficaz.

Um segundo problema desta estrutura ocorre quando é necessário modificar informações sobre o fornecedor. Por exemplo, supondo que necessita de alterar a morada de um fornecedor. Uma vez que aparece em vários locais, poderá alterar a morada num local, mas esquecer-se, acidentalmente, de alterá-la noutros. O registo da morada do fornecedor num único local resolve o problema.

Quando estrutura a base de dados, tente sempre registar cada facto apenas uma vez. Se detectar que está a repetir as mesma informações em mais de um local, como, por exemplo, a morada de um determinado fornecedor, coloque essas informações numa tabela em separado.

Por fim, suponha que existe apenas um produto fornecido pela Adega Coho e pretende eliminar o produto, mas manter as informações sobre o nome e a morada do fornecedor. De que forma elimina o registo do produto sem perder também as informações do fornecedor? Não é possível. Uma vez que cada registo inclui factos sobre o produto, bem como factos sobre um fornecedor, não é possível eliminar um sem eliminar o outro. Para manter estes factos em separado, tem de dividir a tabela em duas: uma tabela para as informações sobre o produto e outra para as informações sobre o fornecedor. A eliminação do registo de um produto deve eliminar apenas os factos referentes ao produto e não os factos sobre o fornecedor.

Depois de escolher o assunto que é representado por uma tabela, as respectivas colunas devem armazenar factos apenas sobre o assunto. Por exemplo, a tabela de produtos deve armazenar factos apenas sobre produtos. Uma vez que a morada do fornecedor é um facto sobre o fornecedor e não um facto sobre o produto, pertence à tabela de fornecedores.

Início da Página Início da Página

Transformar os itens de informações em colunas

Para determinar as colunas de uma tabela, decida quais as informações que necessita registar sobre o assunto registado na tabela. Por exemplo, para a tabela Clientes, o Nome, Morada, Código postal, Enviar mensagem de correio electrónico, Saudação e Endereço de correio electrónico formam uma lista inicial de colunas adequada. Cada registo na tabela contém o mesmo conjunto de colunas, pelo que pode armazenar as informações sobre o Nome, Morada, Código postal, Enviar mensagem de correio electrónico, Saudação e Endereço de correio electrónico de cada registo. Por exemplo, a coluna de endereços contém as moradas dos clientes. Cada registo inclui dados sobre um cliente e o campo da morada contém a morada desse cliente.

Depois de determinar o conjunto inicial de colunas para cada tabela, pode optimizá-las. Por exemplo, é aconselhável armazenar o nome do cliente em duas colunas separadas: nome próprio e apelido, para poder ordenar, procurar e indexar nessas colunas. Da mesma forma, a morada é composta por cinco componentes individuais, morada, localidade, distrito, código postal e país/região, sendo também aconselhável armazená-los em colunas em separado. Se pretender efectuar uma operação de procura, filtro ou ordenação por distrito, por exemplo, necessita das informações sobre o distrito armazenadas numa coluna em separado.

Também deve ter em consideração se a base de dados incluirá informações apenas de origem nacional ou também internacional. Por exemplo, se pretender armazenar moradas internacionais, é aconselhável criar uma coluna Região em vez de Distrito, porque esta coluna pode acomodar distritos nacionais e regiões de outros países/regiões. Da mesma forma, Código Postal é mais indicado do que Código Zip (E.U.A.) se armazenar moradas internacionais.

A lista seguinte mostra algumas sugestões para determinação das colunas a utilizar.

  • Não incluir dados calculados    

Na maioria dos casos, não deve armazenar o resultado de cálculos em tabelas. Em vez disso, o Access pode efectuar os cálculos quando pretender ver o resultado. Por exemplo, supondo que existe um relatório Produtos Da Encomenda que apresenta o subtotal de unidades na encomenda para cada categoria de produtos na base de dados. No entanto, não existe uma coluna de subtotal Unidades Da Encomenda em qualquer tabela. Em vez disso, a tabela Produtos inclui uma coluna Unidades Da Encomenda que armazena as unidades da encomenda por cada produto. Utilizando esses dados, o Access calcula o subtotal sempre que imprime o relatório. O próprio subtotal não deve ser armazenado numa tabela.

  • Armazenar informações nos respectivos elementos lógicos mais pequenos.    

Poderá preferir utilizar um único campo para nomes completos ou para nomes de produtos em conjunto com as respectivas descrições. Se combinar mais de um tipo de informações num campo, é difícil obter os factos individuais posteriormente. Experimente dividir as informações em elementos lógicos; por exemplo, crie campos em separado para o nome próprio e apelido ou para o nome do produto, categoria e descrição.

Lista de itens de informações durante o processo de estruturação

Depois de optimizar as colunas de dados de cada tabela, está pronto para escolher a chave primária para cada tabela.

Início da Página Início da Página

Especificar chaves primárias

Cada tabela deve incluir uma coluna ou conjunto de colunas que identifiquem em exclusivo cada linha armazenada na tabela. Normalmente, trata-se de um número de identificação exclusivo, como, por exemplo o número do código de um empregado ou um número de série. Na terminologia de bases de dados, estas informações são designadas por chave primária da tabela. O Access utiliza campos de chave primária para associar rapidamente dados de várias tabelas e apresentá-los em conjunto.

Se já tiver um identificador exclusivo para uma tabela, como, por exemplo, um número de produto que identifique exclusivamente cada produto no catálogo, pode utilizar esse identificador como chave primária da tabela — mas só se os valores nessa coluna forem sempre diferentes para cada registo. Não é possível ter valores em duplicado numa chave primária. Por exemplo, não utilize nomes de pessoas como chave primária, porque os nomes não são exclusivos. Podem existir duas pessoas com o mesmo nome na mesma tabela.

Uma chave primária tem de ter sempre um valor. Se, a determinado momento, o valor de uma coluna vier a deixar de estar atribuído ou se tornar desconhecido (um valor em falta), não pode ser utilizado como um componente numa chave primária.

Deve escolher sempre uma chave primária em que o valor não é alterado. Numa base de dados que utiliza mais de uma tabela, pode ser utilizada a chave primária de uma tabela como referência noutras tabelas. Se a chave primária for alterada, a alteração tem de ser aplicada também em todos os locais em que esta é referenciada. A utilização de uma chave primária que não sofre alterações reduz as hipóteses de esta vir a deixar de estar sincronizada com outras tabelas em que é referenciada.

Normalmente, é utilizado um número exclusivo arbitrário como a chave primária. Por exemplo, pode atribuir um número de encomenda exclusivo a cada encomenda. O único objectivo do número de encomenda é identificar uma encomenda. Depois de atribuído, nunca é alterado.

Se não lhe ocorrer nenhuma coluna ou conjunto de colunas que possam constituir uma chave primária adequada, considere utilizar uma coluna que tenha um tipo de dados Numeração Automática. Quando utiliza o tipo de dados Numeração Automática, o Access atribui automaticamente um valor. Este tipo de identificador não inclui factos; não contém informações factuais que descrevam a linha que representa. Os identificadores sem factos são indicados como chave primária, uma vez que não são alterados. Uma chave primária que inclua factos sobre uma linha — um número de telefone ou o nome de um cliente, por exemplo — tem mais probabilidades de ser alterada, porque as próprias informações factuais podem ser alteradas.


Imagem que mostra a tabela Produtos com um campo de chave primária

Chamada 1 Normalmente, uma coluna definida com o tipo de dados Numeração Automática constitui uma chave primária adequada. Não existem dois códigos de produto iguais.

Em determinados casos, poderá pretender utilizar dois ou mais campos que, em conjunto, forneçam a chave primária de uma tabela. Por exemplo, uma tabela Detalhes da Encomenda que armazene itens de linha para encomendas, utilizaria duas colunas na respectiva chave primária: Código da Encomenda e Código do Produto. Quando uma chave primária emprega mais de uma coluna, também é designada por chave composta.

Para a base de dados de vendas de produtos, pode criar uma coluna Numeração Automática para cada uma das tabelas, que servirá de chave primária: CódigoDoProduto para a tabela Produtos, CódigoDaEncomenda para a tabela Encomendas, CódigoDoCliente para a tabela Clientes e CódigoDoFornecedor para a tabela Fornecedores.

Imagem que mostra os itens de informações durante o processo de estruturação

Início da Página Início da Página

Criar as relações entre tabelas

Depois de dividir as informações em tabelas, é necessário associá-las novamente de forma coerente. Por exemplo, o formulário seguinte inclui informações de várias tabelas.


O formulário Encomendas

Chamada 1 As informações neste formulário derivam da tabela Clientes...
Chamada 2 ...tabela Empregados...
Chamada 3 ...tabela Encomendas...
Chamada 4 ...tabela Produtos...
Chamada 5 ...e da tabela Detalhes da Encomenda.

O Access é um sistema de base de dados relacional. Numa base de dados relacional, as informações são divididas em tabelas separadas baseadas em assuntos. Em seguida, as relações entre as tabelas são utilizadas para associar as informações conforme necessário.

Início da Página Início da Página

Criar um relação um-para-muitos

Considere este exemplo: as tabelas Fornecedores e Produtos na base de dados de encomendas de produtos. Um fornecedor pode fornecer vários produtos. Portanto, para qualquer fornecedor representado na tabela Fornecedores, podem existir vários produtos representados na tabela Produtos. A relação entre a tabela Fornecedores e a tabela Produtos é, por conseguinte, uma relação um-para-muitos.

Conceito um-para-muitos

Para representar uma relação um-para-muitos na estrutura da base de dados, adicione a chave primária do lado "um" da relação como uma coluna ou colunas adicionais à tabela no lado "muitos" da relação. Neste caso, por exemplo, adicione a coluna Código do Fornecedor à tabela Produtos. Em seguida, o Access pode utilizar o número do código do fornecedor na tabela Produtos para localizar o fornecedor correcto de cada produto.

A coluna Código do Fornecedor na tabela Produtos é designada por chave externa. Uma chave externa é a chave primária de outra tabela. A coluna Código do Fornecedor na tabela Produtos é uma chave externa, porque também é a chave primária na tabela Fornecedores.

Lista de itens de informações durante o processo de estruturação

O utilizador fornece a base para associar as tabelas relacionadas estabelecendo pares de chaves primárias e de chaves externas. Se não tiver a certeza de quais as tabelas que devem partilhar uma coluna comum, a identificação de uma relação um-para-muitos assegura que as duas tabelas envolvidas irão, efectivamente, necessitar de uma coluna partilhada.

Início da Página Início da Página

Criar uma relação muitos-para-muitos

Considere a relação entre a tabela Produtos e a tabela Encomendas.

Uma única encomenda pode incluir mais de um produto. Por outro lado, um único produto pode aparecer em várias encomendas. Como tal, para cada registo na tabela Encomendas, podem existir vários registos na tabela Produtos. E para cada registo na tabela Produtos, podem existir vários registos na tabela Encomendas. Este tipo de relação é designada por uma relação muitos-para-muitos, porque para qualquer produto, podem existir várias encomendas; e para qualquer encomenda, podem existir vários produtos. Note que para detectar relações muitos-para-muitos entre as tabelas, é importante considerar ambos os lados da relação.

Os assuntos das duas tabelas — encomendas e produtos — têm uma relação muitos-para-muitos. Isto representa um problema. Para compreender o problema, imagine o que aconteceria se tentasse criar a relação entre as duas tabelas adicionando o campo Código do Produto à tabela Encomendas. Para ter mais de um produto por encomenda, necessita de mais de um registo na tabela Encomendas por encomenda. Repetiria as informações da encomenda em cada linha associada a uma única encomenda — resultando numa estrutura ineficaz que poderia gerar dados imprecisos. O mesmo problema ocorre se colocar o campo Código da Encomenda na tabela Produtos — teria mais de um registo na tabela Produtos para cada produto. Como resolver este problema?

A resposta é criar uma terceira tabela, normalmente designada por tabela de união, que divide a relação muitos-para-muitos em duas relações um-para-muitos. O utilizador introduz a chave primária de cada uma das duas tabelas na terceira tabela. Como resultado, a terceira tabela regista todas as ocorrências ou instâncias da relação.

Uma relação muitos-para-muitos

Cada registo na tabela Detalhes da Encomenda representa um item de linha numa encomenda. A chave primária da tabela Detalhes da Encomenda é composta por dois campos — as chaves externas das tabelas Encomendas e Produtos. Se utilizar o campo Código da Encomenda sozinho, este não funcionará como chave primária para esta tabela, porque uma encomenda pode ter vários itens de linha. O Código da Encomenda repete-se em todos os itens de linha numa encomenda, pelo que o campo não contém valores exclusivos. Se utilizar o campo Código do Produto sozinho, este também não funciona, porque um produto pode aparecer em várias encomendas diferentes. No entanto, utilizados em conjunto, os dois campos geram sempre um valor exclusivo para cada registo.

Na base de dados de vendas de produtos, a tabela Encomendas e a tabela Produtos não estão directamente associadas uma à outra. Estão indirectamente associadas através da tabela Detalhes da Encomenda. A relação muitos-para-muitos entre encomendas e produtos é representada na base de dados utilizando duas relações um-para-muitos:

  • A tabela Encomendas e a tabela Detalhes da Encomenda têm uma relação um-para-muitos. Cada encomenda tem mais de um item de linha, mas cada item de linha está associado apenas a uma encomenda.
  • A tabela Produtos e a tabela Detalhes da Encomenda têm uma relação um-para-muitos. Cada produto pode ter vários itens de linha associados, mas cada item de linha está associado apenas a um produto.

A partir da tabela Detalhes da Encomenda, é possível determinar todos os produtos numa determinada encomenda. Também é possível determinar todas as encomendas de um determinado produto.

Depois de incorporar a tabela Detalhes da Encomenda, a lista de tabelas e campos deverá ter o seguinte aspecto:

Lista de itens de informações durante o processo de estruturação

Início da Página Início da Página

Criar um relação um-para-um

Outro tipo de relação é a relação um-para-um. Por exemplo, supondo que necessita de registar informações adicionais sobre o produto, as quais necessita raramente ou se aplicam apenas a alguns produtos. Uma vez que não necessita dessas informações frequentemente e porque o armazenamento das informações na tabela Produtos resultaria em espaços vazios para todos os produtos aos quais não se aplicam, coloque-as numa tabela em separado. Tal como acontece com a tabela Produtos, o Código do Produto é utilizado como chave primária. A relação entre esta tabela adicional e a tabela Produtos é uma relação um-para-um. Para cada registo na tabela Produtos, existe um único registo com correspondência na tabela adicional. Quando identifica uma relação deste tipo, ambas as tabelas têm de partilhar um campo comum.

Quando detecta a necessidade de uma relação um-para-um na base de dados, considere se é possível colocar as informações das duas tabelas juntas numa única tabela. Se não pretender fazê-lo por qualquer motivo, talvez porque resultaria em muitos espaços vazios, a lista que se segue mostra como representar a relação na estrutura:

  • Se as duas tabelas tiverem o mesmo assunto, poderá configurar a relação utilizando a mesma chave primária em ambas.
  • Se as duas tabelas tiverem assuntos diferentes com chaves primárias diferentes, escolha uma das tabelas (qualquer uma) e introduza a respectiva chave primária na outra tabela como chave externa.

Determinar as relações entre tabelas ajuda a garantir que tem as colunas e tabelas adequadas. Quando existe uma relação um-para-um ou um-para-muitos, as tabelas envolvidas têm de partilhar uma coluna ou colunas comuns. Quando existe uma relação muitos-para-muitos, é necessária uma terceira tabela para representar a relação.

Início da Página Início da Página

Optimizar a estrutura

Depois de ter as tabelas, campos e relações de que necessita, deve criar e preencher as tabelas com dados de exemplo e experimentar trabalhar com as informações: criando consultas, adicionando novos registos, etc. Este método ajuda a realçar problemas potenciais — por exemplo, poderá ser necessário adicionar uma coluna que se esqueceu de inserir durante a fase de estruturação ou poderá ter uma tabela que é necessário dividir em duas tabelas para remover duplicados.

Verifique se consegue utilizar a base de dados para obter as respostas que pretende. Faça rascunhos dos seus formulários e relatórios e veja se apresentam os dados que esperava. Procure dados em duplicado desnecessários e, se existirem, altere a estrutura para eliminá-los.

À medida que experimenta a base de dados inicial, provavelmente descobrirá pontos a melhorar. Seguem-se alguns elementos que deverá verificar:

  • Esqueceu-se de alguma coluna? Se for o caso, as informações encontram-se nas tabelas existentes? Se se tratarem de informações sobre outro assunto, poderá ser necessário criar outra tabela. Crie uma coluna para todos os itens de informações que pretende registar. Se não for possível obter as informações a partir de outras colunas, é provável que necessite de uma nova coluna.
  • Existem colunas desnecessárias passíveis de serem calculadas a partir de campos existentes? Se um item de informações for passível de ser calculado a partir de outras colunas existentes — por exemplo, um preço com desconto calculado a partir do preço de retalho — é melhor não efectuar qualquer outra acção e evitar criar uma nova coluna.
  • Está a introduzir repetidamente informações em duplicado numa das tabelas? Se for o caso, poderá ser necessário dividir a tabela em duas tabelas com uma relação um-para-muitos.
  • Existem tabelas com vários campos, um número limitado de registos e vários campos vazios em registos individuais? Se for o caso, experimente criar uma nova estrutura da tabela para que contenha menos campos e mais registos.
  • Todos os itens de informações foram divididos em elementos úteis mais pequenos? Se for necessário criar um relatório, ordenar, procurar ou efectuar cálculos com base num item de informações, coloque-os numa coluna individual.
  • Todas as colunas contêm factos sobre o assunto da tabela? Se uma coluna não incluir informações sobre o assunto da tabela, significa que pertence a uma tabela diferente.
  • Estão representadas todas as relações entre as tabelas, por campos comuns ou por uma terceira tabela? As relações um-para-um e um-para-muitos requerem colunas em comum. As relações muitos-para-muitos requerem uma terceira tabela.

Optimizar a tabela Produtos

Suponha que cada produto na base de dados de vendas de produtos está compreendido numa determinada categoria, como, por exemplo, bebidas, condimentos ou marisco. A tabela Produtos poderia incluir um campo que mostre a categoria de cada produto.

Suponha que após examinar e optimizar a estrutura da base de dados, decide armazenar uma descrição da categoria juntamente com o respectivo nome. Se adicionar um campo Descrição da Categoria à tabela Produtos, tem de repetir cada descrição da categoria para cada produto correspondente à mesma — esta não é uma solução eficaz.

A melhor solução é criar um novo assunto, Categorias, na base de dados para efectuar o registo na sua própria tabela e chave primária. Em seguida, pode adicionar a chave primária da tabela Categorias à tabela Produtos como chave externa.

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 apenas a uma categoria.

Quando examina as estruturas das tabelas, tenha atenção aos grupos repetidos. Por exemplo, considere uma tabela que contém as seguintes colunas:

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

Aqui, cada produto é um grupo repetido de colunas que só difere das restantes pela adição de um número no fim do nome da coluna. Quando vê as colunas numeradas desta forma, deve rever a estrutura.

Este tipo de estrutura apresenta diversas falhas. Para começar, força-o a colocar um limite máximo no número de produtos. Quando excede esse limite, tem de adicionar um novo grupo de colunas à estrutura da tabela, o que significa uma tarefa administrativa mais extensa.

Outro problema prende-se com o facto de que os fornecedores que têm um número de produtos inferior ao limite máximo ocupam espaço desnecessário, porque as colunas adicionais estão vazias. A falha mais grave neste tipo de estrutura é tornar difícil a execução de algumas tarefas, como, por exemplo, a ordenação ou indexação da tabela por código do produto ou nome.

Sempre que vir grupos repetidos, reveja a estrutura atentamente, com vista a dividir a tabela em duas. No exemplo anterior, é mais eficaz utilizar duas tabelas, uma para fornecedores e uma para produtos, associadas por um código de fornecedor.

Início da Página Início da Página

Aplicar as regras de normalização

No passo seguinte, pode aplicar as regras de normalização de dados (por vezes designadas apenas por regras de normalização) na estrutura. Estas regras são utilizadas para verificar se as tabelas estão estruturadas correctamente. O processo de aplicação das regras na estrutura da base de dados é denominado por normalização da base de dados ou apenas normalização.

A normalização é útil, sobretudo depois de ter representado todos os itens de informações e de ter criado uma estrutura preliminar. A ideia é ajudá-lo a certificar-se de que colocou os itens de informações nas tabelas apropriadas. O que a normalização não consegue fazer é garantir que tem todos os itens de dados indicados para começar.

As regras são aplicadas em sequência, certificando-se em cada fase de que a estrutura é considerada aquilo que se chama de "formulário de normalização." São aceites cinco formulários de normalização : do primeiro formulário de normalização ao quinto formulário de normalização. Este artigo descreve os primeiros três, pois são os necessários para a maioria das estruturas de base de dados.

Primeiro formulário de normalização

O primeiro formulário de normalização indica que em todas as intersecções de linhas e colunas existe um único valor e nunca uma lista de valores. Por exemplo, não é possível ter um campo com o nome Preço, em que coloca mais de um Preço. Se pensar em cada intersecção de linhas e colunas como uma célula, cada célula pode incluir apenas um valor.

Segundo formulário de normalização

O segundo formulário de normalização requer que todas as colunas que não são chave sejam totalmente dependentes da chave primária completa e não apenas de parte da mesma. Esta regra aplica-se quando tem uma chave primária composta por mais de uma coluna. Por exemplo, suponha que tem uma tabela que contém as seguintes colunas, onde Código da Encomenda e Código do Produto formam a chave primária:

  • Código da Encomenda (chave primária)
  • Código do Produto (chave primária)
  • Nome do Produto

Esta estrutura viola o segundo formulário de normalização, porque Nome do Produto é dependente de Código do Produto, mas não de Código da Encomenda, pelo que não é dependente da chave primária completa. Tem de remover Nome do Produto da tabela. Pertence a uma tabela diferente (Produtos).

Terceiro formulário de normalização

O terceiro formulário de normalização requer que todas as colunas que não são chave sejam dependentes da chave primária completa, mas também que estas colunas sejam independentes umas das outras.

Por outras palavras, todas as colunas que não são chave têm de ser dependentes só e apenas da chave primária. Por exemplo, suponha que tem uma tabela que contém as seguintes colunas:

  • Código do Produto (chave primária)
  • Nome
  • PVR
  • Desconto

Suponha que a coluna Desconto depende do preço de venda recomendado (PVR). Esta tabela viola o terceiro formulário de normalização, porque uma coluna que não é chave, Desconto, depende de outra coluna que não é chave, PVR. A independência das colunas significa que o utilizador deverá conseguir alterar uma coluna que não é chave sem afectar qualquer outra coluna. Se alterar um valor no campo PVR, o campo Desconto seria alterado em conformidade, o que violaria essa regra. Neste caso, o campo Desconto deve ser movido para outra tabela baseada na chave-primária PVR.

Início da Página Início da Página

Para obter mais informações

Para mais informações sobre os princípios fundamentais da estrutura de tabelas, consulte o artigo Criar tabelas numa base de dados.

Para obter informações adicionais sobre a estrutura de bases de dados, consulte os seguintes livros:

  • Hernandez, Michael J. Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design, Second Edition. Addison-Wesley Professional. 2003.
  • Fleming, Candace C. von Halle, Barbara. Handbook of Relational Database Design. Addison-Wesley Professional. 1989.
  • Riordan, Rebecca M. Designing Effective Database Systems. Addison-Wesley Professional. 2005.

Início da Página Início da Página

 
 
Aplica-se a:
Access 2007