Banco de dados orientado a objetos

Um banco de dados orientado a objetos é um banco de dados em que cada informação é armazenada na forma de objetos, ou seja, utiliza a estrutura de dados denominada orientação a objetos, a qual permeia as linguagens mais modernas. Começou a ser comercialmente viável em 1980. O gerenciador do banco de dados para um orientado a objeto é referenciado por vários como ODBMS ou OODBMS.

Existem dois fatores principais que levam à adoção da tecnologia de banco de dados orientados a objetos. A primeira, é que, em um banco de dados relacional, se torna difícil de manipular com dados complexos (esta dificuldade se dá pois o modelo relacional se baseia menos no senso comum relativo ao modelo de dados necessário ao projeto e mais nas contingências práticas do armazenamento eletrônico). O segundo fator é que os dados são geralmente manipulados pela aplicação escrita usando linguagens de programação orientada a objetos, como C++, C#, Java, Python ou Delphi (Object Pascal), e o código precisa ser traduzido entre a representação do dado e as tuplas da tabela relacional, o que além de ser uma operação tediosa de ser escrita, consome tempo. Esta perda entre os modelos usados para representar a informação na aplicação e no banco de dados é também chamada de "perda por resistência".

História

Os sistemas de gerenciamento de banco de dados orientado a objetos cresceram fora das pesquisas durante o começo da metade dos anos 1980, buscando ter sustentação intrínseca da gerência da base de dados para objetos gráfico-estruturados. A expressão "sistema de banco de dados orientado a objetos" surgiu originalmente por volta de 1985. Projetos de pesquisa notáveis incluem 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), e Zeitgeist (Texas Instruments). O projeto ORION teve mais artigos publicados do que qualquer outro. Won Kim, do MCC, compilou os melhores destes artigos num livro publicado pelo MIT Press.^[1]

Surgiram produtos comerciais, como o GemStone (Servio Logic, alterado para GemStone Systems), Gbase (Graphael), e Vbase (Ontologic). No começo da metade dos anos 1990, vimos novos produtos comerciais entrarem no mercado. Destes, incluem-se ITASCA (Itasca Systems), Matisse (Matisse Software), Objectivity/DB (Objectivity, Inc.), ObjectStore (Progress Software, adquirido pela eXcelon, a qual era originalmente Object Design), ONTOS (Ontos, Inc., alterado para Ontologic), O₂^[2] (O₂ Technology, surgiu de várias companhias, foi adquirido pela Informix, a qual por sua vez foi adquirida pela IBM), POET (agora da FastObjects da Versant que adquiriu a Poet Systems), e Versant Object Database (Versant Corporation). Alguns destes produtos se mantêm no mercado, tendo alguns se unido com novos produtos.

Os Sistema de Gerenciamento de Banco de Dados Orientados a Objetos adicionaram o conceito de persistência à programação orientada a objetos. No início, os produtos comerciais eram integrados com várias linguagens GemStone (Smalltalk), Gbase (Lisp), e Vbase (COP). O COP era o C Object Processor, uma linguagem proprietária baseada no C (COP é diferente de C++. Apesar de ambas terem C como base, C++ também foi influenciada pela Simula). Durante praticamente todos os anos 1990, o C++ dominou o mercado comercial de Gerenciadores de Banco de Dados Orientados a Objetos. Os vendedores acrescentaram o Java no final dos anos 1990 e mais recentemente o C#.

Recursos Técnicos

Num banco de dados orientado a objetos puro, os dados são armazenados como objetos onde só podem ser manipulados pelos métodos definidos pela classe de que estes objetos pertencem. Os objetos são organizados numa hierarquia de tipos e subtipos que recebem as características de seus supertipos. Os objetos podem conter referências para outros objetos, e as aplicações podem consequentemente acessar os dados requeridos usando um estilo de navegação de programação.

Um dos objetivos de um SGBDO (Sistema de Gerenciamento de Banco de Dados de Objeto) é manter uma correspondência direta entre objetos do mundo real e do banco de dados, de modo que objetos não percam sua integridade e identidade e possam facilmente ser identificados e operados. Assim, o SGBDO oferece uma identidade única e imutável a cada objeto armazenado no banco de dados chamado OID(Identificador de objeto). O valor de um OID não e visível ao usuário externo, somente ao sistema para poder gerenciar a referência dos objetos.^[3]

A maioria dos bancos de dados também oferece algum tipo de linguagem de consulta, permitindo que os objetos sejam localizados por uma programação declarativa mais próxima, isto é, na área das linguagens de consulta orientada a objetos. A integração da consulta com a interface de navegação faz a grande diferença entre os produtos que são encontrados. Uma tentativa de padronização foi feita pela ODMG (Object Data Management Group) com a OQL (Object Query Language).

O acesso aos dados pode ser rápido porque as junções geralmente não são necessárias (como numa implementação tabular de uma base de dados relacional), isto é, porque um objeto pode ser obtido diretamente sem busca, seguindo os ponteiros.

