INSTITUTO MILITAR DE ENGENHARIA USO DE REGRAS ATIVAS NO TRATAMENTO DE EVOLUÇÃO DE ESQUEMAS EM UM SISTEMA DE GERENCIADOR DE OBJETOS POR

Transcrição

1 INSTITUTO MILITAR DE ENGENHARIA USO DE REGRAS ATIVAS NO TRATAMENTO DE EVOLUÇÃO DE ESQUEMAS EM UM SISTEMA DE GERENCIADOR DE OBJETOS POR RICARDO OLIVEIRA BARROS TESE SUBMETIDA COMO REQUISITO PARCIAL PARA A OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIAS EM SISTEMAS E COMPUTAÇÃO Assintur do Orientdor d Tese ANA MARIA DE CARVALHO MOURA - D. Ing. Rio de Jneiro Mio 1996

2 Tese presentd por RICARDO OLIVEIRA BARROS e provd por: ANA MARIA DE CARVALHO MOURA - Dr. Ing. ASTÉRIO KIYOSHI TANAKA - PhD. MARTA LIMA DE QUEIRÓS MATTOSO - D.Sc. GUSTAVO MIRANDA ARAÚJO - M.Sc. IME, RIO DE JANEIRO - RJ, 03 de Mio de ii

3 RESUMO Evolução de esquems é um importnte requisito pr plicções OO (Orientds Objeto). Est funcionlidde está ssocid à hbilidde de executr dinmicmente um lrg vriedde de modificções sobre o esquem do BD, minimizndo necessidde de um reorgnizção em prol de um melhor desempenho do sistem. Modificções em esquems de SGBDOOs tendem ser mis freqüentes do que em SGBDs convencionis, devido o fto de que um esquem de BDOO é extensível, ou sej, suport crição de novos tipos e operções. Portnto, existênci de muitos interrelcionmentos no esquem e necessidde de lterções cd vez mis freqüentes, fzem com que o suporte à evolução de esquems em SGBDOOs sej necessário e muito mis complexo que nos SGBDs convencionis. Muitos dos SGBDOOs comercilmente disponíveis trtm pens d integridde estruturl do esquem, não permitindo modificções depois d bse instncid. Neste trblho, são trtdos os efeitos ds modificções do esquem sobre os métodos e objetos instncidos no SIGO - Sistem Gerencidor de Objetos. O principl objetivo é grntir, lém d integridde estruturl, integridde comportmentl e de instncição do esquem d plicção. Este resultdo é obtido pelo rmzenmento ds efetivs modificções sobre o esquem num hierrqui de clsses e pel conseqüente propgção dests modificções os objetos instncidos. A propgção é feit trvés de métodos definidos como regrs tivs ssocidos às clsses. Ests regrs são utomticmente tivds por métodos que referencim os objetos durnte mnipulção do esquem. iii

4 ABSTRACT Schem evolution is n importnt requirement to OO (Object Oriented) pplictions. This functionlity is ssocited to the bility to dynmiclly execute wide vriety of modifictions on the DB (Dtbse) schem, minimizing the need to reorgnize it, in order to hve better performnce. Schem chnges in n OODBMS (Object Oriented Dtbse Mngement System) hppen to be more frequent thn in conventionl DBMS, s the schem is extensible, tht is, it provides the cretion of new types nd opertions. So, the existence of mny reltionships in the schem nd its need for frequent chnges, turns out to require n OODBMS schem evolution support, nturlly much more complex thn in conventionl DBMS. Most of the commercil OODBMS vilble in the mrket keep only the schem structurl integrity, not llowing modifictions fter the dtbse hs been instntited. This work describes the schem modifiction effects over objects nd methods stored in SIGO - n Object Mnger System. Its min purpose is to mintin, besides its structurl integrity, the behviorl nd the instntition integrity of the ppliction schem. This im is obtined by storing the rel schem modifiction in clss hierrchy nd by propgting these modifictions to the objects instntited in the DB. This propgtion is executed by methods defined s ctive rules, ssocited to the clsses. These rules re utomticlly ctivted by ppliction methods tht reference objects during the schem mnipultion. iv

