----------------------- Page 1--------------------------------------------- Page 2----------------------UNIVERSIDADE PRESBITERIANA MACKENZIE FACULDADE DE COMPUTAO E INFORMTICA BACHARELADO EM SISTEMAS DE INFORMAO PERSISTNCIA DE OBJETOS

VIA MAPEAMENTO OBJETO-RELACIONAL CAMILA ARNELLAS COELHO REINALDO COELHO SARTORELLI So Pau o 2004 ----------------------- Page 3----------------------Cami a Arne as Coe ho Reina do Coe ho Sartore PERSISTNCIA DE OBJETOS VIA MAPEAMENTO OBJETO-RELACIONAL Traba ho de Graduao Interdiscip inar apresentado Faculdade de Computao e Informtica da Universidade Mackenzie como exigncia parcia para a conc uso do curso de Sistemas de Informao. Orientador: Prof. Dr. Luciano Silva So Pau o 2004 ----------------------- Page 4----------------------RESUMO Este estudo tem como objetivo apresentar as principais tcnicas de persistncia de o bjetos, com relevncia na tcnica de apeamento Objeto-Relacional ( OR). i

Atualmente, comum o uso de bancos de dados relacionais no meio corpo rativo, e da programao nvolvedores orientada a objetos nas aplicaes de interface. Os dese

frequentemente deparam-se com estes dois paradigmas diferentes: o modelo r elacional e o modelo de objetos. Uma maneira de se trabalhar com um paradigma orientado a objetos junto a SGBD re lacionais

justamente o propsito da tcnica de

OR.

O estudo de caso proposto apresentar um exemplo prtico de aplicao destes co nceitos, atravs da utilizao de um f ramework para a persistncia de objetos, o Obj ec t Relational Bridge (OJB). Pa avras-chave: , padres de projeto, OJB, JDBC. ----------------------- Page 5----------------------ABSTRACT The purpose of this work is to introduce the main current techniques of object p ersistence, with a special approach on the topic of Object-Relational apping (OR ). apeamento Objeto-Relacional, persistncia, impedncia

Nowadays, the Relational Databases still represent the majority of data storage facilities found on corporations. ogy of choice eanwhile, object-oriented programming is becoming the technol

for most applications. However, programmers often face two different paradigms: the Relational odel and the Object odel.

An elegant and productive way to circumvent this issue is the purpose of OR . It provides ways to keep RDB S and still use an object-oriented approach to the data.

A case study is presented as a practical approach of the implementantion of OR techniques, using an O/R framework known as OJB (Obj ect Relational Bridge) . Keywords: Object-Relational ns, OJB, JDBC. apping, persistence, impedance, design patter

----------------------- Page 6----------------------SUMRIO INTRODUO.......................................................................... .................................................9 CAPTULO 1 - O prob ema da persistncia de objetos.................................. .......................11 1.1. Persistncia de Dados................................................... ....................................................11

1.2. Persistncia em um contexto orientado a objetos......................... ....................................14 1.3. O descompasso objeto-relacional....................................... ..............................................18 CAPTULO 2 - Mecanismos de persistncia de objetos.................................. ......................21 2.1. Serializao de objetos.................................................... .................................................21 2.2. Persistncia em X L......................................... ..............................................................23 2.3. Bancos de Dados Estendidos (OR)........................................ ..........................................27 2.4. Bancos de Dados Orientados a Objetos................................... ........................................30 2.5. Outros mecanismos de persistncia de objetos............................. ...................................35 2.6. Conectividade entre o SGBD e aplicaes O.O. .............................. ...............................36 CAPTULO 3 - Mapeamento Objeto-Re aciona ......................................... ..........................39 3.1. Persistncia em SGBDR.................................................... ..............................................39 3.2. Conceitos bsicos de OR................................... ...........................................................42 3.3. Tipos comuns de OR...................................... ..............................................................44 3.4. Implementaes de Camadas de Persistncia.................................... ..............................51 3.5. Padres de apeamento Objeto-Relacional........................ ............................................56 3.6. Consideraes Finais....................................................... .................................................61 CAPTULO 4 - Estudo de caso: Object Re ationa Bridge............................. ......................63 4.1. Introduo................................................................. .......................................................63 4.2. Requisitos funcionais.................................................. .....................................................63 4.3. Estrutura da aplicao..................................................... .................................................64

4.4. Implementao.............................................................. ...................................................66 ----------------------- Page 7----------------------4.5. Comparativos........................................................... ........................................................70 CONCLUSES........................................................................ ..................................................76 REFERNCIAS BIBLIOGRFICAS.......................................................... ...........................78 ANEXO A: Script de criao do banco de dados........................................ ...........................81 ANEXO B: XML de conexo e mapeamento.............................................. ............................82 ANEXO C: Cdigo do estudo de caso................................................. ....................................86 ----------------------- Page 8----------------------LISTA DE ABREVIATURAS ADT/TAD API BLOB/CLOB CRUD FIFO IDE JDBC MOR/OR g OCI ODBC OD OID OO PBR SGDB SGDBOO G Abstract Data Type/Tipo de Dados Abstrato Application Program Interface Binary/Character Large Objects Create, Read, Update, Delete First In, First Out Integrated Development Environment Java Database Connectivity Mapeamento Objeto-Relacional/Object Relational Oracle Call Interface Open Database Connectivity Object Data anagement Group appin

Object Identifier Orientao a Objetos Persistence by Reachability Sistema Gerenciador de Bancos de Dados Sistema Gerenciador de Banco de Dados Orientado a Objetos

SGDBOR Estendido) SGDBR SQL U X XND L L