Outra área de variação entre os produtos é o modo que este esquema do banco de dados é definido. Uma característica geral, entretanto, é que a linguagem de programação e o esquema do banco de dados usam o mesmo modo de definição de tipos.

Aplicações multimídias são facilitadas porque os métodos de classe associados com os dados são responsáveis pela correta reprodução.

Muitos bancos de dados orientados a objetos oferecem suporte a versões. Um objeto pode ser visto de todas as várias versões. Ainda, versões de objetos podem ser tratadas como objetos na versão correta. Alguns bancos de dados orientados a objetos ainda proveem um suporte sistemático a triggers e constraints que são as bases dos bancos ativos.

Vantagens e Desvantagens

Benchmarks entre ODBMS's e relacionais DBMS's têm mostrado que ODBMS podem ser claramente superiores para certos tipos de tarefas. A principal razão para isto é que várias operações são feitas utilizando interfaces navegacionais ao invés das relacionais, e o acesso navegacional é geralmente implementado de forma muito eficiente por ponteiros.^[4]

Críticos das tecnologias baseadas em Bancos de Dados Navegacionais, como os ODBMS, sugerem que as técnicas baseadas em ponteiros são otimizadas para "rotas de pesquisa" ou pontos de vista muito específicos. Entretanto, para o propósito de consultas gerais a mesma informação, técnicas baseadas em ponteiros tenderão a ser mais lentas e mais difíceis de se formular do que as relacionais. Desta maneira, a abordagem navegacional parece simplificar para usos dos específicos conhecidos às custas do uso geral, ignorando usos futuros.

Outra coisa que trabalha contra os ODBMS parece ser a perda da interoperabilidade com um grande número de ferramentas/características que são tidas como certas no mundo SQL, incluindo a indústria de padrões de conectividade, ferramentas de relatório, ferramentas de OLAP e backup, e padrões de recuperação. Adicionalmente, banco de dados orientado a objetos perdem o fundamento formal matemático, ao contrário do modelo relacional, e isto às vezes conduz a fraqueza na sustentação da consulta. Entretanto esta objeção é descartada pelo fato que alguns ODBMS's suportam totalmente o SQL em adição ao acesso navegacional (Objectivity/SQL++). Mas, o uso eficaz pode requerer acordos para manter ambos os paradigmas sincronizados.

De fato há uma tensão intrínseca entre a noção de encapsulamento, que esconde os dados e somente os disponibiliza através de uma interface de métodos publicados, e o pressuposto de muitas tecnologias de bancos de dados, de que estes dados podem ser acessados por consultas baseadas em seu conteúdo ao invés de caminhos predefinidos. O pensamento centrado em bancos de dados tende a ver o mundo através de forma declarativa e dirigida a uma visão de atributos, enquanto a OOP tenta ver o mundo através um ponto de vista comportamental. Esta é uma das várias "perdas por resistência" que envolvem OOP e banco de dados.

Embora alguns afirmem que a tecnologia de banco de dados orientado a objetos fracassou, os argumentos essenciais em seu favor permanecem válidos, e as tentativas de integrar as funcionalidades de bancos de dados mais próxima as linguagens de programação orientadas a objeto continuam tanto nas comunidades de pesquisa quanto nas industriais.

ODMG

O ODMG (Object Database Management Group) era um consórcio de vendedores de banco de dados orientados a objetos e mapeadores objeto-relacionais, membros da comunidade acadêmica, e parceiros interessados. A meta era criar um conjunto de especificações que permitiriam a portabilidade das aplicações que armazenam objetos em sistemas de gerenciamento de banco de dados. Foram publicadas várias versões desta especificação. O último release foi a ODMG 3.0. Em 2001, a maioria dos principais vendedores de banco de dados orientado a objetos e mapeadores de objeto-relacionais reivindicaram a conformidade com a ODMG Java Language Binding. A conformidade com os demais componentes da especificação foi variada.^[5] Em 2001, o ODMG Java Language Binding foi submetido para o Java Community Process como base para a especificação Java Data Objects. As companhias membros do ODMG decidiram então concentrar esforços na especificação do Java Data Objects. Como resultado, a ODMG se dissolveu em 2001.

Várias ideias do banco de dados orientado a objetos foram absorvidas pela SQL:1999 e têm sido implementadas em vários graus nos produtos de banco de dados objeto-relacional.

Em 2005, Cook, Rai e Rosenberger propuseram abandonar todos os esforços de padronização para introduzir APIs adicionais de consulta orientadas a objetos e, ao invés disso, usar as próprias linguagens orientadas a objetos, como o JAVA e o .NET. Como resultado, surgiram as Consultas Nativas (Native Queries). Similarmente, a Microsoft anunciou a LINQ (Language Integrated Query) e DLINQ, uma implementação do LINQ, em setembro de 2005, para prover a aproximação da capacidade da linguagem de consulta integrada do banco de dados com as linguagens de programação C# e VB.NET 9.

