Banco de dados orientado a objetos

Alex Novaes de Santana1 , Bruno Rios Patriarca Nunes1 , Vitor Fernandes Ribeiro de Oliveira1
1

Universidade Federal da Bahia Departamento de Ci ncia da Computacao e

1. Introducao
Um Sistema Gerenciador de Banco de Dados(SGBD) pode ser denido basicamente como um gerenciador de grandes volumes de informacao. Os SGBD atuais tem suas ori gens nos antigos sistemas de gerenciamento de arquivos que evoluram para banco de da dos de rede ou hier rquicos chegando at os modelos de bancos de dados relacionais. As a e caractersticas comuns a esses sistemas s o a uniformidade, orientacao a registro, itens de a dados pequenos e campos at micos, a necessidade de armazenar e manipular informacoes o mais complexas, junto com o surgimento de novas aplicacoes(e.g. CAD, CASE, banco de dados multimdia, ...) de linguagem orientadas a objetos e sistemas que precisam de um banco de dados poderoso e que possua algumas capacidades como continuidade, simultaneidade e transacoes dos seus ambientes. Essas exig ncias levaram ao estudo e a e criacao de BDOO[Boscarioli et al. ][Silberschatz et al. 1999]. Um banco de dados orientados a objetos(BDOO) e capaz de integrar as funcionalidades de um banco de dados com as ferramentas das linguagens com o paradigma de orientacao a objetos, desta forma os BDOO tem a habilidade de persistir informacao sob forma de objetos, os ger nciadores de BDOO s o normalmente chamados de ODBMS e a ou OODBMS. Os BDOO estendem as linguagens orientadas a objetos adicionando persist ncia de dados transparente, controle de concorr ncia, recuperacao de dados, Query e e associativa e outras habilidades dos bancos de dados que ser o apresentadas neste a trabalho[Barry ].

2. Hist ria o
O desenvolvimento dos Sistemas de Gerenciamento de Banco de Dados Orientado a Objetos(SGBDOO ou do ingl s ODBMS) teve origem na combinacao de id ias dos modelos e e de dados tradicionais e de linguagens de programacao orientada a objetos. Os SGBDOO, Sistema de Ger nciamento de Banco de Dados Orientado a Objee tos, cresceram na metade dos anos 80 e foi por volta de 1985 que surgiu o termo banco de dados orientado a objetos. V rios foram os projetos de pesquisa envolvidos com BDOO, a mas os mais importantes foram: Encore-Ob/Server (Brown University), EXODUS (University of Wisconsin), IRIS (Hewlett-Packard), ODE (Bell Labs), ORION (Microelectronics and Computer Technology Corporation or MCC), Vodak (GMD-IPSI), Zeitgeist (Texas Instruments). Dentre esse projetos um ganhou maior destaque e divulgacao, Won Kim pesquisador do ORION escreveu v rios artigos sobre o tema e terminou escrevendo a um livro sobre BDOO pela MIT press. Durante a d cada de 90 a linguagem c++ domie nou o mercado de OODBMS, apenas no nal dessa d cada os vendedores acresentaram e o JAVA e nos ultimos anos o C#[wik ][Systems ].

