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.
Neste artigo
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.
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.
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.
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.
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.
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.
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 construir um protótipo de cada relatório ou listagem de saída e considerar os itens necessários para produzir o relatório. Por exemplo, quando examina uma letra de formulário, algumas coisas podem vir à mente. Se quiser incluir uma saudação adequada , por exemplo, a cadeia "Mr.", "Mrs." ou "Ms." que inicia uma saudação, terá de criar um item de saudação. Além disso, normalmente pode começar uma carta com "Caro Sr. Smith", em vez de "Querido. Sr. Sylvester Smith. Isto sugere que normalmente pretende armazenar o apelido separado do nome próprio.
Um ponto chave a ter em mente é que deve dividir cada informação nas partes mais pequenas úteis. No caso de um nome, para tornar o apelido prontamente disponível, irá dividir o nome em duas partes : Nome Próprio e Apelido. Para ordenar um relatório por apelido, por exemplo, ajuda ter o apelido do cliente armazenado separadamente. Em geral, se quiser ordenar, procurar, calcular ou reportar com base num item de informações, 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.
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:
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:
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.
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 refinar ainda mais as colunas. Por exemplo, faz sentido armazenar o nome do cliente como duas colunas separadas: nome próprio e apelido, para que possa ordenar, procurar e indexar apenas nessas colunas. Da mesma forma, o endereço consiste, na verdade, em cinco componentes separados, endereço, cidade, estado, código postal e país/região, e também faz sentido armazená-los em colunas separadas. Se quiser efetuar uma operação de pesquisa, filtragem ou ordenação por estado, por exemplo, precisa das informações de estado armazenadas 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 ter um único campo para nomes completos ou nomes de produtos, juntamente com descrições de produtos. Se combinar mais do que um tipo de informação num campo, é difícil obter factos individuais mais tarde. Tente dividir as informações em partes lógicas; por exemplo, crie campos separados para o nome próprio e apelido ou para o nome do produto, categoria e descrição.
Depois de aperfeiçoar as colunas de dados em cada tabela, está pronto para escolher a chave primária de cada tabela.
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.
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.
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.
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.
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.
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.
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.
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. Isto apresenta 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 na tabela Encomendas por encomenda. Repetiria as informações de ordem para cada linha relacionada com uma única ordem, o que resulta num design ineficiente que pode levar a dados imprecisos. Se colocar o campo ID da Encomenda na tabela Produtos, terá mais do que um registo na tabela Produtos para cada produto. Como 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.
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:
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.
Aperfeiçoar a estrutura
Assim que 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. Esta ação ajuda a realçar potenciais problemas — por exemplo, poderá ter de adicionar uma coluna que se esqueceu de inserir durante a fase de conceção ou pode ter uma tabela que deve dividir em duas tabelas para remover a duplicação.
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.
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
Suponha que o Desconto depende do preço de venda a retalho sugerido (SRP). Esta tabela viola o terceiro formulário normal porque uma coluna não chave, Discount, depende de outra coluna não chave, SRP. A independência da coluna significa que deve ser capaz de alterar qualquer coluna não chave sem afetar qualquer outra coluna. Se alterar um valor no campo SRP, o Desconto mudará em conformidade, violando assim essa regra. Neste caso, o Desconto deve ser movido para outra tabela com chave no SRP.