Sistema Gerenciador de Banco de Dados Objeto-Relacional ( Sistema Gerenciador de Banco de Dados Relacionais Structured Query Language Unified Extensible X odeling Language arkup Language

L Native Database

----------------------- Page 9----------------------LISTA DE FIGURAS Figura 1 16 Figura 2 21 Figura 3 24 Figura 4 28 Figura 5 40 Figura 6 45 Figura 7 47 Figura 8 48 Figura 9 48 Figura 10 49 Figura 11 57 Figura 12 57 Figura 13 58 Figura 14 59 Persistncia de objetos [extrado de WOL03]. Exemplo de Classe Pessoa. Representao dos dados em tabela. Representao em tabela de uma classe. Arquitetura de 3 camadas [extrado de IB 00]. Exemplo de OR (adaptao de [RAJ02; Fig. 5.2]).

Relacionamento 1:1. Relacionamento 1:n. Relacionamento n:n. Direcionalidade. Gateway Pattern [extrado de FOW02]. Active Record Pattern [extrado de FOW02]. Data apper Pattern [extrado de FOW02].

Herana de Tabela Simples [extrado de FOW02].

Figura 15 60 Figura 16 60 Figura 17 65 Figura 18 65 9

Herana de Tabelas Concretas [extrado de FOW02]. Herana de Classe e Tabela [extrado de FOW02]. Diagrama de Classes do estudo de caso. odelo ER do estudo de caso.

----------------------- Page 10----------------------INTRODUO Atualmente, as linguagens de programao orientadas a objetos (ou simplesmen te O.O.) possuem um papel importante enquanto paradigma de programao, tendo sua adoo em crescimento constante, tanto na indstria, quanto em meios acadmicos. Devido frequente necessidade das aplicaes de persistirem dados, para que possam recuperar a informao gerada por elas em novos processos, e de uma forma que seja possvel compartilh-la entre tipos de sistemas distintos, o uso de tcnicas de persistncia de objetos em SGBDR (Sistemas Gerenciadores de Bancos de Dados Relacionais), como o mapeamento objeto-relacional ( OR), ante para aplicaes tem se tornado um tema comum e relev

desenvolvidas utilizando a orientao a objetos. Aplicaes de mdio e grande porte, em geral, utilizam os SGBDR como principal meio de armazenamento de dados, devido principalmente aos sistemas legados, em detri mento da utilizao de Sistemas de Bancos de Dados Orientados a Objetos (SGBDOO), que ainda no atingiram um grau relevante de aceitao. No Captulo 1, conceitualiza-se persistncia de dados, principais sua importncia, os

mecanismos e os fatores envolvidos na persistncia de objetos. No Captulo 2, aborda

m-se os principais mtodos de persistncia de objetos, e finalmente, no Captulo 3, apresenta-se o mtodo de lema de OR, uma tcnica que tem como principal propsito contornar o prob mismatch, que

impedncia, mais conhecido pelo termo em ingls imp edance ocorre na

utilizao da programao orientada a objetos para persistncia de dados em bancos relacio nais. Em linhas gerais, pode-se dizer que, atravs das tcnicas de ssvel escrever OR, po

aplicaes de negcio em linguagens orientadas a objetos que persistam objetos em SGBD R, sem a necessidade da codificao de uma linha sequer de instruo SQL. As ferramentas d e MOR se encarregam de gerar e executar estas instrues, provendo transparnc ia entre a 10 ----------------------- Page 11----------------------aplicao (interface) e o mecanismos de persistncia (SGBD). Estamos utilizando o termo pp ing) para qualquer OR (ou OR - Obj ect-Relational Ma

camada de persistncia onde os comandos SQL so gerados automaticamente, a partir de uma descrio baseada em metadados (metadata) de mapeamento de objetos em relao s estrutura s relacionais (tabelas).

Alm da conceituao terica dos mtodos de persistncia de objetos - o tema centra deste trabalho com relevncia nas tecnologias de legados, OR para a utilizao dos SGBD

apresenta-se tambm uma aplicao prtica destes conceitos atravs da utilizao um arcabouo (f ramework) de persistncia de objetos utilizando lo 4). OR em Java (Captu

O f ramework em questo o OJB (Obj ect Relational Bridge), que utiliza o m apeamento objeto-relacional para atingir este objetivo: apresentar um mecanismo de persistn

cia de objetos transparente para como meio de a aplicao orientada a objeto utilizando SGBDR

armazenamento de dados. A escolha por este f ramework deve-se ao fato de ser um projeto de software livre, robusto, de fcil utilizao e de alto grau de aceitao pela comunidade J ava em geral. 11 ----------------------- Page 12----------------------CAPTULO 1 - O prob ema da persistncia de objetos A persistncia dos dados um fator de importncia fundamental para qualquer s istema que trabalhe e dependa de informaes e que, portanto, necessite de algum me canismo de armazenamento estvel para estas informaes. A persistncia de dados no paradigma da orientao a objetos envolve a persistn cia dos objetos. As linguagens orientadas a objeto tm como base o conceito de objeto enquanto elemento fundamental da linguagem. Neste captulo, aborda-se a necessidade da persistncia de dados nos sistemas, e os conceitos envolvidos na persistncia de objetos. Reserva-se uma ateno espec ial para o descompasso existente entre a linguagem relacional, utilizada nos SGBD, e as linguagens orientadas a objetos, isto , o problema da impedncia entre o modelo de dados e o m odelo de objetos do paradigma da orientao a objetos. 1.1. Persistncia de Dados Para explicar a persistncia de dados, ser primeiramente apresentada uma si tuao real, na qual seria de extrema importncia a existncia de um mecanismo de persistncia. Sup onha um sistema que mostre estatsticas em tempo real, onde seus valores passem por co nstantes

atualizaes na memria, e com estes dados, gera-se um grfico vital para a sobrevivncia de uma determinada empresa. Caso, porventura, a energia eltrica falhar, os dados con tidos no sistema (ou seja, imensurvel. Logo, a necessidade de persistncia de dados um requisito fundamental da m aioria dos sistemas, seja atravs de bancos de dados, arquivos de texto ou X que o retorno L, de forma na memria da mquina) se perdero. O prejuzo causado empresa ser

destes dados memria do computador, quando o estado normal do sistema estiver rest aurado, possa ocorrer, sem que haja perda de informao. 12 ----------------------- Page 13----------------------A persistncia de dados , portanto, uma forma de assegurar que os dados uti lizados e alterados em um determinado sistema sejam durveis, atravs da manuteno dos dados em u m meio de armazenamento estvel, que possibilite a restaurao posterior. A persistncia dos dados uma necessidade que existe desde os sistemas prim ordiais da

computao. Na evoluo dos depsitos de dados, as primeiras gravaes eram feitas em disco e fitas magnticas, utilizando-se de arquivos de texto puro. Quando havia a nec essidade da gravao de um grupo de dados, no qual se davam na maioria dos casos, separavam -se os campos atravs de algum caracter especial (como vrgula(,) ou ponto-e-vrgula(;), por exemplo), e demarcava-se um novo registro com o caracter especial de quebra de linha. A gr avao e recuperao era feita em ordem FIFO, ou seja, os dados eram recuperados na mesma ord em em que foram gravados. A necessidade crescente de gravar-se cada vez mais informaes em disco, par a que

pudessem ser recuperadas na medida da necessidade, seguida da necessidade da con sulta de informaes especficas de forma eficiente, mplexas de sem a necessidade de rotinas co

converses de formatos e inmeras operaes de I/O, trouxe-nos o que hoje conhecido como sistemas de bancos de dados. Bancos de dados podem ser definidos como depsitos ou repositrios, que contm dados, objetivando o armazenamento, a tas) e a disponibilizao de informaes (consul

manuteno. Basicamente, um banco de dados composto por quatro componentes [DAT00]: Hardware: meio fsico, composto por o primrio (memria) e secundrio (discos); Software: meio lgico, composto pelos programas que permitem a manipulao do s dados (as operaes CRUD: criao, leitura, atualizao e deleo); 13 ----------------------- Page 14---------------------- Dados: o elemento essencial do banco de dados, que caracteriza -o enquanto um sistema de informao; Usurios: agentes que interagem com o banco de dados, como pro gramadores, administradores de dados e usurios finais. Os SGBD (Sistemas Gerenciadores de Bancos de Dados) so sistemas que, em conjunto com os arquivos de dados, fornecem um ambiente conveniente para armazena r e recuperar informaes [SKS01]. Alguns representantes desta categoria so o SGBD da Oracle, o DB/ 2 da IB , entre outros. Eles passam no somente a se preocupar em gravar os dados em disco, mas tambm com o que est sendo gravado em disco, e isso trouxe mais uma n ecessidade a necessidade de se validar os dados gravados no banco de dados. dispositivos de armazenament

Alm disso, um SGDB deve ser capaz de lidar com acessos simultneos, atr avs de transaes. Os requisitos de um SGBD so descritos pelas propriedades AC D [SPE03]: , seja por erro de software ou hardware, toda a transao deve ser cancela da. ado Consistncia: O consistente, banco de dados deve manter-se em um est

Atomicidade: As transaes devem ser atmicas. Caso uma parte da transao falh

respeitando a integridade referencial. Iso amento: As transaes no devem afetar saes simultneas, ou seja, as transaes devem operar de forma isolada, sem int erferirem entre si. A Durabi idade: Refere-se garantia da ao prprio conceito de persistncia. a execuo de

outras tra

durabilidade dos dados feita atravs de logs de transao e backups do b anco de dados. 14 ----------------------- Page 15----------------------Ao contrrio dos sistemas primrios de persistncia de dados, um banco de dado s que possui estas propriedades pode assegurar no somente que os dados estaro per sistidos em disco, mas que sero gravados com valores vlidos e coerentes. Os sistemas de bancos de dados evoluram de sistemas de rede e hi errquicos aos chamados bancos de dados relacionais. Bancos de relacional, cujo dados na relacionais (SGBDR) lgebra so baseados Este tipo no modelo de abordag

fundamento encontra-se em permite o desenvolvimento de um dados so

relacional.

modelo lgico dos dados armazenados no banco. Os

armazenados em tup las, um conjunto de atributos, constitudos por domnio (tipo de dados) e valor (o dado em si). A definio de um domnio ou combinao de domnios que identifica individualmente enquanto a cada elemento da relao chamada de chave primria,

identificao da relao entre os itens nicos da tabela dada por uma chave estrangeira. Dados os conjuntos S1, S1, ..., Sn (conjuntos no necessariamente distint os), R uma relao destes n conjuntos, se for um conjunto de n-tuplas, onde o primeiro elemen to um elemento do primeiro conjunto (S1) , o segundo elemento do segundo conjunto (S1) , e assim por diante [COD70]. Relaes podem ser unrias, binrias, ternrias ou de ordem n. Estes so os conceitos bsicos por trs do modelo relacional, que caracteriza a tecnologia de persistncia de dados mais utilizada na atualidade, de maior maturidade, e que apresenta-se enquanto a justificativa da tecnologia de mapeamento objeto-relacional para a pe rsistncia de objetos neste tipo de modelo. Estes conceitos, por sua vez, sero abordados a segu ir. 1.2. Persistncia em um contexto orientado a objetos Antes da entrada no mbito da persistncia de objetos, apresentam-se alguns conceitos bsicos que caracterizam o paradigma da orientao a objetos. Alguns autores definem a programao orientada a objetos como uma programao de

15 ----------------------- Page 16----------------------tipos de dados abstratos (TADs) e seus relacionamentos [MUE97]. Um tipo de dado abstrato

constitudo por Dados, isto , a descrio de estruturas dos dados, e Operaes, que s sua interface e os mtodos de instncia. H dois tipos especiais de operaes:

o Construtor, que descreve as aes que sero tomadas a partir da c iao da entidade TAD

 o Destruidor, que so as aes executadas quando a entidade remov da memria. Na orientao a objetos, o conceito de TAD chamado de Classe. Objetos so abstraes alm de simples tipos de dados abstratos. Um obj eto uma instncia de uma classe, sendo constitudo por atributos (cuja implementao caracteriza uma varivel de instncia) com um determinado estado (conjunto de valores dos atributos em um determinado momento) e capaz de interagir com mensagens enviadas por outros obje tos atravs da implementao dos mtodos de sua classe. De forma geral, um objeto deve apresentar as seguintes caractersticas [FA S97]: Identidade: este o fator que distinge um objeto de outro objeto que possua o mesmo valor, ou o mesmo estado. Portanto, ela deve ser independente dos valores que o objeto possui. Estado: os valores de seus atributos em um determinado momento (variveis de instncia). Objetos podem passar por transies de estados ou manter o mesmo estado em todo seu ciclo de vida. Comportamento: uma abstrao que permite a interao com o objeto: o conjunto

de operaes de um objeto (a sua interface), as respostas destas operaes e as 16 ----------------------- Page 17----------------------mudanas que estas operaes podem causar ao objeto e a outros objetos do s istema. Toda interao com um objeto deve ocorrer atravs de sua interface. bjeto de outros objetos. Os atributos dos objetos geralmente so privados, cu jo acesso apenas Encapsulamento: a forma de ocultar-se os detalhes de implementao de um o

ocorre atravs dos mtodos pblicos do mesmo. O modelo de objetos da OMT (Obj ect Modelling Technique [RU 90], precursora da metodologia U apresentando os L), representa a estrutura esttica dos objetos de um sistema,

fatores que os caracterizam (identidade, estado, e operaes), alm dos relacionamento s entre os

objetos, descritos pelas associaes (ligaes potenciais), agregaes (relacionamento partetodo) e generalizaes (herana) [RIC96]. Um objeto pode ser transiente ou persistente. Um objeto transiente existe apenas na memria voltil durante a execuo do programa, sendo limitado ao tempo de vida do objet o que o instanciou. Quando o programa termina, o objeto deixa de existir. Persistncia, no contexto O.O., a capacidade de um objeto de manter seu e stado alm do ciclo de vida da aplicao. Normalmente, isto significa que o objeto deve ser gra vado em um meio de armazenamento estvel, para que possa ser recriado em um momento futuro. A persistncia possibilita que o objeto seja acessvel mesmo aps ter sido removido da m emria (Fig. 1). Fig. 1: Persistncia de obje tos [extrado de WOL03]. 17 ----------------------- Page 18----------------------Dado o conceito de objeto enquanto elemento fundamental de dados da ori entao a objetos, conclui-se que o problema da persistncia no se trata da persistn cia dos dados diretamente, mas sim da necessidade de desenvolvimento de mecanismos que possibi litem a 1 persistncia dos objetos, ou de todo o grafo de objetos , em seus estados originai s. Algumas das tarefas envolvidas para a persistncia de objetos incluem a n

ecessidade da gravao dos valores das variveis de instncia de um objeto, da converso dos ponteiros d e objetos em memria (as referncias aos objetos) em identificadores permanen tes e nicos (swizzling), e da ecurso raramente gravao dos mtodos da classe do objeto (um r

implementado pelos mecanismos de persistncia), de forma permanente. Swizzling o processo de transformao de identificadores permanente s do objeto (Obj ect D, ou simplesmente, OID) em endereos de memria [KRO99]. Na mai oria das linguagens O.O., ponteiros so uma forma de endereamento de memria, com v alidade limitada execuo do programa. Ao armazenar um objeto, os ponteiros de memria podem s er associados a um identificador permanente nico, vlido em todo o ciclo de vida d o objeto, estando em memria ou no. Este o mtodo utilizado pelos SGBDOO para mant erem referncias nicas a respeito de cada objeto armazenado. chamado Na terminologia chave. A relacional, o identificador de objetos SG

determinao de OIDs simplifica a estratgia de chaves na utilizao de um BDR, e possibilita a replicao de objetos. Um OID no deve ser associado a nenhuma regra de negcio, e deve ser nico na hierarquia de classes, e preferencialmente, entre todas as cla sses [AMB98]. O objeto deve manter sua identidade mesmo se houver alterao de todos seus mtodos e variveis de instncia [SKS01].

A estratgia de gerao do OID no deve ser proprietria (levando-se em conta a portabilidade, confiabilidade e manuteno da aplicao) e no deve ser tarefa do mecanism o de persistncia (do SGBD, por exemplo). 1 Ou hierarquia de composio [SKS01], refere-se a objetos que so compostos de outr os objetos (complexos).

18 ----------------------- Page 19----------------------H diversas opes para se efetuar a persistncia de objetos, mas muitas delas ainda so tecnologias bastante recentes, sem histrico de sucesso e/ou de baixo ndice de adoo, como os bancos de dados O.O. e os bancos de dados baseados em X L.

Atualmente, a tecnologia mais utilizada para este fim para aplicaes corpor ativas ainda so os sistemas gerenciadores de bancos de dados relacionais (SGBDR). Uma forma ef iciente de se utilizar SGBDR com orientao a objetos o mtodo de ntado com mais detalhes nos captulos seguintes. 1.3. O descompasso objeto-re aciona nas Grande parte utiliza a do desenvolvimento como principal de aplicaes de negcio moder OR, que ser aprese

tecnologia O.O., mas mantm s de dados relacionais.

meio de persistncia os banco

Enquanto o paradigma da orientao a objetos baseado em princpios provados pe la engenharia de software, cpios matemticos, o paradigma relacional baseado em prin

especificamente em teoremas da lgebra relacional. Por consequncia das diferenas entre os dois modelos, h uma dificuldade do p onto de

vista tcnico para a implementao rpida e descomplicada de aplicaes que envo vam programao em linguagem O.O. e o armazenamento de informaes em um SGBD relacional. Este um problema to recorrente que j recebeu um nome: " mp edance Mismatch" [A B02]. Como foi visto anteriormente, os dados em uma abordagem O.O. so represent ados por objetos, incluindo os valores dos atributos e as operaes do objeto.

H uma diferena de representao: os objetos so referenciados em memria, enquant

os dados so referenciados por chaves em tabelas, que existem fisicamente. Alm disso, os objetos possuem campos multivalorados, ao contrrio do modelo relacional, ond e os dados devem ser atmicos. 19 ----------------------- Page 20----------------------O modelo relacional apresenta uma forma bem distinta de representao de dad os. No modelo relacional, os dados so representados por tup las, ou registros de uma tabela, e no apresentam comportamento associado a eles. A CRUD (recuperao e atualizao de dados), permitindo que tabelas sejam combinadas para expre ssar o relacionamento entre os dados. Pode-se colocar o problema da seguinte forma: com a diferena entre as abo rdagens, o programador dever aplicao programar em duas linguagens diferentes. A lgica da linguagem SQL o padro adotado pelos SGBDR para operaes de

implementada utilizando uma linguagem orientada a objetos, enquanto utiliza-se a SQL para criar e manipular dados no banco de dados. Quando os dados so recuperados do ba nco de dados relacional eles devem ser traduzidos para a representao especfica da linguage m O.O. Os bancos relacionais apresentam algumas limitaes em termos de modelagem . Em SGBDR, no h o conceito de instncia, comportamento e herana. Tambm h questes de performance, quando muitas junes so necessrias para representar um objeto, alm do prprio descompasso semntico em relao s linguagens O.O.: h um conjunto limitado de tipos de dados no banco relacional, e um nmero infinito de classes em potencial. Estes, entre outros fatores, tem como consequncia o descompasso entre os modelos.

Se a arquitetura do sistema no est alinhada ao modelo de dados, a produtiv idade afetada, em virtude da necessidade de disp-la em camadas e de se criar uma interf ace entre elas, o que no ocorreria se o mesmo modelo de dados fosse adotado por ambas aplic aes. Alguns autores afirmam que a diferena cultural entre os programad ores O.O. e os DBAs mais relevante que a questo tcnica, j que as preocupaes de modelagem possuem a mesma essncia [A ode ser B03]. Um dos argumentos de que qualquer modelo relacional p

modelado por objetos, e de que, com um projeto adequado e uma estruturao cuidadosa do sistema, tudo pode ser encapsulado [ 20 ----------------------- Page 21----------------------Entretanto, a realidade de muitos sistemas diferente: o modelo de dados j se encontra em produo h um perodo de tempo considervel, e as empresas que dependem do mesmo dificilmente se disporiam a alter-lo para atender aos novos paradigmas de desenvo lvimento, devido a questes de investimento e risco, entre outras. vo da Uma proposta tcnica de de integrao entre os dois modelos o objeti UL99].

Mapeamento Objeto/Relacional ( lham para transformar

OR). Os mecanismos de

OR traba

uma representao de dados em outra, atravs de tcnicas de traduo entre os d ferentes esquemas de dados, para, enfim, lidar com este descompasso em situaes onde a utili zao de um banco de dados orientado a objetos no uma opo. 21 ----------------------- Page 22----------------------CAPTULO 2 - Mecanismos de persistncia de objetos No captulo anterior, foram apresentados os conceitos bsicos da m

etodologia de orientao a objetos e a importncia da persistncia dos objetos. Procurou-se demonstrar o problema do descompasso de impedncia entre a utilizao de uma linguagem est ruturada, como a SQL, do lado do banco de dados, e de uma linguagem orientada a objetos pa ra acesso e processamento dos dados armazenados em um banco relacional. Enfim, a importncia d e se alinhar a arquitetura do sistema com a arquitetura dos dados. Existem diversas tecnologias que permitem a persistncia de objetos. Nest e captulo, sero apresentadas as principais delas, iniciando pelo mtodo de serializao de objet os, em seguida pelo armazenamento em arquivos XML, passando pelas tcnicas de persistnci a de objetos implementadas pelos SGBDOR e SGBDOO atuais e as principais bib liotecas de conectividade (JDBC/ODBC) entre a interface O.O. e o banco em questo. 2.1. Serializao de objetos Quando trabalha-se com orientao a objetos e necessita-se da persistnci a de certos objetos de um determinado sistema, depara-se com o seguinte problema: como recuperar o objeto persistido de forma a reconstitu-lo em seu estado na memria? Para exemplificar, considere um simples aplicativo de agenda telefnica. Um modelo possvel de objeto para este sistema est representado abaixo (Fig. 2): < < persistent > > Pessoa + + Nome Telefone getNome() getTel()

Fig. 2: Exemp lo de Classe Pessoa. 22 ----------------------- Page 23-----------------------

A forma mais simples de se realizar a persistncia destes dados seria atra vs da gravao dos mesmos diretamente em disco, em um formato de arquivo sequencial ( f lat-file ). Assim, preciso levar em considerao o formato em que ser armazenado cada atributo do objeto , para que seja possvel recuper-lo depois. Dependendo do grau de complexidade do objeto ( como referncias a outros objetos e tipos de dados complexos), muito esforo ser necessrio tanto na gravao quanto na reconstituio do objeto persistido desta forma. Para evitar este esforo de desenvolvimento de funes especficas de persis tncia e restituio de objetos, izam bibliotecas de as linguagens orientadas a objeto disponibil

serializao de obj etos (como o caso de Java, C++, etc). O mtodo de serializao, ou linearizao, essencialmente transforma um objeto (o u o grafo do objeto que compe seu estado) em um fluxo de dados (mais especifi camente, um stream de bytes), e grava este fluxo em disco. Para recuperar este objeto, efetu a-se a operao inversa. As classes de serializao se encarregam em reconstituir o objeto automatic amente no mesmo estado em que foi armazedo, incluindo o estado de objetos nele contidos ou por ele referenciados [QUA00]. Em Java, um objeto deve implementar a interface java.io.Serializable p ara poder ser armazenado desta forma [ECK02]. Esta interface no possui mtodos ou campos a serem im plementados, pois seu propsito apenas identificar os objetos que podem ter s eus estados serializados ou desserializados. A maioria das classes da biblioteca Java implementa m esta interface diretamente ou por herana. Campos estticos ou transientes no so se rializados automaticamente, por no constituirem parte da instncia.

Para cada definio de classe calculado um nmero de srie, ou nmero de vers

que identifica cada objeto para a restaurao posterior [FLA97]. Esta estratgia de persistncia a forma mais simples e direta de persistncia de objetos.

Entretanto, a simples serializao no permite operaes mais complexas como a alterao do 23 ----------------------- Page 24----------------------objetos da aplicao. Se o objeto receber mais um atributo, como o nmero do celular por exemplo, a leitura do objeto serializado retornar erros, pois seu nmero de srie ser alterado. Alm disso, a gravao de objetos em arquivos sequenciais (f lat-f i le) causam um detrimento na performance, devido necessidade de acessos constantes ao disco. Eventuais falhas no processo podem resultar em um arquivo corrompido, e portanto, na perd a dos dados. Por ltimo, uma possvel aps reconstituio em de ser altamente pesquisa a memria nos de objetos armazenados desta forma s que po

todos os objetos

serializados, o

ineficiente, considerando um volume grande de registros. 2.2. Persistncia em XML A persistncia de dados em X no contexto de aplicaes Web, devido ao fato do formato X te um padro de documentos para a troca de dados na Internet. A linguagem X de marcao L (Extended Markup Language) derivada da linguagem L um recurso cada vez mais utilizado L estar se tornando rapidamen

de textos SGML (Standard Generalized Markup Language), que tambm originou a ling uagem de marcao HT dro X L tem como propsito ser uma forma simples de identificao de dados, que pod L (Hyp ertext Markup Language) [W3C04].

XML nada mais que uma abordagem padronizada para a descrio de dados. O pa

e ser interpretada tanto por pessoas, devido flexibilidade de seus atributos, quanto por mquinas, devido estruturao lgica de seus componentes. A linguagem X estruturas de L pressupe dois conceitos bsicos: a utilizao de correto destas estruturas de forma

marcao (tags) e o aninhamento hierrquica (wellf ormedness).

Considere a classe utilizada no exemplo anterior. Uma forma possvel de r epresent-la 24 ----------------------- Page 25----------------------em um formato X <agenda> <pessoa id=1> <nome>Silva Nunes</nome> <tel>11-123-456</tel> </pessoa> </agenda> O mapeamento entre o X a a objetos, um L e um objeto, em uma linguagem orientad L seria:

processo relativamente simples. O elemento raz, no caso Agenda, representa o nome da classe principal, enquanto os elementos filhos representam os objetos Pessoa com s eus respectivos atributos, Nome e Telefone. Seguindo basicamente o mesmo princpio, seria possvel m apear o mesmo X L em um modelo relacional [WIL00], com est exemplificado na Fig. 3. id 1 nome tel Silvia Nunes 11-123-456

Fig 3: Rep resentao dos dados em tabela. Alm do documento X scritor de L, muitas vezes utiliza-se tambm um arquivo de

tipos DTD (Document Type Def inition), que inclui a definio dos tipos de dados de cada elemento (texto, numrico, etc.), ou, em implementaes mais recentes, um arquivo desc

ritor de esquema , o chamado X L para a definio L Schema, que utiliza o prprio formato X

dos tipos. Estes arquivos so necessrios para o mapeamento dos atributos em bancos de dados tradicionais, como ser visto adiante. A persistncia de objetos em formato X da serializao: L segue o mesmo princpio

uma classe se encarrega em converter os dados para um arquivo com formatao X L (ao invs de um simples fluxo de dados) e estes dados so em seguida gravados em um arqu ivo no disco. Para a recuperao do objeto, a classe deve fornecer mecanismos de mapeamento entre os 25 ----------------------- Page 26----------------------atributos do objeto no estado em que foi armazenado para um objeto utilizvel na l inguagem de programao. As vantagens do uso do formato X simplicidade L na persistncia dos objetos, alm da

inerente desta tecnologia, est no fato deste formato basear-se em um padro bem def inido de arquivos de texto puro, com adoo cada vez maior da indstria de modo geral. Outra vantagem deste tipo de persistncia de dados est no fato dos atributo s dos objetos no serem mais mantidos em um um formato formato binrio de arquivo, mas sim em

estruturado que pode ser lido por humanos, o que torna a aplicao muito mais flexvel . Este mecanismo tambm permite a recuperao de objetos com verses dife rentes, possibilitando desta forma a recuperao de objetos, mesmo aps terem sido alte rados pelo aplicativo (como a adio de atributos, por exemplo), da mesma forma que uma verso an terior do aplicativo tambm capaz de recuperar objetos armazenados em um padro novo.

Os recursos do mecanismo de persistncia em X acordo com a

L podem variar de

biblioteca utilizada para o processamento e persistncia utilizando este padro de documentos nas linguagens orientadas a objeto. o X A tecnologia X L), L engloba aspectos de armazenamento (o prprio document

metadados (esquemas e DTDs), linguagens de consulta, como a Xquery, e interfaces de programao, como SAX, DO e XSLT [WIL00].

Alguns exemplos de bibliotecas relativamente simples de persistncia de dados em X L na linguagem Java so: JDO est prevista , cuja integrao nas bibliotecas da linguagem

para a verso 1.5; Castor, uma iniciativa do projeto Apache para disponibilizar e ste recurso s aplicaes o Apache Java, alm de Xerces e Xalan, tambm integrantes do projet

[http://www.apache.org]. Por outro lado, as desvantagens de mtodos de persistncia baseados em X L so as mesmas de se utilizar simples arquivos de texto armazenados em disco: a integridade dos 26 ----------------------- Page 27----------------------arquivos pode ser afetada se houver falhas no processo de gravao em disco e os ace ssos ao disco afetam a performance do sistema. Tanto o mtodo de serializao quanto a persistn cia em X L, no fornecem nenhuma forma de controle de transaes e/ou integridade de dados. L para minimizar estas d

H algumas propostas de bancos de dados X esvantagens. Elas

dividem-se basicamente entre o suporte dos SGBDR atuais ao formato, e os chamado s bancos de dados X rtao e L nativos (ou XND).

Alguns sistemas SGBDR mais recentes j apresentam a funcionalidade de impo

exportao de dados no formato X to X L

L [WIL00]. Geralmente os dados de um documen

so mapeados no banco de dados relacional atravs do relacionamento de um dete rminado elemento com uma coluna especfica de uma tabela. Este mtodo pode no garantir que o documento X iamente. L retornar exatamente da mesma forma como foi armazenado prev utilizam objetos BLOB [Binary Large

Alguns bancos simplesmente Objects] para o

armazenamento de XML. Ressalta-se tambm que a abordagem dos SGBD tradicionais par a o padro XML altamente dependente das extenses proprietrias de cada fabricante. O banco de dados DB/2 da IB chamado DAD , por exemplo, utiliza um esquema XML L ser map

(Document Access Def inition) que define como cada atributo X eado no banco de

dados, incluindo informaes de tabela, coluna e, opcionalmente, a definio do relacion amento entre tabelas (por uma chave primria ou estrangeira) relativas a cada elemento. O conceito de mapeamento de dados em bancos relacionais ser visto com mais detalhes nos captulos seguintes. J a tecnologia de bancos de dados XML nativos, ou XND, por sua vez, tem como principal propsito amento quanto na trabalhar com o formato X L tanto no armazen para

recuperao dos dados, sem a necessidade de um mapeamento posterior uma outra estrutura de dados.

Um XND define um modelo lgico para armazenamento e recuperao de documentos 27 ----------------------- Page 28----------------------X L. O documento X zenamento, da L consiste em sua unidade lgica fundamental de arma

mesma forma que uma tup la de uma tabela a unidade fundamental de armazenamento

em bancos de dados relacionais. Esse tipo de modelo fsico de sistema no apresenta um

armazenamento em particular, podendo utilizar um banco orientado a objetos, rela cional, ou mesmo um banco de dados hierrquico. Em geral, utiliza-se um formato p roprietrio de armazenamento. A aplicao deste tipo de soluo adequada para dados centrados em documentos , semi-estruturados, que possuem uma estrutura complexa com diversos aninham entos como

captulos de um livro, informaes mdicas, entre outros ao contrrio de aplicaes centr em dados, como ordem de vendas, dados de consumidores, dentre outras. 2 3 Alguns exemplos de bancos X Yggdrasill , Excelon . Outro tipo de mas de portal aplicao que de se enquadra 1

L nativos existentes: Tamino , nesta categoria so os siste

gerenciamento de contedo, que utilizam X de dados.

L como meio de armazenamento

A tecnologia existente, entretanto, ainda no implementa recursos para garantir a performance e a disponibilidade semelhantes aos recursos existentes nos bancos de dados tradicionais, e as extenses X e de concorrncia e L que permitem as consultas, control

transaes, por exemplo, ainda no se apresentam bem definidas. 2.3. Bancos de Dados Estendidos Como foi visto anteriormente, novos recursos tm sido integrados aos SGBD R, como o suporte a arquivos X dores de bancos de dados comerciais tm necessidades do paradigma O.O.. Os chamados bancos de dados objeto-relacionais (SGBDOR) nada mais so que bancos L e a linguagens O.O.. Os principais desenvolve mantido esforos para adaptar seus sistemas s

1 2 3

Software AG: http://www.softwareag.com/ edia Fusion: http://www.mediafusion-usa.com/ eXcelon: http://www.objectstore.net/ 28

----------------------- Page 29----------------------de dados relacionais estendidos com estas novas funcionalidades. Os SGBDOR trazem a vantagem da robustez e tradio dos SGBD tradicionais, c omo o suporte a processamento rana e todas as paralelo, replicao, alta-disponibilidade, segu

propriedades ACID (Atomicidade, Consistncia, Isolamento, Durabilidade). Algumas das caractersticas dos bancos estendidos incluem a extenso dos tipos de dados bsicos (CREATE TYPE no Oracle, por exemplo), encapsulamento e herana de tipos, suporte a objetos complexos e colees, suporte a mtodos definidos pelo usurio (proced ures), regras e triggers, alm do suporte a novos tipo de dados, incluindo a pesquisa aos mesmos. Enfim, o suporte linguagem SQL3 (atualmente conhecida como SQL-99) [ UL99]. Desta forma, os SGDBOR permitem o armazenamento de objetos utilizando o modelo relacional, como apresentado na Fig. 4. Pessoa - Nome Tabela - Telefone Pessoa Fig 4: Repr esentao em tabela de uma classe. A linguagem SQL-99 a proposta ANSI/ISO para substituir al SQL-92. A o atu

principal novidade da nova verso o suporte a estas estruturas OR. A idia bsica perm itir a criao de tipos de dados estruturados pelo usurio (alm de tipos abstratos, tipos dist intos e

rowtyp es), o que seria a aproximao da orientao a objetos, e de funes definidas tamb

pelo usurio. Alm disso, especificao da novos tipos de dados bsicos foram includos na

linguagem. Alm dos tipos CHAR, FLOAT, DATE, etc., novos tipos de dados in cluem o suporte a objetos BLOB, que representam dados multimdia, e CLOB (Charac ter Large 29 ----------------------- Page 30----------------------Obj ects), entre outros. Os tipos de objetos ou tipos de dados estruturados definidos pelo usurio permitem o mapeamento do modelo de dados de um objeto diretamente para um esquema de banco de dados objeto-relacional, o que evita a necessidade de reestruturao do modelo de da dos em um formato linha-coluna de tabelas relacionais, e assim evita-se tambm a nec essidade de inmeros relacionamentos (JOINS) entre tabelas para possibilitar a representao do obje to. [EI Um tipo estruturado, definido pelo usurio, pode ter os seguintes aspectos 99]:

A comparao de valores pode ser feita apenas por funes definidas pelo usurio; Podem ter um ou mais atributos, que podem ser um dos tipos pr-definidos ou de outros tipos estruturados; Todos os aspectos de seu comportamento podem ser descritos por mtodos, fu nes e procedimentos; Podem participar de zados (sub-tipos) hierarquias de tipo, onde tipos especiali

possuem todos os atributos e rotinas associadas aos tipos mais general izados (supertipos), e ainda assim podem definir novos atributos e rotinas; Seus atributos so encapsulados. Os objetos complexos englobam referncias a outros objetos, colees (set, bag

, list e arrays), colunas com tipo definido pelo usurio e tabelas aninhadas. O acesso aos atributos dos tipos definidos pelo uncional (ob eto usurio pode ser feito tanto atravs da notao f

(atributo)) quanto pela notao por ponto (ob eto.atributo). Outra caracterstica do SQL-99 a incluso de novos predicados de pesquisa, e ntre eles o e predicado S M LAR, o predicado que permite a utilizao de expresses regulares

30 ----------------------- Page 31----------------------D ST NCT, que similar ao UN QUE, diferindo na forma em que lida com valores nul os. A tendncia atual de que os sistemas de bancos de dados relacionais passem a adotar estas extenses para trabalharem com novos tipos de dados, como dados geogrficos e imagens, alm de adaptarem-se aos novos paradigmas de programao. Um SGBDOR deve permitir omplexos utilizando o padro SQL, mantendo as regras do modelo relacional. Atualmente, os principais bancos de dados j adotam um modelo objeto-relac ional, entre eles o DB/2, da IB ceito de extenses , que trabalham com objetos utilizando o con a busca, acesso e manipulao de dados c

relacionais (Relational Extenders), o Informix, com o conceito de lminas de dad os, e o Oracle (8x e 9x), da Oracle, com o conceito de cartuchos. Infelizmente, no h uma padronizao definida para estes sistemas, apesar de mu itas propostas [STO90; DAT95]. Enquanto os desenvolvedores no adotarem um padro na abordagem objeto-relac ional,

haver uma dependncia do usurio nas solues especficas e extenses proprietrias distribuidores da aplicao, o que pode prejudicar a portabilidade e escalabilidade

da aplicao. Alm disso, os SGBDOR atuais no implementam muitas das caractersticas descritas acim a, ou implementam de forma ainda muito rudimentar. 2.4. Bancos de Dados Orientados a Objetos Os bancos de dados orientados a objetos adicionam a persistncia para linguagens orientadas a objetos de forma transparente, ao contrrio dos outros mtodos. Eles pe rmitem o acesso aos dados diretamente atravs de objetos. Sendo assim, no h a necess idade de se reconstituir os objetos pela , elimina-se a linguagem de programao. Da mesma forma

necessidade do cdigo adicional para efetuar persistncia de objetos ao se utilizar este tipo de armazenamento. No h descompasso de impedncia: o que armazenado exatamente o 31 ----------------------- Page 32----------------------mesmo que ser recuperado posteriormente. Alguns autores definem os bancos de dados orientados a objetos como banc os de dados de Terceira Gerao. Os antigos bancos de dados Hierrquicos e de rede enquadrariam-se na primeira gerao, e os bancos relacionais na segunda. Algumas propostas foram feitas para definir o que caracterizaria realmente um banco de dados O.O., ou de terceira ge rao, e abaixo apresentamos uma das propostas preliminares, mantida como referncia sobre o assun to. Um banco de dados O.O. deve satisfazer basicamente dois critrios [ATK89]: 1) O banco deve caracterizar-se enquanto um SGBD, implementando os seguintes recursos: Persistncia: O objeto deve ser capaz de sobreviver fora dos limites da aplicao

que o criou. Este recurso equivalente definio de durabilidade nas pro priedades ACID. Gerenciamento de memria secundria: Este recurso inclui o gerenciamento de ndices, clusters de dados, buff ers e otimizao de consultas ( queries). Enfim, recursos de performance em geral. Estes fatores devem ser invisveis ao usurio, isto , deve haver uma independncia entre o modelo fsico e lgico do sist ema. Concorrncia: Deve permitir o acesso simultneo aos dados e prover mecani smos (como locks de acesso) para que os dados sejam mantidos em um esta do ntegro mesmo sendo acessados concorrentemente. Este recurso o equivalente definio de atomicidade das propriedades ACID. To erncia a fa has: Em caso de falhas de software ou hardware, o siste ma deve fornecer mecanismos de recuperao, isto , de retorno a um estado coeren te de dados. 32 ----------------------- Page 33---------------------- Queries ad-hoc: O sistema deve permitir alguma forma de consulta de alto nvel base de dados, efetiva em qualquer SGBDOO (independente de aplicao). 2) O banco deve caracterizar-se enquanto um sistema O.O., apresentando: Suporte a objetos comp exos: Construtores aplicados a tipos simples de objet os representam objetos complexos, e estes devem ser ortogonais (aplicveis a qua lquer objeto). Entre eles esto os construtores de tupla, que representam as propri edades de uma entidade, set, list e bag. Identidade: Cada objeto deve apresentar um identificador de objeto (OID) nico,

