Tcc Exemplo OO Pagina12

SistemasdeBancosdeDadosOrientadosaObjetos

IvanLuizMarquesRicarte

Depto.EngenhariadeComputaçãoe AutomaçãoIndustrial

FaculdadedeEngenhariaElétricaedeComputação

UniversidadeEstadualdeCampinas

mailto:[email protected]

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


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.


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.


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


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.


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,

��


� 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


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.


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


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


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


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


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.


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.


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


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


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


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


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


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


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


(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.


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é


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


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,


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).


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


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.


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;


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:


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


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


...

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


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.


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.


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.


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.


[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.


[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.


[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.

Documents

Tcc Exemplo OO Pagina12