5 SUMÁRIO RESUMO ABSTRACT LISTA DE ILUSTRAÇÕES LISTA DE TABELAS LISTA DE ABREVIATURAS E SÍMBOLOS iii iv viii xi xii 1 - INTRODUÇÃO Posicionmento Justifictiv pr o trblho Objetivo do trblho Orgnizção do trblho EVOLUÇÃO DE ESQUEMAS EM SGBDOOs Evolução de esquems sobre um esquem único Evolução de esquems no O Evolução de esquems no ORION Evolução de esquems no GEMSTONE Evolução de esquems no OBJECTSTORE Qudro resumo dos spectos de correção nos SGBDOOs estuddos Evolução de esquems utilizndo Versionmento 32 v

6 3 - SIGO Um visão gerl O modelo de objetos e o esquem conceitul Evolução de esquems Persistênci de objetos Ambiente de progrmção USO DE REGRAS ATIVAS NO TRATAMENTO DE EVOLUÇÃO DE ESQUEMAS NO SIGO Aspectos de Regrs Ativs Um visão gerl Semântic de regrs tivs Seleção d regr e o modo de coplmento Grnulridde do processmento de regrs tivs Arquiteturs e técnics pr monitormento de condições Efeito ds modificções do esquem sobre os objetos e métodos Modificções de tributos Modificções de clsses Modificções de objetos Modificções de métodos Especificção ds lterntivs e mecnismos utilizdos pr evolução d vi

7 bse de objetos Semântic de regrs tivs no SIGO Aderênci Conceitul o modelo de execução de regrs em BDs Ativos O Repositório de Regrs Ativs Orientdo Objetos (R2O2) DESCRIÇÃO FUNCIONAL DE MÉTODOS E FUNÇÕES Operções de modificção sobre objetos e métodos Operções específics de mnipulção do R2O Tbels de Conversão pr modificções de tributos AMBIENTE DO PROTÓTIPO DE IMPLEMENTAÇÃO Contexto d plicção Operções de evolução d bse de objetos no SHC CONCLUSÃO Contribuições Sugestões pr trblhos futuros Considerções finis 135 REFERÊNCIAS BIBLIOGRÁFICAS 137 APÊNDICE A - ESTRUTURA DO ARQUIVO DE MODIFICAÇÕES DO ESQUEMA ALT.DAT 142 vii

8 LISTA DE ILUSTRAÇÕES FIGURA Arquitetur ORION 19 FIGURA Um hierrqui de clsses com conflito de nomes 23 FIGURA Clsse VEÍCULOS 24 FIGURA Ctegoris e subctegoris de modificções de esquem 30 FIGURA Histórico de versões pr três objetos X, Y e Z em um BD 34 FIGURA Arquitetur do SIGO 38 FIGURA Definição de Objeto no SIGO 41 FIGURA Exemplo de um plicção SIGO 43 FIGURA Seleção d Clsse EMPREG e crição do tributo PROJETOS 44 FIGURA Seleção d Clsse PROJETO como elemento d List PROJETOS 44 FIGURA Definição d List PROJETOS pr o máximo de sete elementos 45 FIGURA Tbels representndo um esquem conceitul 48 FIGURA Ambiente de desenvolvimento de plicções 51 FIGURA Algoritmo pr o processmento de regrs 57 FIGURA Arquitetur Integrd pr BDs Ativos 61 FIGURA Arquitetur de Cmds pr BDs Ativos 62 FIGURA Inclusão do tributo dt_nsc pr clsse Pesso 66 FIGURA Exclusão do tributo dt_nsc d clsse Pesso 67 FIGURA Modificção do domínio do tributo projeto d clsse Funcionário 69 FIGURA Modificção de restrição sobre tributo slário d clsse Funcionário 71 FIGURA Modificção de crcterístic sobre o tributo endereço d clsse Pesso 72 FIGURA Inclusão d clsse Pesso como superclsse d clsse Professor 75 viii

