Tcc Exemplo OO Pagina12

SistemasdeBancosdeDadosOrientadosaObjetos

IvanLuizMarquesRicarte

Depto.EngenhariadeComputaçãoe AutomaçãoIndustrial

FaculdadedeEngenhariaElétricaedeComputação

UniversidadeEstadualdeCampinas

mailto:ricarte@dca.fee.unicamp.br

http://www.dca.fee.unicamp.br/~ricarte/

Setembrode1998

Resumo

Sistemasdebancodedadosrepresentamum papelfundamentalemaplicaçõesdeprocessa-

mentodeinformaçãonão-numérica,ondea utilizaçãodetaissistemaspermitefacilitar a manu-

tençãodedadosconsistentesquepodemsercompartilhadospordiversasaplicações,asquaisnão

precisamconhecero modocomotaisdadossãointernamentearmazenadosou representados.A

tecnologiadebancodedadosjá estámaduraparadiversasaplicações,principalmentenasáreas

administrativae comercial.

Entretanto,novascategoriasde aplicaçõestêmdemandadoo gerenciamentodedadosmais

complexos— sãoaplicaçõestaiscomosistemasdeapoioa projetose deautomaçãodeescritó-

rios. Paraessasaplicações,o paradigmadeorientaçãoaobjetossurgecomoalternativaadequada

paraa representaçãoe manipulaçãodosdados,masé precisoaindaintegrardeformaadequada

estatecnologiaasistemasdebancodedados.

Sistemasgerenciadoresdebancosdedadosorientadosa objetosconstituema propostacor-

renteparaa soluçãodesseproblema.Nestetrabalhoapresentam-seosaspectosbásicosdamo-

delageme da tecnologiade tais sistemas,com umabreve discussãosobretendênciasna área

deprocessamentodeinformaçãonão-numérica.Pelaanálisedessastendências,observa-seque

astécnicasdesenvolvidasparaa integraçãodeorientaçãoa objetosa bancodedadosoferecem

contribuiçõesquecertamenteestarãopresentesnasnovasplataformasdeprocessamentoporob-

jetosdistribuídos. Assim,o estudode sistemasgerenciadoresde basede objetosdevemainda

permanecercomoobjetodeinteresseporumlongoperíodo.

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

1 Moti vação

Um bancodedadoséumacoleçãodedadosrelacionadosquepodeserarmazenadasobalguma

formafísica.Osdadosarmazenadosemumbancodedadosrepresentamalgumaspectoespecíficodo

mundoreal— um universode discursodeondeosdadossãoobtidos— e apresentamalgumgrau

decoerêncialógicaentreseuscomponentes.Portanto,umacoleçãoaleatóriadedadosnãoconstitui

umbancodedados.

Um sistemagerenciadordebancodedadoséo softwarequepermitecriar, manteremanipular

bancosdedadosparadiversasaplicações.A criaçãoemanutençãodebancosdedadosétarefadeuma

pessoaou grupodepessoas,normalmentereferenciadacomoo administrador do bancode dados.

A manipulaçãodobancodedados— atualizaçõeseconsultas— érealizadadiretaou indiretamente,

atravésdeprogramasaplicativos,pelosusuáriosdobancodedados.O sistemagerenciadordebanco

dedadospodeserdepropósitogeralouespecíficoparaalgumaaplicação.

Um sistemadebancodedadoséconstituídoporumbancodedadoseporumsistemagerencia-

dor debancodedados,comomostradonaFig. 1 [16]. Um sistemadebancodedadosé usualmente

umaaplicaçãoqueserve desuportea outrasaplicações,taiscomofolha depagamento,controlede

pessoale informaçõesbancárias.

MetadadosBase de DadosArmazenados

Software para Processar Consultas

e Programas

Software paraAcessar os Dados

Armazenados

Usuários/Programadores

Programas Aplicativos/Consultas

Sistema deBanco de Dados

SGBD

Figura1: Sistemasimplificadodebancodedados.

Tradicionalmente,sistemasdebancodedadosestavam relacionadosa aplicaçõesnasáreasad-

ministrativa e comercial. Com o tempo,asvantagensobtidascom a utilizaçãode um sistemade

bancode dadosparasuportara armazenagemda informaçãode umaaplicação— principalmente

a independênciadaaplicaçãocomrelaçãoà estruturainternadearmazenageme a possibilidadede

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

compartilhardadosentreaplicações— passaramaserdesejadasemoutrasclassesdeaplicações,tais

comoprojetosdeengenharia(CAD/CAE — ComputerAidedDesign,ComputerAidedEngineering),

automaçãoindustrialedeescritórios(CAM — ComputerAidedManufacturing, OA — OfficeAuto-

mation), sistemasespecialistasdesuporteà tomadadedecisões(DSS— DecisionSupportSystems)

e sistemasdesuporteao trabalhocooperativo (CSCW— ComputerSupportedCooperative Work).

Muitasdestasaplicações“não convencionais”impõemrequisitosaosistemadebancodedadosque

nãoestavam presentesnasaplicaçõestradicionais,tais comolidar commaioresvolumesdedados,

a necessidadede manipulaçãode dadosem formatosnão-alfanuméricos— incluindo informação

multimídia— e o tratamentodeesquemasevolutivosedinâmicos.

As necessidadesdessasnovas categoriasde aplicaçõesconstituema maior motivaçãoparao

surgimentodenovasabordagensparao gerenciamentodedados.É nestesentidoqueaintegraçãodo

paradigmadeorientaçãoaobjetosasistemasdebancodedadostemsurgido comoa tendênciamais

promissoraemtermosdegerenciamentodedadosparaasmaisdiversascategoriasdeaplicação.

Nestetrabalhoapresenta-seum breve relatoda evoluçãodos sistemasde bancode dadosem

direçãoa sistemasgerenciadoresde basede objetos. Na Seção2 descreve-sea “primeira onda”

do processamentoda informaçãonão-numérica,culminandocom a propostado modelorelacional

e o desenvolvimentodosprimeirossistemasgerenciadoresdebancodedadosrelacionais.Sistemas

gerenciadoresdebancodedadosrelacionaisaindadominamboafatiadomercadodeprocessamento

de informação,utilizandoumatecnologiadominadae sendoperfeitamenteadequadosparagrande

partedasaplicaçõescomerciaiseadministrativas.

NaSeção3apresentam-seosresultadosdeumperíododetransição,ondealimitaçãodosmodelos

tradicionaisderepresentaçãodedadostornou-sepatenteparaasnovasaplicaçõescomputacionaisque

surgiam. Nessecontexto foi quea orientaçãoa objetosfoi propostacomoo paradigmaadequadode

representaçãodedados,emboraaindafosseincertocomoo casamentoentreorientaçãoa objetose

sistemasdebancodedadosdevesseocorrer. Foi umperíododeexperimentação,duranteo qualforam

lançadososfundamentosparaamodelagemdedadossegundoo paradigmadeorientaçãoaobjetos.

NaSeção4 apresenta-seo resultadodoamadurecimentodaaplicaçãodoparadigmadeorientação

aobjetosasistemasdebancodedados.Aspectosdatecnologiaqueoferecesuporteàimplementação

desistemasgerenciadoresdebasedeobjetossãoapresentados.A Seção5 apresentaalgunsexemplos

representativosdegerenciadoresdeobjetos,ondealgumasdestastécnicassãoilustradas.

Finalmente,na Seção6 sãoapresentadasastendênciasparao futuro do gerenciamentode da-

dosemaplicaçõescomputacionais,queindicamsero paradigmadeorientaçãoa objetosa basepara

a evoluçãodessasaplicações.Assim, sistemasgerenciadoresde basede objetosdeverãode fato

representarumpapelfundamentalcomorepositóriosdeinformaçãonofuturodasaplicaçõescompu-

tacionaisporum longoperíodo.

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

2 Evoluçãodesistemasdebancodedados

Paramelhorcompreendero estadoatualdatecnologiadebancodedados,é interessanteobservar

comoestatecnologiasurgiu eevoluiu.

O surgimento dos primeiros computadoresestáintimamenteligado à realizaçãode cálculos

numéricosrepetitivos. Esteera a motivaçãode Babbageparao projeto e elaboraçãode seuEn-

genhoAnalítico no SéculoXIX. Da mesmaforma, os trabalhospioneirosde Zuse,na Alemanha,

e deAtanasoff, Aiken,Mauchlye Eckert, nosEstadosUnidos,eramcomputadoresvoltadosparaa

soluçãodeproblemasnuméricos.Porumlongoperíodo,o desenvolvimentodecomputadorescientí-

ficos(paraaplicaçõesnuméricas)foi independentedodesenvolvimentodemáquinasparaaplicações

comerciais.Somenteno início dadécadade1960a integraçãoentreestasduastendênciasocorreu

de modomaisacentuado,principalmenteatravés dosesforçosda IBM paraotimizar sualinha de

produçãodemáquinasparaasduasáreasdeaplicação.

O conceitoquemotivouo surgimentodebancosdedadoséquasetãoantigoquantososprimeiros

sistemascomputacionaisparaaplicaçõesnão-numéricas,remontandoao final da décadade 1950.

Entretanto,o surgimentodesistemasgerenciadoresdebancodedadossofreuinfluênciastambémde

outrasáreasdeaplicação,notadamentedaáreadedefesaedeaplicaçõesmilitares.

2.1 Primórdios do processamentonão-numérico

O desenvolvimentode linguagensdedefiniçãodedadosfoi um fator importanteno desenvolvi-

mentodesistemasdebancodedados[18]. Entreelasdestacam-seCOMPOOLeCOBOL.

COMPOOL foi umalinguagemdesenvolvida noMassachusettsInstituteof Technologynocon-

texto do projetoSAGE, decontrolede tráfego aéreo,suportadopelaForçaAéreanorte-americana.

Ela forneciaum mecanismoparadefiniçãodeatributoscompartilhadospor centenasdeprogramas

emtempo-real.

COBOL é umalinguagemdeprogramaçãocomumaseçãocentralizadaparaa definiçãodeda-

dos,aDATA DIVISION. A criaçãodestalinguagemfoi coordenadapeloconsórcioCODASYL para

integrarlinguagensdeaplicaçõescomerciais,comoFACT (Honeywell), GECOM(GeneralElectric)

eCommercialTranslator(IBM).

O uso de uma linguagemcomumde definiçãoe processamentodos dados,como no casode

COBOL, eraatrativo pois a linguagemde definiçãoseguia o modeloda sistemasbaseadosem fi-

tase cartões.Entretanto,cadafabricanteadotava seupróprio esquemade armazenamento,o que

dificultava a transferênciadedadosentresistemasdefabricantesdistintos.

Geradoresde relatóriosforam criadosparafacilitar o trabalhode produzirsaídasformatadasa

partir de dadosarmazenadosno sistema.Emboratais tarefaspudessemser(e eram)produzidasa

partir delinguagensdeprogramaçãoconvencionais,osprogramasproduzidoserammuito extensos.

O usodestesreport generators permitiaentãoqueusuáriosexaminasseme manipulassemgrandes

volumesdedados,sendoumprecursordaslinguagensdeconsultaabancosdedados.

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

A GeneralElectricdesenvolveu o GeneralizedReportGenerator parao centrodeoperaçõesda

Atomic Energy CommissionemHanford,estadodeWashington,em1956.Estesistemafoi o ances-

tral detodosossistemasdegeraçãoderelatórios,incluindoossistemasdaIBM, RPG(System/360,

1965)eseusucessor, RPGII (1967).

2.2 Desenvolvimento degerenciadoresdebancodedados

Os primeirosprotótiposdesenvolvidos com a funcionalidadede gerenciardadosde umaapli-

cação,secomparadoscomossistemasatuais,oferecempoucasemelhançadefuncionalidade.Entre-

tanto,foramesforçossignificativosparaa épocae queinfluenciaramdediversosmodoso desenvol-

vimentodossistemasposteriores[18]. Algunsdestesesforçossãocitadosaseguir.

Base-Ballfoi um sistemaespecialistadeacessoa dadosatravésdeumainterfaceemlinguagem

natural. Os dados,assimcomoo vocabulário de interaçãoentreusuáriose a basede fatos,eram

relacionadosabeisebol.

B-Treeé umaestruturaextensivamenteutilizadaparaacessoeficientea arquivos,cujaprimeira

implementaçãofoi apresentadaemartigopublicadonaCommunicationsdaACM dejaneirode1962,

porCollilla e Sams.

QUERY eraumalinguagemdeconsultaadadoscomtraduçãoparalinguagemdemáquina,des-

critaemartigonaCommunicationsdaACM tambémdejaneirode1962,porCheathameWarshall.

Recol (Retrieval Command-OrientedLanguage), eraum sistemadegerenciamentodeacessoà

informaçãogeneralizadoparaunidadesdefita, descritoporClimensonnaCommunicationsdaACM,

demarçode1963.

ACSI-Matic foi um sistemaprojetadoparaexplorar o uso efetivo de memóriae inferências.

Foi o primeiro sistemaa oferecerum pacotegeneralizadopararecuperaçãode dadosem discos

comrequisiçõesembatch, a oferecergerenciamentodinâmicodememóriaprincipale a utilizar um

montadorcomrotinaparaalocaçãodinâmicadememória.Erapartedeumprojetodoexércitonorte-

americano,descritoinicialmenteem1960,comumprotótipoimplementadoem1964pelaRCA.

ADAM (AdvancedData ManagementSystem)foi um sistemadesenvolvido com recursosda

ForçaAéreanorte-americanaapartirdoprotótipoETF(ExperimentalTransportFacility), daMITRE

Corporation.Tinhaporobjetivo serumlaboratórioparamodelagem,desenvolvimentodeprotótipos,

verificaçãodeprojetoeavaliaçãodesistemasgerenciadoresdedados.

Colingo eraum conjuntode sistemasde gerênciade dadosorientadosa fitas, oferecendouma

estruturaestiloCOBOLemmáquinasIBM.

Apósestesprimeirosesforçosnosentidodeoferecersistemasmanipuladoresdedados,surgiram

de fato asprimeirasfamíliasde gerenciadoresde dados. Esforçospioneirosincluíamo Mark IV

paramáquinasIBM1401, desenvolvido por Postley na Informaticsno período1964–1968;o IDS

(Integrated Data Store), desenvolvido por Bachmanno período1964–1966;e o FormattedFile,

desenvolvido pelaforçaaéreanorte-americananoperíodo1961–1965.O FormattedFile influenciou

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

o produtoda IBM, GIS (Generalized Information System), que introduziu como contribuiçõeso

armazenamentodetabelacomo formatodoarquivo eamanipulaçãodegrandesarquivos.

O IDS combinava tecnologiadeacessoa posiçõesaleatóriascomlinguagensprocedimentaisde

alto nível (inicialmente,Gecom;posteriormente,COBOL,em1966)oferecendoum modelodeda-

dosdotipo rede.Nestamesmafamíliadegerenciadoresincluem-setambémAPL (AssociativePL/I),

