Um banco de dados adequadamente projetado fornece acesso a informações atualizadas e precisas. Como um design correto é essencial para atingir seus objetivos ao trabalhar com um banco de dados, investir o tempo necessário para aprender os princípios de um bom design faz sentido. No final, é muito mais provável que você acabe com um banco de dados que atenda às suas necessidades e possa acomodar facilmente as alterações.
Este artigo fornece diretrizes para o planejamento de um banco de dados da área de trabalho. Você aprenderá a decidir quais informações precisa, como dividir essas informações em tabelas e colunas apropriadas e como essas tabelas se relacionam entre si. Você deve ler este artigo antes de criar seu primeiro banco de dados de área de trabalho.
Neste artigo
- Alguns termos de banco de dados que você precisa saber
- O que é um bom design de banco de dados?
- O processo de design
- Determinando a finalidade do seu banco de dados
- Localizando e organizando as informações necessárias
- Dividindo as informações em tabelas
- Transformando itens de informação em colunas
- Especificando chaves primárias
- Criar relações de tabela
- Refinando o design
- Aplicando as regras de normalização
Alguns termos de banco de dados que você precisa saber
O Access organiza suas informações em tabelas: listas de linhas e colunas que lembram o bloco de um contador ou uma planilha. Em um banco de dados simples, você pode ter apenas uma tabela. Para a maioria dos bancos de dados, você precisará de mais de um. Por exemplo, você pode ter uma tabela que armazena informações sobre produtos, outra tabela que armazena informações sobre pedidos e outra tabela com informações sobre clientes.
Cada linha é mais corretamente chamada de registro, e cada coluna, de campo. Um registro é uma maneira significativa e consistente de combinar informações sobre algo. Um campo é um único item de informação — um tipo de item que aparece em todos os registros. Na tabela Produtos, por exemplo, cada linha ou registro teria as informações sobre um produto. Cada coluna ou campo contém algum tipo de informação sobre o produto, por exemplo, nome ou preço.
O que é um bom design de banco de dados?
Certos princípios orientam o processo de design do banco de dados. O primeiro princípio é que informações duplicadas (também chamadas de dados redundantes) são ruins, pois desperdiçam espaço 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 o banco de dados contiver informações incorretas, todos os relatórios que extraem informações do banco de dados também conterão informações incorretas. Como resultado, quaisquer decisões que você tomar com base nesses relatórios serão mal informadas.
Um bom design de banco de dados é, portanto, aquele que:
- Divide suas informações em tabelas baseadas em assunto para reduzir dados redundantes.
- Fornece ao Access as informações necessárias para unir as informações nas tabelas conforme necessário.
- Ajuda a oferecer suporte e garantir a precisão e a integridade de suas informações.
- Acomoda suas necessidades de processamento e geração de relatórios de dados.
O processo de design
O processo de design consiste nas seguintes etapas:
-
Determinar a finalidade do seu banco de dados
Isso ajuda a prepará-lo para as etapas restantes. -
Localizar e organizar as informações necessárias
Reúna todos os tipos de informações que você talvez queira registrar no banco de dados, como nome do produto e número do pedido. -
Dividir as informações em tabelas
Divida seus itens de informação em entidades ou assuntos principais, como Produtos ou Pedidos. Cada assunto então se torna uma tabela. -
Transformar itens de informação em colunas
Decida quais informações você deseja armazenar em cada tabela. Cada item se torna um campo e é exibido como uma coluna na tabela. Por exemplo, uma tabela Funcionários pode incluir campos como Sobrenome e Data de Contratação. -
Especificar chaves primárias
Escolha a chave primária de cada tabela. A chave primária é uma coluna usada para identificar exclusivamente cada linha. Um exemplo pode ser ID do Produto ou ID do Pedido. -
Configurar as relações da tabela
Examine cada tabela e decida como os dados de uma tabela estão relacionados aos dados de outras tabelas. Adicione campos a tabelas ou crie novas tabelas para esclarecer as relações, conforme necessário. -
Refine seu design
Analise seu design em busca de erros. Crie as tabelas e adicione alguns registros de dados de exemplo. Veja se você consegue obter os resultados desejados de suas tabelas. Faça ajustes no design, conforme necessário. -
Aplicar as regras de normalização
Aplique as regras de normalização de dados para ver se as tabelas estão estruturadas corretamente. Faça ajustes nas tabelas, conforme necessário.
Determinando a finalidade do seu banco de dados
É uma boa ideia anotar o propósito do banco de dados no papel - seu propósito, como você espera usá-lo e quem o usará. Para um pequeno banco de dados para uma empresa doméstica, por exemplo, você pode escrever algo simples como "O banco de dados do cliente mantém uma lista de informações do cliente com a finalidade de produzir correspondências e relatórios". Se o banco de dados for mais complexo ou for usado por muitas pessoas, como geralmente ocorre em um ambiente corporativo, a finalidade pode facilmente ser um parágrafo ou mais e deve incluir quando e como cada pessoa usará o banco de dados. A ideia é ter uma declaração de missão bem desenvolvida que possa ser consultada durante todo o processo de design. Ter essa declaração ajuda você a se concentrar em seus objetivos ao tomar decisões.
Localizando e organizando as informações necessárias
Para localizar e organizar as informações necessárias, comece com as informações existentes. Por exemplo, você pode registrar ordens de compra em um razão ou manter as informações do cliente em formulários de papel em um armário de arquivos. Reúna esses documentos e liste cada tipo de informação mostrada (por exemplo, cada caixa que você preenche em um formulário). Se você não tem nenhum formulário existente, imagine que precisa criar um formulário para registrar as informações do cliente. Que informações você colocaria no formulário? Que caixas de preenchimento você criaria? Identifique e liste cada um desses itens. Por exemplo, suponha que você mantenha atualmente a lista de clientes em cartões de índice. O exame desses cartões pode mostrar que cada card contém o nome, endereço, cidade, estado, código postal e número de telefone de um cliente. Cada um desses itens representa uma coluna potencial em uma tabela.
Ao preparar esta lista, não se preocupe em deixá-la perfeita no início. Em vez disso, faça uma lista de cada item que vier à mente. Se outra pessoa for usar o banco de dados, peça suas ideias também. Você poderá ajustar a lista posteriormente.
Em seguida, considere os tipos de relatórios ou correspondências que você pode querer produzir a partir do banco de dados. Por exemplo, talvez você queira um relatório de vendas de produtos para mostrar as vendas por região ou um relatório de resumo de estoque que mostre os níveis de estoque de produtos. Você também pode gerar cartas modelo para enviar aos clientes que anunciam um evento de venda ou oferecem um prêmio. Crie o relatório em sua mente e imagine como ele seria. Que informações você colocaria no relatório? Liste cada item. Faça o mesmo com a carta modelo e para qualquer outro relatório que você pretenda criar.
Pensar nos relatórios e correspondências que você pode querer criar ajuda a identificar os itens que você precisará em seu banco de dados. Por exemplo, suponha que você dê aos clientes a oportunidade de aceitar (ou não) atualizações periódicas de email e queira imprimir uma lista daqueles que aceitaram. Para registrar essas informações, adicione uma coluna "Enviar email" à tabela cliente. Para cada cliente, você pode definir o campo como Sim ou Não.
A exigência de enviar mensagens de email aos clientes sugere outro item a ser registrado. Depois de saber que um cliente deseja receber mensagens de email, você também precisará saber o endereço de email para o qual enviá-las. Portanto, você precisa registrar um endereço de email para cada cliente.
Faz sentido construir um protótipo de cada relatório ou listagem de saída e considerar quais itens você precisará para produzir o relatório. Por exemplo, quando você examina uma carta modelo, algumas coisas podem vir à mente. Se desejar incluir uma saudação adequada — por exemplo, a cadeia de caracteres "Sr.", "Sra." ou "Sra." que inicia uma saudação, você terá que criar um item de saudação. Além disso, você normalmente pode começar uma carta com "Prezado Sr. Smith", em vez de "Prezado. Sr. Sylvester Smith". Isso sugere que normalmente você deseja armazenar o sobrenome separado do nome.
Um ponto importante a ser lembrado é que você deve dividir cada informação em suas menores partes úteis. No caso de um nome, para tornar o sobrenome prontamente disponível, você dividirá o nome em duas partes - Nome e Sobrenome. Para classificar um relatório por sobrenome, por exemplo, é útil ter o sobrenome do cliente armazenado separadamente. Em geral, se você quiser classificar, pesquisar, calcular ou relatar com base em um item de informação, você deve colocar esse item em seu próprio campo.
Pense nas perguntas que você pode querer que o banco de dados responda. Por exemplo, quantas vendas do seu produto em destaque você fechou no mês passado? Onde moram seus melhores clientes ? Quem é o fornecedor do seu produto mais vendido? Antecipar essas perguntas ajuda a se concentrar em itens adicionais a serem registrados.
Depois de coletar essas informações, você estará pronto para a próxima etapa.
Dividindo as informações em tabelas
Para dividir as informações em tabelas, escolha as entidades principais ou assuntos. Por exemplo, depois de encontrar e organizar as informações de um banco de dados de vendas de produtos, a lista preliminar pode ter esta aparência:
As principais entidades mostradas aqui são os produtos, os fornecedores, os clientes e os pedidos. Portanto, faz sentido começar com essas quatro tabelas: uma para fatos sobre produtos, uma para fatos sobre fornecedores, uma para fatos sobre clientes e outra para fatos sobre pedidos. Embora isso não complete a lista, é um bom ponto de partida. Você pode continuar a refinar essa lista até ter um design que funcione bem.
Ao examinar pela primeira vez a lista preliminar de itens, você pode ficar tentado a colocá-los todos em uma única tabela, em vez das quatro mostradas na ilustração anterior. Você aprenderá aqui por que isso é uma má ideia. Considere por um momento, a tabela mostrada aqui:
Nesse caso, cada linha contém informações sobre o produto e seu fornecedor. Como você pode ter muitos produtos do mesmo fornecedor, as informações de nome e endereço do fornecedor devem ser repetidas muitas vezes. Isso desperdiça espaço em disco. Registrar as informações do fornecedor apenas uma vez em uma tabela separada de Fornecedores e, em seguida, vincular essa tabela à tabela Produtos é uma solução muito melhor.
Um segundo problema com esse design surge quando você precisa modificar informações sobre o fornecedor. Por exemplo, vamos supor que você precise alterar o endereço de um fornecedor. Como ele aparece em vários lugares, talvez você acidentalmente altere o endereço em um só lugar, mas esqueça de alterá-lo em outros. Registrar o endereço do fornecedor em um só lugar resolve o problema.
Ao projetar seu banco de dados, sempre tente registrar cada fato apenas uma vez. Se você estiver repetindo as mesmas informações em mais de um lugar, como o endereço de um fornecedor específico, coloque essas informações em uma tabela separada.
Por fim, suponha que haja apenas um produto fornecido pela Coho Winery e você queira excluir o produto, mas mantenha as informações de nome e endereço do fornecedor. Como você excluiria o registro do produto sem perder também as informações do fornecedor? Isso não é possível. Como cada registro contém fatos sobre um produto, bem como fatos sobre um fornecedor, você não pode excluir um sem excluir o outro. Para manter esses fatos separados, você deve dividir uma tabela em duas: uma tabela para informações do produto e outra tabela para informações do fornecedor. A exclusão de um registro de produto deve excluir apenas os fatos sobre o produto, não os fatos sobre o fornecedor.
Depois de escolher o assunto representado por uma tabela, as colunas nessa tabela devem armazenar fatos apenas sobre o assunto. Por exemplo, a tabela de produtos deve armazenar fatos apenas sobre produtos. Como o endereço do fornecedor é um fato sobre o fornecedor, e não um fato sobre o produto, ele pertence à tabela de fornecedores.
Transformando itens de informação em colunas
Para determinar as colunas em uma tabela, decida quais informações você precisa acompanhar sobre o assunto registrado na tabela. Por exemplo, para a tabela Clientes, Nome, Endereço, Cidade-Estado-CEP, Enviar email, Saudação e Endereço de email compõem uma boa lista inicial de colunas. Cada registro na tabela contém o mesmo conjunto de colunas, para que você possa armazenar informações de Nome, Endereço, Cidade-Estado-CEP, Enviar email, Saudação e Endereço de email para cada registro. Por exemplo, a coluna de endereço contém os endereços dos clientes. Cada registro contém dados sobre um cliente e o campo de endereço contém o endereço desse cliente.
Depois de determinar o conjunto inicial de colunas para cada tabela, você poderá refinar ainda mais as colunas. Por exemplo, faz sentido armazenar o nome do cliente como duas colunas separadas: nome e sobrenome, para que você possa classificar, pesquisar e indexar apenas nessas colunas. Da mesma forma, o endereço na verdade consiste em cinco componentes separados, endereço, cidade, estado, CEP e país/região, e também faz sentido armazená-los em colunas separadas. Se quiser executar uma operação de pesquisa, filtro ou classificação por estado, por exemplo, você precisará das informações de estado armazenadas em uma coluna separada.
Você também deve considerar se o banco de dados conterá informações apenas de origem doméstica ou internacional. Por exemplo, se você planeja armazenar endereços internacionais, é melhor ter uma coluna Região em vez de Estado, porque essa coluna pode acomodar estados domésticos e regiões de outros países/regiões. Da mesma forma, o código postal faz mais sentido do que o código postal se você for armazenar endereços internacionais.
A lista a seguir mostra algumas dicas para determinar suas colunas.
-
Não incluir dados calculados
Na maioria dos casos, você não deve armazenar o resultado dos cálculos em tabelas. Em vez disso, você pode fazer com que o Access faça os cálculos quando você quiser ver o resultado. Por exemplo, suponha que haja um relatório de Produtos no Pedido que exiba o subtotal de unidades no pedido para cada categoria de produto no banco de dados. No entanto, não há nenhuma coluna de subtotal Unidades no Pedido em nenhuma tabela. Em vez disso, a tabela Produtos inclui uma coluna Unidades no Pedido que armazena as unidades no pedido de cada produto. Usando esses dados, o Access calcula o subtotal sempre que você imprime o relatório. O subtotal em si não deve ser armazenado em uma tabela. -
Armazenar informações em suas menores partes lógicas
Você pode ficar tentado a ter um único campo para nomes completos ou nomes de produtos junto com descrições de produtos. Se você combinar mais de um tipo de informação em um campo, será difícil recuperar fatos individuais posteriormente. Tente dividir as informações em partes lógicas; Por exemplo, crie campos separados para nome e sobrenome ou para nome, categoria e descrição do produto.
Depois de refinar as colunas de dados em cada tabela, você estará pronto para escolher a chave primária de cada tabela.
Especificando chaves primárias
Cada tabela deve incluir uma coluna ou um conjunto de colunas que identifique com exclusividade cada linha armazenada na tabela. Geralmente, é um número de identificação exclusivo, como um número de ID de funcionário ou um número de série. Na terminologia de banco de dados, essas informações são chamadas de chave primária da tabela. O Access usa os campos de chaves primárias para associar rapidamente os dados de várias tabelas e reunir os dados para você.
Se você já tiver um identificador exclusivo para uma tabela, como um número de produto que identifica exclusivamente cada produto em seu catálogo, poderá usar esse identificador como a chave primária da tabela — mas somente se os valores nessa coluna forem sempre diferentes para cada registro. Você não pode ter valores duplicados em uma chave primária. Por exemplo, não use nomes de pessoas como chave primária, pois os nomes não são exclusivos. Você poderia facilmente ter duas pessoas com o mesmo nome na mesma tabela.
Uma chave primária sempre deve ter um valor. Se o valor de uma coluna puder se tornar não atribuído ou desconhecido (um valor ausente) em algum momento, ele não poderá ser usado como um componente em uma chave primária.
Você deve sempre escolher uma chave primária cujo valor não será alterado. Em um banco de dados que usa mais de uma tabela, a chave primária de uma tabela pode ser usada como referência em outras tabelas. Se a chave primária for alterada, a alteração também deverá ser aplicada em todos os lugares em que a chave for referenciada. Usar uma chave primária que não será alterada reduz a chance de que a chave primária fique fora de sincronia com outras tabelas que façam referência a ela.
Muitas vezes, um número exclusivo arbitrário é usado como chave primária. Por exemplo, você pode atribuir a cada pedido um número de pedido exclusivo. A única finalidade do número do pedido é identificar um pedido. Depois de atribuído, ele nunca é alterado.
Se você não tem em mente uma coluna ou um conjunto de colunas que pode ser uma boa chave primária, considere usar uma coluna que tenha o tipo de dados Numeração Automática. Quando você usa o tipo de dados Numeração Automática, o Access atribui automaticamente um valor para você. Tal identificador não tem fatos; Ele não contém nenhuma informação factual que descreva a linha que representa. Os identificadores sem fatos são ideais para uso como uma chave primária porque não mudam. Uma chave primária que contém fatos sobre uma linha — um número de telefone ou um nome de cliente, por exemplo — tem mais probabilidade de ser alterada, pois as próprias informações factuais podem mudar.
1. Uma coluna definida com o tipo de dados Numeração Automática geralmente constitui uma boa chave primária. Não há duas IDs de produto iguais.
Em alguns casos, você pode querer usar dois ou mais campos que, juntos, fornecem a chave primária de uma tabela. Por exemplo, uma tabela de Detalhes do Pedido que armazena itens da linha para pedidos usaria duas colunas na chave primária: ID do pedido e ID do produto. Quando uma chave primária emprega mais de uma coluna, ela também é chamada de chave composta.
Para o banco de dados de vendas de produtos, você pode criar uma coluna de Numeração Automática para cada uma das tabelas para servir como chave primária: IDProduto para a tabela Produtos, IDPedido para a tabela Pedidos, IDCliente para a tabela Clientes e IDFornecedor para a tabela Fornecedores.
Criar relações de tabela
Agora que você dividiu suas informações em tabelas, precisa de uma maneira de reunir as informações novamente de maneiras significativas. Por exemplo, o formulário a seguir inclui informações de várias tabelas.
1. As informações neste formulário são provenientes da tabela Clientes...
2. ... a tabela Funcionários...
3. ... a tabela Pedidos...
4. ... a tabela de Produtos...
5. ... e a tabela Detalhes do Pedido.
O Access é um sistema de gerenciamento de bancos de dados relacionais. Em um banco de dados relacional, você divide as informações em tabelas separadas baseadas em assunto. Em seguida, use as relações de tabela para reunir as informações conforme necessário.
Criando uma relação um-para-muitos
Considere este exemplo: as tabelas Fornecedores e Produtos no banco de dados de pedidos de produtos. Um fornecedor pode fornecer qualquer número de produtos. Assim, para qualquer fornecedor representado na tabela Fornecedores, pode haver muitos produtos representados na tabela Produtos. A relação entre a tabela Fornecedores e a tabela Produtos é, portanto, uma relação de um para muitos.
Para representar uma relação de um para muitos no design de banco de dados, use a chave primária no lado "um" da relação e adicione-a como uma coluna ou colunas adicionais à tabela no lado "muitos" da relação. Nesse caso, por exemplo, você adiciona a coluna ID do Fornecedor da tabela Fornecedores à tabela Produtos. O Access pode então usar o número de ID do fornecedor na tabela Produtos para localizar o fornecedor correto para cada produto.
A coluna ID do Fornecedor na tabela Produtos é chamada de chave estrangeira. Uma chave estrangeira é a chave primária de outra tabela. A coluna ID do Fornecedor na tabela Produtos é uma chave estrangeira porque também é a chave primária na tabela Fornecedores.
Você fornece a base para unir tabelas relacionadas estabelecendo emparelhamentos de chaves primárias e chaves estrangeiras. Se você não tiver certeza de quais tabelas devem compartilhar uma coluna comum, identificar uma relação de um para muitos garante que as duas tabelas envolvidas realmente exigirão uma coluna compartilhada.
Criando uma relação de muitos para muitos
Considere a relação entre a tabela Produtos e a tabela Pedidos.
Um único pedido pode incluir mais de um produto. Por outro lado, um único produto pode constar em vários pedidos. Assim, para todos os registros da tabela Pedidos, pode haver vários registros na tabela Produtos. E para cada registro na tabela Produtos, pode haver muitos registros na tabela Pedidos. Esse tipo de relacionamento é chamado de relacionamento muitos para muitos porque, para qualquer produto, pode haver muitos pedidos; E para qualquer pedido, pode haver muitos produtos. Observe que, para detectar relações de muitos para muitos entre as tabelas, é importante considerar os dois lados da relação.
Os assuntos das duas tabelas — pedidos e produtos — têm uma relação de muitos para muitos. Isso representa um problema. Para entender o problema, imagine o que aconteceria se você tentasse criar a relação entre as duas tabelas adicionando o campo ID do Produto à tabela Pedidos. Para ter mais de um produto por pedido, você precisa de mais de um registro na tabela Pedidos por pedido. Você estaria repetindo as informações da ordem para cada linha relacionada a uma única ordem, resultando em um design ineficiente que poderia levar a dados imprecisos. Você terá o mesmo problema se colocar o campo ID do Pedido na tabela Produtos — você terá mais de um registro na tabela Produtos para cada produto. Como você resolve esse problema?
A resposta é criar uma terceira tabela, geralmente chamada de tabela de junção, que divide a relação de muitos para muitos em duas relações de um para muitos. Insira a chave primária de cada uma das duas tabelas na terceira tabela. Como resultado, a terceira tabela registra cada ocorrência ou instância da relação.
Cada registro na tabela Detalhes do Pedido representa um item de linha em um pedido. A chave primária da tabela Detalhes do Pedido consiste em dois campos — as chaves estrangeiras das tabelas Pedidos e Produtos. O uso do campo ID do pedido sozinho não funciona como a chave primária dessa tabela, pois um pedido pode ter vários itens de linha. O ID do pedido é repetido para cada item de linha em um pedido, para que o campo não contenha valores exclusivos. Usar apenas o campo ID do Produto também não funciona, pois um produto pode aparecer em muitos pedidos diferentes. Juntos, os dois campos sempre produzem um valor exclusivo para cada registro.
No banco de dados de vendas de produtos, a tabela Pedidos e a tabela Produtos não estão relacionadas entre si diretamente. Em vez disso, elas são relacionadas indiretamente por meio da tabela Detalhes do Pedido. A relação de muitos para muitos entre pedidos e produtos é representada no banco de dados usando duas relações de um para muitos:
- As tabelas Pedidos e Detalhes do Pedido têm uma relação de um para muitos. Cada pedido pode ter mais de um item de linha, mas cada item de linha está conectado a apenas um pedido.
- A tabela Produtos e a tabela Detalhes do Pedido têm uma relação de um para muitos. Cada produto pode ter muitos itens de linha associados a ele, mas cada item de linha se refere a apenas um produto.
Na tabela Detalhes do Pedido, você pode determinar todos os produtos em um pedido específico. Você também pode determinar todos os pedidos de um determinado produto.
Depois de incorporar a tabela Detalhes do Pedido, a lista de tabelas e campos pode ser algo assim:
Criando um relacionamento de um-para-um
Outro tipo de relacionamento é o relacionamento um-para-um. Por exemplo, suponha que você precise registrar algumas informações suplementares especiais sobre o produto que raramente serão necessárias ou que se apliquem apenas a alguns produtos. Como você não precisa das informações com frequência e como armazenar as informações na tabela Produtos resultaria em espaço vazio para cada produto ao qual elas não se aplicam, coloque-as em uma tabela separada. Assim como na tabela Produtos, você usa ProductID como a chave primária. A relação entre essa tabela suplementar e a tabela Produto é uma relação um para um. Para cada registro na tabela Produto, existe um único registro correspondente na tabela complementar. Quando você identifica esse tipo de relação, ambas as tabelas devem compartilhar um campo em comum.
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
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 aspetos a marcar:
- 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).
Terceira forma 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
- SRP
- 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 será alterado em conformidade, violando assim essa regra. Neste caso, o Desconto deve ser movido para outra tabela com uma chave no PRS.