9 FIGURA Retird d clsse Pesso d list de superclsses d clsse Professor 76 FIGURA Retird d clsse Funcionário do esquem do BD 78 FIGURA Migrção do objeto 0 4 d clsse Funcionário pr clsse Aluno 80 FIGURA Arquitetur do SIGO com suporte à evolução d bse de objetos 82 FIGURA Algoritmo pr processmento de regrs no SIGO 84 FIGURA Hierrqui de clsses do R2O2 pr operções sobre objetos 87 FIGURA Hierrqui de clsses do R2O2 pr operções sobre métodos 90 FIGURA Esquem conceitul e tbels d plicção SCH 115 FIGURA Objetos instncidos n clsse MÉDICO (Exemplo n o 1) 122 FIGURA Objetos instncidos n clsse MÉDICO (Exemplo n o 1) 122 FIGURA Objetos instncidos n clsse EXAME (Exemplo n o 2) 123 FIGURA Objetos instncidos n clsse EXAME (Exemplo n o 2) 123 FIGURA 6.6- Objetos instncidos n clsse MÉDICO (Exemplo n o 3) 124 FIGURA Objetos instncidos n clsse MÉDICO (Exemplo n o 3) 124 FIGURA Objetos instncidos n clsse PACIENTE (Exemplo n o 4) 125 FIGURA Objetos instncidos n clsse PACIENTE (Exemplo n o 4) 125 FIGURA Objetos instncidos n clsse PACIENTE (Exemplo n o 5) 126 FIGURA Objetos instncidos n clsse PACIENTE (Exemplo n o 5) 126 FIGURA Objetos instncidos n clsse PESSOA (Exemplo n o 6) 127 FIGURA Objetos instncidos n clsse PESSOA (Exemplo n o 6) 127 FIGURA Objetos instncidos n clsse EXAME (Exemplo n o 7) 128 FIGURA Objetos instncidos n clsse EXAME (Exemplo n o 7) 128 FIGURA Objetos instncidos n clsse EXAME (Exemplo n o 8) 128 FIGURA Objetos instncidos n clsse EXAME (Exemplo n o 8) 129 ix

10 FIGURA Objetos instncidos n clsse RESIDENTE (Exemplo n o 10) 129 FIGURA Objetos instncidos n clsse RESIDENTE (Exemplo n o 10) 129 FIGURA Objetos instncidos n clsse MÉDICO (Exemplo n o 12) 130 FIGURA Objetos instncidos n clsse PACIENTE (Exemplo n o 12) 130 FIGURA Objetos instncidos n clsse MÉDICO (Exemplo n o 12) 131 FIGURA Objetos instncidos n clsse PACIENTE (Exemplo n o 12) 131 x

11 LISTA DE TABELAS TABELA Aspectos de correção do esquem nos SGBDOOs: O 2, ORION, OBJECTSTORE e GEMSTONE 31 TABELA Conversões possíveis de domínio 111 TABELA Modificções possíveis de restrições 111 TABELA Modificções possíveis de crcterístics 111 xi

12 LISTA DE ABREVIATURAS E SÍMBOLOS ADB - Administrdor do Bnco de Ddos API - Appliction progrmming interfce BD - Bnco de Ddos BDOO - Bnco de Ddos Orientdo Objeto BLOB - Binry Lrge Objects CAD - Computer-ided Design CAM - Computer-ided Mnufcturing CASE - Computer-ided Softwre Engineering C/S - Cliente/Servidor ECA - Evento / Condição / Ação GSI - GemStone Smlltlk Interfce IA - Inteligênci Artificil ID_OBJ - Identificdores de Objetos IME/RJ - Instituto Militr de Engenhri no Rio de Jneiro LIDAS - Lingugem pr o Desenvolvimento de Aplicções LIMOS - Lingugem Intertiv pr Mnipulção de Objetos MACRO - Módulo de Armzenmento, Crição e Recuperção de Objetos MAME - Módulo de Aquisição e Modelgem de Esquem MCC - Microelectronics nd Computer Technology Corportion MORSO - Modelo em Rede Semântic Orientd Objetos OIS - Office Informtion System OO - Orientção Objetos / Orientdo Objetos xii

13 R2O2 - Repositório de Regrs Ativs Orientdo Objetos SCH - Sistem de Controle Hospitlr SGBD - Sistem Gerencidor de Bnco de Ddos SGBDOO - Sistem Gerencidor de Bnco de Ddos Orientdo Objeto SGBDR - Sistem Gerencidor de Bnco de Ddos Relcionl SIGO - Sistem Gerencidor de Objetos SQL - Structured Query Lnguge TAO - Tipos Abstrtos de Objetos xiii