desenvolvido naGeneralMotors (1966),e dataBASIC, daHoneywell (1970). As principaiscarac-

terísticasdestesgerenciadores,queforamcontribuiçõesimportantesparagerenciadoresdedadosque

seseguiram,incluem:

� verbosparamanipulaçãodedadosnainterfacedealtonível;

� descriçõesseparadasparaarmazenamentoeparaprogramação;

� princípioselementaresde manutençãoda consistência,com mecanismospararemoçãoe in-

serçãoimplícitas;

� conceitosdepaginaçãodedados;e

� acessocompartilhadoaosdados.

Osprimeirosdesenvolvimentoscomerciaisemgerenciadoresdebancodedadosforammarcados

pelosesforçosdaCODASYL, como Data BaseTaskGroup (DBTG, 1969–1971)e o projetoIMS

(1966–1969)daAgênciaEspacialnorte-americana(NASA), queinfluenciouo produtoIMS/360da

IBM.

A abordagemdo DBTG foi proporumaextensãoa COBOL paraa manipulaçãode bancosde

dados.Estaabordagemfoi adotadapor diversosprodutos,entreosquaisdestacam-seo IDMS (In-

tegrated Data ManagementSystem), desenvolvido pela IBM paraIBM System/360;IDMS-11 e

DBMS-10, implementaçõesdeIDMS pelaDigital EquipmentCorporationparasuasmáquinasPDP-

11/45e PDP-10,respectivamente;e o IDS/II , umaadaptaçãodeIDS realizadapelaHoneywell para

adequaçãoaopadrãoDBTG.

O projetoIMS foi resultadodeumdesenvolvimentoconjuntodasempresasRockwell,IBM eCa-

terpillarparaapoioaoprogramaApollo, daNASA. ForamfrutosdesteprojetoosprodutosICS/DL/I

(InformationControl System,DataLanguage/I), daRockwell;e IMS/360, daIBM desenvolvido para

suasmáquinasdafamíliaSystem/360.

2.3 O modelorelacionaldedados

A maior contribuiçãodosprimeirosgerenciadoresdedadosfoi introduzir a separaçãoentreos

dadosarmazenadose a descriçãodaestruturadosdados,o esquemadedados.As restriçõessobre

tiposdedadose deesquemasquesãopermitidospor um sistemaconstituemseumodelode dados.

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

A abordagempropostapelogrupoCODASYL/DBTG suportaum modelodedadosconhecidopos-

teriormentecomoo modelorede(network), enquantoqueaabordagemdeIMS introduziuo modelo

dedadoshierárquico.

Ambosmodelosdedadostêmporprincípioo estabelecimentodeligaçõesentregruposderegis-

tros.No modelodedadosredeosregistrossãoorganizadosnaformadegrafosdirigidos.No modelo

de dadoshierárquicocadaregistro tem um único antecessor, limitando a organizaçãodosdadosa

umaestruturadeárvore,ouhierarquia.

Apesardo avançoem relaçãoaosprimeirossistemasgerenciadoresde dados,os modelosrede

e hierárquicoapresentavam como limitaçãoumaforte dependênciaentreasestruturasinternasde

armazenamentoe a representaçãoabstratadosdados,influenciandoassimosmecanismosdemani-

pulação.Umacaracterísticagenéricadosprodutosbaseadosnestesmodelosestava no modocomo

asligaçõesentreregistroseraarmazenada,usualmenteutilizandoendereçosfísicos,comumaforte

dependênciaentrea representaçãodoarmazenamentoeamáquinaondeo sistemaestava implemen-

tado. No entanto,paraaquelaépocaportabilidadenãoeraumaquestãomaior, poismuitosclientes

concentravamsuasaplicaçõesemumaúnicamáquinadegrandeporte.

Um grandemarconaevoluçãoemmodelosdedadosfoi a propostado modelorelacional [12],

queapresentava um modelomatemáticoparaa representaçãoe manipulaçãode dadostotalmente

independentedecaracterísticasdeimplementação.

O modelorelacionalofereceumavisãodo conjuntodedadoscomoumacoleçãode tabelasou

relações(no sentidomatemáticodapalavra), ondecadatabelaé um conjuntoderegistrosou tuplas,� -uplasordenadasdevaloresliteraispertencentesadomíniosatômicos.O modeloofereceapossibi-

lidadedeexpressarconsultasemanipulaçõessobreabasededadosusandolinguagensindependentes

desistemas,baseadasemálgebrarelacionaleemcálculorelacional[26].

A álgebra relacionalofereceoperaçõesbásicascomoseleçãodetuplasdentreaspertencentesa

umarelação( � ), a projeçãodecolunasda tabelagerandoumanova relaçãocomapenasascolunas

selecionadas(�

), o produtocartesianode duasrelaçõesgerandoumanova relaçãocom todasas

combinaçõespossíveisdetuplasentreasduasrelaçõesoriginais( � ), a uniãodeduasrelaçõescom

estruturascompatíveis ( � ) e a diferençade duasrelaçõescom estruturascompatíveis ( � ), ondeo

resultadoéumaterceirarelaçãoquecontémastuplasdaprimeirarelaçãoquenãoestãopresentesna

segundarelação.

As principaisoperaçõesderivadasdasoperaçõesbásicasnaálgebrarelacionalincluem:

� a interseçãodeconjuntos,quepodeserexpressaemtermosdediferenças,

��� ��� ��� � � ��

� a junçãocompredicados,quepodeserexpressaemtermosdeseleçãoeprodutocartesiano,

�������� � ��� �

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

� a junçãonatural,ondeo predicadode junçãoé a igualdadeentrevaloresde atributos com

domínioscompatíveisnasduasrelaçõesenvolvidas.

A álgebrarelacionalpermiteexpressarasoperaçõeselementaresquedevem serseguidas,em

ordem,paraa obtençãodo resultadodesejado.Nestesentido,é umalinguagemprocedimental,pois

suasexpressõesdefinemsequênciasdeoperações.No entanto,nãoé umalinguagemprocedimental

completa,poisnãoinclui asconstruçõesdecontroledeexecuçãousualmentepresentesemlinguagens

deprogramação.

O cálculo relacionalé baseadoemconstruçõesnão-procedimentais,usandodescriçõesformais

do queé desejadona manipulação.Duasvariantesbásicassãoo cálculo relacionalde tuplase o

cálculorelacionaldedomínios.É possível mostrarqueestastrêslinguagensrelacionais— aálgebra,

o cálculodetuplaseo cálculodedomínios— têmpoderequivalentedeexpressão[26].

As linguagensrelacionais,matemáticas,ofereceramosfundamentosparao desenvolvimetnode

diversaslinguagenscomputacionaisde consultae manipulaçãode basesde dados. A linguagem

SQL usaumacombinaçãode construçõesda álgebrae do cálculo relacionais.Outraslinguagens

deconsultaconhecidasincluemQuel (baseadano cálculorelacionalde tuplas)e QBE (baseadano

cálculorelacionaldedomínios).

As vantagensdo modelorelacionalpodemserresumidasemdoispontosprincipais.O primeiro

é seuforte suporteteóricoparadescriçãodarepresentaçãoe damanipulaçãodosdados.O segundo

é a facilidadeoferecidaparao mapeamentode tuplasparaosdispositivos dearmazenamento,com

umaassociaçãopraticamentediretapararegistrosdedimensãofixa emarquivos comacessodireto

emdisco.Estasvantagensmotivaramospesquisadoresdaépocaa investirnoestudodemecanismos

desuporteà implementaçãodesistemasgerenciadoresdebancodedadosrelacionais.

A décadade 1970foi assimmarcadapelo desenvolvimentode protótiposde sistemasrelacio-

nais. Osprincipaisprojetosdestafaseforamo SystemR, da IBM, e INGRES,daUniversidadeda

CalifórniaemBerkeley.

O SystemR [2, 6] foi um projeto-protótipodo laboratóriode pesquisada IBM em SanJose,

Califórnia, iniciadoem1974. Concluídoem1979,deuaindaorigemaoprodutoSQL/DataSystem

(1981)eaoprojetoR* paraestudodesistemasdebancosdedadosdistribuídos.Posteriormente,em

1983,aIBM lançoutambémo produtoDB2 paramanipulaçãodegrandesbasesdedadosrelacionais.

As principaiscontribuiçõesdesteprojetoforama definiçãodalinguagemdeconsultaSQL,a intro-

duçãodemecanismosparaa compilaçãoe otimizaçãodeconsultas,a introduçãodemecanismosde

integraçãoda linguagemdeconsultaa linguagensdeprogramação,e a introduçãodosconceitosde

locking emduasfasesecommúltiplasgranularidades.

INGRES [45,46] foi umsistemagerenciadordebancodedadosexperimentaldesenvolvido por

umgrupodepesquisadaUniversidadedeBerkeley. Posteriormente,umprodutodomesmonomede-

rivadodesteprojetofoi lançadopelaempresaRelationalTechnology, Inc., sendoatualmentecomer-

cializadopelaempresaIngresInc. O protótipoinicial do sistemafoi desenvolvido emum PDP-11,

comsistemaoperacionalUnix. INGRESfoi projetadocomoum sistemagerenciadorcomdiversos

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

processosconcorrentescom mecanismosde comunicaçãointer-processos.A linguagemQuel foi

introduzidaporesteprojeto,juntamentecomummecanismodeembeddingparaa linguagemdepro-

gramaçãoC. As técnicasdeotimizaçãodeconsultanãoeramrealizadaspor pré-compilação,como

emSystemR, masdurantea interpretaçãodasconsultas,atravésdeum processodedecomposição

deconsultas.Desteprojetoderivou-setambémo projetoPOSTGRES[41], sistemagerenciadorde

bancode dadosrelacionalcom característicasavançadasde controlede restriçõese apoioa novos

tiposdedados.

Estesprotótiposinfluenciaramo desenvolvimentodemuitosprodutos,e sistemasgerenciadores

debancodedadosrelacionaisatingiramgrandesucessocomercial.Entretanto,o desenvolvimentoda

tecnologiacomputacionalvemmotivandoa implementaçãodeaplicaçõescadavezmaiscomplexas,

cujasnecessidadesderepresentaçãodeinformaçãonemsempreeramadequadamenteatendidaspor

tais produtos. Assim, o modelorelacionalde dadosenfrentou(e continuaenfrentando)algumas

críticas,dasquaissedestacam:

1. éapenasadequadoparaaplicações“estruturalmentesimples”;

2. o poderdeexpressãodastabelasé limitado;

3. desenvolver umbomprojetorelacional,normalizado,nãoé tarefa simples.

É a partir desituaçõescomoessasquea buscapor novos mecanismosdeexpressãodedadosé

motivada. Nestecaso,havia umanecessidadedesebuscarmodelosdedadoscommaior poderde

expressãoqueo modelorelacionaldedados.As abordagensresultantespodemserresumidasemtrês

grandescategoriasdemodelos:osmodelosrelacionaisestendidos,osmodelosdedadosconceituais

eosmodelosorientadosaobjetos.

Osmodelosrelacionaisestendidosincorporammecanismosnãoprevistosnapropostaoriginal

do modelorelacional[13]. Osprincipaismecanismosdescritosemdiversaspropostasincluempro-

cedimentosarmazenados,versões,objetosbinários(BLOBs)edefiniçãodetiposabstratosdedados.

A nãoexistênciadeum modeloestendidounificadodificulta umaaceitaçãomaisampladessalinha

deevoluçãodemodelos.Sistemasrepresentativosdestatendênciaincluemop já citadoPOSTGRES,

daUniversidadedaCalifórniaemBerkeley, queevoluiu posteriormenteparaum produtocomercial

denominadoMontage[50], eStarburst[27], do IBM AlmadenResearchCenter.

Os modelosde dadosconceituaisoferecemconstruçõesno nível maispróximo do projetista

paraorganizaçãodo mundode interesse[5, 38]. O termo“conceitual” refere-seao fato de queas

construçõesoferecidaspor estesmodelosestãoem níveis de abstraçãomaispróximosdo universo

de interessedo usuáriodo quedos aspectosde implementaçãoda máquina. Váriaspropostasde

arquiteturasde bancosde dadosutilizam três níveis de abstraçãoparabancosde dados(Fig. 2),

emboraemgeralnãohajaumconsensosobreosnomesdecadanível. Aqui adotou-seanomenclatura

deParsaye[36]. De qualquermodo,osmodelosdedadosconceituaisestãopróximosdo nível mais

alto.

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

Físico

armazenamentodispositivos de

métodos de acessodefinições de dadosdicionários

tabelascamposregistros

relaçõesatributosConceitual

Lógico

entidades

Figura2: Arquiteturadebancodedados.

Nestaestruturaçãodebancodedadosemumaarquiteturadetrêsníveis,a informaçãodomundo

real é modeladapor usuáriosindependentementedasestruturascomputacionaisqueserãoutiliza-

dasno nível conceitual.Nestenível, construçõesparaa representaçãodosdadossão(por exemplo)

entidades,atributose relações.No nível conceitual,a informaçãoé estruturada,ondealgumascons-

truçõescomputacionaispodemjá ser consideradas.Construçõesparaa representaçãodos dados

seriamregistros,campose tabelas.O nível internoou físico correspondea representaçõesdo dado

ondesãoconsideradosdetalhesdearmazenamento,representaçãoedesempenho.Nestenível seriam

consideradasconstruçõescomputacionaiscomodicionários,definiçõesdedados,métodosdeacesso

edispositivosdearmazenamento.

Algumasdasprincipaispropostasno sentidodeoferecermodelosdedadosconceituaisincluem

o modeloentidade-relacionamento, queorganizaa informaçãoemtiposdeentidadese tiposdere-

lacionamentos;osmecanismosdeabstraçõesembancosdedados,agregaçãoe generalização;e os

modelossemânticose funcionais,queorganizama informaçãoatravésdeobjetose funções.

O modelo entidade-relacionamento[11] foi propostopor Chenem 1976 como um modelo

conceitual,nãoestandodiretamenterelacionadoa preocupaçõesrelativasà implementaçãodesuas

primitivas. Por estemotivo, juntamentecom a propostado modelohá descriçõespararealizaro

mapeamentodo modeloE-R paraosmodelosrelacionale rede,paraosquaishavia sistemasgeren-

ciadoresdebancodedadosdisponíveis.AlgumasdascaracterísticasdeinteressedomodeloE-Rsão

o encapsulamentodosdetalhesestruturaisemconstruçõesdealto nível (tiposdeentidadee tiposde

relacionamento)e mecanismosparamanutençãodeintegridadeeconsistênciadosdados.

Os conceitosde abstraçãoem bancosde dados, agregaçãoe generalização,foram propostos

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

por Smithe Smith [44] em1977comoferramentasdeprojetodebancodedados,juntamentecom

propostasde mecanismosparaseusuporteem sistemasgerenciadoresde bancode dados,princi-

palmenterelacionais.Estesconceitosbásicosreaparecememmuitosoutrosmodelossobdiferentes

