Modelagem de Dados em Microsoft Access 95

I D E O L G I C A P R O D U T I V I D A D E E M P R E S A R I A L E I N F O R M T I C A

Modelagem de Dados em Microsoft Access 95

Ideolgica Produtividade Empresarial Informtica R. Iguatemi, 252, 9 Andar Telefone (011) 883-3103 Fax (011) 853-3259

GEEK BRASIL http://www.geekbrasil.com.br

ndice Analtico
Introduo modelagem de dados 1 Por que Projetar?.................................................................................................................................................2 Problemas Resultantes de um Projeto Pobre.........................................................................................................2 Introduo ao Projeto de Banco de Dados.............................................................................................................3 Modelo Domnio/Chave........................................................................................................................................5 O Processo de Normalizao................................................................................................................................8 Um Mtodo de Projeto de Banco de Dados 9 Projeto do Modelo do Banco de Dados 11

GEEK BRASIL http://www.geekbrasil.com.br

Captulo

Introduo modelagem de dados

Aprenda os conceitos bsicos de normalizao

Um projeto de banco de dados uma matria complexa, no importando como algumas pessoas achem que seja fcil. Esta sesso apenas arranha a superfcie, mas com um belo arranho. Um banco de dados projetado de forma conveniente um modelo de uma empresa, ou de alguma outra coisa no mundo real. Como seu modelo fsico, em contrapartida, um modelo de dados permite a voc fazer perguntas sobre os fatos que compem os objetivos a serem alcanados. Estas so as perguntas que precisam de respostas e que determinaro quais fatores precisaro serem armazenados no modelo de dados. No modelo relacional, os dados so organizados em tabelas que possuem as seguintes caractersticas: Todo registro tem o mesmo nmero de fatos; Todo campo contm o mesmo tipo de fato em cada um dos registros; H apenas um ingresso para cada fato; Dois registros nunca so exatamente os mesmos; A ordem dos registros e campos no importante.

Ao final desta leitura, voc ter a compreenso bsica dos problemas resultantes de um projeto pobre de banco de dados, estar familiarizado com o Modelo Domnio/Chave, compreender o processo para se projetar um banco de dados relacional, e saber sobre as ferramentas usadas no Microsoft Access para suportar integridade coagindo num banco de dados.

Por que Projetar?

Um projeto preciso crucial para a operao de um sistema de informaes seguro e eficiente. A tecnologia dos microcomputadores atualmente to avanada que o impacto de um projeto pobre pode no se mostrar to cedo quanto no passado; todavia, quando os problemas aparecerem, eles sero severos. Um projeto de um banco de dados tem que fazer com que o caminho dos dados seja armazenado e mostrar como os dados sero relatados. Os processos do projeto so desenvolvidos depois de voc determinar exatamente quais informaes precisam ser armazenadas e como elas sero recuperadas. Quanto mais cuidadoso seu projeto, tanto melhor o banco de dados fsico se identificar com as necessidades do usurio. No processo de desenvolvimento de um sistema completo, voc precisa considerar as necessidades do usurio de vrios pontos de vista.

Problemas Resultantes de um Projeto Pobre

Diversos problemas podem se manifestar como resultado de um banco de dados mal projetado: O banco de dados adequadamente. e/ou aplicao no podem funcionar

Os dados podem no ser confiveis ou sero inexatos. A performance pode ser degradada. A flexibilidade poder ser perdida. A seo seguinte explica sobre alguns dos problemas mais comuns resultantes de um projeto de banco de dados pobre. Os problemas podem ser agrupados sob duas categorias: dados redundantes e modificaes anmalas.

Introduo ao Projeto de Banco de Dados

Considere a tabela seguinte que armazena dados sobre produtos e fornecedores. Esta aparentemente inofensiva tabela contm muitos problemas potenciais.
IDProdut Descrio o 34 27 68 42 20 21 61 46 35 Sasquatch Ale Schoggi Schokolade Scottish Longbreads Singaporean Fried Mee Sir Rodneys Marmalade Sir Rodneys Scones Sirop drable Spegesild Steeleye Stout Fornecedor Bigfoot Breweries Heli Swaren GmbH Specialty Biscuits, Ltd. Leka Trading Specialty Biscuits, Ltd. Specialty Biscuits, Ltd. Forts drables Lyngbysild Bigfoot Breweries Endereo 3400 - 8th Avenue, Suite 210 Tiergartenstrae 5 29 Kings Way 471 Serangoon Loop, 29 Kings Way 29 Kings Way 148 rue Chasseur Lyngbysild Fiskebakken 10 3400 - 8th Avenue Suite 210 Cidade Bend Berlin Manchester Singapore Manchester Manchester SteHyacinthe Lyngby Bend OR Qubec Regio OR Pas USA Germany UK Singapore UK UK Canada Denmark USA

