Princípios básicos do design de banco de dados

Um banco de dados projetado corretamente fornece acesso a informações atualizadas e precisas. Como um design correto é essencial para alcançar suas metas em trabalhar com um banco de dados, investir o tempo necessário para aprender os princípios do 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 planejar um banco de dados de área de trabalho. Você aprenderá a decidir quais informações você precisa, como dividir essas informações nas 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 da área de trabalho.

Neste artigo

• Alguns termos de banco de dados para saber
• O que é um bom design de banco de dados?
• O processo de design
• Determinando a finalidade do banco de dados
• Localizar e organizar as informações necessárias
• Dividindo as informações em tabelas
• Transformando itens de informação em colunas
• Especificando chaves primárias
• Criando as relações de tabela
• Refinando o design
• Aplicando as regras de normalização

Alguns termos de banco de dados para 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, um campo. Um registro é uma maneira significativa e consistente de combinar informações sobre algo. Um campo é um único item de informações – um tipo de item que aparece em cada registro. 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.

Início da Página

O que é um bom design de banco de dados?

Determinados princípios orientam o processo de design do banco de dados. O primeiro princípio é que as 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 correçã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, todas as decisões que você tomar com base nesses relatórios serão entã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 o Access com as informações necessárias para unir as informações nas tabelas, conforme necessário.
• Ajuda a dar suporte e garantir a precisão e integridade de suas informações.
• Acomoda suas necessidades de processamento de dados e relatórios.

Início da Página

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 talvez você 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ções em entidades ou entidades principais, como Produtos ou Pedidos. Cada assunto então se torna uma tabela.
• Transformar itens de informações 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 de tabela
  Olhe para cada tabela e decida como os dados em uma tabela estão relacionados aos dados em outras tabelas. Adicione campos a tabelas ou crie novas tabelas para esclarecer as relações, conforme necessário.
• Refinar seu design
  Analise seu design em busca de erros. Crie as tabelas e adicione alguns registros de dados de exemplo. Confira se você pode obter os resultados desejados em 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.

Início da Página

Determinando a finalidade do banco de dados

É uma boa ideia anotar a finalidade do banco de dados no papel – sua finalidade, como você espera usá-lo e quem o usará. Para um pequeno banco de dados para uma empresa baseada em casa, 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 emails e relatórios". Se o banco de dados for mais complexo ou for usado por muitas pessoas, como ocorre frequentemente em uma configuração corporativa, a finalidade poderá ser facilmente um parágrafo ou mais e deve incluir quando e como cada pessoa usará o banco de dados. A ideia é ter uma instrução de missão bem desenvolvida que possa ser encaminhada durante todo o processo de design. Ter essa instrução ajuda você a se concentrar em seus objetivos ao tomar 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 com suas informações existentes. Por exemplo, você pode registrar pedidos de compra em um razão ou manter 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 tiver formulários existentes, imagine que você precisa criar um formulário para registrar as informações do cliente. Quais informações você colocaria no formulário? Que caixas de preenchimento você criaria? Identifique e liste cada um desses itens. Por exemplo, suponha que atualmente você mantenha a lista de clientes em cartões de índice. Examinar esses cartões pode mostrar que cada card contém um nome, endereço, cidade, estado, código postal e número de telefone dos clientes. Cada um desses itens representa uma coluna potencial em uma tabela.

Ao preparar esta lista, não se preocupe em aperfeiçoá-la no início. Em vez disso, liste cada item que vem à mente. Se outra pessoa usar o banco de dados, peça suas ideias também. Você pode ajustar a lista mais tarde.

Em seguida, considere os tipos de relatórios ou emails que talvez você queira produzir do banco de dados. Por exemplo, você pode querer que um relatório de vendas de produtos mostre vendas por região ou um relatório de resumo de inventário que mostre os níveis de inventário do produto. Você também pode querer gerar cartas de formulário 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. Quais informações você colocaria no relatório? Liste cada item. Faça o mesmo para a letra do formulário e para qualquer outro relatório que você preveja criar.

Pensar nos relatórios e emails que talvez você queira criar ajuda a identificar itens necessários em seu banco de dados. Por exemplo, suponha que você dê aos clientes a oportunidade de optar por atualizações de email periódicas (ou fora) e deseja imprimir uma listagem daqueles que optaram por entrar. Para registrar essas informações, você adiciona uma coluna "Enviar email" à tabela do cliente. Para cada cliente, você pode definir o campo como Sim ou Não.