3. Banco de Dados OO
3.1. Propriedades Pela uni o de linguagens orientadas a objetos com bancos de dados os BDOO possuem a propriedades que facilitam a compreens o do seu funcionamento, dentre elas temos: a Persist ncia transparente: A habilidade de manipular os dados guardados no e banco usando uma linguagem orientada a objetos, diferente dos bancos de dados relacionais onde utilizam uma sub-linguagem(e.g. SQL) para manipular o banco de dados, esta habilidade minimiza o tamanho e a complexidade do c digo da o aplicacao. Aus ncia de Impedance Mismatch: Os projetos que utilizam bancos de dados e relacionais necessitam mapear os objetos do modelo de entidade-relacionamento para o modelo relacional utilizado na base de dados, este mapeamento de obje tos em tabelas ou outras estruturas e conhecido como Impedance Mismatch, este esforco n o ocorre nos BDOO, pois estes guardam os objetos diretamente nas a suas bases, permitindo que o mesmo modelo de classe utilizado para desenvolver a aplicacao seja usado no banco de dados. Identidade de Objeto: Objetos de um BDOO s o uma referencia a uma entidade a de uma empresa que est sendo modelada pelo banco de dados. No BDOO um a objeto possui uma identidade que permanece imut vel mesmo depois de o objetos a sofrer mudancas em um ou em todos os seus atributos, de forma diferente os bancos de dados relacionais identicam as tuplas de uma relacao somente pelos valores que ela cont m. Dentre as formas de identidade temos: e Valor: Um valor de dados e utilizado para identidade, de forma semelhante aos bancos relacionais onde a chave primaria e usada para identicar a tupla. Nome: Um nome fornecido pelo usu rio e usado para identidade. a Embutido: A nocao de identidade esta embutida na linguagem de programacao, sem a necessidade de uma entrada fornecida pelo usu rio, a esta forma e muito utilizada em sistemas orientados a objetos, onde cada objeto quando criado recebe automaticamente uma identidade. 3.2. Funcionamento No banco de dados orientados a objetos os dados s o armazenados na forma de objetos a que s podem ser manipulados pelos m todos denidos pela classe que o objeto pertence. o e Os objetos s o organizados numa hierarquia de tipos, e subtipos que recebem as caraca tersticas de seus supertipos. Os BDOO possuem v rias das caractersticas presentes em linguagens orientadas a a objetos, como: Heranca: Onde uma classe pode ser derivada de outra. Essa caracterstica torna se bastante util em um problema existe diversos tipos de classes com atributos e/ou operacoes em comum mas que possuam particularidades inerentes. Polimorsmo: Polimorsmo e um princpio que permite um comportamento diferenciado seja implementado por duas classes, desde que sejam especializacoes de uma mesma classe e o m todo tenha a mesma assinatura. e

 Encapsulamento: Esta caracterstica permite que a classe dena quais dos seus atributos estejam visveis para as outros classes. Com estas caractersticas, muitas vezes as classes de objetos usadas pelas linguagens de programacao s o as mesmas usadas no modelo de dados. a Os objetos criados pelas linguagens orientadas a objetos tem como caracterstica serem dados transientes, ou seja, s o eliminados no momento em que a aplicacao e encera rada. Para tornar os objetos criados em objetos persistentes algumas abordagens podem ser adotadas: Persist ncia por classe: Nesta abordagem uma classe e declarada persistente e e todos os objetos da classe s o persistentes por padr o, esta abordagem e pouco a a exvel pois e util utilizarmos possuir objetos persistentes e transientes de uma classe. Persist ncia por criacao: Neste caso uma nova sintaxe e denida para que no e momento da criacao de um objeto, este seja denido como persistente ou tran sientes. Persist ncia por marcacao:Todos objetos s o criados como transientes, mas caso e a seja necess rio torna-lo persistente o mesmo deve ser marcado explicitamente a como persistente antes da aplicacao ser encerrada. Persist ncia por refer ncia:Um ou mais objetos s o denidos como persistentes e e a e a partir dele todos objetos referenciados por ele ser o persistentes, da mesma a forma todas as referencias dos novos objetos tamb m ser o persistentes, pere a mitindo assim que estruturas inteiras tornem-se persistentes declarando apenas um ou mais objetos raiz como persistentes.[Silberschatz et al. 1999] Muitas s o as msticas com relacao aos DBOOs, como por exemplo a armacao de a que DBOOs n o s o bons bancos para grandes base de dados. Esta armacao e facilmente a a negada visualizando o exemplo do Stanford Linear Accelerator Center que possui uma das maiores sen o a maior base de dados do mundo com cerca de 895 TB de informacao a e crescendo[sla ], al m do SLAC, podemos encontrar bancos de dados OO tamb m na e e RCS(Radio Computing Services), British Telecommunications, SouthWest Airline, Ajou University Medical Center e at mesmo no MP4/13 Formula One carro de corrida usado e pela West McLaren Mercedes que usava o DBOO Jasmine para monitorar a performance do carro.[Barry ]