Suponhamos que voc deseje adicionar outro registro

37 Lumbermans Lager Bigfoot Breweries 3400 - 8th Avenue Suite 210 Bend OR USA

O espao em disco perdido por duplicao dos dados sobre o fornecedor. Toda vez que um novo produto registrado para um fornecedor em particular, todos os dados sobre este fornecedor tem de ser repetidos. Imagine o problema se diversos fornecedores fornecem centenas de produtos cada um.

Modificaes Anmalas

O que acontece se o fornecedor Bigfoot Breweries se muda para Portland? Quantos campos tero de ser modificados para se assegurar que o novo endereo foi registrado?
IDProdut Descrio o 34 27 68 42 Sasquatch Ale Schoggi Schokolade Scottish Longbreads Singaporean Fried Mee Fornecedor Bigfoot Breweries Endereo 3400 - 8th Avenue Suite 210 29 Kings Way 471 Serangoon Loop, Cidade Bend Berlin Manchester Singapore Regio OR Pas USA Germany UK Singapore

Heli Swaren GmbH Tiergartenstrae 5 Specialty Biscuits, Ltd. Leka Trading

37 20 21 61 46 35

Lumbermans Lager Sir Rodneys Marmalade Sir Rodneys Scones Sirop drable Spegesild Steeleye Stout

Bigfoot Breweries Specialty Biscuits, Ltd. Specialty Biscuits, Ltd. Forts drables Lyngbysild Bigfoot Breweries

3400 - 8th Avenue Suite 210 29 Kings Way 29 Kings Way 148 rue Chasseur

Bend Manchester Manchester SteHyacinthe Bend

OR

USA UK UK

Qubec

Canada Denmark

Lyngbysild Fiskebakken 10 Lyngby 3400 - 8th Avenue Suite 210 OR

USA

Novamente, imagine o que pode resultar da modificao de centenas de campos de dados para apenas um fornecedor. Quando modificaes so feitas, elas devero abranger todas as cpias dos dados. Pense a respeito da confuso que resulta de modificar apenas um subgrupo de um dado duplicado.

Excluses Anmalas

Suponhamos que voc no trabalhou por muito tempo com o produto 42 e decidiu eliminar esta linha de dados de sua tabela?
IDProdut o 34 27 68 42 20 21 61 46 35 Descrio Sasquatch Ale Schoggi Schokolade Scottish Longbreads Fornecedor Bigfoot Breweries Endereo 3400 - 8th Avenue Suite 210 29 Kings Way 471 Serangoon Loop, 29 Kings Way 29 Kings Way 148 rue Chasseur Lyngbysild Fiskebakken 10 3400 - 8th Avenue Suite 210 Cidade Bend Berlin Manchester Singapore Manchester Manchester SteHyacinthe Lyngby Bend OR Qubec Regio OR Pas USA Germany UK Singapore UK UK Canada Denmark USA

Heli Swaren GmbH Tiergartenstrae 5 Specialty Biscuits, Ltd. Specialty Biscuits, Ltd. Specialty Biscuits, Ltd. Forts drables Lyngbysild Bigfoot Breweries

Singaporean Fried Mee Leka Trading Sir Rodneys Marmalade Sir Rodneys Scones Sirop drable Spegesild Steeleye Stout

Agora, observando os dados restantes, onde est o endereo do fornecedor Leka Trading?
IDProduto 34 27 68 20 Descrio Sasquatch Ale Schoggi Schokolade Scottish Longbreads Sir Rodneys Marmalade Fornecedor Bigfoot Breweries Endereo 3400 - 8th Avenue Suite 210 Cidade Bend Berlin Manchester Manchester Regio OR Pas USA German y UK UK

Heli Swaren GmbH Tiergartenstrae 5 Specialty Biscuits, Ltd. Specialty Biscuits, Ltd. 29 Kings Way 29 Kings Way

21 61 46 35

Sir Rodneys Scones Sirop drable Spegesild Steeleye Stout

Specialty Biscuits, Ltd. Forts drables Lyngbysild Bigfoot Breweries

29 Kings Way 148 rue Chasseur Lyngbysild Fiskebakken 10 3400 - 8th Avenue Suite 210

Manchester SteHyacinthe Lyngby Bend OR Qubec

UK Canada Denmar k USA

Uma excluso anmala faz com que percamos mais informaes do que o necessrio. Ns perdemos dados sobre mais de um assunto a cada excluso.

Insero Anmala