formas.

Modelos semânticose modelosfuncionais [22,37] estãovoltadosprincipalmenteparaa in-

tegraçãoentresistemasde bancosde dadose sistemasde representaçãode conhecimento,sendo

fortementeinfluenciadospor técnicasdainteligênciaartificial. Assim,incorporammecanismospara

expressartiposcomplexos,relacionamentosentreobjetos(incluindohierarquiasnaformaIS-A) ede-

rivaçãodeesquemas.Tambémnãohouve umaabordagemdemodelagemsemânticauniversalmente

aceita,damesmaformacomoocorreucommodelosrelacionaisestendidos.

A abordagemdemodelagempor orientaçãoa objetos,apesardepróximoemprincípioaosmo-

delosdedadosconceituais,vemrecebendoatençãoe aceitaçãomuito maisampla.Porestemotivo,

essetópicoserátratadoemmaisdetalhesnapróximaseção.

3 Modelagemdedadosorientada a objetos

Ossistemascomerciaisdegerênciadebancodedados,baseadosprincipalmentenomodelorela-

cionaldedados,obtiveramamplaaceitaçãoe divulgação,emdiversosníveisdeescaladeaplicação.

Entretanto,tais sistemasmostraram-seinadequadosparaumaamplagamade aplicaçõesquesur-

giu com a ampliaçãodo poderde processamentodos computadoresmodernos.Essasaplicações

incluem,entreoutras,atividadesemprojetosdeengenharia(siatemasCASEparaengenhariadesoft-

ware, CAD paradesenvolvimentode hardware e apoioà engenhariamecânica,engenhariacivil e

arquitetura),autoriaemanipulaçãodedocumentoseletrônicos,manufaturaecontrole.

O paradigmadeorientaçãoaobjetossurgiu comoumaalternativaparaamodelagemdebancosde

dadosquepermitiriaincorporarmuitosdosconceitospropostospelasoutrasabordagensalternativas

aomodelorelacionaldedados.Emborainicialmentetenhatambémsofridopeloexcessodeaborda-

gensnão-compatíveis,suaamplaaceitaçãomotivou esforçosdepadronizaçãoquevêmunificandoo

chamado“modelodeobjetos”.

Destemodo,o desenvolvimentodesistemasgerenciadoresdebasesdeobjetos(SGBOs)surgiu

comoumaalternativacomo potencialadequadoparaatenderàdemandadetaisaplicações,sendopor

estemotivo objetodeintensointeressedepesquisae desenvolvimento.Antevia-sequetaissistemas

ofereceriamo ferramentalnecessárioparaasnovascategoriasdeaplicaçõesquenãoestavamsendo

adequadamentesuportadasporbasesdedadosrelacionais.

3.1 Princípios da orientaçãoa objetos

O conceitodeobjeto comoconstruçãodeprogramaçãofoi inicialmenteintroduzidona lingua-

gemSimula67,ondea execuçãodeum programaerarealizadaatravésdacomposiçãodaexecução

deváriosobjetosinter-relacionados. Objetoscomumamesmaestruturaconstituíamumaclasse, que

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

eradescritaporumadeclaraçãodeclasse.OsconceitosintroduzidosporSimulaestiverampormuito

tempolimitadosà utilizaçãoemaplicaçõesdesimulação.Apenasa partir dadécadade1980hou-

ve um maior esforçono sentidode valorizar tais conceitose incorporá-losa outraslinguagensde

programação.

Nygaard[31] defineprogramaçãoorientadaaobjetoscomo

. . . odesenvolvimentodeumsistemaemumprocessodeinformaçãoatravésdetrans-

formaçõesdeseuestado.A substânciadoprocessoéorganizadacomocomponentesdo

sistema,denominadosobjetos.Umapropriedademensurávelda substânciaé umapro-

priedadede um objeto. Transformaçõesde estadosãoconsideradascomoaçõespor

objetos.

Um aspectochaveemprogramaçãoorientadaaobjetoséo conceitodeabstração,quepermiteabstrair

(nestadefinição)substânciacomodeclaraçõesdeclasses;valorese propriedadesmensuráveiscomo

declaraçõesdetipos;eaçõescomodeclaraçõesdemétodosouprocedimentos.Um objetoencapsula

umaestruturaquesóémanipulável atravésdemétodoscomponentesdeumainterfacepública.

ComoStroustrupdestaca[47], programaçãoorientadaa objetosé umatécnica,um paradigma.

Umalinguagemdeprogramaçãoorientadaa objetosnadamaisé do queumalinguagemdeprogra-

maçãoquefavorecea aplicaçãodessatécnica.Entretanto,épossível realizarprogramaçãoorientada

a objetossemusarumalinguagemdeprogramaçãoorientadaa objetos,assimcomonãohágaran-

tia de queum programaseráorientadoa objetossimplesmenteporquefoi implementadoem uma

linguagemdeprogramaçãoorientadaaobjetos.

Além dosconceitosfundamentaisdeclasses,objetose métodos,doisconceitosinerentesà pro-

gramaçãoorientadaa objetossãoherançae polimorfismo. Herança é o mecanismoquepermite

reaproveitardeclaraçõesdeclasses,criandoclassesderivadasapartirdedeclaraçõesdeclassesbases

já existentes.Juntamentecom a técnicade padrõesde projeto(designpatterns), herançatorna-se

um mecanismodereusopoderoso.Polimorfismo é o mecanismoquepermiteexpressarqueações

similaresem classesdistintasvenhama ter um comportamentouniforme. Por exemplo,espera-se

queum métododenominadoprint em duasclassesdistintastenhaum comportamentocomum,

independentementedasdiferençasinternasdesuaimplementação.

EmboraSimulatenhaintroduzidoo conceitodeobjetosemprogramação,Smalltalkfoi a lingua-

gemresponsável porsuapopularização[29]. EmSmalltalk[19] todaa informaçãosobreo processo

deinteresseéorganizadaatravésdeobjetos,pormaissimplesoucomplexa quesejaaunidadedein-

formação.Programasmanipulamobjetos,sendoquea definiçãosobrea realizaçãodo objeto,assim

comodemétodosinvocados,ocorreapenasduranteo períododeexecução,atravésdomecanismode

ligaçãodinâmica(ou late binding). A execuçãodeum programaSmalltalkocorrepor interpretação,

podendohaver umaconversãodeum programafonteparaum programaemformatointermediário

deinterpretação,bytecodes.

Atualmente,aslinguagensde programaçãoorientadasa objetosde maior utilizaçãosãoC++ e

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

Java. C++ [48], ao contráriode Smalltalk,é umalinguagemfortementetipada,ondea maior par-

te dasverificaçõesde operaçõessobreobjetossãorealizadasem tempode compilação,atravésdo

mecanismode early binding. Informaçãoem C++ podeestarrepresentadasoba forma de objetos,

representantesde entidadesabstratasou do mundoreal, ou soba forma de literais, representando

valoressimplescomointeiros,númerosreais,caracterese strings. ComoC++ nãoé umalinguagem

interpretada,suaexecuçãoé rápidae eficiente,fazendocomqueC++ sejaa linguagempreferencial

ondeo desempenhodasaplicaçõeséumaspectoimportante.Críticasà linguagemreferem-seprinci-

palmenteà suacomplexidadee à dificuldadedeserealizaro transportedeaplicaçõesemC++ entre

diferentesplataformascomputacionais.Além disto,C++ éumalinguagemque,devido àsuaproximi-

dadeecompatibilidadecoma linguagemC, favorecea implementaçãodeprogramasnão-orientados

aobjetos.

Java [20] éumalinguagemdeprogramaçãodefinidapelaSunMicrosystemscomouma“simpli-

ficação”deC++, como objetivo inicial dedesenvolver aplicaçõesdesoftwareparasistemasembarca-

dos.Tendoesteobjetivo, a linguagemdeveriasersimples,eficienteeoferecerumaltograudeporta-

bilidadeentreaspossivelmenteváriasplataformasdeexecuçãodistintas.Inicialmente,considerou-se

a utilizaçãodeC++ paraatingir esteobjetivo, masconstatou-sequeessalinguagem— assimcomo

muitasoutrasanalisadas— nãoeraadequadaparatal fim. Assim,definiu-seumanova linguagem

deprogramaçãotomandoC++ comobasemasondeosseusmecanismoscomplexos,causadoresda

maiorpartedoserrosdeprogramação,forameliminados.Assim,Java nãoutiliza ponteiros,templa-

tesouherançamúltipla. Paraalcançarportabilidade,empregou-seo conceitodecompilarprogramas

Javaparabytecodesquesãointerpretadosporumamáquinavirtual [21]. A portabilidadeéalcançada

apartir domomentoemquemáquinasvirtuaisJava estejamdisponíveisemdiversasplataformas.

3.2 Incorporaçãodeorientaçãoa objetosa sistemasdebancodedados

A definiçãodeNygaardparaprogramaçãoorientadaaobjetossugereseresteumparadigmaade-

quadoàmanipulaçãodesistemasdeinformação.Defato,algunsdestesconceitosestavampresentes

empropostasdemodelosdedados,comoo agrupamentodeentidades(objetos)emtiposdeentida-

des(classes)no modeloEntidade-RelacionamentodeChen. Assim,pareciasero caminhonatural

de evoluçãoa fusãode orientaçãoa objetose sistemasde bancode dados. Entretanto,apesarda

proximidadeemseusobjetivosfinais,asduasabordagensdesoluções— delinguagensedemodelos

— estavambemdistantesnaquelemomento,emmeadosdadécadade1980.

De um lado,sistemasdebancodedadosatendiamàsnecessidadesdasaplicaçõesquemanipu-

lavam dadosnosmaisdiversostipos de sistemasde processamentode informação.Estessistemas

ofereciamo armazenamentopersistentedosdados,ouseja,osdadosregistradosnosistematinham

um períodode vida queseestendiaalémdo períodode vida dosprocessosqueos manipulavam.

Em um programaorientadoa objetos,variáveis tipicamenteseextingüemcomo final daexecução

do programa.Sistemasdebancodedadostambémerameficientesemofereceraramzenamentoefi-

cienteparagrandesvolumesderegistros,muitomaioresqueacapacidadedememóriaprincipaldos

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

computadores.

Outroaspectobematendidoporsistemasdebancodedadosreferia-seaooferecimentodemeca-

nismosdealtonível paraa interaçãocomusuários,taiscomoadefiniçãode linguagensdeconsulta

declarativasemecanismosparaageraçãode formulários deinteração.

A operaçãodebasesdedadosemambientesdistribuídosjá apresentava soluçõessoba formade

sistemasde banco de dadosdistribuídos. Mesmoquea soluçãonãofossea ideal, umavez que

osproblemasdeambientescombasesdedadosheterogênease ambientesmultidatabasesaindasão

objetosde estudo[23], eramuito maisdo queoferecidopor qualquerlinguagemde programação.

Outroaspectomelhoratendidopor sistemasdebancodedadoseraa questãodo suportea múltiplos

usuáriosemacessoconcorrenteàsbasesdedados.

Sistemasde bancode dadostambémofereciammecanismosinteressantesde manutençãode

consistênciadosdados,comoosmecanismosdecontrolede transaçõesatômicas; de recuperação

dedadosem casosde falhas;e sistemasde regras(triggers) paraa avaliaçãodecondiçõesdurante

a manipulaçãode dadosquepermitiam“disparar” procedimentosde verificaçãoe manutençãoda

consistência.

Acima de tudo, a utilizaçãode sistemasde bancode dadospermitiaqueaplicaçõesalcanças-

sema independênciadedados, ou seja,erapossível implementaraplicaçõessemquefossepreciso

conhecera estruturainternade comoosseusdadosestavam registrados.Duasconseqüênciasdes-

ta propriedadeeramfundamentaisparaa implementaçãodeaplicaçõesemsistemasdeinformação.

Emprimeirolugar, mudançasnaestruturainternadearmazenamentonãoafetavamaimplementação

daaplicação.Em segundolugar, erapossível compartilharosdadosentrediversasaplicações,per-

mitindo a manutençãosimplificadade um único repositóriode dadosparaas aplicaçõesde uma

corporação.

Apesardadistânciaentrelinguagensdeprogramaçãoorientadasaobjetosesistemasdebancode

dados,asvantagensantevistasparaa integraçãoentreasduasabordagenseraevidente.A perspectiva

de seter um modelode objetos,ondeentidadesdo mundoreal pudessemserrepresentadasunivo-

camenteno esquemadabasededadospor umaconstruçãocom alto nível deabstração(o objeto),

pareciaserasoluçãoidealparao problemadogapsemânticoentremodelagenseo mundoreal.

Destaforma,houveumgrandeinvestimentodapartedospesquisadoresdaáreadebancodedados

em se desenvolver modelosintegrandoos conceitosde orientaçãoa objetoscom funcionalidades

de bancosde dados. As motivações,assimcomo as necessidades,parase obter mecanismosde

modelagemdeobjetoserammuitas,comodescritoa seguir [10].

Identificadores de objetos. Em aplicaçõesde engenharia,de projeto e em algumasaplicações

comerciais,a identificaçãode entidadespor valoresde atributos podeserartificial e sujeitaa in-

consistências.Por estemotivo, ter umaidentificaçãoúnica,independentedevaloresdeatributose

gerenciadapelosistema,é importanteparataisaplicações.

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

Objetoscompostos. Sistemasdebancodedadosrelacionaisnãolidavamdemodoadequadocom

o conceitode objetosformadospela agregaçãode outrosobjetos. A importânciadesteconceito

já havia sido enfatizadapelo trabalhode Smith e Smith sobreabstraçãode dados,sendoessencial

em sistemasde bancode dadosde apoio a projetosde engenharia.Nestasaplicações,é usuala

necessidadedeseoferecermecanismosparadefinir objetosquecontêmoutrosobjetos,assimcomo

deofereceroperaçõesdeacessoasubcomponentesnashierarquiasquedefinemtaisobjetos.

Referênciase integridade. Composiçãopor agregaçãoé apenasum casoespecialdeumaneces-

sidademaior, queé o estabelecimentodeassociaçõesentreobjetos.É fundamentala capacidadede

seexpressarrelacionamentosgenéricosentreobjetos,com mecanismosadequadosparaseutilizar

estainformação.Adicionalmente,é precisoqueo sistemasejacapazdemantera integridadedessas

referências.

Hierarquiasdetipos. O mecanismodeherançapresenteemlinguagensdeprogramaçãoorientadas

aobjetosdeveseroferecidocomoummecanismodedefiniçãodeesquemasdedadoseobjetos,sendo

importanteparaamaiorpartedasaplicações.

Procedimentosassociados. É interessantequea basedeobjetospossaregistrartantoa estrutura

quantoo comportamentodosobjetosdaaplicação,ondeo comportamentoé expressopelosproce-

dimentos(métodos)quemanipulamo conteúdodosobjetos.Em sistemastradicionais,o comporta-

mentoé relevadoàaplicação.