que deve ser persistente. Dois objetos podem compartilhar componentes , sendo assim atualizaes nos componentes devem refletir em ambos. Encapsu amento: ao los apenas acessveis pelas operaes (ou mtodos) do objeto. Tipos e c asses: O suporte a mecanismos estruturados de dados, sejam tipos o u classes (dependendo da abordagem da linguagem), fundamental. Este con ceito substitui o esquema dos bancos de dados tradicionais pelo conceito de conju nto de classes ou tipos. Hierarquias de c asses ou tipos: O conceito de herana (simples) um requisito fundamental de um SGBDOO. Sobrecarga e late binding : O polimorfismo implementado atravs de mtodos de sobrecarga e sobrescrita. Late binding necessrio para que a linguagem seja c apaz de associar, em tempo de execuo, a mensagem enviada a um objeto a seu respectivo mtodo. 33 ----------------------- Page 34---------------------- Extensibi idade: A linguagem deve apresentar mecanismos de definio de n ovos tipos pelo usurio, alm de tipos pr-definidos. Comp etude computaciona : Refere-se executar s do prprio SGBD. Opcionalmente, ecursos: herana um banco O.O. pode implementar os seguintes r capacidade do sistema de Distino entre especificao (interface) e implement

(estado). Em geral, o encapsulamento deve envolver os dados de forma a mant-

qualquer funo computvel, utilizando-se da linguagem de manipulao de dado

mltipla, verificao de tipos, distribuio de dados, definio de transaes pelo usur controle de verses [ATK89]. De uma forma geral, as propostas de definio de Bancos de Dados de Terceira Gerao concordam com , funes, a necessidade da implementao dos aspectos de herana

encapsulamento e tipos estendidos para que um banco de dados possa ser caracteri zado como orientado a objetos. Os SGBDOO armazenam os objetos incluindo seus atributos (dados) e opcion almente, os mtodos de acesso aos dados. O relacionamento nos Bancos de Dados Orientados a Objetos so dados por um conjunto de vnculos entre os objetos, incluindo as multiplicidades padro um-para-um, um-para-muitos e muitos-para-muitos, por meio de OIDs internos. Os b ancos de dados Orientados a Objetos em geral baseiam-se nas colees e iteradores para operar em com relacionamentos entre objetos.

As operaes de relacionamento de objetos, portanto, operam sobre colees. Set

representao tpica de colees de objetos: uma coleo no-ordenada de objetos ou literai

onde no se permite duplicaes. Bag uma coleo no-ordenada de objetos ou literais qu pode conter duplicaes. List uma coleo ordenada de objetos ou literais, rray representa uma coleo ordenada de objetos ou literais de tamanho dinmico, acessveis p or 34 ----------------------- Page 35-----------------------

posio. Finalmente, h o tipo de coleo Dictionary, uma sequncia no ordenada de pares de associaes sem chaves duplicadas [ radores UL99]. Cada uma destas colees possui ope

apropriados que atuam no objeto de forma transitiva (percorrendo todo o grafo). Os bancos de dados orientados a objetos tambm possuem uma linguagem de co nsulta: a OQL (Obj ect Query Language), proposta pela OD G (Obj ect Database Ma

nagement Group) . Entretanto, ela ainda pouco utilizada, dando lugar muitas vezes utilizao de iterad ores em colees de objetos. A OD etos, assim como pela definio do modelo de objeto. Entretanto, as implementaes variam entr e os distribuidores. Outras propostas de padro da OD ingiram um grau significativo de aceitao so a a O L (Obj ect Manip ulation Language) [CAT00]. A . Em performance geral, a dos SGBDOO tem recebido constantes melhorias ODL (Obj ect G que Def inition ainda no at Language) e G a responsvel pela definio dos padres dos bancos orientados a obj

instanciao de um objeto em consultas no banco apenas gera uma referncia ao objeto, que somente inicializado se houver uma requisio de fato. Isto possibilitado por tcnicas de lazy loading e objetos proxy [FAS97]. Os bancos de dados O.O. recentes fazem uso de mtodos de caching de objetos, isto , serem lidos objetos so mantidos em memria ao invs de

diretamente do disco. Desta forma, o SGBDOO otimiza seus recursos, evita ndo uma carga desnecessria na inicializao de todos os atributos referentes a um objeto em uma con sulta base de dados. Alm da transparncia entre a linguagem da aplicao e o banco de dados, e dos d iversos recursos disponveis nos bancos de equados para dados O.O., eles so especialmente ad

representar dados cuja representao em tabelas pouco eficiente (como dados geoespac iais e de CAD/CA ) [RAJ02].

A desvantagem deste tipo de sistema est principalmente no fato de ainda c onstituir-se 35

----------------------- Page 36----------------------em uma tecnologia de adoo recente, com implementaes ainda em desenvolvimento, como o caso da OQL, e a falta de uma padronizao entre os distribuidores. Alm disso, os s istemas de bancos de dados relacionais so legados na maioria das organizaes. Sua substituio p or sistemas Orientados a Objetos ainda uma perspectiva bastante remota. 2.5. Outros mecanismos de persistncia de objetos Como foi apresentado nas sees anteriores, quando se trata de aplicaes mais robustas, o mtodo de persistncia mais utilizado ainda so os bancos de dados relacionais, enquanto

aplicaes de pequeno e mdio porte, voltadas Web, e aplicaes especficas utilizam banc de dados X L ou bancos de dados O.O.. a de objetos, como a todos primitivos de persistnci

utilizao da serializao de objetos, tambm so bastante utilizados em aplicaes simples no necessitam de recursos mais sofisticados como o controle de transaes e concorrnci a. Um mecanismo de persistncia de objetos que tem ganho uma certa noto riedade no mercado o mecanismo de persistncia em memria [BJW87]. Um exemplo de aplicao desta 1 tecnologia a arquitetura Prevayler , que tem como base o conceito de prev alncia, que refere-se ao fato dos objetos prevalecerem em memria em todo seu ciclo de vida. Tod as operaes que ocorrem sobre estes objetos so gravadas em arquivos de log, e em perodos de pouco acesso aos dados, o sistema encarrega-se de gravar snapshots dos estados c orrentes dos objetos. Assim, se h alguma falha no sistema com perda de memria, os objetos tm um meio

de retornarem ao seu ltimo estado estvel, atravs da recuperao do snapshot, que feita em conjunto com a leitura e processamento dos comandos armazenados nos arquivos de log. 2