Agora voc precisa adicionar um novo fornecedor, StarStruck, mas voc ainda no tem encomendado nenhum produto deste fornecedor. O que voc adicionar?
IDProdut o 34 27 68 42 20 21 61 46 35 ??? Descrio Sasquatch Ale Schoggi Schokolade Scottish Longbreads Fornecedor Bigfoot Breweries Endereo 3400 - 8th Avenue Suite 210 29 Kings Way 471 Serangoon Loop, 29 Kings Way 29 Kings Way 148 rue Chasseur Lyngbysild Fiskebakken 10 3400 - 8th Avenue Suite 210 101 Mariposa Cidade Bend Berlin Manchester Singapore Manchester Manchester SteHyacinthe Lyngby Bend Seattle OR WA Qubec Regio OR Pas USA Germany UK Singapore UK UK Canada Denmark USA USA

Heli Swaren GmbH Tiergartenstrae 5 Specialty Biscuits, Ltd. Specialty Biscuits, Ltd. Specialty Biscuits, Ltd. Forts drables Lyngbysild Bigfoot Breweries StarStruck, Inc.

Singaporean Fried Mee Leka Trading Sir Rodneys Marmalade Sir Rodneys Scones Sirop drable Spegesild Steeleye Stout ??????

Esta situao chamada de insero anmala. No podemos adicionar um dado sobre um assunto at que ns tenhamos dados adicionais sobre outro assunto.

Modelo Domnio/Chave
Teorias relacionais tm classificado os esquemas de banco de dados que tm inconsistncias, baseando-se nas anomalias a qual eles so suscetveis . Voc pode ter encontrado discusses sobre diferentes formas. Uma das nicas normalizaes foi propostas por R. Fagin, em 1981, e usada como a base desta apresentao. Fagin apurou que se as tabelas em seu banco de dados esto no Modelo Domnio/Chave, ento eles esto livres de modificaes anormais .

Para compreender este modelo a esto quatro termos que devem ser compreendidos: dependncia, chave, domnio e restrio .

Dependncia

Uma dependncia uma relao que pode existir entre duas colunas . Dados os valores da primeira coluna , voc estar apto para determinar o valor de uma outra. Vamos usar a tabela dos exemplos anteriores. Dados o nmero do produto, ns estaremos capazes de determinar as descries dos produtos. Esta uma dependncia: descries so dependncias nos nmeros dos produtos. Dados um nome de fornecedor, seremos ns capazes de determinar a descrio do produto? No necessariamente . No caso do BigFoot Breweries, este fornecedor tem um nmero de produtos associados a ele. Portanto , nas tabelas acima, descrio no uma dependncia de fornecedores. Para detectar uma dependncia, pergunte a si mesmo o seguinte: Nesta tabela, pode o valor de uma coluna determinar TODOS OS VALORES POSSVEIS de outra coluna?

IDProduto Fornecedor Fornecedor

determina Descrio? determina Endereo? determina IDProduto?

SIM SIM NO

Chave

A maior parte das tabelas deve ter uma coluna ou uma combinao de colunas que unicamente identifique uma linha de dados. Uma coluna chave se todas as outras colunas numa linha de dados so dependentes dela. A primeira olhada, pode parecer que a coluna IDProduto em nosso exemplo unicamente identifica uma linha de dados. Mas IDProduto 34 identifica o fornecedor como BigFoot Breweries, que tambm faz parte dos nmeros 35 e 37. Portanto, a coluna IDProduto no uma chave. Nesta tabela, ns temos uma chave complexa, derivada de IDProduto, Descrio, e Fornecedor.

Domnio

Um domnio o conjunto de valores que uma coluna pode ter. Toda coluna tem um domnio que tem, por sua vez, as propriedades lgicas e fsicas. Descrio Fsica. A parte fsica do domnio o tipo de informao sobre cada coluna. Em nosso exemplo, Fornecedor definido como TEXTO 40. A partir desta definio, a descrio fsica do domnio o conjunto de valores de dados de TEXTO com 40 caracteres ou menos. Similarmente, a descrio fsica para o domnio de IDProduto expressa como INTEIRO. Isto resulta em dados com nove nmeros ou menos. Descrio Lgica. A parte lgica do domnio o conjunto de informaes associadas com os fatos. Os endereos dos fornecedores no esto no mesmo domnio dos endereos dos clientes, apesar deles terem a mesma propriedade fsica de TEXTO 60.

Considere o valor 7124 E. 41st Place. Este um valor no domnio de endereos de fornecedores? Para estar neste domnio ele precisa ter menos de 60 caracteres e ser um endereo de fornecedor.

Restrio

