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

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

Uma base de dados devidamente estruturada dá-lhe acesso a informações precisas e atualizadas. É essencial ter uma estrutura correta para alcançar os seus objetivos ao trabalhar com uma base de dados e investir o tempo necessário para aprender os princípios de uma boa estruturação. Desta forma, é mais provável obter uma base de dados que corresponda às suas necessidades e que permita efetuar alterações facilmente.

Este artigo inclui orientações para planear uma base de dados de ambiente de trabalho. Irá aprender a identificar as informações de que precisa, como dividir corretamente as informações em tabelas e colunas e como essas tabelas estão relacionadas. Deve ler este artigo antes de criar a sua primeira base de dados de ambiente de trabalho.

Importante: O Access oferece experiências de estruturação que lhe permitem criar aplicações de base de dados para a Web. Muitos aspetos da estruturação são diferentes quando faz a estruturação para a Web. Este artigo não aborda a estruturação de aplicações de base de dados Web. Para obter mais informações, consulte o artigo Criar uma base de dados para partilhar na Web.

Neste artigo

Alguns termos de base de dados a conhecer

O que é uma boa estrutura de base de dados?

O processo de estruturação

Determinar o objetivo da base de dados

Localizar e organizar as informações necessárias

Dividir informações em tabelas

Transformar itens de informação em colunas

Especificar chaves primárias

Criar relações de tabelas

Aperfeiçoar a estrutura

Aplicar as regras de normalização


Alguns termos de base de dados a conhecer

O Access organiza as informações em tabelas: listas de linhas e colunas que lembram o teclado de marcação de um contabilista ou uma folha de cálculo. Numa base de dados simples, poderá ter apenas uma tabela. Para a maioria das bases de dados, é necessário ter mais do que uma tabela. Por exemplo, pode ter uma tabela com as informações sobre os produtos, outra tabela com informações sobre as encomendas e uma outra com informações sobre os clientes.

Imagem ilustrando três tabelas em folhas de dados

Cada linha é designada, mais corretamente, por registo e cada coluna por campo. Um registo é uma forma consistente e relevante de combinar informações sobre algo. Um campo é um único item de informação, ou seja, um tipo de item que aparece em cada registo. Na tabela Produtos, por exemplo, cada linha ou registo contém informações sobre um produto. Cada coluna ou campo contém algum tipo de informação sobre esse produto, como o nome ou o preço.

Início da Página

O que é uma boa estrutura de base de dados?

O processo de estruturação é baseado em alguns princípios. O primeiro princípio é que as informações duplicadas (também denominadas dados redundantes) são prejudiciais, pois ocupam espaço desnecessário e aumentam 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 a sua base de dados tiver informações incorretas, qualquer relatório que extraia informações da base de dados também terá informações incorretas. Consequentemente, as decisões que tomar serão feitas com base nas informações incorretas desses relatórios.

Uma boa estrutura de base de dados deve:

  • Dividir as informações em tabelas baseadas em assuntos para reduzir o número de dados redundantes.

  • Transmitir ao Access as informações necessárias para associar as informações das tabelas conforme necessário.

  • Ajudar a suportar e garantir a precisão e a integridade das informações da base de dados.

  • Satisfazer as suas necessidades de criação de relatórios e processamento de dados.

Início da Página

O processo de estruturação

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

  • Determinar o objetivo da base de dados    

    Isto ajuda-o a preparar-se para os restantes passos.

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

    Reúna todos os tipos de informações que pretende registar na base de dados, como nomes de produtos e números de encomenda.

  • Dividir informações em tabelas    

    Divida os itens de informação em entidades ou assuntos principais, como produtos ou encomendas. Cada assunto torna-se uma tabela.

  • Transformar itens de informação em colunas    

    Decida que informações pretende armazenar em cada tabela. Cada item torna-se um campo e é apresentado como uma coluna na tabela. Por exemplo, uma tabela designada Funcionários poderá incluir campos como Apelido, Nome Próprio e Data de Contratação.

  • Especificar chaves primárias    

    Escolha a chave primária de cada tabela. A chave primária é uma coluna utilizada para identificar cada linha. Por exemplo, pode ser o ID do Produto ou ID da Encomenda.

  • Estabelecer relações de tabelas    

    Observe para cada tabela e decida de que forma é que os dados numa tabela estão relacionados com os dados noutras tabelas. Adicione campos às tabelas ou crie novas tabelas para definir as relações, conforme necessário.

  • Aperfeiçoar a estrutura    

    Verifique se existem erros na estrutura. Crie as tabelas e adicione alguns registos de dados de exemplo. Veja se consegue obter os resultados que pretende a partir das tabelas. Ajuste a estrutura conforme necessário.

  • Aplicar as regras de normalização    

    Aplique regras de normalização de dados para ver se as suas tabelas estão corretamente estruturadas. Ajuste as tabelas conforme necessário.

