0

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
Por que Projetar?
Problemas Resultantes de um Projeto Pobre
Introduo ao Projeto de Banco de Dados
Modelo Domnio/Chave
O Processo de Normalizao

1
2
2
3
5
7

Um Mtodo de Projeto de Banco de Dados 8

Projeto do Modelo do Banco de Dados

ii

Introduo modelagem de
dados
Aprenda os conceitos bsicos de
normalizao

Captulo

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

Fornecedor

Endereo

Cidade

Regio

Pas

OR

USA

34

Sasquatch Ale

Bigfoot Breweries

3400 - 8th Avenue,

Suite 210

Bend

27

Schoggi Schokolade

Heli Swaren
GmbH

Tiergartenstrae 5

Berlin

Germany

68

Scottish Longbreads

Specialty Biscuits,
Ltd.

29 Kings Way

Manchester

UK

42

Singaporean Fried
Mee

Leka Trading

471 Serangoon Loop,

Singapore

Singapore

20

Sir Rodneys
Marmalade

Specialty Biscuits,
Ltd.

29 Kings Way

Manchester

UK

21

Sir Rodneys Scones

Specialty Biscuits,
Ltd.

29 Kings Way

Manchester

UK

61

Sirop drable

Forts drables

148 rue Chasseur

SteHyacinthe

46

Spegesild

Lyngbysild

Lyngbysild Fiskebakken
10

Lyngby

35

Steeleye Stout

Bigfoot Breweries

3400 - 8th Avenue Suite

210

Bend

Qubec

Canada
Denmark

OR

USA

OR

USA

Suponhamos que voc deseje adicionar outro registro

37

Lumbermans Lager

Bigfoot Breweries

3400 - 8th Avenue Suite

210

Bend

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

Fornecedor

Endereo

Cidade

Regio

Pas

OR

USA

34

Sasquatch Ale

Bigfoot Breweries

3400 - 8th Avenue Suite

210

Bend

27

Schoggi Schokolade

Heli Swaren
GmbH

Tiergartenstrae 5

Berlin

Germany

68

Scottish Longbreads

Specialty Biscuits,
Ltd.

29 Kings Way

Manchester

UK

42

Singaporean Fried

Leka Trading

471 Serangoon Loop,

Singapore

Singapor

Mee

37

Lumbermans Lager

Bigfoot Breweries

3400 - 8th Avenue Suite

210

Bend

20

Sir Rodneys
Marmalade

Specialty Biscuits,
Ltd.

29 Kings Way

Manchester

UK

21

Sir Rodneys Scones

Specialty Biscuits,
Ltd.

29 Kings Way

Manchester

UK

61

Sirop drable

Forts drables

148 rue Chasseur

SteHyacinthe

46

Spegesild

Lyngbysild

Lyngbysild Fiskebakken 10 Lyngby

35

Steeleye Stout

Bigfoot Breweries

3400 - 8th Avenue Suite

210

Bend

OR

Qubec

USA

Canada
Denmark

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

Descrio

Fornecedor

Endereo

Cidade

Regio
OR

Pas

34

Sasquatch Ale

Bigfoot Breweries

3400 - 8th Avenue

Suite 210

Bend

27

Schoggi Schokolade

Heli Swaren
GmbH

Tiergartenstrae 5

Berlin

Germany

68

Scottish Longbreads

Specialty Biscuits,
Ltd.

29 Kings Way

Manchester

UK

42

Singaporean Fried
Mee

Leka Trading

471 Serangoon Loop,

Singapore

Singapor
e

20

Sir Rodneys
Marmalade

Specialty Biscuits,
Ltd.

29 Kings Way

Manchester

UK

21

Sir Rodneys Scones

Specialty Biscuits,
Ltd.

29 Kings Way

Manchester

UK

61

Sirop drable

Forts drables

148 rue Chasseur

SteHyacinthe

46

Spegesild

Lyngbysild

Lyngbysild Fiskebakken
10

Lyngby

35

Steeleye Stout

Bigfoot Breweries

3400 - 8th Avenue Suite

210

Bend

Qubec

USA

Canada
Denmark

OR

USA

Agora, observando os dados restantes, onde est o endereo do

fornecedor Leka Trading?

IDProdut
o

Descrio

Fornecedor

Endereo

Cidade

Regio
OR

Pas

34

Sasquatch Ale

Bigfoot Breweries

3400 - 8th Avenue Suite

210

Bend

27

Schoggi Schokolade

Heli Swaren
GmbH

Tiergartenstrae 5

Berlin

German
y

68