Encapsulaçãode objetos. Isolara estruturainternadeobjetosdaaplicaçãoé um mecanismoim-

portanteparaobter reuso,inter-operabilidade e modularizaçãodasaplicações.A basede objetos

deve oferecersubsídiosparaqueestemecanismodaslinguagensdeprogramaçãoorientadasa obje-

tosreflita-senosistemagerenciadordabasedeobjetos.

Coleçõesordenadas. Sistemasrelacionaisoperamexclusivamentecom o conceitode conjuntos

(coleçõesnãoordenadas),mashádiversasaplicaçõesondeaordemdoselementosdeumacoleçãoé

importante.Um sistemagerenciadordabasedeobjetosdeve oferecermecanismosadicionaisparaa

representaçãodecoleçõesmaisgenéricasquesimplesmenteconjuntos.

Grandes blocosde dados. Alguns atributosde objetospodemocuparespaçosde armazenagem

muito maior que o espaçousualmenteocupadopela representaçãode valoresliterais. Exemplos

sãoregistrosde textos, imagense sons. O mecanismode BLOBs presentesam algunssistemas

relacionaisestendidos,apesarde permitir o armazenamentodestesvolumesde dados,nãooferece

mecanismosparaa interpretaçãodestesdados,delegandotal tarefa exclusivamenteà aplicação.

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

Acessoremoto. Em ambientesde projeto,a operaçãode computadoresem redesé a regra geral

e nãoa exceção.É importantequeum sistemagerenciadordabasedeobjetosofereçamecanismos

eficientesparaacessoremotoaosobjetos,commecanismosdecheckout, locking por períodosque

podemserextensosecheckin deobjetos.

Evoluçãode esquema. Aplicaçõesdeprojeto,maisqueoutras,necessitamfacilidadesparaintro-

duzir modificaçõesno esquemadeobjetosao longodesuaexecução,poisnessetipo deaplicaçãoa

definiçãodoesquemaépartedaatividadedeprojeto.Assim,éimportanteterumsistemagerenciador

dabasedeobjetosnoqualmodificaçõesdeesquemapossamocorrersemmaioresimpactossobreos

dadosjá armazenados.

Interfaces de programação. Em sistemasgerenciadoresdebancodedadostradicionais,a mani-

pulaçãodosdadosocorreatravésdeumalinguagemdeconsulta,nãoprocedimental,semanticamente

distantedalinguagemdeprogramaçãodaaplicação.Nasaplicaçõesutilizandoumsistemagerencia-

dor da basede objetos,ao contrário,é interessantequehajaumamaior integraçãoentrea basede

objetosea linguagemdeprogramaçãoorientadaa objetosusadapelaaplicação,umavezqueambas

adotamo mesmoparadigma.

Múltiplas versões. Em aplicaçõesdeprojetoo conceitodeversõesdosobjetosé essencial,tanto

paraa manutençãoda evoluçãohistóricado projetocomoparaexpressaralternativasconcorrentes

paraos objetosde projeto. É importantequeum sistemagerenciadorda basede objetospermita

expressaressamultiplicidadederepresentaçõesparaummesmoobjeto.

Emboratais motivaçõestenhamsido expostasprincipalmentea partir dasnecessidadesde um

sistemagerenciadordabasedeobjetosparaaplicaçõesdeprojetoemengenharia,claramentediver-

sosdessesmecanismossãointeressantesparaoutrascategoriasdeaplicação.A importânciaemse

obterumacombinaçãodestesnovos mecanismoscom os mecanismostradicionalmenteoferecidos

porsistemasgerenciadoresdebancodedadosfoi logoobservada,motivandodiversaslinhasdepes-

quisacomo objetivo deanalisare proporcomotal integraçãopoderiaocorrer. Afinal, um sistema

gerenciadorda basede objetosincorporandotais mecanismosconstituiuma ferramentapoderosa

paraaplicaçõesfuturaseparaaevoluçãodeaplicaçõestradicionais.

3.3 Protótipospioneiros

Nestaseçãoserãoapresentadosalgunsdosesforçospioneirosno desenvolvimentode sistemas

gerenciadoresqueincorporassem,dealgummodo,o conceitodeorientaçãoa objetos.Algunsdos

primeirosdesenvolvimentosemsistemasgerenciadoresdabasedeobjetosincluemossistemasIris,

ORIONeGemStone[25].

Iris [17] foi umprotótipodesenvolvido naHewlett-Packardparaexplorarasnovasfuncionalida-

desdeumsistemagerenciadordabasedeobjetos.A abordagemadotadaemIris podeserclassificada

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

comoumaextensãodesistemasfuncionaisparaorientaçãoa objetos.Entreosobjetivosdo projeto

buscava-seincorporarnovosmecanismosdemodelagemedeconstruçãodetiposdedados,suportea

inferênciasnobancodedados,suportea transaçõeslongaseamúltiplasversõesdasbasesdedados.

Aplicaçõespoderiaminteragircom o sistemagerenciadorda basede objetosatravésde várias

linguagens,queteriamsuasconstruçõesmapeadasparaasconstruçõesinternasdo gerenciadorde

objetos. A arquiteturabásicado sistemaé apresentadana Fig. 3. Parao módulogerenciadorde

armazenamento,umsistemagerenciadordebancodedadosrelacionaldaprópriaHPfoi utilizado.O

sistemafoi implementadoemC emestaçõesdetrabalhoUnix (HP-9000).

ObjectSQL

EditorGráfico

dados estruturados

dados nãoestruturados

tipos, objetos, funções,

consultas, atualizações,otimização, versões

Objetos C Objetos Lisp

C-Iris Lisp-Iris

Gerenciadorde objetos

Gerenciador dearmazenamento

concorrência, recuperação,indexação, buffering,clustering

Figura3: ArquiteturadosistemaIris.

Do pontodevistadaaplicação,trêsabordagensdeinterfaceforampropostasparaestesistema.

A primeiraabordagemrefletiaa interfaceusualparasistemasgerenciadoresde bancode dadosde

então— atravésdecomandosdeumalinguagem,OSQL,embutidosemalgumalinguagemdepro-

gramação.A segundaabordagemapresentava o sistemagerenciadorda basede objetoscomoum

objetoparaaaplicação,queinteragiriacomo sistemaatravésdemétodosaplicadosaoobjeto.Final-

mente,a terceiraabordagemprocurava exploraro conceitodepersistênciadeobjetos,ondeobjetos

daaplicaçãoseriammanipuladospelosistemagerenciadordabasedeobjetosdeformatransparente

parao programador. Um editorgráfico,implementadoemLisp, ofereciafacilidadesparaa criaçãoe

manipulaçãodeesquemasdeobjetos.

AlgumascaracterísticasparticularesdeIris incluíamapossibilidadedeexaminaresquemascomo

quaisqueroutrosdados,a possibilidadedeassociarum objetoa maisdeum tipo, e um mecanismo

simplesdecontroledeversõespor checkout e checkin. Iris deuorigemposteriormentea umproduto

daHP, OpenODB.

ORION [24] foi resultadode um projetodesenvolvido no ProgramaAdvancedComputerAr-

chitecture da MCC (Microelectronics and ComputerCorporation), empresade Austin, Texas. O

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

objetivo do projetoerainicialmentesuportarasnecessidadesdemanipulaçãode dadosdeProteus,

umaplataformaparasistemasespecialistas.

ForamimplementadasemORIONfunçõestaiscomocontroledeversõesenotificaçãodemodifi-

cações,objetoscompostoseBLOBs,herançamúltipla,evoluçãodinâmicadeesquemas,gerênciade

transações,consultase armazenamentodedadosmultimídia. Versõesdeobjetose referênciaseram

suportadasatravésdetimestamps.

A arquiteturado sistemaé apresentadana Fig. 4. O sistema,inicialmentemono-usuário,foi

implementadoemCommonLisp paraSymbolics(máquinaLisp) e estaçõesdetrabalhoUnix. Pos-

teriormenteo sistemaapresentouumasegundaversãocommúltiplosclientese umaterceiraversão

commúltiplosservidores.

subsistema dearmazenamento

subsistemade objetos

subsistemade transações

de mensagensmanipulador

Figura4: ArquiteturadoSistemaORION.

A interaçãodaaplicaçãocomORION foi definidaatravésdemensagens,quepoderiamsermé-

todosdefinidosporusuários,paraadefiniçãoearmazenamentodedados;mensagensdeacesso,para

a recuperaçãoe atualizaçãodevaloresdeatributosdeumaclasse;e funçõesdefinidaspelosistema,

pararealizartarefastaiscomodefiniçãodeesquemas,gerênciadetransações,criaçãoe remoçãode

instâncias.

As principaisênfasesno projetoORION foram na implementaçãode basesdistribuídase em

evoluçõesde esquema[4]. Duasformasde evoluçãode esquemaeramsuportadas:mudançasna

definiçãodeclasses(atributosemétodos)emudançasnaestruturadeclasses(classeseassociações).

O sistemaORIONdeuposteriormenteorigemaum sistemadebancodedadoscomercial,Itasca

[3]. Itascaapresentaumaarquiteturademúltiplosclientesemúltiplosservidores,adotandoformatos

neutrospararepresentaçãointernadedados.Assim,dadosdo sistemapodessercompartilhadospor

aplicaçõescominterfacedeprogramaçãoC++, C, CLOS,Lisp eAda.

GemStone[7, 8, 14] foi um produtoda Servio Logic Corporationque estendeua linguagem

Smalltalkparaincorporarmanipulaçãode basesde dados.A linguagemresultante,OPAL, imple-

mentava um modelodedadosbaseadoemteoriadeconjuntos,STDM (SetTheoretic Data Model).

Entreoutrascaracterísticas,GemStoneincorporava o conceitodehistóriadeobjetos.

UmavisãosimplificadadaarquiteturadosistemaGemStoneéapresentadanaFig. 5. Gemofere-

cia compilaçãodeprogramasemOPAL, verificava autorizaçãodeusuários,e ofereciaum conjunto

pré-definidode classese métodosem OPAL parausoda aplicação.Casoatuasseno servidor, era

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

Gem

Stone

sessão sessão

interpretador,compilador

concorrência,armazenamento,transações, autorização,replicação, recuperação

Figura5: ArquiteturadoSistemaGemStone.

tambémo móduloencarregadopor controlarconexõescom assessõesclientes,recebendobyteco-

desparaum submódulointerpretador. Opcionalmente,estemódulopoderiaseralocadoà máquina

cliente.

Stoneerao gerenciadordedados,móduloondeasfuncionalidadesdesistemasdebancodedados,

taiscomoentradaesaídadedisco,controledeconcorrência,serviçosdetransaçãoederecuperação,

eramefetivamenteimplementadas.

O protótipoinicial de GemStone,suportandoa linguagemOPAL, foi implementadoem hard-

ware específico.Posteriormente,o sistematambémfoi oferecidocompossibilidadedeintegraçãoa

aplicaçõesemC++. Assim,GemStonefoi o primeirosistemaa oferecerintegraçãoatravésdemais

deumalinguagem.

4 Manipulação e implementaçãodegerenciadoresdebasesdeobjetos

Nestaseçãosãodescritosos aspectosdo gerenciamentodedadosquesãoespecíficosparasis-

temasgerenciadoresdebasedeobjetos[10]. Inicialmenteé apresentadaumavisãoconceitualdos

mecanismosde manipulaçãode objetos,seguidapor umaapresentaçãodosprincipaisaspectosde

implementação.

4.1 Objetoseatributos

Naorientaçãoaobjetos,objetostêmumaidentificaçãoúnicaquenãodependedevaloresdeseus

atributos. Estaidentificaçãode objeto(OID) é utilizadaparareferênciasa objetos,tanto internas

como(possivelmente)externas.Destemodo,limitaçõesrelacionadasao processamentode chaves

(primárias,“estrangeiras”)em sistemasde bancode dadosrelacionaisnão estariampresentesem

sistemasdebancodedadosorientadosaobjetos.

Não obstante,o conceitode um atributo chave estápresenteem muitasaplicações.Destemo-

do,apesardenãoserum conceitodaorientaçãoa objetos,váriossistemasgerenciadoresdebasede

objetosoferecemadefiniçãodeatributoschavescomoummecanismodeacessoadicionalaoidenti-

ficadordeobjeto,maispróximodacompreensãodosusuáriose oferecendoasmesmasrestriçõesde

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

integridadepresentesemsistemasgerenciadoresdebancodedadosrelacionais.

Atributosdeobjetosestãopresentesemqualquersistemagerenciadordebancodedados,sendo

queem sistemastradicionaisusualmentetais atributosestãorestritosa valoresliterais e atômicos.

Uma diferençaem sistemasgerenciadoresde basede objetosestána maior flexibilidadeoferecida

paraadefiniçãodestesatributos,quepodemsimplesoucomplexos.

Atributossimplessãoaquelescujosvaloressãoliterais.Emmuitasaplicações,valoresmultimídia

sãoconsideradosatributossimples,ondeo BLOB referenteaoobjetomultimídiaé consideradoum

valor literal, atômicoe não-estruturado.Um sistemagerenciadorde bancode dadosmultimídia

é essencialmenteum sistemagerenciadorde basede objetosondeos dadosmultimídia recebem

tratamentodiferenciado,nãosendoconsideradossimplesBLOBs literais.

Atributos complexos podemser de três tipos: referências,coleçõesou virtuais. Referências

ou associaçõesestabelecemrelacionamentosentreobjetos,tendocomovaloresidentificadoresde

objetos.Um aspectofundamentalemsistemasgerenciadoresdebasedeobjetosé a manutençãoda

consistênciaentrereferênciasaobjetos.

Atributoscomplexos do tipo coleçãosãoutilizadosparadefinir conjuntos,listasou arranjosde

valores. Coleçõessãoexemplosde tipos parametrizadospresentesem sistemasgerenciadoresde

basedeobjetos;ostrêstiposcitadossãoasconstruçõesparametrizáveis fundamentais,porémoutras

podemestarpresentesemdistintasimplementações.

Atributosvirtuaisou derivadossãoaquelescujosvaloresnãoestãoexplicitamentearmazenados

nabasededados,masao invéssãocomputadosatravésdeprocedimentos.Em geral,taisatributos

sãodefinidoscomoread-only, sendoraroo oferecimentodemecanismosparaatualizarseusvalores.

4.2 Aspectoscomportamentais

Um sistemagerenciadordebasedeobjetosprecisaoferecermaisquesimplesmentenovos me-

canismosde estruturaçãode dados. Além da orientaçãoa objetosestrutural,é precisosuportara

orientaçãoa objetoscomportamental[1], quepodeserobtidaatravésdadefiniçãodemétodos,pro-

cedimentosquepermitemencapsulara semânticade um objeto. Em geral,atributosde um objeto

sãopropriedadeprivadae exclusiva do objeto,sendoqueapenasatravésdosmétodospúblicosa in-

formaçãoassociadaaoobjetopodesermanipulada.Estemecanismodeencapsulaçãoéfundamental