Outro exemplo da aplicao desta tecnologia o projeto HSQLdb , baseado no p rojeto Hyp ersonic, desenvolvido para ser usado em plataformas embarcadas (dispositivos portteis). Esse tipo de banco, apesar de relacional, apresenta a possibilidade de rodar em memria (por 1 2 Prevayler: http://www.prevayler.org/ HSQLDB: http://hsqldb.sourceforge.net/ 36 ----------------------- Page 37----------------------exemplo, atravs da clusula CREATE uporte nativo E ORY TABLE) ou em disco, e o s

linguagem Java, assim como o suporte linguagem padro SQL. 3 H outras implementaes de bancos de dados 100% Java, como o Cloudscap e , da IB 4 e o JDataStore , da Borland. Entretanto, estes sistemas ainda atuam em nichos muito especficos de apl icaes, sem muita representatividade no contexto de aplicaes empresariais de mdio a grande port e. 2.6. Conectividade entre o SGBD e ap icaes O.O. A presena de mercado dos bancos de dados relacionais ainda predominante, porm, o modelo de objetos tende a ser utilizado cada vez mais pelas aplicaes de interface de negcios. Por este fato, os principais fornecedores de bancos de dados esto evoluindo suas arquiteturas para adaptarem-se aos novos paradigmas de programao. uitas solues de conectividade entre SGBDR e aplicaes foram desenvolvida s ao longo dos anos, entre elas as tecnologias ODBC e SQL CLI (Call Level ace), para as linguagens que no trabalham com orientao a objetos. ividade Para linguagens especficos, O.O., existem alguns mecanismos de conect nterf

destacando-se o SQLJ e o JDBC. O primeiro a implementao dos principais fornecedore s de SGBD para a utilizao de SQL diretamente nos programas Java. A vantagem de se utili zar est abordagem est na portabilidade do cdigo. Ao contrrio da linguagem PL/SQL do banco d e dados Oracle, por exemplo, a SQLJ permite a reutilizao do cdigo em plataformas dife rentes de bancos de dados. JDBC (Java Database Connectivity) a interface de conectividade com banc o de dados padro que acompanha as implementaes atuais de desenvolvimento da linguagem Java. Es ta interface evoluiu ao longo dos anos deixando de ser apenas uma ponte de conectiv idade com a 3 4 Cloudscape: http://www-306.ibm.com/software/data/cloudscape/ JDataStore: http://www.borland.com/jdatastore/ 37 ----------------------- Page 38----------------------tecnologia ODBC, para tornar-se uma tecnologia independente, com um ric o conjunto de recursos de conectividade disponveis, e atualmente parte integral da tecnologia J 2EE (Java 2 Enterprise Edition). Atravs das classes fornecidas pela API possvel efet uar qualquer operao no banco de dados de dentro de uma aplicao Java. A utilizao do JDBC relativamente simples. Inicialmente, deve-se instanciar o driver especfico do banco de dados, utilizando o mtodo f orName: Class.forName(com.dummy.Driver) Atravs da reflexo, o objeto referente ao driver instanciado dinamicamente [FLA97]. Aps criada a instncia do driver, o gerenciador de drivers JDBC realizar a iniciali zao e registro para que ele passe a receber as requisies de conexo. O prximo passo estabelecer a conexo com o banco, possibilitada atravs do mt odo

getConnection da classe gerenciadora DriverManager do JDBC. A partir da, basta utilizar os mtodos disponibilizados pela API para executar consultas ou mesmo criar tabelas o u alterar registros no banco de dados relacional. As novas implementaes de JDBC (JDBC 2 e 3) j incluem a possibilidade de con exo atravs da interface JNDI, isto , sem a necessidade dos mtodos de reflexo e sem o acoplamento gerado pela classe de gerenciamento de drivers do JDBC 1. Outros re cursos so o

suporte a transaes distribudas e p ool de conexes, utilizao de pontos de controle, en re outros [SPE03]. O propsito original da JDBC facilitar a utilizao de bancos de dados na ling uagem Java, a partir do encapsulamento do banco de forma que os desenvolvedores t ivessem uma interface consistente de acesso ao mesmo, sem a necessidade do conhecimento da c amada fsica entre a aplicao e o modelo de dados. Outras linguagens orientadas a objeto, como C++, tambm possuem bib liotecas de 38 ----------------------- Page 39----------------------acesso ao banco de dados semelhantes ao SQLJ e JDBC. Um exemplo de implementao, em C++, de um middleware para comunicao com o banco de dados, a ). Esta interface foi interface OCCI (Oracle C++ Call nterf ace

desenvolvida para o banco de dados Oracle, e modelada de acordo com a especificao JDBC. Sendo assim, ela implementa construtores de linguagem semelhantes. A OCCI uma interface transparente de manipulao de objetos, com tipos defin idos pelo usurio, como se fossem instncias de classe C++. Os relacionamentos entre obje tos so implementados por referncias (REFs), e utilizados pelos mecanismos de navegao para

acesso aos dados objeto-relacionais. Esta biblioteca especfica para bancos de dados Orac le. Apesar da disponibilidade de bibliotecas orientadas a objeto para a linguagem C++, ainda comum as aplicaes C++ utilizarem ODBC puro para efetuar a conectivi dade ao SGBD. 39 ----------------------- Page 40----------------------CAPTULO 3 - Mapeamento Objeto-Re aciona No captulo anterior, foram abordadas as formas mais comuns de persistncia de objetos, atravs de arquivos serializados, documentos X s principais L ou SGBD (O.O. e O/R), e o

mtodos de conectividade entre bancos de dados e aplicao. Neste captulo, ser retomada a relevncia da utilizao de bancos de dados relaci onais para a persistncia de dados no contexto atual, e ento, ser apresentado o mtodo de mapeamento objeto-relacional, uma soluo elegante para o problema que aparece quand o o sistema precisa armazenar de forma permanente os dados gerados por ele em um SG BDR: o descompasso de impedncia. O ara dados OR nada mais que o ato de converso de objetos em memria p

relacionais, e vice-versa. Em geral, pressupe-se que o modelo de dados j existe, e que temos que adaptar nosso sistema orientado a objetos para trabalhar com este esquema prexistente. Caso contrrio, a utilizao de bancos O.O. nativos pode ser mais adequada do que a ge rao de tabelas baseadas no modelo de objetos, em conjunto com mecanismos de OR, que somente adicionariam uma camada de complexidade desnecessria aplicao. O objetivo deste captulo , em suma, apresentar os diversos mecanismos de M

OR, a aplicao da camada de persistncia e apresentar tambm as principais ferramentas existe ntes com este propsito. 3.1. Persistncia em SGBDR Como foi visto, a forma de persistncia de dados predominante atualmente a inda baseiase na utilizao de sistemas legados de bancos de dados relacionais. comum encontrar mos esta arquitetura j existente, e em produo, tanto em sistemas de mdio porte q uanto em sistemas com alto volume de dados. Bancos de dados relacionais provaram ao longo das dcadas que so uma forma estvel, segura e eficiente de armazenamento de dados. 40 ----------------------- Page 41----------------------Ressalta-se tambm o fato de que muito investimento foi e ainda empregado pelas empresas na manuteno dos sistemas de bancos de dados relacionais, pois ele tido co mo a base das operaes que envolvem a tecnologia da informao. Isto sem contar os gastos co m treinamento e equipe e de licenciamento deste tipo de sistema investidos ao long o do processo. Os SGBDR so considerados sistemas crticos na maioria das organizaes, enquan to o modelo de objetos adotado no desenvolvimento das aplicaes de negcio. Portanto, refo rase a necessidade da utilizao de metodologias que permitam que haja uma integrao efet iva entre as interfaces, que tendem a ser orientadas a objetos, e os dados, armazena dos no modelo relacional. Uma arquitetura de sistemas utilizando ambos os modelos apresentada na Fig. 5: Fig. 5: Arquitetura de 3 camadas. [extrado de BM00] uitas vezes, mecanismos simples de persistncia, como a serializao de obj etos, torna

o sistema incapaz de lidar com uma grande quantidade de dados. Uma soluo apropriad a para este problema seria persistir as informaes em um SGBDR, por ser um sistema robusto, geralmente apresentando suporte a alto volume de dados, controle de concorrncia, transaes e

otimizaes. Adotando-se esta soluo, elimina-se muitos problemas e preocupaes co o 41 ----------------------- Page 42----------------------segurana, rapidez na manipulao das informaes e distribuio de dados. O modelo relacional envolve a existncia de tabelas uni-dimensionais de ar mazenamento de dados, onde cada linha ou tupla representa um determinado registro no banco d e dados. uma abordagem simples e eficiente de persistncia, entretanto, retorna-se ao probl ema inicial da impedncia entre a linguagem relacional e a linguagem O.O.. Objetos incluem estruturas de dados como listas e mapas, e utilizam hera na e ligaes diretas entre os objetos para se relacionarem entre si. Alm disso, os ob jetos so criados e modificados em memria, sendo necessrio coordenar o que ocorre na memria com o que ocorre em disco [FOW02]. De uma forma geral, na persistncia de objetos em SGBD, a identidade dos o bjetos, seus relacionamentos (herana, agregao e associao) e seu estado devem ser preserva dos nas tabelas relacionais. O esforo gasto no processo de persistncia manual de objetos no banco de da dos acaba trazendo no apenas uma camada de complexidade a mais, mas tambm resulta em uma inconsistncia com o modelo O.O.. A alternativa de se acoplar a linguagem SQL no cdigo O.O. acaba por descaracterizar o segundo modelo, pois desta forma, o prog

rama perde as caractersticas bsicas do modelo O.O.: a possibilidade de reutilizao e a f acilidade de manuteno do cdigo. A criao de uma camada de persistncia de objetos permite diminuir o acoplame nto entre o banco de dados e a aplicao. Desta forma, uma mudana em um modelo pode ser traduzida no outro, sem que haja a necessidade de se reestruturar toda a aplicao [A B03] Logo, atravs da camada de de afetar OR, pequenas mudanas no esquema relacional deixam

o cdigo orientado a objeto como um todo, e assim, evita-se a necessidade do desen volvedor da aplicao de atuar tambm como um administrador de dados, a partir do momento que o conhecimento do esquema do banco deixa de ser fundamental. 42 ----------------------- Page 43----------------------Atravs de odas as vantagens trazidas por ele, recem ao realizar-se a e evitando-se os problemas que apa OR, possvel persistir os objetos em um SGBDR, obtendo-se t

persistncia em O.O. utilizando um modelo relacional (impedncia de modelos). 3.2. Conceitos bsicos de MOR ao O mapeamento processo de pode ser visto como um processo semelhante

desenvolvimento de um compilador. A maioria dos compiladores de linguagens de pr ogramao convertem um determinado cdigo-fonte em um programa real atravs de trs o peraes bsicas. Primeiro efetua-se a anlise lxica do cdigo-fonte, separando as palavras-chav e e os tokens da linguagem de forma compreensvel pelo compilador. A seguir, fei ta a anlise sinttica, que identifica construtores vlidos de linguagem nos grupos de tokens. Fi nalmente, o gerador de cdigo interpreta estes construtores e gera o cdigo executvel.

O processo de mapeamento de um objeto, por exemplo, definido em uma est rutura de documento X mo princpio. L, para uma tabela do banco de dados relacional, segue o mes o cdigo para reconhecer o que caracteriza

Inicialmente, analisa-se um atributo e seus

respectivos valores. Verifica-se ento se o documento vlido, isto , se o documento e st bem formado. Verifica-se tambm se o documento segue a estrutura definida em um esquem a ou DTD associado a ele. Aps estas anlises, possvel extrair documento e determinar a melhor forma de adapt-los em uma estrutura relacional. O mapeamento objeto-relacional ( o esquema OR) uma tcnica de traduo entre os dados do

relacional e o modelo de objetos, via mapeamento dos estados de um o bjeto no modelo relacional de armazenamento (SGDBR). Desta forma, adiciona-se uma forma consiste nte de se trabalhar com SGDBR em linguagens O.O.. O mapeamento realizado entre os objetos de uma linguagem O.O. e as tabe las de um SGBDR torna possvel a persistncia de objetos em um nsparente. 43 ----------------------- Page 44----------------------Persistncia transparente refere-se habilidade de se manipular os dados armazenad os em um SGBDR diretamente pela linguagem O.O., e o objetivo do ma aos seguintes OR. Isso reto SGBDR de modo tra

aspectos desejveis em um sistema de persistncia de objetos [QUA00]: Persistncia ortogona : a persistncia deve ser vlida para todos os objetos do sistema, independente de seu tipo; Persistncia transitiva (PBR): se um objeto persistente, ento todos os ob jetos referenciados por esse objeto devem ser promovidos a objetos persiste

ntes. jetos As tcnicas (design de mapeamento tm como fundamento padres de pro

patterns), que procuram encontrar solues para diferentes problemas, modelos de da dos e de objetos. Tambm so utilizadas, no processo de mapeamento, tcnicas de cache para a ob teno de melhor performance em relao aos mtodos tradicionais de persistncia em SGBDR (SQL com JDBC ou ODBC). Apesar de muitas linguagens apresentarem zarem a tarefa da bibliotecas para reali

persistncia dos objetos, como por exemplo, a API de serializao de objetos, este tipo de soluo muitas vezes inadequada para sistemas de maior complexidade, onde esperado q ue o mecanismo de persistncia seja consideravelmente mais robusto e poderoso. Os f rameworks de o banco de OR trabalham independentemente da aplicao e d

dados. A camada de persistncia deve intermediar a camada de dados e a camada de a plicao. Esse tipo de soluo tem como foco aplicaes que necessitam acessar dados legad os, bases heterogneas, ou gerenciar objetos de negcio distribudos e persistentes. Um f ramework de OR deve apresentar recursos de consulta de dados, suporte a transaes, concorrncia (locking otimista ou pessimista [AMB03]), e enfim, possibilitar a persistnc ia transparente, encapsulando o acesso ao banco de dados relacional. 44 ----------------------- Page 45----------------------3.3. Tipos comuns de MOR Para permitir a persistncia de objetos em um SGBDR, algum acordo deve s er feito quanto forma como os dados sero armazenados. O mapeamento deve envolver cada elem ento de um objeto: seus atributos, relacionamentos e sua herana. Logo, os conceitos da

programao O.O. devem ser mapeados para estruturas gao, associao, herana, polimorfismo) [KEL97]. Isso traz algumas questes, que mento entre os modelos e na escolha de um f ramework de tado das consultas? Como atualizar os dados caso o estado de um objeto mapeado seja alterad o? Como modelar os relacionamentos entre os objetos? Como modelar a herana dos objetos no modelo relacional? Qual estratgia de caching pode ser utilizada para minimizar os acessos a o SGBD? Como executar funes agregadas? A principal tarefa do mapeamento O/R envolve a identificao das c onstrues da orientao a objetos que se deseja extrair do esquema relacional, entre elas a ident ificao das classes, dos relacionamentos que podem ser representados no modelo de objetos e estabelecer as cardinalidades [LER99]. Como foi visto, o processo de mapeamento busca, basicamente, a traduo entre os modelos O.O. e relacional, partindo do princpio de que h uma arquitetura co mum entre ambos. As tcnicas de MOR, em geral, lidam com esquemas relacionais na 3FN (tercei ra forma normal) [QUA00]. Como as tcnicas de com modelos OR foram desenvolvidas para trabalhar devem ser consideradas no mapea de tabelas relacionais (agre

OR, entre elas [JOH03]:

Como converter os valores das colunas em objetos e apresent-los no resul

entidade-relacionamento pr-existentes, a tarefa de traduo, ou mapeamento, co nsistir na 45 ----------------------- Page 46-----------------------

adaptao do modelo de objetos ao modelo de dados. As principais tcnicas de mapeamento de objetos em SGBDR podem ser descri tas como: Mapeamento c asse - tabe a: ou mais tabelas, apeamento de uma classe em uma

ou de uma tabela para uma ou mais classes, e mapeamento de herana; Mapeamento atributo - co una: Mapeamento de tipos em atributos; Mapeamento re acionamento - chave estrangeira: eamento dos relacionamentos O.O. em relacionamentos entre tabelas. Fig. 6: Exemp lo de MOR (adap tao de [RAJ02; f ig. 5.2] ). Para modelos de dados muito simples, classes podem ser mapeadas d iretamente em tabelas, em uma relao um-para-um (Fig. 6). Esta a forma mais intuitiva de mapeamen to classe-tabela, onde todos os atributos da classe persistente so represen tados por todas as colunas de uma tabela no modelo relacional. Assim, objeto pode ser cada instncia do ap

armazenada em uma tupla da tabela. Porm, este tipo de modelo pode conflitar com o modelo entidade-relacionamento existente, que pressupe a normalizao das tabelas e a otimiz ao de consultas. Uma estratgia mais realista de mapeamento classe-tabela divide-as em dua s categorias 46 ----------------------- Page 47----------------------[OBJ03]: Mapeamento de subset, onde os atributos da classe persistente represen tam algumas ou todas colunas de uma tabela. Esta estratgia convm para casos onde t odos os atributos de uma classe persistente so mapeados a uma mesma tabela, e onde no h preocupao de incluir as colunas que no fazem parte do modelo de negcios.

Pode referir-se tambm herana de tabelas simples. Mapeamento de sup erset, onde os atributos da classe persistente so de rivados de colunas de mltiplas tabelas. Este tipo de mapeamento usado para criar "classes de viso", que ocultam o modelo fsico de dados, ou para mapear uma rvore de herana de classes utilizando o mapeamento vertical. Os atributos de uma classe, por sua vez, podem ser mapeados para zero ou mais colunas de uma tabela de um SGBDR, pois os atributos de um objeto no so nece ssariamente persistentes. Caso um atributo seja um objeto por si s, o mapeamento pode ser fei to para vrias colunas da tabela. Os atributos podem ser caracterizados em [IB peado a uma coluna de uma tabela, isto , refere-se ao valor de um tipo de dados especfico (int, float, double, dentre outros). Atributos de Referncia: Atributos de referncia representam relacionamentos com outras classes, isto , referem-se a atributos cujo tipo uma referncia a outro objeto ou conjunto de objetos (composio). Em um modelo orientado a objetos, uma classe pode se relacionar com outr a atravs de 47 ----------------------- Page 48----------------------agregao ou associao. A cardinalidade (ou multiplicidade) de um relacionamento pode s er [1:1], [1:n], [n:1], [n:m]. Tabelas so relacionadas utilizando-se das mesmas card inalidades. Relacionamentos, no modelo de objetos, so implementados com comb inaes de referncias a objetos e operaes. Quando a multiplicidade 1 (0..1 ou 1), o relacion 00]:

Atributos Primitivos: Este termo denota um atributo de uma classe que ma

amento implementado por uma referncia a um objeto ou operao de get/set. Quando a multiplic idade N (N, 0..*, 1..*), o relacionamento implementado atravs de um atributo de coleo (p or exemplo, um array), e por operaes de manipulao deste array [AMB03]. Sendo assim, as relaes entre objetos so implementadas explicitament e atravs de atributos de referncia, enquanto as relaes entre tabelas so realizadas atravs de asso ciaes de chaves estrangeiras. Um f ramework de relaes entre objetos OR pode mapear as

utilizando as chaves estrangeiras das tabelas correspondentes. O mapeamento de associaes preocupa-se, tegorias de relacionamentos entre objetos [A dade: de chave estrangeira no modelo relacional e sempre bi-direcional (Fig. 7) . Fig. 7: Relacionamento 1:1 (adap tao de [ BM02]) . 48 ----------------------- Page 49---------------------- Mapeamento 1:n: O relacionamento 1:n (Fig. 8) pode ser implementado de for ma similar ao mapeamento 1:1, onde a chave estrangeira adicionada classe associ ativa. Os atributos dos objetos agregados podem ser mapeados a uma nica tabela, ou at ravs da criao de uma tabela associativa para o tipo agregado [KEL97]. Fig. 8: Relacionamento 1:n (adap tao de [ BM02]) . Mapeamento n:m: Para implementar relacionamentos n:m (muitos-para-muitos), que no existem fisicamente no modelo relacional, utiliza-se uma tabela associativa (Fig 9). O relacionamento passa a ser representado em uma tabela distinta no banco de basicamente, com duas ca

B03]. A primeira baseia-se na multiplici

Mapeamento 1:1: O relacionamento 1:1 implementado atravs de restries

dados, contendo os OIDs (ou chaves estrangeiras) dos objetos participantes da associ ao. Fig. 9: Relacionamento N:N. 49 ----------------------- Page 50----------------------A segunda categoria de relacionamentos baseia-se em dois tipos de direci onalidade: relacionamentos unidirecionais e relacionamentos bidirecionais (Fig. 10). O rel acionamento unidirecional ocorre quando um objeto relaciona-se a outro, mas este segund o desconhece as classes associadas a com relacionamentos ele. O modelo relacional apenas trabalha

bidirecionais, inclusive, este um fator de descompasso de impedncia entre as tec nologias [A B03]. Fig. 10: Direcionalidade. Outra forma de relacionamento entre objetos so os relacionamentos recursivos (por exemplo, um time pode ser integrante de outros times). O mapeamento em tabelas p ode ser feito da mesma forma que um mapeamento n:m, isto , atravs da criao de uma tabela associati va. A diferena que, neste caso, ambas colunas sero chaves estrangeiras da mesma tabela . Um aspecto essencial da tecnologia O.O. a herana. A herana permite que da dos e comportamentos de uma superclasse (classe base ou classe pai) sejam re aproveitados por subclasses (as classes derivadas da classe pai). Bancos de dados relacionais no possuem o conceito de herana: entidades no podem herdar atributos de outras entidades. Entre as principais tcnicas para representar hierarquias em um esquema r elacional esto o mapeamento distribudo de herana (horizontal e vertical) e o mapeamento de filtro de

herana, ou de tabela simples. No primeiro, cada subclasse mapeada em uma tabela s eparada, e todos os atributos herdados so replicados na tabela. Essa abordagem eficiente q uando a superclasse tem menos atributos que a subclasse. O mapeamento distribudo de herana difcil 50 ----------------------- Page 51----------------------de ser implementado quando colees heterogneas de objetos precisam recuperadas. ser

[IB 00]. No segundo tipo, as classes so representadas em uma nica tabela. Cada r egistro da tabela utiliza atributos pertinentes sua subclasse, enquanto os outros atributos so mantidos nulos. Esta a forma mais rpida de mapeamento, com o custo de manuteno e espao. Os padres de projeto referentes ao mapeamento de heranas sero vistos na prxima seo. Outros fatores a se considerar no mapeamento so a existncia de uma restrio a respeito da ordem dos dados - o que envolve o mapeamento de colees - e o mapeament o dos metadados, geralmente definidos em um documento descritor X frequentemente empregados pelos f rameworks de a forma como as colunas de um SGBDR sero mapeadas em atributos de objeto s, incluindo informaes a respeito da multiplicidade dos relacionamentos, junes, integridade refe rencial, OR. L, tambm

O mapeamento dos metadados refere-se criao de um arquivo de detalhamento d

etc. Assim, evita-se cdigo repetitivo atravs da gerao de cdigo ou programao reflexi do f ramework em questo. No processo siderao quais e primria, de contadores e nmeros de versionamento. Outra informao relevante refere-se de mapeamento tambm importante levar em con

informaes adicionais devero ser mantidas pelo objeto, por exemplo, informao de chav

existncia do objeto no banco de dados, o que resultaria na deciso entre um comand o UPDATE da linguagem SQL, ou de um comando INSERT. Uma tcnica para isto seria implementa r uma varivel booleana a cada classe persistente. Essas informaes no precisam ser implemen tadas nos objetos de negcio, mas devem ser tratadas de alguma forma pela aplicao de OR. Como foi visto, h mais de uma forma de efetuar-se o mapeamento entre o mo delo de objetos e o modelo de dados relacional. A estratgia de encapsulamento do acesso ao banco de dados determinar como ser implementado o mapeamento. 51 ----------------------- Page 52----------------------3.4. Imp ementaes de Camadas de Persistncia A criao de uma camada de persistncia deve permitir o desacoplamento entre o modelo de dados e a aplicao. Numa arquitetura tpica de n-camadas, comum a presena de uma camada para o acesso aos dados que separe os mecanismos de persistncia da lgic a de negcios. Como foi visto, h diferenas tcnicas entre o modelo persistente do S GBDR e o modelo transiente da programao O.O. que devem ser consideradas, entre elas: [BER02 ] Bancos de dados utilizam identificadores baseados em chaves, en quanto objetos possuem identidade intrnseca (OID); A quantidade de objetos em memria tipicamente representa apenas uma pequ ena parte dos objetos do banco de dados; bilitam sidentes Bancos de consultas dados possuem linguagem de pesquisa que possi

eficientes atravs do uso de ndices, mas no conseguem acessar objetos re

em memria; ma que no afete a integridade referencial do banco de dados e/ou a perfor mance do mesmo; Bancos de dados apresentam o controle de transaes (commit e rollback); Bancos de dados apresentam semnticas complexas de locking e isolamento d e dados; Relacionamentos entre objetos so implcitos, e em um banco de dad os so bidirecionais; Pode ser desejvel utilizar uma estrutura lgica diferente de tabelas relac ionais para os objetos residentes em memria . 52 ----------------------- Page 53----------------------Para lidar com estas questes de forma eficiente, preciso interceptar as i nteraes entre a aplicao e os objetos de dados. O desenvolvimento de uma camada de persistncia somente simples se h um relacionamento linear entre os objetos da aplicao O.O. e as tabelas correspondente s do banco de dados relacional. que possuam as comum encontrar objetos ou esquemas de banco udanas em objetos residentes em memria devem ser persistidas de uma for

estruturas complexas, e no simplesmente apresentem um relacionamento um-para-um. Um DBA, por exemplo, pode decidir isolar a informao referente a cartes de crdito d e uma tabela de clientes, e isto implicaria na codificao de rotinas SQL para duas interaes separadas, resultando em duas requisies no banco para cada objeto. As implementaes de camadas de persistncia, desenvolvidas na linguag em O.O., muitas vezes tratam da gerao dos esquemas de dados (mapeamentos) automatic

amente e podem at mesmo efetuar uma engenharia reversa criando hierarquia de classes a pa rtir de um esquema de tabelas em banco de dados. Estas ferramentas tm como propsito facilitar e automatizar o processo de m apeamento entre os modelos, atravs de diferentes abordagens [BER02]: Ferramentas de mapeamento primitivo sem identificador: As ferramentas que se enquadram nesta categoria simplesmente automatizam a criao de pesquisas na base de dados ou atualizaes via JDBC. criada uma classe on de as variveis de instncia correspondem s colunas na tabela, e todas as i nteraes so explcitas, isto , os comandos DDL apenas so refletidos nas classe s e no h preocupao com a definio de uma chave primria correspondente. Desta forma, se duas consultas retornarem a mesma coluna, isso refletir na criao de dois objetos diferentes correspondentes mesma tupla relacional. 53 ----------------------- Page 54---------------------- e reflete as colunas de uma tabela. Entretanto, estas ferramentas mantm um ndice (tabela hash) de todos os registros criados por conexo. Assim, as regr as de negcio do esquema podem ser escritas independente das aplicaes de interface com o u surio. Esta forma eficiente em processamento de dados "centrados em documento" , com um padro conhecido, mas no recomendados para transaes "f ine-grained" onde h objetos de quantidade desconhecida sendo constantemente lidos e escrito s em resposta a Ferramentas de mapeamento direto com identificador:

Da mesma forma do mapeamento primitivo, tambm h uma classe que basicament

aes dos usurios. Destacamos as seguintes APIs da linguagem Java que utilizam mapeamento direto, entre 1 outros recursos: Hibernate , Castor JDO Hibernate, utiliza reflexo (ref lection) para recuperar seu respectivo que igo SQL medida que for necessrio. Desta forma, ele generaliza a camada de pe rsistncia, permitindo que eventuais mudanas no esquema relacional afetem mi nimamente o cdigo da camada de persistncia. O Castor JDO, apesar do nome, no implement a o modelo Sun JDO (Java Data Obj ects). Sua proposta fornecer o OR para diversas estruturas de representao de objetos, como documentos X , tabelas SQL e diretrios LDAP. Por fim, a ferramenta OJB (Obj ect Relational Bridge), do projeto Apache-DB, tambm utiliza a abordagem de reflexo, permitindo que objetos sejam manipu lados sem a necessidade da implementao de alguma interface em especial ou da herana de alguma classe especfica, atravs de persistncia transitiva. 1 2 3 Hibernate: http://www.hibernate.org/ Castor JDO: http://www.castor.org/ OJB: http://db.apache.org/ojb/ 54 ----------------------- Page 55---------------------- jetos Ferramentas de mapeamento genera izado: reconhece os objetos persistentes como ob L mapeamento com elimina a o banco relacional 2 e OJB . A 3 primeira,

informaes sobre os objetos e em tempo de execuo, o

necessidade de codificao do mapeamento na camada de persistncia, gerando cd

Esta alternativa "especiais", com

tratamento diferenciado. As regras de negcio podem ser implementadas

atravs de to. As ao e constantes atribuio podem ser utilizadas para operaes de recuper

eventos pr-definidos, e pouco cdigo necessrio para criar a definio de um obj

(get/set ) de valores, como no exemplo: String phone = employee.getString(Employee.PHONE_NR); Ao invs de depender da implementao de mtodos especficos, como por exemplo: String phone = employee.getPhoneNr(); ML, atravs de objetos proxy representativos dos objetos da aplicao. Atravs deste tipo de objeto (subclasse), pode-se interceptar o acesso aos objetos de dados e elaborar mtodos para lidar com os problemas envolvidos na persistncia de acordo. Outro mto do a representao de relacionamentos como objetos explcitos, mas assim, a dicionam-se objetos relacionamentos desnecessrios so ao modelo, e apenas o acesso aos Geradores, Proxies e objetos de re acionamento

Outra abordagem a gerao de cdigo baseado em definies escritas em

interceptados. Finalmente, pode-se alterar a mquina virtual da linguagem, como a JV da linguagem Java, para lidar com as questes envolvidas na persistncia. As ferramentas de MOR devem considerar tambm a utilizao de tcnicas implcitas ou

explcitas de otimizao de junes. O mapeamento de junes entre tabelas pode ser feito d diferentes maneiras. Uma forma seria mapear a juno como se fosse uma viso relaciona l em um nico objeto. Outra forma seria preservar dois objetos distintos e s eparar os campos 55 ----------------------- Page 56----------------------referentes a cada um. Mas para isso a juno deve ser do tipo "Outer Join", caso con trrio, os

objetos que no se enquadrarem na juno sero eliminados da memria. Outro fator a se considerar na implementao de uma ferramenta de OR so as colees de objetos. Quando recupera-se um conjunto de objetos com atributos em comu m, isto caracterizaria uma coleo de registros em associao com estes respectivos at ributos. As ferramentas de OR devem ser capazes de lidar com este tipo de da dos caracterstico da orientao a objetos. outros Alm das tipos de abordagens citadas acima, pelo destacam-se EJB-C tambm dois P

abordagens, adotadas e JDO, ambos da Microsystems . s lidam de

especificamente Sun o

padro

1 Eles utilizam forma

conceito

de

mapeamento

direto,

ma

diferenciada com as questes de persistncia, como o controle de transao e concorrncia . C P (Container Managed (Enterprise Persistence) parte da especificao EJB

JavaBeans), que definem componentes distribudos de trs tipos: seo (lgica de negcios), mensagem (reao s mensagens) e entidade (contendo os dados). CMP, portanto, um tipo especial de EJBs de entidade [SPE03]. Esta tecnologia baseia-se na def inio de classes abstratas de acesso para cada varivel de instncia. As chamadas ao banco de dados so geradas em tempo de instalao (dep loy), para manter a independncia do mecanismo de persistn cia e esquema, ao contrrio da tecnologia precedente, EJB-B P [THO02].

JDO a proposta da linguagem Java de padronizar os mtodos de OR. Ela utiliza processamento posterior de "bytecode". Isto permite o acesso aos mecanismos inte rnos (engine) da ferramenta para assim interceptar o acesso e endereamento no que diz respeito aos dados das variveis de instncia do objeto. Enfim, os f rameworks de foro necessrio na OR tem como propsito reduzir o es

codificao de rotinas especficas de mapeamento. A persistncia transparente , portanto, o principal objetivo das imp lementaes de 1 Sun Microsystems: http://www.sun.com/ 56 ----------------------- Page 57----------------------MOR. Esta transparncia permite a manipulao e navegao entre os objetos persiste ntes diretamente pela linguagem, como se fossem objetos transientes. 3.5. Padres de Mapeamento Objeto-Relaciona que Padres de contm projeto so documentos, elaborados por desenvolvedores,

instrues para resolver um problema dentro de um contexto especfico. Estes documento s so como uma receita do caminho a seguir para resolver determinados problemas de des ign. Em outras palavras, so modelos conceituais que podem ser aplicados em determinadas re as de uma aplicao de acordo com a necessidade [SPE03]. Em geral, as ferramentas de odelo de OR so desenvolvidas para trabalhar com um

Domnios (Domain Model). Sua base a criao de um modelo de objetos que incorpo ra ambos os dados e o comportamento, criando uma rede de objetos interligados. simi lar a um modelo de banco de dados, mas envolve dados e processos, atributos multi-valorad os e herana [FOW02]. Implementar te tipo de manualmente uma camada de persistncia utilizando es

modelo uma tarefa de alta complexidade, por isso geralmente opta-se por utilizar ferramentas e f rameworks de OR.

artin Fowler [FOW02], autor de diversos livros a respeito de pa dres de projeto, props alguns padres especficos de MOR, utilizados na base de muitos f rameworks, qu e sero

descritos nesta seo. Os padres de urais. A escolha bsica para o padro da arquitetura est dividida em quatro modelos : Row Data Gateway, Table Data Gateway, Active Record e Data Mapp er. Os primeiros so baseados em gateways, um objeto que encapsula o acesso a sistemas ou recursos externos (Fig. 11). Em ambos os casos, tem-se em memria as classes r eferentes s tabelas do seu banco de dados. 57 ----------------------- Page 58----------------------Os gateways e as tabelas do banco de dados possuem a mesma forma: para c ada tabela h uma classe, e para cada campo h uma coluna correspondente no banco de dados. Ou tra caracterstica do gateway que ele contm todo o cdigo de mapeamento do banco para um a aplicao. O gateway aquele que faz os acessos ao banco de dados, nada mais. O Row Data Gateway um objeto que age como um gateway para um nico registr o no banco de dados, isto , um objeto que reflete um registro de uma tabela . O Table Data Gatweway age sobre uma tabela, mantendo todo o cdigo SQL de acesso, encapsulando a lgica de acesso do banco de dados. Fig. 11: Gateway Pattern [extrado de FOW02] O Active Record, por sua vez, combina o gateway e o objeto de domnio em u ma nica classe, combinando a lgica de negcio e o acesso ao banco de dados (Fig. 12). Fig. 12: Active Record Pattern [extrado de FOW02] Finalmente, h o Data Mapp er (Fig. 13). Este, por ser mais flexvel, o mai s complexo. A grande diferena entre ele e o modelo de gateway est na inverso da dependncia e do OR dividem-se entre padres de arquitetura e padres estrut

controle. 58 ----------------------- Page 59----------------------Com os gateways de dados, a lgica de domnio deve conhecer a estrutura do b anco de dados, mesmo no lidando com SQL. No Data Mapp er, o domnio de objetos pode ignora r completamente o layout de banco de dados, agindo como um mediador entre os obje tos em memria e o banco de dados. Sua responsabilidade transferir dados entre ambos, e g eralmente utilizado com um odelo de Domnios.

Fig. 13: O Data Mapp er isola o objeto de dominio do banco de dados [extr ado de FOW02]. Nos projetos de uturais, abordados OR, geralmente o foco est nos aspectos estr

anteriormente (cap. 3.3). Os padres estruturais descrevem como os dados em um banco relacional refletem (mapeiam) em dados em um tanto, a maior modelo de objetos. Entre

complexidade encontra-se nos aspectos de arquitetura e comportamento. H duas questes (impedncias) envolvidas no processo: l e em memria, enquanto os dados relacionais so referenciados por cha ves que esto alocadas em outras tabelas; em nico modelo relacional. Uma forma de lidar com o primeiro problema atravs da manuteno da identidade relacional de cada objeto com a adio de um campo identificador (armazenamento da c have atributos mu tiva orados: os objetos lidam com mltiplas referncias campo, atravs de colees, enquanto no h campos multivalorados no diferena de representao: os objetos so referenciados em tempo rea

59 ----------------------- Page 60----------------------primria nos atributos do objeto). e lazy Para o segundo caso, geralmente utiliza-se uma tcnica chamada d loading

[WOL03], onde o objeto no contm todos os dados: os dados so atribudos ao objeto apen as quando necessrio. Outra questo a se considerar refere-se ao conceito de herana. H diversas e stratgias de mapeamento de uma estrutura de herana de um modelo de objetos para um modelo relacional, cada uma elaborada para lidar com um problema especfico, entre elas: Herana de tabe a simp es: Na estratgia de herana de tabela simples (flat) , uma tabela representa todas as classes da hierarquia (Fig. 14). Essa um a forma eficiente de mapear classes onde consultas so efetuadas no nvel da classe base ( superclasse). Entretanto, h uma perda de espao considervel (valores nulos) e a necess idade de uma icao das coluna (no instncias caso, type) para possibilitar a identif

correspondentes a cada classe. Fig. 14: Herana de Tabela Simp les [extrado de FOW02] . Herana horizonta : Na estratgia de herana horizontal, ou herana de tabelas concretas (Fig. 15), cada classe concreta (no-abstrata) associada su a respectiva 60 ----------------------- Page 61----------------------tabela, incluindo os atributos da classe herdada. A rapidez na persistncia e a lterao de instncias adquirida desta forma pelo custo da desnormalizao. Qualqu er alterao na classe abstrata dever ser refletida nas tabelas das subclasses.

Fig. 15: Herana de Tabelas Concretas [extrado de FOW02] Herana vertical: Na quia, estratgia de herana vertical, cada classe da hierar

inclusive classes abstratas, associada a uma tabela separada no banco de dado s (Fig 16). Atravs do mapeamento vertical, mltiplas tabelas so acessadas e todos os dados so extrados para um objeto. Essa a forma mais flexvel de se lidar com dados legados complexos. Porm, maior esforo ser necessrio para a reconstituio dos objetos, em comparao com as estratgias anteriores. Fig. 16: Herana de Classe e Tabela [extrado de FOW02] 61 ----------------------- Page 62----------------------3.6. Consideraes Finais Neste captulo abordou-se a aplicao de uma camada de persistncia utilizando tc nicas de OR. Foi visto tambm que a utilizao de formas simples de persistncia , como a codificao de rotinas de bancos de dados relacionais em SQL diretamente nas classes de negcio O.O., resulta em cdigo difcil de se manter e de se estender fut uramente. Esta alternativa s vivel em aplicaes muito pequenas e prottipos [A om este B01].

procedimento, h um acoplamento direto entre as classes de negcio da aplicao e o esqu ema do banco de dados relacional, e consequentemente, a cada mudana que ocorrer no modelo relacional, como por exemplo a renomeao de uma coluna, ir implicar na reescrita do cdigo fonte da aplicao. Uma abordagem um pouco melhor para este problema o encapsulamento das ro tinas SQL em "classes de dados", por exemplo, com a criao de stored procedures no banc o de dados para representar os objetos. as ainda assim, se h mudanas no modelo, se

r preciso recompilar o cdigo novamente. Finalmente, apresentou-se a abordagem do mapeamento objeto-relacional ( OR), que permite que, atravs da criao da camada de persistncia, seja feito o mapeam ento entre objetos e o banco de dados relacional, e assim, mudanas no esquema deixam de impl icar em mudanas na aplicao. Atravs do mapeamento objeto-relacional, o cdigo passa a ser muito mais con sistente (eliminando a maioria dos problemas de impedncia entre os modelos), simples de se manter e de ser estendido futuramente. A principal idia por trs dos f rameworks de tuplas de OR o mapeamento entre as

um banco de dados relacional e objetos em memria, de forma que possam ser manipul ados por linguagens orientadas a objeto. A o impacto da grande desvantagem desta tcnica est n

performance das aplicaes, mas considerando as vantagens mencionadas acima, e com a 62 ----------------------- Page 63----------------------construo e aplicao adequada da camada de persistncia, este fator bastante reduzido. O mapeamento objeto-relacional pode ser utilizado tambm em diferentes mec anismos de persistncia, entretanto, esta situao ser pouco adequada, especialmente quando o sistema enquadrar-se em um desses casos [JOH03]: No caso da modelagem centrada em objetos, o resultado um esquema relaci onal artificial, onde h a necessidade de efetuar-se junes complexas para operaes comuns de recuperao de dados e h falta de integridade referencial. pode ser

 No caso da modelagem relacional, o resultado uma camada de o bjetos com relacionamento de um-para-um com as tabelas do SGBD, o que pode ser i neficiente. As consultas e atualizaes no SGBD passam a ser ineficientes. Tarefas que podem ser efetuadas de maneira simples com operaes r elacionais podem necessitar de cdigo significativo em aplicaes O.O., ou resultar na criao de objetos desnecessrios. Em geral, o mapeamento objeto-relacional no o mtodo mais apropriado em sis temas onde h requisitos de OLAP (Online Analytic Processing) ou de data warehousing, qu e foram desenvolvidos para trabalhar especialmente com operaes relacionais. Um dos segredos do sucesso do mapeamento objeto-relacional o ent endimento de ambos paradigmas relacional e O.O.) e suas diferenas, e fazer tradeoffs bas eados neste conhecimento [A B98]. 63 ----------------------- Page 64----------------------CAPTULO 4 - Estudo de caso: Obj ect Relational Bridge 4.1. Introduo apeamento objeto-relacional um requisito comum de muitos projetos de software. As atividades envolvidas na persistncia de dados so tediosas e passveis de erro. Consi derando as inevitveis mudanas nos requisitos que ocorrem no ciclo de vida de um sistema, o me canismo de persistncia de dados deve ser mantido em sincronia com o cdigo fonte, alm das qu estes de portabilidade que podem estar envolvidas. O f ramework OJB (Obj ect Relational Bridge) uma ferramenta que tem como propsito minimizar estes problemas, disponibilizando uma camada de persistnc