Início da Página

Determinar o objetivo da base de dados

É aconselhável escrever uma descrição do objetivo da base de dados num papel, juntamente com a forma como a pretende utilizar e quem a irá utilizar. Por exemplo, para uma base de dados pequena para um negócio doméstico, poderá escrever algo simples como "A base de dados de clientes contém uma lista de informações de clientes com o objetivo de criar e-mails e relatórios". Se a base de dados for mais complexa ou for utilizada por muitas pessoas, como ocorre frequentemente em empresas de maior dimensão, o objetivo pode ser facilmente descrito num parágrafo ou mais e deve incluir informações sobre quando e como cada pessoa irá utilizar a base de dados. A ideia é ter uma declaração de objetivos bem desenvolvida que possa ser consultada durante o processo de estruturação. Isto ajuda-o a concentrar-se nos seus objetivos durante a tomada de decisões.

Início da Página

Localizar e organizar as informações necessárias

Para localizar e organizar as informações necessárias, comece pelas informações existentes. Por exemplo, pode ter registado as notas de encomenda num registo financeiro ou mantido as informações dos clientes em formulários de papel. Reúna esses documentos e faça uma lista de cada tipo de informação apresentado (por exemplo, cada caixa que preenche num formulário). Se não tiver um formulário existente, imagine que tem de estruturar um formulário para registar as informações dos clientes. Que informações colocaria no formulário? Que caixas de preenchimento criaria? Identifique e faça uma lista destes itens. Por exemplo, imaginemos que guarda a lista de clientes em marcadores de índice. Ao examinar estes marcadores, poderá ver que cada um deles contém o nome do cliente, endereço, distrito, código postal localidade e número de telefone. Cada um destes itens representa uma potencial coluna numa tabela.

Quando preparar esta lista, não se preocupe em deixá-la perfeita inicialmente. Opte por adicionar à lista todos os itens de que se lembrar. Se alguém estiver a utilizar a base de dados, peça-lhes que também contribuam com ideias. Pode aperfeiçoar a lista mais tarde.

Em seguida, pense nos tipos de relatório ou e-mail que pretende criar a partir da base de dados. Por exemplo, poderá querer um relatório de vendas de produtos que apresente as vendas por região ou um relatório de resumo de inventário que apresente os níveis de inventário dos produtos. Também poderá querer criar cartas de formulário para enviar aos clientes a anunciar uma promoção ou uma oferta Premium. Estruture o relatório na sua cabeça e imagine o seu aspeto. Que informações incluiria no relatório? Faça uma lista de todos os itens. Repita o mesmo processo para a carta de formulário e para qualquer outro relatório que pretenda criar.

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

Pensar nos relatórios e e-mails que pretende criar ajuda-o a identificar os itens de que precisa na sua base de dados. Por exemplo, imagine que dá aos clientes a possibilidade de optarem por receber (ou não receber) atualizações periódicas por e-mail e que pretende imprimir uma listagem das pessoas que optaram por receber. Para registar essas informações, adicione uma coluna "Enviar e-mail" à tabela de clientes. Pode definir o campo como Sim ou Não para cada cliente.

O requisito para enviar mensagens de e-mail aos clientes sugere outro item a registar. Quando souber que um cliente pretende receber mensagens de e-mail, também terá de saber o endereço de e-mail para o qual as deve enviar. Consequentemente, precisa de registar um endereço de e-mail para cada cliente.