Uma restrio uma limitao de algum tipo nos valores da tabela. Uma dependncia um tipo de restrio. Especificar que a Descrio dependente de IDProduto uma restrio. Chaves so um tipo de restrio. Quando uma coluna uma chave, significa que todas as outras colunas na tabela so dependentes dela. Lembre-se que uma chave pode ser uma combinao de colunas. Um domnio outro tipo de restrio. Quando definimos as propriedades lgica e fsica de uma coluna, ns restringimos os dados que ela poder armazenar. Restrio um termo geral. Existem muitas maneiras de restringir os dados numa tabela. Abaixo esto alguns exemplos: Especificar que as datas devero ser formatadas como DD/MM/AA. IDProduto precisa iniciar a partir do nmero 100. Fornecedores precisam ser TEXTO com 40 caracteres ou menos. Taxa Total precisa ser MOEDA com valores entre $1,00 e $9.999.999,99.

O Processo de Normalizao
Normalizar o banco de dados garante que a estrutura permitir as mudanas a serem feitas sem que ocorram conseqncias inesperadas. O papel da normalizao manter estvel, e com dados confiveis, o banco de dados, atravs de um bom projeto. O objetivo de um bom projeto de banco de dados assegurar que todas as restries sejam conseqncias lgicas das restries de domnio e chave. Tabelas, como pargrafos, devem ter um s tema. A tabela nos exemplos de anomalias teve dois temas: Informaes sobre os produtos. Informaes sobre os fornecedores dos produtos. A maneira de administrar esta informao mais eficientemente dividir a tabela em duas: uma tabela de produtos e uma tabela de fornecedores.
Produtos
IDProdu Descrio to 34 27 68 42 20 21 61 46 35 Sasquatch Ale Schoggi Schokolade Scottish Longbreads Singaporean Hokkien Fried Mee Sir Rodneys Marmalade Sir Rodneys Scones Sirop drable Spegesild Steeleye Stout Fornecedor Bigfoot Breweries Heli Swaren GmbH & Co. KG Specialty Biscuits, Ltd. Leka Trading Specialty Biscuits, Ltd. Specialty Biscuits, Ltd. Forts drables Lyngbysild Bigfoot Breweries

Fornecedores
Fornecedor
Bigfoot Breweries Heli Swaren GmbH & Co. KG Specialty Biscuits, Ltd. Leka Trading Forts drables Lyngbysild

Endereo
3400 - 8th Avenue Suite 210 Tiergartenstrae 5 29 Kings Way 471 Serangoon Loop, Suite #402 148 rue Chasseur

Cidade
Bend Berlin Manchester Singapore Ste-Hyacinthe

Regi o
OR

Pas
USA German y UK Singapo re

Qubec Canada Denmar k

Lyngbysild Fiskebakken 10 Lyngby

Agora voc pode adicionar produtos sem duplicaes, modificar a localizao de fornecedores sem alterar vrias linhas de dados, e no perder informaes se voc excluir uma parte realmente no necessria. Se voc desejar, poder sempre trazer de volta a tabela original usando uma pergunta em associao a Fornecedor.

Um Mtodo de Projeto de Banco de Dados

Assim como voc viu, o projeto de banco de dados desempenha o maior papel na estabilidade e confiana de seus dados. Nesta seo, ns mostraremos a voc o processo de projetar um banco de dados. Para ajudar a ilustrar este processo, um banco de dados chamado Zipper ser criado para um fictcio atacadista e fabricante de roupas chamado Zipper. Apesar de existirem vrias regras que devero ser seguidas no projeto da estrutura do banco de dados, o processo de projeto muito mais uma arte que uma cincia. Siga estas regras sempre que possvel, mas no at o ponto de perder a funcionalidade que to importante ao usurio. Fazer o projeto do banco de dados primeiramente no papel traz diversas vantagens: Economiza dinheiro, tempo e sanidade; Torna o sistema mais seguro; evita potenciais problemas com modificaes de dados; Serve de planta para discusses; Ajuda a estimar custos e tamanho.

Um bom projeto dever ter os seguintes objetivos: Ir ao encontro a necessidade dos usurios Solucionar o problema Ser livre de modificaes anmalas Ter um confivel e estvel banco de dados, onde as tabelas sejam to independentes quanto possvel

Ser fcil de usar

Projeto do Modelo do Banco de Dados

O projeto da estrutura do banco de dados necessita dos seguintes passos: 1. 2. 3. 4. 5. 6. 7. 8. Relacione os objetos. Liste os fatores relacionados aos objetos. Transforme os objetos e fatores em tabelas e colunas. Determine as relaes entre os objetos. Determine as chaves das colunas. Determine as colunas relacionadas. Determine as relaes de reserva. Avalie o modelo projetado.

9. Desenvolva o banco de dados.

Passo 1: Relacione os objetos

Faa uma lista de todos os objetos. Um objeto um tema nico, similar a um pargrafo. Na Zipper os objetos so:

Cliente Produto Funcionrio