ia

de

objetos

transparente para a aplicao O.O., onde a persistncia implementada sem que o objeto em questo necessite implementar uma interface ou herdar atributos persistentes. Neste captulo apresenta-se um estudo de caso onde a tcnica de mapeamento o bjetorelacional aplicada utilizando o f ramework OJB. 4.2. Requisitos funcionais A aplicao proposta neste estudo de caso no apresenta interface grfica ou lgic a de negcios, tendo sido desenvolvida com o objetivo de apresentar uma aplicao prtica e d idtica da aplicao de OR, atravs do f ramework OJB.

A escolha por este f ramework deve-se ao fato de ser uma ferramenta flexv el (suporte a mltiplas APIs: o padro OD che (alto ndice de adoo da incipalmente, por G 3.0, JDO, alm do PB), integrante do projeto Apa comunidade Java e op en source em geral), e pr

apresentar-se enquanto uma ferramenta robusta de de query, caching, objetos proxy, enfim, de persistncia transparente. 64 ----------------------- Page 65-----------------------

OR, com recursos

Esta aplicao foi desenvolvida na linguagem Java, utilizando a IDE Ecli pse para a programao e dep loyment. Por ser baseada em Java, ela compatvel com os p rincipais sistemas operacionais e arquiteturas atuais (Unix, Windows, MacOS, etc). Abaixo, esto relacionadas as ferramentas utilizadas no processo, suas respectivas verses, e onde obt-las: o; ObjectRelationalBridge (OJB) 1.0-rc6: f ramework de OR do J2SDK 1.4.2: ferramentas e bibliotecas para programao Java; Ec ipse 3.0 M8: Ambiente de desenvolvimento Java robusto e modularizad

projeto Apache; e configurao adequada ncional para a destas ferramentas caracterizaram um ambiente fu MySQL 4.0.18: Banco de dados relacional op en-source; MySQL Connector/J 3.0: driver do banco ySQL para JDBC.

O scrip t de criao dos bancos encontra-se disponvel em (ANEXO A). A instalao

aplicao apresentada neste estudo. 4.3. Estrutura da ap icao A aplicao proposta neste estudo de caso um sistema de contro e fi nanceiro. O funcionamento do sistema foi bastante simplificado, com o objetivo de demonstrar a aplicao de OR de forma clara e prtica.

O sistema tem como base a criao de transaes, associadas a diferent es contas (bancria, dinheiro, carto de crdito, etc). Cada transao no sistema possui os seguinte s dados: a data referente ao crdito ou dbito (tipo de transao), o item (de compra, ou salrio, etc), o valor e a instituio (banco, loja, etc). Para tanto, foi desenvolvido o diagrama de classes, como visto na Fig. 1 7: 65 ----------------------- Page 66----------------------Fig. 17: Diagrama de Classes do es tudo de caso. Com base neste modelo, foi desenvolvido o modelo entidade-relacionamento ( Fig. 18): Contas Primary K ey Cod_Conta [PK1] Non-Key A ttributes Descricao

FK_Contas_Transacoes Transacoe s Primary K ey [PK1] [FK] Itens [PK2] [FK] Primary Key ituicao [PK3] [FK] o [PK1] Cod_ Item [PK1] ttributes utes Non-Key Attributes Descricao FK_ Itens_Transacoes FK_ Instituicao_Transacoes Cod_Conta Instituicao Cod_ Item Primary Key Cod_ Inst Cod_ Instituica Non-Key A Non-Key Attrib Data Descricao alor Tipo Fig. 18: Modelo ER do estu do de caso.

66 ----------------------- Page 67----------------------Desta forma, o processo de mapeamento incluir os seguintes aspectos: mapeamento de classe-tabela simples, um-para-um; mapeamento de atributos primitivos (todos atributos possuem tipo s equivalentes JDBC para a representao no banco); mapeamento de relacionamentos um-para-muitos. vo X O f ramework OJB implementa os respectivos mapeamentos atravs do arqui L

repository_user.xm , que ser detalhado na prxima seo. 4.4. Imp ementao s para Inicialmente a definem-se os parmetros de conexo JDBC necessrio

comunicao entre o f ramework (OJB) e o banco de dados ( O .xm , elemento o dbc-connection-descriptor, descrito

ySQL). no repository

responsvel por armazenar estas informaes, entre elas, o driver, o protocolo, a loca lizao do