Faz todo o sentido criar um protótipo de cada relatório ou lista de resultados e considerar os itens de que precisa para criar o relatório. Por exemplo, ao examinar uma carta de formulário poderá lembrar-se de alguns itens. Se quiser incluir uma saudação adequada, como a abreviatura "Sr." ou "Sra." que inicia uma saudação, terá de criar um item de saudação. Além disso, pode iniciar uma carta com "Caro Sr. Sarmento" em vez de "Caro Sr. Guilherme Sarmento". Isto geralmente sugere que pretende armazenar o apelido separadamente do nome próprio.

Um ponto importante a lembrar é que deve dividir cada informação em partes úteis mais pequenas. No caso de um nome, para que o apelido esteja disponível, divida o nome em duas partes – o Nome Próprio e o Apelido. Por exemplo, é útil ter o apelido do cliente armazenado separadamente para ordenar um relatório pelo apelido Em geral, se pretender ordenar, procurar, calcular ou criar relatórios com base num item de informação, deve colocar esse item no seu próprio campo.

Pense nas perguntas às quais pretende que a base de dados responda. Por exemplo, quantas vendas do seu produto em destaque fez no mês passado? Onde vivem os seus melhores clientes? Quem é o fornecedor do seu produto mais vendido? Antecipar estas perguntas ajuda-o a pensar em mais itens a registar.

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

Início da Página

Dividir informações em tabelas

Para dividir as informações em tabelas, selecione as principais entidades ou assuntos. Por exemplo, depois de encontrar e organizar as informações numa base de dados de vendas de produtos, a lista preliminar terá o seguinte aspeto:

itens de informações manuscritas agrupados por assuntos

As principais entidades aqui apresentadas são: produtos, fornecedores, clientes e encomendas. Por isso, é aconselhável começar com estas quatro tabelas: uma para factos sobre produtos, uma para factos sobre fornecedores, uma para factos sobre clientes e outra para factos sobre encomendas. Embora isto não seja uma lista completa, é um bom ponto de partida. Pode continuar a aperfeiçoar a lista até obter uma estrutura adequada.

Ao rever pela primeira vez a lista preliminar de itens, poderá sentir-se tentado a colocar tudo numa única tabela em vez de dividir os itens em quatro tabelas, conforme apresentado na ilustração anterior. Vamos explicar-lhe por que razão isso é uma má ideia. Repare na tabela aqui apresentada:

Imagem mostrando uma tabela que contém produtos e fornecedores

Neste caso, cada linha contém informações sobre o produto e o respetivo fornecedor. Uma vez que pode ter vários produtos do mesmo fornecedor, o nome e o endereço do fornecedor têm de ser repetidos várias vezes. Isto ocupa espaço desnecessário em disco. Uma solução melhor é registar as informações do fornecedor apenas uma vez na tabela Fornecedores em separado e, em seguida, associar essa tabela à tabela Produtos.

Um segundo problema com esta estrutura ocorre ao modificar as informações sobre o fornecedor. Por exemplo, suponha que precisa de alterar o endereço de um fornecedor. Uma vez que é apresentado em vários locais, o endereço poderá ser acidentalmente alterado num local, mas não nos outros. Registar o endereço do fornecedor apenas num local resolve o problema.

Quando estruturar a sua base de dados, tente sempre registar cada facto só uma vez. Se notar que está a repetir as mesmas informações em mais do que um local, como o endereço de um determinado fornecedor, coloque essas informações numa tabela separada.

Por fim, suponha que a Coho Winery fornece apenas um produto e que pretende eliminar o produto, mas manter o nome e o endereço do fornecedor. É possível eliminar o registo do produto sem perder também as informações do fornecedor? Não é possível. Uma vez que cada registo contém factos sobre um produto, bem como factos sobre um fornecedor, não pode eliminar um sem eliminar o outro. Para manter estes factos separados, 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. Ao eliminar um registo de produto, eliminará apenas os factos sobre o produto e não os factos sobre o fornecedor.

