Você está na página 1de 35

CAPITULO 25

Bancos de dados relacional/objeto


25.1 INTRODUO
Nos ltimos cinco anos, desde que a edio anterior deste
livro foi publicada, vrios fornecedores lanaram produtos de
SGBDs relacional/objeto (tambm conhecidos, pelo menos no
mundo do marketing, como servidores universais). Os exemplos
incluem a verso Universal Database do DB2, o Universal Data
Option para lnformix Dynamic Server e o Oracle 8i Universal
Server, Database Server ou Enterprise Ser- ver (todos os trs
nomes parecem ser usados na prtica). A idia geral em cada
caso que o produto deve admitir recursos tantos de objetos
quanto relacionais; em outras palavras, os produtos em
questo so tentativas de uma aproximao entre as duas
tecnologias.
E opinio enftica deste autor que qualquer aproximao deve
estar firmemente baseada no modelo relacional (que afinal a
base da moderna tecnologia de bancos de dados em geral, como
explicamos na Parte II deste livro). Desse modo, o que
queremos que os sistemas relacionais evoluam* para
incorporar os recursos ou, pelo menos, os bons recursos
de objetos (no queremos descartar os sistemas relacionais
completamente, nem ter de lidar com dois sistemas separados,
o relacional e o de objetos, existindo lado a lado). E essa
opinio compartilhada por muitos outros autores, incluindo
em particular os autores do Third-Generation Database System
Manifesto [25.34], que estabelece categoricamente que os
SGBDs de terceira gerao devem incluir os SGBDs de segunda
gerao onde SGBDs de primeira gerao so os SGBDs pr-
relacionais, SGBDs de segunda gerao so os sistemas de
SQL, e SGBDs de terceira gerao so o que vier em seguida.
Porm, a opinio aparentemente no compartilhada por alguns
dos produtos de objetos, nem por certos escritores sobre
objetos. Aqui est uma citao tpica:
A cincia da computao viu muitas geraes de produtos de
gerenciamento de dados, comeando com arquivos indexados e,
mais tarde, SGBDs de rede e hierrquicos ... [e] mais
recentemente os SGBDs relacionais ... Agora, estamos prestes
a ver outra gerao de sistemas de bancos de dados ... [que]
oferece o gerenciamento de objetos, [que admite] tipos de
dados muito mais complexos [25.4].
Aqui o autor est sugerindo claramente que, da mesma forma
que os sistemas relacionais substituram os antigos sistemas
hierrquicos e de rede, os sistemas de objetos iro
substituir por sua vez os siste ma relacionais. -
A razo para discordarmos dessa posio que relacional
realmente diferente [25.13]. E diferente porque no ad
hoc. Os sistemas pr-relacionais mais antigos eram ad hoc;
eles podem ter oferecido solues para certos problemas
importantes de sua poca, mas no repousam sobre qualquer
base terica slida. Infelizmente, os defensores dos sistemas
relacionais inclusive este autor prestaram um grande
* Observe que estamos definitivamente interessados em
evoluo, no em revoluo. Por contraste, considere esta
citao do livro sobre SGBDOs [24.13]: os [SGBDs de objetos]
so um desenvolvimento revolucionrio, mais que
evolucionrio (itlico acrescentado). No acreditamos que o
mercado em geral esteja preparado para uma revoluo, nem
achamos que ele precisa ou deveria estar essa uma razo
pela qual The Third Manifesto [3.3] muito especificamente
evolucionrio, e no revolucion rio por natureza. 741
desservio no incio, quando discutiram os mritos relativos
dos sistemas relacionais e pr-relacionais;
claro que tais argumentos eram necessrios na poca, mas eles
tiveram o efeito imprevisto de reforar a
idia de que os SGBDs relacionais e pr-relacionais eram
essencialmente o mesmo tipo de coisa. E essa 1 O
idia equivocada, por sua vez, sustentava a posio citada
anteriormente ou seja, que objetos esto para
relaes assim como as relaes estavam para hierarquias e
redes.
Ento, o que dizer dos objetos? Eles so ad hoc? A citao a
seguir, retirada do Object-Oriented Database System Manifesto
[24. 11 revelador a esse respeito: considerando-se a
especificao do sistema, estamos usando uma abordagem
darwiniana: esperamos que, do conjunto de prottipos
experimentais que esto sendo construdos, venha a emergir um
modelo [de objetos] conveniente. Em outras palavras,
aparentemente a sugesto a de que devemos escrever cdigo e
construir sistemas sem qualquer modelo predefinido e ver o
que acontece!
Assim, no que se segue, tomamos como um axioma e faremos o
mesmo no caso dos principais fornecedores de SGBDs que
desejamos na realidade ampliar os sistemas relacionais para
incorporar as bons recursos da tecnologia de objetos.
Repetindo, no queremos descartar a tecnologia relacional;
seria uma pena jogar fora mais de trinta anos de pesquisa e
desenvolvimento slido no campo relacional.
Agora, afirmamos no Captulo 24 veja tambm a anotao
referncia [25.23] que a orientao a objetos envolve
apenas uma boa idia, isto , o suporte apropriado para tipos
de dados (ou duas boas idias, se voc quiser contar
separadamente a herana de tipos). Ento, a questo com que
nos defrontamos vem a ser: como podemos incorporar o suporte
apropriado de tipos de dados ao modelo relacional? E claro
que a resposta, como voc provavelmente j percebeu, que o
suporte j existe, sob a forma de domnios (que, de qualquer
modo, preferimos chamar tipos). Em outras palavras, no
precisamos fazer nada no modelo relacional a fim de alcanar
a funcionalidade de objetos em sistemas relacionais ou
seja, nada alm de implement-lo completa e corretamente, o
que a maioria dos sistemas de hoje tem deixado de fazer.*
Desse modo, acreditamos que um sistema relacional que
admitisse domnios de modo apropriado seria capaz de lidar
com todos aqueles tipos de dados problemticos que (com
frequncia se afirma que) sistemas de objetos podem tratar e
sistemas relacionais no podem: dados de sries temporais,
dados biolgicos, dados financeiros, dados de projetos de
engenharia, dados de automao de escritrios, e assim por
diante. Consequentemente, acreditamos tambm que um
verdadeiro sistema telacional/objeto no seria nada mais
nem menos que um sistema relacional verdadeiro o que
significa dizer, um sistema que admite o modelo relacional,
com todos os vnculos de tal suporte. Ento, os fornecedores
de SGBDs devem ser encorajados a fazer o que de fato esto
tentando fazer: isto , estender seus sistemas para incluir
suporte apropriado a tipos ou domnios. Na realidade, pode-se
usar o argumento de que o motivo principal pelo qual os
sistemas de objetos parecem to atraentes exatamente pelo
fato de os fornecedores de SQL no terem admitido de modo
adequado o modelo relaciona!. Porm, esse fato no deve ser
visto como argumento para se abandonar inteiramente os
sistemas relacionais.
A ttulo de exemplo, vamos agora cuidar de algumas questes
no concludas do Captulo 24 (Seo 24.1) e mostrar uma boa
soluo relacional para o problema dos retngulos. Essa
soluo envolve primeiro a definio de um tipo retngulo
(digamos, RECT):
TYPE RECT POSSREP ( Xi RACIONAL, Vi RATIONAL,
X2 RATIONAL. Y2 RATIONAL )
Supomos que retngulos so representados fisicamente por meio
de uma das estruturas de armazenamento que foram criadas
especificamente para admitir de modo eficiente dados de
espao espaciais rvores qudruplas, rvores R etc.
[25.27].
* Em particular, esses sistemas deram origem a toda essa
concepo errada e multo comum de que os sistemas relacionais
s podem admitir um nmero limitado de tipos muito simples.
As citaes a seguir so bastante tpicas: os sistemas de
bancos de dados relacionais admitem uma coleo pequena e
fixa de tipos de dados [25.25]: um SGBD relaciona! pode
admitir somente
seus tipos embutidos [basicamente apenas nmeros, strings,
datas e horas] [24.381: os modelos de dados
relacional/objeto es- 742 tendem o modelo de dados
relacional, fornecendo um sistema de tipos mais rico [1761];
e assim por diante.
Tambm definimos um operador para testar se dois retngulos
dados se superpem:
OPERATOR OVERLAP ( RI RECT, R2 RECT )
RETLJRNS ( BOOLEAN )
RETURN ( THEX1(R1) _ THEX2(R2) AND
THEY1(R1) _ THEY2(R2) AND
THEX2(R1) _ THEX1(R2) AND
THEY2(R1) _ THEY1(R2) )
END OPERATOR
Esse operador implementa a forma curta eficiente do teste
das sobreposies (reveja o Captulo 24, se precisar
refrescar sua memria a respeito dessa forma curta) sobre a
estrutura de armazdnamento eficiente (rvore R ou qualquer
outra).
Agora o usurio pode criar uma varivel de relao bsica com
um atributo do tipo RECT:
VAR RECTANGLE RELATION { R RECT, ... } KEY { R }
E a consulta Obter todos os retngulos que se superpem ao
quadrado unitrio agora se torna simplesmente:
RECTANGLE WHERE OVERLAP ( R, RECT ( 0,0, 0,0, 1,0, 1,0
Essa soluo supera todas as desvantagens discutidas em
conexo com essa consulta no Captulo 24.
O plano do restante do captulo apresentado a seguir. As
Sees 25.2 e 25.3 discutem Os Dois Grandes Erros (dos quais,
pelo menos um est sendo aparentemente cometido por quase
todos os produtos relacional/objeto do mercado). A Seo 25.4
considera ento certos aspectos da implementao de
um sistema telacional/objeto. A Seo 25.5 descreve os
benefcios de um sistema telacional/objetogenu(no (isto , um
sistema que no comete nenhum dos dois erros). A Seo 25.6
apresenta um resumo.
25.2 O PRIMEIRO GRANDE ERRO
Comeamos com uma citao da referncia [3.3j:
[Antes] de podermos considerar a questo de integrar objetos
e relaes com qualquer nvel de detalhe, existe uma questo
preliminar crucial que precisamos examinar, e essa questo :
A razo para essa pergunta ser to importante o fato de que
a classe de objetos na realidade o conceito mais
fundamental de todos no mundo de objetos todos os outros
conceitos de objetos dependem dele em maior ou menor grau.
Alm disso, existem duas equaes que podem ser, e foram,
propostas como respostas a essa pergunta:
- Domnio = classe de objetos.
- Varivel de relao = classe de objetos.
Agora, continuamos a afirmar com vigor que a primeira dessas
equaes est correta e a segunda est errada.
E claro que, na verdade, a primeira equao obviamente
correta, pois as classes de objetos e os domnios so ambos
apenas tipos. De fato, considerando-se que as variveis de
relaes so variveis e as classes so tipos, deve ser bvio
de imediato que a segunda equao est errada (variveis e
tipos no so a mesma coisa); por essa simples razo, The
Third Manifesto [3.31 afirma categoricamente que variveis
743
Que conceito no mundo relaciona! o
equivalente ao conceito de
classe de objetos no mundo dos objetos?
de relaes no so domnios. No obstante, muitas pessoas e
alguns produtos tm de fato abraado a segunda equao um
equvoco ao qual nos referimos como O Grande Erro (ou, mais
exatamente, O Primeiro Grande Erro, pois veremos outro mais
tarde). Desse modo, instrutivo dar uma olhada muito
cuidadosa na segunda equao, e vamos faz-lo. Nota: a maior
parte do restante desta seo foi tirada de forma mais ou
menos literal da referncia [3.3].
Por que algum poderia cometer tal erro? Bem, considere a
seguintes definio de classe simples, expressa em uma
linguagem de objetos hipottico que semelhante, mas
deliberadamente no idntica da Seo 24.3:
CREATE OBJECT CLASS EMP ( EMP#
ENOME
SAL
PASSATEMPO
TRABALHA_PARA
CHAR(5),
CHAR(2O),
NUMERIC,
CHAR(2O),
CHAR(20) )
(EMP#, ENOME, etc., aqui so variveis de instncias
pblicas.) E agora considere a seguinte definio de
varivel de relao bsica dc SQL:
CREATE TABLE EMP
( EMP#
ENOME
SAL
PASSATEMPO
TRABALHA_PARA
CHAR(5),
CHAR(20),
NUMERIC,
CHAR(20),
CHAR(2O) ) )
Essas duas definies certamente so bem parecidas, e a idia
de compar-las desse modo parece muito tentadora. Alm disso
(como j indicamos), certos sistemas, inclusive alguns
produtos comerciais, tm de fato feito exatamente isso.
Assim, vamos observar mais de perto. Mais precisamente, vamos
usar a instruo CREATE TABLE que acabamos de mostrar e
considerar uma srie de extenses possveis para ela que
(algumas pessoas afirmariam) servem para torn-la mais
semelhantes a objetos. Nota: a discusso a seguir se baseia
em um produto comercial especfico; de fato, ela baseado em
um exemplo contido na prpria documentao desse produto.
Porm, no identificamos esse produto aqui, pois no nosso
intento neste livro criticar ou louvar produtos especficos.
Em vez disso, as crticas que faremos mais adiante nesta
seo se aplicam, mutatis mutandis, a qualquer sistema que
adote a equao varivel de relao = classe.
A primeira extenso para permitir isto atributos
compostos (isto , com valor de tupla); ou seja, permitimos
que valores de atributos sejam tuplas de alguma outra
varivel de relao (ou possivelmente da mesma varivel de
relao). No exemplo, podemos substituir a instruo original
CREATE TABLE pela seguinte coleo de instrues (consulte a
Figura 25.1):
CREATE TABLE ATIVIDADE
NOME CHAR(20),
EQUIPE INTEGER
CREATE TABLE EMP ( EMP#
ENOME
SAL
PASSATEMPO
TRABALHA_PARA
CHAR(5),
CHAR(20),
NUMERIC,
ATIVIDADE,
EMPRESA )
744
CREATE TABLE EMPRESA
NOME CHAR(20),
LOCAL CIDADE_ESTADO
CREATE TABLE CIDADE_ESTADO
CIDADE CHAR(20),
ESTADO CHAR(2)
Explicao: o atributo PASSATEMPO na varivel de relao EMP
declarado como sendo do tipo ATIVIDADE. Por sua vez,
ATIVIDADE uma varivel de relao com dois atributos, NOME
e EQUIPE, onde EQUIPE fornece o nmero de jogadores em uma
equipe correspondente a NOME. Por exemplo, uma possvel
atividade poderia ser (Futebol, 11). Portanto, cada valor
de PASSATEMPO na realidade um par de valores, um valor NOME
e um valor EQUIPE (mais precisamente, um par de valores que
aparecem atualmente como uma tupla na varivel de relao
ATIVIDADE). Nota: observe que j violamos a afirmao do The
Third Manifesto de que as variveis de relaes no so
domnios o domnio para o atributo PASSATEMPO definido
como a varivel de relao ATIVIDADE. Veja mais adiante nesta
seo uma discusso adicional desse ponto.
FIGURA 25. 1 Atributos contendo (ponteiros para) tuplas
desaconselhado
De modo semelhante, o atributo TRABALHA PARA na varivel de
relao EMP declarado como sendo do tipo EMPRESA de tipo, e
EMPRESA tambm uma varivel de relao de dois atributos,
um dos quais definido como do tipo CIDADE_ESTADO, que
outra varivel de relao de dois atributos, e assim por
diante. Em outras palavras, as variveis de relaes
ATIVIDADE, EMPRESA e CIDADE_ESTADO so todas consideradas
tipos (ou domnios) bem como variveis de relaes. E claro
que o mesmo verdade para a prpria varivel de relao EMP.
Desse modo, essa primeira extenso aproximadamente anloga
ao de permitir que objetos contenham outros objetos,
admitindo-se assim o conceito de hierarquia de conteno
(consulte o Captulo 24).
Como um aparte, observamos que caracterizamos essa primeira
extenso como atributos contendo tuplas porque esse o
modo como os prprios defensores da equao varivel de
relao = classe a caracterizam (por exemplo, veja a
referncia [24.33]). Porm, seria mais preciso caracteriz-la
como atributos contendo ponteiros para tuplas uma questo
que examinaremos daqui a pouco. (Portanto, na Figura 25.1,
devemos na realidade substituir cada uma das trs ocorrncias
do termo tupla pela expresso ponteiro para tu pia.)
Observaes anlogas s do pargrafo anterior tambm se
aplicam segunda extenso, qual seja a de permitir atributos
com valor de relao; isto , valores de atributos podem ser
conjuntos de tuplas de alguma outra varivel de relao (ou
possivelmente da mesma varivel de relao). Por exemplo,
suponha que empregados possam ter um nmero arbitrrio de
passatempos, em vez de apenas um (consulte a Figura 25.2):
745
EMP
EMP
#
ENOM
E
SA
L
rela
o
PASSATEM
POS
tupla
TRABALHA
PARA
NOM
E
EQUI
PE
j
tupl LOC
a AL
CIDA
DE
EST
A
CREATE TABLE EMP
( EMP# CHAR(5)
ENOME CHAR(20),
SAL NUMERIC,
PASSATEMPOS SET OF ( ATIVIDADE
TRABALHA_PARA EMPRESA
FIGURA 25.2 Atributos contendo conjuntos de (ponteiros para)
tu pias desaconselhado
Explicao: o valor PASSATEMPOS dentro de qualquer tupla
especfica da varivel de relao EMP agora
(conceitualmente) um conjunto de zero ou mais pares
(NOME,EQUIPE) isto , tuplas da varivel de relao
ATIVIDADE. Essa segunda extenso ento aproximadamente
anloga a permitir que objetos contenham objetos coleo:
uma verso mais complexa da hierarquia de conteno. Nota:
observamos de passagem que, no produto particular em que
nosso exemplo se baseia, esses objetos coleo podem ser
sequncias ou bags, bem como conjuntos propriamente ditos.
A terceira extenso tem a finalidade de permitir que
variveis de relaes tenham mtodos associados a elas. Por
exemplo:
CREATE TABLE EMP
( EMP# CHAR(5),
ENOME CHAR(20),
SAL NUMERIC,
PASSATEMPOS SET OF ( ATIVIDADE ),
TRABALHA_PARA EMPRESA
METHOD BENEFICIOS_APOSENTADORIA ( ) : NUMERIC
Explicao: BENEFICIOS_APOSENTADORIA um mtodo que toma uma
determinada tupla de EMP como parmetro e produz um resultado
do tipo NUMERIC.
A ltima extenso de definio tem o objetivo de permitir
subclasses. Por exemplo (consulte a Figura 25.3):
CREATE TABLE PESSOA
( FF# CHAR(9),
NASCIMENTO DATE,
ENDEREO CHAR(50)
CREATE TABLE EMP
AS SUBCLASS OF PESSOA
( EMP# CHAR(5)
ENOME CHAR(2 O)
SAL NUMERIC,
PASSATEMPOS SET OF ( ATIVIDADE ),
TRABALHA PARA EMPRESA
746 METHOD BENEFICIOS_APOSENTADORIA ( ) : NUMERIC
EMP
EMP#
ENO
ME
SAL
rela
o
PASSATEM
POS
tup
la
TRABALHA_
PARA
j
NOM
E
EQUI
PE
NOM
E
tu
pl
a
LOCAL
CIDA
DE
ESTADO
PESSOA
[FF# 1 NASCIMENTO ENDEREO
EMP
FIGURA 25 .3 Variveis de relaes como superclasses e
subclasses desaconselhado
Explicao: EMP tem agora, trs atributos adicionais (FF#,
NASCIMENTO e ENDEREO) herdados de PESSOA (porque cada
instncia de EMP tambm uma instncia de PESSOA, em termos
informais). Se PESSOA tivesse quaisquer mtodos, ela tambm
os herdaria. Nota: aqui, PESSOA e EMP so exemplos daquilo
que s vezes chamamos supertabelas e subta belas,
respectivamente. Consulte a referncia [13.12] e tambm o
Apndice B, a fim de ver uma discusso adicional e uma
crtica desses conceitos.
Alm das extenses de definio esboadas anteriormente,
claro que tambm so necessrias certas extenses de
manipulao por exemplo:
Expresses de caminhos tais como,
EMP.TRABALHA_PARA.LOCAL.ESTADO. Observe que, em geral, essas
expresses podem retornar escalares, tuplas ou relaes. Alm
disso note que, nos dois ltimos casos, os componentes dessas
tuplas ou relaes podem eles prprios ser tuplas ou relaes
(e assim por diante); por exemplo, a expresso
EMP.PASSATEMPOS.NOME retorna uma relao. A propsito,
observe que essas expresses de caminhos descem pela
hierarquia de conteno, enquanto as expresses de caminhos
discutidas no Captulo 24 sobem por essa hierarquia.
- Literais de tuplas e relaes (possivelmente aninhados)
por exemplo:
`EOOl', `Smith', $50000,
Futebol , 11 ), ( `Beisebol , 9
`18W, ( `San Jose', CA' )
(sem pretender que seja essa uma sintaxe real).
- Operadores de comparao relaciona! por exemplo, SUBSET,
SUBSE1'EQ e assim por diante. (Os operadores especficos
mencionados foram tirados do produto comercia! particular em
discusso. Nesse produto, SUBSET significa realmente
subconjunto prprio e SUBSETEQ quer dizer subconjunto
(!).)
- Operadores para percorrer a hierarquia de classes. Nota:
tambm necessrio cuidado nesse caso. Pode muito bem
ocorrer a situao em que um pedido para recuperar
informaes de PESSOA junto com informaes de EMP associadas
produza um resultado que no seja uma relao significando
que a propriedade relacional vital de fechamento foi violada,
com implicaes potencialmente desastrosas. (Nessa conexo, a
referncia [25.3 1] que se refere a tal resultado como um
retorno irregular apenas observa alegremente que o
programa do cliente tem de estar preparado para lidar com a
complexidade de um retorno irregular!)
- A capacidade de invocar mtodos, por exemplo, dentro de
clusulas SELECT e WHERE (em
termos de SQL). 747
EM
P#
ENOM
E
SAL
relao
PASSATEMPOS
tup
la
TRABALHA
_PARA
[ NOME
EQUI
PE
NOME
tupl
a
LOCAL
CIDA
DE
ESTADO
- A capacidade de obter acesso a componentes individuais
dentro de valores de atributos que sejam tuplas ou relaes.
Assim tivemos uma rpida viso geral de como a equao
varivel de relao = classe percebida na prtica. Ento,
o que h de errado com ela?
Bem, observe em primeiro lugar que (conforme afirmamos antes)
uma varivel de relao uma varivel e uma classe um
tipo. Ento, de que maneira elas poderiam ser iguais? Essa
primeira observao deve ser logicamente suficiente para
desfazer a idia de varivel de relao = classe. Porm, h
outros pontos teis que podemos mencionar; vamos concordar
ento em suspender a descrena por um tempo um pouco mais
longo... Aqui esto alguns pontos adicionais a considerar:
- A equao varivel dc relao = classe implica as
equaes adicionais tupla = objeto e atributo = varivel
de instncia (pblica). Desse modo, enquanto (como vimos no
Captulo 24) uma classe dc objetos verdadeira pelo menos,
uma classe de objetos escalares ou encapsulados tem
mtodos e nenhuma varivel de instncia pblica, uma varivel
de relao classe de objetos tem variveis de instncias
pblicas e s opcionalmente tem mtodos (ela definitivamente
no encapsulada). Ento, novamente, de que maneira as
duas noes teriam a possibilidade de serem iguais?
- Existe uma diferena importante entre as definies de
atributos (por exemplo) SAL NUMERIC e TRABALHA PARA
EMPRESA. NUMERIC um tipo de dados verdadeiro (de forma
equivalente, um domnio verdadeiro, embora primitivo); ele
impe uma restrio independente do tempo sobre os valores
que podem ser vlidos no atributo SAL. Ao contrrio, EMPRESA
no um tipo de dados verdadeiro; a restrio que ele impe
sobre os valores que podem aparecer no atributo TRABALHA_PARA
dependente do tempo (ela depende, obviamente, do valor
atual da varivel de relao EMPRESA). De fato, como
assinalamos antes, a distino entre varivel de relao e
domnio ou, se voc preferir a terminologia de objetos, a
distino entre coleo e classe tornou-se confusa nesse
caso.
- Vimos que objetos tuplas aparentemente podem conter
outros objetos desse tipo: por exemplo, objetos EMP
aparentam conter objetos EMPRESA. Contudo, eles no os
contm na realidade; em vez disso, contm ponteiros para
esses objetos contidos, e os usurios devem ter esse ponto
absolutamente claro. Por exemplo, vamos supor que o usurio
atualize alguma tupla EMPRESA particular de algum modo
(reveja a Figura 25.1). Ento, essa atualizao estar
imediatamente visvel em todas as tuplas EMP que contm
essa tupla EMPRESA. Nota: no estamos dizendo que esse efeito
indesejvel, apenas dizendo que ele tem de ser explicado ao
usurio. Porm, explic-lo ao usurio significa dizer ao
usurio que o modelo mostrado na Figura 25. 1 incorreto
tuplas EMP no contm tuplas EMPRESA; elas contm ponteiros
para tuplas EMPRESA (como j afirmamos).
Aqui esto mais algumas implicaes e perguntas adicionais
que surgem a partir desse mesmo ponto:
a. Podemos inserir uma tupla EMP e especificar um valor para
a tupla EMPRESA contida que no existe no momento na
varivel de relao EMPRESA? Se a resposta sim, o fato de
ser o atributo TRABALHA_PARA definido como do tipo EMPRESA
no quer dizer muito, pois ele no restringe de modo
significativo a operao INSERT de qualquer modo. Se a
resposta no, a operao INSERT se torna desnecessariamente
complexa o usurio tem de especificar, no apenas o nome de
uma empresa existente (isto , o valor de uma chave
estrangeira) como seria necessrio na situao relacional
anloga, mas uma tupla EMPRESA existente inteira. Alm disso,
especificar uma tupla EMPRESA inteira significa, na melhor
das hipteses, informar ao sistema algo que ele j sabe; na
pior das hipteses, quer dizer que, se o usurio cometer um
erro, a operao INSERT falhar quando poderia perfeitamente
ser bem-sucedida.
748
b. Vamos supor que desejamos a regra ON DELETE RESTRICT para
empresas (ou seja, uma tentativa de eliminar uma empresa deve
falhar se a empresa tiver algum empregado). Podemos presumir
que essa regra tem de ser importa por cdigo procedural,
digamos por algum mtodo M (observe que a varivel de relao
EMP no tem nenhuma chave estrangeira qual uma verso
declarativa da regra possa ser associada). Alm disso,
operaes DELETE comuns de SQL no devem agora ser executadas
sobre a varivel de relao EMPRESA, exceto aquelas contidas
dentro do cdigo que implementa esse mtodo M. Como esse
requisito imposto? Observaes e perguntas anlogas se
aplicam, claro, a outras regras de chaves estrangeiras,
como ON
DELETE CASCADE.
c. Observe tambm que a eliminao de uma tupla EMP
presumivelmente no se propagar em cascata at eliminar a
tupla EMPRESA correspondente, apesar da pretenso de que a
tupla EMP contm essa tupla EMPRESA.
De todos os itens anteriores, decorre que no estamos mais
falando exatamente sobre o modelo relaciona!. O objeto de
dados fundamental no mais uma relao contendo valores,
uma relao
na realidade, no propriamente uma relao, ao menos no
que se refere ao modelo relacional contendo valores e
ponteiros. Em outras palavras, minamos a integridade
conceitual do modelo relaciona!. *
- Vamos supor que definamos a viso V como a projeo de EMP
sobre (digamos) apenas o atributo PASSATEMPOS. E claro que V
tambm uma varivel de relao, mas uma varivel de relao
derivada, e no bsica. Ento, se varivel de relao =
classe uma equao correta, V tambm uma classe. Que
classe ela? Alm disso, classes tm mtodos; que mtodos se
aplicam a V?
Bem, a classe EMP tem apenas um mtodo,
BENEFICIOS_APOSENTADORIA, e esse mtodo sem dvida no se
aplica classe V. De fato, no parece razovel que
quaisquer mtodos que se aplicassem classe EMP se
aplicariam classe V e certamente no h outros. Ento,
parece que (em geral) absolutamente nenhum mtodo se aplica
ao resultado de uma projeo; isto , o resultado, seja qual
for, no realmente uma classe. (Poderamos dizer que ele
uma classe, mas isso no cria uma classe! ele ter
variveis de instncias pblicas e nenhum mtodo, enquanto j
observamos que uma classe encapsulada verdadeira tem
mtodos e nenhuma varivel de instncia pblica.)
De fato, deve ficar bastante claro que, quando as pessoas
igualam variveis de relaes e classes, o que elas tm em
mente so as variveis de relaes bsicas em particular
essas pessoas esto se esquecendo das variveis de relaes
derivadas. (Certamente, os ponteiros discutidos antes so
ponteiros para tuplas em variveis de relaes bsicas, e no
derivadas.) Porm, a distino feita dessa maneira entre
variveis de relaes bsicas e derivadas um equvoco da
mais alta ordem, porque a questo de saber quais variveis de
relaes so bsicas e quais so derivadas , em um sentido
muito importante, arbitrria (reveja a discusso de O
Princpio da Permutabilidade no Captulo 9).
- Finalmente, que domnios so admitidos? Aqueles que
defendem a equao varivel de relao = classe nunca
parecem ter muito a dizer sobre domnios, talvez porque no
possam ver como os domnios se encaixam em seu esquema geral.
Alm disso, claro que domnios so essenciais, como sabemos
de muitas de nossas discusses anteriores (por exemplo,
consulte o Captulo 3).
A expresso integridade conceitual se deve a Fred Brooks, que
diz sobre ela [25.1]: A integridade [conceitualj a
considerao mais importante no projeto de sistemas. E melhor
fazer um sistema omitir certas caractersticas anmalas [e]
refletir um conjunto de idias de projeto, que ter um que
contm muitas idias boas, mas independentes e
descoordenadas (itlico no original). Escrevendo vinte anos
depois, ele acrescenta: Um produto de programao limpo e
elegante deve representar ... um modelo mental coerente ... A
integridade [conceitual] ... o fator mais importante na
facilidade de uso ... Hoje estou mais convencido que nunca. A
integridade conceitual central para a qualidade do produto
(negrito e itlico no original). 749
A mensagem geral do que foi mencionado pode ser resumida
desta forma: bvio que podem ser montados sistemas baseados
na equao errada varivel de relao = classe; na verdade,
alguns desses sistemas j existem. Igualmente bvio o fato
de que esses sistemas (como um carro sem leo no motor, ou
uma casa construda sobre a areia) podem at fornecer um
servio til durante algum tempo, mas esto condenados a uma
falha eventual.
De onde surgiu O Primeiro Grande Erro?
interessante especular sobre a origem do Primeiro Grande
Erro. Parece que ele tem suas razes na falta de consenso,
observada no Captulo 24, sobre o significado dos termos no
mundo de objetos. Em particular, o prprio termo objeto no
tem um significado consensual e de aceitao universal esse
precisamente o motivo pelo qual no o utilizamos muito.
Apesar das observaes anteriores, de qualquer modo no
mnimo razoaveirnente claro que, na rea de linguagens de
programao de objetos, o termo objeto se refere ao que se
chamaria de forma mais tradicional um valor ou uma varivel
(ou talvez ambos). Porm, infelizmente, o termo utilizado
tambm em outros reas; em particular, ele empregado em
certas reas de modelagem semntica, como parte de diversas
tcnicas e metodologias de anlise e projeto de objetos ou
modelagem de objetos (por exemplo, consulte a referncia
[13.3j). Alm disso, parece claro nessas reas que o termo
no significa um valor ou uma varivel, mas sim aquilo que em
geral se chamaria na comunidade de bancos de dados de uma
entidade (implicando entre outras coisas, incidentalmente,
que diferente dos objetos de linguagens de programao
esses objetos sem dvida no so encapsulados). Em outras
palavras, a modelagem de objetos na realidade apenas a
modelagem de entidades/relacionamentos com outro nome; de
fato, a referncia j13.3] admite mais ou menos isso. Em
consequncia, coisas que so identificadas como objetos em
tais metodologias so ento (corretamente) mapeadas para
tuplas em variveis de relaes, em vez de serem mapeadas
para valores em domnios. Pronto!
25.3 O SEGUNDO GRANDE ERRO
Nesta seo, examinamos O Segundo Grande Erro; como veremos,
esse segundo erro parece ser uma consequncia lgica do
primeiro, mas ele tambm tem seu prprio significado (alm
disso, tambm possvel cometer apenas esse erro, mesmo que
O Primeiro Grande Erro seja evitado), O erro consiste em
misturar ponteiros e relaes. Comeamos revendo as
principais caractersticas da abordagem de varivel de
relao = classe, identificadas na seo anterior. Algumas
pessoas podem achar essa seo um pouco confusa pois algumas
dessas caractersticas pareciam estar se contrapondo a
recursos que defendemos em favor de pontos anteriores no
livro (os atributos com valor de tupla e relao constituem
um exemplo). Ento, aqui est:
- Atributos com valores de tu pias e relaes: na verdade,
no fazemos nenhuma objeo a tais atributos (como
poderamos?). Nossa objeo (a) idia de que tais
atributos devem ter, muito especificamente, valores que
pertencem no momento a alguma outra varivel de relao
(bsica), e (b) idia de que tais atributos realmente tm
valores que no so propriamente tuplas ou relaes, mas sim
ponteiros para tuplas ou relaes o que significa, claro,
que no estamos realmente falando sobre atributos com valores
de tuplas ou relaes. Nota: na verdade, a idia de ponteiros
indicando tuplas ou relaes com o significado especfico
de valores de tuplas ou relaes no faz mais nenhum sentido.
Discutiremos esse ponto em detalhes daqui a pouco.
- Associao de operadores (mtodos) com variveis de
relaes: tambm no fazemos nenhuma objeo a essa idia
ela basicamente apenas a noo de procedimentos armazenados
ou ativados sob outro disfarce. Porm, fazemos objeo
idia de que tais operadores devam estar associados com
variveis de relaes (e somente com variveis de relaes) e
no com domnios ou tipos. Tambm fazemos objeo idia de
que eles devam estar associados com uma varivel de
750 relao especfica (a noo de operandos de destino sob
outro disfarce).
- Subclasses e superciasses: nesse caso, fazemos objeo...
Em um sistema que iguala variveis de
relaes e classes, subclasses e superciasses se tornam
subtabelas e supertabelas e essa noo
uma daquelas sobre as quais estamos muito cticos [13.12].
Queremos um suporte apropriado
para a herana conforme descrevemos no Captulo 19.
- Expresses de caminhos: no teramos nenhuma objeo a
expresses de caminhos que fossem meras abreviaes
sintticas para acompanhar certas referncias associativas
por exemplo, de uma chave estrangeira para uma chave
candidata correspondente, como foi proposto na referncia
[25.11]. Contudo, as expresses de caminhos discutidas na
Seo 25.2 so, em vez disso, abreviaes para seguir certas
cadeias de ponteiros, e a essas fazemos objeo (porque
tambm fazemos objeo a ponteiros).
- Literais de tu pias e relaes: esses so essenciais
embora precisem ser generalizados em seletores de tuplas e
relaes [3.3].
- Operadores de comparao relacional: tambm essenciais
(embora tambm devessem ser feitos de forma correta).
- Operadores para percorrer a hierarquia de classes: se
hierarquia de classe significa realmente hierarquia de
variveis de relaes, ento (como observamos na seo
anterior) fazemos objees importantes devido violao
provvel da propriedade de fechamento relacional (por
exemplo, consulte a referncia [25.31]). Se ela significar
hierarquia de tipos no sentido do Captulo 19, ento no
temos nenhuma objeo (mas ela no tem esse ltimo
significado).
- Invocao de mtodos em, por exemplo, clusulas SELECT e
WHERE: claro.
a Acesso a componentes individuais dentro de valores de
atributos que sejam tu pias ou relaes: claro.
Ento, vamos agora focar na questo de misturar ponteiros e
relaes. O ponto crucial do argumento muito simples. Por
definio, ponteiros apontam para variveis, e no para
valores (porque variveis tm endereos e valores no).
Ento, por definio, se a varivel de relao Ri puder ter
um atributo cujos valores sejam ponteiros para a varivel
de relao R2, ento esses ponteiros apontaro para variveis
de tuplas, e no para valores de tuplas. No entanto, no
existe nada como uma varivel de tupla no modelo relacional.
O modelo relacional lida com valores de relaes, que so (em
termos informais) conjuntos de valores de tuplas que, por sua
vez, so (novamente, em termos informais) conjuntos de
valores escalares. Ele tambm lida com variveis de relaes,
que so variveis cujos valores so relaes. Porm, ele no
lida com variveis de tuplas (que so variveis cujos valores
so tuplas) ou variveis escalares (que so variveis cujos
valores so escalares). O nico tipo de varivel includo no
modelo relaciona! (e o nic tipo de varivel permitido em um
banco de dados relaciona!) , de modo muito especfico, a
varivel de relao. Segue-se que a idia de misturar
ponteiros e relaes constitui um afastamento IMPORTANTE do
modelo relaciona!, um tipo inteiramente novo de varivel. De
fato, como observamos na seo anterior, ele prejudica
seriamente a integridade conceitual do modelo relaciona!.
Podemosencontrar argumentos mais detalhados em apoio a essa
posio nas referncias [24.211 e
[25.11]. Consulte tambm as referncias [25.8] a [25.101 e
[25.13]que discutem a noo relacionada e
importante de essencialidade (de construo de dados dentro
de um modelo de dados).
Assim, dado o argumento anterior, triste ver que a maioria
dos (possivelmente todos os) produtos atuais
relacional/objeto mesmo aqueles que evitam O Primeiro
Grande Erro parecem estar misturando ponteiros e relaes,
exatamente da maneira discutida e contestada antes. Quando
definiu pela primeira vez o modelo relaciona!, Codd excluiu
deliberadamente os ponteiros. Para citar a referncia [5.2]:
E seguro supor que todos os tipos de usurios [inclusive
usurios finais em particular] entendam
a ao de comparar valores, mas relativamente poucos entendem
as complexidades de ponteiros. O modelo relaciona! se baseia
nesse princpio fundamental ... [A] manipulao de ponteiros
mais propensa a bugs que a ao de comparar valores, mesmo
que o usurio entenda as complexidades dos
ponteiros. 751
Para sermos especficos, os ponteiros levam a pointer-
chasing, algo que notoriamente propenso a erros. Como
observamos no Captulo 24, exatamente esse aspecto dos
sistemas de objetos que d origem s crticas, algumas vezes
ouvidas, de que tais sistemas parecem CODASYL requentado.
De onde surgiu O Segundo Grande Erro?
difcil encontrar qualquer justificativa real na literatura
para O Segundo Grande Erro (ou melhor, qualquer justificativa
tcnica mas existem evidncias de que a justificativa no
de modo algum tcnica, mas sim poltica). E claro que,
considerando-se o fato de que todos os sistemas e linguagens
de objetos incluem ponteiros (sob a forma de IDs de objetos),
a idia de misturar ponteiros e relaes quase certamente
surge de um desejo de tornar os sistemas relacionais mais
semelhantes a objetos, mas essa justificativa apenas
empurra o problema para outro nvel; j deixamos muito claro
que (em nossa opinio) os sistemas de objetos expem
ponteiros para o usurio, precisamente porque no conseguem
fazer uma distino apropriada entre modelo e implementao.
Desse modo, podemos apenas conjecturar que a razo pela qual
a idia de misturar ponteiros e relaes est sendo to
amplamente promovida porque bem poucas pessoas entendem o
motivo pelo qual os ponteiros foram excludos das relaes.
Citando Santayana: Aqueles que no conseguem se lembrar do
passado esto condenados a repeti-lo (em geral, citado na
forma Aqueles que no sabem histria esto condenados a
repeti-la). Sobre essas questes concordamos enfaticamente
com Maurice Wilkes, quando ele escreve [25.35]:
Gostaria de ver a cincia da computao ensinando a teoria de
conjuntos deliberadamente em um quadro histrico ... Os
alunos precisam entender como se chegou at a situao atual,
o que foi experimentado, o que funcionou e o que no
funcionou, e como as melhorias no hardware tornaram o
progresso possvel. A ausncia desse elemento em seu
treinamento faz com que as pessoas abordem todo problema a
partir de conceitos iniciais. Elas esto aptas a propor
solues que no foram consideradas viveis no passado. Em
vez de se basearem em seus precursores, elas procuram seguir
sozinhas.
25.4 QUESTES DE IMPLEMENTAO
Uma implicao importante do suporte para tipos de dados
prprios que ele permite que fornecedores independentes
(bem como os prprios fornecedores de SGBDs) construam e
vendam pacotes separados de tipos de dados que podem ser
conectados de forma efetiva ao SGBD. Os exemplos incluem
pacotes para suporte a tratamento de texto sofisticado,
processamento de sries financeiras temporais, anlise de
dados geoespaciais (cartogrficos), e assim por diante. Esses
pacotes so referenciados de forma variada como data blades
(lminas de dados) (Informix), cartuchos de dados (data
cartridges) (Oracle), relational extenders (IBM),* e assim
por diante. No texto a seguir, manteremos o termo pacote de
tipos (type packages).
Porm, a incluso de um novo pacote de tipos no sistema no
uma tarefa trivial e a habilidade de faz-lo tem implicaes
significativas para o projeto e a estrutura do prprio SGBD.
Para ver o porqu em ambos os casos, considere o que
acontecer se, por exemplo, alguma consulta incluir
referncias a dados de algum tipo definido pelo usurio ou
invocaes de algum operador definido pelo usurio (ou
ambos):
- Em primeiro lugar, o compilador da linguagem de consulta
tem de ser capaz de analisar e fazer a verificao do tipo
solicitado; assim, ele tem de saber algo sobre esses tipos e
operadores definidos pelo usurio.
- Segundo, o otimizador tem de ser capaz de decidir sobre um
plano de consulta apropriado para essa solicitao; ento,
ele tambm tem de estar ciente de certas propriedades desses
tipos de operadores definidos pelo usurio. Em particular,
precisa saber como os dados esto fisicamente armazenados
(consulte o prximo pargrafo).
752 * Um termo excessivamente inadequado, em nossa opinio.
- Terceiro, o componente que gerencia o armazenamento fsico
tem de admitir as estruturas de armazenamento mais novas
(quadtrees, rvores R etc.) mencionadas em nossa discusso
do problema dos retngulos na Seo 25.1. Pode ser que ele
tenha at mesmo de oferecer suporte para a possibilidade de
usurios com experincia adequada introduzirem novas
estruturas de armazenamento e mtodos de acesso deles
prprios [25.21, 25.33].
O resultado final de tudo isso que o sistema precisa ser
extensvel de fato, extensvel em vrios nveis.
Discutiremos cada nvel rapidamente.
Anlise e verificao de tipos
Em um sistema convencional, como os nicos tipos e operadores
disponveis esto todos embutidos, as informaes a respeito
deles podem estar (e em geral estaro) embutidas no cdigo
hadwired no compilador da linguagem de consulta. Ao
contrrio, em um sistema no qual os usurios possam definir
seus prprios tipos e operadores, essa abordagem embutida no
cdigo claramente no funcionar. Portanto, em vez disso, o
que acontece :
1. As informaes relativas a tipos e operadores definidos
pelo usurio e possivelmente tambm as informaes
relativas a tipos e operadores embutidos so mantidas no
catlogo do sistema. Esse fato implica que o prprio catlogo
precisa ser reprojetado (ou pelo menos estendido); ele tambm
implica que a introduo de um novo pacote de tipos envolve
um grande trabalho de atualizao do catlogo. (E claro que,
em termos de Tutorial D, essa atualizao realizada IIOS
bastidores, como parte do processo de execuo das instrues
de definio TYPE e OPERATOR aplicveis.)
2. O prprio compilador precisa ser reescrito para obter
acesso ao catlogo, a fim de conseguir as informaes
necessrias sobre tipos e operadores. Em seguida, ele pode
usar essas informaes para conduzir toda a verificao de
tipo em tempo de compilao descrita nos Captulos 5, 8 e 19.
Otimizao
Existem muitos assuntos envoltos aqui, e s podemos arranhar
a superfcie do problema neste livro. Porm, pelo menos
podemos assinalar que algumas dessas questes so:
- Transformao de expresses (reescrita de consultas): um
otimizador convencional aplica certas leis de transformao
para reescrever consultas, como vimos no Captulo 17.
Contudo, historicamente, essas leis de transformao foram
todas embutidas no cdigo no otimizador (porque, novamente,
os tipos de dados e operadores disponveis foram todos
embutidos). Por contraste, em um sistema telacional/objeto, o
conhecimento relevante (pelo menos medida que ele se aplica
especificamente a tipos e operadores definidos pelo usurio)
precisa ser mantido no catlogo implicando mais extenses
ao catlogo e tambm que o prprio otimizador precisa ser
reescrito. Aqui esto algumas ilustraes:
a. Dada uma expresso como NOT (QDE> 500), um bom otimizador
convencional a transformar em QDE _ 500 (porque a segunda
verso pode fazer uso de um ndice sobre QDE, enquanto a
primeira no pode). Por razes anlogas, necessrio haver
um caminho para informar ao otimizador quando um operador
definido pelo usurio a negao de outro.
b. Um bom otimizador convencional tambm saber que, por
exemplo, as expresses QDE > 500 e 500 <QDE so logicamente
equivalentes. E preciso haver um meio para informar ao
otimizador quando dois operadores definidos pelo usurio so
opostos nesse sentido.
c. Um bom otimizador convencional tambm saber que, por
exemplo, os operadores + e - se cancelam (isto , so
inversos); por exemplo, a expresso QDE + 500 500 se reduz
apenas a Q DE. E necessrio haver um meio para informar ao
otimizador quando dois operadores definidos pelo usurio so
inversos nesse sentido.
753
- Seletividade: dada uma expresso booleana como QDE > 500,
em geral os otimizadores faro uma suposio sobre a
seletividade dessa expresso (isto , a porcentagem de tuplas
que a torna verdadeira). No caso de tipos de dados e
operadores embutidos, mais uma vez essas informaes sobre a
seletividade podem ser embutidas no cdigo do otimizador;
em contraste, no caso de tipos e operadores definidos pelo
usurio, necessrio haver um meio para fornecer ao
otimizador algum cdigo definido peio usurio a ser invocado
com o objetivo de fazer suposies sobre as seletividades.
- Frmulas de custo: o otimizador precisa saber quanto custa
executar um determinado operador definido pelo usurio. Por
exemplo, dada uma expresso como p AND q, onde p (digamos)
uma invocao do operador AREA em algum polgono complicado e
q uma comparao simples como QDE > 500, provavelmente
seria prefervel que o sistema executasse q primeiro, de
forma que p somente fosse executada sobre tuplas para as
quais q tivesse valor verdadeiro. De fato, uma parte da
heurstica clssica de transformao de expresses, como a de
sempre executar restries antes de junes, no
necessariamente vlida para tipos e operadores definidos pelo
usurio [25.7, 25.18].
- Estruturas de armazenamento e mtodos de acesso: o
otimizador precisa estar claramente ciente das estruturas de
armazenamento e dos mtodos de acesso em efeito (consulte a
prxima subseo).
Estruturas de armazenamento
Deve ser bvio que sistemas relacional/objeto vo precisar de
outros meios possivelmente muitos outros meios para
armazenar e obter acesso a dados no nvel fsico que (por
exemplo) os sistemas de SQL tm oferecido tradicionalmente.
Aqui esto algumas consideraes relevantes:
- Novas estruturas de armazenamento: como j observamos,
bem provvel que o sistema precise dar suporte a novas
estruturas de armazenamento embutidas no cdigo (rvores R,
etc.), e pode ser at mesmo necessrio haver um modo para que
usurios qualificados introduzam estruturas de armazenamento
e mtodos de acesso adicionais deles prprios.
- Indices sobre dados de um tipo definido pelo usurio: os
ndices tradicionais se baseiam em dados de algum tipo
embutido e em uma compreenso interna do que significa o
operador<. Em um sistema telacional/objeto, tem de ser
possvel montar ndices sobre dados de um tipo definido pelo
usurio, com base na semntica do operador < definido pelo
usurio aplicvel (supondo-se que tal operador tenha sido
definido inicialmcnte, claro).
- Indices sobre resultados de operadores: provavelmente
existiria pouco interesse em montar um ndice diretamente
sobre um conjunto de valores de dados do tipo POLIGONO;
mais provvel que esse ndice ordenasse os polgonos de
acordo com suas codificaes internas de strings de bytes.*
No entanto, um ndice baseado nas reas desses polgonos
poderia ser muito til. Nota:
fazemos referncia a tais ndices sob o nome de ndices
funcionais no Captulo 21.
25.5 BENEFICIOS DA VERDADEIRA APROXIMAO
Na referncia [25.31], Stonebraker apresenta uma matriz de
classificao para SGBDs (ver Figura
25.4). O Quadrante 1 dessa matriz representa aplicaes que
lidam apenas com dados bastante simples e no tm nenhuma
exigncia para consulta ad hoc (um processador de textos
tradicional um bom exemplo). Na realidade, essas aplicaes
no so de modo algum aplicaes de bancos de dados no
sentido clssico dessa expresso; o SGBD que melhor serve a
suas necessidades apenas o sistema interno de arquivos
fornecido como parte do sistema operacional subjacente.
* Vimos no Captulo 24 que os sistemas fornecem
tradicionalmente um tipo de dados BLOB para se lidar com
objetos binrios extensos. Em um sistema telacional/objeto,
valores de dados de certos tipos definidos pelo usurio
poderiam muito bem ser ar-
754 inazenados fisicamente como BLOBs.
[
FlC
ap dra
SQ
nhi dr de
ad
do
qu
su
qu
e s
1h
dados simples dados complexos
FIGURA 25.4 A matriz de classificao de SGBDs de Stonebraker
O Quadrante 2 representa aplicaes que tm uma exigncia de
consulta ad hoc, mas ainda lidam apenas com dados bastante
simples. A maioria das aplicaes comerciais de hoje se
encaixa nesse quadrante, e elas so razoavelmcnte bem aceitas
por SGI3Ds relacionais tradicionais (ou pelo menos de
SQL).
O Quadrante 3 representa aplicaes com exigncias de dados e
processamento complexas, mas nenhuma exigncia de consulta ad
hoc. Por exemplo, aplicaes de CAD/CAM podem se encaixar
nesse quadrante. Os SGBDs de objetos atuais se destinam
principalmente a esse segmento do mercado (os produtos de SQL
tradicionais tendem a no realizar um trabalho muito bom
sobre aplicaes do Quadrante 3).
Finalmente, o Quadrante 4 representa aplicaes com
necessidade de dados complexos e consultas ad hoc sobre seus
dados. Stonebraker oferece um exemplo de banco de dados
contendo slides digitalizados de 35 mm, com uma consulta
tpica sendo Obter imagens do alvorecer tiradas em um raio
de 36 quilmetros de Sacramento, Califrnia. Em seguida, ele
continua a apresentar argumentos para apoiar sua posio de
que (a) um SGBD telacional/objeto necessrio para
aplicaes que se encaixam nesse quadrante, e (b) ao longo
dos prximos anos, a maioria das aplicaes se enquadrar ou
migrar para esse quadrante. Por exemplo, at mesmo uma
simples aplicao de recursos humanos poder se expandir para
incluir fotografias de empregados, gravaes sonoras
(mensagens faladas) e caractersticas semelhantes.
Em suma, Stonebraker est afirmando (e ns concordamos) que
sistemas relacional/objeto fazem parte do futuro do mundo;
eles no so apenas um modismo passageiro, que logo ser
substitudo por alguma outra idia. Entretanto, talvez se
deva lembrar que, pelo menos no que se refere a ns, um
sistema telacional/objeto verdadeiro apenas um sistema
relacional verdadeiro. Em particular, um sistema que no
comete nenhum dos dois Grandes Erros! Stonebraker parece no
concordar com essa nossa posio aqui pelo menos, a
referncia [25.3 1] nunca chega a dizer isso e, na verdade,
ela implica que a mistura de ponteiros e relaes no
apenas aceitvel, mas tambm desejvel (de fato,
obrigatria).
Seja como for, argumentaramos que um sistema
telacional/objeto genuno resolveria todos os problemas que
(como afirmamos no captulo anterior) so na realidade
problemas de sistemas que so apenas sistemas de objetos
simples, no de sistemas relacional/objeto. Para sermos
especficos, um sistema desse tipo deve ser capaz de oferecer
suporte para todos os itens a seguir sem dificuldade:
- Consulta ad hoc, definio de vises e restries de
integridade declarativas.
- Mtodos que ampliem as classes (no h necessidade de um
operando de destino distinto).
- Classes definidas dinamicamente (para resultados de
consultas ad hoc).
- Acesso de modo duplo (no enfatizamos esse ponto no
Captulo 24, mas os sistemas de objetos em geral no admitem
o princpio da dualidade em vez disso, eles empregam
diferentes linguagens para acesso programado e interativo ao
banco de dados).
- Verificao de integridade adiada (at o COMMIT).
- Restries de transies.
consulta
sem consulta
- Otimizao semntica.
755
2

4

1

3

Relacionamentos de grau maior que dois.
- Regras de chave estrangeira (ON DELETE CASCADE, etc.).
- Possibilidade de otimizao.
E assim por diante. Alm disso:
- OIDs e pointer chasing esto agora totalmente nos
bastidores e ocultas do usurio.
- Perguntas de objetos difceis (por exemplo, o que
significa a juno de dois objetos?) desaparecem.
- Os benefcios do encapsulamento, ainda se aplicam como so
hoje, mas a valores escalares dentro de relaes, e no a
relaes em si.
- Agora, os sistemas relacionais podem tratar reas de
aplicaes complexas como CAD/CAM, conforme discutimos
anteriormente.
Alm disso, a abordagem conceitualmente limpa.
25.6 RESUMO
Examinamos rapidamente o campo dos sistemas
telacional/objeto. Esses sistemas so (ou deveriam ser)
basicamente apenas sistemas relacionais que admitem o
conceito de domnio relaciona! (ou seja, tipos) de maneira
apropriada significando em particular que os usurios so
(ou deveriam ser) capazes de definir seus prprios tipos. No
precisamos fazer nada para que o modelo relaciona! alcance a
funcionalidade de objetos que desejamos (exceto implement-
la).
Em seguida, examinamos os dois Grandes Erros. O primeiro
igualar classes de objeto e variveis de relaes (uma
equao que infelizmente muito atraente, pelo menos
primeira vista). Especulamos que o erro surge de uma confuso
sobre duas interpretaes bem distintas do termo objeto.
Discutimos um exemplo (em detalhes) mostrando a aparncia de
um sistema que comete O Primeiro Grande Erro, e explicamos
algumas das consequncias desse equvoco. Uma consequncia
importante que ele tambm parece conduzir diretamente a O
Segundo Grande Erro! ou seja, a mistura de ponteiros e
relaes (embora na verdade esse segundo erro possa ser
cometido sem o primeiro, e praticamente todo sistema no
mercado parece estar cometendo esse erro). Nossa posio
que O Segundo Grande Erro mina a integridade conceitual do
modelo relaciona! de vrias maneiras. Em particular, ele
viola O Princpio da Permutabilidade de relaes bsicas e
derivadas.
Depois, fizemos um breve exame de algumas questes de
implementao. O ponto fundamental que a adio de um novo
pacote de tipos afeta pelo menos os componentes compilador,
otimizador e gerenciador de armazenamento do sistema. Como
consequncia, um sistema telacional/objeto no pode ser
implementado ao menos no muito bem pela simples
imposio de uma nova camada de cdigo sobre um sistema
relaciona! existente; em vez disso, o sistema precisa ser
reconstrudo desde o incio, a fim de tornar cada componente
individualmente extensvel conforme necessrio.
Finalmente, examinamos a matriz de classificao de SGBDs de
Stonebraker e discutimos rapidamente as vantagens que
poderiam ser obtidas de uma aproximao verdadeira entre as
tecnologias de objetos e relaciona! (onde por verdadeira
queremos dizer em particular que o sistema em questo no
comete nenhum dos dois Grandes Erros).
REFERNCIAS E BIBLIOGRAFIA
Vrios prottipos relacional/objeto foram elaborados nos
ltimos anos. Dois dos mais conhecidos e mais influentes so
o Postgres da Universidade da Califrnia em Berkeley [25.26,
25.30, 25.32] e Starburst da IBM Research [25.14, 25.17,
25.21 e 25.22]. Observamos que (pelo menos em sua forma
original), nenhum desses sistemas aderiu equao
obviamente correta domnio = classe.
756
Devemos mencionar tambm que a SQL3 inclui uma srie de
caractersticas destinadas especificamente a fornecer suporte
para sistemas relacional/objeto (consulte o Apndice B).
25.1 Frederick P. Brooks, Jr.: The Mythical Man-Month (edio
do vigsimo aniversrio). Reading. Mass.: Addison-Wesley
(1995).
25.2 Michael J. Carey, Nelson M. Mattos e Anil K. Nori:
Object/Relational Database Systems: Principles, Products,
and Chailenges, Proc. 1997 ACM SIGMOD Int. Conf. on
Management of Data, Tucson, Arizona (maio de 1997).
Para citar: Tipos de dados abstratos, funes definidas pelo
usurio, tipos de linhas, referncias, herana, subtabelas,
colees, gatilhos o que significa tudo isso, afinal? Boa
pergunta! H oito caractersticas na lista (e existe a
suposio tcita de que todas elas so recursos especficos
de SQL3). Dessas oito, poderamos afirmar que pelo menos
quatro caractersticas so indesejveis, duas outras fazem
parte da mesma coisa, e as outras duas so ortogonais
questo de se saber se o sistema ou no telacional/objeto.
Consulte o Apndice B.
25.3 Michael J. Carey et ai.: The BUCKY Object/Relational
Benchmark, Proc. 1997 ACM SIGMOD lnt. Conf. on Management of
Data, Tucson, Arizona (maio de 1997).
Do resumo: BUCKY (Benchmark of Universal or Complex Kwery
Interfaces [sicl) um benchmark orientado a consultas que
testa muitos recursos fundamentais oferecidos por sistemas
relacional/objeto, inclusive tipos de linhas e herana,
referncias e expresses de caminhos, conjuntos de valores
atmicos e de referncias, mtodos e acoplamento tardio, e
ainda tipos abstratos de dados definidos pelo usurio e seus
mtodos.
25.4 R. G. G. Cattell: What Are Next-Generation DB
Systems?, CACM 34, Nmero 10 (outubro de 1991).
25.5 Donald D. Chamberlin: Relations and References
Another Point of View, InfoDB 10, Nmero 6 (abril de 1997).
Consulte a anotao referncia [25.11].
25.6 Surajit Chaudhuri e Luis Gravano: Optimizing Queries
over Multi-Media Repositories, Proc. 1996 ACM SIGMOD Int.
Conf. on Management of Data, Montreal, Canad (junho de
1996).
Os bancos de dados relacional/objeto poderiam muito bem ser
usados como repositrios de multimdia. As consultas sobre
dados de multimdia em geral no produzem apenas um conjunto
de objetos resultantes, mas tambm um conceito de
correspondncia para cada um desses objetos que indica como
ele atende condio de pesquisa (por exemplo, o grau de
vermelhido de uma imagem). Essas consultas podem
especificar um limiar no conceito de correspondncia e tambm
pode especificar uma quota [6.4]. Esse artigo considera a
otimizao de tais consultas.
25.7 Surajit Chaudhuri e Kyuseok Shim: Optimization of
Queries with User-Defined Predicates, Proc. 22nd Int. Conf.
on Very Large Data Bases, Mumbai (Bombaim), India (setembro
de 1996).
25.8 E. F. Codd e C. J. Date: Interactive Support for
Nonprogrammers: The Relational and Network Approaches, em C.
J. Date, Relational Database: Selected Writings. Reading,
Mass.: Addison-Wesley (1986).
O artigo que introduziu a noo de essencialidade, um
conceito fundamental para a compreenso adequada de modelos
de dados (em ambos os sentidos desse termo! consulte o
Captulo 1, Seo 1.3). Basicamente, o modelo relacional tem
apenas uma construo de dados essencial, a prpria relao.
Ao contrrio, o modelo de objetos tem muitas: conjuntos,
sacolas, listas, arrays e assim por diante (para no
mencionarmos IDs de objetos). Consulte as referncias [25.9 e
25.101 e tambm [25. 13] para ver uma explicao adicional.
25.9 C. J. Date: Support for the Conceptual Schema: The
Relational and Network approaches, em Relational Database
Writings 1985-1989, Reading, Mass.: Addison-Wesley (1990).
Um argumento contrrio mistura de ponteiros e relaes
[25.11] a complexidade que os ponteiros provocam. Esse
artigo inclui um exemplo que ilustra esse assunto com muita
clareza (veja as Figuras 25.5 e 25.6).
25.10 C. J. Date: Essentiality, em Relational Database
Writings 1991-1994. Reading, Mass.: Addison-Wesley (1995).
25.11 C. J. Date: Don't Mix Pointers and Relations! e
Don't Mix Pointers and Relations Please!, ambos em C. J.
Date, Hugh Darwen e David McGoveran, Relational Database
Writings 1994-1997. Reading, Mass.:
Addison-Wesley (1998).
757
O primeiro desse dois artigos contesta de modo enftico O
Segundo Grande Erro. Na referncia [25.5], Chamberlin
apresenta uma refutao a alguns argumentos desse primeiro
artigo. O segundo artigo foi escrito como uma resposta direta
refutao de Chamberlin.
25.12 C. J. Date: Objects and Relations: Forty-Seven Points
of Light, em C. J. Date, Hugh Darwen e David McGoveran,
Relational Database Writings 1994-1997. Reading, Mass.:
Addison-Wesley (1998).
Uma resposta minuciosa a cada ponto da referncia [25.19).
25.13 C. J. Date: Relational Really Is Different, parte de
nmero 10 da referncia [5.9]. www.intelligententerprise.com.
25.14 Linda G. DeMichiel, Donald D. Chamberlin, Bruce G.
Lindsay, Rakesh Agrawal e Manish Arya: Polyglot:
Extensions to Relational Databases for Sharable Types and
Functions in a Multi-Language Environment, IBM Research
Report RJ8888 (julho de 1992).
Citando o resumo: O Polyglot um sistema de tipos de bancos
de dados relacionais extensvel que admite herana,
encapsulamento e expedio dinmica de mtodos. (Expedio
dinmica de mtodos outra expresso que significa
acoplamento em tempo de execuo. Continuando:) [O Polyglot]
permite o uso de vrias linguagens de aplicao e permite que
os objetos conservem seu comportamento enquanto cruzam a
fronteira entre o banco de dados e o programa de aplicao.
Esse artigo descreve o projeto do Polyglot, extenses para a
linguagem SQL com o objetivo de dar suporte ao uso de tipos e
mtodos do Polyglot e ainda a implementao do Polyglot no
[prottipo] relacional Starburst.
MAJORP#
P1
P1
P5
P3
P6
P5
P2
MINORP#
P2
P4
P3
P6
P1
P6
P4
QDE
2
4
1
3
9
8
3
FIGURA 25.5 Uma relao de lista de materiais
Setas cheias: lista de materiais Setas tracejadas: usadas em
758 FIGURA 25.6 Verso baseada em ponteiros da Figura 25.5
O Polyglot est atacando claramente os tipos de questes que
so o assunto deste captulo (como tambm dos Captulos 5, 19
e 24). Entretanto, algumas observaes so relevantes.
Primeiro, o termo relacional domnio (surpreendentemente)
nunca mencionado. Em segundo lugar, o Polyglot fornece os
geradores de tipos embutidos (o termo do Polyglot
metatipos) de tipo bsico, de tipo tupla, de tipo de
renomeao, de tipo array e de tipo linguagem, mas (de novo
surpreendentemente) no de tipo relao. Porm, o sistema foi
projetado para permitir a introduo de geradores de tipos
adicionais.
25.15 David J. DeWitt, Navin Kabra, Jun Luo, Jignesh M. Patel
e Jie-Bing Yu: Client-Server Paradise, Proc. 2Oth Int.
Conf. on Very Large Data Bases, Santiago, Chile (setembro de
1994).
O Paradise Parallel Data Information System um
prottipo telacional/objeto (originalmente
relacional estendido) da Universidade de Wisconsin, nos
EUA, criado para manipular aplicaes
GIS (GIS Geographic Information System). Esse artigo
descreve o projeto e a implementao do
Paradise.
25.16 Michael Godfrey, Tobias Mayr, Praveen Seshadri e
Thorsten von Eichen: Secure and Portable Database
Extensibility, Proc. 1998 ACM SIGMOD Int. Conf. on
Management of Data, Seattle, Wash. (junho de 1998).
Tendo em vista que operadores definidos pelo usurio so
fornecidos por clientes desconhecidos ou no confiveis, o
SGBD deve ser cauteloso quanto a operadores que poderiam
provocar a queda do sistema ou modificar seus arquivos ou
memria a diretamente (burlando os mecanismos de
autorizao), ou ainda monopolizar CPU, memria ou recursos
de disco (ligeiramente modificado). Os controles so
obviamente necessrios. Esse artigo relata investigaes
sobre essa questo, utilizando o Java e o prottipo
telacional/objeto PREDATOR [25.24]. Ele conclui de forma
corajosa que um sistema de banco de dados pode fornecer
suporte para extensibilidade segura e porttil usando o Java
sem sacrificar indevidamente o desempenho.
25.17 Laura M. Haas, J. C. Freytag, G. M. Lohman e Hamid
Pirahesh: Extensible Query Processing in Starburst, Proc.
1989 ACM SIGMOD Int. Conf. on Management of Data, Portland,
Ore. (junho de 1989).
Os objetivos do projeto Starburst se expandiram um pouco aps
a elaborao do artigo original [25.21]:
o Starburst oferece suporte para a incluso de novos mtodos
de armazenamento para tabelas, novos tipos de mtodos de
acesso e restries de integridade, novos tipos de dados,
funes e novas operaes sobre tabelas. O sistema est
dividido em dois componentes principais, Core e Corona,
correspondendo respectivamente ao RSS e ao RDS no prottipo
original do System R (consulte a referncia [4.2] para ver
uma explicao desses dois componentes do System R). O Core
admite as funes de extensibilidade descritas na referncia
[25.21j. Corona admite a linguagem de consulta Hydrogen do
Starburst, um dialeto de SQL que (a) elimina a maioria das
restries de implementao de SQL do System R, (b) muito
mais ortogonal que a SQL do System R, (c) admite consultas
recursivas e (d) extensvel pelo usurio. O artigo inclui
uma discusso interessante sobre a reescrita de consultas
isto , as regras de transformao de expresses (consulte o
Captulo 17). Veja tambm a referncia [17.50].
25.18 Joseph M. Hellerstein and Jeffrey F. Naughton: Query
Execution Techniques for Caching Expensive Methods, Proc.
1996 ACM SIGMOD Int. Conf. on Management of Data, Montreal,
Canad (junho de 1996).
25.19 Won Kim: On Marrying Relations and Objects: Relation-
Centric and Object-Centric Perspectives, Data Base
Newsletter 22, Nmero 6 (novembro/dezembro de 1994).
Esse artigo argumenta contra a posio de que um equvoco
srio igualar variveis de relaes e classes (O Primeiro
Grande Erro). A referncia [25.12] uma resposta a esse
artigo.
25.20 Won Kim: Bringing Object/Relational Down to Earth,
DBP&D 10, Nmero 7 (julho de 1997).
Nesse artigo, Kim afirma que certamente reinar a confuso
no mercado de bancos de dados relacional/objeto porque,
primeiro, foi dado um peso exagerado ao papel da
extensibilidade de tipos de dados e, em segundo lugar, a
medida da completeza telacional/objeto de um produto ...
uma rea p0- tencialmente sria de perplexidade. Ele
continua a propor uma mtrica prtica para a completeza
telacional/objeto que possa ser usada como uma diretriz para
determinar se um produto verdadeiramente
[telacional/objeto]. Esse esquema envolve os seguintes
critrios:
1. Modelo de dados.
2. Linguagem de consulta.
3. Servios de misso crtica.
4. Modelo computacional. 759
5. Desempenho e escalabilidade.
6. Ferramentas de bancos de dados.
7. Aproveitamento da energia.
Com respeito ao primeiro desses critrios (o crucial!), Kim
assume a posio muito diferente daquele de The Third
Manifesto [3.3] de que o modelo de dados deve ser o Core
Object Model (Modelo de Objetos do Ncleo) definido pelo
Object Management Group (OMG), que inclui o modelo de dados
relacional, bem como os conceitos centrais de modelagem
orientada a objetos das linguagens de programao orientada a
objetos. De acordo com Kim, ele incluir assim todos os
seguintes conceitos: classe (Kim acrescenta ou tipo),
instncia, atributo, restries de integridade, IDs de
objetos, encapsulamento, herana de classe (mltipla),
herana ADT (mltipla), dados de referncia de tipo,
atributos com valor de conjunto, atributos de classes,
mtodos de classes e outros ainda. Observe que as relaes
que, claro, consideramos ao mesmo tempo cruciais e
fundamentais nunca so mencionadas explicitamente; Kim
afirma que o Core Object Model do OMG inclui o modelo
relacional inteiro, alm de tudo que se encontra na lista
anterior, mas de fato isso no ocorre.
25.2 1 Bruce Lindsay, John McPherson e Hamid Pirahesh: A
Data Management Extension Architecture, Proc.
1987 ACM SIGMOD Int. Conf. on Management of Data, San
Francisco, Calif. (maio de 1987).
Descreve a arquitetura geral do prottipo Starburst. O
Starburst facilita a implementao de extenses de
administrao de dados para sistemas de bancos de dados
relacionais. So descritos nesse artigo dois tipos de
extenses, as estruturas de armazenamento e mtodos de acesso
definidos pelo usurio, e tambm restries de integridade
definida pelo usurio (mas certo que todas as restries de
integridade so definidas pelo usurio?) e procedimentos
ativados. Contudo (para citar o artigo), claro que existem
outras orientaes pelas quais importante ser capaz de
estender [inclusive SGBDs] tipos de dados
[e] tcnicas de avaliao de consultas ... definidas pelo
usurio.
25.22 Guy M. Lohman et al.: Extensions to Starburst:
Objects, Types, Functions, and Rules, CACM 34, Nmero 10
(outubro de 1991).
25.23 David Maier: Comments on the Third-Generation Database
System Manifesto, Tech. Report Nmero CS/E 91-012, Oregon
Graduate Center, Beaverton, Ore. (abril de 1991).
Maier altamente crtico sobre quase tudo na referncia
[25.34]. Concordamos com algumas de suas crticas e
discordamos de outras. No entanto, achamos interessantes as
observaes a seguir (elas sustentam nossa posio de que
objetos envolvem apenas uma boa idia, ou seja, o suporte
para tipos de dados prprios): Muitos de ns no campo dos
bancos de dados orientados a objetos lutaram para destilar a
essncia da orientao a objetos' para um sistema de banco
de dados... Minha prpria maneira de pensar sobre isso foi
[sic] das caractersticas mais importantes de BDOOs que mudou
com o passar do tempo. A princpio, pensei que era a herana
e o modelo de mensagens. Mais tarde, cheguei a pensar que a
identidade de objetos, o suporte para estado complexo e o
encapsulamento do comportamento era mais importantes.
Recentemente, aps comear a ouvir de usurios de SGBDOOs
sobre o que eles mais valorizam nesses sistemas, imaginei que
a extensibilidade de tipo a chave. A identidade, o estado
complexo e o encapsulamento ainda so importantes, mas
[somentel de tal maneira que eles ofeream suporte para a
criao de novos tipos de dados.
25.24 Jignesh Patel et al.: Building a Scalable Geo-Spatial
DBMS: Technology, Implementation, and Evaluation, Proc. 1997
ACM SIGMOD Int. Conf. on Management of Data, Tucson. Ariz.
(maio de 1997).
Citando o resumo: Esse artigo apresenta uma srie de novas
tcnicas para formar sistemas de bancos de
dados geoespaciais em paralelo e discute sua implementao no
sistema de banco de dados telacional/ob jet Paradise
[25.151.
25.25 Raghu Ramakrishnan: Database Management Systems.
Boston, Mass.: McGraw-Hill (1998). 4
25.26 Lawrence A. Rowe e Michael R. Stonebraker: The
Postgres Data Model, Proc. l3th Int. Conf. 011 Very Large
Data Bases, Brighton, Reino Unido (setembro de 1987).
25.27 Hanan Samet: The Design andAnalysis of Spatial Data
Structures, Reading, Mass.: Addison-Wesley (1990).
25.28 Cynthia Maro Saracco: Universal Database Management: A
Guide to Object/Relational Technology. San Francisco, Calif.:
Morgan Kaufmann (1999).
Uma avaliao legvel de alto nvel. Porm, observamos que
Saracco defende (a propsito, como faz Stonebraker na
referncia [25.3 1]) uma forma muito suspeita de herana,
envolvendo uma verso da idia
de subtabelas e supertabelas sobre a qual somos cticos
para comear com [13.121 que significativa- mente
diferente da verso includa na SQL3. Para ser especfico,
suponha que a tabela PGMR (programadores) seja definida
como uma subtabela da tabela EMP (empregados). Ento,
Saracco e Stonebraker consideram EMP contendo linhas apenas
para empregados que no so programadores, enquanto a SQL3
consideraria essa tabela contendo linhas para todos os
empregados (consulte o Apndice B).
25.29 Praveen Seshadri e Mark Paskin: PREDATOR: An OR-DBMS
with Enhanced Data Types, Proc. 1997 ACM SIGMOD Int. Conf.
on Management of Data, Tucson, Ariz. (maio de 1997).
A idia bsica em PREDATOR fornecer mecanismos para que
cada tipo de dados especifique a semntica de seus mtodos;
essa semntica usada ento na otimizao de consultas.
25.30 Michael Stonebraker: The Design of the Postgres
Storage System, Proc. l3th Int. Conf. on Very Large Data
Bases. Brighton, Reino Unido (setembro de 1987).
25.31 Michael Stonebraker e Paul Brown (com Dorothy Moore):
Object/Reiationai DBMSs: Tracking the Next Great Wave (2k'
edio). San Francisco), Calif.: Morgan Kaufmann (1999).
Esse livro um tutorial sobre sistemas relacional/objeto.
Ele se baseia pesadamente na verdade, quase exclusivamente
na Universal Data Option para o produto Dynamic Server
daInformix. Essa Universal Data Option se baseada em um
sistema anterior chamado Illustra (um produto comercial em
cujo desenvolvimento o prprio Stonebraker participou).
Consulte a referncia [3.3] para ver uma anlise estendida e
uma crtica desse livro; consulte tambm a anotao
referncia [25.28].
25.32 Michael Stonebraker e Greg Kemnitz: The Postgres Next
Generation Database Managenent System, CACM 34, Nmero 10
(outubro de 1991).
25.33 Michael Stonebraker e Lawrence A. Rowe: The Design of
Postgres, Proc. 1986 ACM SIGMOD Int. Conf. on Management of
Data, Washington, DC (junho de 1986).
Os objetivos anunciados do Postgres so:
1. Fornecer melhor suporte para objetos complexos:
2. Promover a extensibilidade para tipos de dados, operadores
e mtodos de acesso.
3. Oferecer recursos ativos de bancos de dados (alertas e
triggers), alm do suporte inferncia.
4. Simplificar o cdigo do SGBD para a recuperao que
quedas.
5. Produzir um projeto que possa tirar proveito de discos
pticos, estaes de trabalho com multiprocessadores e chips
VLSI de projeto personalizado.
6. Efetuar o mnimo de mudanas possvel (de preferncia
nenhuma) no modelo relacional.
25.34 Michael Stonebraker et ai.: Third-Generation Database
System Manifesto, ACM SIGMOD Record 19, Nmero 3 (setembro
de 1990).
Em parte, esse artigo uma resposta a isto , uma
contraproposta para o Object-Oriented Database System
Manifesto [24.1] que (entre outras coisas) essencialmente
ignora por completo o modelo relacional (!). Uma citao: Os
sistemas de segunda gerao foram uma contribuio importante
em duas reas, o acesso no procedural aos dados e a
independncia de dados, e esses avanos no devem ser
comprometidos pelos sistemas de terceira gerao. As
caractersticas a seguir so consideradas requisitos
essenciais de um SGBD de terceira gerao (parafraseamos um
pouco o original):
1. Fornecer servios de bancos de dados tradicionais, alm de
estruturas e regras de objetos mais ricas.
- Sistema de tipos rico.
- Herana.
- Funes e encapsulamento.
- IDs de tuplas atribudas pelo sistema opcionais.
- Regras (por exemplo, regras de integridade) no amarradas a
objetos especficos
2. Incluir SGBDs de segunda gerao.
- Navegao apenas como ltimo recurso.
- Definies de conjuntos intensionais e extensionais
(significando colees que so mantidas auto maticament pelo
sistema e colees que so mantidas manualmente pelo
usurio).
- Vises atualizveis.
- Clusters, ndices etc., ocultos do usurio. 761
3. Fornecer suporte a sistemas abertos.
- Suporte para vrios idiomas.
- Persistncia ortogonal ao tipo.
- SQL (caracterizada como dialeto de dados intergalctico).
- Consultas e resultados devem ser do nvel mais baixo de
comunicao cliente/servidor.
Consulte a referncia [3.31 para ver uma anlise e uma
crtica mais abrangente desse artigo, e tambm a referncia
[25.231. Nota: a propsito, agora podemos explicar por que
The Third Manifesto chamado terceiro... Ele foi escrito
especificamente para seguir (e, esperamos, suceder) os dois
manifestos anteriores, apresentados nas referncias [24.1] e
[25.34].
25.35 Maurice V. Wilkes: Software and the Programmer, CACM
34, Nmero 5 (maio de 1991).
762