Taxa de Embarque Fatura Dependente

Passo 2: Liste os fatores relacionados aos objetos

Aqui est o grande negcio da informao associada a cada objeto. Neste passo, voc deve listar os fatos sobre cada objeto e ento eliminar os fatos que no so importantes para a soluo do problema. O objeto cliente, por exemplo, pode ter muitos fatos associados a ele: nome da companhia, endereo, cidade, fundadores, nmero de funcionrios, preo das aes. Neste caso, no importante manter informaes sobre o nmero de funcionrios, preo das aes, ou fundadores. A Zipper precisa somente das informaes que ir usar agora ou que possivelmente ir usar no futuro.
Objeto Funcionrio Cliente Fatura Produto Dependente Taxa de Embarque Fatores Importantes Sobre o Objeto funcionrio, nome, data de nascimento, sexo, estado civil nome da companhia, endereo, cidade, estado, CEP, contato data, vendedor, cliente, quantidade, despesa de transporte, taxas, fretes nome do produto, descrio, custo, remarcao de preos nome, data de nascimento estado , taxas

Passo 3: Transforme os objetos e fatores em tabelas e colunas

Objetos automaticamente iro tornar-se tabelas, e fatos iro tornar-se colunas assim que seus domnios sejam determinados. Recorde que um domnio um conjunto de valores que a coluna pode ter. Toda coluna tem um domnio, que tem propriedades lgica e fsica. Por exemplo, a coluna para ltimo nome dos funcionrios definida como TEXTO 15. TEXTO

15 a propriedade fsica da coluna. A partir desta definio, o domnio o conjunto de todos os ltimos nomes de todos os empregados com 15 caracteres ou menos. Se uma coluna usada para conectar duas ou mais tabelas, o domnio precisa ser o mesmo e as colunas devem ter o mesmo nome. Se a descrio lgica diferir (por exemplo, ltimo nome do funcionrio e ltimo nome do cliente), as colunas no so as mesmas e no devem partilhar o mesmo nome. A seguir se encontra uma lista das tabelas preliminares, colunas e domnios para a Zipper:

Tabela: CLIENTE Nome COMPANY CADD1 CADD2 CCITY CSTATE CZIP CAC CTELPH CONTACT TITLE

Tabela: PRODUTO Tipo TEXTO TEXTO TEXTO TEXTO TEXTO TEXTO TEXTO TEXTO TEXTO TEXTO Compr 45 30 30 25 2 10 3 7 30 30 Tabela: DEPENDENTE Nome Tipo DLAST DFIRST DDOB TEXTO TEXTO D/H Compr 15 10 Nome PRODNAME PRODDESC PRODCOST PMARKUP Tipo TEXTO TEXTO MOEDA NM Compr 30 50

Tabela: FATURA Nome INVDATE REQDATE SHIPNAME SHIPADDR SHIPCITY SHIPZIP INVTOTAL Tipo D/H D/H TEXTO TEXTO TEXTO TEXTO MOEDA 45 30 25 10 Compr

Tabela: FUNCIONRIO Nome ESSN ELASTN EFIRSTN EDOB EGENDER EMARITAL EADDR1 EADDR2 Tipo TEXTO TEXTO TEXTO D/H TEXTO TEXTO TEXTO TEXTO 1 1 30 20 Compr 11 15 10

ECITY Tabela: TAXA DE EMBARQUE Nome Tipo Compr SHIPST SHIPRATE TEXTO NM 2 ESTATE EZIP EAC EHOMEPH

TEXTO TEXTO TEXTO TEXTO TEXTO

25 2 10 3 7

Freqentemente uma ajuda no estgio de projeto desenhar caixas representando as tabelas. Em passos posteriores voc poder ento preencher as colunas chave e desenhar as relaes entre as tabelas.

CLIENTE

PRODUTO

FUNCIONRIO

FATURA

DEPENDENTE

TAXA DE EMBARQUE

Passo 4: Determine as relaes entre objetos

Para determinar as relaes entre os objetos, pegue um objeto e olhe como este objeto pode se relacionar com outro. Mantenha em mente que nem toda relao existente entre objetos importante. As relaes que so importantes so aquelas que permitem a voc modelar o banco de dados de maneira a corresponder s situaes do mundo real que ele representa. Relaes um-para-um. Para qualquer linha de dados na tabela A, existe uma nica linha na tabela B. Para qualquer linha de dados na tabela B, existe uma nica linha na tabela A. No existe nenhum relacionamento um-para-um no banco de dados da Zipper. Um exemplo de uma relao um-para-um aquela que abrange dados sobre o funcionrio e dados pessoais sobre o funcionrio. Informaes gerais, como nome do funcionrio, endereo, data de contratao, so mantidas em uma tabela,