Depois de escolher o assunto de uma tabela, as colunas nessa tabela devem conter factos exclusivamente sobre esse assunto. Por exemplo, uma tabela de produtos deverá conter factos apenas sobre produtos. Uma vez que o endereço do fornecedor é um facto sobre o fornecedor, e não sobre o produto, pertence à tabela de fornecedores.

Início da Página

Transformar itens de informação em colunas

Para determinar as colunas numa tabela, decida quais as informações que precisa de monitorizar sobre o assunto registado na tabela. Por exemplo, as colunas Nome, Endereço, Distrito, Código Postal, Localidade, Enviar e-mail, Saudação e Endereço de e-mail compõem uma boa lista de colunas para a tabela Clientes. Cada registo na tabela contém o mesmo conjunto de colunas, para poder armazenar as informações sobre as colunas Nome, Endereço, Distrito, Código Postal, Localidade Enviar e-mail, Saudação e Endereço de e-mail de cada registo. Por exemplo, a coluna de endereços contém os endereços dos clientes. Cada registo contém dados sobre um cliente e o campo de endereço contém o endereço desse cliente.

Depois de determinar o conjunto inicial de colunas para cada tabela, pode aperfeiçoar ainda mais as colunas. Por exemplo, é aconselhável armazenar o nome do cliente em duas colunas separadas: nome próprio e apelido. Desta forma, pode classificar, procurar e indexar apenas nessas colunas. De forma semelhante, o endereço consiste em cinco componentes separados (endereço, distrito, código postal, localidade e país/região) e também é aconselhável armazená-los em colunas separadas. Se quiser efetuar uma pesquisa, filtrar ou ordenar por distrito, por exemplo, precisa que as informações de distrito estejam numa coluna separada.

Também deve ponderar se a base de dados irá conter informações só de origem nacional ou também internacional. Por exemplo, se planear armazenar endereços internacionais, é melhor ter uma coluna Região em vez de Distrito, porque esse tipo de coluna pode incluir os distritos nacionais e as regiões de outros países. Da mesma forma, é aconselhável utilizar o Código Postal se pretender armazenar endereços internacionais.

A lista seguinte apresenta algumas sugestões para determinar as suas colunas.

  • Não inclua dados calculados    

    Na maioria dos casos, não deve armazenar o resultado dos cálculos nas tabelas. Em alternativa, pode utilizar o Access para efetuar os cálculos quando pretender ver o resultado. Por exemplo, imaginemos que existe um relatório Produtos Encomendados que apresenta o subtotal de unidades encomendadas para cada categoria de produto na base de dados. No entanto, não existe uma coluna de subtotal das Unidades Encomendadas em nenhuma tabela. Em vez disso, a tabela Produtos inclui uma coluna Unidades Encomendadas que armazena as unidades encomendadas para cada produto. O Access utiliza esses dados para calcular o subtotal sempre que imprimir o relatório. O subtotal em si não deve estar armazenado numa tabela.

  • Armazenar informações em partes lógicas mais pequenas    

    Poderá sentir-se tentado a utilizar um único campo para os nomes completos ou para nomes de produtos juntamente com descrições dos produtos. Se combinar mais do que um tipo de informação num campo, será difícil obter factos individuais posteriormente. Experimente dividir as informações em partes lógicas. Por exemplo, crie campos separados para o nome próprio e apelido ou para o nome, categoria e descrição do produto.

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

Depois de aperfeiçoar as colunas de dados em cada tabela, está pronto para escolher a chave primária de cada tabela.

Início da Página

Especificar chaves primárias

Cada tabela deve incluir uma coluna ou conjunto de colunas que identifique exclusivamente cada linha armazenada na tabela. Esta forma de identificação geralmente é exclusiva, tal como o número de ID de um funcionário ou um número de série. Em terminologia de base de dados, esta informação é denominada chave primária da tabela. O Access utiliza campos de chaves primárias para associar rapidamente dados de várias tabelas e apresentar os dados em conjunto.

