Vídeo: Introdução às bases de dados

Para manter a estrutura focada, resuma o objetivo da base de dados e consulte esse resumo com frequência. Se pretender, por exemplo, uma base de dados pequena para um negócio doméstico, poderá escrever algo simples, como "A base de dados de clientes contém uma lista de informações de clientes com o objetivo de criar mailings e relatórios". Para uma base de dados empresarial, poderá necessitar de vários parágrafos para descrever quando e como pessoas com diferentes funções irão utilizar a base de dados e os respetivos dados. Crie uma declaração de objetivos específica e detalhada para consulta ao longo do processo de estruturação.

Comece com as informações e os métodos de controlo existentes. Por exemplo, é provável que registe atualmente as notas de encomenda num registo financeiro ou que inclua as informações dos clientes em formulários de papel. Utilize essas origens para listar as informações que está atualmente a recolher (por exemplo, todas as caixas dos formulários). Para as informações importantes que não esteja a recolher, pense nas informações distintas de que precisa. Cada tipo de dados individual torna-se um campo na sua base de dados.

Não se preocupe em tornar a sua primeira lista perfeita, já que pode otimizá-la ao longo do tempo. No entanto, tenha em conta todas as pessoas que utilizam essas informações e peça-lhes ideias.

Em seguida, pense no que pretende com a base de dados e nos tipos de relatórios ou mailings que pretende criar. Certifique-se também de que está a recolher as informações necessárias para cumprir esses objetivos. Por exemplo, se pretender um relatório que mostre vendas por região, tem de recolher os dados de vendas ao nível regional. Experimente esboçar o relatório com as informações dispostas como as pretende ver. Em seguida, liste os dados de que necessita para criar o relatório. Efetue o mesmo para mailings ou outro tipo de resultados que pretenda da base de dados.

Exemplo

Suponha que dá aos clientes a possibilidade de optarem por receber (ou não receber) atualizações periódicas por e-mail e que pretende imprimir uma lista das pessoas que optaram por receber. Necessita de uma coluna Enviar E-mail na tabela Cliente, com valores permitidos de Sim e Não.

Para as pessoas dispostas a receber e-mails, necessita de um endereço de e-mail, o que também requer um campo. Se pretender incluir uma saudação inicial (como Sr. ou Sra.), inclua o campo Saudação. Se pretender tratar os clientes pelo nome próprio nos e-mails, adicione o campo Nome Próprio.

Depois de ter a lista de informações necessárias, determine as entidades (ou assuntos) principais de que necessita para organizar os seus dados. Evite duplicar dados em várias entidades. Por exemplo, a lista preliminar para uma base de dados de vendas de produtos poderá ter o seguinte aspeto:

As entidades principais são as seguintes: clientes, fornecedores, produtos e encomendas. Por conseguinte, deve começar com essas quatro tabelas: uma para factos sobre clientes, uma para factos sobre fornecedores e assim sucessivamente. Esta pode não ser a estrutura final, mas é um bom ponto de partida.

Para compreender por que razão ter mais tabelas é melhor do que ter menos, observe a seguinte tabela:

Cada linha contém informações sobre o produto e o respetivo fornecedor. Uma vez que pode ter vários produtos do mesmo fornecedor, o nome e o endereço do fornecedor têm de ser repetidos várias vezes. Isto ocupa espaço desnecessário em disco. Em alternativa, registe as informações do fornecedor apenas uma vez numa tabela Fornecedores em separado e, em seguida, associe essa tabela à tabela Produtos.

Um segundo problema com esta estrutura torna-se evidente ao modificar as informações sobre o fornecedor. Suponha que necessita de alterar o endereço de um fornecedor. Uma vez que é apresentado em vários locais, o endereço poderá ser acidentalmente alterado num local, mas não nos outros. Registar o endereço do fornecedor em apenas um local resolve este problema.

Por fim, suponha que a Coho Winery fornece apenas um produto e que pretende eliminar o produto, mas manter o nome e o endereço de fornecedor. Com esta estrutura, é possível eliminar o registo do produto sem perder também as informações do fornecedor? Não é possível. Uma vez que cada registo contém factos sobre um produto, além de factos sobre um fornecedor, é impossível eliminar um sem eliminar o outro. Para manter estes factos separados, divida a tabela em duas: a primeira para as informações do produto e a segunda para as informações do fornecedor. Assim, ao eliminar um registo de produto, elimina apenas os factos sobre o produto e não os factos sobre o fornecedor.

Depois de escolher o assunto para uma tabela de base de dados, as colunas dessa tabela devem apenas armazenar factos sobre esse assunto específico. Por exemplo, uma tabela de produtos deverá armazenar factos apenas sobre produtos e não sobre os respetivos fornecedores.

Para escolher as informações a controlar na tabela, utilize a lista que criou anteriormente. Por exemplo, a tabela Clientes poderá incluir: Nome Próprio, Apelido, Endereço, Enviar E-mail, Saudação e Endereço de E-mail. Cada registo (cliente) na tabela contém o mesmo conjunto de colunas, pelo que armazena exatamente as mesmas informações para cada cliente.

Crie a sua primeira lista e, em seguida, reveja e otimize-a. Lembre-se de dividir as informações nos menores campos possíveis. Por exemplo, se a lista inicial tiver Endereço como um campo, divida-o em Rua, Cidade, Distrito e Código Postal ou, se os seus clientes forem multinacionais, em ainda mais campos. Desta forma, por exemplo, pode criar mailings no formato adequado ou criar relatórios sobre encomendas por distrito.

Depois de otimizar as colunas de dados em cada tabela, está pronto para escolher a chave primária de cada tabela.

Necessita de uma forma de identificar exclusivamente cada linha de cada tabela. Lembra-se do exemplo anterior em que dois clientes tinham o mesmo nome? Uma vez que têm o mesmo nome, necessita de uma forma de identificar individualmente cada um.

Por conseguinte, cada tabela deve incluir uma coluna (ou conjunto de colunas) que identifique exclusivamente cada linha. Esta forma de identificação é denominada chave primária e, normalmente, é um número exclusivo, tal como o número de ID de um funcionário ou um número de série. O Access utiliza chaves primárias para associar rapidamente dados de várias tabelas e apresentar os dados em conjunto.

Por vezes, a chave primária consiste em dois ou mais campos. Por exemplo, uma tabela Detalhes da Encomenda que armazene itens de linha para encomendas poderá utilizar duas colunas na respetiva chave primária: ID da Encomenda e ID do Produto. Quando uma chave primária utiliza mais de uma coluna também é denominada chave composta.

Se já tiver um identificador exclusivo para as informações numa tabela, como números de produtos que identificam exclusivamente cada produto no seu catálogo, utilize-o, mas apenas se os valores cumprirem as seguintes regras para chaves primárias:

• O identificador será sempre diferente para cada registo. Não são permitidos valores duplicados numa chave primária.

• Há sempre um valor para o item. Todos os registos da tabela têm de ter uma chave primária. Se estiver a utilizar várias colunas para criar a chave (como Família de Peças e Número de Peça), ambos os valores têm sempre de estar presentes.

• A chave primária é um valor que não muda. Uma vez que as chaves são referenciadas por outras tabelas, qualquer alteração a uma chave primária numa tabela significa uma alteração à mesma em qualquer local em que seja referenciada. As alterações frequentes aumentam o risco de erros.

Se não tiver um identificador óbvio, utilize um número exclusivo arbitrário como chave primária. Por exemplo, poderá atribuir a cada encomenda um número de encomenda exclusivo com o único objetivo de identificar a encomenda.