Scottish Longbreads

Specialty Biscuits,
Ltd.

29 Kings Way

Manchester

UK

20

Sir Rodneys
Marmalade

Specialty Biscuits,
Ltd.

29 Kings Way

Manchester

UK

21

Sir Rodneys Scones

Specialty Biscuits,
Ltd.

29 Kings Way

Manchester

UK

61

Sirop drable

Forts drables

148 rue Chasseur

SteHyacinthe

46

Spegesild

Lyngbysild

Lyngbysild Fiskebakken
10

Lyngby

35

Steeleye Stout

Bigfoot Breweries

3400 - 8th Avenue Suite

210

Bend

Qubec

USA

Canada
Denmar
k

OR

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

Descrio

Fornecedor

Endereo

Cidade

Regio
OR

Pas

34

Sasquatch Ale

Bigfoot Breweries

3400 - 8th Avenue Suite

210

Bend

27

Schoggi Schokolade

Heli Swaren
GmbH

Tiergartenstrae 5

Berlin

Germany

68

Scottish Longbreads

Specialty Biscuits,
Ltd.

29 Kings Way

Manchester

UK

42

Singaporean Fried Mee Leka Trading

471 Serangoon Loop,

Singapore

Singapore

20

Sir Rodneys
Marmalade

Specialty Biscuits,
Ltd.

29 Kings Way

Manchester

UK

21

Sir Rodneys Scones

Specialty Biscuits,
Ltd.

29 Kings Way

Manchester

UK

61

Sirop drable

Forts drables

148 rue Chasseur

SteHyacinthe

46

Spegesild

Lyngbysild

Lyngbysild Fiskebakken
10

Lyngby

35

Steeleye Stout

Bigfoot Breweries

3400 - 8th Avenue Suite

210

Bend

OR

USA

???

??????

StarStruck, Inc.

101 Mariposa

Seattle

WA

USA

Qubec

USA

Canada
Denmark

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

determina Descrio?

SIM

Fornecedor

determina Endereo?

SIM

Fornecedor

determina IDProduto?

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

Fornecedor

34

Sasquatch Ale

Bigfoot Breweries

27

Schoggi Schokolade

Heli Swaren GmbH & Co. KG

68

Scottish Longbreads

Specialty Biscuits, Ltd.

42

Singaporean Hokkien Fried Mee

Leka Trading

20

Sir Rodneys Marmalade

Specialty Biscuits, Ltd.

21

Sir Rodneys Scones

Specialty Biscuits, Ltd.

61

Sirop drable

Forts drables

46

Spegesild

Lyngbysild

35

Steeleye Stout

Bigfoot Breweries

Fornecedores
Fornecedor

Endereo

Cidade

Regi
o

Pas

Bigfoot Breweries

3400 - 8th Avenue Suite

210

Bend

OR

USA

Heli Swaren GmbH &

Co. KG

Tiergartenstrae 5

Berlin

German
y

Specialty Biscuits, Ltd.

29 Kings Way

Manchester

UK

Leka Trading

471 Serangoon Loop,

Suite #402

Singapore

Singapo
re

Forts drables

148 rue Chasseur

Ste-Hyacinthe

Qubec Canada

Lyngbysild

Lyngbysild Fiskebakken 10 Lyngby

Denmar
k

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.

Relacione os objetos.

2.

Liste os fatores relacionados aos objetos.

3.

Transforme os objetos e fatores em tabelas e colunas.

4.

Determine as relaes entre os objetos.

5.

Determine as chaves das colunas.

6.

Determine as colunas relacionadas.

7.

Determine as relaes de reserva.

8.

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

Taxa de Embarque

Produto

Fatura

Funcionrio

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

Fatores Importantes Sobre o Objeto

Funcionrio

funcionrio, nome, data de nascimento, sexo,

estado civil

Cliente

nome da companhia, endereo, cidade, estado, CEP,

contato

Fatura

data, vendedor, cliente, quantidade, despesa de

transporte, taxas, fretes

Produto

nome do produto, descrio, custo, remarcao de

preos

Dependente

nome, data de nascimento

Taxa de
Embarque

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

Tabela: PRODUTO

Nome

Tipo

COMPANY

TEXTO

CADD1

Compr

Nome

Tipo

45

PRODNAME

TEXTO

30

TEXTO

30

PRODDESC

TEXTO

50

CADD2

TEXTO

30

PRODCOST

MOEDA

CCITY

TEXTO

25

PMARKUP

NM

CSTATE

TEXTO

CZIP

TEXTO

10

CAC