O requisito para 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 gravar 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 de formulário, algumas coisas podem vir à mente. Se você quiser incluir uma saudação adequada – por exemplo, a cadeia de caracteres "Mr.", "Mrs." ou "Ms" 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 "Caro Sr. Smith", em vez de "Querido. Sr. Sylvester Smith". Isso sugere que você normalmente deseja armazenar o sobrenome separado do primeiro nome.

Um ponto chave a ser lembrado é que você deve dividir cada informação em suas menores partes úteis. No caso de um nome, para disponibilizar o sobrenome prontamente, você dividirá o nome em duas partes : Nome e Sobrenome. Para classificar um relatório pelo sobrenome, por exemplo, ele ajuda a ter o sobrenome do cliente armazenado separadamente. Em geral, se você quiser classificar, pesquisar, calcular ou relatar com base em um item de informações, você deverá colocar esse item em seu próprio campo.

Pense nas perguntas que talvez você queira 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? A antecipação dessas perguntas ajuda você a zero em itens adicionais a serem registrados.

Depois de coletar essas informações, você está pronto para a próxima etapa.

Início da Página

Dividindo as informações em tabelas

Para dividir as informações em tabelas, escolha as entidades principais ou as entidades. Por exemplo, depois de encontrar e organizar informações para um banco de dados de vendas de produtos, a lista preliminar pode ser semelhante a esta:

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 conclua 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ê poderá ser tentado a colocá-los todos em uma única tabela, em vez dos quatro mostrados na ilustração anterior. Você aprenderá aqui por que isso é uma má idéia. 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, o nome do fornecedor e as informações de endereço devem ser repetidos muitas vezes. Isso desperdiça espaço em disco. Registrar as informações do fornecedor apenas uma vez em uma tabela fornecedores separada e, em seguida, vincular essa tabela à tabela Produtos, é uma solução muito melhor.

Um segundo problema com esse design ocorre quando você precisa modificar informações sobre o fornecedor. Por exemplo, suponha 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. Gravar o endereço do fornecedor em apenas um local resolve o problema.

Ao projetar seu banco de dados, sempre tente registrar cada fato apenas uma vez. Se você se encontrar 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 Vinícola Coho e você queira excluir o produto, mas mantenha o nome do fornecedor e as informações de endereço. 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 de 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 do produto 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.

Início da Página

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-Zip, Enviar email, Saudação e endereço de email incluem uma boa lista inicial de colunas. Cada registro na tabela contém o mesmo conjunto de colunas, para que você possa armazenar Nome, Endereço, Cidade-Estado-Zip, Enviar e-mail, Saudação e informações de endereço de email para cada registro. Por exemplo, a coluna de endereços 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 consiste 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 você quiser executar uma pesquisa, filtrar ou classificar operação por estado, por exemplo, precisará das informações de estado armazenadas em uma coluna separada.

Você também deve considerar se o banco de dados conterá informações de origem doméstica ou internacionais também. Por exemplo, se você planeja armazenar endereços internacionais, é melhor ter uma coluna Region em vez de Estado, pois 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 CEP se você vai armazenar endereços internacionais.

A lista a seguir mostra algumas dicas para determinar suas colunas.

• Não inclua dados calculados
  Na maioria dos casos, você não deve armazenar o resultado de cálculos em tabelas. Em vez disso, você pode fazer com que o Access execute os cálculos quando quiser ver o resultado. Por exemplo, suponha que haja um relatório Products On Order que exibe o subtotal de unidades em ordem para cada categoria de produto no banco de dados. No entanto, não há nenhuma coluna subtotal Units On Order em qualquer tabela. Em vez disso, a tabela Produtos inclui uma coluna Units On Order que armazena as unidades em ordem para 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 ser tentado a ter um único campo para nomes completos ou para nomes de produtos, juntamente com as descrições do produto. Se você combinar mais de um tipo de informação em um campo, é difícil recuperar fatos individuais mais tarde. Tente dividir informações em partes lógicas; por exemplo, crie campos separados para nome e sobrenome ou para nome do produto, categoria e descrição.

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

Início da Página

Especificando chaves primárias

Cada tabela deve incluir uma coluna ou um conjunto de colunas que identifica exclusivamente cada linha armazenada na tabela. Geralmente, esse é um número de identificação exclusivo, como um número de ID do funcionário ou um número de série. Na terminologia do banco de dados, essas informações são chamadas de chave primária da tabela. O Access usa campos-chave primários para associar rapidamente 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 nesta coluna sempre forem diferentes para cada registro. Você não pode ter valores duplicados em uma chave primária. Por exemplo, não use os nomes das pessoas como uma chave primária, porque os nomes não são exclusivos. Você poderia facilmente ter duas pessoas com o mesmo nome na mesma tabela.