e para manter privacidade, informaes pessoais, como salrio, so mantidas em outra tabela. Relaes um-para-vrios. Para qualquer linha de dados na tabela A, existem vrias linhas na tabela B. Para qualquer linha de dados na tabela B, existe uma nica linha na tabela A. As relaes entre funcionrios e seus dependentes um-para-vrios, porque um funcionrio pode ter muitos dependentes, mas um dependente relacionado a apenas um funcionrio. A relao entre clientes e faturas tambm um-para-vrios. Uma fatura relacionada a um cliente, mas um cliente pode ter vrias faturas.

Relaes vrios-para-vrios. Para qualquer linha de dados na tabela A, existem vrias linhas na tabela B. Para qualquer linha de dados na tabela B, existem vrias linhas na tabela A. Existe uma relao vrios-para-vrios entre a tabela de produtos e a tabela de faturas. Um produto pode ser associado a diferentes faturas e uma fatura pode conter vrios produtos diferentes. No caso do banco de dados Zipper, ns estamos tentando modelar um ambiente que baseado em transaes de vendas. Pegue o exemplo de produtos e clientes: Apesar de em algumas circunstncias ns podermos nos interessar nas relaes entre clientes e produtos, nas transaes de vendas, o cliente relacionado a um produto somente quando uma venda ocorre. Portanto, um cliente relacionado a uma fatura, e uma fatura carrega a relao a um produto. O primeiro passo na determinao do tipo de relacionamento entre tabelas listar todas as tabelas e verificar como cada uma se relaciona com todas as outras: Cliente relacionado fatura. Cliente no relacionado a nenhuma outra tabela na lista. Funcionrio relacionado a dependente. Funcionrio (vendas) relacionado a fatura. Produto relacionado a fatura. Um mtodo eficaz de encontrar o tipo de relacionamento perguntar se um determinado registro na tabela A pode apontar para ( relacionado a) uma ou mais linhas de dados na tabela B, e em seguida inverter as tabelas e fazer a pergunta novamente.

Um registro de cliente aponta para uma ou vrias faturas? Vrias Uma linha de dados de fatura se liga a um ou vrios clientes? A relao entre as tabelas um-para-vrios. Um

Um funcionrio de vendas registra uma ou vrias faturas? Uma fatura registrada por um ou vrios funcionrios? A relao entre funcionrio e fatura tambm um-para-vrios.

Vrias Um

 Um produto pode ser um item listado em uma ou vrias faturas? Vrias Uma fatura pode se relacionar a um ou vrios produtos? A relao entre produto e fatura vrios-para-vrios. Vrios

A tabela Taxa de Embarque ilustra a idia de que uma tabela pode ser includa num banco de dados no precisando de relacionamentos com qualquer outra tabela.

Passo 5: Determine as chaves das colunas

Uma chave pode ser um nmero de conta, nmero de seguridade social, nmero de licena, ou qualquer outro valor numrico ou combinao de caracteres que seja nico. Uma chave complexa aquela que se deriva de mais de uma coluna. O Microsoft Access suporta chaves complexas diretamente. Nenhuma outra linha na tabela pode ter o valor da(s) coluna(s) chave. As outras tabelas podem compartilhar do mesmo conjunto de informaes chave. Se o nome de uma companhia universalmente nico, ele usado como linha nica e identificadora. Porm, se existe a possibilidade de outra companhia ter o mesmo nome, ento ele no nico e no dever ser empregada como coluna chave. No use qualquer coluna como chave se existe a possibilidade de duplicidade. Uma coluna chave no pode conter valores nulos. Por definio, todas as colunas chave devero ser indexadas. Como normalmente os textos de nomes no so nicos e no podem ser usados em operaes matemticas, costumeiro fazer com que as colunas chave assumam um valor numrico seqencial. Em muitos casos, mais fcil voc desenvolver sua prpria linha de dados, nica e identificadora. Se voc necessita de uma numerao automtica para nmeros de faturas ou nmeros de funcionrios, o tipo de dado CONTADOR no Microsoft Access uma boa escolha para a descrio fsica do domnio da coluna chave. A maior parte das tabelas ao final do projeto do banco de dados Zipper contm colunas com o tipo de dados CONTADOR ou NMERO para exercerem a funo de linhas identificadoras e nicas. Cada chave tambm indexada, e duplicatas no so permitidas. A performance do banco de dados acentuada com uma simples coluna numrica como chave.

CLIENTE A chave CUSTID (CONTADOR). COMPANY pode no ser nica. FUNCIONRIO A chave EMPID (CONTADOR). Poderia ser usada ESSN mas TEXTO. DEPENDENTE Chave complexa. Todas as colunas.