banco de dados e os dados de usurio, descritas abaixo (Listagem 4.1): < dbc-connection-descriptor cd-alias="MYSQLCON" default-connection="true" plataform="MySQL" dbc-level="2.0" driver="com.mysql. dbc.Driver" protocol=" dbc" subprotocol="mysql" dbalias="//localhost:3306/controle_financeiro" username="root" password="" batch-mode="false" > Listagem 4.1: Parmetros de Conexo JDBC Configura-se tambm o elemento sequence-manager, com o valor compatvel com o banco em questo. Este atributo o responsvel pela gerao de OIDs do OJB. No caso, 67 ----------------------- Page 68----------------------utilizamos o prprio recurso de gerao de sequncias do banco de dados (Listagem 4.2). <sequence-manager className=org.apache.o b.broker.util.sequence. SequenceManagerNativeImpl> </sequence-manager> Listagem 4.2: Sequence Manager umento Em seguida, XML descrevem-se os respectivos mapeamentos no doc

repository_user, que contm as especificaes da forma como as classes sero mapeadas no

banco de dados. Este arquivo referenciado pelo repository.xm atravs da notao XML &, que indica a chamada a outros arquivos na mesma estrutura. fine-se Para a nossa o seguinte classe Conta, relacionada classe Transao, de

mapeamento de atributos primitivos (Listagem 4.3): <field-descriptor name="codConta" column="COD_CONTA" dbc-type="INTEGER" primarykey="true" autoincrement="false" access="readonly" />

<field-descriptor name="descricao" column="DESCRICAO" dbc-type="VARCHAR" /> Listagem 4.3: apeamento de atributos O relacionamento para-muitos, por sua vez, define-se atravs do elemento de coleo <collection-descriptor> (Listagem 4.4): <collection-descriptor name="transacoes" element-classref="br.com.mackenzie.controlefinanceiro.Transacao" auto-retrieve="true" auto-update="true" auto-delete="true"> <inverse-foreignkey field-ref="codConta" /> </collection-descriptor> Listagem 4.4: apeamento de colees 68 ----------------------- Page 69----------------------Para cada caso de relacionamento para-muitos, deve ser definida uma coleo, ao contrrio de uma relao um-para-um, onde se definiria um <reference-descriptor> s imples, como pode ser visto no mapeamento abaixo, referente classe Transao (Listagem 4.5) : <reference-descriptor name="contas" class-ref="br.com.mackenzie.controlefinanceiro.Conta" > <foreignkey field-ref="codConta" /> </reference-descriptor> Listagem 4.5: apeamento 1:1 As classes Java da aplicao encontram-se divididas em classes de acesso aos dados (objetos DAO) e classes de negcio (Value Obj ects), com o objetivo de isolar os c omponentes responsveis pela camada de apresentao (no caso, uma interface hipottica) das camadas de negcio e de acesso aos dados. A comunicao entre as regras de negcio e a camada de dados ocorre a

travs dos JavaBeans, que se responsabilizam por efetuar a conexo entre a interface e a classe DAO respectiva. Os JavaBeans utilizados so classes serializadas com s pblicos, que atributo

mantm os valores em um bean, removendo a necessidade de mltiplas chamadas para mtod os que retornam um nico valor, que resultariam em uma queda de performance significa tiva. Seguindo esta componentizao, a classe Contas apresenta os mtodos de atribuio e recuperao de valores (getter/setters) (Listagem 4.6): public class Conta implements Serializable{ private int codConta; private String descricao; public String getDescricao() {return descricao;} public void setDescricao(String descricao) { this.descricao = descricao; } public int getCodConta() {return codConta;} } Listagem 4.6: Classe Conta 69 ----------------------- Page 70----------------------No h regra de negcio para a atribuio de cdigo (codConta), pois como pode ser observado no esquema do banco de dados (ANEXO B), o campo CodConta se quencial, atribudo automaticamente pelo SGBDR. Por ltimo, tem-se a definio das classes DAO referentes ao objeto Co nta. Foram criadas duas classes, uma responsvel pelas operaes de INSERT, UPDATE e D ELETE (OperacoesContas) e outra para a consulta dos valores do objeto (ConsultaContas) . O f ramework tem como base de funcionamento a classe Persistenc eBroker (PB Listagem 4.7), que deve ser instanciada no construtor de cada classe DAO: public OperacaoContas(PersistenceBroker broker) { this.broker = broker;

} Listagem 4.7: Persistence Broker As operaes so efetuadas com base no PB, a API de mais baixo nvel do OJB, que faz a interface com o -se pelas tradues mecanismo de persistncia. O PB responsabiliza

necessrias entre as camadas e pelo gerenciamento das transaes. Um INSERT, por exemplo, consistiria nas operaes a seguir (Listagem 4.8): broker.beginTransaction(); broker.store(conta); broker.commitTransaction(); Listagem 4.8: INSERT via f ramework de OR Desta forma, todas as operaes seguem a mesma lgica orientada a objetos (obj etos, mtodos e mensagens). A operao de consulta necessita da declarao de um iterador para receber o valor de cada coluna. O critrio de consulta, por sua vez, deve ser uma instncia da classe Criteria. Esta classe tem mtodos de consulta equivalentes aos encontrados na linguagem SQL (addEqualTo para o operador '=', addGreaterThan, para o operador '>', entre outros). A referncia dos mtodos da classe Criteria encontra-se na documentao da API do OJB. 70 ----------------------- Page 71----------------------a Um classe exemplo DAO de consulta na classe Conta, implementado pel

ConsultaConta, segue abaixo (Listagem 4.9): Criteria criteria = new Criteria(); try{ criteria.addEqualTo("codConta",new Integer(idConta)); Query queryConta = new QueryByCriteria(Conta.class, criteria); Iterator i = broker.getIteratorByQuery(queryConta); if(i.hasNext()){ c = (Conta)i.next(); } else {

System.out.println("Registro no encontrado."); } } Listagem 4.9: Consulta via classe Criteria Isto resume as principais operaes e conceitos envolvidos na utilizao do f ra mework de OR, OJB. O cdigo completo e comentado da aplicao deste estudo de caso encontr a-se em (ANEXO C). 4.5. Comparativos a Com a apresentao utilizao da do estudo de caso, procurou-se demonstrar

orientao a objetos em toda a aplicao, inclusive nas questes de persistncia de objetos em SGBDR, devido utilizao do f ramework de OR como camada de persistncia.

Sem o desenvolvimento de uma camada de persistncia, o acesso ao SGBD ocor reria via programao SQL embutida no cdigo, o que contraria os princpios do paradigma O.O., especialmente no que diz respeito aos fatores de encapsulamento e reutilizao de cdi go. A seguir, sero apresentados alguns exemplos para ilustrar esta situao. O exemplo da pgina seguinte (Listagem 4.10) apresenta a implementao da c lasse DAO equivalente classe Conta, descrita na seo anterior, porm utilizando chamadas JD BC 71 ----------------------- Page 72----------------------nativas: import ava.sql.*;

class Conta { String url = " dbc:msql://localhost/controle_financeiro"; String username = "username"; String passwd = "password";

Connection con = null; Statement st = null; try { Class.forName("com.mysql. dbc.Driver").newInstance(); con = DriverManager.getConnection(url, username, passwd); con.setAutoCommit(false); st = con.createStatement(); st.executeUpdate("INSERT INTO contas " + "VALUES (1, 'Carto de crdito')"); con.commit(); } catch(Exception ex) { con.rollback(); } finally { con.close(); } } Listagem 4.10: Classe DAO JDBC s est se trabalhando com SQL diretamente. A probabilidade de erros no cdigo so maiores, pois h um novo fator de erro em potencial, o erro no cdigo SQL. Alm disso, h uma nova preocupao: o estado da transao. importante que defina o "rollback " explicitamente, caso ocorra uma exceo, neste tipo de soluo m anual. Atravs de um f ramework como o OJB, estas questes so lidadas automaticamente. No h nenhum tipo de encapsulamento na utilizao manual de JDBC: os valores so 72 ----------------------- Page 73----------------------passados diretamente aos atributos da classe DAO. A reutilizao do cdigo prejudicada

O conhecimento estrutural da tabela Contas necessrio neste tipo de soluo, po

, por estar intimamente ligada com a estrutura do banco utilizado e a sintaxe SQL do m esmo. O f ramework divide esta mesma operao em dois componentes: Primeiro, a atribuio de valores deve ser efetuada atravs de u m JavaBean (Listagem 4.11): Conta conta = new Conta(); OperacaoContas opeConta = new OperacaoContas(broker);

conta.setDescricao("Lo a de Roupas"); opeConta.inserir(conta); Listagem 4.11: Atribuio de valores ao objeto Conta dos Segundo, dados uma classe DAO responsabiliza-se pela manipulao

(Listagem 4.12): public void inserir(Conta contaVO) throws DataAccessException { PersistenceBroker broker = null; try { broker = ServiceLocator.getInstance().findBroker();

broker.beginTransaction(); broker.store(contaVO); broker.commitTransaction();

} catch (PersistenceBrokerException pbe) {} }

Listagem 4.12: todo INSERT da classe DAO A programao JDBC nativa apresenta-se como uma soluo de maior complexidade especialmente para consultas ao banco de dados. No caso da consulta d e uma transao,

73 ----------------------- Page 74----------------------exemplificada no estudo de caso (ANEXO C), o cdigo JDBC para tanto encontra-se a seguir (Listagem 4.13): String tabelas = "itens, instituicoes, contas, transacoes"; StringBuffer sb = new StringBuffer(); sb.append("itens.COD_ITEM = 1"); sb.append("AND instituicoes.COD_INST = 1"); sb.append("AND contas.COD_CONTA = 1"); sb.append("AND transacoes.COD_CONTA = conta.COD_CONTA"); sb.append("AND transacoes.COD_ITEM = itens.COD_ITEM"); sb.append("AND transacoes.COD_INST = instituicoes.COD_INST"); String query = "select * from " + tabelas + "where " + sb; try { Class.forName("com.mysql. dbc.Driver").newInstance(); Connection con = DriverManager.getConnection(url, username, password); Statement stmt = con.createStatement(); ResultSet rs = stmt.executeQuery(query); ResultSetMetaData rsmd = rs.getMetaData(); int numberOfColumns = rsmd.getColumnCount(); while (rs.next()) { for (i = 1; i <= numberOfColumns; i++) { System.out.print(rs.getString(i)); } System.out.println(); } stmt.close(); con.close();

} catch(SQLException ex) {}

Listagem 4.13: Consulta via JDBC 74 ----------------------- Page 75----------------------Como pode ser observado na listagem 4.13, para efetuar uma conexo JDBC, i nstanciase o driver, indica-se o endereo do banco e os parmetros de acesso diretamente na aplicao. Atravs da camada de persistncia, a mesma consulta poderia ser efetuada com muito menos esforo de programao, como pode ser observado abaixo (Listagem 4.14): Criteria criteriaTransacao = new Criteria(); // oin implcito criteriaTransacao.addEqualTo("instituicoes.codInstituicao", "1"); criteriaTransacao.addEqualTo("contas.codConta", "1"); criteriaTransacao.addEqualTo("itens.codItem", "1");

Query query = QueryFactory.newQuery(Transacao.class, criteriaTransacao,true); Iterator i = broker.getIteratorByQuery(query); Transacao t = null; while(i.hasNext()){ t = (Transacao) i.next(); System.out.println(t.getDescricao()); } Listagem 4.14: Consulta via f ramework de OR Atravs de uma soluo manual utilizando JDBC, a aplicao perde em flexibilidade, portabilidade, escalabilidade, eficincia e produtividade em geral. Para sistemas de maior nvel de complexidade, comuns em ambientes corporativos que lidam com alto volume de d ados e

esquemas de bancos complexos, o desenvolvedor necessitaria conhecer a estrutura do banco em questo, a sintaxe SQL especfica e efetuar junes complexas para manipular os dados em uma aplicao O.O.. A camada de persistncia permite a abstrao da camada de dados, e assim, o cdi go passa a independer da configurao do banco. Os componentes da aplicao so isolados do 75 ----------------------- Page 76----------------------mecanismo de persistncia. Se houver alteraes na estrutura do banco, ou de banco par a outro mecanismo de persistncia, elas no refletiro na aplicao, somente nos descritores X L. Um f ramework de izaes no que diz OR disponibiliza, em geral, diversas otim

respeito ao acesso aos dados, entre elas, a manuteno de um cache de obj etos, suporte a

transaes distribudas, p ool de conexes, compartilhamento de sesses, alm da possibilid de de se efetuar operaes de persistncia de objetos A implementao manual destas operaes via cdigo JDBC, por sua vez, uma tarefa complexa e trabalhosa, comparando-se util izao dos recursos de um f ramework de stas operaes automaticamente e via descries X 76 ----------------------- Page 77----------------------CONCLUSES Para qualquer sistema de informao, a persistncia dos dados um fator fundame ntal. A persistncia de dados pode ser feita atravs da gravao dos dados em um dispositivo d e armazenamento secundrio. Entretanto, as limitaes destes mecanismos em aplic aes de OR, como o OJB, que efetua muitas de L (sem a necessidade da codificao).

mdio a grande porte, que envolvem um volume relativamente grande de dados e neces sidades de consulta e controle de concorrncia, trouxeram a necessidade dos sistemas geren ciadores de bancos de dados (SGBD). Nesta categoria, destaca-se o modelo relacional, que pr ovou ao longo das dcadas desde sua concepo, ser um mecanismo eficiente e confivel de armazenamento de dados, possibilitando a manipulao, a manuteno da integridade e a segurana dos dado s. A persistncia de objetos, por sua vez, envolve o paradigma da orientao a ob jetos, que difere em diversos aspectos do paradigma dados, possuem relacional. Objetos, alm de

comportamento. Objetos podem ser multi-valorados, englobando objetos complexos o u mesmo outros objetos, e terem atributos provenientes de relacionamentos (herana) com ou tros objetos. Estas, entre outras caractersticas, trazem uma camada de complexidade a mais no mb ito da persistncia. Alguns dos mtodos de persistncia de objetos incluem a serializao, o mapeamen to dos objetos em documentos X os SGBDOR e os SGBDOO. Porm, no contexto atual, os SGBDR representam o mecanismo de persistncia d e maior aceitao e maturidade. Por outro lado, a orientao a objetos nas camadas de negcio , e a metodologia U envolvimento L de anlise de sistemas j constituem o paradigma de des L, e SGBD que suportam esta tecnologia, como

dominante no mercado. Este fato leva a uma impedncia entre o modelo da aplicao e o modelo de dado s. A persistncia de objetos por meio da tcnica de mapeamento de objeto relacional permi te que 77

----------------------- Page 78----------------------contorne-se a impedncia existente entre as metodologias O.O. e relacional, aprove itando assim os benefcios de ambas metodologias. Para lidar com bancos relacionais em sistemas O.O., os desenvolvedores q ue no optam pelo desenvolvimento de uma camada de persistncia, muitas vezes vo de e ncontro aos fundamentos da O.O., de reutilizao e portabilidade do cdigo. A partir do momento em que h o acoplamento da aplicao ao modelo de dados, qualquer mudana no esquema do banco af eta diretamente a aplicao, sendo necessrio o retrabalho na adaptao de todas as cl asses de acesso ao banco. Dependendo do grau de complexidade da aplicao, o custo da reestru turao dos sistemas ser altssimo, o que prova que a falta de separao entre as camadas de da dos e negcios resultam na ineficincia da aplicao como um todo. O propsito do arente entre aplicao orientada a objeto e o mecanismo de persistncia relacional. O mecanis mo de MOR atua na traduo transparente entre os modelos, exceto no processo de mapeamento , que envolve a definio de metadados em arquivo descritor, geralmente X L. OR , basicamente, prover uma camada de persistncia transp

A utilizao de tcnicas de MOR, em especial atravs de f rameworks de OR, como o OJB, apresentado no estudo de caso, possibilita s empresas que tem como base SGBDR,

direcionarem seus investimentos em inovao e tecnologia, com a utilizao de solues O.O. e, ao mesmo tempo, manterem a confiabilidade, segurana, e tradio dos bancos de dados relacionais. Atravs do lacional e a OR diminui-se o acoplamento entre o modelo de dados re

aplicao O.O., permitindo a portabilidade e a escalabilidade futura das aplicaes, e e nfim, a diminuio do custo de manuteno do software.

Entretanto, o sucesso desta abordagem tem dependncia intrnseca com a forma como o sistema foi estruturado, e podem no trazer o resultado esperado caso o pro jeto do banco relacional seja inadequado, assim uam requisitos de processamento analtico (OLAP). 78 ----------------------- Page 79----------------------REFERNCIAS BIBLIOGRFICAS st [A B98] Cambridge: A BLER, S. W. Building Object App ications that Work. 1 ed. Cambridge University Press, 1998. [A B01] A BLER, S. W. Strategies for Storing Java s. Java Deve oper's Journa . New Jersey, v. 6, n. 8, p. 62-70, Aug 2001. [A B03] ley & Sons, [ATK89] anifesto. A 2003. ATKINSON, M.; et al. The Object-Oriented Database System M Object como no caso de projetos que poss

st BLER, S. W. Agile Database Techniques. 1 ed. New York: Wi

Proceedings of the First International Conference on Ded uctive and ObjectOriented Databases, Japan, 1989. Disponvel em: <http://citeseer .ist.psu.edu/at kinson89objectoriented.html>. Acesso em: 11 dez, 2003. [BER02] BERGLAS, Anthony. Object Re ationa Mapping Too s. SimpleOR Whitepaper, 2002. Disponvel em: <http://www.simpleorm.org/OR Tools.ht ml>. Acesso em: 10 fev. 2004.

[BJW87] A simp e gs 7.

BIRRELL, J.; JONES; . WOBBER, E. and efficient imp ementation for sma databases. Proceedin of the 11th AC Symposium on Operating System Principles, S.l, 198 Disponvel em: <http://birrell.org/andrew/papers/>. Acesso em: 11 dez, 2003. CATTELL, R.; et al. The Object Data Standard: ODMG 3.0. San Fr organ Kaufmann, 2000.

[CAT00] ancisco:

[COD70] Banks.

CODD, E. F. A Re ationa Mode

of Data for Large Shared Data

Communications of the AC , v. 13, n. 6, 1970, pp . 377-387. Disponvel em: <http://www.acm.org/classics/nov95/>. Acesso em: 10 jan. 2004. [DAT00] Janeiro: [DAT95] 24, n. DATE, C. J. Introduo a Sistemas de Bancos de Dados. 7 ed. Rio de Editora Campus, 2000. DATE, C. J.; DARWEN, H. The Third Manifesto. SIGMOD Record, v.

1. S.l., 1995. Disponvel em: <http://citeseer.ist.psu.edu/ darwen95third.html>. Acesso em: 01 fev. 2004. [ECK02] 2002. [EI 99] known as ECKEL, B. Thinking in Java. 3rd ed. New Jersey: Prentice Hall,

EISENBERG, A.; ELTON, Jim. SQL:1999, formely SQL3. SIG OD Record, v. 28, n. 1, pp. 131-138. S.l, 1999. Disponvel em: <http://dbs.uni-leipzig.de/en/lokal/standards.pdf>. Acesso em: 01 fev 2004. [FAS97] ping. S. l/>. Acesso em: 01 fev. 2004. 79 ----------------------- Page 80----------------------[FLA97] FLANAGAN, D. Java in a Nutshe : O'Reilly, 1997. . 2nd ed. New York l., FASSELL, . Foundations of Object Oriented Map 1997. Disponvel em: <http://www.chimu.com/publications/objectRelationa

[FOW02] FOWLER, . Patterns of Enterprise App ication Architect ure. 1st ed. New York: Addison-Wesley, 2002. [IB 00] Techno ogies. sso em: 10 jan 2004. [IB 02] the UML. sso em: 10 jan 2004. [JOH03] cago: JOHNSON, R. Expert One-on-One J2EE Design and Deve opment. Chi Wrox Press, 2003. IB Rational Whitepapers. Mapping Object to Data Mode with IB Rational Whitepapers. Integrating Object and Re ationa