paraatingir independênciadedadosemsistemasgerenciadoresdebasedeobjetos.

A definiçãoestritadeencapsulaçãoexigeasatisfaçãodetrêscritérios:

1. Apenasmétodospodemserpúblicos;

2. Métodossãodefinidosemumalinguagemprocedimental;

3. Métodospodemmanipularapenasdadosdopróprioobjeto.

Estadefiniçãoé satisfeitaemSmalltalk. Há no entantodiversasoutraslinguagensdeprogramação

orientadasa objetose sistemasgerenciadoresde basede objetosquerelaxamumaou maisdestas

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

restriçõesparaoferecerum melhordesempenhodeexecuçãoàscustasdeseaceitarum graumenor

deencapsulação.

A representaçãodecomportamentoemsistemasgerenciadoresdebasedeobjetospermitedefi-

nir dadosativos,queincluemosatributosderivados,regrase agentes.Atributosderivadosjá foram

apresentadosanteriormente.Regrasou triggerssãodefinidoscomoparespadrão-ação,ondeasações

sãoativadasquandomodificaçõesàbasededadostornamverdadeiroo predicadoexpressonopadrão

da regra. Restriçõesde integridadesãocasosparticularesde regrasondeasaçõesestãolimitadas

a sinalizaçõesdecondiçõesdeerro. Agentessãocaracterizadospor processosassociadosaosiste-

magerenciadordebasedeobjetos,porémindependentes,podendorealizaraçõesqueextrapolamo

ambientedabasededados— porexemplo,enviar umamensagemporcorreioeletrônico.

4.3 Tipose herança

Objetoscomestruturasimilar sãoagrupadosem classes,sendoqueo tipo do objetoé definido

atravésde umadeclaraçãode classe.Usualmente,tipos sãocriadosatravésde umalinguagemde

definiçãodedadosou, maisespecificamenteemsistemasgerenciadoresdebasedeobjetos,através

de umalinguagemde definiçãode objetos. Uma diferençaentreuma linguagemde definiçãode

dadoseumalinguagemdedefiniçãodeobjetoséqueestaúltimapodepermitir, comojá observado,a

definiçãodeprocedimentosassociadosà estrutura,comono casodeatributosvirtuais,incorporando

assimaspectosdelinguagemdemanipulaçãodedados.

Um conceitoavançadoquepodeestarpresenteum umalinguagemdedefiniçãodeobjetosé o

conceitodeherança,quepermitedefinirnovostiposdeobjetosapartirdetiposjá existentes.Herança

é um mecanismodeimplementaçãodo conceitodegeneralização,importanteparabancosdedados

comoressaltadono trabalhodeSmithe Smithsobreabstraçãodedados.Osnovossubtipospodem

serdiferenciadosdostiposdosquaisforamderivadospormecanismostaiscomoespecialização,com

o acréscimode novos atributos,ou sobrecarga (overloading), ondeoferece-seumaimplementação

diferenciadaparaum métodojá existenteno tipo ancestral.Destemodo,o esquemade tipos de

objetosdefineumaárvoreouhierarquiadetiposrelacionados.

Herançamúltiplarefere-seaomecanismodeherançaatravésdoqualumnovo tipo deobjetopode

serderivadoa partir demaisdeum tipo ancestral.Entretanto,a semânticadeherançamúltipla nem

sempreéclara.Ademais,a implementaçãodeherançamúltipla requercuidadosadicionaisparalidar

comsituaçõescomoo conflito deresoluçãoparaatributosou métodos.Quandoherançamúltipla é

suportada,o esquemadetiposdeobjetospassaaserorganizadocomoumamalhaougrafodetipos.

Emumsistemagerenciadordebasedeobjetos,amodificaçãodeumtipo implicanamodificação

do esquemadedados.Em um sistemagerenciadordebancodedadostradicional,modificaçõesno

esquemaeramaçõesqueafetavamextremamenteasaplicações,muitasvezesnecessitandodeproces-

samentooff-line paraconverterosdadosdeumesquemaparao outro.Emumsistemagerenciadorde

basedeobjetos,estaevoluçãodeesquemasdeve ocorrerdeformamaisnatural.Sãotrêsascatego-

riasdemodificaçõesqueimplicamemevoluçãodo esquema:mudançasemcomponentes(atributos

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

ou métodos)deum tipo, mudançasnahierarquia(ou malha)detipos,ou mudançasnadefiniçãode

tipos,atravésdemodificaçãodenome,inclusãoou remoçãodetipos.

4.4 Consultas

Um dosprincipaisaspectosa seconsiderarna manipulaçãode basesde dadosé o mecanismo

oferecidoparaexpressaroperaçõessobreosdados.Em geral,aplicaçõesusandobasesdedadossão

desenvolvidasemalgumalinguagemdeprogramaçãoe integramexpressõesdemanipulaçãodeda-

dosaosprogramas.A diferençaentreestaslinguagensdeprogramaçãoedemanipulaçãodedadosdá

origemaoproblemade“descasamentodeimpedâncias”(impedancemismatch) entreaslinguagens,

queéendereçadodemaneirasdistintasemdiversossistemasgerenciadoresdebasedeobjetos.Entre-

tanto,nenhumadestasabordagens,descritasa seguir, consegueeliminarcompletamenteo problema

dodescasamentodeimpedânciasentreasaplicações.

Umaestratégiadeintegraçãodelinguagenséo querydownload, ondetodososobjetosrelevantes

paraa operaçãoda aplicaçãosãorecuperadosda basede dados,traduzidosparaa representação

adequadaparaa linguagemde programação,manipulados,re-traduzidose armazenadosde volta à

basede dados. Uma variantedesteesquemalimita a operaçãoa um único objeto por interação,

com o objetivo de maximizara concorrênciade acessoà basede dados.Outraalternativa aindaé

armazenarobjetosdalinguagemdeprogramaçãocomoBLOBsnabasededados,quenestasituação

nãoconterianenhumainformaçãosobreaestruturadoobjeto.

Em outradireçãodeintegração,algunssistemasestendemlinguagensdemanipulaçãodedados

comconstruçõesprocedimentais.SybaseadotouestaabordagemaoestenderSQL comconstruções

decontroledeexecuçãoparasistemasrelacionais.Outrossistemasoferecemnovos tiposdedados

nalinguagemdeprogramaçãopararefletir tiposeoperaçõesreferentesàbasededados.

Umaabordagemmaistransparentede integraçãoentrelinguagensdeprogramaçãoorientadasa

objetose sistemasgerenciadoresde basedeobjetosé a incorporaçãodemecanismosdepersistên-

cia de objetosà linguagemde programação.Nestasituação,a basede dadosé utilizadade forma

implícitae transparentecomomeiodemanutençãodoestadodeobjetosdaaplicaçãoentresessões.

Métodosdeespecificaçãodepersistênciaemsistemasgerenciadoresdebasedeobjetospodemser

portipo,porinvocaçãoexplícitaouporreferência.Naespecificaçãoportipo,apenasalgunstipospré-

definidossãopersistentes.Umacríticaa estemodeloé quepersistênciae especificaçãodetipossão

conceitosortogonais,e queassociarpersistênciaa apenasalgunstiposfereessaortogonalidade.Na

especificaçãodepersistênciapor invocaçãoexplícita, a aplicaçãosolicitaexplicitamenteaosistema

gerenciadordebasedeobjetoso armazenamentopersistentedoobjetoemquestão.Naespecificação

porreferência,umoumaisobjetos(asraízes)sãodeclaradoscomopersistentes,etodososobjetospor

elesreferenciadostornam-seautomaticamentepersistentes.Esteé o mecanismomaistransparente,

masqueexigemaisemtermosdeprocessamentodapartedosistemagerenciadordebasedeobjetos.

Outro aspectoimportanterelativo a consultasem sistemasgerenciadoresde basede objetos

refere-seaotipo deresultadoqueumaconsultagera.Em sistemasrelacionais,existeum únicotipo

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

(a relação);portanto,operandose resultadosdeconsultassãorelações.Em sistemasgerenciadores

de basede objetos,o graude liberdadeé maior. Alguns sistemaspodemlimitar a respostaobtida

a algunstiposespecíficos,emboraa tendênciasejapermitir a manipulaçãoderesultadosabertos—

literal, objeto,coleçõesdeobjetosouatémesmorelações(arranjostabularesdedados).

Consultasenvolvendomúltiplosobjetosnecessitamdealgumaformademecanismode junção.

Duasvariantesda operaçãode junçãoem sistemasgerenciadoresde basede objetossãoa junção

por referênciae a junçãopor valor. A junçãopor referênciautiliza associaçõesdefinidasnabasede

objetosparaobterobjetosassociados.A junçãopor valor, assimcomoa junçãodesistemasrelacio-

nais,é realizadasobrevaloresdeatributosquecompartilhamum domíniocomum,nãonecessitando

portantodeassociaçõesexplícitasparasuarealização.

4.5 Concorrênciae recuperação

Como dadosem uma basede dadossãopersistentese usualmentecompartilhadospor várias

aplicaçõese/ouusuários,é precisoquehajamecanismosparacontrolede acessoconcorrente,de

recuperaçãodedadosemcasodeoperaçõesfalhase demanutençãode integridadedosdados.Em

um sistemagerenciadordebasedeobjetos,diferentementedo queocorreemsistemastradicionais,

umaaplicaçãomanipulade forma naturaldadostransientese dadospersistentes,o quepodecriar

dificuldadesadicionaisnamanutençãodeconsistênciadosdados.

Operaçõessobreobjetospersistentessãousualmentedefinidasno escopode transações,assim

comoocorreem sistemasgerenciadoresde bancode dadostradicionais. Uma possível diferença

é quesistemasgerenciadoresde basede objetospodem(e geralmenteo fazem)incluir transações

longase,emalgunscasos,transaçõesaninhadas.

Versõesoferecemum mecanismoalternativo paracontrolede concorrência.Atravésdo meca-

nismodeversõeslibera-seo sistemademanterumaúnicacópiadeum objetonabase,o quealivia

umaeventualdegradaçãoquepoderiaocorrercomaincorporaçãodetransações(econsequentemente

locks) longas.Comversões,evoluçõesalternativasnosestadosdosobjetossãopermitidas.Um con-

ceitorelacionadoa esteé configuração,um conjuntodeversõesdeobjetosmutuamenteconsistente.

Configuraçõesequivalemasnapshots(ouvisõesinstantâneas)consistentesdabasedeobjetos.

4.6 Implementaçãode identificadores

Um dosfatoresmaisimportantesnodesempenhodeumsistemagerenciadordebasedeobjetosé

a formadeimplementaçãodarepresentaçãodeseusobjetos— comosãoarmazenados,identificados

e recuperadosdabasededados.

A representaçãode identificadoresdeobjetospodeserfísica ou lógica. A representaçãofísica

contémo endereçorealdo objeto,comoocorreemlinguagensdeprogramaçãoorientadasa objetos

ondeobjetossãoidentificadospor suaposiçãonamemória.A representaçãológicaenvolve algum

mecanismodemapeamentoentreumarepresentaçãointernaeo endereçodoobjeto.

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

As quatroabordagensbásicasdeimplementaçãodeidentificadoressãoutilizaçãosimplesdoen-

dereço,um identificadorfísico; utilizaçãodeendereçosestruturados,quecontémumacomponente

lógicae outrafísica;utilizaçãodesurrogates, identificadoreslógicosquesãomapeadosparaende-

reçosfísicosatravésde um índiceou de umatabela;e a utilizaçãode surrogatestipados,ondea

informaçãosobreo tipo doobjetoé incluídano identificadorlógico.

A unicidadedeumidentificadordeobjetoé umaspectofundamentalparaamanutençãodacon-

sistênciade umabasede objetos. Identificadoresde objetossãoutilizadostantopelasaplicações

comopelaprópriabasede objetos,pararepresentarassociaçõesentreobjetos. O mecanismopa-

ra garantirunicidadepodevariar entreimplementaçõesdistintas. Alguns sistemasgarantemque

identificadoresdeobjetosremovidosnãosãoreaproveitados;outrosbuscamgarantirunicidadeentre

múltiplasbasesdeobjetosinterligadasemrede,incorporandoo endereçodamáquinaservidorano

identificadordeobjeto.

Identificadoresdeobjetospuramentefísicos,por endereços,oferecemo melhorpotencialdede-

sempenhopararecuperaçãode objetos. Porém,fixar a posiçãodo objetona basetorna-amenos

flexível, dificultandooperaçõescomorelocaçãode objetos. A relocaçãopodesernecessáriopara

ampliaro espaçodearmazenamentoassociadoa um objetoou realizarumacompactaçãoou reclus-

tering dabasedeobjetos.Porestemotivo, endereçosfísicosnãosãoutilizadosnaprática.ONTOS

e Objectivity/DB utilizam endereçosestruturados,GemStonee POSTGRESutilizam surrogates, e

ORIONe Itascaadotamsurrogatestipados.

Além da referênciaa objetospor identificadoresde objetos,diversossistemasoferecema pos-

sibilidadede selocalizarum objetoatravésde atributoschaves. Em geral,a implementaçãodeste

mecanismoemsistemasgerenciadoresdebasedeobjetosé similar àqueladesistemastradicionais,

ondevaloresdeatributoschavessãomapeadosa identificadoresdeobjetosatravésde índiceshash

ouB-trees.

4.7 Swizzling

Swizzlingé o processodeconversãoentrea representaçãopersistentedo objeto,nabasedeob-

jetos,e suarepresentaçãodinâmica,nalinguagemdeprogramaçãoorientadaa objetosadotadapela

aplicação,ondeo objetoseráefetivamentemanipulado.Evidentemente,é um processoimportante

namanipulaçãodeobjetos,sendodeterminanteparao desempenhodo sistemagerenciadordebase

deobjetos.

A conversãoquedeve ocorreratravésdeswizzlingenvolve tipicamentetraduçõesdereferências

e, eventualmente,modificaçõesna estruturae no formatode representaçãode dados. Referências

dinâmicassãotipicamenteponteirosnalinguagemdeprogramação,enãoidentificadoresdeobjetos.

A traduçãode identificadoresde objetosparareferênciasa objetosna linguagemde programação

é a principal atividadedesempenhadaduranteo swizzling. Mudançasna estruturapodemocorrer

atravésda incorporaçãodecabeçalhose camposparautilizaçãoemtempodeexecução.Mudanças

narepresentaçãointernadosdadospodemsernecessáriasprincipalmentequandoabasedeobjetosé

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

compartilhadaemambientesheterogêneos.

Swizzlingpodeocorrerem momentosdistintos,de acordocom a implementaçãoadotadapara

estemecanismo.Tipicamente,umadasquatroabordagensaseguir éadotada:

1. A conversãoocorrenomomentoemqueo objetoétransferidodabasedeobjetosparao espaço

dememóriadaaplicação(checkout).

2. A conversãoocorrenomomentoemqueo objeto,já transferidoparaamemória,éreferenciado