Uma chave primária deve sempre ter um valor. Se o valor de uma coluna pode ficar sem sinal ou desconhecido (um valor ausente) em algum momento, ele não poderá ser usado como um componente em uma chave primária.

Você sempre deve escolher uma chave primária cujo valor não será alterado. Numa base de dados que utiliza 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 for alterada, a alteração também tem de ser aplicada em todos os locais onde a chave é referenciada. A utilização de uma chave primária que não será alterada reduz a probabilidade de a chave primária ficar dessincronizada com outras tabelas que a referenciam.

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

Se não tiver em mente uma coluna ou conjunto de colunas que possam criar uma boa chave primária, considere utilizar uma coluna que tenha o tipo de dados Numeração Automática. Quando utiliza o tipo de dados Numeração Automática, o Access atribui automaticamente um valor por si. Tal identificador não tem factos; não contém informações factuais que descrevam a linha que representa. Os identificadores sem factos são ideais para serem utilizados como chave primária porque não mudam. Uma chave primária que contém factos sobre uma linha ( um número de telefone ou um nome de cliente, por exemplo) é mais provável que mude, porque as informações factuais em si podem mudar.

1. Muitas vezes, uma coluna definida para o tipo de dados Numeração Automática constitui uma boa chave primária. Não existem dois IDs de produto iguais.

Em alguns casos, poderá querer utilizar dois ou mais campos que, em conjunto, fornecem a chave primária de uma tabela. Por exemplo, uma tabela Detalhes da Encomenda que armazena itens de linha para encomendas utilizaria duas colunas na chave primária: ID da Encomenda e ID do Produto. Quando uma chave primária emprega mais de uma coluna, ela também é chamada de chave composta.

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

Início da Página

Criar as relações de tabela

Agora que dividiu as suas informações em tabelas, precisa de uma forma de reunir novamente as informações de formas significativas. Por exemplo, o seguinte formulário 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 Encomendas...

4. ... a tabela Produtos...

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

O Access é um sistema de gestão de bases de dados relacionais. Numa base de dados relacional, divide as suas informações em tabelas separadas baseadas no assunto. Em seguida, utilize 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 qualquer número de produtos. Segue-se que, 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 um-para-muitos.

Para representar uma relação um-para-muitos na estrutura da base de dados, utilize 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. Neste caso, por exemplo, adiciona a coluna ID do Fornecedor da tabela Fornecedores à tabela Produtos. Em seguida, o Access pode utilizar 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 é 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.

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

Início da Página

Criar uma relação muitos-para-muitos

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

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. Para cada registo na tabela Produtos, pode haver muitos registos na tabela Encomendas. Este tipo de relação chama-se uma relação muitos-para-muitos porque, para qualquer produto, pode haver muitas encomendas; e para qualquer encomenda, pode haver muitos produtos. Tenha em atenção que, para detetar relações muitos-para-muitos entre as tabelas, é importante que considere 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, muitas vezes 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 duas 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 por si só não funciona como a chave primária para esta tabela, porque uma encomenda pode ter muitos itens de linha. O ID da Encomenda é repetido para cada item de linha numa encomenda, pelo que o campo não contém valores exclusivos. Utilizar o campo ID do Produto por si só também não funciona, porque um produto pode aparecer em muitas encomendas diferentes. No entanto, em conjunto, os dois campos 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 diretamente relacionadas entre si. Em vez disso, estão relacionadas indiretamente através da tabela Detalhes da Encomenda. A relação muitos-para-muitos entre encomendas e produtos é representada na base de dados através de 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 apenas uma encomenda.
• A tabela Produtos e a tabela Detalhes da Encomenda têm uma relação um-para-muitos. Cada produto pode ter muitos itens de linha associados, mas cada item de linha refere-se apenas a um produto.

Na tabela Detalhes da Encomenda, pode determinar todos os produtos numa encomenda específica. Também pode determinar todas as encomendas de um determinado produto.

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

Início da Página

Criando um relacionamento de um-para-um