Disponvel em: <http://www.rational.com/media/whitepapers>. Ace

Disponvel em: <http://www.rational.com/media/whitepapers/>. Ace

[KEL97] eedings of 97. Siemens

KELLER, W. Mapping Objects to Tab es: A Pattern Language. Proc the European Pattern Languages Conference, Irrsee, Germany: 19 Technical Report 120/SW1/FB.

[KRO99] undamentals,

KROENKE, D. Design and Implementation. 7

. Database

Processing:

th ed. New Jersey: Prentice Hall, 1999.

[LER99] D O/R. iblioteca central

LER

EN, A. Um framework de mapeamento ODMG para SGB estrado, UFRS, 1999. Disponvel na b

Cap. 4. Dissertao de da UNICA [ UE97] ing in eller/Cours e/>. Acesso em: 01 fev. 2004. [ UL99] L for Data UELLER, C++. P. P. Introduction

to

Object-Oriented

Programm

Berlin, 1997. Disponvel em: <http://www.zib.de/Visual/people/mu

ULLER, R. Database Design for Smarties: Using U odeling. st organ Kaufmann, 1999.

1 ed. San Francisco: [OBJ03] . Disponvel . Acesso em: 10 jan, 2004. [QUA99] ese [RIC96] CA/FEE courses/>. Acesso em: 02 fev. 2004. [RAJ02] e Java Beans. RO AN, E.; A OBJECT

ATTER. Mapping Too Guide: Visual BSF, 1998-2003

em <http://www.objectmatter.com/vbsf/docs/maptool/guide.html>

QUADROS, N. Um arcabouo ref exivo para persistncia de objetos. T de ps-graduao, Lab. de Sistemas Distribudos do IC, UNICAMP, 1999. RICARTE, I. L. Programao Orientada a Objetos com C++. D UNICAMP, 1996. Disponvel em: <http://www.dca.fee.unicamp.br/

BLER, S. JEWELL, T. Mastering Enterpris

2nd ed. New York: Wiley, 2002. 80 ----------------------- Page 81----------------------st BAUGH, J.; et al. Object-Oriented Mode ing and Design

[RUM90] . 1 ed. New

RU

Jersey: Prentice-Hall, 1990.

[SKS01] Systems

SILBERSCHATZ,

A;

KORTH,

H.; SUDARSHAN,

S. Database

Concepts. 4th ed. Boston:

cGraw-Hill, 2001.

[SPE03] APress, 2003.

st SPERKO, R. Java Persistence for Re ationa Databases. 1 ed.

[STO90] STONEBRAKER, .; et al. Third-Generation Datab ase System Manifesto. SIG OD Record, v.19 n.3, p.31-44. S.l, 1990. Disponvel em: <http://citeseer.ist.psu.edu/for90thirdgeneration.html> Acess o em: 02 fev. 2004. st THOMAS, T. ed. New York: &T: 2002.

[THO02] d JAXP. 1

. Java Data Access: JDBC, JNDI, an

[W3C04] . 3rd ed. W3C TR/2004/REC-

BRAY, T.; et al. Extensible Markup Language (XML) 1.0 Recommendation Paper. Disponvel em: <http://www.w3.org/

xml-20040204/>. Acesso em: 10 jan. 2004. st [WIL00] WILLIA ed. Chicago: Wrox Press, 2000. [WOL03] ming. >. Acesso em: 10 abr. 2004.

S, K.; et al. Professiona XML Databases. 1

WOLFGANG, K.; Persistence Options for Object-Oriented Program Alemanha, 2004. Disponvel em: <http://www.objectarchitects.de/

81 ----------------------- Page 82----------------------ANEXO A: Scrip t de criao do banco de dados. # controle_financeiro.sql CREATE DATABASE controle_financeiro; USE controle_financeiro; CREATE TABLE `contas` ( `COD_CONTA` int(11) NOT NULL auto_increment, `DESCRICAO` varchar(50) NOT NULL default '', PRIMARY KEY (`COD_CONTA`) ) TYPE=INNODB;

CREATE TABLE `instituicoes` ( `COD_INSTITUICAO` int(11) NOT NULL auto_increment, `DESCRICAO` varchar(50) NOT NULL default '', PRIMARY KEY (`COD_INSTITUICAO`) ) TYPE=INNODB; CREATE TABLE `itens` ( `COD_ITEM` int(11) NOT NULL auto_increment, `DESCRICAO` varchar(50) NOT NULL default '', PRIMARY KEY (`COD_ITEM`) ) TYPE=INNODB; CREATE TABLE transacoes ( COD_CONTA int(11) not null, COD_ITEM int(11) not null, COD_INSTITUICAO int(11) not null, valor double not null default '0', tipo char not null default '', data datetime not null, PRIMARY KEY (COD_ITEM, COD_CONTA, COD_INSTITUICAO), INDEX (COD_ITEM), INDEX (COD_CONTA), INDEX (COD_INSTITUICAO), CONSTRAINT FK_CONTA_TRAN FOREIGN KEY(COD_CONTA) REFERENCES contas (COD_CONTA), CONSTRAINT FK_INST_TRAN FOREIGN KEY(COD_INSTITUICAO) REFERENCES instituicoes(COD_INSTITUICAO), CONSTRAINT FK_ITEM_TRAN FOREIGN KEY(COD_ITEM) REFERENCES itens(COD_ITEM) ) TYPE=INNODB; 82 ----------------------- Page 83----------------------ANEXO B: XML de conexo e mapeamento. repository.xml <?xml version="1.0" encoding="ISO-8859-1"?> <!-- Arquivo de Configurao do OJB: Configuraes de Conexo --> <!DOCTYPE descriptor-repository SYSTEM "repository.dtd" [ <!ENTITY internal SYSTEM "repository_internal.xml"> <!ENTITY user SYSTEM "repository_user.xml"> ]> <descriptor-repository version="1.0" isolation-level="read-uncommitted"> <!-- Configurao do Banco de Dados que iremos utilizar (MySQL) --> < dbc-connection-descriptor cd-alias="MYSQLCON" default-connection="true" plataform="MySQL" dbc-level="2.0" driver="com.mysql. dbc.Driver" protocol=" dbc" subprotocol="mysql" dbalias="//localhost:3306/controle_financeiro" username="root" password="" batch-mode="false"

> <!-- Configurao do Pool da Conexo --> <connection-pool maxActive="5" ValidationQuery="" /> <sequence-manager className="org.apache.o b.broker.util.sequence.SequenceManagerNativeImpl"> </sequence-manager> </ dbc-connection-descriptor> <!-- Arquivo XML que contem os mapeamentos internos do OJB --> &internal; <!-- Arquivo XML que contem os mapeamentos definidos pelo desenvolvedor --> &user; </descriptor-repository> 8 3 ----------------------- Page 84----------------------repository_user.xml <?xml version="1.0" encoding="ISO-8859-1"?> <!-- Arquivo de Configurao do mapeamento O/R da aplicao --> <!-- Inicio do mapeamento da tabela CONTAS --> <class-descriptor class="br.com.mackenzie.controlefinanceiro.Conta" table="CONTAS" > <field-descriptor name="codConta" column="COD_CONTA" dbc-type="INTEGER" primarykey="true" autoincrement="false" access="readonly" /> <field-descriptor name="descricao" column="DESCRICAO" dbc-type="VARCHAR" /> <collection-descriptor name="transacoes" element-class-ref="br.com.mackenzie.controlefinanceiro.Transacao" auto-retrieve="true" auto-update="true" auto-delete="true"> <inverse-foreignkey field-ref="codConta" />

</collection-descriptor> </class-descriptor> <!-- Fim do Mapeamento da tabela CONTAS --> <!-- Inicio do mapeamento da tabela INSTITUICOES --> <class-descriptor class="br.com.mackenzie.controlefinanceiro.Instituicao" table="INSTITUICOES" > <field-descriptor name="codInstituicao" column="COD_INSTITUICAO" dbc-type="INTEGER" primarykey="true" autoincrement="false" access="readonly" /> <field-descriptor name="descricao" column="DESCRICAO" dbc-type="VARCHAR" /> <collection-descriptor name="transacoes" element-class-ref="br.com.mackenzie.controlefinanceiro.Transacao" 84 ----------------------- Page 85----------------------auto-retrieve="true" auto-update="true" auto-delete="true"> <inverse-foreignkey field-ref="codInstituicao" /> </collection-descriptor> </class-descriptor> <!-- Fim do Mapeamento da tabela INSTITUICOES --> <!-- Inicio do mapeamento da tabela ITENS --> <class-descriptor class="br.com.mackenzie.controlefinanceiro.Item" table="ITENS" > <field-descriptor name="codItem" column="COD_ITEM" dbc-type="INTEGER" primarykey="true" autoincrement="false" access="readonly" /> <field-descriptor name="descricaoItem" column="DESCRICAO" dbc-type="VARCHAR" />

<collection-descriptor name="transacoes" element-class-ref="br.com.mackenzie.controlefinanceiro.Transacao" auto-retrieve="true" auto-update="true" auto-delete="true"> <inverse-foreignkey field-ref="codItem" /> </collection-descriptor> </class-descriptor> <!-- Fim do Mapeamento da tabela ITENS --> <!-- Inicio do mapeamento da tabela TRANSACOES --> <class-descriptor class="br.com.mackenzie.controlefinanceiro.Transacao" table="TRANSACOES" > <field-descriptor name="codConta" column="COD_CONTA" dbc-type="INTEGER" primarykey="true" /> <field-descriptor name="codItem" column="COD_ITEM" dbc-type="INTEGER" primarykey="true" /> <field-descriptor name="codInstituicao" 85 ----------------------- Page 86----------------------column="COD_INSTITUICAO" dbc-type="INTEGER" primarykey="true" /> <field-descriptor name="data" column="DATA" dbc-type="DATE" /> <field-descriptor name="valor" column="VALOR" dbc-type="FLOAT" /> <field-descriptor name="tipo" column="TIPO" dbc-type="VARCHAR" /> <!-- Referencia tabela Itens --> <reference-descriptor name="itens" class-ref="br.com.mackenzie.controlefinanceiro.Item"