14 CAPÍTULO 1 INTRODUÇÃO POSICIONAMENTO Ao contrário dos SGBDs relcionis (SGBDRs) (CODD,1970) que rmzenm pens ddos, os SGBDs Orientdos Objetos (SGBDOOs) rmzenm tmbém processos, sob form de métodos, plicções e/ou funções, umentndo complexidde pr mnutenção d consistênci do esquem do Bnco de Ddos (BD) em um mbiente dinâmico (MORSI,1992). Além disso, s clsses de um esquem Orientdo Objetos (OO) podem estr interrelcionds, trvés de composição ou hernç, possibilitndo gerção de esquems extensíveis. Por estes motivos, lterções em esquems de Bncos de Ddos Orientdos Objetos (BDOOs) podem cusr efeitos colteris em váris definições, lém de fetr objetos instncidos e execução de métodos eles ssocidos (PREVOT,1994). O prdigm d Orientção Objetos tem sido o mis dequdo pr modelr estruturs complexs no domínio de plicções não convencionis, tis como: CAD/CAM, CASE, IA, sistems bsedos em conhecimento e OIS (Office Informtion Systems) com documentos multimídi (BANERJEE,1987). Aplicções de BDs Não Convencionis requerem funcionliddes dicionis, tmbém pr mbientes de desenvolvimento, visto que o projeto de plicções em gerl, vem ser nturlmente intertivo, onde completez destes projetos pode requerer investigção de lgums lterntivs (KIM,1995). Porém, importânci d flexibilidde de modificr esquems durnte fse de especificção em mbientes de desenvolvimento, pode não ser mesm em mbientes de produção onde o desempenho sej fundmentl (KIM,1990). 1

15 Assim, lém d persistênci e comprtilhmento - dentre outrs crcterístics, dvinds dos SGBDs Convencionis e incorpords o mbiente OO (ATKINSON,1989) (KHOSHAFIAN,1993) (CATTELL,1994) - outro importnte requisito pr ests plicções é evolução de esquems, ou sej, hbilidde de executr dinmicmente um lrg vriedde de modificções sobre o esquem do BD, minimizndo necessidde de um reorgnizção em prol de um melhor desempenho do sistem (CATTELL,1991). Alguns SGBDOOs permitem o usuário modificr definição de clsses, muito embor vrindo considervelmente o nível de ssistênci oferecido pr o mnuseio dests modificções (LÈCLUSE,1989) (DEUX,1991) (FERRANDINA,1995) (ZICARI,1991) (KIM,1990) (XIDAK,1990) (OBJECTIVITY,1990) (PENNEY,1987) (GEMSTONE,1995) (OBJECTDESIGN,1990). Por exemplo, se um novo tributo é incluído pr um clsse de objetos: É necessário o usuário corrigir, explicitmente, todos os objetos existentes dquel clsse pr que tenhm o novo tributo? ; É possível incluir um nov superclsse qundo existem instâncis de um clsse? ; O que contece os progrms existentes que usm o ntigo esquem?. Existem, portnto, três implicções decorrentes de modificções em um esquem de ddos: (1) Modificções de progrms que usm o ntigo esquem; (2) Modificções ds instâncis existentes ds clsses modificds; (3) Efeitos ds modificções no restnte do esquem. A implicção (1) é extremmente substncil, porém, se for usdo encpsulmento restrito, em modificções feits somente pr tributos, os únicos progrms que necessitm 2

16 ser modificdos são queles ssocidos às clsses de objetos modificds (KHOSHAFIAN,1993). Outrossim, exclusão ou modificção d interfce de um método pode invlidr tnto o código existente em outr clsse de objetos, como tmbém modificr tributos não protegidos por encpsulmento, ou por lgum outro mecnismo de independênci de ddos. A miori dos SGBDOOs não oferece, té então, ferrments de ssistênci às modificções de progrms existentes qundo ocorrem tulizções no esquem. Contudo, cpcidde pr renomer, incluir e excluir proprieddes de tipos de objetos, bem como incluir e excluir os próprios tipos de objetos em tempo de execução ( run-time types ) são importntes requisitos, que vism prover ferrments e progrms Ad hoc pr executr trnsformções no esquem. Sem ests cpciddes de run-time types seri necessário definir estticmente o novo e o ntigo esquem trvés de um progrm genérico de trnsformção (CATTELL,1991) JUSTIFICATIVA PARA O TRABALHO Como foi visto nteriormente, s plicções não convencionis necessitm de spectos relciondos um mior dinmismo e que, por enqunto, somente OO é cpz de stisfzer estes requisitos de form mis simples e nturl. Assim, modificções em esquems de SGBDOOs tendem ser mis freqüentes do que em esquems de BDs Convencionis, pelo fto dos esquems gerdos por um SGBDOO serem extensíveis, isto é, por suportrem crição de novos tipos e operções (CATTELL,1991). Portnto, existênci de muitos inter-relcionmentos em um esquem e necessidde de modificções cd vez mis freqüentes fzem com que o suporte à evolução 3