4. Banco de dados orientado a objeto, banco de dados relacional e banco de dados objeto-relacional
Persistir objetos em um banco de dados relacional recorre ao problema de dist ncia a sem ntica entre banco de dados orientado a objetos e banco de dados relacional. Banco de a dados relacionais n o foram feitos para armazenar objetos, n o possuem caractersticas a a como heranca ou polimorsmo e armazenar objetos em tabelas torna-se uma tarefa bas tante difcil. Hoje um modelo hbrido e bem aceito por muitos pois permite aos desen volvedores usar t cnicas mais poderosas de orientacao a objetos, por m acredita-se que e e esse modelo acrescenta um overhead de traducao as operacoes de persist ncia, tornando-o ` e proporcionalmente mais lento que as outras duas solucoes. O mapeamento objeto-relacional e um exemplo de modelo hbrido e foi desen volvido na tentativa de solucionar essa m combinacao e facilitar a persist ncia de objetos a e

ao desenvolvedor. Sistemas desse tipo atuam como intermedi rio entre os modelos puros a de forma a representar o objeto de maneira relacional no banco de dados, conseguindo fazer o caminho inverso sem perda de informacao. Depois de se conhecer os modelos puros e hbridos, qual das opcoes escolher em uma determinada aplicacao? Essa escolha depende n o s do contexto inserido bem como a o da an lise sobre alguns fatores (performance, facilidade, etc.). N o existe uma unica abora a dagem correta no que diz respeito a qual escolha fazer. O que se faz e um levantamento de vantagens e desvantagens dos diferentes modelos sobre esse fatores. Esse levantamento ajudar na escolha da modelagem a seguir. Como exemplo, banco de dados orientado a a objeto facilita o desenvolvimento pois automatiza virtualmente todos os aspectos de persist ncia, ao passo que o mesmo torna complexa a extracao de dados por esconder seus e ` conte dos atr s de programacao orientada a objetos. Em outra vis o, no que se refere a u a a performance, arma-se que aplicacoes que navegam dados utilizar o o modelo de obje a tos, enquanto um que utiliza queries complexas ou processa dados seq encialmente, s o u a mais voltados ao modelo relacional. A mais importante caracterstica dos BDOOs e a juncao de programacao orientada a objeto com tecnologia de banco de dados, fornecendo um sistema de desenvolvimento de aplicacao integrado. Al m disso, as operacoes denidas desse tipo de sistema s o in e a dependentes na aplicacao de banco de dados executada num dado momento. SGBDOO e um modo mais natural de pensar. Suas vantagens est o em caractersticas com heranca, a que permite solucao de problemas complexos pela denicao de novos objetos atrav s de e objetos anteriormente denidos. Se houverem muitos relacionamentos many-to-many, estruturas de rede ou arvores, BDOO tratar estes com muito mais rapidez que um BDR. a Outros benefcios do SGBDOO s o sua conanca e reusabilidade. Uma diferenca entre a banco de dados orientado a objeto e banco de dados relacional e que o banco de dados orientado a objeto representa relacionamentos explicitamente. Mais que isso, os SGB DOOs se estenderam em areas n o conhecidas pelo banco de dados relacional, tais como a medicina, multimdia e fsica. Em contrapartida, banco de dados relacionais s o mais simples e produtivos e por a isso, os dados s o mais facilmente entendidos, tamb m por que a linguagem SQL e mais a e f cil de aprender. Desse modo, os usu rios n o se prendem no tempo de aprendizagem a a a e sim na pr tica. Atrav s dessas vantagens pode-se chegar a uma mais geral, talvez a a e maior, que e a tranq ilidade com que os usu rios podem criar e acessar dados e estend u a e los se necess rio. Por m algumas limitacoes surgem, e nesse contexto surge tamb m o a e e banco de dados orientado o objetos: o SGBDR se limita bastante a linguagem SQL, e mesmo suportando outras linguagens, estas n o s o adequadas por n o trabalharem com a a a eci ncia. Ainda assim, e o modelo dominante no cen rio atual. e a 4.1. DB4O versus Hibernate Db4o e um banco de objetos de c digo aberto que diz facilmente o que e como persistir. o Hibernate e um framework que faz o mapeamento de objetos para um banco de dados relacional que armazena objetos na mem ria e recupera objetos de um banco de dados o relacional. A benchmark 007 em vers o Java, uma t cnica de medicao criada para ina e vestigar v rios aspectos de desempenho entre esses dois mecanismos de persist ncia de a e objetos, mostra que a performance total do DB4O se mostrou melhor que o Hibernate e