Se já tiver um identificador exclusivo para uma tabela, tal como um número de produto que identifique exclusivamente cada produto no seu catálogo, pode utilizar esse identificador como chave primária da tabela, mas apenas se os valores nessa coluna forem sempre diferentes para cada registo. Não pode ter valores duplicados numa chave primária. Por exemplo, não utilize nomes de pessoas como chave primária, uma vez que os nomes não são exclusivos. Pode facilmente ter duas pessoas com o mesmo nome na mesma tabela.

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

Deve sempre escolher uma chave primária cujo valor seja inalterável. Numa base de dados com mais do que uma tabela, a chave primária de uma tabela pode ser utilizada como referência noutras tabelas. Se a chave primária mudar, a alteração também tem de ser aplicada em todos os locais onde a chave é referenciada. Utilizar uma chave primária que não mude reduz a probabilidade de a chave primária ficar dessincronizada com outras tabelas onde é referenciada.

Geralmente, utiliza-se um número exclusivo arbitrário como chave primária. Por exemplo, pode atribuir um número de encomenda exclusivo a cada encomenda. O número de encomenda serve apenas para identificar uma encomenda. Depois de atribuído, jamais é alterado.

Se não se lembrar de uma coluna ou conjunto de colunas que daria uma boa chave primária, pondere utilizar uma coluna com o 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 contém informações factuais que descrevam a linha que representa. Os identificadores sem informações factuais são ideais para utilizar como chave primária uma vez que não mudam. Uma chave primária com factos sobre uma linha – por exemplo, um número de telefone ou o nome de um cliente – tem mais probabilidade de mudar, pois as informações factuais em si podem mudar.

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

1. Uma coluna definida para o tipo de dados Numeração Automática geralmente dá uma boa chave primária. Não existem dois IDs de produto iguais.

Em alguns casos, é aconselhável utilizar dois ou mais campos em conjunto para formar a chave primária de uma tabela. Por exemplo, a tabela Detalhes da Encomenda que armazena itens de linha para encomendas utilizaria duas colunas na respetiva chave primária: ID da Encomenda e ID do Produto. Quando uma chave primária utiliza mais do que uma coluna também é denominada chave composta.

Para a base de dados de vendas de produtos, pode criar uma coluna de Numeração Automática para cada uma das tabelas para utilizar como chave primária: IDDoProduto para a tabela Produtos, IDDaEncomenda para a tabela Encomendas, IDDoCliente para a tabela Cliente e IDDoFornecedor para a tabela Fornecedores.

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


Início da Página

Criar relações de tabelas

Agora que já dividiu as informações em tabelas, precisa de uma forma de reunir novamente as informações de forma relevante. Por exemplo, a forma seguinte inclui informações de várias tabelas.

O formulário Encomendas

1. As informações neste formulário derivam da tabela Clientes...

2. ... da tabela Colaboradores...

3. ... da tabela Encomendas...

4. ... da tabela Produtos...

5. ...e da tabela Detalhes da Encomenda.

O Access é um sistema de gestão de base de dados relacional. Numa base de dados relacional, divida as informações em tabelas separadas e baseadas em assuntos. Em seguida, utilize as relações de tabela para reunir as informações conforme necessário.

Início da Página

Criar uma relação um-para-muitos

Considere este exemplo: as tabelas Fornecedores e Produtos na base de dados de encomendas de produtos. Um fornecedor pode fornecer inúmeros produtos. Isto significa que para qualquer fornecedor representado na tabela Fornecedores, podem existir muitos produtos representados na tabela Produtos. A relação entre a tabela Fornecedores e a tabela Produtos é, portanto, 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 coluna ou colunas adicionais à tabela no lado "muitos" da relação. Neste caso, por exemplo, deverá adicionar a coluna ID do Fornecedor da tabela Fornecedores à tabela Produtos. O Access pode então utilizar o número ID do Cliente na tabela Encomendas para localizar o cliente correto para cada encomenda.

A coluna ID do Fornecedor na tabela Produtos é denominada chave externa. Uma chave externa é a chave primária de outra tabela. A coluna ID do Fornecedor na tabela Produtos é uma chave externa porque também é a chave primária na tabela Fornecedores.

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