17 de esquems em SGBDOOs sej necessário e muito mis complexo do que nos SGBDs Convencionis: relcionis, redes e hierárquicos (NAVATHE,1994) (SILBERSCHATZ,1994) (ULLMAN, 1989) (DATE, 1987). O processo de evolução de esquems inclui dois importntes spectos reltivos à consistênci intencionl e extensionl dos componentes do BD. Estes spectos são controldos por mecnismos que grntem integridde do BD como um todo. A prte intencionl é compost pelo esquem, onde está trduzid semântic d plicção pr o contexto do modelo de ddos utilizdo, e prte extensionl é compost pel bse de ddos, informções do mundo rel cptds de cordo com perspectiv do esquem (GUIMARÃES,1995). Ao serem confrontds plicções trdicionis com s não convencionis, é possível perceber que s primeirs póim-se num esquem prticmente fixo, enqunto s outrs, implicitmente, supõem um dinmicidde d modelgem d relidde, isto é, o possível surgimento de novos relcionmentos, novs composições etc., o longo d construção do esquem, ssim tornndo, freqüentes s lterções. Verificd necessidde de evolução d modelgem e, por conseguinte, do esquem é preciso grntir su correção o longo do processo evolutivo. Em (BANERJEE,1987) ests modificções são definids como o mpemento que lev um esquem de um estdo consistente S outro S', igulmente consistente. Assim, pós cd modificção introduzid, deve ser verificd correção do esquem. Aind em (BANERJEE,1987) são identificdos três spectos serem exmindos: o relciondo com estrutur do esquem frente o modelo que o sustent; o relciondo com s plicções sobre ele construíds; e o que envolve s instâncis obtids prtir ds clsses que s compõem. Deste modo são observdos os seguintes spectos de correção: 4

18 (1) Integridde Estruturl Refere-se à correção do grfo que represent o esquem, onde s clsses estão representds por rcos de especilizção / generlizção. Este specto é mntido trvés do estbelecimento de pré-condições, denominds invrintes do esquem. Ests invrintes são verificds pós cd lterção, e qundo stisfeits, ssegurm este specto de correção. (2) Integridde Comportmentl Refere-se à correção dos spectos comportmentis (métodos) ssocidos às clsses, ssegurndo que sus ssinturs possuem prâmetros com tipos existentes e corretos e que o vlor de retorno tem o tipo certo. De um form mis mpl, um BDOO é comportmentlmente correto se todos seus métodos produzirem o resultdo esperdo. Este specto é de difícil controle, pois tução do método tem um sentido semântico mplo. No entnto, mntendo-se um list de tributos e outr de métodos, é possível detectr, por exemplo, n oportunidde de redefinição de um tributo, quis métodos serão fetdos e lertr o projetist (detentor do completo domínio d semântic que se desejou trduzir no código). (3) Integridde de Instncição Aqui preocupção é que tods s instâncis, o menos qundo consultds, estejm de cordo com definição tul d clsse que tomm como bse. Neste cso pode não ser necessário mnter s instâncis constntemente tulizds, bstndo que sejm "vists" como tulizds. 5

19 Outr bordgem semelhnte encontrd em (PREVOT,1994), ind sobre os spectos de consistênci, present interessntes definições. Nest bordgem um esquem model mbs s prtes: estruturl e comportmentl do BD. Seus principis componentes são hierrqui de clsses e s ssinturs de métodos, que descrevem interfce de progrmção ds instâncis ds clsses. As clsses são os pontos de entrd no BD. Funções, plicções e tipos são tmbém prtes do esquem. Um bse é um coleção de instâncis (objetos e vlores) cujs estruturs e comportmentos estão definidos em um esquem. El está sempre relciond um único esquem, que descreve, podendo servir como definição estruturl e comportmentl de váris bses. Modificções de esquem podem implicr em lterções nos objetos que estiverem relciondos com prte do esquem onde foi feit mudnç. Já modificções de objetos não implicm em mudnçs no esquem. O desejdo é que mudnçs n prte estruturl e comportmentl não provoquem erros de execução, ou comportmentos nômlos de um método e/ou função e/ou progrm, ou outros tipos de situções imprevisíveis. A consistênci do esquem e d bse é estbelecid prtir de um clssificção em dois tipos: consistênci estruturl, que se refere à prte estátic do BD; e consistênci comportmentl, que se referem os métodos, plicções ou funções. Um esquem é estruturlmente consistente se e somente se: (1) hierrqui de clsses é consistente; (2) o conjunto de métodos é consistente; (3) cd nome dentro do esquem tem um regr de escopo bem definid. Um bse é estruturlmente consistente se e somente se: (1) os vlores dos objetos forem consistentes com o tipo d clsse que pertencem; 6