que este executa de forma ineciente consultas que requerem joins. A conclus o revela a tamb m que muitos dos resultados obtidos parecem conrmar o que foi dito anteriore mente sobre sistemas hbridos, que o overhead de traducao objeto-relacional implica nas implementacoes baseadas em banco de dados objeto-relacionais serem mais lentas que quando na forma de objeto com um banco de dados orientado a objetos.[Zyl et al. ]

5. Padr o ODMG a
Com o intuito de criar aplicacoes que armazenassem objetos em sistemas de banco de dados surgiu o Object Database Management Group, padr o para SGBDOO, cons rcio a o de vendedores e fabricantes, com objetivo de integrar banco de dados a linguagens de programacao orientada a objetos. A vers o mais recente dentre v rias j publicadas e a a a a ODMG 3.0, de 2001. O padr o ODMG oferece vantagens como portabilidade e interopa erabilidade e e composto de: Modelo de objetos, que fornece tipos de dados e construtores de tipos; Linguagem de denicao de objetos (ODL), que permite denir classes, interfaces e especicacao de tipos objeto; e Linguagem de consulta (OQL), linguagem declarativa usada em consulta e atualizacao de objetos no banco de dados com sintaxe baseada em SQL[Subieta ]. 5.1. O Modelo de Objetos O modelo de objetos descreve os tipos de sem ntica que podem ser denidos explicia tamente em um SGDBOO. Essas sem nticas determinam as caractersticas dos objetos, a como eles se relacionam entre si, al m de como esses objetos podem ser identicados. As e seguintes construcoes s o suportadas pelo modelo de objetos: a As primitivas b sicas de modelagem s o objetos e literais. Objetos possuem um a a identicador unico, enquanto literais n o possuem identicador. a Objetos e literais podem ser classicados em tipos. Elementos de um mesmo tipo compartilham um mesmo conjunto de propriedades (atributos) e possuem comportamento semelhante (m todos). Um objeto pertencente a um tipo e dito e ser uma inst ncia desse tipo. a ` O estado de um objeto e denido pelos valores associados as suas propriedades em um dado momento. Al m de valores, as propriedades podem ainda ser relae cionamentos com outros objetos, criando objetos compostos. O comportamento de um objeto e determinado pela sua lista de m todos, que e possuem um conjunto de par metros e devem ter um tipo de retorno. Cada objeto a e limitado a executar as operacoes denidas pelo seu tipo. O modelo de objetos do padr o ODMG especica o signicado de objetos, lita erais, tipos, operacoes, atributos, propriedades e outros conceitos necess rios ao desen a volvimento de uma aplicacao orientada a objetos. 5.1.1. Denicao de Tipos Existem dois aspectos na denicao de tipos: a especicacao e a implementacao. A especicacao dene de forma abstrata o comportamento e as propriedades das inst ncias a de um tipo. Uma interface e a entidade respons vel pela denicao das operacoes de a um tipo. E uma esp cie de contrato, que dene os m todos que poder o ser invocados e e a

 por um objeto. E importante notar que a interface n o cont m implementacao, apenas a e a prototipacao das funcoes. As propriedades s o os campos que guardar o o estado do a a objeto. Para os BDOO, s o estas propriedades que representar o o esquema banco. Uma a a classe e a uni o dos m todos descritos na interface com as vari veis de estado denidas a e a pelos atributos. De posse de uma classe, e necess rio que os m todos denidos sejam implemena e tados. Esta fase e conhecida como language binding e e dependente das funcionalidades da linguagem de programacao escolhida. 5.1.2. Manipulacao de Objetos As seguintes quest es inerentes a objetos s o tratadas no padr o: o a a Criacao A criacao de novos objetos e feita via a chamada de m todos construtores e providos pelo programador. A operacao de new produz um novo objeto de um determinado tipo. Todos os objetos devem seguir a uma interface comum, que cont m m todos de controle de concorr ncia, teste de identidade, c pia e delecao. e e e o interface Object { enum LockType { r e a d , w r i t e , u p g r a d e } ; void l o c k ( i n Lock Type mode ) r a i s e s ( L o c k N o t G r a n t e d ) ; b o o l e a n t r y L o c k ( i n Lock Type mode ) ; b o o l e a n sameAs ( i n O b j e c t a n O b j e c t ) ; O b j e c t copy ( ) ; void delete (); }; Com o m todo sameAs(object) e possvel denir as condicoes de igualdade entre e objetos. E equivalente ao m todo equals(object) em Java. A operacao copy(), e semelhante ao clone() em Java, produz uma c pia id ntica de um objeto. J o e a delete() e um destrutor, representado pelo Classe() em C++. Identicacao Todos os objetos possuem um atributo unico que os identica den tro do domnio de armazenamento. Esses identicadores s o atribuidos pelo a SGDBOO e s o mantidos durante todo o ciclo de vida do objeto. E a partir desses a atributos unicos que um objeto pode ser referenciado por outros. Tipos literais ou primitivos n o possuem um identicador associado a eles e s o consideraa a dos imut veis, enquanto os objetos compostos podem ser alterados no decorrer do a tempo. A identidade de dois objetos pode ser comparada pela operacao sameAs() vista acima. Tempo de Vida O tempo de vida de objetos pode ser transiente ou persistente, e s o denidos no momento de sua criacao. Objetos transientes s o aqueles que a a existem na mem ria durante a execucao de um procedimento, mas logo s o apao a gados. J os objetos persistentes s o aqueles que s o manipulados em tempo de a a a execucao, mas t m uma representacao no banco. Sendo assim, esses objetos t m e e o estado salvo ao t rmino de sua utilizacao. Vale notar que o tempo de vida de um e objeto n o est associado ao seu tipo. Uma mesma classe pode ter inst ncias trana a a sientes e persistentes ao mesmo tempo. No modelo relacional, em contrapartida,

todos os tipos representados no esquema s o tidos como persistentes. Os outros a tipos n o presentes nas tabelas do banco s o considerados transientes. a a 5.2. Object Denition Language - ODL ODL e uma linguagem de especicacao de tipos de objetos em conformidade com o padr o ODMG e tem por objetivo padronizar e facilitar a migracao de dados de um a SGDBOO para outro. A linguagem ODL n o consistem em uma linguagem completa a ` de programacao, antes atende bem a tarefa de especicacao de objetos. E independente de qualquer linguagem de programacao e foi concebida para ser facilmente extensvel. 5.2.1. Especicacao de Tipo Um tipo pode ser denido atrav s de uma classe ou de uma interface. Uma vers o sime a plicada da Extended Backus Naur Form (EBFN) est descrita abaixo. A gram tica coma a pleta da ODL pode ser encontrada em [Berler et al. 1999]. : : = <i n t e r f a c e d c l > | <i n t e r f a c e f o r w a r d d c l > <i n t e r f a c e d c l > : : = <i n t e r f a c e h e a d e r > { [ <i n t e r f a c e b o d y > ] } <i n t e r f a c e f o r w a r d d c l >::= i n t e r f a c e < i d e n t i f i e r > ::= i n t e r f a c e <i d e n t i f i e r > <i n t e r f a c e h e a d e r > [ <i n h e r i t a n c e s p e c > ] <c l a s s > : : = <c l a s s d c l > | <c l a s s f o r w a r d d c l > : : = <c l a s s h e a d e r > { <i n t e r f a c e b o d y > } <c l a s s d c l > <c l a s s f o r w a r d d c l > ::= class <i d e n t i f i e r > <c l a s s h e a d e r > ::= class <i d e n t i f i e r > [ e x t e n d s <scopedName> ] [ <i n h e r i t a n c e s p e c > ] [ <t y p e p r o p e r t y l i s t > ] E possvel tamb m denir algumas caractersticas aos tipos como informacoes e de supertipos e especicacao de chaves e atributos de unicidade. E importante ressaltar que, ao contr rio de linguagens como C++, a ODL permite apenas a declaracao de um a supertipo para cada tipo criado. Um pequeno exemplo de declaracao de um tipo e visto abaixo: class Professor ( e x t e n t Pessoa ) { propriedades operacoes }; <i n t e r f a c e >