Outro tipo de relação é a relação um-para-um. Por exemplo, suponha que precisa de registar algumas informações especiais sobre produtos suplementares de que precisa raramente ou que se aplicam apenas a alguns produtos. Uma vez que não precisa das informações com frequência e porque armazenar as informações na tabela Produtos resultaria num espaço vazio para cada produto ao qual não se aplica, coloca-as numa tabela separada. Tal como na tabela Produtos, utiliza o ProductID como chave primária. A relação entre esta tabela suplementar e a tabela Produto é uma relação um-para-um. Para cada registo na tabela Produto, existe um único registo correspondente na tabela suplementar. Quando você identifica esse tipo de relação, ambas as tabelas devem compartilhar um campo em comum.

Ao detectar a necessidade de uma relação um-para-um em seu banco de dados, considere se você pode colocar as informações das duas tabelas juntas em uma tabela. Se você não quiser fazer isso por algum motivo, talvez porque isso resultaria em muito espaço vazio, a lista a seguir mostra como você representaria a relação em seu design:

• Se as duas tabelas tiverem o mesmo assunto, provavelmente você poderá configurar a relação usando 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 (uma delas) e insira sua chave primária na outra tabela como uma chave estrangeira.

Determinar as relações entre tabelas ajuda você a garantir que você tenha as tabelas e colunas certas. Quando existe uma relação de um para um ou um para muitos, as tabelas envolvidas precisam compartilhar uma coluna ou coluna comum. Quando existe uma relação de muitos para muitos, uma terceira tabela é necessária para representar a relação.

Início da Página

Refinando o design

Depois de ter as tabelas, campos e relacionamentos necessários, você deve criar e preencher suas tabelas com dados de exemplo e tentar trabalhar com as informações: criar consultas, adicionar novos registros e assim por diante. Fazer isso ajuda a realçar possíveis problemas – por exemplo, talvez seja necessário adicionar uma coluna que você esqueceu de inserir durante a fase de design ou pode ter uma tabela que você deve dividir em duas tabelas para remover a duplicação.

Veja se você pode usar o banco de dados para obter as respostas desejadas. Crie rascunhos brutos de seus formulários e relatórios e veja se eles mostram os dados esperados. Procure duplicação desnecessária de dados e, quando encontrar algum, altere seu design para eliminá-los.

Ao experimentar seu banco de dados inicial, você provavelmente descobrirá espaço para melhorias. Aqui estão algumas coisas para marcar:

• Esqueceu alguma coluna? Nesse caso, as informações pertencem às tabelas existentes? Se forem informações sobre outra coisa, talvez seja necessário criar outra tabela. Crie uma coluna para cada item de informação que você precisa rastrear. Se as informações não puderem ser calculadas de outras colunas, é provável que você precise de uma nova coluna para ela.
• Alguma coluna é desnecessária porque pode ser calculada a partir de campos existentes? Se um item de informações puder ser calculado a partir de outras colunas existentes – um preço com desconto calculado a partir do preço de varejo, por exemplo – geralmente é melhor fazer exatamente isso e evitar criar uma nova coluna.
• Você está inserindo repetidamente informações duplicadas em uma de suas tabelas? Se assim for, você provavelmente precisa dividir a tabela em duas tabelas que têm uma relação de um para muitos.
• Você tem tabelas com muitos campos, um número limitado de registros e muitos campos vazios em registros individuais? Nesse caso, pense em reprojetar a tabela para que ela tenha menos campos e mais registros.
• Cada item de informação foi dividido em suas menores partes úteis? Se você precisar relatar, classificar, pesquisar ou calcular em um item de informações, coloque esse item em sua própria coluna.
• Cada coluna contém um fato sobre o assunto da tabela? Se uma coluna não contiver informações sobre o assunto da tabela, ela pertence a uma tabela diferente.
• Todas as relações entre tabelas são representadas por campos comuns ou por uma terceira tabela? Relações um para um e um para muitos exigem colunas comuns. Relações de muitos para muitos exigem uma terceira tabela.

Refinando a tabela Produtos

Suponha que cada produto no banco de dados de vendas de produtos esteja em uma categoria geral, como bebidas, condimentos ou frutos do mar. A tabela Produtos pode incluir um campo que mostra a categoria de cada produto.

Suponha que, depois de examinar e refinar o design do banco de dados, você decida armazenar uma descrição da categoria junto com seu nome. Se você adicionar um campo Descrição de Categoria à tabela Produtos, deverá repetir cada descrição de categoria para cada produto que se enquadra na categoria – essa não é uma boa solução.