20 (2) os vlores de cd propriedde especificd forem consistentes com o tipo definido n clsse à qul estão ssocidos. Informlmente, um SGBDOO é comportmentlmente consistente se cd método, função e progrm, trvés de sus ssinturs e códigos, produzirem o resultdo esperdo. A ssintur de um método é utilizd pr verificr comptibilidde de tipo dos rgumentos do método dentro d hierrqui. Portnto, este tipo de verificção tmbém é prte do processo pr ssegurr consistênci estruturl. No entnto, verificção de ssinturs não é suficiente pr ssegurr consistênci comportmentl de métodos, de funções e de progrms. Existem referêncis dentro de seus códigos que podem se tornr inválids pós um lterção no esquem. Com isto, tis lterções podem resultr em comportmentos nômlos de lgums funções, progrms e métodos no tocnte à dependênci entre os mesmos. Por exemplo, remover um método pode tornr outros métodos inconsistentes, por estes referirem-se um método não mis existente, ou ind, porque o método que substituiu, por hernç, o método excluído, tem um ssintur incomptível com chmd o método. Inconsistêncis comportmentis nem sempre resultm em erros de execução. Podem existir métodos que, em conseqüênci de um lterção, tenhm um comportmento diferente do nterior à mudnç. É preciso ressltr que os conceitos de flh em um método (métodos com erros de execução) e de mudnç de comportmento de um método (métodos com resultdo diferente do esperdo) são distintos, no entnto, o termo gerl consistênci comportmentl é utilizdo em mbos os csos. Pr que o esquem e bse continuem estruturlmente consistentes, deverá ser grntido que: (1) não ocorrerão conflitos de hernç; (2) hierrqui de clsses deverá permnecer consistente; 7

21 (3) o conjunto de ssinturs de métodos deverá permnecer consistente; (4) bse de ddos deverá permnecer consistente com o esquem que descreve. Em (KIM,1990) s modificções dinâmics de esquems de BDs integrdos são dividids em dus dimensões: evolução sobre um esquem único, onde s modificções são diretmente executds sobre um único esquem lógico de BD, e evolução de esquems utilizndo versionmento, onde são crids versões do esquem referentes às modificções OBJETIVO DO TRABALHO A miori dos SGBDOOs comercilmente disponíveis trt pens d integridde estruturl do esquem, não permitindo modificções depois d bse instncid. Neste trblho, são trtdos os efeitos dests modificções sobre os objetos instncidos em um bse definid no mbiente do Sistem Gerencidor de Objetos - SIGO (MOURA,1995) (MOURAb,1995) (BARROS,1996). Este trtmento tem como objetivo grntir integridde de instncição do esquem d plicção, lém de su integridde estruturl e comportmentl, trvés do uso de regrs tivs. Pr obtenção deste resultdo, s efetivs modificções sobre o esquem d plicção são rmzends num hierrqui de clsses e, conseqüentemente, propgds os objetos instncidos, podendo resultr n crição, retird ou modificção destes objetos. Est propgção é feit trvés de métodos ssocidos às clsses e definidos como regrs tivs, estruturs cpzes de reconhecer eventos específicos que, sob determinds condições, executm lgums ções, seguindo o prdigm (ECA) EVENTO/CONDIÇÃO/AÇÃO (WIDOM,1996) (CERI,1994) (TANAKA,1995). Ests regrs são utomticmente tivds 8