5.2.2. Atributos Tipos podem ser declarados, de maneira simplicada, como descreve a seguinte EBNF:

<a t t r d c l > ::= [ readonly ] a t t r i b u t e <d o m a i n t y p e > < a t t r i b u t e n a m e > [ < f i x e d a r r a y s i z e >] Nota-se que h a possibilidade de declarar um atributo como apenas leitura, a exa emplo do modicador nal em Java. Tamb m e possvel declarar um vetor de tamanho e xo com elementos pertencentes a um determinado tipo do domnio. Adicionando atrib ` utos a classe Professor, tem-se: class Professor ( e x t e n t Pessoa ) { a t t r i b u t e s t r i n g nome ; a t t r i b u t e Endereco endereco ; a t t r i b u t e unsigned long cpf ; relacionamentos operacoes }; A palavra-chave attribute e obrigat ria. o

5.2.3. Relacionamentos A especicacao de um relacionamento dene a ordem direta e inversa atrav s da qual e cada tipo envolvido poder acessar o outro. O exemplo abaixo mostra o uso de relacionaa mentos: class Professor ( e x t e n t Pessoa ) { a t t r i b u t e s t r i n g nome ; a t t r i b u t e Endereco endereco ; a t t r i b u t e unsigned long cpf ; relationship inverse relationship inverse operacoes }; Neste exemplo est o presentes dois relacionamentos do tipo um-para-muitos da a classe Professor para as classes Aluno e Monitor. O atributo orienta representa o conjunto de alunos que s o orientados por um professor. A cl usula inverse mostra como a a este relacionamento estar expresso na declaracao da classe Aluno. Nesta existir um a a s e t <Aluno> o r i e n t a Aluno : : o r i e n t a d o r ; s e t <M o n i t o r > m o n i t o r e s Monitor : : t r a b a l h a p a r a ;

atributo do tipo Professor de nome orientador. O mesmo vale para o relacionamento entre Professor e Monitor. O uso da palavra-chave relationship e obrigat rio. o 5.2.4. Operacoes A declaracao de m todos funciona de forma simplicada como segue: e <o p e r a t i o n d c l > : : = <r e t u r n t y p e > < i d e n t i f i e r > <p a r a m e t e r d c l > [ <r a i s e s e x p r > ] Al m de um tipo de retorno e um conjunto de par metros, e possvel tamb m e a e denir uma lista de excecoes que podem ser disparadas durante a execucao do m todo. e class Professor ( e x t e n t Pessoa ) { a t t r i b u t e s t r i n g nome ; a t t r i b u t e Endereco endereco ; a t t r i b u t e unsigned long cpf ; relationship inverse relationship inverse s e t <Aluno> o r i e n t a Aluno : : o r i e n t a d o r ; s e t <M o n i t o r > m o n i t o r e s Monitor : : t r a b a l h a p a r a ;

void p u b l i c a T r a b a l h o ( ) r a i s e s ( PrazoExpirado ) ; }; 5.3. Object Query Language - OQL A OQL e uma linguagem de consulta para o modelo ODMG, que tem segue alguns princpios e caractersticas: OQL assemelha-se a SQL-92. Diferencia-se por apresentar nocoes de orientacao a objetos, identidade de objetos, polimorsmo, acesso via caminhos (path expressions) e invocacao de m todos. e Prov mecanismos de alto nvel para lidar com colecoes como listas e arrays. e N o consiste em linguagem computacionalmente completa. Seu objeto e ser uma a simple e eciente linguagem de consulta. N o apresenta operadores explcitos para atualizacao (update). A alteracao de a atributos e feita com os pr prios m todos oferecidos pela classe. o e 5.3.1. Consultas Seja um esquema com os tipos Pessoa e Empregado. O tipo Pessoa possui os atributos nome, aniversario e salario, al m do m todo idade(). O tipo Empregado estende de e e Pessoa e dene os relacionamentos coordena e subordinado.

Para retornar, por exemplo, o conjunto das idades de todos os funcion rios chamaa dos Maria, usa-se a consulta: s e l e c t d i s t i n c t p . idade from P e s s o a p where p . name = M a r i a Para retornar uma estrutura com o nome e a idade de todos os funcion rios com a mais de trinta anos: s e l e c t d i s t i n c t s t r u c t ( n : p . nome , i : p . i d a d e ) from P e s s o a p where p . i d a d e > 30 Pode-se tamb m usar uma cl usula where dentro do from, como uma subconsulta: e a s e l e c t s t r u c t ( n : p . nome , i : p . i d a d e ) from ( s e l e c t y from Empregado y where y . i d a d e > 3 0 ) a s x where x . name = M a r i a E tamb m possvel omitir a construcao select-from-where. A consulta abaixo ree torna todos os empregados. Empregado

5.3.2. Criacao de Objetos Para inserir um novo objeto no banco deve-se invocar um m todo construtor que possui o e mesmo nome do tipo. Dentro do construtor e possvel passar valores para alguns atributos. Os atributos n o contemplados explicitamente no construtor assumir o valores padr o. a a a Para inserir uma nova pessoa, pode-se usar a seguinte construcao: P e s s o a ( nome= M a r i a , a n i v e r s a r i o = d a t e 1970 10 12 , s a l a r i o =3 50 0)

5.3.3. Path Expressions O uso de path expressions permite a f cil navegacao pelos relacionamentos de um objeto. a Atrav s do operador . ou -> possvel acessar diretamente atributos de um tipo, o que e e simplica as consultas e reduz o uso de joins. Para, por exemplo, saber o nome da cidade em que vive uma pessoa, pode-se fazer a seguinte consulta: s e l e c t p . e n d e r e c o . c i d a d e . nome from P e s s o a p

6. Conclus o a
Neste artigo, foi discutido os conceitos, padr es, uso de Bancos de Dados Orientados a o Objetos e uma comparacao com o modelo relacional. Com o surgimento de aplicacoes complexas e com o modelo de dados relacional n o atendendo a todas as necessidade dessas aplicacoes, ca claro que o uso de novo a modelos e o caminho para suprir esta necessidade, neste momento que os modelos de dados orientados a objetos podem ser aplicatos trazendo um retorno ecente. Por outro lado grande parte das bases de dados existentes utilizam do modelo relacional e uma migracao para o orientado a objetos representa um custo muito grande, outro fator que pode impossibilitar uma maior utilizacao dos BDOO e o fator de grande parte dos sis temas ger nciadores de bancos de dados OO serem produzidos por empresas de m dio e e e pequeno porte, o que torna a adocao deste modelo arriscada devido uma possiv l falta e de surpote do produto gerada pela fal ncia dessas empresas. Uma alternativa e o uso e do modelo objeto-relacional que apresenta funcionalidades dos dois modelos(relacional e objetos) e que as grandes empresas fornecedoras de sistemas de bancos de dados j a investem e j fornecem diversas ferramentas para a utilizacao do modelo. Por m, O a modelo de banco de dados orientados a objetos deve ser pensado no momento do projeto de um banco de dados levando em conta o tipo de aplicacao e dados que utilizar o a base a de dados, este pensamento j pode ser visto no mercado com o surgimento de aplicacoes a que utilizam o modelo orientado a objetos.

References
Banco de dados orientado a objetos. http://pt.wikipedia.org/wiki/Banco de dados orientado a objetos. 31.05.2008. Stanford linear accelerator center babar database. http://www.slac.stanford.edu/BFROOT/www/Public/Computing/Databases/index.shtml. 31.05.2008. Barry, D. K. Object database articles. http://www.service-architecture.com/objectoriented-databases/articles/. 31.05.2008. Berler, M., Eastnam, J., Jordan, D., Brussell, C., Schadow, O., Stanienda, T., and Velez, F. (1999). The Object Data Standard: ODMG 3.0. Morgan Kaufmann Publishers. Boscarioli, C., Bezerra, A., Benedicto, M., and Gilliard, D. Uma reex o sobre banco de a dados orientadodos a objetos. Silberschatz, A., Korth, H. F., and Sudarshan, S. (1999). Sistemas de Bancos de Dados. Pearson Education. Subieta, K. Object-orientedness in databases - motivation and the state-of-the-art. Systems, O. D. M. Object database articles. http://www.odbms.org. 31.05.2008. Zyl, P. V., Kourie, D. G., and Boake, A. Comparing the performance of object databases and orm tools.