Ao estabelecer pares de chaves primárias e chaves externas está a fornecer a base para associar tabelas relacionadas. Se não tiver certeza de quais as tabelas que devem partilhar uma coluna em comum, identificar uma relação um-para-muitos garante que as duas tabelas envolvidas exigem uma coluna partilhada.

Início da Página

Criar uma relação muitos-para-muitos

Repare na relação entre a tabela Produtos e a tabela Encomendas.

Uma única encomenda pode incluir mais do que um produto. Por outro lado, um único produto pode aparecer em muitas encomendas. Como tal, para cada registo na tabela Encomendas, pode haver vários registos na tabela Produtos. Além disso, para cada registo na tabela Produtos, pode haver vários registos na tabela Encomendas. Este tipo de relação chama-se uma relação muitos-para-muitos porque podem existir muitas encomendas para um produto e muitos produtos para uma encomenda. Tenha em atenção que, para detetar relações muitos-para-muitos entre 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. Tal representa um problema. Para compreender o problema, imagine o que aconteceria se tentasse criar a relação entre as duas tabelas, ao adicionar o campo ID do Produto à tabela Encomendas. Para ter mais do que um produto por encomenda, precisa de mais do que um registo por encomenda na tabela Encomendas. Estaria a repetir as informações da encomenda em cada linha relacionada com uma encomenda individual, o que resultaria numa estrutura ineficaz que podia gerar dados imprecisos. O mesmo problema ocorre se colocar o campo ID da Encomenda na tabela Produtos. Teria mais do que um registo para cada produto na tabela Produtos. Como pode resolver este problema?

A resposta é criar uma terceira tabela, geralmente denominada tabela de junção, que divide a relação muitos-para-muitos em duas relações um-para-muitos. Insira a chave primária de cada uma das tabelas na terceira tabela. Como resultado, a terceira tabela regista cada ocorrência ou instância 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 consiste em dois campos: as chaves externas das tabelas Encomendas e Produtos. Utilizar o campo ID da Encomenda individualmente não funciona como chave primária para esta tabela, visto que uma encomenda pode ter muitos itens de linha. O ID da Encomenda é repetido em todos os itens de linha numa encomenda, para que o campo não contenha valores exclusivos. Utilizar o campo ID do Produto individualmente também não funciona, visto que um produto pode aparecer em diversas encomendas. No entanto, os dois campos em conjunto produzem 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 relacionadas entre si diretamente. Na verdade, estão relacionadas indiretamente através da tabela Detalhes da Encomenda. A relação muitos-para-muitos entre as encomendas e os produtos é representada na base de dados por utilizar 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 pode ter mais do que um item de linha, mas cada item de linha está ligado a uma encomenda individual.

  • A tabela Produtos e a tabela Detalhes da Encomenda têm uma relação um-para-muitos. Um produto pode ter muitos itens de linha associados ao mesmo, mas um item de linha refere-se apenas a um produto.

A partir da tabela Detalhes da Encomenda, consegue determinar todos os produtos numa encomenda específica. Também consegue determinar todas as encomendas de um produto específico.

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

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


Início da Página

Criar uma relação um-para-um

Outro tipo de relação é a relação um-para-um. Por exemplo, suponhamos que precisa de registar algumas informações de produto complementares das quais raramente precisará ou que se aplicam apenas a alguns produtos. Uma vez que não precisa das informações regularmente, e porque armazenar as informações na tabela Produtos iria deixar espaços em branco para cada produto ao qual estas não se aplicassem, coloque-as numa tabela separada. Tal como a tabela Produtos, utilize o IDDoProduto como chave primária. A relação entre esta tabela complementar e a tabela Produtos é uma relação um-para-um. Para cada registo na tabela Produtos, existe um registo único correspondente na tabela complementar. Quando identifica uma relação deste tipo, ambas as tabelas têm de partilhar um campo em comum.

Quando detetar a necessidade de uma relação um-para-um na sua base de dados, pondere sobre o local onde pode colocar as informações das duas tabelas reunidas numa única tabela. Se, por algum motivo, não o quiser fazer (como por deixar muito espaço vazio), a lista seguinte mostra-lhe como poderia representar a relação na sua estrutura.

  • Se as duas tabelas tiverem o mesmo assunto, é possível configurar a relação ao utilizar a mesma chave primária em ambas as tabelas.

  • Se as duas tabelas tiverem assuntos diferentes com chaves primárias diferentes, escolha uma das tabelas e insira a respetiva chave primária como chave externa na outra tabela.

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