> <foreignkey field-ref="codItem" /> </reference-descriptor> <!-- Referencia tabela Contas --> <reference-descriptor name="contas" class-ref="br.com.mackenzie.controlefinanceiro.Conta" > <foreignkey field-ref="codConta" /> </reference-descriptor> <!-- Referencia tabela Instituicoes --> <reference-descriptor name="instituicoes" class-ref="br.com.mackenzie.controlefinanceiro.Instituicao" > <foreignkey field-ref="codInstituicao" /> </reference-descriptor> </class-descriptor> <!-- Fim do Mapeamento da tabela TRANSACOES --> 86 ----------------------- Page 87----------------------ANEXO C: Cdigo do estudo de caso. /* * Classe ControleFinanceiro * */ import br.com.mackenzie.controlefinanceiro.Conta; import br.com.mackenzie.controlefinanceiro.dao.OperacaoContas; import br.com.mackenzie.controlefinanceiro.Item; import br.com.mackenzie.controlefinanceiro.dao.OperacaoItens; import br.com.mackenzie.controlefinanceiro.Instituicao; import br.com.mackenzie.controlefinanceiro.dao.OperacaoInstituicoes; import br.com.mackenzie.controlefinanceiro.Transacao; import br.com.mackenzie.controlefinanceiro.dao.OperacaoTransacoes; import br.com.mackenzie.controlefinanceiro.dao.ConsultaTransacoes; import org.apache.o b.broker.PersistenceBroker; import org.apache.o b.broker.PersistenceBrokerFactory; import ava.util.Date; /** * * @author Reinaldo/Camila * * Esta classe tem como ob etivo, gravar algumas informaes * no banco de dados, e efetuar uma consulta utilizando uma * tcnica de INNER JOIN. */ public class ControleFinanceiro {

public static void main(String[] args) { //Cria e instancia classe de conexo com banco de dados(Via arquivo XML). final PersistenceBroker broker; broker = PersistenceBrokerFactory.defaultPersistenceBroker(); /*INSERE REGISTROS NA TABELA CONTAS*/ try{ //Cria e instancia classe de contas e operaes na conta. Conta conta = new Conta(); OperacaoContas opeConta = new OperacaoContas(broker); //Insere registros na tabela contas. conta.setDescricao("Lo a de Roupas"); opeConta.inserir(conta); conta.setDescricao("Lo a de Sapatos"); opeConta.inserir(conta); conta.setDescricao("Lo a de Brinquedos"); opeConta.inserir(conta); conta.setDescricao("Lo a de Automoveis"); 87 ----------------------- Page 88----------------------opeConta.inserir(conta); } catch (Exception e){ System.out.println("Erro ao inserir dados das contas." + e.getMessage()); System.exit(0); } /*INSERE REGISTROS NA TABELA INSTITUICOES*/ try{ //Cria e instancia classe de instituicoes e operaes na instituicao. Instituicao instituicao = new Instituicao(); OperacaoInstituicoes opeinstituicao = new OperacaoInstituicoes(broker); //Insere registros na tabela instituicao. instituicao.setDescricao("DasRoupas SA"); opeinstituicao.inserir(instituicao); instituicao.setDescricao("Sapataria So Miguel"); opeinstituicao.inserir(instituicao); instituicao.setDescricao("Brinquedolandia SA"); opeinstituicao.inserir(instituicao); instituicao.setDescricao("CarraoNaHora SA"); opeinstituicao.inserir(instituicao); } catch (Exception e){ System.out.println("Erro ao inserir dados das instituicoes." + e.getMessage()); System.exit(0); } /*INSERE REGISTROS NA TABELA ITENS*/ try{ //Cria e instancia classe de itens e operaes no item.

Item item = new Item(); OperacaoItens opeitem = new OperacaoItens(broker); //Insere registros na tabela item. item.setDescricaoItem("Camisas"); opeitem.inserir(item); item.setDescricaoItem("Calcas"); opeitem.inserir(item); item.setDescricaoItem("Meias"); opeitem.inserir(item); item.setDescricaoItem("Sapatos"); opeitem.inserir(item); item.setDescricaoItem("Tennis"); opeitem.inserir(item); item.setDescricaoItem("Carrinhos"); opeitem.inserir(item); item.setDescricaoItem("Bolas"); opeitem.inserir(item); item.setDescricaoItem("Gol"); opeitem.inserir(item); item.setDescricaoItem("Uno"); opeitem.inserir(item); item.setDescricaoItem("BMW"); opeitem.inserir(item); } 88 ----------------------- Page 89----------------------catch (Exception e){ System.out.println("Erro ao inserir dados dos itens." + e.getMessage()); System.exit(0); } /*INSERE REGISTROS NA TABELA TRANSACOES*/ try{ //Cria e instancia classe de transacoes e operaes na transacao. Transacao transacao = new Transacao(); OperacaoTransacoes opetransacao = new OperacaoTransacoes (broker); //Insere registros na tabela transacao. transacao.setCodigoConta(1); transacao.setCodigoInstituicao(1); transacao.setCodigoItem(1); transacao.setData(new Date()); transacao.setValor(127); transacao.setTipo("D"); opetransacao.inserir(transacao); transacao.setCodigoConta(3); transacao.setCodigoInstituicao(3); transacao.setCodigoItem(7); transacao.setData(new Date()); transacao.setValor(50); transacao.setTipo("D"); opetransacao.inserir(transacao); }

catch (Exception e){ System.out.println("Erro ao inserir dados das transacoes." + e.getMessage()); System.exit(0); } /*CONSULTA REGISTROS A PARTIR DE UMA QUERY SQL(NAO ACONSELHAVEL)*/ try{ //Cria e instancia classe de consulta de transacoes. ConsultaTransacoes consultaTransacaoSQL = new ConsultaTransacoes(broker); //Cria um array para receber o resultado da consulta. Transacao transacoes[] = null; //Recebe o array de transaes com os dados selecionados. transacoes = consultaTransacaoSQL.findTransacaoByChave (1,1,1); //Mostra o resultado da consulta SQL em tela. if(transacoes.length>0){ for(int i=0; i < transacoes.length; i++){ //Exibe os dados encontrados. Conta contas = transacoes[i].getConta(); System.out.println("Conta = " + contas.getDescricao() ); Instituicao instituicoes = transacoes[i]. getInstituicoes(); System.out.println("Instituicao = " + instituicoes.getDescricao()); Item itens = transacoes[i].getItens(); 89 ----------------------- Page 90----------------------System.out.println("Item = " + itens.getDescricaoItem()); System.out.println("Data = " + transacoes[i]. getData().toString()); System.out.println("Valor = " + transacoes[i]. getValor()); System.out.println("Tipo = " + transacoes[i]. getTipo()); System.out.println("\n\n"); } } } catch (Exception e){ System.out.println("Erro ao consultar dados das transaes: " + e.getMessage() + " - " + e.toString()); System.exit(0); } } } /* * Classe Conta * */ package br.com.mackenzie.controlefinanceiro; import ava.io.Serializable;

/** * * @author Reinaldo/Camila * Esta classe representa a tabela CONTAS no banco de dados. */ public class Conta implements Serializable{ /*Propriedades*/ private int codConta; private String descricao; /*Referenciado pela FK*/ private Transacao[] transacoes; /** * @return Returns the descricao. */ public String getDescricao() { return descricao; } /** * @param descricao The descricao to set. */ public void setDescricao(String descricao) { this.descricao = descricao; } /** * @return Returns the codConta. */ 90 ----------------------- Page 91----------------------public int getCodConta() { return codConta; } /** * @return Returns the transacoes. */ public Transacao[] getTransacoes() { return transacoes; } /** * @param transacoes The transacoes to set. */ public void setTransacoes(Transacao[] transacoes) { this.transacoes = transacoes; } } /* * Classe Instituicao * */ package br.com.mackenzie.controlefinanceiro;

import br.com.mackenzie.controlefinanceiro.Transacao; /** * * @author Reinaldo/Camila * Esta classe representa a tabela INSTITUICOES no banco de dados. */ public class Instituicao { /*Propriedades*/ private int codInstituicao; private String descricao; /*Referenciado pela FK*/ private Transacao[] transacoes; /** * @return Returns the codInstituicao. */ public int getCodInstituicao() { return codInstituicao; } /** * @param codInstituicao The codInstituicao to set. */ public void setCodInstituicao(int codInstituicao) { this.codInstituicao = codInstituicao; } /** * @return Returns the descricao. 91 ----------------------- Page 92----------------------*/ public String getDescricao() { return descricao; } /** * @param descricao The descricao to set. */ public void setDescricao(String descricao) { this.descricao = descricao; } /** * @return Returns the transacoes. */ public Transacao[] getTransacoes() { return transacoes; } /** * @param transacoes The transacoes to set. */ public void setTransacoes(Transacao[] transacoes) { this.transacoes = transacoes; }

} /* * Classe Item * */ package br.com.mackenzie.controlefinanceiro; /** * * @author Reinaldo/Camila * Esta classe representa a tabela ITENS no banco de dados. */ public class Item { /*Propriedades*/ private int codItem; private String descricaoItem; /*Referenciado pela FK*/ private Transacao[] transacoes; /** * @return Returns the codItem. */ public int getCodItem() { return codItem; } /** * @param codItem The codItem to set. */ public void setCodItem(int codItem) { this.codItem = codItem; } 92 ----------------------- Page 93----------------------/** * @return Returns the descricaoItem. */ public String getDescricaoItem() { return descricaoItem; } /** * @param descricaoItem The descricaoItem to set. */ public void setDescricaoItem(String descricaoItem) { this.descricaoItem = descricaoItem; } /** * @return Returns the transacoes. */ public Transacao[] getTransacoes() { return transacoes; }

/** * @param transacoes The transacoes to set. */ public void setTransacoes(Transacao[] transacoes) { this.transacoes = transacoes; } } /* * Classe Transacao * */ package br.com.mackenzie.controlefinanceiro; import ava.util.Date; import br.com.mackenzie.controlefinanceiro.Item; import br.com.mackenzie.controlefinanceiro.Conta; import br.com.mackenzie.controlefinanceiro.Instituicao; /** * * @author Reinaldo/Camila * Esta classe representa a tabela TRANSACOES no banco de dados. */ public class Transacao { //Propriedades. private int codConta; private int codItem; private int codInstituicao; private Date data; private double valor; private String tipo; //Classes para as FKs. private Item itens; private Conta contas; private Instituicao instituicoes; 93 ----------------------- Page 94----------------------/** * @return Returns the codigoConta. */ public int getCodigoConta() { return codConta; } /** * @param codigoConta The codigoConta to set. */ public void setCodigoConta(int codigoConta) { this.codConta = codigoConta; } /** * @return Returns the codigoInstituicao. */ public int getCodigoInstituicao() {

return codInstituicao; } /** * @param codigoInstituicao The codigoInstituicao to set. */ public void setCodigoInstituicao(int codigoInstituicao) { this.codInstituicao = codigoInstituicao; } /** * @return Returns the codigoItem. */ public int getCodigoItem() { return codItem; } /** * @param codigoItem The codigoItem to set. */ public void setCodigoItem(int codigoItem) { this.codItem = codigoItem; } /** * @return Returns the data. */ public Date getData() { return data; } /** * @param data The data to set. */ public void setData(Date data) { this.data = data; } /** * @return Returns the tipo. */ 94 ----------------------- Page 95----------------------public String getTipo() { return tipo; } /** * @param tipo The tipo to set. */ public void setTipo(String tipo) { this.tipo = tipo; } /** * @return Returns the valor. */

public double getValor() { return valor; } /** * @param valor The valor to set. */ public void setValor(float valor) { this.valor = valor; } /** * @return Returns the contas. */ public Conta getConta() { return this.contas; } /** * @param contas The contas to set. */ public void setConta(Conta conta) { this.contas = conta; } /** * @return Returns the instituicoes. */ public Instituicao getInstituicoes() { return instituicoes; } /** * @param instituicoes The instituicoes to set. */ public void setInstituicoes(Instituicao instituicoes) { this.instituicoes = instituicoes; } /** * @return Returns the itens. */ public Item getItens() { return itens; } 95 ----------------------- Page 96----------------------/** * @param itens The itens to set. */ public void setItens(Item itens) { this.itens = itens; } /** * @param valor The valor to set. */

public void setValor(double valor) { this.valor = valor; } } /* * Classe ConsultaContas * */ package br.com.mackenzie.controlefinanceiro.dao; import ava.util.Iterator; import import import import import org.apache.o org.apache.o org.apache.o org.apache.o org.apache.o b.broker.PersistenceBroker; b.broker.PersistenceBrokerException; b.broker.query.Criteria; b.broker.query.Query; b.broker.query.QueryByCriteria;

import br.com.mackenzie.controlefinanceiro.Conta; /** * * @author Reinaldo/Camila * Esta classe exibe conulta de dados referentes a * tabela CONTAS, de acordo com a chave primaria. */ public class ConsultaContas { //Instancia a classe do Framework. private PersistenceBroker broker; //Contrutor. public ConsultaContas(PersistenceBroker broker){ this.broker = broker; } public Conta findContaByID(int idConta){ //Gera instncia de Conta. Conta c = new Conta(); //Cria ob eto criteria. Criteria criteria = new Criteria(); try{ //Indica o critrio de seleo. criteria.addEqualTo("codConta",new Integer(idConta)); //Gera query utilizando o criterio criado acima. 96 ----------------------- Page 97----------------------Query queryConta = new QueryByCriteria(Conta.class, criteria); //Recebe retorno da consulta. Iterator i = broker.getIteratorByQuery(queryConta); //Caso encontre resultado, retorna valor. if(i.hasNext()){ c = (Conta)i.next();

} else { System.out.println("Registro no encontrado."); } //Limpa variaveis. i = null; queryConta = null; criteria = null; } catch (PersistenceBrokerException e){ System.out.println("Erro: " + e.getClass().getName() + " " + e.getMessage()); } catch (Throwable t){ System.out.println("Erro: " + t.getClass().getName() + " " + t.getMessage()); } finally{ return c; } } } /* * Classe ConsultaInstituicoes * */ package br.com.mackenzie.controlefinanceiro.dao; import ava.util.Iterator; import import import import import org.apache.o org.apache.o org.apache.o org.apache.o org.apache.o b.broker.PersistenceBroker; b.broker.PersistenceBrokerException; b.broker.query.Criteria; b.broker.query.Query; b.broker.query.QueryByCriteria;

import br.com.mackenzie.controlefinanceiro.Instituicao; /** * * @author Reinaldo/Camila * Esta classe exibe conulta de dados referentes a * tabela INSTITUICOES, de acordo com a chave primaria. */ public class ConsultaInstituicoes { //Instancia a classe do Framework. 97 ----------------------- Page 98----------------------private PersistenceBroker broker; //Contrutor. public ConsultaInstituicoes(PersistenceBroker broker){ this.broker = broker; }

public Instituicao findInstituicoesByID(int idInstituicao){ //Gera instncia de Conta. Instituicao ins = new Instituicao(); //Cria ob eto criteria. Criteria criteria = new Criteria(); try{ //Indica o critrio de seleo. criteria.addEqualTo("codInstituicao",new Integer (idInstituicao)); //Gera query utilizando o criterio criado acima. Query queryInstituicao = new QueryByCriteria (Instituicao.class, criteria); //Recebe retorno da consulta. Iterator i = broker.getIteratorByQuery(queryInstituicao); //Caso encontre resultado, retorna valor. if(i.hasNext()){ ins = (Instituicao)i.next(); } else { System.out.println("Registro no encontrado."); } //Limpa variaveis. i = null; queryInstituicao = null; criteria = null; } catch (PersistenceBrokerException e){ System.out.println("Erro: " + e.getClass().getName() + " " + e.getMessage()); } catch (Throwable t){ System.out.println("Erro: " + t.getClass().getName() + " " + t.getMessage()); } finally{ return ins; } } } /* * Classe ConsultaItens * */ package br.com.mackenzie.controlefinanceiro.dao; 98 ----------------------- Page 99----------------------import ava.util.Iterator; import import import import org.apache.o org.apache.o org.apache.o org.apache.o b.broker.PersistenceBroker; b.broker.PersistenceBrokerException; b.broker.query.Criteria; b.broker.query.Query;

import org.apache.o b.broker.query.QueryByCriteria; import br.com.mackenzie.controlefinanceiro.Item; /** * * @author Reinaldo/Camila * Esta classe exibe conulta de dados referentes a * tabela ITENS, de acordo com a chave primaria. */ public class ConsultaItens { //Instancia a classe do Framework. private PersistenceBroker broker; //Contrutor. public ConsultaItens(PersistenceBroker broker){ this.broker = broker; } public Item findItensByID(int idItem){ //Gera instncia de Conta. Item ite = new Item(); //Cria ob eto criteria. Criteria criteria = new Criteria(); try{ //Indica o critrio de seleo. criteria.addEqualTo("codItem",new Integer(idItem)); //Gera query utilizando o criterio criado acima. Query queryItem = new QueryByCriteria(Item.class, criteria); //Recebe retorno da consulta. Iterator i = broker.getIteratorByQuery(queryItem); //Caso encontre resultado, retorna valor. if(i.hasNext()){ ite = (Item)i.next(); } else { System.out.println("Registro no encontrado."); } //Limpa variaveis. i = null; queryItem = null; criteria = null; } catch (PersistenceBrokerException e){ System.out.println("Erro: " + e.getClass().getName() + " " + e.getMessage()); } catch (Throwable t){ 99 ----------------------- Page 100----------------------System.out.println("Erro: " + t.getClass().getName() + " " + t.getMessage());

} finally{ return ite; } } } /* * Classe ConsultaTransacoes * */ package br.com.mackenzie.controlefinanceiro.dao; import ava.util.Iterator; import ava.util.ArrayList; import import import import import org.apache.o org.apache.o org.apache.o org.apache.o org.apache.o b.broker.PersistenceBroker; b.broker.PersistenceBrokerException; b.broker.query.Criteria; b.broker.query.Query; b.broker.query.QueryFactory;

import br.com.mackenzie.controlefinanceiro.Transacao; /** * * @author Reinaldo/Camila * Esta classe exibe conulta de dados referentes a * tabela TRANSACOES, de acordo com a chave primaria. */ public class ConsultaTransacoes { //Instancia a classe do Framework. private PersistenceBroker broker; //Contrutor. public ConsultaTransacoes(PersistenceBroker broker){ this.broker = broker; } public Transacao[] findTransacaoByChave(int idItem, int idInstituicao, int idConta){ //Variavel retorno. Transacao consulta[] = null; //Cria ob eto de criterios de seleo. Criteria criteriaTransacao = new Criteria(); try{ //Indica o critrio de seleo. // ** Para que este tipo de JOIN de tabelas existam, // necessrio que o arquivo repository_user.xml // tenha as chaves das tabelas devidamente ligadas, // em ambas as tabelas, para que as referencias se am // cruzadas, caso contrario gerar um erro. 10 0 ----------------------- Page 101-----------------------

criteriaTransacao.addEqualTo("instituicoes.codInstituicao", "1"); criteriaTransacao.addEqualTo("contas.codConta", "1"); criteriaTransacao.addEqualTo("itens.descricao", new String ("Camisas")); criteriaTransacao.addEqualTo("tipo", new String("D")); //Gera a Query da consulta. Query queryResult = QueryFactory.newQuery(Transacao.class, criteriaTransacao, true); //Recebe resultado da busca. Iterator i = broker.getIteratorByQuery(queryResult); //Caso encontre resultado, gera array de transacoes. ArrayList array = new ArrayList(); while(i.hasNext()){ Transacao conTrans = (Transacao) i.next(); array.add(conTrans); conTrans = null; } //Limpa variaveis. i = null; queryResult = null; criteriaTransacao = null; //Insere os dados do array, num array de Transacoes. if(array.size() > 0){ consulta = new Transacao[array.size()]; for(int =0; <array.size(); ++){ consulta[ ] = (Transacao) array.get( ); } } } catch (PersistenceBrokerException e){ System.out.println("Erro: " + e.getClass().getName() + " " + e.toString()); } catch (Throwable t){ System.out.println("Erro: " + t.getClass().getName() + " " + t.toString()); } finally{ //Retorna array de transacoes. return consulta; } } } /* * Classe OperacaoContas * */ package br.com.mackenzie.controlefinanceiro.dao; import org.apache.o b.broker.PersistenceBroker; import org.apache.o b.broker.PersistenceBrokerException; 101

----------------------- Page 102----------------------import br.com.mackenzie.controlefinanceiro.Conta; /** * * @author Reinaldo/Camila * Esta classe exibe operaes que poder ser realizadas na * tabela CONTAS, de acordo com a instancia informada. */ public class OperacaoContas { private PersistenceBroker broker; public OperacaoContas(PersistenceBroker broker) { this.broker = broker; } //Metodo para Inserir registros. public boolean inserir(Conta conta){ boolean retorno = false; try{ broker.beginTransaction(); broker.store(conta); broker.commitTransaction(); retorno = true; } catch (PersistenceBrokerException e){ try{ broker.abortTransaction(); System.out.println("Erro"); } catch (Exception ex){ System.out.println("Erro"); } System.out.println("Erro"); } catch (Throwable t){ try{ broker.abortTransaction(); System.out.println("Erro"); } catch (Exception ex){ System.out.println("Erro"); } System.out.println("Erro"); } finally{ return retorno; } } //Metodo para Alterar registros public boolean alterar(Conta conta) { boolean retorno = false; try{ broker.beginTransaction(); broker.store(conta);

broker.commitTransaction(); 1 02 ----------------------- Page 103----------------------retorno = true; } catch (PersistenceBrokerException e){ try{ System.out.println("Erro"); broker.abortTransaction(); } catch (Exception ex){ System.out.println("Erro"); } System.out.println("Erro"); } catch (Throwable t){ try{ System.out.println("Erro"); broker.abortTransaction(); } catch (Exception ex){ System.out.println("Erro"); } System.out.println("Erro"); } finally{ return retorno; } } //Metodo para excluir registros public boolean excluir(Conta conta){ boolean retorno = false; try{ broker.beginTransaction(); broker.delete(conta); broker.commitTransaction(); retorno = true; } catch (PersistenceBrokerException e){ try{ System.out.println("Erro"); broker.abortTransaction(); } catch (Exception ex){ System.out.println("Erro"); } System.out.println("Erro"); } catch (Throwable t){ try{ System.out.println("Erro"); broker.abortTransaction(); }

catch (Exception ex){ System.out.println("Erro"); } System.out.println("Erro"); } 103 ----------------------- Page 104----------------------finally { return retorno; } } } /* * OperacaoInstituicoes * */ package br.com.mackenzie.controlefinanceiro.dao; import org.apache.o b.broker.PersistenceBroker; import org.apache.o b.broker.PersistenceBrokerException; import br.com.mackenzie.controlefinanceiro.Instituicao; /** * * @author Reinaldo/Camila * Esta classe exibe operaes que poder ser realizadas na * tabela INSTITUICOES, de acordo com a instancia informada. */ public class OperacaoInstituicoes { private PersistenceBroker broker; public OperacaoInstituicoes(PersistenceBroker broker) { this.broker = broker; } //Metodo para Inserir registros. public boolean inserir(Instituicao instituicao){ boolean retorno = false; try{ broker.beginTransaction(); broker.store(instituicao); broker.commitTransaction(); retorno = true; } catch (PersistenceBrokerException e){ try{ System.out.println("Erro"); broker.abortTransaction(); } catch (Exception ex){ System.out.println("Erro"); } System.out.println("Erro");

} catch (Throwable t){ try{ System.out.println("Erro"); broker.abortTransaction(); } catch (Exception ex){ 1 04 ----------------------- Page 105----------------------System.out.println("Erro"); } System.out.println("Erro"); } finally{ return retorno; } } //Metodo para Alterar registros public boolean alterar(Instituicao instituicao) { boolean retorno = false; try{ broker.beginTransaction(); broker.store(instituicao); broker.commitTransaction(); retorno = true; } catch (PersistenceBrokerException e){ try{ broker.abortTransaction(); } catch (Exception ex){ System.out.println("Erro"); } System.out.println("Erro"); } catch (Throwable t){ try{ broker.abortTransaction(); } catch (Exception ex){ System.out.println("Erro"); } System.out.println("Erro"); } finally{ return retorno; } } //Metodo para excluir registros public boolean excluir(Instituicao instituicao){ boolean retorno = false;

try{ broker.beginTransaction(); broker.delete(instituicao); broker.commitTransaction(); retorno = true; } catch (PersistenceBrokerException e){ try{ broker.abortTransaction(); } catch (Exception ex){ 105 ----------------------- Page 106----------------------System.out.println("Erro"); } System.out.println("Erro"); } catch (Throwable t){ try{ System.out.println("Erro"); broker.abortTransaction(); } catch (Exception ex){ System.out.println("Erro"); } System.out.println("Erro"); } finally { return retorno; } } } /* * OperacaoItens * */ package br.com.mackenzie.controlefinanceiro.dao; import org.apache.o b.broker.PersistenceBroker; import org.apache.o b.broker.PersistenceBrokerException; import br.com.mackenzie.controlefinanceiro.Item; /** * * @author Reinaldo/Camila * Esta classe exibe operaes que poder ser realizadas na * tabela ITENS, de acordo com a instancia informada. */ public class OperacaoItens { private PersistenceBroker broker; public OperacaoItens(PersistenceBroker broker) { this.broker = broker; }

//Metodo para Inserir registros. public boolean inserir(Item item){ boolean retorno = false; try{ broker.beginTransaction(); broker.store(item); broker.commitTransaction(); retorno = true; } catch (PersistenceBrokerException e){ try{ System.out.println("Erro"); 10 6 ----------------------- Page 107----------------------broker.abortTransaction(); } catch (Exception ex){ System.out.println("Erro"); } System.out.println("Erro"); } catch (Throwable t){ try{ System.out.println("Erro"); broker.abortTransaction(); } catch (Exception ex){ System.out.println("Erro"); } System.out.println("Erro"); } finally{ return retorno; } } //Metodo para Alterar registros public boolean alterar(Item item) { boolean retorno = false; try{ broker.beginTransaction(); broker.store(item); broker.commitTransaction(); retorno = true; } catch (PersistenceBrokerException e){ try{ broker.abortTransaction(); } catch (Exception ex){ System.out.println("Erro");

} System.out.println("Erro"); } catch (Throwable t){ try{ broker.abortTransaction(); } catch (Exception ex){ System.out.println("Erro"); } System.out.println("Erro"); } finally{ return retorno; } } //Metodo para excluir registros public boolean excluir(Item item){ boolean retorno = false; 107 ----------------------- Page 108----------------------try{ broker.beginTransaction(); broker.delete(item); broker.commitTransaction(); retorno = true; } catch (PersistenceBrokerException e){ try{ broker.abortTransaction(); } catch (Exception ex){ System.out.println("Erro"); } System.out.println("Erro"); } catch (Throwable t){ try{ System.out.println("Erro"); broker.abortTransaction(); } catch (Exception ex){ System.out.println("Erro"); } System.out.println("Erro"); } finally { return retorno; } } } /* * OperacaoTransacoes *

*/ package br.com.mackenzie.controlefinanceiro.dao; import org.apache.o b.broker.PersistenceBroker; import org.apache.o b.broker.PersistenceBrokerException; import br.com.mackenzie.controlefinanceiro.Transacao; /** * * @author Reinaldo/Camila * Esta classe exibe operaes que poder ser realizadas na * tabela TRANSACOES, de acordo com a instancia informada. */ public class OperacaoTransacoes { private PersistenceBroker broker; public OperacaoTransacoes(PersistenceBroker broker) { this.broker = broker; } //Metodo para Inserir registros. 108 ----------------------- Page 109----------------------public boolean inserir(Transacao transacao){ boolean retorno = false; try{ broker.beginTransaction(); broker.store(transacao); broker.commitTransaction(); retorno = true; } catch (PersistenceBrokerException e){ try{ System.out.println("Erro"); broker.abortTransaction(); } catch (Exception ex){ System.out.println("Erro" + ex.getMessage()); } System.out.println("Erro" + e.getMessage()); } catch (Throwable t){ try{ System.out.println("Erro"); broker.abortTransaction(); } catch (Exception ex){ System.out.println("Erro" + ex.getMessage()); } System.out.println("Erro" + t.getMessage()); } finally{ return retorno;

} } //Metodo para Alterar registros public boolean alterar(Transacao transacao) { boolean retorno = false; try{ broker.beginTransaction(); broker.store(transacao); broker.commitTransaction(); retorno = true; } catch (PersistenceBrokerException e){ try{ broker.abortTransaction(); } catch (Exception ex){ System.out.println("Erro"); } System.out.println("Erro"); } catch (Throwable t){ try{ broker.abortTransaction(); } 109 ----------------------- Page 110----------------------catch (Exception ex){ System.out.println("Erro"); } System.out.println("Erro"); } finally{ return retorno; } } //Metodo para excluir registros public boolean excluir(Transacao transacao){ boolean retorno = false; try{ broker.beginTransaction(); broker.delete(transacao); broker.commitTransaction(); retorno = true; } catch (PersistenceBrokerException e){ try{ System.out.println("Erro"); broker.abortTransaction(); } catch (Exception ex){ System.out.println("Erro" + ex.getMessage());

} System.out.println("Erro" + e.getMessage()); } catch (Throwable t){ try{ System.out.println("Erro"); broker.abortTransaction(); } catch (Exception ex){ System.out.println("Erro" + ex.getMessage()); } System.out.println("Erro" + t.getMessage()); } finally { return retorno; } } } 110