Introdução aos bancos de dados

Para manter seu design focado, resuma a finalidade do banco de dados e consulte o resumo com frequência. Se quiser um pequeno banco de dados para uma empresa doméstica, por exemplo, você poderá escrever algo simples, como "o banco de dados do cliente mantém uma lista de informações do cliente a fim de produzir correspondências e relatórios". Para um banco de dados corporativo, talvez seja necessário vários parágrafos para descrever quando e como as pessoas em funções diferentes usarão o banco de dados e seus dados. Crie uma declaração de missão específica e detalhada para consultar ao longo do processo de design.

Comece com as informações existentes e os métodos de acompanhamento. Por exemplo, talvez no momento você registre ordens de compra em um livro-razão ou guarde as informações do cliente em formulários de papel. Use essas fontes para listar as informações capturadas no momento (por exemplo, todas as caixas em seus formulários). Onde você no momento não capturar informações importantes, pense sobre quais informações distintas serão necessárias. Cada tipo de dados individuais torna-se um campo no banco de dados.

Não se preocupe em deixar sua primeira lista perfeita: você poderá ajustá-la ao longo do tempo. Mas pense em todas as pessoas que usam essas informações e ouça suas ideias.

Em seguida, pense sobre o que você espera do banco de dados e os tipos de relatórios ou correspondências que deseja produzir. Em seguida, verifique se você está capturando as informações necessárias para atender a esses objetivos. Por exemplo, se você quiser um relatório que mostre as vendas por região, precisará capturar os dados de vendas no nível regional. Tente esboçar o relatório com as informações reais como gostaria de vê-las. Em seguida, liste os dados necessários para criar o relatório. Faça a mesma coisa para correspondências ou outras saídas desejadas do banco de dados.

Exemplo

Suponha que você forneça aos clientes a oportunidade de ativar ou desativar as atualizações periódicas de email e queira imprimir uma lista das pessoas que ativaram. Você precisará de uma coluna Enviar Email na tabela Clientes, com valores permitidos Sim e Não.

Para os que desejaram receber emails, você precisará de um endereço de email, que também exige um campo. Se quiser incluir uma saudação adequada (como Sr. ou Sra.), inclua um campo de Saudação. Se quiser se dirigir aos clientes pelo nome nos emails, adicione um campo Nome.

Depois de elaborar sua lista de informações necessárias, determine as principais entidades (ou assuntos) necessários para organizar seus dados. Evite duplicar dados entre entidades. Por exemplo, a lista preliminar para um banco de dados de vendas de produto poderia ser assim:

As entidades principais são: clientes, fornecedores, produtos e pedidos. Sendo assim, comece com essas quatro tabelas: uma para fatos sobre clientes, uma para fatos sobre fornecedores e assim por diante. Isso pode não ser seu design final, mas é um bom ponto de partida.

Para entender por que mais tabelas são melhores do que menos tabelas, considere a tabela a seguir:

Cada linha contém informações sobre o produto e seus fornecedores. Como você pode ter muitos produtos do mesmo fornecedor, as informações de nome e endereço do fornecedor devem ser repetidas várias vezes. Isso desperdiça espaço em disco. Em vez disso, registre as informações de fornecedor somente uma vez em uma tabela Fornecedores separada e vincule essa tabela à tabela Produtos.

Um segundo problema com este design é evidente quando você precisa modificar as informações sobre o fornecedor. Suponha que você precise alterar o endereço do fornecedor. Como ele aparece em vários lugares, talvez você acidentalmente altere o endereço em um só lugar, mas esqueça de alterá-lo em outros. Registrar o endereço do fornecedor em um só lugar resolve esse problema.

Por fim, vamos supor que haja apenas um produto fornecido pela Coho Winery e você queira excluir o produto, mas manter as informações de nome e endereço do fornecedor. Com esse design, como você poderia excluir o registro de produto sem perder as informações de fornecedor? Isso não é possível. Como cada registro contém informações sobre um produto além de fatos sobre um fornecedor, é impossível excluir um sem excluir o outro. Para manter esses fatos separados, divida essa tabela em duas: a primeira para informações sobre o produto e a segunda para informações sobre o fornecedor. Em seguida, quando você exclui um registro de produto, exclui apenas os fatos sobre o produto, não os fatos sobre o fornecedor.

Depois de selecionar o assunto para uma tabela de banco de dados, as colunas nessa tabela somente deverão armazenar fatos sobre esse único assunto. Por exemplo, uma tabela de produto deve armazenar fatos apenas sobre os produtos, não sobre seus fornecedores.

Para decidir quais informações devem ser controladas na tabela, use a lista criada anteriormente. Por exemplo, a tabela Clientes pode incluir: Nome, Sobrenome, Endereço, Enviar Email, Saudação e Endereço de Email. Cada registro (cliente) na tabela contém o mesmo conjunto de colunas, para que você armazene exatamente as mesmas informações para cada cliente.

Crie sua primeira lista e, em seguida, analise e melhore-a. Lembre-se de dividir informações nos menores campos possíveis. Por exemplo, se sua lista inicial tiver Endereço como um campo, divida em Endereço, Cidade, Estado e CEP, ou, se seus clientes forem globais, em ainda mais campos. Dessa forma, por exemplo, você pode fazer correspondência no formato adequado ou relatório de pedidos por estado.

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

Você precisa de uma maneira exclusiva de identificar cada linha de cada tabela. Lembra-se do exemplo anterior em que duas clientes têm o mesmo nome? Como têm o mesmo nome, você precisa de uma maneira de identificar cada uma separadamente.

Assim, cada tabela deve incluir uma coluna (ou um conjunto de colunas) que identifique exclusivamente cada linha. Isso é chamado de chave primária e normalmente é um número exclusivo, como um número de ID de funcionário ou número de série. O Access utiliza chaves primárias para associar rapidamente dados de várias tabelas e reunir os dados para você.

Às vezes, a chave primária consiste em dois ou mais campos. Por exemplo, uma tabela Detalhes do Pedido que armazena itens de linha para pedidos pode usar 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.

Se você já tiver um identificador exclusivo para as informações em uma tabela, como números de produto que identificam exclusivamente cada produto em seu catálogo, use-o, mas somente se os valores atenderem a essas regras para chaves primárias:

• O identificador sempre será diferente para cada registro. Valores duplicados não são permitidos em uma chave primária.

• Sempre há um valor para o item. Todos os registros em sua tabela devem ter uma chave primária. Se você estiver usando várias colunas para criar a chave (como Família da Peça e Número da Peça), ambos os valores sempre deverão estar presentes.

• A chave primária é um valor que não muda. Como as teclas são referenciadas por outras tabelas, qualquer alteração em uma chave primária em uma tabela significa uma alteração em todos os lugares que fazem referência a ela. Alterações frequentes aumentam o risco de erros.

Se você não tiver um identificador óbvio, use um número arbitrário e único como chave primária. Por exemplo, você pode atribuir a cada pedido um número de pedido exclusivo com o único propósito de identificar o pedido.