Uma base de dados corretamente concebida fornece-lhe acesso a informações atualizadas e precisas. Uma vez que um design correto é essencial para alcançar os seus objetivos de trabalhar com uma base 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 acabe com uma base de dados que satisfaça as suas necessidades e possa facilmente acomodar alterações.
Este artigo fornece diretrizes para planear uma base de dados de ambiente de trabalho. Irá aprender a decidir de que informações precisa, como dividir essas informações nas tabelas e colunas adequadas e como essas tabelas se relacionam entre si. 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 saber
Access organiza as suas informações em tabelas: listas de linhas e colunas que lembram o teclado 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, precisará de mais do que uma. Por exemplo, pode ter uma tabela que armazena informações sobre produtos, outra tabela que armazena informações sobre encomendas e outra tabela com informações sobre clientes.
Cada linha é mais corretamente denominada registo e cada coluna, um campo. Um registo é uma forma 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 registos. 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?
Determinados princípios orientam o processo de conceção da base de dados. O primeiro princípio é que a informação duplicada (também denominada dados redundantes) é má, porque perde espaço e aumenta a probabilidade de erros e inconsistências. O segundo princípio é que a correção e a preenza das informações são importantes. Se a base de dados contiver informações incorretas, os relatórios que solicitarem informações da base de dados também irão conter informações incorretas. Como resultado, todas as decisões que tomar com base nesses relatórios serão mal informadas.
Uma boa estrutura de base de dados é, portanto, uma estrutura que:
-
Divide as suas informações em tabelas baseadas em assuntos para reduzir os dados redundantes.
-
Fornece Access com as informações necessárias para associar as informações nas tabelas, conforme necessário.
-
Ajuda a suportar e garantir a exatidão e integridade das suas informações.
-
Acomoda as suas necessidades de processamento de dados e relatórios.
O processo de conceção
O processo de conceção consiste nos seguintes passos:
-
Determinar a finalidade do seu banco de dados
Isto ajuda a prepará-lo para os restantes passos.
-
Localizar e organizar as informações necessárias
Reúna todos os tipos de informações que poderá querer registar na base de dados, como o nome do produto e o número da encomenda.
-
Dividir as informações em tabelas
Divida os seus itens de informações em entidades ou assuntos principais, como Produtos ou Encomendas. Em seguida, cada assunto torna-se uma tabela.
-
Transformar itens de informações 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 Funcionários pode incluir campos como Apelido e Data de Contratação.
-
Especificar chaves primárias
Escolha a chave primária de cada tabela. A chave primária é uma coluna que é utilizada para identificar exclusivamente cada linha. Um exemplo pode ser ID do Produto ou ID da Encomenda.
-
Configurar as relações de tabela
Observe cada tabela e decida como os dados numa tabela estão relacionados com os dados noutras tabelas. Adicione campos a tabelas ou crie novas tabelas para clarificar as relações, conforme necessário.
-
Refinar a estrutura
Analise a sua estrutura quanto a erros. Crie as tabelas e adicione alguns registos de dados de exemplo. Veja se consegue obter os resultados que pretende das tabelas. Faça ajustes à estrutura, 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 às tabelas, conforme necessário.
Determinar o objetivo da base de dados
Recomendamos que anote a finalidade da base de dados no papel , a sua finalidade, como espera utilizá-la e quem irá utilizá-la. Para uma pequena base de dados para uma empresa baseada em casa, por exemplo, pode escrever algo simples como "A base de dados do cliente mantém uma lista de informações do cliente com o objetivo de produzir mailings e relatórios". Se a base de dados for mais complexa ou for utilizada por muitas pessoas, como ocorre frequentemente numa definição empresarial, a finalidade pode ser facilmente um parágrafo ou mais e deve incluir quando e como cada pessoa irá utilizar a base de dados. A ideia é ter uma declaração de missão bem desenvolvida que possa ser referida ao longo do processo de design. Ter essa afirmação ajuda-o a concentrar-se nos seus objetivos quando tomar decisões.
Localizar e organizar as informações necessárias
Para localizar e organizar as informações necessárias, comece com as suas informações existentes. Por exemplo, pode registar encomendas de compra num livro razão ou manter as informações dos clientes em formulários em papel num arquivo de ficheiros. Reúna esses documentos e liste cada tipo de informações apresentadas (por exemplo, cada caixa que preencher num formulário). Se não tiver formulários existentes, imagine que tem de estruturar um formulário para registar as informações do cliente. Que informações colocaria no formulário? Que caixas de preenchimento criaria? Identificar e listar cada um destes itens. Por exemplo, suponha que atualmente mantém a lista de clientes nos cartões de índice. Examinar estes 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 destes itens representa uma coluna potencial numa tabela.
À medida que prepara 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 estiver a utilizar a base de dados, peça também as suas ideias. Pode ajustar a lista mais tarde.
Em seguida, considere os tipos de relatórios ou mailings que poderá querer produzir a partir da base de dados. Por exemplo, poderá querer que um relatório de vendas de produtos mostre as vendas por região ou um relatório de resumo de inventário que mostre os níveis de inventário de produtos. Também poderá 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 na sua mente e imagine como seria. Que informações colocaria no relatório? Listar cada item. Faça o mesmo para a letra de formulário e para qualquer outro relatório que preveja criar.
Pensar nos relatórios e mailings que poderá querer criar ajuda-o a identificar os itens de que irá precisar na sua base de dados. Por exemplo, suponha que dá aos clientes a oportunidade de optarem por receber (ou não) atualizações periódicas de e-mail e pretende imprimir uma listagem das pessoas que optaram por participar. Para registar essas informações, adicione uma coluna "Enviar e-mail" à tabela de clientes. Para cada cliente, pode definir o campo como Sim ou Não.
O requisito para enviar mensagens de e-mail aos clientes sugere outro item a registar. Assim que souber que um cliente quer receber mensagens de e-mail, também terá de saber o endereço de e-mail para o qual pretende enviá-las. Por conseguinte, tem 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 que poderá querer que a base de dados responda. Por exemplo, quantas vendas do produto em destaque fechou no mês passado? Onde vivem os seus melhores clientes ? Quem é o fornecedor do seu produto mais vendido? Antecipar estas perguntas ajuda-o a utilizar itens adicionais a registar.
Depois de recolher estas informações, está pronto para o próximo passo.
Dividir as informações em tabelas
Para dividir as informações em tabelas, selecione as principais entidades ou assuntos. Por exemplo, depois de encontrar e organizar informações para uma base de dados de vendas de produtos, a lista preliminar poderá ter o seguinte aspeto:
As principais entidades aqui apresentadas são os produtos, os fornecedores, os clientes e as encomendas. Por conseguinte, faz sentido começar com estas quatro tabelas: uma para factos sobre produtos, outra para factos sobre fornecedores, outra para factos sobre clientes e outra para factos sobre encomendas. Embora esta ação não conclua a lista, é um bom ponto de partida. Pode continuar a refinar esta lista até ter um design que funcione bem.
Quando revê pela primeira vez a lista preliminar de itens, poderá sentir-se tentado a colocá-los todos numa única tabela, em vez dos quatro apresentados na ilustração anterior. Vais aprender aqui porque é que isso é uma má ideia. Considere por um momento, a tabela apresentada aqui:
Neste caso, cada linha contém informações sobre o produto e o respetivo fornecedor. Uma vez que pode ter muitos produtos do mesmo fornecedor, o nome do fornecedor e as informações de endereço têm de ser repetidos muitas vezes. Isso desperdiça espaço em disco. Registar as informações do fornecedor apenas uma vez numa tabela Fornecedores separada e, em seguida, ligar essa tabela à tabela Produtos, é uma solução muito melhor.
Um segundo problema com esta estrutura surge quando precisa de modificar as informações sobre o fornecedor. Por exemplo, suponha que precisa de 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. Registar o endereço do fornecedor em apenas um local resolve o problema.
Ao estruturar a sua base de dados, tente sempre registar cada facto apenas uma vez. Se repetir as mesmas informações em mais do que um local, como o endereço de um fornecedor específico, coloque essas informações numa tabela separada.
Por fim, suponha que existe apenas um produto fornecido pela Coho Winery e que pretende eliminar o produto, mas manter as informações de nome e endereço do fornecedor. Como eliminaria o registo do produto sem perder também as informações do fornecedor? Isso 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 uma tabela em duas: uma tabela para informações sobre o produto e outra tabela para obter informações sobre fornecedores. A eliminação de um registo de produto deve eliminar apenas os factos sobre o produto e não os factos sobre o fornecedor.
Depois de escolher o assunto representado por uma tabela, as colunas nessa tabela devem armazenar factos apenas sobre o assunto. Por exemplo, a tabela de produtos deve armazenar factos apenas sobre produtos. Uma vez que o endereço do fornecedor é um facto sobre o fornecedor e não um facto sobre o produto, pertence à tabela de fornecedores.
Transformar itens de informações em colunas
Para determinar as colunas numa tabela, decida que informações precisa de controlar sobre o assunto registado na tabela. Por exemplo, para a tabela Clientes, Nome, Endereço, Cidade-Estado-Zip, Enviar e-mail, Saudação e Endereço de e-mail incluem uma boa lista inicial de colunas. Cada registo na tabela contém o mesmo conjunto de colunas, para que possa armazenar informações de Nome, Endereço, Cidade-Estado-Zip, Enviar e-mail, Saudação e Endereço de e-mail para cada registo. Por exemplo, a coluna de endereço 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 considerar se a base de dados irá conter informações apenas de origem doméstica ou internacionais. Por exemplo, se planear armazenar endereços internacionais, é melhor ter uma coluna Região em vez de Estado, uma vez que essa coluna pode acomodar os estados nacionais e as 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 pretender armazenar endereços internacionais.
A lista seguinte mostra algumas sugestões para determinar as colunas.
-
Não incluir dados calculados
Na maioria dos casos, não deve armazenar o resultado dos cálculos em tabelas. Em vez disso, pode ter Access efetuar os cálculos quando quiser ver o resultado. Por exemplo, suponha que existe um relatório Produtos Por Encomenda que apresenta o subtotal de unidades por encomenda para cada categoria de produto na base de dados. No entanto, não existe nenhuma coluna de subtotal Unidades Por Encomenda em nenhuma tabela. Em vez disso, a tabela Produtos inclui uma coluna Unidades Por Encomenda que armazena as unidades por encomenda para cada produto. Ao utilizar esses dados, Access calcula o subtotal sempre que imprime o relatório. O subtotal em si não deve ser armazenado numa tabela.
-
Armazenar informações nas 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 refinar 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. Geralmente, trata-se de 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 da base de dados, estas informações são denominadas chave primária da tabela. Access utiliza campos de chave primária para associar rapidamente dados de várias tabelas e reunir os dados automaticamente.
Se já tiver um identificador exclusivo para uma tabela, como um número de produto que identifica exclusivamente cada produto no seu catálogo, pode utilizar esse identificador como chave primária da tabela, mas apenas se os valores nesta coluna forem sempre diferentes para cada registo. Não pode ter valores duplicados numa chave primária. Por exemplo, não utilize os nomes das pessoas como chave primária, porque os nomes não são exclusivos. Pode facilmente ter duas pessoas com o mesmo nome na mesma tabela.
Uma chave primária tem de ter sempre um valor. Se o valor de uma coluna puder ficar não atribuído ou desconhecido (um valor em falta) em algum momento, não pode ser utilizado como um componente numa chave primária.
Deve sempre 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 você não tiver em mente uma coluna ou um conjunto de colunas que possam fazer uma boa chave primária, considere usar uma coluna que tenha o tipo de dados AutoNumber. Quando você usa o tipo de dados AutoNumber, Access atribui automaticamente um valor para você. Esse identificador não tem fatos; não contém informações factuais que descrevem a linha que ela representa. Identificadores sem fatos são ideais para uso como chave primária porque não são alterados. Uma chave primária que contém fatos sobre uma linha – um número de telefone ou um nome de cliente, por exemplo – é mais provável que seja alterada, pois as próprias informações factuais podem ser alteradas.
1. Um conjunto de colunas para o tipo de dados AutoNumber geralmente faz uma boa chave primária. Nenhuma ID de produto é a mesma.
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 Detalhes do Pedido que armazena itens de linha para pedidos usaria duas colunas em sua 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 AutoNumber para cada uma das tabelas para servir como chave primária: ProductID para a tabela Produtos, OrderID para a tabela Orders, CustomerID para a tabela Clientes e SupplierID para a tabela Fornecedores.
Criando as relações de tabela
Agora que você dividiu suas informações em tabelas, você 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 desse formulário são originárias da tabela Clientes...
2. ... a tabela Funcionários...
3. ... a tabela Ordens...
4. ... a tabela Produtos...
5. ... e a tabela Detalhes do Pedido.
Access é um sistema de gerenciamento de banco de dados relacional. Em um banco de dados relacional, você divide suas informações em tabelas separadas baseadas em assunto. Em seguida, você usa relações de tabela para reunir as informações conforme necessário.
Criando uma relação de um para muitos
Considere este exemplo: as tabelas Fornecedores e Produtos no banco de dados de pedidos de produto. 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 de um para muitos.
Para representar uma relação de um para muitos no design do banco de dados, pegue 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. Access pode 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 exigirão, de fato, 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 relação é chamado de uma relação de 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 suas tabelas, é importante que você considere ambos os lados da relação.
Os assuntos das duas tabelas – pedidos e produtos – têm uma relação de muitos para muitos. Isso apresenta 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 ordem. Você estaria repetindo informações de pedido 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, muitas vezes 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. Usar o campo ID de pedido sozinho não funciona como a chave primária para esta tabela, pois um pedido pode ter muitos itens de linha. A ID do pedido é repetida para cada item de linha em um pedido, de modo que o campo não contém valores exclusivos. Usar o campo ID do produto sozinho também não funciona, pois um produto pode aparecer em muitos pedidos diferentes. Mas 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, eles estão relacionados 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:
-
A tabela Pedidos e a tabela 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 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 semelhante a esta:
Criando um relacionamento de um-para-um
Outro tipo de relação é a relação um-para-um. Por exemplo, suponha que você precise registrar algumas informações especiais de produto suplementar que você raramente precisará ou que se aplique 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 ela não se aplica, você as coloca em uma tabela separada. Assim como a tabela Produtos, você usa o ProductID como a chave primária. A relação entre essa tabela suplementar e a tabela Product é uma relação de um para um. Para cada registro na tabela Produto, existe um único registro 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.
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.
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.