Em fevereiro de 2006, o OMG (Object Management Group) anunciou que havia concedido o direito de desenvolver novas especificações baseadas na especificação ODMG 3.0 e a formação do ODBT WG (Object Database Technology Working Group). O ODBT WG planeja criar um conjunto de especificações que incorporará avanços da tecnologia de banco de dados orientados a objetos (exemplo replicação), gerenciamento de dados (ex. indexação espacial) e formato de dados (exemplo XML) e incluir novas características dentro deste padrão que dará suporte ao domínios onde as bancos de dados orientadas a objeto estão sendo adotadas (exemplo sistemas de Tempo real).

ODL

A Linguagem de Definição de Objeto (ODL) é a linguagem de especificação que define a interface para os tipos de objeto em conformidade com o Modelo de Objeto ODMG. Frequentemente abreviado pela sigla ODL.O objetivo desta linguagem é definir a estrutura de um diagrama de relação de entidade.

A ODL é projetada para dar suporte ás construções semânticas do modelo de objeto ODMG e é independente de qualquer linguagem de programação em particular. Seu uso principal é para criar especificações de objeto, ou seja, classes e interfaces. Logo, a ODL não é uma linguagem de programação completa.Por exemplo, um usuário pode especificar um esquema de banco de dados na ODL independentemente de qualquer linguagem especifica para indicar como as construções ODL podem ser mapeadas em construções nas linguagens de programação especificas.^[3]

Exemplo de ODL

Type Date Tuple (year, day, month) Type year, day, month integer

interface Manager { keys id; attribute String name; attribute String phone; relationShip Set<Employee> employees inverse Employee::manager}

interface Employee { keys id; attribute String name; attribute Date Start_Date; relationShip Manager manager inverse Manager::employees }

OQL

O Object Query Language (OQL) é um padrão de linguagem de consulta para bancos de dados orientados a objetos modelados a partir do SQL. OQL foi desenvolvido pelo Object Data Management Group (ODMG). Devido à sua complexidade geral, ninguém se aventurou a implementar o OQL completo. O OQL influenciou o design de algumas das novas linguagens de consulta, como JDOQL e EJB QL, mas elas não podem ser consideradas como diferentes tipos de OQL.

A linguagem de consulta de objeto OQL é a linguagem proposta para o modelo de objeto ODMG. Ela foi projetada para trabalhar de perto com as linguagens de programação para as quais um binding ODMG é definido, como C++ e JAVA. Logo, uma consulta OQL embutida em uma dessas linguagens de programação pode retornar objetos que combinam com o sistema de tipos dessa linguagem. Além disso, as implementações de operações de classe em um esquema ODMG podem ter seu código escrito nessas linguagens de programação. A sintaxe OQL para consultas é semelhante a sintaxe da linguagem de consulta do padrão relacional, SQL, com recursos adicionais para os conceitos ODMG, como identidade, polimorfismo e relacionamentos.^[3]

Exemplo de OQL

Consulta Simples

O exemplo a seguir ilustra como alguém pode recuperar a velocidade da CPU de todos os computadores com mais de 64MB de RAM de um banco de dados fictício:

SELECT pc.cpuspeed
FROM PCs pc
WHERE pc.ram > 64;

Ver também

Referências

[1]
Kim, Won. Introduction to Object-Oriented Databases. The MIT Press, 1990. ISBN 0-262-11124-1
[2]
Bancilhon, Francois; Delobel,Claude; and Kanellakis, Paris. Building an Object-Oriented Database System: The Story of O₂. Morgan Kaufmann Publishers, 1992. ISBN 1-55860-169-4.
[3]
Elmasri, Ramez (2011). Sistemas de Banco de Dados. São Paulo: Pearson Addison Wesley
[4]
Animação mostrando como um banco de dados orientado a objetos funciona
[5]
Barry, Douglas and Duhl, Joshua. Object Storage Fact Books: Object DBMSs and Object-Relational Mapping. Barry & Associates, Inc., 2001. A páginas exibe a conformidade da ODMG para a os banco de dados orientados a objetos e os produtos objeto-relacionais em 2001

[1] [1]
Kim, Won. Introduction to Object-Oriented Databases. The MIT Press, 1990. ISBN 0-262-11124-1

[2] [2]
Bancilhon, Francois; Delobel,Claude; and Kanellakis, Paris. Building an Object-Oriented Database System: The Story of O₂. Morgan Kaufmann Publishers, 1992. ISBN 1-55860-169-4.

[:0-3] [3]
Elmasri, Ramez (2011). Sistemas de Banco de Dados. São Paulo: Pearson Addison Wesley

[4] [4]
Animação mostrando como um banco de dados orientado a objetos funciona

[5] [5]
Barry, Douglas and Duhl, Joshua. Object Storage Fact Books: Object DBMSs and Object-Relational Mapping. Barry & Associates, Inc., 2001. A páginas exibe a conformidade da ODMG para a os banco de dados orientados a objetos e os produtos objeto-relacionais em 2001

[1]

[2]

[3]

[4]

[5]