Você está na página 1de 43

CAPITULO 13

Modelagem semntica
13.1 INTRODUO
A modelagem semntica foi tema de muita pesquisa desde o
final da dcada de 1970. A motivao geral para essa pesquisa
isto , o problema que os pesquisadores vm tentando
resolver este: em geral, os sistemas de bancos de dados tm
apenas uma compreenso muito limitada do que significam os
dados no banco de dados; eles tipicamente compreendem
certos valores de dados simples, e talvez certas restries
de integridade simples que se aplicam a esses valores, mas
pouca coisa alm disso (qualquer interpretao mais
sofisticada deixada para o usurio humano). Seria muito bom
se os sistemas pudessem entender um pouco mais,* de modo a
poderem responder de modo um pouco mais inteligente a
interaes de usurios, e talvez admitir interfaces do
usurio mais sofisticadas (de nvel mais alto). Por exemplo,
seria bom se a SQL pudesse entender que pesos de peas e
quantidades de remessas, embora sejam ambos valores
numricos, so diferentes em espcies isto ,
semanticamente diferentes de modo que (por exemplo) uma
solicitao de juno de peas e remessas com base nos pesos
a quantidades correspondentes pudesse pelo menos ser
questionada, se no rejeitada de imediato.
E claro que a noo de domnios (ou tipos) muito relevante
para esse exemplo particular o que serve para ilustrar o
ponto importante de que os modelos de dados atuais no so
totalmente desprovidos de aspectos semnticos. Por exemplo,
domnios, chaves candidatas e chaves estrangeiras so todos
aspectos semnticos do modelo relacional existente. Posto de
outra forma, os vrios modelos estendidos de dados que
foram desenvolvidos ao longo dos anos para considerar a
questo semntica so apenas ligeiramente mais semnticos que
os modelos anteriores; parafraseando Codd 113.6], capturar o
significado dos dados uma tarefa sem fim, e podemos esperar
(ou ter esperana de!) desenvolvimentos contnuos nessa rea
medida que nossa compreenso continue a evoluir. O termo
modelo semntico, usado com frequncia para se referir a um
ou outro dos modelos estendidos, no muito adequado
porque tende a sugerir que o modelo em questo procurou de
algum modo capturar toda a semntica da situao considerada.
Por outro lado, modelagem semntica um rtulo apropriado
para a atividade geral de tentar representar significados.
Neste captulo, apresentamos primeiro uma breve introduo a
algumas idias subjacentes a essa atividade; em seguida,
examinamos uma abordagem particular, a abordagem de
entidades/relacionamentos (a dc uso mais comum na prtica)
com alguma profundidade.
Observamos que a modelagem semntica conhecida por muitos
nomes, modelagem de dados, modelagem
entidades/relacionamentos, modelagem entidades e modelagem de
objetos. Preferimos a expresso modelagem semntica pelas
seguintes razes:
* desnecessrio dizer que nossa posio que um sistema
que admitisse predicados de variveis de relaes e bancos de
dados discutidos no Captulo 8 seria um pouco mais
compreensivo; ou seja, poderamos argumentar que esse
suporte de predicados a base certa e apropriada para a
modelagem semntica. Contudo, infelizmente, a maioria dos
esquemas de modelagem semntica no se baseia em nenhum
fundamento slido sendo ad hoc at certo ponto (as propostas
das referncias [13.17 a 13.19] so excees). Porm, essa
situao pode mudar, graas conscincia crescente na rea
comercial sobre a importncia de regras de
negcio 8.18 e 8.19]; os predicados do Captulo 8 so
basicamente apenas regras do negcio nesse sentido. 365
- No gostamos de modelagem de dados porque (a) ela se
choca com nosso uso j estabelecido do termo modelo de
dados para indicar um sistema formal com aspectos
estruturais, de integridade e manipulao, e (b) tende a
reforar a impresso popular de que um modelo de dados (em
nosso sentido) envolve apenas a estrutura de dados. Nota:
relevante lembr-lo do que vimos no Captulo 1, Seo 1.3
sobre o fato de que o termo modelo de dados usado na
literatura com dois significados bem diferentes. O primeiro
como um modelo de dados em geral (o modelo relacional um
modelo de dados nesse sentido). O segundo como um modelo
dos dados persistentes de alguma empresa em particular. Ns
mesmos no usamos o termo nesse ltimo sentido, mas muitos
autores o fazem.
- Tambm no gostamos de modelagem de
entidades/relacionamentos, porque tende a sugerir que h
apenas uma abordagem especfica para o problema, enquanto na
prtica muitas abordagens diferentes so possveis. Porm,
modelagem de entidades/relacionamentos uma expresso bem
estabelecida e, na verdade, bastante popular e comum.
- No temos objees profundas a modelagem de entidades,
exceto pelo fato de parecer um pouco mais especifica como
designao que modelagem semntica e, por isso, poderia
sugerir uma nfase que no muito adequada.
- No caso de modelagem de objetos, o problema que o termo
objetos claramente um sinnimo para entidades nesse
contexto, embora seja usado com um significado muito
diferente em outros contextos (em particular, outros
contextos de bancos de dados consulte a Parte VI deste
livro). De fato, parece que exatamente isso (dois
significados diferentes para o termo) o fator responsvel
para aquilo que chamamos O Primeiro Grande Erro [3.3].
Consulte o Captulo 25 para ver um exame mais completo do
assunto.
De qualquer modo, vamos voltar ao fio principal da discusso.
Nossa razo para incluir este material nesta parte do livro
: as idias de modelagem semntica podem ser teis como
auxlio no projeto de bancos de dados, mesmo na ausncia de
suporte direto do SGBD para essas idias. Assim, exatamente
como as idias do modelo relacional original foram usadas
como ajuda a um projeto primitivo de banco de dados, bem
antes de existirem implementaes comerciais desse modelo,
tambm as idias de algum modelo estendido poderiam ser
teis como ajuda ao projeto, mesmo que no existissem
implementaes comerciais dessas idias. De fato, na poca em
que escrevemos, talvez seja justo dizer que o impacto maior
das idias de modelagem semntica ocorreu na rea de projeto
de bancos de dados foram propostas vrias metodologias de
projeto baseadas em uma ou outra abordagem de modelagem
semntica. Por essa razo, a maior nfase deste captulo est
na aplicao das idias de modelagem semntica questo
especfica do projeto de bancos de dados.
A organizao do captulo a seguinte: aps essa seo
introdutria, a Seo 13.2 explica em termos gerais o que
est envolvido na modelagem semntica. A Seo 13.3 introduz
ento o mais conhecido dos modelos estendidos, o modelo de
entidades/relacionamentos (E/R) de Chen, e as Sees 13.4 e
13.5 consideram a aplicao desse modelo ao projeto de bancos
de dados. (Outros modelos so discutidos rapidamente nas
anotaes a algumas referncias da seo Referncias e
bibliografia.) Finalmente, a Seo 13.6 oferece uma breve
anlise de certos aspectos do modelo E/R e a Seo 13.7
apresenta um resumo.
13.2 A ABORDAGEM GERAL
Podemos caracterizar a abordagem geral para o problema de
modelagem semntica em termos dos quatro passos a seguir.
1. Primeiro, tentamos identificar um conjunto de conceitos
semnticos que parecem teis quando se fala informalmente
sobre o mundo real. Por exemplo:
- Podemos concordar que o mundo feito de entidades. (Apesar
do fato de que no podemos enunciar com alguma preciso o que
exatamente uma entidade, o conceito de entidade parece
366 ser til ao se falar sobre o mundo, pelo menos
intuitivamente.)
- Podemos ir alm e concordar que as entidades podem ser
classificadas de modo til em tipos de entidade. Por exemplo,
podemos concordar que todos os empregados individuais so
instncias do tipo de entidade genrico EMPREGADO. A vantagem
dessa classificao que todas as entidades de um dado tipo
tero em comum certas propriedades por exemplo, todos os
empregados tm um salrio e portanto que isso pode levar a
algumas economias de representao (bastante bvias). Por
exemplo, em termos relacionais, o caractere comum pode ser
fatorado em um cabealho de varivel de relao.
- Podemos ir ainda mais longe e concordar que cada entidade
tem uma propriedade particular que serve para identificar
essa entidade isto , toda entidade tem uma identidade.
- Podemos outra vez ir mais longe e concordar que cada
entidade pode estar relacionada a outras entidades por meio
de relacionamentos.
E assim por diante. Porm, observe cuidadosamente que todos
esses termos (ocorrncia de entidade, tipo de entidade,
propriedade, relacionamento, etc.) no so definidos de
maneira precisa ou formal so conceitos reais, no-
formais. O Passo 1 no um passo formal. Porm, em
contraste, os Passos de 2 a 4 a seguir so formais.
2. Em seguida, tentamos criar um conjunto de objetos
simblicos (isto , formais), que possam ser usados para
representar os conceitos semnticos anteriores. (Nota: no
estamos usando aqui o termo objeto em qualquer sentido
formal!) Por exemplo, o modelo relaciona! estendido RM/T
[13.61 fornece algumas espcies particulares de relaes
chamadas relaes E e relaes P. Em linhas gerais, as
relaes E representam entidades e as relaes P representam
propriedades; porm, as relaes E e P tm obviamente
definies formais; por outro lado, como explicamos as
entidades e propriedades no tm.
3. Tambm criamos um conjunto de regras de integridade (ou
metarrestries, para usar a terminologia do Captulo 8)
formais que acompanham esses objetos formais. Por exemplo, o
RM/T inclui uma regra chamada integridade de propriedade, que
diz que todo elemento em uma relao P deve ter uma entrada
correspondente em uma relao E (refletindo o fato de que
toda propriedade deve ser uma propriedade de alguma
entidade).
4. Finalmente, tambm desenvolvemos um conjunto de operadores
formais para manipular esses objetos formais. Por exemplo,
RM/T fornece um operador PROPERTY, que pode ser usado para
fazer a juno de uma relao E com todas as suas
correspondentes relaes P, e assim reunir todas as
propriedade de uma dada entidade.
Os objetos, regras e operadores dos Passos de 2 a 4
anteriores constituem juntos um modelo de dados estendido
estendido se essas construes de fato formam um
superconjunto das construes de um dos modelos bsicos, como
o modelo relaciona! bsico; porm, no h na realidade uma
distino clara entre o que estendido e o que bsico.
Entretanto, observe que as regras e os operadores so apenas
parte do modelo, tanto quanto os objetos (exatamente como no
modelo relacional bsico). Contudo, apesar desse fato, os
operadores talvez sejam menos importantes que os objetos e
regras do ponto de vista do projeto de bancos de dados; a
nfase no restante do captulo ento feita sobre objetos e
regras, mais do que sobre operadores, embora ocasionalmente
comentemos algo sobre os operadores.
Repetindo, o Passo 1 envolve uma tentativa de identificar um
conjunto de conceitos semnticos que parecem ser teis para
falar sobre o mundo. Alguns desses conceitos entidade,
propriedade, relacionamento, subtipo so mostrados na
Figura 13.1, acompanhados por definies informais e alguns
exemplos. Observe que os exemplos foram escolhidos
deliberadamente para ilustrar o fato de que o mesmo objeto no
mundo real poderia ser considerado de forma legtima uma
entidade por algumas pessoas, uma propriedade por outras e um
relacionamento por outras ainda. (Esse fato mostra por que
impossvel dar uma definio precisa a termos como
entidade.) E uma meta da modelagem semntica no
completamente atingida dar suporte a essa flexibilidade de
interpretao.
367
A propsito, observe que provavelmente h choques entre (a)
termos como os ilustrados na Figura 13.1 usados no nvel
semntico e (b) termos usados em algum formalismo bsico como
o modelo relacional. Por exemplo, muitos esquemas de
modelagem semntica utilizam o termo atributo em lugar de
nosso propriedade mas isso no significa necessariamente
que um desses atributos seja a mesma coisa ou possa ser
mapeado como um atributo no nvel relacional. Como outro
exemplo, o conceito de tipo de entidade empregado no modelo
E/R no de modo algum o mesmo conceito tipo discutido no
Captulo 5. Para sermos especficos, esses tipos de entidades
provavelmente sero mapeados como variveis de relaes em um
projeto relacional; assim, eles certamente no correspondem a
tipos de atributos relacionais (domnios). Porm, eles tambm
no correspondem totalmente a tipos de relaes, porque:
1. Alguns tipos bsicos de relaes provavelmente
correspondero a tipos de relacionamentos, e no tipos de
entidades, no nvel semntico.
2. Tipos de relaes derivadas podem a nada corresponder no
nvel semntico (em termos muito informais).
Conceito Definio informal Exemplos
ENTIDADE Um objeto perceptvel Fornecedor, pea, remessa,
empregado,
departamento, pessoa, composio,
orquestra, maestro, pedido de compra,
linha de pedido
PROPRIEDADE Um item de informao que descreve uma Nmero de
fornecedor, quantidade de
entidade remessa, departamento de empregado,
altura de pessoa, tipo de concerto,
data de pedido de compra
RELACIONAMENTO Uma entidade que serve para Remessa
(fornecedor-pea), Designao
interconectar duas.ou mais de outras (empregado-
departamento), Gravao
entidades (composi o-orquestra-maestro)
SUBTIPO O tipo de entidade Y um subtipo do Empregado um
subtipo de pessoa,
tipo de entidade X se e somente se concerto um subtipo de
composio
todo Y necessariamente um X
FIGURA 13.1 Alguns conceitos semnticos teis
A confuso sobre nveis em particular, a confuso que surge
de conflitos de terminologia levou a alguns equvocos
dispendiosos no passado, e continua a faz-lo hoje (consulte
o Captulo 25, Seo
25.2).
Uma observao final para fechar esta seo: dissemos no
Captulo 1 que prefervel considerar relacionamentos como
entidades por direito prprio, e que em geral os trataramos
assim em todo este livro. Tambm indicamos no Captulo 3 que
uma vantagem do modelo relaciona! era precisamente
representar todas as entidades, inclusive relacionamentos, do
mesmo modo; ou seja, por meio de variveis de relaes. No
entanto, o conceito de relacionamento (como o de entidade)
parece ser intuitivamente til quando se fala do mundo; alm
disso, a abordagem ao projeto de banco de dados a ser
discutido nas Sees 13.3 a 13.5 depende em grande parte da
distino entre entidade e relacionamento. Adotamos ento a
terminologia de relacionamento nas prximas sees.
Entretanto, teremos mais a dizer sobre a questo na Seo
13.6.
13.3 O MODELO E/R
Como indicamos na Seo 13.1, uma das abordagens de modelagem
semntica mais conhecidas certamente uma das mais usadas
a abordagem chamada entidades/relacionamentos (E/R),
baseada no modelo de entidades/relacionamentos introduzido
por Chen em 1976 [13.5] e refinada de vrios modos
368 por Chen e muitos outros desde ento (por exemplo,
consulte as referncias [13.13] e [13.40 a 13.42].
Grande parte deste captulo portanto dedicada a uma
discusso da abordagem E/R. (Porm, devemos frisar que o
modelo E/R est muito longe de ser o nico modelo estendido
muitos e muitos outros foram propostos. Por exemplo,
consulte as referncias [13.5], [13.13], [13.25] e
particularmente [13.19] para ver introdues a vrios outros,
e tambm as referncias [13.22] e [13.3 1] para examinar
pesquisas tutoriais do campo.)
O modelo E/R inclui anlogos de todos os objetos semnticos
listados na Figura 13.1. Examinaremos esses objetos um a um.
Porm primeiro devemos observar que a referncia [13.5] no
apenas introduziu um modelo E/R em si, ela tambm introduziu
uma tcnica de diagramao correspondente (diagramas E/R).
Discutiremos os diagramas E/R com algum detalhe na prxima
seo, mas um exemplo simples desse diagrama, baseado em uma
figura da referncia [13.5] mostrado na Figura 13.2, e voc
pode achar til estudar esse exemplo em conjunto com as
discusses desta seo. O exemplo representa os dados para
uma empresa manufatureira simples ( uma verso estendida do
diagrama E/R para a empresa KnowWare mc., dado na Figura
1.6 do Captulo 1).
FIGURA 13.2 Um diagrama de entidades/relacionamentos (exemplo
incompleto)
Nota: a maioria das idias a serem discutidas nas subsees
seguintes deve ser bastante familiar para qualquer pessoa que
conhea o modelo relaciona!. Contudo, h certas diferenas na
terminologia, como voc ver em breve.
Entidades
A referncia [13.5] comea definindo uma entidade como uma
coisa que pode ser distintamente identificada. Em seguida,
continua a classificar entidades como entidades regulares e
entidades fracas. Uma entidade fraca uma entidade
dependente da existncia de alguma outra entidade, no sentido
de que ela no poder existir se essa outra entidade tambm
no existir. Por exemplo, com referncia Figura 13.2, os
dependentes de um empregado poderiam ser entidades fracas
eles no podem existir (no que se refere ao banco de dados)
se o empregado relevante no existir. Em particular, se um
dado empregado for eliminado, todos os dependentes desse
empregado tambm devem ser eliminados. Em contraste, uma
entidade regular, uma entidade que no fraca; por
exemplo, empregados podem ser entidades regulares. Nota:
alguns autores usam o termo entidade forte em lugar de
entidade regular.
M
DEPENDENTE
369
Propriedades
Entidades e tambm relacionamentos tm propriedades.
Todas as entidades ou relacionamentos de um tipo dado tm
certos tipos de propriedades em comum; por exemplo, todos os
empregados tm um nmero de empregado, um nome, um salrio, e
assim por diante. (Nota: deliberadamente no mencionamos
nmero de departamento como uma propriedade de empregado
nesse exemplo. Consulte a discusso de relacionamentos a
seguir.) Cada espcie de propriedade tira seus valores de um
conjunto de valores correspondente (isto , domnio, em
termos relacionais). Alm disso, as propriedades podem ser:
- Simples ou compostas: por exemplo, a propriedade composta
nome de empregado poderia ser constituda das propriedades
simples primeiro nome, inicial do meio e ltimo nome.
- Chave (isto , exclusiva, possivelmente dentro de algum
contexto); por exemplo, o nome de um dependente poderia ser
exclusivo dentro de um contexto de um dado empregado.
- Univalorada ou multivalorada (em outras palavras, grupos
repetidos so permitidos): todas as propriedades mostradas na
Figura 13.2 so univaloradas; porm, se um dado fornecedor,
por exemplo, pudesse ter vrios locais de fornecedor
distintos, ento cidade de fornecedor poderia ser uma
propriedade multivalorada.
- Em falta (por exemplo desconhecido ou no-aplicvel):
esse conceito no est ilustrado na Figura 13.2. Consulte o
Captulo 18 para ver uma descrio detalhada.
- Bsica ou derivada: por exemplo, quantidade total para
uma pea dada poderia ser derivada como a soma das quantidade
de remessas individuais para essa pea. Novamente, esse
conceito no est ilustrado na Figura 13.2.
Nota: alguns autores utilizam o termo atributo em lugar de
propriedade em um contexto de E/R.
Relacionamentos
A referncia [13.51 define um relacionamento como uma
associao entre entidades. Por exemplo, existe um
relacionamento chamado DEPTO EMP entre departamentos e
empregados, representando o fato de que certos departamentos
empregam certos empregados. Como ocorre com as entidades
(consulte o Captulo 1), necessrio em principio distinguir
entre tipos de relacionamento e instncias de relacionamento,
mas comum ignorar esses refinamentos na discusso informal,
e ns mesmos o faremos com frequncia no texto a seguir.
As entidades envolvidas em um dado relacionamento so ditas
participantes desse relacionamento. O nmero de participantes
em um dado relacionamento chamado grau desse
relacionamento. (Portanto, observe que esse termo no
significa a mesma coisa que no modelo relacional.)
Seja R um tipo de relacionamento que envolve o tipo de
entidade E como participante. Se toda instncia de E
participa de pelo menos uma instncia de R, ento a
participao de E em R dita total, do contrrio ela dita
parcial. Por exemplo, se todo empregado deve pertencer a um
departamento, ento a participao de empregados em DEPTO EMP
total; possvel um dado departamento no ter nenhum
empregado, e ento a participao de departamentos em DEPTO
EMP parcial.
Um relacionamento E/R pode ser de um para um, de um para
muitos (tambm conhecido como de muitos para um) ou de muitos
para muitos (supomos por simplicidade que todos os
relacionamentos so binrios, isto , de grau dois; estender
os conceitos e a terminologia a relacionamentos de grau maior
que dois essencialmente direto, claro). Se voc estiver
familiarizado com o modelo relacional, poder ser tentado a
pensar no caso de muitos para muitos como o nico
relacionamento genuno, pois esse caso o nico que demanda
representao por meio de uma varivel de relao separada
os relacionamentos de um para um e de um para muitos sempre
podem ser representados por meio de uma chave estrangeira em
uma das variveis de relaes participantes. Porm, h boas
razes para tratar os casos de um para um e de um para muitos
do mesmo modo que o caso de muitos para muitos, pelo menos se
existir qualquer
370 possibilidade de que eles possam evoluir e se tornar de
muitos para muitos com o tempo. Somente se no
existir essa possibilidade ser seguro trat-los de modo
diferente. claro que s vezes no existe essa
possibilidade. Por exemplo, sempre ser verdade que um
crculo tem exatamente um ponto como centro.
Subtipos e supertipos de entidades
Nota: as idias discutidas nesta subseo no foram includas
no modelo E/R original da referncia [13.5], mas foram
acrescentadas mais tarde. Por exemplo, veja Teorey, Yang e
Fry [13.41].
Qualquer entidade especfica pelo menos de um tipo de
entidade, mas uma entidade pode ser de vrios tipos
simultaneamente. Por exemplo, se alguns empregados so
programadores (e todos os programadores so empregados),
ento podemos dizer que o tipo de entidade PROGRAMADOR um
sub- tipo do tipo de entidade EMPREGADO (ou, de forma
equivalente, que o tipo de entidade EMPREGADO um supertipo
do tipo de entidade PROGRAMADOR). Todas as propriedades de
empregados se aplicam automaticamente a programadores, mas a
recproca no verdadeira (por exemplo, programadores
poderiam ter uma propriedade habilidade em linguagem de
programao, que no se aplica a empregados em geral). Da
mesma forma, programadores participam automaticamente de
todos os relacionamentos em que os empregados participam, mas
a recproca no verdadeira (por exemplo, os programadores
poderiam pertencer a alguma sociedade profissional de
computao, enquanto os empregados em geral no pertencem).
Dizemos que as propriedades e os relacionamentos que se
aplicam ao supertipo so herdadas pelo subtipo.
Observe ainda que alguns programadores poderiam ser
programadores de aplicaes, e outros programadores de
sistemas; assim, poderamos dizer que os tipos de entidades
APLICAAO_PROGRAMADOR e SISTEMA_PROGRAMADOR so ambos
subtipos do supertipo PROGRAMADOR (e assim por diante). Em
outras palavras, um subtipo de entidade ainda um tipo de
entidade e pode ter seus subtipos. Um determinado tipo e seus
subtipos imediatos, seus subtipos imediatos e assim por
diante constituem juntos uma hierarquia de tipos de entidades
(ver Figura 13.3).
Surgem pontos importantes:
1. Discutiremos as hierarquias de tipos e a herana de tipos
em profundidade no Captulo 19. Porm, devemos adverti-lo de
imediato que naquele captulo empregaremos o termo tipo com o
significado exato do Captulo 5 ele no ser um tipo de
entidade no sentido deste captulo.
2. Para os leitores que estejam familiarizados com o IMS (ou
algum outro sistema de bancos de dados que admita uma
estrutura de dados hierrquica) observamos que as hierarquias
de tipos no devem ser confundidas com hierarquias no estilo
do IMS. Na Figura 13.3, por exemplo, no h sugesto de que
para um EMPREGADO existam muitos PROGRAMADORES
correspondentes (como haveria se a figura representasse uma
hierarquia no estilo do IMS); pelo contrrio, para uma
instncia dc EMPREGADO h no mximo um PROGRAMADOR
correspondente representando o mesmo EMPREGADO em sua funo
de PROGRAMADOR.
APLICAO_ PROGRAMADOR
SISTEMA_ PROGRAMADOR
FIGURA 13.3 Exemplo de uma hierarquia de tipos de entidades
371
Isso encerra nossa breve discusso sobre os aspectos
estruturais mais importantes do modelo E/R. Agora, vamos
dedicar nossa ateno aos diagramas E/R.
13.4 DIAGRAMAS E/R
Como foi explicado na seo anterior, a referncia [13.5] no
apenas introduziu o modelo EIR, como tambm introduziu o
conceito de diagramas de entidades/relacionamentos (diagramas
E/R). Diagramas E/R constituem um tcnica para representar a
estrutura lgica de um banco de dados de modo pictrico. Com
tal, fornecem um meio simples e fcil de entender para
comunicar os aspectos principais do projeto de qualquer banco
de dados (uma figura vale mil palavras). De fato, a
popularidade do modelo E/R como abordagem ao projeto de banco
de dados provavelmente pode ser atribuda existncia da
tcnica de diagramao E/R, mais que a qualquer outra causa.
Descrevemos as regras para construir um diagrama E/R em
termos dos exemplos j dados nas Figuras 13.2 e 13.3.
Nota: como o prprio modelo E/R, a tcnica de diagramao E/R
evoluiu bastante com o tempo. A verso que descrevemos nesta
seo difere em certos pontos importantes da descrita
originalmente por Chen na referncia [13.5].
Entidades
Cada tipo de entidade mostrado como um retngulo, marcado
com o nome do tipo de entidade em questo. Para um tipo de
entidade fraca, o retngulo dobrado.
Exemplos (ver Figura 13.2):
- Entidades regulares:
DEPARTAMENTO
EMPREGADO
FORNECEDOR
PEA
PROJETO
- Entidade fraca:
DEPENDENTE
Propriedades
As propriedades so mostradas como elipses, contendo o nome
da propriedade em questo e ligadas entidade ou
relacionamento relevante por meio de um linha contnua. A
borda da elipse pontilhada ou tracejada se a propriedade
derivada e dupla se a propriedade multivalorada. Se a
propriedade composta, suas propriedades componentes so
mostradas como outras elipses, ligadas elipse para a
propriedade composta em questo por meio de outras linhas
contnuas. As propriedades chaves so sublinhadas. Conjuntos
de valores correspondentes a propriedades no so mostrados.
Exemplos (ver Figura 13.2):
- Para EMPREGADO:
EMP# (chave) -
ENOME (composta, consistindo em PRIMEIRO, ME e ULTIMO)
SALARIO
- Para FORNECEDOR:
F# (chave)
FNOME
STATUS
CIDADE
372
- Para FORN_PEA_PROJ:
QDE
- Para ESTRUTURA_PEA:
QDE
Todas as outras propriedades foram omitidas da Figura 13.2
por razes de espao.
Relacionamentos
Cada tipo de relacionamento mostrado como um losango,
contendo o nome do tipo de relacionamento em questo. O
losango dobrado se o relacionamento entre um tipo de
entidade fraca e o tipo de entidade do qual depende sua
existncia. Os participantes de cada relacionamento esto
ligados ao relacionamento relevante por meio de linhas
contnuas; cada linha tem a indicao 1 ou M, a fim de
indicar se o relacionamento de um para um, muitos para um
etc. A linha dobrada se a participao total.
Exemplos (ver Figura 13.2):
- DEPTO_EMP (relacionamento um para muitos entre DEPARTAMENTO
e EMPREGADO)
- EMP_DEP (relacionamento um para muitos entre EMPREGADO e
DEPENDENTE, um tipo de entidade fraca)
- PROJTRAB e PROJ GER (ambos relacionamentos entre EMPREGADO
e PROJETO, o primeiro muitos para muitos, o segundo um para
muitos)
- FORN_PEA_PROJ (relacionamento muitos para muitos para
muitos envolvendo FORNECEDOR, PEA e PROJETO)
- FORN_PEA (relacionamento muitos para muitos entre
FORNECEDOR e PEA)
- FORN_ESTRUTURA (relacionamento muitos para muitos entre
PEA e PEA)
Nesse ltimo caso, observe que as duas linhas de PEA para
ESTRUTURA_PEA so distinguidas identificando-se cada uma com
nomes de funes distintos (EXP e IMP, para exploso de
pea e imploso de pea, respectivamente). ESTRUTURA_PEA
um exemplo daquilo que s vezes se chama um relacionamento
recursivo.
Subtipos e supertipos de entidades
Seja o tipo de entidade Y um subtipo do tipo de entidade X.
Ento, traamos uma linha contnua do retngulo X para o
retngulo Y marcada com uma ponta de seta na extremidade Y. A
linha denota aquilo que s vezes se chama o relacionamento
um (porque todo Y um X de modo equivalente, o conjunto
de todos os Y um subconjunto do conjunto de todos os X).
Exemplos (ver Figura 13.3):
- PROGRAMADOR um subtipo de EMPREGADO.
- APLICAO_PROGRAMADOR e SISTEMA_PROGRAMADOR so subtipos de
PROGRAMADOR.
13.5 PROJETO DE BANCOS DE DADOS COM O MODELO E/R
Em certo sentido, um diagrama E/R construdo de acordo com as
regras descritas na seo anterior um projeto de banco de
dados. Porm, se tentarmos transformar esse projeto nos
formalismos de um SGBD especfico,* logo descobriremos que o
diagrama E/R ainda muito impreciso em certos aspectos e
deixa sem especficao diversos detalhes (especialmente
detalhes de restries de integridade). Para ilustrar esse
fato, consideramos o que significa mapear um projeto como o
da Figura 13.2 em uma definio de banco de dados relacional.
* Existem agora muitas ferramentas que podem ajudar nesse
processo de mapeamento (por exemplo, utilizando o diagrama
E/R
para gerar instrues CREATE TABLE de SQL e outras
semelhantes). 373
Entidades regulares
Repetindo, as entidades regulares na Figura 13.2 so:
DEPARTAMENTO
EMPREGADO
FORNECEDOR
PEA
PROJETO
Cada tipo de entidade regular transformado em uma varivel
de relao bsica por mapeamento. Assim, o banco de dados
conter cinco variveis de relaes bsicas, digamos DEPTO,
EMP, F, P e J, correspondendo a esses cinco tipos de
entidades. Alm disso, cada uma dessas variveis de relaes
bsicas ter uma chave candidata representada pelos
atributos DEPTO#, EMP#, F#, P# e J#, digamos
correspondentes s chaves identificadas no diagrama E/R. Em
definitivo, vamos concordar em dar a cada varivel de relao
uma chave primria. Ento, a definio da varivel de relao
DEPTO (por exemplo) pode ser algo semelhante a:
VAR DEPTO BASE RELATION
{DEPTO#
PRIMARY KEY { DEPTO#
As outras quatro variveis de relaes ficam como exerccio.
Nota: os domnios ou conjuntos de valores usados tambm
precisam ser documentados. Omitimos a discusso detalhada
desse aspecto aqui, pois os conjuntos de valores j
mencionados no esto includos no diagrama E/R.
Relacionamentos muitos para muitos
Os relacionamentos muitos para muitos (ou muitos para muitos
para muitos etc.) no exemplo so:
PROJ_TRAB (envolvendo empregados e projetos)
FORN_PEA ( envolvendo fornecedores e peas)
FORN_PEAPROJ (envolvendo fornecedores, peas e projetos)
ESTRUTURA PEA (envolvendo peas e peas)
Cada relacionamento desses tambm mapeado em uma varivel
de relao bsica. Introduzimos portanto mais quatro
variveis de relaes bsicas correspondentes a esses quatro
relacionamentos. Vamos nos concentrar no relacionamento
FORN_PEA. Seja FP a varivel de relao para esse
relacionamento. Vamos adiar por um momento a questo da chave
primria para essa varivel dc relao e nos concentrar em
vez disso no problema das chaves estrangeiras necessrias
para identificar os participantes do relacionamento:
VAR FP BASE RELATION FP
FOREIGN KEY { F# } REFERENCES F
FOREIGN KEY { P# } REFERENCES P
Evidentemente, a varivel de relao deve incluir duas chaves
estrangeiras (F# e P#) correspondentes aos dois participantes
(fornecedores e peas) e essas chaves estrangeiras devem
fazer referncia as variveis de relaes participantes F e P
correspondentes. Alm disso, um conjunto apropriado de regras
de chaves estrangeiras isto , uma regra DELETE e uma regra
UPDATE devem ser especificadas para
cada uma dessas chaves estrangeiras (consulte o Captulo 8 se
precisar reavivar a memria sobre essas re
gras). No caso da varivel de relao FP, poderamos
especificar regras como a seguir. (As regras especficas
mostradas so apenas para ilustrao; observe em particular
que elas no so derivadas do, ou especificadas pelo,
diagrama E/R.)
VAR FP BASE RELATION FP
{ F# . . . , }
FOREIGN KEY { F# } REFERENCES F
ON DELETE RESTRICT
ON UPDATE CASCADE
FOREIGN KEY { P# } REFERENCES P
ON DELETE RESTRICT
ON UPDATE CASCADE ;
E qual ser a chave primria para essa varivel de relao?
Uma possibilidade seria tomar a combinao das chaves
estrangeiras que identificam participantes (F# e P#, no caso
de FP) se (a) essa combinao tiver um valor nico para
cada instncia do relacionamento (o que pode acontecer ou
no, mas em geral acontece), e se (b) o projetista no fizer
nenhuma objeo a chaves primrias compostas (o que pode
ocorrer ou no). Como outra opo, um novo atributo
substituto no composto, digamos nmero de remessa, poderia
ser introduzido para servir como chave primria (consulte as
referncias [13.10] e [13.161). No caso do exemplo,
continuamos com a primeira dessas duas possibilidades, e
assim adicionamos a clusula
PRIMARY KEY { F#, P# }
definio da varivel de relao bsica FP.
Deixamos a considerao dos relacionamentos PROJ_TRAB,
ESTRUTURA_PEA e FORN_PEA PROJ como exerccio.
Relacionamentos muitos para um
No exemplo, h trs relacionamentos muitos para um:
PROJGER (de projetos a gerentes)
DEPTO_EMP (de empregados a departamentos)
EMP_DEP (de dependentes a empregados)
Desses trs, o ltimo envolve um tipo de entidade fraca
(DEPENDENTE), os outros dois envolvem apenas tipos de
entidades regulares. Discutiremos o caso de entidade fraca em
breve; por enquanto, vamos nos concentrar nos outros dois
casos. Considere o exemplo DEPTO EMP. Esse exemplo no
provoca a introduo de nenhuma varivel de relao nova.* Em
vez disso, simplesmente introduzimos uma chave estrangeira na
varivel de relao do lado muitos do relacionamento (EMP)
que referencia a varivel de relao no lado um (DEPTO),
assim:
VAR EMP BASE RELATION
{EMP#..., DEPTO# }
PRIMARY KEY { EMP# }
FOREIGN KEY ( DEPTO# ) REFERENCES DEPTO
ON DELETE
ON UPDATE
*Embora pudesse faz-lo; como mencionamos na Seo 13.3, s
vezes existem boas razes para tratar um relacionamento mui
to para um como se fosse muitos para muitos. Por exemplo,
consulte a parte final da referncia [18.201. 375
As possibilidades de regras DELETE e UPDATE aqui so
exatamente as mesmas de uma chave estrangeira que
representasse um participante em um relacionamento muitos
para muitos (em geral). Observe mais uma vez que elas no
esto especificadas pelo diagrama E/R.
Nota: para fins desta exposio, vamos supor que
relacionamentos um para um (que de todo modo no so comuns
na prtica) so tratados exatamente do mesmo modo que
relacionamentos muitos para um. A referncia [13.7] contm
uma extensa discusso dos problemas particulares do caso de
um para um.
Entidades fracas
O relacionamento de um tipo de entidade fraca com o tipo de
entidade do qual ela depende naturalmente um relacionamento
muitos para um, como indicamos na subseo anterior. Porm,
as regras de DELETE e UPDATE devem ser:
ON DELETE CASCADE
ON UPDATE CASCADE
Juntas, essas especificaes captam e refletem a dependncia
de existncia necessria. Aqui est um exemplo:
VAR DEPENDENTE BASE RELATION
{ EMP# }
FOREIGN KEY ( EMP# ) REFERENCES EMP
ON DELETE CASCADE
ON UPDATE CASCADE ;
Qual a chave primria para essa varivel de relao? Como
no caso de relacionamentos muitos para muitos, temos um
escolha. Uma possibilidade tomar a combinao da chave
estrangeira e da chave de entidade fraca do diagrama E/R
se (mais uma vez) o projetista do banco de dados no fizer
objees a chaves primrias compostas. Como outra opo,
poderamos introduzir um novo atributo substituto (no
composto) para servir como chave primria. Novamente,
consulte as referncias [13.10] e [13.16]. No caso do
exemplo, ficaremos de novo com a primeira das duas
possibilidades, e assim acrescentaremos a clusula:
PRIMARY KEY { EMP#, NOME DEP
(onde NOME DEP o nome do dependente do empregado)
definio da varivel de relao bsica
DEPENDENTE.
Propriedades
Cada propriedade mostrada no diagrama E/R mapeada para um
atributo na varivel de relao bsica apropriada exceto
pelo fato de que, se a propriedade multivalorada, em geral
criamos uma nova varivel de relao para ela de acordo com
os princpios de normalizao discutidos no Captulo 11
(especialmente na Seo 11.6). Domnios so criados para
conjuntos de valores da maneira bvia (embora a deciso sobre
conjuntos de valores possa no ser muito bvia!). Os detalhes
sobre esses passos so diretos e sero omitidos aqui.
Supertipos e subtipos de entidades
Como a Figura 13.2 no envolve supertipos ou subtipos, vamos
passar para o exemplo da Figura 13.3, 376 que os contm.
Vamos nos concentrar por enquanto em tipos de entidades
EMPREGADO e PRO
GRAMADOR. Para simplificar, suponha que programadores tenham
habilidade em apenas uma linguagem de programao (isto , a
propriedade LING univalorada). Ento: *
- O supertipo EMPREGADO mapeado em uma varivel de relao
bsica, digamos EMP, da maneira usual (isto , como j
discutimos).
- O subtipo PROGRAMADOR mapeado em outra varivel de
relao bsica, digamos PGMR, com chave primria igual da
varivel de relao bsica do supertipo e com outros
atributos correspondentes s propriedades que se aplicam
apenas a empregados que tambm so programadores (isto ,
apenas LING, no exemplo):
VAR PGMR BASE RELATION
{EMP# . . ., LING . . . }
PRIMARY KEY { EMP# } .. .
Alm disso, a chave primria de PGMR tambm uma chave
estrangeira, fazendo referncia de volta varivel de
relao EMP. Desse modo, tambm precisamos estender a
definio de acordo (em particular note as regras DELETE e
UPDATE):
VAR PGMR BASE RELATION
{EMP# ..., LING ... }
PRIMARY KEY { EMP#
FOREIGN KEY { EMP# } REFERENCES EMP
ON DELETE CASCADE
ON UPDATE CASCADE ;
- Tambm necessitamos de uma viso, digamos EMP_PGMR, que
seja a juno das variveis de relaes supertipo e subtipo:
VAR EMPPGMR VIEW
EMP JOIN PGMR ;
Observe que essa juno (zero ou um) para um ela ocorre
sobre uma chave candidata e uma chave estrangeira associada,
e essa chave estrangeira ela prpria uma chave candidata.
Assim, a viso contm apenas os empregadores que so
programadores, em termos informais.
Dado este projeto:
- Podemos ter acesso a propriedades que se aplicam a todos os
empregados (por exemplo, para recuperao) usando a varivel
de relao bsica EMP.
- Podemos ter acesso a propriedades que se aplicam apenas a
programadores usando a varivel de relao bsica PGMR.
- Podemos ter acesso a todas propriedades que se aplicam a
programadores usando a viso
EMP_PGMR.
- Podemos inserir empregados que no so programadores usando
a varivel de relao bsica
EMP.
- Podemos inserir empregados que so programadores usando a
viso EMP_PGMR.
* Observe em particular que no mapeamos empregados e
programadores em algum tipo de construo de supertabela e
subtabela. Existe uma dificuldade conceitual, ou pelo menos
uma armadilha, nesse caso: apenas pelo fato de o tipo de
entidade Y ser um subtipo do tipo de entidade X no diagrama
E/R, no decorre que o anlogo relacional de Y seja um sub
qualquer
coisa do anlogo relacional deX e, na verdade, no .
Consulte a referncia [13.12]. 377
r'
As possibilidades de regras DELETE e UPDATE aqui so
exatamente as mesmas de uma chave estrangeira que
representasse um participante em um relacionamento muitos
para muitos (em geral). Observe mais uma vez que elas no
esto especificadas pelo diagrama E/R.
Nota: para fins desta exposio, vamos supor que
relacionamentos um para um (que de todo modo no so comuns
na prtica) so tratados exatamente do mesmo modo que
relacionamentos muitos para um. A referncia [13.7] contm
uma extensa discusso dos problemas particulares do caso de
um para um.
Entidades fracas
O relacionamento de um tipo de entidade fraca com o tipo de
entidade do qual ela depende naturalmente um relacionamento
muitos para um, como indicamos na subseo anterior. Porm,
as regras de DELETE e UPDATE devem ser:
ON DELETE CASCADE
ON UPDATE CASCADE
Juntas, essas especificaes captam e refletem a dependncia
de existncia necessria. Aqui est um exemplo:
VAR DEPENDENTE BASE RELATION
{ EMP# }
FOREIGN KEY ( EMP# ) REFERENCES EMP
ON DELETE CASCADE
ON UPDATE CASCADE ;
Qual a chave primria para essa varivel de relao? Como
no caso de relacionamentos muitos para muitos, temos um
escolha. Uma possibilidade tomar a combinao da chave
estrangeira e da chave de entidade fraca do diagrama E/R
se (mais uma vez) o projetista do banco de dados no fizer
objees a chaves primrias compostas. Como outra opo,
poderamos introduzir um novo atributo substituto (no
composto) para servir como chave primria. Novamente,
consulte as referncias [13.10] e [13.16]. No caso do
exemplo, ficaremos de novo com a primeira das duas
possibilidades, e assim acrescentaremos a clusula:
PRIMARY KEY { EMP#, NOME DEP
(onde NOME_DEP o nome do dependente do empregado)
definio da varivel de relao bsica
DEPENDENTE.
Propriedades
Cada propriedade mostrada no diagrama E/R mapeada para um
atributo na varivel de relao bsica apropriada exceto
pelo fato de que, se a propriedade multivalorada, em geral
criamos uma nova varivel de relao para ela de acordo com
os princpios de normalizao discutidos no Captulo 11
(especialmente na Seo 11.6). Domnios so criados para
conjuntos de valores da maneira bvia (embora a
deciso sobre conjuntos de valores possa no ser muito
bvia!). Os detalhes sobre esses passos so diretos e sero
omitidos aqui.
Supertipos e subtipos de entidades
Como a Figura 13.2 no envolve supertipos ou subtipos, vamos
passar para o exemplo da Figura 13.3, 376 que os contm.
Vamos nos concentrar por enquanto em tipos de entidades
EMPREGADO e PRO
GRAMADOR. Para simplificar, suponha que programadores tenham
habilidade em apenas uma linguagem de programao (isto , a
propriedade LING univalorada). Ento:*
- O supertipo EMPREGADO mapeado em uma varivel de relao
bsica, digamos EMP, da maneira usual (isto , como j
discutimos).
- O subtipo PROGRAMADOR mapeado em outra varivel de
relao bsica, digamos PGMR, com chave primria igual da
varivel de relao bsica do supertipo e com outros
atributos correspondentes s propriedades que se aplicam
apenas a empregados que tambm so programadores (isto ,
apenas LING, no exemplo):
VAR PGMR BASE RELATION
{EMP# . . ., LING . . . }
PRIMARY KEY { EMP# } .. . ;
Alm disso, a chave primria de PGMR tambm uma chave
estrangeira, fazendo referncia de volta varivel de
relao EMP. Desse modo, tambm precisamos estender a
definio de acordo (em particular note as regras DELETE e
UPDATE):
VAR PGMR BASE RELATION
{EMP# . . ., LING . . . }
PRIMARY KEY { EMP#
FOREIGN KEY { EMP# } REFERENCES EMP
ON DELETE CASCADE
ON UPDATE CASCADE
- Tambm necessitamos de uma viso, digamos EMP PGMR, que
seja a juno das variveis de relaes supertipo e subtipo:
VAR EMPPGMR VIEW
EMP JOIN PGMR ;
Observe que essa juno (zero ou um) para um ela ocorre
sobre uma chave candidata e uma chave estrangeira associada,
e essa chave estrangeira ela prpria uma chave candidata.
Assim, a viso contm apenas os empregadores que so
programadores, em termos informais.
Dado este projeto:
- Podemos ter acesso a propriedades que se aplicam a todos os
empregados (por exemplo, para recuperao) usando a varivel
de relao bsica EMP.
- Podemos ter acesso a propriedades que se aplicam apenas a
programadores usando a varivel de relao bsica PGMR.
- Podemos ter acesso a todas propriedades que se aplicam a
programadores usando a viso
EMP_PGMR.
- Podemos inserir empregados que no so programadores usando
a varivel de relao bsica
EMP.
- Podemos inserir empregados que so programadores usando a
viso EMP_PGMR.
* Observe em particular que no mapeamos empregados e
programadores em algum tipo de construo de supertabela e
subtabela. Existe uma dificuldade conceitual, ou pelo menos
uma armadilha, nesse caso: apenas pelo fato de o tipo de
entidade Y ser um subtipo do tipo de entidade X no diagrama
E!R, no decorre que o anlogo relaciona! de Y seja um sub
qualquer
coisa do anlogo relaciona! de X e, na verdade, no .
Consulte a referncia [13.121. 377
J
- Podemos eliminar empregadores, programadores ou no, usando
a varivel de relao bsica EMP ou (somente para
programadores) a viso EMP_PGMR.
- Podemos atualizar propriedades que se aplicam a todos os
empregados usando a varivel de relao bsica EMP ou
(somente para programadores) a viso EMP_PGMR.
- Podemos atualizar propriedades que se aplicam apenas a
programadores usando a varivel de relao bsica PGMR.
- Podemos transformar um no programador existente em
programador inserindo o empregado na varivel de relao
bsica PGMR ou na viso EMP_PGMR.
- Podemos transformar um programador existente em no
programador eliminando o programador da varivel de relao
bsica PGMR.
- Fica como exerccio a considerao sobre os outros tipos de
entidades na Figura 13.3 (APLICAAO PROGRAMADOR e
SISTEMA_PROGRAMADOR).
13.6 UMA BREVE ANLISE
Nesta seo, examinaremos rapidamente certos aspectos do
modelo E/R com um pouco mais de profundidade. As discusses
que seguem foram tiradas em sua maior parte de um exame mais
longo dos mesmos tpicos pelo autor na referncia [13.8]. A
anlise e os comentrios adicionais podem ser encontrados na
anotao a muitas das referncias da Seo Referncias e
bibliografia no final do captulo.
O modelo E/R como base para o modelo relacional?
Comeamos considerando a abordagem E/R de uma perspectiva
ligeiramente diferente. Talvez seja bvio para voc que as
idias da abordagem E/R, ou algo muito prximo a essas
idias, devem ter sido as bases informais na mente de Codd
quando ele desenvolveu pela primeira vez o modelo relacional
formal. Como explicamos na Seo 13.2, a abordagem geral para
o desenvolvimento de um modelo estendido envolve quatro
grandes etapas, como a seguir:
1. Identificar conceitos semnticos teis.
2. Criar objetos formais.
3. Criar regras de integridade formais (metarrestries)
4. Criar operadores formais.
Porm, esses mesmos quatro passos tambm so aplicveis ao
projeto do modelo relacional bsico (e na verdade a qualquer
modelo de dados formal), no apenas a modelos estendidos
como o modelo E/R. Em outras palavras, para que Codd
construsse o modelo relacional bsico (formal), desde o
incio ele deve ter tido em mente alguns conceitos
semnticos teis (informais), e esses conceitos basicamente
devem ter sido os do modelo E/R, ou algo muito prximo. De
fato, os artigos do prprio Codd vm em apoio a essa
afirmao. No primeiro de todos os seus artigos sobre o
modelo relacional (a verso anterior da referncia [5.1],
encontramos o seguinte):
O conjunto de entidades de um dado tipo de entidade pode ser
visto como uma relao, e chamaremos a essa relao uma
relao de tipo de entidade... As relaes restantes.., esto
entre tipos de entidades e so... chamadas relaes entre
entidades... Uma propriedade essencial de toda relao entre
entidades que ela inclui pelo menos duas chaves
estrangeiras que se referem a tipos de entidades distintos ou
a um tipo de entidade comum desempenhando papis distintos.
Aqui, Codd est claramente propondo que as relaes sejam
usadas para representar tanto entidades quanto
relacionamentos. Porm e esse um grande porm o
importante que relaes so objetos formais e o modelo
relacional um sistema formal. A essncia da contribuio de
Codd est nb fato
378 de ele ter encontrado um bom modelo formal para certos
aspectos do mundo real.
Em contraste com o texto anterior, o modelo de
entidades/relacionamentos no (ou, peio menos, no
principalmente) um modelo formal. Em vez disso, ele consiste
em um conjunto de conceitos informais, correspondendo ao
Passo 1 (apenas) dos quatro passos mencionados antes. (Alm
disso, esses aspectos formais que ele possui no parecem ser
significativamente diferentes dos aspectos correspondentes do
modelo relaciona1 bsico consulte a discusso adicional
sobre esse ponto na prxima subseo.) Alm disso, embora
indiscutivelmente seja til ter um arsenal de conceitos
Passo 1 disposio para fins dc projeto de banco de dados
(entre outros fins), permanece o fato de no ser possvel
completar projetos de banco de dados sem os objetos formais e
as regras dos Passos 2 e 3, e muitas outras tarefas no podem
ser realizadas de modo algum sem os operadores formais do
Passo 4.
Observe que as observaes anteriores no pretendem sugerir
que o modelo E/R no til. Ele . Porm, isso no tudo. E
um pouco estranho perceber que a primeira descrio
publicada do modelo E/R informal aparece vrios anos depois
da primeira descrio publicada do modelo relacional formal,
dado que (como vimos) este ltimo foi originalmente baseado
em algumas idias bem parecidas com as idias do modelo E/R.
O modelo E/R um modelo de dados?
Pelas discusses anteriores, no fica nem mesmo claro que o
modelo E/R realmente um modelo de dados, no sentido em
que temos usado esse termo neste livro at agora (isto ,
como um sistema formal envolvendo aspectos estruturais de
integridade e manipulao). Certamente, a expresso
modelagem E/R em geral considerada como o processo de
decidir a estrutura (somente) do banco de dados, embora
tenhamos includo tambm algum tratamento de aspectos de
integridade (a maioria relacionada com chaves primrias e
estrangeiras) em nossas discusses nas Sees de 13.3 a
13.5.* Porm, uma leitura cuidadosa da referncia [13.15]
poderia sugerir que o modelo E/R de fato um modelo de
dados, mas um modelo que essencialmente apenas uma fina
camada sobre o modelo relacional bsico (ele certamente no
candidato a substituir o modelo relacional, como algumas
pessoas tm sugerido). Justificamos nossa afirmao desta
forma:
- Primeiro, o objeto de dados fundamental de E/R isto , o
objeto fundamental formal, em oposio aos objetos informais
entidade, relacionamento etc. a relao n-ria.
- Os operadores E/R so basicamente os operadores da lgebra
relacional. (Na verdade, a referncia [13.5] no muito
clara quanto a esse ponto, mas parece propor um conjunto de
operadores que so estritamente menos poderosos que aqueles
da lgebra relacional; por exemplo, no h aparentemente
nenhuma unio e nenhuma juno explcita.)
- na rea da integridade que o modelo E/R tem algumas
funes (secundrias) que o modelo relacional no tem: o
modelo E/R inclui um conjunto de regras de integridade
embutidas, correspondendo a algumas, mas no todas, as regras
de chaves estrangeiras discutidas neste livro. Assim, onde um
sistema relacional puro exigiria que o usurio formulasse
explicitamente certas regras de chaves estrangeiras, um
sistema E/R exigiria apenas que o usurio declarasse que uma
dada varivel de relao representa um certo tipo de
relacionamento, e ento certas regras de chaves estrangeiras
seriam ento entendidas.
* E claro que existe aqui uma deficincia importante: o
modelo E/R completamente incapaz de lidar com restries de
integridade ou regras de negcio, exceto em alguns casos
especiais (que admitimos ser importantes). Aqui est uma
citao tpica: as regras declarativas so complexas demais
para serem capturadas como parte do modelo do negcio e devem
ser definidas separadamente pelo analista/desenvolvedor
[13.271. E ainda existe um forte argumento de que o projeto
de bancos de dados deve ser exatamente um projeto de
determinar as restries aplicveis (veja as referncias
[8.18 e 8.191, e tambm
[13.17 a 13.19]). 379
Entidades e relacionamentos
J mencionamos vrias vezes neste livro que o melhor modo de
ver os relacionamentos simplesmente consider-los uma
espcie particular de entidade. Em contraste, uma condio
sine qua non da abordagem E/R que os dois conceitos sejam
diferenciados de alguma maneira. Em nossa opinio, qualquer
abordagem que insista em fazer tal distino tem um grave
defeito, porque (como mencionamos na Seo 13.2) o mesmo
objeto pode, de forma bastante legtima, ser visto como uma
entidade por alguns usurios e como um relacionamento por
outros. Considere, por exemplo, um casamento:
- De um certo ponto de vista, um casamento claramente um
relacionamento entre duas pessoas (amostra de consulta: Com
quem Elizabeth Taylor estava casada em 1975?).
- De outro ponto de vista e com igual clareza, um casamento
uma entidade em si (amostra de consulta: Quantos casamentos
foram realizados nesta igreja desde abril?).
Se a metodologia de projeto insistir na distino entre
entidade e relacionamento, ento (na melhor das hipteses) as
duas interpretaes sero tratadas assimetricamente (isto ,
consultas de entidades e consultas de relacionamentos
tomaro formas bastante diferentes); no pior caso, uma das
interpretaes no ser admitida de modo algum (isto , ser
impossvel formular uma classe de consultas).
Como mais uma ilustrao desse fato, considere a seguinte
declarao de um tutorial sobre a abordagem E/R na referncia
[13.17]:
E comum que se representem inicialmente alguns
relacionamentos como atributos [significando,
especificamente, chaves estrangeiras] durante a elaborao do
projeto de esquema conceitual, e depois que se convertam
esses atributos em relacionamentos, medida que o projeto
progride e mais bem entendido.
Entretanto, o que acontece se um atributo passa a ser uma
chave estrangeira em algum momento posterior? isto , se o
banco de dados evoluir depois de j existir por algum tempo?
Se levarmos esse argumento sua concluso lgica, projetos
de bancos de dados devero envolver somente relacionamentos,
sem absolutamente nenhum atributo. (Na verdade, h algum
mrito nessa posio. Consulte a anotao referncia
[13.181, no final do captulo.)
Uma observao final
Existem muitos outros esquemas de modelagem semntica alm do
esquema especfico de modelagem E/R que estamos examinando
neste captulo. Contudo, a maioria desses esquemas guarda uma
forte semelhana em relao a cada um dos outros; em
particular, quase todos eles podem ser caracterizados por
simplesmente fornecerem uma notao grfica para representar
certas restries de chaves estrangeiras, alm de alguns
outros itens e fragmentos. E claro que tais representaes
grficas podem ser teis em uma espcie de quadro geral,
mas so simplistas demais para realizar todo o trabalho de
projeto.* Em particular, como observamos antes, elas
normalmente no conseguem lidar com restries de integridade
gerais. Por exemplo, como voc representaria uma dependncia
de juno em um diagrama E/R?
13.7 RESUMO
Comeamos este captulo apresentando uma breve introduo
idia geral de modelagem semntica. H quatro grandes passos
envolvidos, dos quais o primeiro informal e os outros
formais:
1. Identificar conceitos semnticos teis.
2. Criar objetos simblicos correspondentes.
*Uma observao triste sobre o estado da indstria que
solues simples so populares mesmo quando so simples
demais. Sobre esse tema, concordamos com Einstein, que disse
certa vez: tudo deve ser to simples quanto possvel porm,
no mais sim380 pies.
3. Criar regras de integridade correspondentes.
4. Criar operadores correspondentes.
Alguns conceitos semnticos teis so entidade, propriedade,
relacionamento e subtipo. Nota: tambm enfatizamos que (a)
haver provavelmente muitos conflitos de terminologia entre o
nvel de modelagem semntica (informal) e o nvel de sistema
de suporte (formal) subjacente, e (b) esses conflitos podero
causar confuso! Pedimos desculpas ao leitor.
O objetivo final da pesquisa sobre a modelagem semntica o
de tornar os sistemas de banco de dados um pouco mais
inteligentes. Um objetivo mais imediato fornecer uma base
para um ataque sistemtico ao problema de projeto de banco de
dados. Descrevemos a aplicao de um modelo semntico em
particular, o modelo de entidades/relacionamentos de Chen,
para o problema de projeto.
Em conexo com o que foi dito, vale a pena repetir que o
artigo original de Chen [13.51 realmente continha duas
propostas distintas e mais ou menos independentes; ele
propunha o modelo E/R em si e tambm a tcnica de diagramao
de E/R. Como dissemos na Seo 13.4, a popularidade do modelo
E/R pode provavelmente ser atribuda mais existncia dessa
tcnica de diagramao que a qualquer outra causa. Porm, o
importante que no necessrio adotar todas as idias do
modelo para usar os diagramas; perfeitamente possvel usar
diagramas E/R como base para qualquer metodologia de projeto
talvez uma metodologia baseada no RM/T, por exemplo [13.6].
Argumentos a respeito da adequao relativa da modelagem E/R
e de algumas outras abordagens como uma base para um projeto
de banco de da- dos com frequncia parecem omitir esse ponto.
Vamos comparar tambm as idias de modelagem semntica (e do
modelo E/R em particular) com a disciplina de normalizao
descrita nos Captulos 11 e 12. A disciplina de normalizao
envolve a reduo de grandes variveis de relaes a outras
menores; ela pressupe que temos algum nmero pequeno de
variveis de relaes grandes como entrada e manipula essa
entrada para produzir um grande nmero de pequenas variveis
de relaes como sada isto , mapeia variveis de relaes
grandes em pequenas ( claro que estamos falando aqui de modo
muito informal!). Contudo, a disciplina de normalizao no
tem absolutamente nada a dizer sobre como chegamos a essas
grandes variveis de relaes. Ao contrrio, as metodologias
top-down como a que foi descrita neste captulo, enfrentam
exatamente esse problema; transformam o mundo real em grandes
relaes. Em outras palavras, as duas abordagens (projeto
top-down e normalizao) se com plementam. O procedimento
geral sugerido para projeto ento este:
1. Usar a abordagem E/R (ou outra metodologia anloga*) para
gerar grandes variveis de relaes representando entidades
regulares, entidades fracas etc.
2. Em seguida, usar as idias de normalizao avanada para
desmembrar essas grandes variveis de relaes, reduzindo-
as a pequenas variveis de relaes.
Porm, voc deve ter percebido, pela natureza das discusses
no texto do captulo, que a modelagem semntica em geral no
nem de longe to rigorosa ou claramente definida quanto a
disciplina de normalizao discutida nos Captulos 11 e 12. A
razo para essa situao que (como indicamos na introduo
a esta parte do livro) o projeto de bancos de dados ainda
em grande parte um exerccio subjetivo, e no objetivo;
existem relativamente poucos princpios realmente slidos que
podem ser usados como base para soluo do problema (os
poucos princpios que existem so, claro, basicamente
aqueles que foram discutidos nos dois captulos anteriores).
As idias deste captulo podem ser consideradas mais como
regras prticas, embora paream funcionar razoavelmente bem
em situaes do dia-a-dia.
Existe um ltimo detalhe que vale a pena mencionar de forma
explcita. Embora todo o assunto ainda seja um tanto
subjetivo, h uma rea especfica em que as idias da
modelagem semntica podem ser hoje muito relevantes e teis
ou seja, a rea de dicionrios de dados. O dicionrio de
dados pode ser visto em alguns aspectos como o banco de
dados do projetista de banco de dados; afinal, ele um
banco de dados no qual so registradas decises de projeto de
bancos de dados, entre outras coisas [13.2]. O es Nossa
abordagem preferida seria anotar os predicados que descrevem
a empresa, e depois mapear esses predicados (diretamen te em
restries de bancos de dados e de variveis de relaes, da
maneira descrita no Captulo 8. 381
tudo da modelagem semntica pode ser assim muito til no
projeto do sistema de dicionrio, porque ele identifica as
espcies de objetos que o prprio dicionrio precisa admitir
e reconhecer por exemplo, categorias de entidades (como
as entidades regulares e fracas do modelo E!R), regras de
integridade (como a noo de participao total e parcial em
um relacionamento do modelo E/R), supertipos e subtipos de
entidades, e assim por diante.
EXERCICIOS
13.1 O que voc entende por modelagem semntica?
13.2 Identifique os quatro grandes passos envolvidos na
definio de um modelo estendido como o modelo
E/R.
13.3 Defina os seguintes termos de E/R:
entidade propriedade
entidade fraca propriedade de chave
entidade regular relacionamento
herana supertipo, subtipo
hierarquia de tipos conjunto de valores
13.4 D exemplos de:
a. Um relacionamento muitos para muitos no qual um dos
participantes uma entidade fraca.
b. Um relacionamento muitos para muitos no qual um dos
participantes outro relacionamento.
c. Um relacionamento muitos para muitos que tem um subtipo.
d. Um subtipo que tem uma entidade fraca associada que no se
aplica ao supertipo.
13.5 Trace um diagrama E/R para o banco de dados de ensino do
Exerccio 8.10 no Captulo 8.
13.6 Trace um diagrama E/R para o banco de dados de pessoal
da empresa do Exerccio 11.3 no Captulo 11. Use esse
diagrama para derivar um conjunto apropriado de definies de
variveis de relaes bsicas.
13.7 Trace um diagrama E/R para o banco de dados de entrada
de pedidos do Exerccio 11.4 no Captulo 11. Use esse
diagrama para derivar um conjunto apropriado de definies de
variveis de relaes bsicas.
13.8 Trace um diagrama EIR para o banco de dados de vendas do
Exerccio 12.3 no Captulo 12. Use esse diagrama para derivar
um conjunto apropriado de definies de variveis de relaes
bsicas.
13.9 Trace um diagrama E/R para o banco de dados revisado de
vendas do Exerccio 12.5 no Captulo 12. Use esse diagrama
para derivar um conjunto apropriado de definies de
variveis de relaes bsicas.
REFERNCIAS E BIBLIOGRAFIA
A extenso da lista de referncias a seguir se deve em grande
parte ao nmero de metodologias de projeto concorrentes que
encontramos no mundo de bancos de dados de hoje, tanto nos
meios industriais quanto acadmicos. Existe pouco consenso
nesse campo; o esquema de EIR discutido no texto do captulo
certamente o enfoque de uso mais amplo, mas nem todos
concordam com ele (ou gostam dele). Na verdade, devemos
frisar que as abordagens mais conhecidas no so
necessariamente as melhores abordagens. Observamos ainda que
muitos produtos disponveis comercialmente so mais que
apenas ferramentas de projeto de bancos de dados; em vez
disso, o que elas fazem gerar aplicaes inteiras telas
interativas, lgica de aplicao, procedimentos trigger etc.,
alm de definies (esquemas) de bancos de dados em
particular. Algumas outras referncias relevantes para o
material deste captulo so o relatrio da ISO sobre o
esquema conceitual [2.3]; o livro de Kent Data and Reality
[2.41 e os livros de Ross sobre regras de negcio [8.18 e
8.19].
13.1 J. R. Abrial: Data Semantics, em J. W. Klimbie e K. L.
Koffeman (editores), Data Base Managenment. Amsterd, Pases
Baixos: North-Holland/Nova York, NY: Elsevier Science (1974).
Uma das primeiras propostas na rea de modelagem semntica. A
citao a seguir capta muito bem o esprito geral do artigo
(alguns diriam do assunto como um todo): Sugesto para o
leitor: se estiver procu382 rando uma definio do termo
semntica, pare de ler porque no existe essa definio neste
artigo.
13.2 Philip A. Bernstein: The Repository: A Modern Vision.
Database Programming and Design 9, Nmero 12 (dezembro de
1996).
Parece haver, no momento em que escrevemos, um movimento no
sentido de substituir o termo dicionrio pelo termo
repositrio. Um sistema de repositrio um SGBD
especializado para a administrao de metadados metadados
no apenas para SGBDs, mas para todos os tipos de ferramentas
de software:
ferramentas para projeto, desenvolvimento e distribuio de
software, como tambm ferramentas para gerenciamento de
projetos eletrnicos, projetos mecnicos. Web sites e muitos
outros tipos de documentos formais relacionados a atividades
de engenharia, para citar Bernstein. Esse artigo um
tutorial sobre conceitos de repositrios.
13.3 Michael Blaha e William Premerlani: Object-Oriented
Modeling and Design for Database Applications, Upper Saddle
River. N.J.: Prentice-Hali (1998).
Descreve em profundidade uma metodologia de projeto chamada
Object Modeling Technique (OMT). A OMT pode ser considerada
uma variao do modelo E/R seus objetos so basicamente
entidades do E/R mas ele engloba muito mais que apenas o
projeto de bancos de dados especificamente. Veja tambm a
anotao referncia [13.32].
13.4 Grady Booch: Object-Oriented Design with Applications.
Redwood City, Calif.: Benjamin/Cummings (1991).
Consulte a anotao referncia [13.32].
13.5 Peter Pin-Shan Chen: The Entity-Relationship Model -
Toward a Unified View of Data, ACM TODS 1, Nmero 1 (maro
de 1976). Republicado em Michael Stonebraker (editor),
Readings in Database Systems. San Mateo, Calif.: Morgan
Kaufmann (1988).
O artigo que introduziu o modelo E/R e os diagramas E/R. Como
foi dito no texto do captulo, o modelo foi consideravelmente
revisado e aprimorado com o tempo; certamente as explicaes
e definies dadas nesse primeiro artigo eram bastante
imprecisas, de modo que tais revises eram sem dvida
necessrias. (Uma das crticas ao modelo E/R sempre foi a de
que os termos no parecem ter um nico significado bem
definido, mas em vez disso so interpretados de muitos modos
diferentes. E claro que verdade que todo o campo de bancos
de dados assombrado pela terminologia imprecisa e
conflitante, mas essa rea em particular pior que a
maioria.) Alguns exemplos:
- Como foi dito na Seo 13.3, uma entidade definida como
uma coisa que pode ser identificada distintamente e um
relacionamento como uma associao entre entidades. A
primeira questo que surge ento a seguinte: um
relacionamento uma entidade? Um relacionamento claramente
uma coisa que pode ser identificada distintamente, mas
sees posteriores do artigo parecem reservar o termo
entidade para designar algo que definitivamente no um
relacionamento. De modo presumvel, essa ltima a
interpretao desejada pois, do contrrio, por que o termo
modelo de entidades/relacionamentos? Porm, o artigo
realmente no claro.
- Entidades e relacionamentos podem ter atributos (usamos o
termo propriedades no texto do captulo). De novo, o artigo
ambivalente quanto ao significado do termo em princpio,
ele define um atributo como uma propriedade que no a chave
primria, nem qualquer componente dela (compare com a
definio relacional); porm, mais adiante, ele utiliza o
termo no sentido relacional.
- Vamos supor que a chave primria para um relacionamento
seja a combinao das chaves estrangeiras identificando as
entidades envolvidas no relacionamento (porm, a expresso
chave estrangeira no usada). Essa suposio s
apropriada para relacionamentos muitos para muitos, e mesmo
assim nem sempre. Por exemplo, considere a varivel de
relao FPD {F#,P#,DATA,QDE}, que representa remessas de
certas peas por certos fornecedores em certas datas; suponha
que o mesmo fornecedor possa enviar a mesma pea mais de um
vez, mas no mais de um vez na mesma data. Ento, a chave
primria (ou, pelo menos, a nica chave candidata) a
combinao {F#,P#,DATA}; no entanto, poderamos optar por
considerar fornecedores e peas como entidades, mas no
datas.
13.6 E. F. Codd: Extending the Database Relational Model to
Capture More Meaning, ACM TODS 4, Nmero 4 (dezembro de
1979).
Nesse artigo, Codd introduziu uma verso estendida do
modelo relacional, que chamou RM/T. O
RM/T trata de algumas questes idnticas ao modelo E/R,
embora seja mais cuidadosamente definido.
Algumas diferenas imediatas entre os dois so: primeiro, o
PJvI/T no faz distines desnecessrias entre 383
13.7 C. J. Date: A Note on One-to-One Relationships, em
RelationalDatabase Writings 1985-1989, Reading, Mass.:
Addison-Wesley (1990).
Uma longa discusso sobre o problema de relacionamentos um
para um, que se mostram bem mais complicados do que poderiam
parecer primeira vista.
13.8 C. J. Date: Entity/Relationship Modeling and the
Relational Model, em C. J. Date e Hugh Darwen, Relational
Database Writings 1989-1991. Reading, Mass.: Addison-Wesley
(1992).
13.9 C. J. Date: Don't Encode Information into Primary
Keys! em C. J. Date e Hugh Darwen, Relational Data- base
Writings 1989-1991. Reading, Mass.: Addison-Wesley (1992).
Apresenta uma srie de argumentos informais contra o que s
vezes se chama chaves inteligentes. Consulte tambm a
referncia [13.10] para ver algumas recomendaes
relacionadas a respeito de chaves estrangeiras.
13.10 C. J. Date: Composite Keys em C. J. Date e Hugh
Darwen, Relational Database Writings 1989-1991. Reading.
Mass.: Addison-Wesley (1992).
Para citar do resumo: Argumentos pr e contra a incluso de
[chaves] compostas no projeto de um banco de dados relacional
so resumidos, e tambm so oferecidas algumas
recomendaes. Em particular, o artigo mostra que chaves
substitutas [13.16] nem sempre so uma boa idia.
13.11 C. J. Date: A Database Design Dilemma?, no Web site
DBP&D, em www.dbpd.com (janeiro de 1999). Consulte tambm o
Apndice B da referncia [3.3].
Diante disso, um dado tipo de entidade digamos empregados
poderia ser representado em um sistema relacional por um tipo
empregados (isto , um domnio) ou por uma varivel de
relao empregados. Esse pequeno artigo oferece orientao
sobre como escolher entre as duas opes.
13.12 C. J. Date: Subtables and Supertables (em duas
partes), no Web site DBP&D, em www.dbpd.com (a ser
apresentado no final de 2000 ou no incio de 2001). Consulte
tambm o Apndice D da referncia [3.3].
Frequentemente, imaginamos que a herana de tipo de entidade
deve ser tratada em um contexto relacional atravs do que se
chama subtabelas e supertabelas o mapeamento de subtipo
de entidade para uma subtabela e o mapeamento de supertipo
de entidade para uma supertabela. Por exemplo, a SQL3
admite tal abordagem no momento em que escrevemos (consulte o
Apndice B), como tambm determinados produtos. Esse artigo
contesta vigorosamente essa idia.
13.13 Ramez Elmasri e Shamkant B. Navathe: Fundamentais of
Database Systems (2 edio). Redwood City, Calif.:
BenjamimJCummings (1994).
Esse livro-texto geral sobre gerenciamento de bancos de dados
inclui dois captulos completos (de um total de 25) sobre o
uso de tcnicas de E/R para projetos de bancos de dados.
13.14 David W. Embley: Object Database Development: Concepts
and Principies. Reading, Mass.: Addison-Wesley (1998).
Apresenta uma metodologia de projeto baseada no OSM (Object-
Oriented Systems Model). Partes do OSM lembram o ORM [13.17 a
13.19].
13.15 Candace C. Fleming e Barbara von Hall: Handbook
ofReiationai Database Design. Reading, Mass.: Addison-Wesley
(1989).
Um bom guia pragmtico para projetos de bancos de dados em um
sistema relacional, com exemplos especficos baseados no
produto DB2 da IBM e no produto DBC/1012 da Teradata (agora
NCR). So focalizadas tanto questes de projeto lgico quanto
fsico embora o livro utilize o termo projeto lgico para
representar aquilo que chamaramos projeto relacional, e o
termo projeto relacional para incluir pelo menos alguns
aspectos do que chamaramos projeto fsico!
13.16 P. Hail, J. Owlett e S. J. P. Todd: Relations and
Entities, em G. M. Nijssen (editor), Modelling in Data Base
Management Systems. Amsterd, Pases Baixos: North-
Holland/Nova York, NY: Elsevier Science (1975).
O primeiro artigo a tratar o conceito de chaves substitutas
em detalhes (o conceito foi incorporado mais tarde ao Rv1/T
[13.61). Chaves substitutas so chaves no sentido relacional
usual, mas tm as seguintes propriedades especficas:
385
- Sempre envolvem exatamente um atributo.
- Seus valores servem unicamente como substitutos (da o
nome) para as entidades que representam. Em outras palavras,
tais valores servem apenas para representar o fato de que as
entidades correspondentes existem eles no conduzem mais
nenhuma informao ou significado adicional.
- Quando uma nova entidade inserida no banco de dados, ela
recebe um valor de chave substituta que nunca foi usado antes
e nunca ser usado novamente, mesmo que a entidade em questo
seja eliminada mais tarde.
No caso ideal, os valores de chaves substitutas seriam
gerados pelo sistema, mas o fato de serem gerados pelo
sistema ou pelo usurio no tem nenhuma relao com a idia
bsica de chaves substitutas.
Vale a pena enfatizar que as substitutas no so (como alguns
autores parecem pensar) o mesmo que IDs de tuplas. Para
comear e para dizer o bvio as IDs de tuplas identificam
tuplas e as substitutas identificam entidades, e com certeza
no existe nada semelhante a uma correspondncia de um para
um entre tuplas e entidades (pense nas IDs de tuplas para
tuplas derivadas em particular). Alm disso, as IDs de tuplas
tm conotaes de desempenho, enquanto as substitutas no
tm; o acesso a uma tupla atravs de sua ID de tupla
geralmente considerado rpido (estamos supondo aqui que as
tuplas pelo menos, tupIas em relaes bsicas so
mapeadas diretamente para o armazenamento fsico, como de
fato acontece na maioria dos produtos de hoje). Alm disso,
as IDs de tuplas costumam estar ocultas do usurio, enquanto
as substitutas no devem estar (devido ao Princpio da
Informao); em outras palavras, no possvel armazenar uma
ID de tupla como um valor de atributo, enquanto certamente
possvel armazenar uma substituta como um valor de atributo.
Em resumo: as substitutas so um conceito lgico; as IDs de
tuplas so um conceito fsico.
13.17 Terry Halpin: Conceptual Schema and Relational Database
Design (2 edio). Sydney. Austrlia: Prentice-HalI of
Australia Pty. Ltd. (1995).
Um tratamento detalhado do ORIvI (veja as anotaes para as
duas referncias seguintes).
13.18 Terry Halpin: Business Rules and Object-Role
Modeling. DBP&D 9, Nmero 10 (outubro de 1996).
Uma introduo excelente modelagem de papel de objetos, ORM
[13.17]. Halpin comea observando que [diferentemente do]
modelo EIR, que tem dezenas de dialetos diferentes, o ORM tem
somente alguns dialetos com diferenas apenas secundrias.
(Nota: um desses dialetos o NIAM [13.29].) O ORJvI tambm
conhecido como modelagem baseada em fatos, pois o que o
projetista faz escrever em linguagem natural ou em uma
notao grfica especial uma srie de fatos elementares (ou
melhor, tipos de fatos) que juntos caracterizam o negcio a
ser modelado. Os exemplos de tais tipos de fatos poderiam
ser:
- Cada Empregado tem no mximo um Empnome.
- Cada Empregado se reporta a no mximo um Empregado.
- Se o Empregado ei se reporta ao Empregado e2, ento no
possvel que o Empregado e2 se reporte ao Empregado ei.
- Nenhum Empregado pode dirigir e avaliar o mesmo Projeto.
Como voc pode ver, os tipos de fatos so realmente
predicados ou regras do negcio; como sugere o ttulo do
artigo de Halpin, o ORM est muito mais no esprito da
abordagem para o projeto de bancos de dados preferida pelos
defensores das regras do negcio [8.18 e 8.19] e, na
verdade, tambm por este autor. Em geral, os fatos
especificam papis desempenhados por objetos em
relacionamentos (da o nome modelagem de papis de objetos,
claro). Observe que (a) o termo objetos aqui realmente
significa entidades, no objetos no sentido especial descrito
na Parte VI deste livro, e (b) relacionamento no so
necessariamente binrios. Porm, os fatos so elementares
eles no podem ser decompostos em fatos menores. Nota: a
idia de que o banco de dados deve conter somente fatos
elementares (ou irredutveis) no nvel conceitual foi
proposta anteriormente por HaIl, Owlett e Todd [13.161.
Observe que o ORM no tem nenhum conceito de atributos.
Como consequncia, os projetos ORM so conceitualmente mais
simples e mais robustos que seus equivalentes em E/R, como o
artigo mostra (nessa conexo, veja tambm a anotao
referncia [13.19]). Porm, os atributos podem aparecer e
aparecem em projetos de E/R ou SQL gerados (automaticamente)
a partir de um projeto ORM.
386
O ORM enfatiza tambm o uso de fatos de amostra (isto ,
instncias de fatos de amostra que chamaramos proposies)
como um modo de permitir ao usurio final validar o projeto.
O argumento que essa abordagem direta no caso da
modelagem baseada em fatos, mas muito menos direta no caso da
modelagem E/R.
Existem, claro, muitos modos logicamente equivalentes para
descrever uma determinada empresa e, portanto, muitos
esquemas ORM logicamente equivalentes. O ORM inclui ento um
conjunto de regras de transformao que permitem a
transformao de esquemas logicamente equivalentes uns nos
outros; ento, uma ferramenta ORM pode executar alguma
otimizao no projeto como especificado pelo projetista. Ela
tambm pode, como mencionamos antes, gerar um esquema de E/R
ou de SQL a partir de um esquema ORM. E pode executar um
processo de engenharia reversa de um esquema ORM a partir de
um esquema E/R ou SQL existente. Dependendo do SGBD de
destino, um esquema de SQL gerado pode incluir restries
declarativas (no estilo da SQL/92), ou essas restries podem
ser implementadas por meio de procedimentos armazenados ou
ativados. A propsito, em relao s restries, observe que
diferente do modelo E/R o ORM inclui por definio uma
linguagem rica para expressar restries. (Porm, Halpin
admite na referncia [13.19] que nem todas as regras de
negcio podem ser expressas na anotao grfica do ORM
ainda necessrio texto para esse fim.)
Finalmente, um esquema ORM pode ( claro) ser considerado
como uma viso abstrata de nvel muito alto do banco de dados
(de fato, diramos que ela est bem prxima de uma viso
relacional pura, talvez um pouco disciplinada). Como tal, ela
pode ser consultada diretamente. Consulte a anotao
referncia [13.19], imediatamente a seguir.
13.19 Terry Halpin: Conceptual Queries. Data Base
Newsletter 26, Nmero 3 (maro/abril de 1998).
Para citar o resumo: a formulao de consultas no triviais
em linguagens relacionais como SQL e QBE pode ser assustadora
para os usurios finais. Con Quer, uma nova linguagem de
consulta conceitual baseada na modelagem de papis de objetos
(ORM) permite ao usurio apresentar consultas de um modo
prontamente compreensvel ... Este artigo destaca as
vantagens de tal linguagem sobre as linguagens de consulta
tradicionais para especificao de consultas e regras do
negcio.
Entre outras coisas, o artigo discute uma consulta em ConQuer
acompanhando de certo modo estas linhas:
/Employee
+ drives Car
+ works for /Branch
(Obter empregado e escritrio para empregados que dirigem
carros.) Se empregados podem dirigir qualquer nmero de
carros, mas trabalham apenas em um escritrio, o projeto de
SQL subjacente envolver duas tabelas, e o cdigo de SQL
gerado ser semelhante a:
SELECT DISTINCT X1.EMP#, X1.BRANCH#
FROM EMPLOYEE AS Xl, DRIVES AS X2
WHERE Xl.EMP# = X2.EMP#
Agora, suponha que se torne possvel para empregados o
trabalho em vrios escritrios ao mesmo tempo.
Ento, o projeto de SQL subjacente ter de mudar para
envolver trs tabelas em vez de duas, e o cdigo de
SQL gerado tambm ter de mudar:
SELECT DISTINCT XL.EMF'#, X3.BRANCH#
FROM EMPLOYEE AS Xl, DRIVES AS X2, WORKS FOR AS X3
WHERE X1.EMP# = X2.EMP# AND Xl.EMP# X3.EMP#
Porm, a formulao em ConQuer permanece inalterada.
Como ilustra o exemplo anterior, uma linguagem como ConQuer
pode ser considerada como fornecendo uma forma
particularmente forte de independncia de dados lgica.
Porm, para explicar essa observao precisamos primeiro
refinar um pouco a arquitetura ANSI/SPARC [2.1 e 2.2].
Dissemos no Captulo 2 que independncia de dados lgica
significa independncia de mudanas no esquema conceitual
mas a importncia do exemplo anterior est no fato de que
mudanas no esquema conceitual no ocorrem! A dificuldade
que os produtos de SQL de hoje no admitem de forma adequada
um esquema conceitual. Em vez dis- 387
so, eles admitem um esquema de SQL. Esse esquema de SQL pode
ser considerado em um nvel intermedirio entre o nvel
conceitual verdadeiro e o nvel interno ou fsico. Se uma
ferramentas ORM nos permite definir um esquema conceitual
verdadeiro, e depois mape-lo para um esquema de SQL, ConQuer
pode fornecer independncia de mudanas para esse esquema de
SQL ( claro, fazendo mudanas apropriadas no mapeamento).
No fica claro pelo artigo quais seriam os limites sobre a
expressiva capacidade de ConQuer. Halpin no examina essa
questo diretamente; porm, ele afirma (com certa
preocupao) que a linguagem deve permitir no caso ideal a
formulao de qualquer pergunta relevante aplicao; na
prtica, aceitvel um pouco menos que esse ideal
(ligeiramente reformulado). Ele tambm declara que a
caracterstica mais poderosa de ConQuer sua capacidade
para executar correlaes de complexidade arbitrria e
fornece o seguinte exemplo:
/Employee 1
+ lives in City 1
+ was bom in Country 1
+ supervises Employee2
+ lives in City 1
+ was bom in Country2 <> Country 1
(Obter empregados que supervisionam um empregado que mora na
mesma cidade que o supervisor, mas nasceu em um pas
diferente do supervisor.) Como diz Halpin: Experimente
fazer isso em SQL!
Finalmente, considerando ConQuer e as regras do negcio,
Halpin afirma: Embora a notao grfica do ORM possa
capturar mais regras de negcio que [abordagens E/RI, ele
ainda precisa ser suplementado por uma linguagem textual
[para expressar certas restries]. Esto sendo realizadas
consultas atualmente para adaptar ConQuer a esse fim.
13.20 M. M. Hammer e D. J. McLeod: The Semantic Data Model:
A Modelling Mechanism for Database Applications, Proc. 1978
ACM SIGMOD Int. Conf. on Management of Data, Austin, Texas
(maio/junho de 1978).
O SDM (Semantic Data Model modelo de dados semntico)
representa outra proposta para um formalismo de projeto de
bancos de dados. Como o modelo E/R, ele se concentra em
aspectos estruturais e (at certo ponto) de integridade, e
tem pouco ou nada a dizer sobre aspectos de manipulao.
Consulte tambm as referncias [13.21] e [13.24].
13.21 Michael Hammer e Dennis McLeod: Database Description
with SDM: A Semantic Database Model, ACM TODS 6, Nmero 3
(setembro de 1981).
Consulte a anotao referncia [13.20].
13.22 Richard HulI e Roger King: Semantic Database Modeling:
Survey, Applications, and Research Issues, ACM Comp. Surv.
19, Nmero 3 (setembro de 1987).
Um tutorial abrangente sobre o campo da modelagem semntica e
questes afins, relativas ao final dos anos oitenta. Esse
artigo um bom ponto de partida para uma investigao mais
profunda de questes e problemas de pesquisa em torno de
atividades de modelagem semntica. Consulte tambm a
referncia
[13.31].
13.23 Ivar Jacobson et ai.: Object-Oriented Software
Engineering (impresso revista). Reading. Mass.: Addison-
Wesley (1994).
Descreve uma metodologia de projeto chamada Object-Oriented
Software Engineering (OOSE). Como o OMT [13.3], as pores do
banco de dados, pelo menos, da OSE podem ser consideradas uma
variao do modelo E/R (como os do OMT, os objetos da OOSE
so basicamente entidades de E/R). A citao digna de nota:
a maioria dos mtodos usados hoje na indstria, tanto para
informaes quanto para desenvolvimento de sistemas tcnicos,
se baseia em uma decomposio funcional e/ou orientada para
dados do sistema. Essas abordagens diferem em vrios aspectos
da abordagem usada pelos mtodos orientados a objetos, nos
quais dados e funes esto altamente integrados. Parece que
aqui Jacobson aponta um desencontro significativo entre o
pensamento de objetos e de bancos de dados. Os bancos de
dados pelo menos bancos de dados compartilhados e de uso
geral, que so o foco principal de grande parte da
388 comunidade de bancos de dados devem estar dissociados
de funes; eles supostamente devem ser
projetados separados das aplicaes que os utilizam. Assim,
nos parece que o termo banco de dados usado na comunidade
de objetos significa na realidade um banco de dados
especfico da aplica do, e no aquele que compartilhado e
de uso geral.
Consulte tambm a anotao referncia [13.3 2] e a
discusso sobre bancos de dados de objetos no Captulo 24.
13.24 D. Jagannathan et ai.: SIM: A Database System Based on
the Semantic Data Model, Proc. 1988 ACM SIGMOD Int. Conf. on
Management of Data, Chicago, 111. (junho de 1988).
Descreve um produto comercial de SGBD baseado em um modelo
de dados semntico semelhante ao Semantic Data Model
proposto por Hammer e McLeod na referncia [13.20].
13.25 Warren Keuffel: Battle of the Modeling Techniques: A
Look at the Three Most Popular Modeling Notations for
Distilling the Essence of Data, DBMS 9, Nmero 9 (agosto de
1996).
As trs notaes mais populares so a modelagem E/R, o
Natural-Language Information Analysis Method, NIAM, de
Nijssen [13.29] e a Semantic Object Modeling, SOM. Keuffel
afirma que a modelagem E/R a av das outras duas, mas
critica sua falta de base formal; como ele diz, entidades,
relacionamentos e atributos (isto , propriedades) so todos
descritos sem referncia ao modo como foram descobertos.
NIAM muito mais rigoroso; quando suas regras so seguidas
de modo estrito, os projetos conceituais resultantes tm
muito mais integridade que os projetos produzidos com o uso
de outras metodologias, embora alguns desenvolvedores
considerem o rigor de NIAM restritivo demais (!). No caso de
SOM, ela lembra a modelagem E/R... com definies vagamente
articuladas de entidades, atributos e relacionamentos;
porm, ela difere da modelagem E/R pelo fato de admitir
atributos de grupos (isto , grupos de repetio), que
permitem a um objeto (ou entidade) conter outros. (A
modelagem E/R permite que entidades contenham grupos de
repetio de atributos mas no de outras entidades.)
13.26 Heikki Mannila e Kari-Jouko Rihii: The Design of
Relational Databases. Reading, Mass.: Addison-Wesley (1992).
Para citar o prefcio, este livro um livro-texto em nvel
de ps-graduao e uma referncia sobre o projeto de bancos
de dados relacionais. Ele cobre tanto a teoria da
dependncia e a normalizao de um lado, quanto a abordagem
E/R de outro, em cada caso de uma perspectiva bastante
formal. A lista (incompleta) de ttulos de captulos a seguir
d uma idia do alcance do livro:
- Princpios de projeto.
- Restries de integridade e dependncias.
- Propriedades de esquemas relacionais.
- Axiomatizaes para dependncias.
- Algoritmos para problemas de projeto.
- Aplicaes mapeamentos entre diagramas E/R e esquemas de
bancos de dados relacionais.
- Transformaes de esquemas.
- Exemplo de utilizao de bancos de dados em projetos.
As tcnicas descritas no livro foram implementadas pelos
autores na forma de uma ferramenta comercialmente disponvel,
chamada Design By Example.
13.27 Terry Moriarty: Enterprise View (coluna regular), DBP&D
10, Nmero 8 (agosto de 1997).
Descreve uma ferramenta de projeto e desenvolvimento de
aplicao comercial chamada Usoft (www.usoft.com) que permite
a definio de regras de negcio usando-se uma sintaxe
semelhante SQL e emprega essas regras para gerar a
aplicao (inclusive a definio do banco de dados).
13.28 G. M. Nijssen, D. J. Duke e 5. M. Twine: The Entity-
Relationship Data Model Considered Harmful, Proc. 6th
Symposium on Empirical Foundations of Information and
Software Sciences, Atlanta, Ga. (outubro de 1988).
O modelo E/R considerado prejudicial? Bem, parece que ele
tem muitas respostas para isso, inclusive:
- Confuso sobre tipos e variveis de relaes (veja a
discusso sobre O Primeiro Grande Erro no Captulo
25).
389
- O estranho negcio de subtabelas e supertabelas [13.12].
- Uma falha geral na apreciao do Princpio de Relatividade
de Banco de Dados (consulte o Captulo 9).
- Confuso sobre entidades e relacionamentos, descritas neste
captulo.
A referncia [13.281 aumenta a litania anterior. Para sermos
mais especficos, ela afirma que o modelo E/R:
- Fornece muitas maneiras superpostas para representar a
estrutura dos dados, complicando assim sem razo o processo
de projeto.
- No fornece nenhuma orientao sobre como escolher entre
representaes alternativas, e de fato pode exigir que os
projetos existentes sejam mudados desnecessariamente se as
circunstncias mudarem.
- Oferece bem poucas maneiras de representar a integridade de
dados, tornando assim impossveis certos aspectos do processo
de projeto ([ verdade] as restries podem ser expressas
formalmente em uma notao mais geral [como] lgica de
predicados, [mas] dizer que essa uma desculpa razovel para
omitir [restries] do prprio modelo de dados como dizer
que uma linguagem de programao adequada [mesmo se] forar
voc a chamar rotinas de linguagem assembly para implementar
tudo que no se consegue exprimir na prpria linguagem!).
- Ao contrrio da opinio popular, no serve como um bom
veculo de comunicao entre usurios e profissionais de
bancos de dados.
- Viola O Princpio da Conceitualizao: Um esquema
conceitual deve ... incluir [apenas] aspectos conceitualmente
relevantes, tanto estticos quanto dinmicos, do universo de
discurso, excluindo assim todos os aspectos de representao
de dados (externa ou interna), organizao de dados fsicos e
acesso, [e] todos os aspectos de uma representao de usurio
particular externa como formatos de mensagens, estruturas de
dados etc. [2.3]. De fato, os autores sugerem que o modelo
E/R essencialmente apenas uma reencarnao do antigo
modelo de rede CODASYL (consulte o Captulo 1). Poderia ser
essa forte inclinao em direo a estruturas de
implementao a principal razo pela qual o modelo E/R
recebeu to ampla aceitao na comunidade profissional [de
bancos de dados]?
O artigo tambm identifica numerosas deficincias adicionais
do modelo E/R no nvel dos detalhes. Em seguida, prope a
metodologia alternativa NIAM [13.29] como a soluo. Em
particular, enfatiza o fato de que NIAM no deve incluir a
distino desnecessria de E/R entre atributos e
relacionamentos.
13.29 T. W. OlIe, H. G. Sol e A. A. Verrijn-Stuart
(editores): Inforniation Systems Design Methodologies: A
Comparative Review. Amsterd, Pases Baixos: North-
Holland/Nova York, NY: Elsevier Science (1982).
Anais de uma conferncia do IFIP Working Group 8.1. Cerca de
treze metodologias diferentes so descritas e aplicadas a um
problema padro de avaliao. Uma das metodologias includas
o NIAM (veja a referncia [13.28]); o artigo em questo
deve ser um dos primeiros sobre o enfoque do NIAM. O livro
inclui ainda um conjunto de resenhas sobre algumas das
abordagens propostas, mais uma vez incluindo em particular o
NIAM.
13.30 M. P. Papazoglou: Unraveling the Semantics of
Conceptual Schemas, CACM 38, Nmero 9 (setembro de
1995).
Esse artigo prope uma abordagem para o que se poderia chamar
consultas de metadados isto , consultas que consideram o
significado (em oposio aos valores) dos dados no banco de
dados ou, em outras palavras, consultas que consideram o
prprio esquema conceitual. Um exemplo de tal consulta
poderia ser O que um empregado permanente?
13.31 Joan Peckham e Fred Maryanski: Semantic Data Models,
ACM Comp. Surv. 20, Nmero 3 (setembro de
1988).
Outro tutorial de pesquisa (consulte tambm a referncia
[13.22]).
13.32 Paul Reed: The Unified Modeling Language Takes Shape,
DBMS 11, Nmero 8 (julho de 1998).
A Unified Modeling Language, UML, uma outra notao grfica
para dar suporte tarefa de projeto e desenvolvimento de
aplicaes (em outras palavras, ela lhe permite desenvolver
aplicaes desenhando figuras). Ela tambm pode ser usada
para desenvolver esquemas de SQL. Nota: a UML provavelmente
se tornar significativa em termos comerciais, em parte
porque foi adotada como padro pelo OMG (Object Management
Group) de modo geral, ela tem uma forte caracterstica de
objetos. A linguagem
390 j aceita por uma grande variedade de produtos
comerciais.
A UML. admite a modelagem de dados e processos (nesse
aspecto, ela vai alm da modelagem E/R), mas no parece ter
muito a mostrar com relao a restries de integridade. (A
seo da referncia [13.321 intitulada From Models to Code:
Business Rules no menciona o termo declarativa de modo
algum! Em vez disso, ela se concentra na gerao de cdigo
procedural de aplicao para implementar processos. Aqui
est uma citao direta: A UML formaliza o que os
praticantes de objetos conhecem h anos: os objetos do mundo
real so melhor modelados como entidades autnomas que contm
ao mesmo tempo dados e funcionalidade. Em outro lugar,
encontramos: E evidente de uma perspectiva histrica que a
separao formal de dados e funes tornou frgil grande
parte dos nossos esforos de desenvolvimento de sofrware, na
melhor das hipteses. Essas observaes poderiam ser vlidas
do ponto de vista de uma aplicao, mas no est
absolutamente claro que elas sejam vlidas sob a perspectiva
de um banco de dados. Consulte, por exemplo, a referncia
[24.29].)
A UML cresceu a partir de um trabalho anterior de Booch no
mtodo de Booch [13.4], de Rumbaugh no OMT [13.31 e de
jacobson do QOSE [13.231. Booch, Rumbaugh ejacobson
produziram recentemente uma srie de livros sobre a UML, que
sem dvida se tornaro as referncias definitivas: The
Unified Modeling Language User Guide, The Unified Modeling
Language Reference Manual e The Unified Software Development
Process, todos publicados pela Addison-Wesley em 1999.
13.33 H. A. Schmid e J. R. Swenson: On The Semantics of the
Relational Data Base Model, Proc. 1975 ACM SIGMOD Int. Conf.
on Management of Data, San Jose, Calif.: (maio de 1975).
Esse artigo props um modelo semntico bsico anterior ao
trabalho de Chen no modelo E/R [13.5] mas, na verdade, era
muito semelhante a esse modelo (exceto na terminologia,
claro; Schmid e Swenson usam objeto independente, objeto
dependente e associao em vez das expresses de Chen
entidade regular, entidade fraca e relacionamento,
respectivamente).
13.34 J. F. Sowa: Conceptual Structures: Information
Processing in Mmd and Machine. Reading. Mass.: Addison-Wesley
(1984).
Esse livro no trata especificamente de sistemas de bancos de
dados, mas sim do problema geral de representao e
processamento do conhecimento. Contudo, partes dele so
diretamente relevantes para o assunto deste captulo. (As
observaes a seguir se baseiam em uma apresentao ao vivo
de Sowa em 1990, sobre a aplicao de estruturas conceituas
modelagem semntica.) Um problema importante com os
diagramas E/R e formalismos similares o fato de que eles
so estritamente menos poderosos que a lgica formal. Em
consequncia, so incapazes de lidar com certas
caractersticas importantes de projeto em particular, tudo
que envolve quantificadores, o que inclui a maioria das
restries de integridade
que a lgica formal pode tratar. (Os quantificadores foram
inventados por Frege em 1879, o que torna os diagramas E/R
uma espcie de lgica anterior a 1879!) Porm, a lgica
formal tende a ser difcil de ler; como diz Sowa, o clculo
de predicados a linguagem assembly da representao do
conhecimento. Os grafos conceituais constituem uma notao
grfica legvel e rigorosa que pode representar toda a
lgica. Por essa razo, eles so (como afirma Sowa) muito
mais adequados atividade de modelagem semntica que a
diagramas E/R e outros semelhantes.
13.35 J. M. Smith e D. C. P. Smith: Database Abstractions:
Aggregation, CACM 20, Nmero 6 (junho de 1977). Consulte a
referncia [13.36], imediatamente a seguir.
13.36 J. M. Smith e D. C. P. Smith: Database Abstractions:
Aggregation and Generalization, ACM TODS 2, Nmero 2 (junho
de 1977).
As propostas desses dois artigos, [13.35] e [13.36], tiveram
uma influncia significativa sobre o RM/T [13.61,
especialmente na rea de subtipos e supertipos.
13.3 7 Veda C. Storey: Understanding Semantic
Relationships, The VLDB Journal 2, Nmero 4 (outubro de
1993).
Citando o resumo: Modelos de dados semnticos tm sido
desenvolvidos [na comunidade de bancos de dados] com o uso de
abstraes como [subtipificao], agregao e associao.
Alm desses relacionamentos bem conhecidos, vrios
relacionamentos semnticos adicionais foram identificados por
pesquisadores em outras disciplinas como lingustica, lgica
e psicologia cognitiva. Esse artigo explora alguns [desses
ltimos] relacionamentos e discute ... seu impacto sobre
projetos de bancos de dados.
13.38 B. Sundgren: The Infological Approach to Data Bases,
emJ. W. Klimbie e K. L. Koffeman (editores), Data
Base Management. Amsterd, Pases Baixos: North-Holland/Nova
York, NY: Elsevier Science (1974). 391
A abordagem infolgica foi um dos primeiros esquemas de
modelagem semntica a serem desenvolvidos. Ele foi usado com
sucesso para projeto de bancos de dados durante muitos anos
na Escandinvia.
13.39 Dan Tasker: Fourth Generation Data: A Guide to Data
Analysis for New and Old Systems. Sydney, Austrlia:
Prentice-Hali of Austrlia Pty., Ltd. (1989).
Um bom guia pragmtico para projeto de bancos de dados, com
nfase em itens de dados individuais (isto , nos domnios).
Os itens de dados so classificados em trs tipos bsicos:
rtulo, quantidade e descrio. Os itens rtulo representam
entidades; em termos relacionais eles correspondem a chaves
primrias ou estrangeiras. Os itens quantidade representam
medidas, quantidades ou posies em uma escala (talvez uma
escala de data) e esto sujeitos s manipulaes aritmticas
usuais. Os itens descrio so todos os outros. (E claro que
h muito mais no esquema de classificao do que esse breve
esboo pode sugerir.) O livro trata de cada espcie com
muitos detalhes. As discusses nem sempre so
relacionalmente puras por exemplo, o uso que Tasker faz
do termo domnio no coincide completamente com o uso
relaciona! desse termo mas o livro contm bons conselhos
prticos.
13.40 Toby J. Teorey e James P. Fry: Design of Database
Structures. Englewood Cliffs, N.J.: Prentice-HaIl (1982).
Um texto sobre todos os aspectos de projeto de bancos de
dados. O livro se divide em cinco partes: Introduo, Projeto
Conceitua!, Projeto de Implementao (isto , o mapeamento do
projeto conceitual para construes que um SGBD especfico
pode entender), Projeto Fsico e Questes Especiais de
Projeto.
13.4 1 Toby J. Teorey, Dongqing Yang e James P. Fry: A
Logica! Design Methodology for Relational Databases Using the
Extended Entity-Re!ationship Mode!, ACM Comp. Surv. 18,
Nmero 2 (junho de 1986).
O modelo E/R estendido do ttulo desse artigo acrescenta
suporte para hierarquias de tipos de entidades, nulos
(consulte o Captulo 18) e relacionamento envolvendo mais de
dois participantes.
13.42 Toby J. Teorey: Database Modeling and Design: The
Entity-Relationship Approach (3 edio). San Mateo, Calif.:
Morgan Kaufmann (1990).
Um texto mais recente sobre a aplicao de conceitos de E/R e
E/R estendido [13.41] para projeto de bancos de dados.
392