pelaprimeiravezpelaaplicação.

3. A conversãoocorrenomomentoemquea aplicaçãoasolicitaexplicitamente.

4. A conversãoocorrequandonãoépossível reaproveitarumendereçofísicodesignadoanterior-

mente,o qualé registradotambémnabasededados.

Estaúltima abordagemé adotadaem ObjectStore,quebuscaexplorar a grandecapacidadede

endereçamentovirtual dosprocessadoresmodernosparaalocarum objetosempreà mesmaposição

dememóriavirtual.

4.8 Granularidade de transferência

Basesde objetospodemtransferirinformaçãoentreo disco e a memóriaem unidadesde di-

mensão,ou granularidades,distintas.Tipicamente,asgranularidadesadotadassãopáginas,objetos

ou resultadosdeconsultas.

A abordagemmaisutilizadanasimplementaçõesde sistemasgerenciadoresde basedeobjetos

é passarparaa aplicaçãoumaimagemdo disco,adotandogranularidadede umapágina(Fig. 6).

Estaabordagemsimplifica o trabalhodo servidorde páginas,ondeo processamentoserámínimo.

Entretanto,o tráfego dedadospelaredeé ampliado,poisumapáginapodecontermaisinformação

queasolicitadapelaaplicação.

Quandoa granularidadeadotadaé um objetoou um resultadode consulta,o tráfego de dados

pelaredeé reduzido,poisgarante-sequea aplicaçãoestarárecebendoapenaso quefoi solicitado.

Entretanto,exige-senessassituaçõesqueo servidordeobjetosjá realizealgumprocessamentosobre

a basede objetos.Seo sistemagerenciadordebasedeobjetosfor compartilhadopor muitasapli-

cações,umaltonúmeroderequisiçõessimultâneaspodeter impactosignificativo nodesempenhodo

servidor.

A abordagemde imagemdo disco,emboraeficiente,podeapresentarriscosà integridadedos

dadospresentesna página.Esteriscoestápresenteprincipalmentequandoa aplicaçãoutiliza uma

linguagemdeprogramaçãoondeé permitidoaosprogramasexaminare alterarqualquerposiçãode

seuespaçode memória— comoocorreem C++, por exemplo. Em tais situações,serianecessário

queo sistemagerenciadordebasedeobjetosimpusessemecanismosadicionaisdemanutençãoda

integridadedosdadosemumapáginamanipuladapelaaplicação,evitandosuadegradaçãoatravésde

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

página

objeto

página

objeto

Área de memória da aplicação

aplicação

Área de armazenamento do servidor

(1)

(2)(3)

(4)

Figura6: Abordagemde imagemdo discocom servidorde páginas:(1) transferênciade página(checkout) do servidorparacliente; (2) swizzling; (3) manipulaçãodo objeto pela aplicação;(4)reconversãoparaformatododiscoe transferênciadepágina(checkin) doclienteparao servidor.

açõesinadvertidasoumaliciosas.Entretanto,asimplementaçõescorrentesdesistemasgerenciadores

debasedeobjetosnãoincorporammecanismoscomestefim.

Citou-secomoumadasatividadesduranteo swizzlinga incorporaçãodeinformaçãoparamani-

pulaçãode objetosem tempode execução.Informaçãotípica de run time paraum objetoinclui o

mapeamentodeum identificadordeobjetoparaendereçofísico,o registrodequaisobjetosestãona

memóriadaaplicação,manutençãodedirty bits paraindicarseobjetosforamatualizadosou apenas

consultados,e contadoresde referênciasparasustentaratividadesinternasde swappinge garbage

collection. Abordagensparamanipulaçãodestetipo deinformaçãoincluemamanutençãodetabelas

emmemória,utilizaçãodedescritoresdeobjetose incorporaçãodestatusbits nopróprioobjeto.

4.9 Atrib utos

A forma de implementaçãomaissimplesparaa representaçãode atributosde um objetoseria

utilizar relações,comcamposdedimensãofixa, comofoi propostopor algunsprotótiposiniciais de

sistemasgerenciadoresde basede objetos. Entretanto,estaalternativa limita severamentea flexi-

bilidadede representaçãoparaobjetos,nãopermitindooperarde modoeficientecom atributosde

dimensõesvariáveis, com coleçõescomquantidadevariável de elementos,a evoluçãode esquema

pelainclusãodeatributoseo armazenamentoeficienteparaatributosnãoutilizadosporumobjeto.

Listasdepropriedadesoferecemum mecanismomaisversátildeimplementaçãodeatributosde

umobjeto.Umalistadepropriedadesécompostaporelementoscontendotrêscampos,representando

um identificadordeatributo, o tamanhodo valor do atributo e o valor. Estemecanismoé flexível,

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

porémdemandaum maiorgraudeprocessamentodapartedosmétodosquemanipulama estrutura

internadoobjeto.

Herançaéoutroaspectoquetrazimpactonarepresentaçãodeatributos.Emsistemasondeapenas

herançasimplesé permitida,o mecanismode lista depropriedadesé aindaadequado.Nestecaso,

a lista depropriedadesdeum objetoé compostapelaconcatenaçãodosatributosdo tipo do objeto

comosatributosdotipo deobjetoancestral,eassimrecursivamenteatéencontrarosatributosdotipo

deobjetoqueé a raiz dahierarquia.Paralidar comherançamúltipla,mecanismosmaiselaborados

sãonecessáriosparaestabelecerpriridadesnaconcatenaçãoeresolverconflitosentretiposancestrais

comatributosdemesmonome.

Manipulaçãodecoleçõesé outroaspectocrítico emsistemasgerenciadoresdebasedeobjetos,

sendoessemecanismoamplamenteutilizadonadescriçãodeestruturadeatributosdeobjetosenore-

tornodeconsultas.Comocoleçõespodemserdemasiadamenteextensase/ouconterobjetosgrandes,

é precisooferecermecanismosquepermitammanipulá-lasdemodomaiseficiente.O principalme-

canismoadotadoéautilizaçãodeobjetositeradores.Um iteradoréumobjetotemporárioquecontém

referênciasaosmembrosdacoleção,oferecendométodostaiscomoproduziro próximoelementoda

coleção(lista)oubuscaro � -ésimoelementodacoleção(arranjo).

A manipulaçãode atributos do tipo BLOB é usualmenteimplementadaatravés de interfaces

stream. Assimcomoiteradores,um streampermitereferenciarobjetossemqueessesestejamcom-

pletamenteconcretizadosemmemória,commétodosparaposicionar, ler eescrever blocosdedados

binários.Alternativasparaa manipulaçãodeBLOBs incluema paginaçãopor demandae utilização

depiecestreams. Napaginaçãopordemanda,aaplicaçãotemo objetocompletoemmemóriavirtual,

sendoquepáginasdo objetosãotransferidasparaa aplicaçãoà medidaqueseusbytessãoreferen-

ciados. Um piecestreamé um mecanismode streamcom facilidadesadicionaisquepermitema

atualizaçãodeconteúdodoBLOB, taiscomoinserçãoe remoçãodebytesnaposiçãocorrente.

4.10 Associações

A implementaçãoderelacionamentosnãoprecisarefletir diretamentea formacomoa aplicação

osdefineconceitualmente.A estratégiade implementaçãopodedependerdamultiplicidadedasas-

sociações.Porexemplo,umrelacionamentoum-para-muitospodeserrepresentadoporcontiguidade

física,por indexação,por ligaçãoouatravésdeobjetosintermediárioscriadospelosistemagerencia-

dordebasedeobjetos.

Um tipo de associaçãoimplícita entreos elementosde umacoleçãoé a ordenação.Apesarde

estarpresenteemmuitasaplicações,nemsempreestemecanismoésuportadoemsistemasgerencia-

doresdebasedeobjetos,ondeapenascoleçõesdo tipo conjunto(assimcomorelações,semcritérios

deordenaçãoentreelementos)sãosuportadas.A importânciadaordenaçãodacoleçãoéreconhecida

de longa data; o modeloCODASYL definia associaçõesde ordenaçãomanual(critério de orde-

naçãoestabelecidopelaaplicação)e automática(estabelecidopelosistemasobrealgumatributo da

coleção).

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

Outroaspectoimportantenaimplementaçãodeassociaçõesé a manutençãodaintegridaderefe-

rencial. O mecanismomaisamplamenteadotadoparaestefim é a utilizaçãode paresde atributos

inversos.Assim, sea aplicaçãodefineumareferênciade um objeto � paraum objeto � , denotada

� � � , o sistemagerenciadordebasedeobjetoscria internamentea referência����� . Alternati-

vamente,o sistemapodeimplementarum contadordereferênciasparao objeto,sópermitindosua

remoçãoquandoo valor destecontadorfor nulo.

4.11 Clustering

A incorporaçãodo conceitode objetocomplexo em sistemasgerenciadoresde basedeobjetos

introduzgrandeflexibilidade de estruturaçãodosdados. Por outro lado, a recuperaçãode objetos

complexos podeintroduzir degradaçãono desempenhodos sistemas. Afinal, o conteúdode um

objetocomplexo é compostopor outrosobjetos,quepotencialmentepodemestardistribuídosem

diversaspáginasespalhadaspelodisco. Assim,recuperaro conteúdodeum objetocomplexo pode

acarretaremváriassolicitaçõesdepáginasdoservidorparao cliente.

Clusteringé um mecanismoquepodeseradotadoparaminimizar estadegradaçãono desem-

penho.Simplesmentecolocado,o conceitodeclusteringé adotaralgumaestratégiadealocaçãode

objetosnosistemadearmazenamentodemodoaminimizaraquantidadedepáginasnecessáriaspara

manipularobjetos.As estratégiasdeclusteringmaisutilizadassão:

Objetoscomplexos: adotao relacionamentode agregaçãoparaidentificarobjetosquedevem ser

armazenadospróximos— preferencialmente,namesmapáginaouempáginascontígüas.

Referências: adotaa existênciade relacionamentosquaisquerentreobjetosparadirecionara pro-

ximidadede armazenamento.A estratégiade clusteringpor objetoscomplexos é um caso

especialdestaestratégia.

Tiposdeobjetos: adotao critériodeaproximaro armazenamentodeobjetosdeumamesmaclasse.

Esteéumcritérioequivalenteaoadotadopelamaiorpartedossistemasgerenciadoresdebanco

dedadosrelacionais,ondetuplasdeumamesmarelaçãosãoarmazenadascontigüamente.

Índices: adotao valordeumatributocomocritériodeordenaçãodosobjetos,eaproximao armaze-

namentodeobjetoscomvalorespróximosnesteatributo.

Definiçãodo usuário: utiliza um indicativo da aplicação,em tempode execução,parabuscara

melhorposiçãodearmazenamentodeum objeto. Um exemplode implementaçãoutiliza um

identificadordeumobjetoexistentecomoparâmetronacriaçãodeum novo objeto,indicando

queosdoisdevemserarmazenadosemposiçõespróximas.

A seleçãode um critério de clusteringdeve dependerda forma de recuperaçãomaisadotada

parao objetona aplicação.Por exemplo,em sistemasCAD provavelmentea estratégiadeobjetos

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

complexosseriaa preferencial,enquantoqueparaumaaplicaçãocomercial,envolvendoseqüências

derecuperaçõesemordemalfabética,a estratégiadeíndicesseriaamaisadequada.

4.12 Evoluçãodeesquemas

Em grandepartedossistemasgerenciadoresde basede objetos,o esquemade dadosé em si

armazenadocomoum objeto. Entretanto,esteobjetonemsempreé diretamentemanipulável pela

aplicaçãoemtempodeexecução;restriçõesdeacessosãoimpostascomoformademanutençãoda

integridadedabasedeobjetos.Mudançasnoesquemadevemobedecera taisrestrições,determinan-

docomoesquemaspodemevoluir.

Há quatroestratégiasbásicasque determinamcomo um esquemapodeevoluir: tipo de uma

escrita,atualizaçãoimediata,atualizaçãoposterior, e mapeamentodeesquema.Taisestratégiassão

brevementeapresentadasaseguir.

A estratégiade tipos de uma escrita(ou tipos write-once) é a abordagemmais simples,que

determinaquequalquertipo que já contenhapelo menosumainstâncianãopodesermodificado.

Modificaçõesno tipo, tal comoa inclusãode um novo atributo, deve serexplicitamentedesempe-

nhadapelaaplicaçãoatravésdacriaçãodeumnovo tipo ecópiadoconteúdodeobjetosjá existentes

paraobjetosdonovo tipo.

A estratégiade atualizaçãoimediataé a mais adotadaem sistemasgerenciadoresde basede

objetoscorrentes. Nestaestratégia,qualquermodificaçãono tipo de um objeto é imediatamente

refletidaparaosobjetos.Assim,a inclusãodeum novo atributo emum tipo fariacomquetodosos

objetosdaqueletipo tivessemsuaestruturaatualizadaoaraconterum campoadicionalcontendoo

valornulo.

Na estratégiadeatualizaçãoposterior, a estruturadeum objetocujo tipo tenhasidomodificado

nãoé alteradaa nãoserno primeiromomentoemqueo objetoé acessadoapósa alteraçãodo tipo.

Nestaabordagem,é precisoque o sistemagerenciadorde basede objetosmantenhainformação

históricasobrea evoluçãode esquemase sobreprocedimentosde conversãoparapodermantera

consistênciadabase.

A estratégiademapeamentodeesquemaequivaleaumaestratégiadeatualizaçãoposterioronde

o momentodeatualizaçãoé postergadoindefinidamente,atéo momentoemqueumareorganização

da basede objetossejaexplicitamentesolicitada. Nestaestratégiaé precisomanteros mapasde

conversãoentretodasaspossíveis versõesdeesquema,o quepossibilitariaqueusuáriospudessem

ter visõesde um mesmoobjetosobdiferentesversõesde esquema.Entretanto,a implementação

de tal estratégiaseriaextremamentecomplexa, nãotendosido implementadaem nenhumsistema

gerenciadordebasedeobjetosatéo momento.

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

5 Exemplos

Nestaseçãoserãodescritosalgunsexemplosdesistemasgerenciadoresdebasedeobjetos.Deve-

seobservar, entretanto,queemsetratandodesistemascomerciaisgeralmentenãoépossível obterin-

formaçãodetalhadasobreosmecanismosdeimplementaçãodosistema.Porestemotivo, apresenta-

seinicialmenteumprotótiposobreo qualinformaçãosobrea implementaçãoébemconhecida.

5.1 UniCOSMOS

UniCOSMOS(University of CampinasObjectStorage ManagementSystem)foi um protótipo

desenvolvido naUNICAMP noperíodo1985–1989paraaplicaçõesemengenharia[28,39]. Efetiva-

mente,UniCOSMOSnãoeraum sistemagerenciadordebasedeobjetos,massim um núcleopara

taissistemasondealgunsdosmecanismosbásicosdemanipulaçãodeobjetospersistentespoderiam

seravaliados.