Início da Página

Aperfeiçoar a estrutura

Quando tiver as tabelas, campos e relações de que precisa, deve criar e preencher as suas tabelas com dados de exemplo e tentar trabalhar com as informações: criar consultas, adicionar novos registos etc. Isso ajuda a destacar possíveis problemas – por exemplo, poderá precisar de adicionar uma coluna que se esqueceu de inserir durante a fase de estruturação ou pode ter uma tabela que deve ser dividida em duas tabelas para remover duplicados.

Veja se consegue utilizar a base de dados para obter as respostas que pretende. Crie rascunhos dos seus formulários e relatórios e verifique se apresentam os dados esperados. Procure dados duplicados desnecessários e, se encontrar algum, altere a sua estrutura para o eliminar.

À medida que experimenta a sua base de dados inicial, poderá detetar pontos a melhorar. Eis alguns pontos a verificar:

  • Esqueceu-se de alguma coluna? Se for o caso, essas informações pertencem a alguma tabela existente? Se as informações forem sobre outro assunto, poderá ter de criar outra tabela. Crie uma coluna para cada item de informação que precisa de monitorizar. Se as informações não puderem ser calculadas a partir de outras colunas, é provável que precise de uma nova coluna para as informações.

  • Tem alguma coluna desnecessária porque não pode ser calculada a partir dos campos existentes? Se um item de informação puder ser calculado a partir de outras colunas existentes – por exemplo, um preço com desconto calculado a partir do preço de revenda – geralmente é melhor fazer isso e evitar criar uma nova coluna.

  • Está a introduzir repetidamente informações duplicadas numa das tabelas? Se for o caso, poderá ter de dividir a tabela em duas tabelas com uma relação um-para-muitos.

  • Tem tabelas com muitos campos, um número limitado de registos e muitos campos em branco em registos individuais? Se for o caso, reestruture a tabela de forma a ficar com menos campos e mais registos.

  • Dividiu cada item de informação em partes úteis mais pequenas? Se precisar de relatar, ordenar, procurar ou calcular um item de informação, coloque esse item na sua própria coluna.

  • Cada coluna contém um facto sobre o assunto da tabela? Se uma coluna não tiver informações sobre o assunto da tabela, pertence a uma tabela diferente.

  • As relações entre tabelas estão todas representadas, quer seja por campos comuns ou por uma terceira tabela. As relações um-para-um e um-para-muitos exigem colunas em comum. As relações muitos-para-muitos exigem uma terceira tabela.

Aperfeiçoar a tabela Produtos

Suponhamos que cada produto na base de dados de vendas de produtos é abrangida por uma categoria geral, como bebidas, condimentos ou marisco. A tabela Produtos pode incluir um campo que mostra a categoria de cada produto.

Suponhamos que após examinar e aperfeiçoar a estrutura da base de dados, decide guardar uma descrição da categoria juntamente com o nome. Se adicionar o campo Descrição da Categoria à tabela Produtos, será preciso repetir a descrição de cada categoria para cada produto abrangido pela categoria, o que não é uma boa solução.

Uma solução melhor é tornar as Categorias num novo assunto para a base de dados monitorizar com sua própria tabela e chave primária. Depois 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 do que um produto, mas um produto só pode pertencer a uma categoria.

Quando analisar as estruturas da sua tabela, verifique se existem grupos repetidos. Por exemplo, uma tabela com as seguintes colunas:

  • ID do Produto

  • Nome

  • ID do Produto1

  • Nome1

  • ID do Produto2

  • Nome2

  • ID do Produto3

  • Nome3

Aqui, cada produto é um grupo repetido de colunas que difere dos outros apenas ao adicionar um número no final do nome da coluna. Quando vir colunas numeradas desta forma, deve analisar novamente a sua estrutura.

