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