A arquiteturade UniCOSMOSé apresentadana Fig. 7. A partesuperiorda figura representa

módulosrelativos ao esquemade objetos,enquantoque a parteinferior representamódulosque

manipulaminstâncias(ouseja,objetos).

domínio detipos deobjetos

domínio detríades

subsistema deacesso a tipos

subsistema deacesso a objetos

domínio devalores

nome do tipo

domínio,valor

iv domínio de

objetos

io

iv

id

ioiv

id

irid

nome

Figura7: ArquiteturadeUniCOSMOS.

Nestesistema,tiposdeobjetossãoidentificadospor um nome. O subsistemadeacessoa tipos

mantémumatabelahashqueassociaosnomesdeobjetosasurrogatestipados(id). Um mecanismo

desinônimosésuportado,sendopossível associarmaisdeumnomeparaummesmotipo deobjeto.

O domíniodetiposdeobjetosregistraainformaçãosobreo esquemadabasededados.Paracada

tipo deobjeto,cincolistasinternasmantêminformaçãosobre:

1. osnomesdo tipo deobjeto;

2. osatributosdo tipo deobjeto;

3. asassociaçõescomoutrostiposdeobjeto;

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

4. ostiposdeobjetoscomponentes,casoo objetosejacomplexo;

5. os tipos de objetosquecontêmestetipo comocomponente,casoo objetofaçapartede um

objetocomplexo.

Associaçõessãorepresentadasinternamentepor tríades,ouassociaçõesbinárias.A ligaçãoentre

doistiposdeobjetosé estabelecidapor umterceirotipo deobjeto,criadointernamente.Assim,uma

referência� �!�"� émapeadainternamenteparaumatríade#$�%���&� . Parafacilitara manutenção

daintegridadereferencial,o domíniodetríadesarmazenatodasaspermutaçõesdecadaassociação.

Assim, tambémsãoarmazenadasnestedomínioastríades���'�(�)# e �*�)#+�,� . Cadatríade

registradanestedomínioé identificadaporumsurrogateir.

No nível de instâncias,objetossãorepresentadosatravésdelistasdepropriedadesarmazenadas

nodomíniodeobjetos.A flexibilidadedaslistasdepropriedadespermitemanipularadequadamente

atributoscom valoresnulos,multivaloradose de dimensãovariável. Cadalista de propriedadesé

identificadaporumsurrogatedeobjeto(io), ecadaelementodalistaéformadoporumidentificador

deatributo (referenteaoidentificadordotipo deobjeto,id) eporumidentificadordevalor (iv). Os

valoressãoarmazenadosdefatono domíniodevalores,ondecadadomínio(no sentidomatemático

dapalavra, o conjuntodeelementosdosquaisosvaloresdeatributossãotomados)é compostopor

umalistadepropriedadesparavalores.Cadaelementodestalista, identificadoporumsurrogateiv,

contémadimensãoea representaçãointernadovalor.

O subsistemadeacessoaobjetostemporobjetivo apoiaratividadesdeconsultasporvaloràbase

deobjetos.Nestemódulosãoimplementadososmecanismosparaagilizaracessoà informação,tais

comoestruturasdeíndices.Comodomíniospodemsercompartilhadosporváriostiposdeobjeto,as

respostasa consultassãoorganizadasnaformadelistasdesurrogatesio. Pararestringira buscaa

um único tipo deobjeto,é precisocombinaresteresultadocomo resultadodeumabuscano nível

de esquema,através do nomedo objeto. Paraagilizar a realizaçãodestascombinações,diversos

métodosdemanipulaçãodesurrogatessãooferecidosàsaplicaçõesdeUniCOSMOS.

O sistemafoi implementadoem linguagemC, em estaçõesde trabalhoUnix. Desenvolvimen-

tosrelacionadosa UniCOSMOSincluíramo tratamentodetransaçõesconvencionaise longas[35],

tratamentode regrase de restrições[30], manipulaçãode herança[43] e a implementaçãode um

gerenciadordedadosparaprojetosdeengenhariamanipulandoesquemasentidade-relacionamento

estendidoscommecanismosparaobjetoscomplexoseevoluçãodeesquemas[40].

5.2 O -O desenvolvimento do SistemaO- [15] iniciou-secomoum protótipode pesquisa,posterior-

menteconvertido paraum produtocomercialda empresafrancesaO- Technology. O sistemafoi

desenvolvido emC++ paraplataformasUnix.

O principalmódulodosistemaéo EngenhoO- , estruturadoemtrêscamadas:

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

Gerenciadordeesquema,responsável por monitorarcriação,recuperação,atualizaçãoe remoção

declasses,métodosenomesglobais;

Gerenciadordeobjetos, camadaintermediáriaqueforneceidentificaçãodeobjetose implementa

estratégiasdeindexaçãoeclustering;

Gerenciadordedisco, responsável por implementarasestruturasde arquivos (paginados)quear-

mazenamfisicamenteosdadosdosobjetosdosistema.

As camadasmaiselevadasdo sistemasãoorganizadasna forma de umaaplicaçãocliente,que

podeexecutaremumamáquinaconectadaaoservidorbabasededados,ondeaaplicaçãogerenciador

dediscoatuacomoumservidordepáginas.

Identificadoresde objetossãoregistradosinternamentesoba forma de endereçosestruturados,

comcamposparaidentificaçãodeum volumededados(2 bytes),combinadocomumaidentifcação

depáginanovolume(4 bytes)eumaposição(slot)napágina(2 bytes).Paraaaplicação,descritores

deobjetossãoutilizados.

Objetosem O- podemser atômicos(inteiros, reais,booleanos,strings e bits) ou complexos,

criadosa partir deconstrutoresdetuplas,conjuntos,bagse arranjos.Persistênciaé definidapor re-

ferência;objetosquesãoderivadosdeumaraizpersistente,diretaou indiretamente,sãopersistentes.

A interaçãodeumaaplicaçãocomo sistemapodeocorreratravésdeinterfacesdeprogramação

emC ou C++, atravésdeumalinguagemdeclarativa (O- C) ou atravésdeO- SQL,umaextensãode

SQLparalidar comobjetoscomplexos.

5.3 ObjectStore

ObjectStore[32] éumsistemacomercialdebancodedadosorientadoaobjetosdesenvolvido pela

ObjectDesignInc., de Burlington, Massachusetts.Um dosobjetivos iniciais no desenvolvimento

destesistemaerafazerdeC++ umalinguagemdeprogramaçãodebancodedados.Porestemotivo,

ObjectStoreéumdossistemasmaispróximosdestalinguagememtermossemânticos.

ObjectStoreoferecesuporteparaidentificaçãode objetos,atributos inversos,herançamúltipla,

acessopaginadoaBLOBseaplicaçõesinterativasparavisualizaçãodeconteúdoecriaçãodeesque-

mas. Manipulaçãode coleçõesé oferecidaatravésde bibliotecasde tipos de coleções,que inclui

conjuntos,bags, listas,arranjose dicionários.Bagssãoconjuntosquepermitemduplicaçãodeele-

mentos. Dicionáriossãobags ondea cadaelementoé associadaumachave. Um tipo genérico,

coleção,tambémé oferecido. A Fig. 8 apresentaumaárvore de decisãoassociadaà definiçãoda

melhorformadecoleçãoparaumaaplicação[33].

A interaçãoentreObjectStoree a aplicaçãopodeocorreratravésdeumalinguagemdemanipu-

laçãode dadosou atravésde interfacesde programaçãoem C, em C++ e, desdea versão5.0, em

Java. O mecanismodemapeamentodeobjetosparao espaçodememóriavirtual tornaa persistên-

cia naturalem ObjectStore,ondequalquerdadopodese tornarpersistente.Assim, o mecanismo

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

ordenadas e desordenadas, ou entredesordenadas com duplicatas e desordenadas sem duplicatas

Mantém a ordem de inserção

Associa chave acada elemento

Adição automática denúmero especificado de

elementos nulos

Permite mudanças entre coleções

os_Collection

os_Dictionary os_List os_ArrayPermite duplicatas

os_Set os_Bag

nãosim

sim

sim

sim

sim

não

não

não

não

Figura8: ÁrvorededecisãoparatiposcomplexosemObjectStore.

de persistênciaé ortogonalà hierarquiade tipos. Um aspectonegativo nestaestratégiaé queeste

mecanismoexige a manutençãodemecanismosdepré-processamento,dificultandoa portabilidade

dosistemaentreplataformasdistintas.Poroutrolado,umavezqueobjetossejamtransferidosparaa

memóriaprincipalapósum page fault, suamanipulaçãoé tãorápidacomoa dequalquerobjetonão

persistentedalinguagemdeprogramação.

AplicaçõesdeObjectStoreutilizam doisprocessosparasuaexecução.O servidordepáginasé

o ObjectStoreServer, queestáexecutandopermanentementeemumamáquinaondeosdadosestão

armazenados.O ladoclientedeObjectStoreé implementadoatravésdeum CacheManager, queé

ativadoautomaticamentepelaaplicação(Fig. 9). Um clientepodeacessarinformaçãode diversos

servidores,caracterizandoObjectStorecomotendoumaarquiteturamúltiplos clientese múltiplos

servidores.

6 Esforçoscorrentesedir eçõesfuturas

Nestaseçãofinal é feito umbreveapanhadodeesforçoscorrentesquepoderãoafetaro desenvol-

vimentofuturo desistemasgerenciadoresdebasedeobjetos,comênfasenosaspectosdepadroni-

zaçãoe futurasaplicações.

6.1 ODMG

ODMG (ObjectDatabaseManagementGroup)é um consórcio,formadoem1991por diversos

fabricantesdesistemasgerenciadoresdebasedeobjetos,quetempor objetivo criar um padrãopara

bancosde dadosorientadosa objetosquepermitaampliaro graude portabilidadedasaplicações

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

...

aplicaçãoaplicação

aplicação

cache manager

cache manager

aplicação

servidor

servidor

cache manager

Figura9: ProcessosnaarquiteturadeObjectStore.

desenvolvidas paraos seusdiferentessistemas[9]. Assim comoSQL permiteoferecerparauma

aplicaçãouma visãocomumde basesde dadosrelacionais,independentedo fabricante,busca-se

comODMG atingirumgraudepadronizaçãosimilarparasistemasgerenciadoresdebasedeobjetos.

OsparticipantesdoconsórcioODMG incluemObjectDesign,ONTOS,O- Technology, Versant,

Objectivity, Digital Equipment,Hewlett-Packard,Itasca,Intellitic, PoetSoftware, Servioe Texas

Instruments.Pelomenosestasempresasconcordaramemtornarseusprodutoscompatíveis como

padrãoODMG parasistemasgerenciadoresdebasedeobjetos.Deve serenfatizadoquenãoháuma

padronizaçãoda implementação,ou seja,os produtosde cadaempresanãosãoidênticos;apenas

oferecemumainterfacecomumparaasaplicações.

O focodestepadrãofoi naintegraçãodesistemasgerenciadoresdebasedeobjetosa linguagens

deprogramação.Entretanto,parapoderdefinir interfacespadronizadasentresistemasgerenciadores

debasede objetose linguagensde programaçãoeranecessárioinicialmenteter umavisãocomum

decomoum sistemagerenciadorde basedeobjetosdeveria estarestruturadoe de quaisseriamos

seuscomponentes.O resultadodesteprimeiro esforçofoi a definiçãode umaarquiteturacomum,

apresentadanaFig. 10.

O padrãoODMG estáorganizadoemduascomponentesprincipais,framework e bindings. Em

frameworkdefinem-seaspectoscomunsatodasaslinguagensdeprogramação,taiscomoaarquitetu-

ra,o modelodeobjetos,a linguagemdedeclaração(ODL) e umalinguagemdeclarativa deconsulta

(OQL). O conjuntodebindings, estabeleceo mapeamentodasconstruçõesdo padrãoparaaquelas

delinguagensdeprogramação.Atualmente,C++, Smalltalke Java sãocontempladasnopadrão.

O modelodeobjetosdeODMG sumarizadiversosconceitossuportadospor sistemasgerencia-

doresde basede objetos.Ele ofereceobjetose literais comoprimitivasde modelamento.Literais

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

Códigoexecutável

Códigoobjeto

Programaaplicação

Declaraçõesem ODL

base dedados

SGBOruntime

aos dadosacesso

metadados

pré-processador

ligador

compilador

Figura10: ArquiteturadeumsistemagerenciadordebasedeobjetosnopadrãoODMG.

podemseratômicos(Long,Float,Octet,.. . ), coleção(Set,Bag,List e Array) ou estruturados(Date,

Time, Timestamp,.. . ). Objetospodemseratômicosou coleção.O estadodeum objetoé definido

por suaspropriedades,quepodemseratributosou relacionamentos.O comportamentodo objetoé

definidopeloconjuntodeoperaçõesquepodemserexecutadassobreo objeto.Objetose literaissão

categorizadospor seustipos;elementosdeum mesmotipo têmestruturae comportamentocomuns.

Algumasvezes,um objetoé denominadoumainstânciadeum tipo. Um bancodedadosarmazena

objetos,permitindoqueestessejamcompartilhadospor múltiplosusuáriose aplicações.Um banco

de dadosé baseadoem um esquemaqueé definidoem umalinguagemde definiçãode objetose

contéminstânciasdetiposdefinidosporseuesquema.

6.2 OMG

OMG (ObjectManagementGroup)[34] éumconsórcioindustrial,formadoem1989,cujoobje-

tivo é definir padrõesparapermitir inter-operabilidade emsistemasdistribuídosheterogêneos,ado-

tandoparatal o paradigmade objetosdistribuídos. Atualmenteo consórcioenglobamaisde 800

participantes.

O principalresultadodoOMG foi adefiniçãodeumaarquiteturaparao desenvolvimentodeapli-

caçõespor objetosdistribuídos. Estaarquitetura,CORBA (CommonObjectRequestBroker Archi-

tecture) (Fig. 11), estabelecea funcionalidadedeumacamadamiddleware, o ORB (ObjectRequest

Broker) e asfuncionalidadesdeserviçosdeobjetospadrões,CORBAservices, queincluemserviços

debuscadeobjetospor nome(naming), buscapor propriedades(trader), serviçosdesegurança,de

transaçõesedenotificaçãodeeventos,entreoutros.

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

Domaininterfaces

ORB

Applicationinterfaces

CommonFacilities

CORBAservices

Figura11: Arquiteturadegerenciamentodeobjetos(OMA).

Além disto, outrostipos de serviçospodemestaragrupadosem CommonFacilities, Domain

InterfacesouApplicationInterfaces[42]. AssimcomoCORBAservices, CommonFacilities incluem

serviçosde propósitogeral; porém, tais serviçosestãomais próximosem nível de abstraçãodo

usuáriofinal, enquantoCORBAservicesapresentamnível deabstraçãobaixo. Um exemplodeuma

facilidadenestacategoria é o Distributed DocumentComponentFacility, paraa manipulaçãode

documentoscompostos.As interfacesdedomíniosãoserviçosespecializadosparadadascategorias