22 por métodos de plicções que referenciem objetos e clsses durnte mnipulção do esquem. Em resumo, prtir d determinção d necessidde de suporte à evolução de esquems em SGBDOOs e do estudo de lguns spectos ssocidos, este trblho tem por objetivo, usndo regrs tivs, estender grnti de consistênci os objetos instncidos em um bse definid no sistem SIGO, durnte o processo de evolução de esquems ORGANIZAÇÃO DO TRABALHO O restnte deste trblho está orgnizdo d seguinte mneir: no cpítulo 2 é presentdo um estudo sobre evolução de esquems em SGBDOOs no tocnte os spectos específicos: evolução de esquems sobre um esquem único, e evolução de esquems utilizndo versionmento. Tmbém são presentdos mecnismos de evolução de esquems desenvolvidos nos seguintes SGBDOOs: O 2, ORION, GEMSTONE e OBJECTSTORE. No cpítulo 3 é descrito o Sistem Gerencidor de Objetos - SIGO, trvés de um visão gerl de su rquitetur, bem como crcterístics específics de modelgem, persistênci de objetos e mbiente de progrmção. O cpítulo 4 present propost deste trblho, ou sej, s lterntivs e mecnismos dotdos pr mnutenção d integridde de instncição, prtir ds efetivs modificções sobre o esquem d plicção, num hierrqui de clsses definid no SIGO. No cpítulo 5 é descrit funcionlidde de métodos e funções, especificds no cpítulo 4. 9

23 No cpítulo 6, os efeitos d propgção ds operções de evolução de esquems são presentdos trvés de lguns exemplos implementdos sobre o protótipo d plicção SCH - Sistem de Controle Hospitlr definid no mbiente SIGO. No Cpítulo 7 são finlmente presentds s conclusões do presente trblho, com sus principis contribuições e proposts de pesquiss futurs. 10

24 CAPÍTULO 2 EVOLUÇÃO DE ESQUEMAS EM SGBDOOs EVOLUÇÃO DE ESQUEMAS SOBRE UM ESQUEMA ÚNICO A independênci lógic de ddos em SGBDs sugere que o problem de modificção de esquems preç extremmente simplificdo. Porém est ind é mior questão, pesr d ntigüidde dos BD. Este problem não surgiu com s lingugens de progrmção, onde tipos crim ddos, em vez de ddos crirem tipos. Os SGBDOOs são suportdos por um modelo complexo e destinm-se às plicções ns quis mudnçs no esquem podem ser freqüentes, fruto de modificções n modelgem relizds pelo projetist e que implicrão em operções de correção sobre definição do esquem. Este processo necessit de meios que, integrdos o BD, possibilitem prototipção do comportmento do esquem frente às modificções. Em (BANERJEE,1987) é definid um txonomi pr modificção de esquems, bem como (ABITEBOUL,1988), (PENNEY,1987), (ZICARI,1991), tmbém definem txonomis similres. Podemos usr cd txonomi pr clssificr sistems de BDs conforme o tipo de modificção de esquem permitido, isto é, se s modificções permitids são em tempo de execução e se o sistem modific utomticmente instâncis ou progrms existentes. Embor pudessem ser fcilmente incluíds como outr modificção, s definições de relcionmentos não constm dests txonomis, visto que nos sistems de BD os relcionmentos são representdos como tributos. Alguns sistems permitem simplesmente modificr nomes, incluir e excluir proprieddes. O nome modificdo, bem como inclusão e exclusão de métodos tipicmente, 11

25 envolvem modificções pens pr o próprio esquem, já que em vez de nomes, identificdores são usdos pr referencir os tipos ds própris instâncis. A inclusão ou exclusão de tributos ou relcionmentos, muits vezes requer técnics mis sofisticds, porque normlmente espços são reservdos pr esses ddos em cd instânci. As modificções podem ter efeito sobre objetos existentes, lterndo-os imeditmente no momento em que o esquem é modificdo, ou pelo uso de um representção de tipo, que permit coexistênci de instâncis de objetos com diferentes conjuntos de tributos, ou relcionmentos, quer dizer, evolução de esquems utilizndo versionmento vist no item 2.2 deste cpítulo. Um lterntiv, denomind lzy updte, represent um form postergd de propgção dos efeitos sobre os objetos. Est lterntiv é mis difícil de implementr, ms útil por evitr um sobrecrg no tempo de modificção do esquem. Mis dinte, ests lterntivs serão discutids como um questão de implementção. ORION e seu sucessor ITASCA (ITASCA,1990), bem como o O 2 provvelmente possuem o mis sofisticdo trtmento de evolução de esquems dentre os SGBDOOs estuddos, suportndo mior prte ds modificções contids n txonomi definid em (BANERJEE,1987). Outrossim, um vez que modificções reltivmente complexs podem ocorrer em muits plicções, outr lterntiv seri o sistem propicir bos ferrments pr uxilir o usuário finl n trnsformção do esquem, dos objetos, e dos progrms, o invés de prover, incrementlmente, um evolução de esquems mis utomátic pr modificções contids n txonomi sugerid (CATTELL,1991). Conforme visto nteriormente, lguns utores sustentm que o esquem modific-se mis freqüentemente pr quels plicções em que os SGBDOOs são mis indicdos, 12