PRODUTO A chave PRODID (CONTADOR). PDESCRIP pode no ser nica. FATURA A chave INVID (CONTADOR)

TAXA DE EMBARQUE Chave complexa. Todas as colunas.

Passo 6: Determine as colunas relacionadas

Se voc foi cuidadoso na determinao das colunas chave, tambm deve ter determinado as colunas relacionadas. Relaes fornecem uma maneira de vincular informaes (linhas de dados) entre tabelas. Se uma tabela tem uma coluna chave, esta coluna pode geralmente servir como elo num vnculo. Tabelas so vinculadas atravs de suas colunas chave. Porm, a colocao da chave importante, e onde o elo ser colocado depender do tipo de relao entre as tabelas. Para determinar a colocao dos elos, voc dever inicialmente conhecer o tipo de relacionamento entre os objetos ou tabelas. Uma vez que voc conhea o tipo de relacionamento entre tabelas, muito mais fcil determinar onde colocar os elos para vincul-las. Lembre-se que nem todas as tabelas precisam ser relacionadas. Funcionrios precisam ser vinculados a dependentes, mas voc no gostaria de relacionar funcionrios com taxas de embarque ou produtos. Vinculando numa relao um-para-um. Numa relao um-para-um o elo deve ser a coluna mais estvel ou deve vir da tabela onde a coluna chave foi criada. A coluna mais estvel aquela que possui a menor parcela de chances de que venha a sofrer modificaes. Se algum sistema de numerao automtica est sendo usado, ento use esta coluna como elo. Vinculando numa relao um-para-vrios. Na relao um-para-vrios a coluna elo deve vir da tabela um. A coluna chave da tabela funcionrio (lado um) deve ser colocada na tabela dependente (lado vrios). Quando a chave empid colocada na tabela dependente, ela referida como uma chave estrangeira na tabela.

Vinculando numa relao vrios-para-vrios. A relao vrios-paravrios causa problemas quando tenta recuperar dados e quando relata um valor em uma tabela para seu valor correspondente em outra. importante compreender esta relao para ser capaz de reconhecer e controlar esta situao quando ela surgir. Uma clssica relao vrios-para-vrios a que existe entre produto e fatura. Um determinado produto pode ter um item citado em vrias faturas diferentes e uma fatura pode ter muitos produtos associados a ela. Mas qual chave iremos usar como elo? Se invid for colocado na tabela produto, ento todos os dados sobre os produtos tero de ser repetidos para cada fatura que contm aquele produto. Se prodid for colocado na tabela fatura, as informaes sobre a fatura devero ser repetidas para cada produto contido na fatura. Isto leva a dados redundantes, e o potencial para dados invlidos aumenta. A performance pode ser avariada. A soluo para relaes vrios-para-vrios criar tabelas intermedirias. Esta tabela deve conter as colunas chave de ambas as tabelas principais. Isto ilustrado pelo diagrama seguinte.
CLIENTE A chave CUSTID (CONTADOR). COMPANY pode no ser nica. INVOICE A chave INVID (CONTADOR) FUNCIONRIO A chave EMPID (CONTADOR). Poderia ser usada ESSN mas TEXTO. DEPENDENTE Chave complexa. Todas as colunas. TRANSAO Complex key. PRODID and INVID. PRODUTO A chave PRODID (CONTADOR). PDESCRIP pode no ser nica.

TAXA DE EMBARQUE Chave complexa. Todas as colunas.

Passo 7: Determine as relaes de reserva

Muitas vezes as informaes que ns recuperamos de um banco de dados vem de mais de uma tabela. Por exemplo, se ns quisermos saber qual o pai ou me de um dependente em particular, o nome determinado usando o valor de empid para procurar a linha com o valor correto na tabela funcionrio. A questo de quem o pai ou me poder ser

respondida somente se existir uma linha na tabela funcionrios com um valor correspondente em empid da tabela dependente. Para assegurar a integridade dos dados em nosso banco de dados, nosso modelo deve requerer, por exemplo, que nenhuma linha possa ser adicionada tabela dependente, sem que exista linha correspondente na tabela funcionrio. Este requisito conhecido como relao de reserva. Neste caso, deve existir uma reserva na tabela dependente que assegure que o funcionrio (pai ou me) exista. Se voc est criando uma fatura, voc deve ter um cliente para mandar a conta. Um registro na tabela cliente deve existir antes que a fatura possa ser redigida. Neste caso, uma reserva deve existir na tabela fatura para assegurar que o cliente existe. A esto, por menores que sejam, quatro mtodos para implementar relaes de reserva: Construo de controles em DBMS Entrada de dados e procedimentos de acesso Programao Implementao de regras