TEXTO

Nome

Tipo

CTELPH

TEXTO

DLAST

TEXTO

15

CONTACT

TEXTO

30

DFIRST

TEXTO

10

TITLE

TEXTO

30

DDOB

D/H

Tabela: FATURA
Nome

Tipo

INVDATE

Compr

Tabela: DEPENDENTE
Compr

Tabela: FUNCIONRIO
Compr

Nome

Tipo

Compr

D/H

ESSN

TEXTO

11

REQDATE

D/H

ELASTN

TEXTO

15

SHIPNAME

TEXTO

45

EFIRSTN

TEXTO

10

SHIPADDR

TEXTO

30

EDOB

D/H

SHIPCITY

TEXTO

25

EGENDER

TEXTO

SHIPZIP

TEXTO

10

EMARITAL

TEXTO

INVTOTAL

MOEDA

EADDR1

TEXTO

30

EADDR2

TEXTO

20

ECITY

TEXTO

25

Tabela: TAXA DE EMBARQUE

ESTATE

TEXTO

Nome

Tipo

Compr

EZIP

TEXTO

10

SHIPST

TEXTO

EAC

TEXTO

SHIPRATE

NM

EHOMEPH

TEXTO

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

FUNCIONRIO

DEPENDENTE

PRODUTO

FATURA

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 vriospara-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?

Um

A relao entre as tabelas um-para-vrios.

Um funcionrio de vendas registra uma ou vrias faturas?Vrias

Uma fatura registrada por um ou vrios funcionrios?

Um

A relao entre funcionrio e fatura tambm um-para-vrios.

 Um produto pode ser um item listado em uma ou vrias faturas?

Vrias
Uma fatura pode se relacionar a um ou vrios produtos? Vrios
A relao entre produto e fatura vrios-para-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-paravrios 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.

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

FUNCIONRIO
A chave EMPID
(CONTADOR). Poderia ser
usada ESSN mas TEXTO.

TRANSAO
Complex key. PRODID and
INVID.

DEPENDENTE
Chave complexa. Todas as
colunas.

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.

Cada tabela possui um tema nico? Assim deve ser. Cada coluna
dever ser um fato sobre a chave.

2.

Cada tabela tem sua(s) coluna(s) chave? Assim deve ser.

3.

Existem dependncias? Somente conseqncias lgicas da chave

devem existir.

4.

So os domnios nicos entre as tabelas? No misture domnios a

menos que a coluna seja comum entre tabelas.

5.

Existe domnio de restrio ou chave?

6.

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

Tabela:
PRODUTO

Nome

Tipo

CUSTID

CONTADOR

COMPANY

TEXTO

CADD1

TEXTO

CADD2

Comp
r

Nome

Tipo

PRODID

CONTADOR

45

PNOME

TEXTO

30

30

PDESCRIP

TEXTO

50

TEXTO

30

PCOST

MOEDA

CCITY

TEXTO

25

PMARKUP

NM

CSTATE

TEXTO

CZIP

TEXTO

10

CAC

TEXTO

Tabela: TAXA DE EMBARQUE

CTELPH

TEXTO

Nome

Tipo

CONTACT

TEXTO

30

SHIPST

TEXTO

TITLE

TEXTO

30

SHIPRATE

NM

Tabela:
FATURA

Compr

Compr
2

Tabela:
TRANSAO

Nome

Tipo

Comp
r

Nome

Tipo

INVID

CONTADOR

INVID

NM

CUSTID
INVDATE

NM

PRODID

NM

D/H

TQTY

NM

REQDATE

D/H

SHIPNOME

TEXTO

45

TDISC

NM

TPRICE

MOEDA

SHIPADDR

TEXTO

30

SHIPCITY

TEXTO

25

SHIPST

TEXTO

SHIPZIP

TEXTO

10

INVTOTAL

MOEDA

Compr

Tabela:
FUNCIONRIO
Nome

Tipo

EMPID

CONTADOR

Compr

ESSN

TEXTO

11

ELASTN

TEXTO

15

EFIRSTN

TEXTO

10

EDOB

D/H

EGENDER

TEXTO

1EMARITAL

TEXTO

EADDR1

TEXTO

30

EADDR2

TEXTO

20

ECITY

TEXTO

25

ESTATE

TEXTO

EZIP

TEXTO

10

EAC

TEXTO

EHOMEPH

TEXTO

Tabela:
DEPENDENTE
Nome

Tipo

Compr

EMPID

NM

DLAST

TEXTO

15

DFIRST

TEXTO

10

DDOB

D/H