26 embor existm plicções em SGBDs Relcionis (SGBDRs) onde modificções de esquem sejm igulmente freqüentes. Em qulquer cso, evolução de esquems é um problem importnte e mis complexo em modelos de ddos vnçdos, por cus do número de crcterístics e ds possibiliddes de trnsformções de esquem nestes modelos. Em (CATTELL,1991) são definids qutro principis lterntivs de mnutenção de instâncis pr evolução de esquems: (1) Write-once type (tipos cridos um vez): lterntiv mis simples, que consiste em proibir s modificções no esquem, um vez que instâncis tenhm sido crids. Se um usuário desejr definir um novo tributo ou modificr clsse, um nov clsse deve ser definid e s instâncis ntigs copids pr est. Est lterntiv er dotd pelo SIGO, nteriormente este trblho; (2) Immedite Updte (tulizção imedit): como o nome sugere nest lterntiv mudnç do esquem fet imeditmente s instâncis existentes d clsse. Por exemplo, se um novo tributo é diciondo pr um clsse de objetos, todos os objetos dquel clsse são utomticmente tulizdos, recebendo um vlor null pr o tributo diciondo. Est lterntiv, dotd pelo OBJECTSTORE (OBJECTDESIGN,1990) e GEMSTONE (GEMSTONE,1995) é considerd mis comum entre os SGBDOOs. (3) Lzy Updte (tulizção postergd): est lterntiv, dotd pelo ORION (XIDAK,1990) e pelo O 2 (FERRANDINA,1995), consiste em retrdr s tulizções pr objetos de um clsse té que estes sejm referencidos. Qundo os objetos são recuperdos n memóri, um ssocição crescentd o objeto indic se este foi tulizdo pel últim definição. Se o esquem mudou - por exemplo, um tributo foi incluído - tulizção é feit, então, neste momento. Nest lterntiv, informção do histórico do esquem e conversão 13

27 de procedimentos deve ser mntid pelo SGBDOO, té que tods s instâncis d clsse modificd tenhm sido convertids pr nov representção. Em (HARRUS,1990) é presentdo um estudo sobre o desempenho lzy updte versus immedite updte. (4) Schem Mpping (mpemento de esquems): lterntiv mis extrem, que consiste em mnter um mpemento entre representção corrente ds clsses e tods s versões nteriores, retrdndo, indefinidmente, s tulizções pr objetos existentes, ou té que um reorgnizção sej explicitmente requisitd. Este mpemento requer mnutenção de múltipls versões de um esquem, o que permite os usuários diferentes visões de um mesmo objeto. Sistems como ORION e GEMSTONE provêem est funcionlidde. Hj vist su complexidde, est lterntiv é de difícil implementção pr os SGBDOOs. Gerlmente, pr modificções de esquems suficientemente complexs, todos os SGBDOOs tendem utilizr primeir lterntiv, definindo novs clsses e copindo s instâncis existentes. Alguns sistems podem mnipulr diretmente modificções simples, tis como inclusão ou exclusão de um tributo, de um relcionmento ou de um método e inclusão ou remoção de subclsses. Embor, de modo direto, em sistems como o ORION - que pode mnipulr tods s modificções d txonomi nteriormente presentd - vst miori ds modificções não cobert pel mesm txonomi, requer que o usuário desenvolv progrms pr crir novs clsses e executr trnsformções de ddos do esquem ntigo pr o esquem novo. Provvelmente, miori ds modificções de esquem do mundo rel irá requerer progrmção nos SGBDOOs e pesquiss dentre os mis sofisticdos lgoritmos de trnsformção de esquems. 14