Um banco de dados projetado corretamente fornece acesso a informações atualizadas e precisas. Como um design correto é essencial para atingir suas metas 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ê termine com um banco de dados que atenda às suas necessidades e possa facilmente acomodar as alterações.
Este artigo fornece diretrizes para o planejamento de um banco de dados de área de trabalho. Você aprenderá a decidir de que informações 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 de área de trabalho.
Importante: Access oferece experiências de design que permitem criar aplicativos de banco de dados para a Web. Muitas considerações de design são diferentes quando você projeta para a Web. Este artigo não discute o design do aplicativo de banco de dados da Web. Para obter mais informações, consulte o artigo Criar um banco de dados para compartilhar na Web.
Neste artigo
Alguns termos de banco de dados para saber
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 registroe 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.
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 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 totalidade das informações são importantes. Se o banco de dados contiver informações incorretas, os relatórios que retirarem informações do banco de dados também conterão informações incorretas. Como resultado, todas as decisões tomadas com base nesses relatórios serão mal informadas.
Um bom design de banco de dados é, portanto, um que:
-
Divide suas informações em tabelas baseadas em assunto para reduzir dados redundantes.
-
Fornece ao Access as informações necessárias para ingressar as informações nas tabelas, conforme necessário.
-
Ajuda a dar suporte e garantir a precisão e a integridade de suas informações.
-
Acomoda suas necessidades de processamento e 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 preparar você para as etapas restantes.
-
Localizar e organizar as informações necessárias
Reúna todos os tipos de informações que você pode querer registrar no banco de dados, como nome do produto e número de pedido.
-
Dividir as informações em tabelas
Divida seus itens de informações em entidades ou entidades principais, como Produtos ou Pedidos. Em seguida, cada assunto 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 Employees 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
Veja 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 para ver se há erros. Crie as tabelas e adicione alguns registros de dados de exemplo. Veja se você pode obter os resultados que deseja 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 suas tabelas estão estruturadas corretamente. Faça ajustes nas tabelas, conforme necessário.
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 o objetivo de produzir emails e relatórios". Se o banco de dados for mais complexo ou for usado por muitas pessoas, como geralmente ocorre em uma configuração corporativa, a finalidade pode 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 referenciada em todo o processo de design. Ter essa instrução ajuda você a se concentrar em suas metas ao tomar decisões.
Localizar e organizar as informações necessárias
Para encontrar e organizar as informações necessárias, comece com suas informações existentes. Por exemplo, você pode registrar pedidos de compra em um livro-razão ou manter informações do cliente em formulários de papel em um gabinete de arquivos. Reúna esses documentos e liste cada tipo de informação mostrada (por exemplo, cada caixa que você preencher em um formulário). Se você não tiver formulários existentes, imagine que você precisa projetar um formulário para registrar as informações do cliente. Quais informações você colocaria no formulário? Quais caixas de preenchimento você criaria? Identifique e liste cada um desses itens. Por exemplo, suponha que você mantenha a lista de clientes nos cartões de índice. Examinar esses cartões pode mostrar que cada cartão contém um nome de cliente, endereço, cidade, estado, código postal e número de telefone. Cada um desses itens representa uma coluna potencial em uma tabela.
Ao preparar essa lista, não se preocupe em aperfeiçoá-la no início. Em vez disso, liste cada item que vier à mente. Se outra pessoa estiver usando 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 você pode querer 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 mostra os níveis de inventário do produto. Você também pode querer gerar letras de formulário para enviar aos clientes que anunciam um evento de venda ou oferecem um prêmio. Projete o relatório em sua mente e imagine como ele seria. Quais informações você colocaria no relatório? Listar cada item. Faça o mesmo para a carta de formulário e para qualquer outro relatório que você antecipar a criação.
Pensar nos relatórios e mailings que você pode querer criar ajuda a identificar itens necessários no banco de dados. Por exemplo, suponha que você dê aos clientes a oportunidade de optar por (ou não) atualizações periódicas de email e você deseja imprimir uma listagem daqueles que optaram por. Para registrar essas informações, adicione uma coluna "Enviar email" à tabela de clientes. 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 "Caro. Sr. Sylvester Smith". Isso sugere que você normalmente deseja armazenar o sobrenome separado do primeiro nome.
Um ponto importante a ser lembrado é que você deve quebrar cada informação em suas menores partes úteis. No caso de um nome, para disponibilizar prontamente o sobrenome, você quebrará 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ê 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 de seu produto em destaque você fechar no mês passado? Onde seus melhores clientes moram? Quem é o fornecedor do produto mais vendido? A antecipação dessas perguntas ajuda você a zero em itens adicionais a registrar.
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 os assuntos. Por exemplo, depois de localizar e organizar informações para 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 conclua a lista, é um bom ponto de partida. Você pode continuar refinando essa lista até ter um design que funcione bem.
Ao revisar pela primeira vez a lista preliminar de itens, você pode ficar tentado a colocar todos eles em uma única tabela, em vez dos quatro mostrados 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, o nome do fornecedor e as informações de endereço devem ser repetidas muitas vezes. Isso desperdiça espaço em disco. Gravar as informações do fornecedor apenas uma vez em uma tabela de Fornecedores separada 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, 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 local, como o endereço de um determinado fornecedor, coloque essas informações em uma tabela separada.
Por fim, suponha que haja apenas um produto fornecido pela Coho Winery e você deseja excluir o produto, mas manter as informações de nome e endereço do fornecedor. Como excluir o registro do produto sem também perder 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 a tabela em duas: uma tabela para informações do produto e outra para informações do fornecedor. Excluir 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ções em colunas
Para determinar as colunas em uma tabela, decida quais informações você precisa rastrear sobre o assunto gravado na tabela. Por exemplo, para a tabela Customers, Name, Address, City-State-Zip, Send e-mail, Salutation and E-mail address compõem uma boa lista inicial de colunas. Cada registro na tabela contém o mesmo conjunto de colunas, para que você possa armazenar Name, Address, City-State-Zip, Send e-mail, Salutation and E-mail address information for each record. 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ê pode 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 essas colunas. Da mesma forma, o endereço realmente 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ê deseja executar uma operação de pesquisa, filtro ou classificação por estado, por exemplo, você precisa 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 internacional também. Por exemplo, se você planeja armazenar endereços internacionais, é melhor ter uma coluna Região em vez de Estado, pois essa coluna pode acomodar estados domésticos e as regiões de outros países/regiões. Da mesma forma, o Código Postal faz mais sentido do que o CEP se você for 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 Unidades No Pedido que armazena as unidades em ordem para cada produto. Usando esses dados, o Access calcula o subtotal sempre que você imprimir 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 estar tentado a ter um único campo para nomes completos ou para nomes de produtos, juntamente com descrições do produto. Se você combinar mais de um tipo de informação em um campo, será difícil recuperar fatos individuais posteriormente. Tente separar 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.
Especificando chaves primárias
Cada tabela deve incluir uma coluna ou um conjunto de colunas que identifique exclusivamente cada linha armazenada na tabela. Geralmente, esse é 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 do banco de dados, essas informações são chamadas de chave primária da tabela. O Access usa campos principais 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 identifique exclusivamente cada produto em seu catálogo, poderá usar esse identificador como chave primária da tabela, mas somente se os valores desta coluna sempre serão diferentes para cada registro. Não é possível 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ê pode 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 pode se tornar não atribuído ou desconhecido (um valor ausente) em algum ponto, ele não pode ser usado como um componente em uma chave primária.
Você sempre deve escolher uma chave primária cujo valor não mudará. 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 mudar, a alteração também deverá ser aplicada em todos os lugares em que a chave for referenciada. O uso de uma chave primária que não mudará reduz a chance de que a chave primária possa ficar fora de sincronia com outras tabelas que a referenciam.
Muitas vezes, um número exclusivo arbitrário é usado como a chave primária. Por exemplo, você pode atribuir a cada ordem um número de pedido exclusivo. A única finalidade do número de pedido é identificar uma ordem. Uma vez atribuído, ele nunca muda.
Se você não tem em mente uma coluna ou um conjunto de colunas que podem fazer uma boa chave primária, considere usar uma coluna que tenha o tipo de dados Denumber Automático. Quando você usa o tipo de dados AutoNumber, o Access atribui automaticamente um valor para você. Esse identificador não tem fatos; ele não contém informações factuais que descrevem a linha que ela representa. Os identificadores sem fatos são ideais para uso como chave primária porque eles 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 — é mais provável de ser mudada, pois as informações factuais em si podem mudar.
1. Uma coluna definida como o tipo de dados de Numeração Automática geralmente faz uma boa chave primária. Nenhuma ID de produto é a mesma.
Em alguns casos, talvez você queira usar dois ou mais campos que, juntos, forneçam 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 servir como chave primária: ProductID para a tabela Produtos, OrderID para a tabela Pedidos, 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 Pedidos...
4. ... a tabela Produtos...
5. ... e a tabela Detalhes do Pedido.
O 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, 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 produto. Um fornecedor pode fornecer qualquer número de produtos. Ele segue 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 no design do banco de dados, pegue a chave primária no lado "um" da relação e adicione-a como uma coluna ou coluna adicional à tabela no lado "muitos" da relação. Nesse caso, por exemplo, você adiciona a coluna ID do Fornecedor da tabela Fornecedores à tabela Produtos. Em seguida, o 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 ingressar em 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 um-para-muitos garante que as duas tabelas envolvidas, de fato, 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 relação é chamado de uma relação de muitos para muitos, pois para qualquer produto, pode haver muitos pedidos; e para qualquer ordem, pode haver muitos produtos. Observe que, para detectar muitas relações entre suas tabelas, é importante considerar 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 pedido. Você estaria repetindo informações de 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ê teria mais de um registro na tabela Produtos para cada produto. Como resolver 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 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 da Ordem representa um item de linha em uma ordem. A chave primária da tabela Detalhes da Ordem consiste em dois campos : as chaves estrangeiras das tabelas Pedidos e Produtos. Usar o campo ID do pedido sozinho não funciona como a chave primária para esta tabela, pois uma ordem pode ter muitos itens de linha. A ID do pedido é repetida para cada item de linha em uma ordem, portanto, 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 do produto, a tabela Pedidos e a tabela Produtos não estão relacionadas umas às outras diretamente. Em vez disso, eles sã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 um-para-muitos:
-
A tabela Pedidos e a tabela Detalhes do Pedido têm uma relação um-para-muitos. Cada ordem 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 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 uma ordem específica. 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 ter a seguinte aparência:
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 de produto suplementar especiais que você precisará raramente 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 não se aplica, você as coloca em uma tabela separada. Como a tabela Produtos, você usa ProductID como a chave primária. A relação entre essa tabela complementar e a tabela Product é uma relação um para um. Para cada registro na tabela Product, 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 no 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 resultaria em muito espaço vazio, a lista a seguir mostra como você representaria a relação em seu design:
-
Se as duas tabelas têm o mesmo assunto, você provavelmente pode configurar a relação usando a mesma chave primária em ambas as tabelas.
-
Se as duas tabelas têm 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 corretas. Quando existe uma relação 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 relações necessárias, 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, você pode precisar 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 que deseja. Crie rascunhos aproximados 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 a verificar:
-
Esqueceu alguma coluna? Nesse caso, as informações pertencem às tabelas existentes? Se for informações sobre outra coisa, talvez seja necessário criar outra tabela. Crie uma coluna para cada item de informações 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.
-
As colunas são desnecessárias porque elas podem ser calculadas a partir de campos existentes? Se um item de informação puder ser calculado a partir de outras colunas existentes — um preço com desconto calculado do preço de varejo, por exemplo — geralmente é melhor fazer exatamente isso e evitar a criação de novas colunas.
-
Você está inserindo repetidamente informações duplicadas em uma de suas tabelas? Nesse caso, você provavelmente precisará dividir a tabela em duas tabelas que tenham uma relação um-para-muitos.
-
Você tem tabelas com muitos campos, um número limitado de registros e muitos campos vazios em registros individuais? Em caso afirmado, pense em redesenhar 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 contém 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? Relacionamentos um para um e um para muitos exigem colunas comuns. As relações de muitos para muitos exigem uma terceira tabela.
Refinando a tabela Produtos
Suponha que cada produto no banco de dados de vendas do produto se enquadra 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 juntamente com seu nome. Se você adicionar um campo Descrição de Categoria à tabela Produtos, você terá que 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 Categories um novo assunto para o banco de dados rastrear, 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 um-para-muitos: uma categoria pode incluir mais de um produto, mas um produto pode pertencer a apenas uma categoria.
Ao revisar suas estruturas de tabela, fica atento a grupos repetidos. Por exemplo, considere uma tabela contendo as seguintes colunas:
-
ID do Produto
-
Nome
-
ID1 do produto
-
Name1
-
ID do produto2
-
Name2
-
ID do produto3
-
Name3
Aqui, cada produto é um grupo repetido de colunas que difere dos outros 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 você exceder esse limite, você deverá 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, pois as colunas adicionais estarão em branco. A falha mais grave com esse design é que ele torna muitas tarefas difíceis de executar, como classificação ou indexação da tabela por ID do produto ou nome.
Sempre que você vir grupos repetidos, revise o design de perto com um olho na divisão da tabela em dois. No exemplo acima, é melhor usar duas tabelas, uma para fornecedores e uma para produtos, vinculadas por ID de fornecedor.
Aplicando as regras de normalização
Você pode aplicar as regras de normalização de dados (às vezes apenas chamadas de regras de normalização) como a próxima etapa em seu design. Você usa essas regras para ver se suas 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ê representou todos os itens de informações e chegou 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 que são conhecidos como "formulários normais". Cinco formulários normais são amplamente aceitos , o primeiro formulário normal através do quinto formulário normal. Este artigo se expande nos três primeiros, pois 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 Preço 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 contendo as seguintes colunas, onde a ID do Pedido e a 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 da chave primária inteira. Você deve remover o Nome do Produto da tabela. Ele pertence a uma tabela diferente (Produtos).
Terceiro formulário normal
O terceiro formulário normal exige que não apenas todas as colunas que não sejam de chave sejam dependentes 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 Discount dependa do preço de varejo sugerido (SRP). Esta tabela viola o terceiro formulário normal porque uma coluna não chave, Discount, depende de outra coluna não chave, SRP. A independência da coluna significa que você deve ser capaz de alterar qualquer coluna que não seja de chave sem afetar qualquer outra coluna. Se você alterar um valor no campo SRP, o Discount mudará de acordo, violando essa regra. Nesse caso, Discount deve ser movido para outra tabela que é chaveada em SRP.