deaplicações,comoemáreafinanceira,telecomunicaçõesemedicina.As interfacesdeaplicaçãosão

componentesdaarquiteturaespecíficosdeumaaplicação,nãosendoportantoobjetodepadronização.

Comomostraa Fig. 12, ORB e bancosdedadosaderentesà propostaODMG apresentamalgu-

masobreposiçãodefuncionalidades,masapresentamum alto graudecomplementaçãodeserviços

oferecidos.Antevê-sequea combinaçãodestasduaslinhasdedesenvolvimentosejaa direçãopara

asnovasaplicaçõesdesistemasdeinformaçãoemambientesdistribuídos.

ORB SGBO

armazenamento

transações

descrição

identificação

distribuiçãoversões

consultas

tradução

localização

heterogeneidade

invocação remota

Figura12: FuncionalidadesORBeODMG.

Uma análiseda integraçãoentresistemagerenciadorde basede objetose CORBA, particular-

menteparaaplicaçõesmultimídia, foi apresentadapor Tobar[49]. Similarmente,outrascategorias

deaplicaçãopoderiamanalisarqualplataformaatendemelhoràssuasnecessidadesparaselecionara

estratégiadeimplementação.

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

6.3 Conclusões

A tecnologiadeorientaçãoaobjetosestápermeandopraticamentetodasasnovasaplicaçõescom-

putacionais.O queháalgumtempoatráseraapenasumabuzzword quedavaum“ar demodernidade”

paraalgumasaplicaçõesé atualmenteumatecnologiarelativamentemadura,comutilizaçãoefetiva

nasmaisdiversascategoriasdeaplicação.

Bancode dadosé apenasumadasáreasquevem sebeneficiandodestatecnologia. Provavel-

mente,maisdo quesimplesmenteoferecera capacidadede ter um repositórioorientadoa objetos

paraaplicaçõesisoladas,a importânciadesistemasgerenciadoresdebasedeobjetosserápermitir a

integraçãodeaplicaçõesemambientesdeobjetosdistribuídos.Nestaabordagem,osserviçosdeum

sistemagerenciadordebasedeobjetospoderãoserincorporadosa aplicaçõesde formauniformee

transparente,damesmamaneiraqueassimo serãoserviçosde interfacesgráficascomusuáriosou

invocaçãodinâmicadeserviçosdistribuídos.

A chaveparaatingirestapróximaetapanatecnologiadebancodedadosestánageneralidade.Ao

contráriodo paradigmadedesenvolvimentoquedominouo final dadécadade1970e praticamente

todaa décadade 1980,quandohavia dezenasou centenasde sistemasgerenciadoresde bancode

dadosespecializadosparaa aplicação. ou paraa aplicação/ , o objetivo atualé oferecerserviços

básicos,possivelmenteconfiguráveis,quepossamserintegradosdeacordocomasnecessidadesde

cadaaplicação.

Estaabordagemdeoferecimentodeserviçosatendede formamuitaadequadaàsnovascatego-

rias de aplicaçãoem sistemasde informação,incluindo a manipulaçãode informaçãomultimídia

e hipermídia. Dificilmente seriapossível desenvolver um sistemagerenciadorde bancode dados

especializadoqueatendesseadequadamenteàsnecessidadesde todasaplicaçõesmultimídiaou hi-

permídia,poisestasvariammuitodeacordocomo caráterdaaplicação.No entanto,éperfeitamente

viável imaginarquetaisaplicaçõesserãoatendidasatravésdacombinaçãodeserviçosespecializados

de armazenamento,de consulta,de pesquisa,e assimpor diante. O oferecimentode tais serviços

torna-seinteressanteà medidaqueelesnãosãodeusoexclusivo deum bancodedadosou deuma

aplicação.Assim,o mesmoserviçodepesquisaqueéutilizadoporumaaplicaçãomultimídiapoderia

serutilizadoemumaoutraaplicaçãoemdatamining, porexemplo.

Em suma,há atualmenteprodutosem bancosde dadosorientadosa objetosqueutilizam uma

tecnologiaque já estárazoavelmenteamadurecida,atendendoa muitasaplicações.Há ainda,no

entanto,umanecessidadedeseestenderasfuncionalidadesdessesserviçosdebancosdedadospara

qualqueraplicaçãodesenvolvidasem frameworksdeobjetosdistribuídos.Paraatingir esteobjetivo,

aspesquisasnestaáreaseguemduasdiretrizesfundamentais.A primeirapodeserresumidaatravés

daspalavrasgeneralidadeeadaptabilidade.Desenvolvimentosemdesignpatternssãoemblemáticos

destadiretriz. A segundapodeserresumidapelapalavra inter-operabilidade,ondea tecnologiade

objetosdistribuídosvemsedestacando.

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

Referências

[1] S.AbitebouleP. Kanellakis.Thetwo facetsof object-orienteddatamodels.IEEEDB Engine-

eringBulletin, 14(2),Junho1991.

[2] M. M. Astrahan,M. W. Blasgen,D. D. Chamberlin,K. P. Eswaran,, J.N. Gray, P. P. Griffiths,

W. F. King, R. A. Lorie, P. R. McJones,J. W. Mehl, G. R. Putzolu,I. L. Traiger, B. W. Wade,

e V. Watson.SystemR: Relationalapproachto databasemanagement.ACM Transactionson

DatabaseSystems, 1(2):97–137,Junho1976.

[3] T. R. Ayers,D. K. Barry, J. D. Dolejsi, J. R. Galareneau,e R. V. Zoeller. Developmentof

ITASCA. Journalof Object-OrientedProgramming, 4(4):46–49,Julho1991.

[4] JayBanerjee,Won Kim, Hyoung-JooKim, e HenryF. Korth. Semanticsandimplementation

of schemaevolution in object-orienteddatabases.Em Proceedingsof theACM SIGMODCon-

ference, páginas311–322.1987.

[5] J.H. terBekke. SemanticDataModeling. PrenticeHall, 1992.

[6] M. W. Blasgen,M. M. Astrahan,D. D. Chamberlin,J.N. Gray, W. F. King, B. G.Lindsay, R.A.

Lorie, J.W. Mehl, T. G. Price,G. R. Putzolu,M. Schkolnick, P. G. Selinger, D. R. Slutz,H. R.

Strong,I. L. Traiger, B. W. Wade,e R. A. Yost. SystemR: An architecturaloverview. IBM

SystemsJournal, 20(1):41–62,1981.

[7] RobertBretl, David Maier, Allen Otis,JasonPenney, BruceSchuchardt,JacobStein,E. Harold

Williams, e Monty Williams. TheGemStonedatamanagementsystem.Em Kim e Lochovsky

[25], capítulo12,páginas283–308.

[8] P. Butterworth,A. Otis, e J.Stein. TheGemStoneobjectdatabasemanagementsystem.Com-

municationsof theACM, 34(10):64–77,Outobro1991.

[9] R. G. G. Cattell, editor. The Object DatabaseStandard: ODMG–93. Morgan–Kaufmann

Publishers,SanMateo,CA, 1993.

[10] R. G.G. Cattell.ObjectDataManagement:Object-OrientedandExtendedRelationalDataba-

seSystems. Addison-Wesley, 1994.Revisededition.

[11] PeterP. Chen.Theentity-relationshipmodel— towarda unifiedview of data.ACM Transac-

tionsonDatabaseSystems, 1(1):9–36,Março1976.

[12] E. F. Codd. A relationalmodelof datafor large shareddatabanks. Communicationsof the

ACM, 13(6):377–387,Junho1970.

[13] E. F. Codd. Extendingthedatabaserelationalmodelto capturemoremeaning.ACM Transac-

tionsonDatabaseSystems, 4(4):397–434,Dezembro1979.

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

[14] GeorgeCopelande David Maier. MakingSmalltalkadatabasesystem.Em Proceedingsof the

SIGMODConference, páginas316–325.ACM, 1984.

[15] O. Deux,C. Delobel,D. DeWitt, Y. Ioannidis,et al. Thestoryof O2. IEEE Transactionson

Knowledge andDataEngineering, 2(1),Março1990.

[16] RamezElmasri e ShamkantB. Navathe. Fundamentalsof DatabaseSystems. Benja-

min/CummingsPublishingCompany, segundaedição,1994.

[17] D. H. Fishman,J. Annevelink, D. Beech,E. Chow, T. Connors,J. W. Davis, W. Hasan,C. G.

Hoch,W. Kent,S. Leichner, P. Lyngbaek,B. Mahbod,M. A. Neimat,T. Risch,M. C. Shan,e

W. K. Wilkinson. Overview of theIris DBMS. EmKim eLochovsky [25], capítulo10,páginas

219–250.

[18] J.P. Fry eE. H. Sibley. Evolutionof data-basemanagementsystems.ACM ComputingSurveys,

8(1):7–42,Março1976.

[19] Adele Goldberg e David Robson. Smalltalk-80,The Language. Addison-Wesley Seriesin

ComputerScience.Addison-Wesley, Setembro1989.

[20] J.Gosling,B. Joy, eG. Steele.TheJavaLanguage Specification. JavaSeries.Addison-Wesley,

1996.http://java.sun.com/doc/language_specification/index.html.

[21] JamesGoslinge HenryMcGilton. TheJavaLanguage Environment:A WhitePaper. SunMi-

crosystems,Inc.,MountainView, CA, Maio 1996.http://www.javasoft.com/docs/

white/langenv/.

[22] RichardHull e RogerKing. Semanticdatabasemodeling:Survey, applications,andresearch

issues.ACM ComputingSurveys, 19(3):201–260,Setembro1987.

[23] WonKim, editor. ModernDatabaseSystems:TheObjectModel,Interoperability andBeyond.

ACM Press,1995.

[24] WonKim, NatBallou,Hong-Tai Chou,JorgeF. Garza,eDarrelWoelk. Featuresof theORION

object-orienteddatabasesystem.EmKim eLochovsky [25], capítulo11,páginas251–282.

[25] Won Kim e FrederickH. Lochovsky, editores. Object-OrientedConcepts,Databases,and

Applications. FrontierSeries.ACM Press,1989.

[26] HenryF. KortheAbrahamSilberschatz.DatabaseSystemConcepts. McGraw-Hill, 1986.

[27] GeorgeLapis,Guy M. Lohman,e HamidPirahesh.Starburst is born. SIGMODRecord (ACM

SpecialInterestGrouponManagementof Data), 19(2),Junho1990.

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

[28] Léo P. Magalhães,ArmandoL. N. Delgado,Ivan L. M. Ricarte,ReginaC. Ruschel,e Carlos

JoséM. Olguín. Implementaçãodeumbancodedadosnão-convencional:a experiênciaGER-

PAC/UniCOSMOS.Em IV SBBD— SimpósioBrasileiro deBancodeDados, páginas77–89.

Campinas,SP, Abril 1989.

[29] OscarNierstrasz.A survey of object-orientedconcepts.EmKim eLochovsky [25], capítulo1,

páginas3–21.

[30] Farid Nouranie Léo Pini Magalhães.Um sistemade tratamentode restriçõesde projetono

contexto GERPAC/UniCOSMOS. Em VI SimpósioBrasileiro de Bancode Dados. Manaus,

AM, Maio 1991.

[31] Kristen Nygaard. Basic conceptsin object oriented programming. SIGPLAN Notices,

21(10):128–132,Outobro1986.

[32] Object Design,Inc., Burlington, MA. ObjectStore Technical Overview; Release2.0, Julho

1992.

[33] ObjectDesign,Inc. ObjectStore C++ API UserGuide. Burlington,MA, Junho1995.

[34] ObjectManagementGroup.OMG homepage.http://www.omg.org/, 1998.

[35] CarlosJoséM. Olguíne Léo Pini Magalhães.Um gerenciadorde transaçõesno contexto do

GERPAC/UniCOSMOS.Em V SimpósioBrasileiro de Bancode Dados. Rio de Janeiro,RJ,

Abril 1990.

[36] KamranParsaye,Mark Chignell, SetragKhoshafian,e Harry Wong. Intelligent Databases:

Object-Oriented,Deductive, HypermediaTechnologies. JohnWiley andSons,1989.

[37] JoanPeckhameFredMaryanski.Semanticdatamodels.ACM ComputingSurveys, 20(3):153–

189,Setembro1988.

[38] WalterD. Pottere RobertP. Trueblood.Traditional,semantic,andhyper-semanticapproaches

dodatamodeling.IEEEComputer, páginas53–63,Junho1988.

[39] IvanL. M. Ricarte.MOODS:amodular, object-orienteddesigndatabasesystem.EmF. Kimura

e A. Rolstadås,editores,ComputerApplicationsin ProductionandEngineering, páginas225–

229.North-Holland,1989.

[40] Ivan L. M. Ricartee ArmandoL. N. Delgado. GERPAC — um SGBD paraPAC. Em II

SimpósioBrasileiro deBancodeDados, páginas22–38.PortoAlegre,RS,Maio 1987.

[41] LawrenceA. Rowe e MichaelR. Stonebraker. ThePOSTGRESdatamodel. Em Proceedings

of the13thVLDBConference, páginas83–96.Brighton,UK, 1987.

IvanL. M. Ricarte BancosdeDadosOrientadosa Objetos

[42] Doug Schmidt. Overview of CORBA. http://www.cs.wustl.edu/~schmidt/

corba-overview.html, Agosto1998.

[43] MamedeAugustoMachadoda Silveira. Extensãodo NúcleoUniCOSMOSpara Suporteà

Orientaçãopor Objeto. Tesedemestrado,FaculdadedeEngenhariaElétrica,UNICAMP, Abril

1991.

[44] JohnMiles Smithe DianeC. P. Smith. Databaseabstractions:Aggregationandgeneralization.

ACM TransactionsonDatabaseSystems, 2(2):105–133,Junho1977.

[45] Michael Stonebraker. Retrospectionon a databasesystem. ACM Transactionson Database

Systems, 5(2):225–240,Junho1980.

[46] MichaelStonebraker, EugeneWong,PeterKreps,e GeraldHeld. Thedesignandimplementa-

tion of INGRES.ACM TransactionsonDatabaseSystems, 1(3):189–222,Setembro1976.

[47] BjarneStroustrup. What is object-orientedprogramming? IEEE Software, páginas10–20,

Maio 1988.

[48] BjarneStroustrup.TheC++ ProgrammingLanguage. Addison-Wesley, segundaedição,1991.

[49] CarlosM. TobareIvanL. M. Ricarte.Multiwaredatabase,adistributedobjectdatabasesystem

for multimediasupport.Em OpenDistributedProcessing:Experienceswith DistributedEnvi-

ronments,Proceedingsof the IFIP InternationalConferenceon OpenDistributedProcessing,

ICODP’95, páginas439–450.Fevereiro1995.

[50] M. Ubell. The MontageextensibleDataBladearchitecture.SIGMODRecord (ACM Special

InterestGrouponManagementof Data), 23(2):482–482,Junho1994.