Uma estrutura como esta tem demasiadas falhas. Para começar, força-o a colocar um limite máximo de número de produtos. Assim que exceder esse limite, tem de adicionar um novo grupo de colunas à estrutura da tabela, que é uma tarefa administrativa importante.

Outro problema é que esses fornecedores com menos do que o número máximo de produtos desperdiçarão algum espaço, uma vez que as colunas adicionais estarão em branco. A falha mais grave de uma estrutura desse tipo é que ela dificulta a execução de muitas tarefas, como ordenar ou indexar a tabela pelo nome ou ID do produto.

Sempre que vir grupos repetidos, analise bem a estrutura com o objetivo de dividir a tabela em duas. No exemplo acima, é melhor utilizar duas tabelas, uma para os fornecedores e outra para os produtos, ligadas pelo ID do Fornecedor.

Início da Página

Aplicar as regras de normalização

Pode aplicar as regras de normalização de dados (às vezes denominadas regras de normalização) como o passo seguinte na sua estruturação. Utilize estas regras para ver se as tabelas estão corretamente estruturadas. O processo de aplicação de regras à estrutura da sua base de dados é denominado normalizar a base de dados ou apenas normalização.

A normalização é mais útil depois de ter todos os itens de informação representados e de ter chegado a uma estrutura preliminar. A ideia é ajudar a garantir que dividiu os itens de informação nas tabelas adequadas. O que a normalização não permite fazer, é garantir que tem todos os itens de dados corretos para começar.

Aplique as regras em sequência, garantindo a cada passo que a sua estrutura resulta no que é conhecido como "formulários normais". Existem cinco formulários normais amplamente aceites – desde o primeiro formulário normal ao quinto. Este artigo descreve os primeiros três, pois são tudo o que é necessário para a maioria das estruturas de base de dados.

Primeiro formulário normal

O primeiro formulário normal indica 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 pode ter um campo com o nome Preço no qual coloca mais do que um Preço. Se imaginar cada interseção de linhas e colunas como uma célula, cada célula pode conter apenas um único valor.

Segundo formulário normal

O segundo formulário normal exige que cada coluna que não seja de chave esteja totalmente dependente da chave primária inteira, não apenas de uma parte da chave. Esta regra aplica-se quando tem uma chave primária que consiste em mais do que uma coluna. Por exemplo, suponhamos que tem uma tabela com as seguintes colunas, onde ID da Encomenda e ID do Produto formam a chave primária:

  • ID da Encomenda (chave primária)

  • ID do Produto (chave primária)

  • Nome do Produto

Esta estrutura não respeita o segundo formulário normal, porque o Nome do Produto depende do ID do Produto, mas não do ID da Encomenda, logo não é dependente da chave primária inteira. Tem de remover o Nome do Produto da tabela. O mesmo pertence a uma tabela diferente (Produtos).

Terceiro formulário normal

O terceiro formulário normal exige que todas as colunas que não sejam de chave sejam dependentes da chave primária inteira e que as colunas que não sejam de chave sejam independentes umas das outras.

Isto quer dizer que cada coluna que não seja de chave tem de ser dependente exclusivamente da chave primária. Por exemplo, suponhamos que tem uma tabela com as seguintes colunas:

  • IDDoProduto (chave primária)

  • Nome

  • PRS

  • Desconto

Suponhamos que o Desconto depende do preço de revenda sugerido (PRS) Esta tabela não respeita o terceiro formulário normal, uma vez que uma coluna que não é de chave (Desconto) depende de outra coluna que não é de chave (PRS). A independência da coluna significa que deve conseguir alterar qualquer coluna que não seja de chave sem afetar qualquer outra coluna. Se alterar um valor no campo PRS, o desconto seria alterado em conformidade, acabando por violar essa regra. Neste caso, o Desconto deve ser movido para outra tabela com uma chave no PRS.

Início da Página

Aumente os seus conhecimentos do Office
Explore as formações
Seja o primeiro a obter novas funcionalidades
Adira ao Office Insider

As informações foram úteis?

Obrigado pelos seus comentários!

Obrigado pelo seu feedback! Parece que poderá ser benéfico reencaminhá-lo para um dos nossos agentes de suporte do Office.

×