Uma solução melhor é tornar Categorias um novo assunto para o banco de dados acompanhar, com sua própria tabela e sua própria chave primária. Em seguida, você pode adicionar a chave primária da tabela Categorias à tabela Produtos como uma chave estrangeira.

As tabelas Categorias e Produtos têm uma relação de um para muitos: uma categoria pode incluir mais de um produto, mas um produto pode pertencer a apenas uma categoria.

Ao examinar suas estruturas de tabela, fique atento a grupos repetidos. Por exemplo, considere uma tabela que contém as seguintes colunas:

• ID do Produto
• Nome
• ID1 do produto
• Name1
• ID2 do produto
• Name2
• ID3 do produto
• Name3

Aqui, cada produto é um grupo repetido de colunas que difere das outras apenas adicionando um número ao final do nome da coluna. Quando você vir colunas numeradas dessa forma, você deve revisitar seu design.

Esse design tem várias falhas. Para começar, isso força você a colocar um limite superior no número de produtos. Assim que exceder esse limite, você deve adicionar um novo grupo de colunas à estrutura da tabela, que é uma tarefa administrativa importante.

Outro problema é que os fornecedores que têm menos do que o número máximo de produtos desperdiçarão algum espaço, já que as colunas adicionais ficarão em branco. A falha mais grave com esse design é que torna muitas tarefas difíceis de executar, como classificar ou indexar a tabela por ID ou nome do produto.

Sempre que você vir grupos repetidos, examine o design de perto de olho na divisão da tabela em dois. No exemplo acima, é melhor usar duas tabelas, uma para fornecedores e outra para produtos, vinculadas pela ID do fornecedor.

Início da Página

Aplicando as regras de normalização

Você pode aplicar as regras de normalização de dados (às vezes chamadas apenas de regras de normalização) como a próxima etapa em seu design. Use essas regras para ver se as tabelas estão estruturadas corretamente. O processo de aplicação das regras ao design do banco de dados é chamado de normalização do banco de dados ou apenas normalização.

A normalização é mais útil depois que você representa todos os itens de informação e chega a um design preliminar. A ideia é ajudá-lo a garantir que você tenha dividido seus itens de informações nas tabelas apropriadas. O que a normalização não pode fazer é garantir que você tenha todos os itens de dados corretos para começar.

Você aplica as regras em sucessão, em cada etapa, garantindo que seu design chegue a um dos "formulários normais". Cinco formulários normais são amplamente aceitos – o primeiro formulário normal até o quinto formulário normal. Este artigo se expande nos três primeiros, porque eles são tudo o que é necessário para a maioria dos designs de banco de dados.

Primeiro formulário normal

O primeiro formulário normal afirma que em cada interseção de linha e coluna na tabela, existe um único valor e nunca uma lista de valores. Por exemplo, você não pode ter um campo chamado Price no qual você coloca mais de um Preço. Se você pensar em cada interseção de linhas e colunas como uma célula, cada célula poderá conter apenas um valor.

Segundo formulário normal

O segundo formulário normal exige que cada coluna não-chave seja totalmente dependente de toda a chave primária, não apenas de parte da chave. Essa regra se aplica quando você tem uma chave primária que consiste em mais de uma coluna. Por exemplo, suponha que você tenha uma tabela que contém as seguintes colunas, em que iD do pedido e ID do produto formam a chave primária:

• ID do pedido (chave primária)
• ID do produto (chave primária)
• Nome do Produto

Esse design viola o segundo formulário normal, pois o Nome do Produto depende da ID do produto, mas não da ID do pedido, portanto, não depende de toda a chave primária. Você deve remover o Nome do Produto da tabela. Ele pertence a uma tabela diferente (Produtos).

Terceira forma normal

O terceiro formulário normal exige que não apenas todas as colunas não-chave dependam de toda a chave primária, mas que as colunas não-chave sejam independentes umas das outras.

Outra maneira de dizer isso é que cada coluna não-chave deve depender da chave primária e nada além da chave primária. Por exemplo, suponha que você tenha uma tabela contendo as seguintes colunas:

• ProductID (chave primária)
• Nome
• SRP
• Desconto

Suponha que o Desconto dependa do preço de varejo sugerido (SRP). Essa 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 você deve ser capaz de alterar qualquer coluna não-chave sem afetar nenhuma outra coluna. Se você alterar um valor no campo SRP, o Desconto será alterado de acordo, violando essa regra. Nesse caso, o Desconto deve ser movido para outra tabela que é chaveada no SRP.

Início da Página