O Microsoft Access tem certos mecanismos de integridade referencial construdos em seus motores. Com o Microsoft FoxPro, a relao de reserva dever ser criada a partir de programao. No Microsoft Access, regras podem ser empregadas para impor o domnio de colunas (por exemplo, aceitar valores menores que 200, ou valores de texto devero ser F ou M) ou em qualquer outra operao onde voc necessite de um teste nos dados a serem registrados.

Passo 8: Avalie o modelo projetado

O prximo passo no processo de projeto a avaliao do projeto. Neste passo, voc dever procurar por todas as falhas que podem vir a causar dados irrecuperveis, instveis ou redundantes. Cada tabela dever ser avaliada respondendo-se as seguintes questes: 1. 2. Cada tabela possui um tema nico? Assim deve ser. Cada coluna dever ser um fato sobre a chave. Cada tabela tem sua(s) coluna(s) chave? Assim deve ser.

3. 4. 5. 6.

Existem dependncias? Somente conseqncias lgicas da chave devem existir. So os domnios nicos entre as tabelas? No misture domnios a menos que a coluna seja comum entre tabelas. Existe domnio de restrio ou chave? A tabela fcil de usar?

Avaliao da Tabela Cliente CUSTID COMPANY CADD1 CADD2 CCITY CSTATE CZIP CAC CTELPH CONTACT TITLE

A tabela tem um nico tema: clientes. A tabela tem uma chave: custid. A tabela no tem nenhuma dependncia que no seja conseqncia lgica da chave. Dado custid, uma companhia e endereo da companhia podem ser determinados unicamente. Dada uma companhia, ns no podemos determinar nenhum custid em particular. Dada um estado, ns no podemos determinar nenhum custid em particular. Portanto, a tabela cliente no tem nenhuma dependncia. O nome das colunas no usado em nenhuma outra tabela, exceto custid que uma chave estrangeira na tabela fatura. As restries so domnio ou chave.

Passo 9: Desenvolva o banco de dados

Uma vez que o banco de dados tenha sido projetado no papel, o prximo passo desenvolver o banco de dados no Microsoft Access. Quando definir tabelas no Microsoft Access, extremamente importante manter seu projeto de papel em mente. Desenvolver um banco de dados sem parmetros pode causar problemas que podem ser difceis de desfazer. (Lembre-se das anomalias anteriormente descritas.) No Microsoft Access 2.0, existem duas ferramentas que o ajudaro a completar a implementao de seu projeto. O Assistente de The Table Tabelas pode ser usado para gerar uma variedade de tabelas comuns. A janela de sistema grfico de relaes pode ser usada para criar relacionamentos e dependncias chave. Perceba que, enquanto usar o Assistente de Tabelas assegura um desenvolvimento relacional eficaz, os

oito passos anteriores para implementao permanecem importantes e devem ser completados antes da construo das tabelas.

A seguir est uma lista das tabelas finais, colunas e domnios para a Zipper, incluindo colunas elo:
Tabela: CLIENTE Nome CUSTID COMPANY CADD1 CADD2 CCITY CSTATE CZIP CAC CTELPH CONTACT TITLE Tipo CONTADOR TEXTO TEXTO TEXTO TEXTO TEXTO TEXTO TEXTO TEXTO TEXTO TEXTO 45 30 30 25 2 10 3 7 30 30 Tabela: TAXA DE EMBARQUE Nome Tipo Compr SHIPST SHIPRATE TEXTO NM 2 Comp r Tabela: PRODUTO Nome PRODID PNOME PDESCRIP PCOST PMARKUP Tipo CONTADOR TEXTO TEXTO MOEDA NM 30 50 Compr

Tabela: FATURA Nome INVID CUSTID INVDATE REQDATE SHIPNOME SHIPADDR SHIPCITY SHIPST SHIPZIP INVTOTAL Tipo CONTADOR NM D/H D/H TEXTO TEXTO TEXTO TEXTO TEXTO MOEDA 45 30 25 2 10 Comp r Nome INVID

Tabela: TRANSAO Tipo NM NM NM NM MOEDA Compr

PRODID TQTY TDISC TPRICE

Tabela: FUNCIONRIO Nome EMPID ESSN ELASTN EFIRSTN EDOB EGENDER 1EMARITAL EADDR1 EADDR2 ECITY ESTATE EZIP EAC EHOMEPH Tipo CONTADOR TEXTO TEXTO TEXTO D/H TEXTO TEXTO TEXTO TEXTO TEXTO TEXTO TEXTO TEXTO TEXTO 1 1 30 20 25 2 10 3 7 11 15 10 Compr

Tabela: DEPENDENTE Nome EMPID DLAST DFIRST DDOB Tipo NM TEXTO TEXTO D/H 15 10 Compr