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. 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
a 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). Segundo, 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”.
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 conseqüentemente acessar os dados
requeridos usando um estilo de navegação de programação.
A maioria
dos banco de dados também oferecem 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 schema do banco de dados é
definido. Uma característica geral, entretanto, é que a linguagem de
programação e o schema do banco de dados usam o mesmo modo de definição de
tipos.
Aplicações
multimídia 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
provêem um suporte sistemático a triggers e constraints que são as bases dos bancos ativos.
VANTAGENS E DESVANTAGENS
Benchmarks
entre ODBMSs e relacionais DBMSs tem 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.3
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 ODBMSs 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 presuposto 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.4
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 membras 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 tem 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 (ex. replicação),
gerenciamento de dados (ex. indexação espacial) e formato de dados (ex. XML) e incluir novas
características dentro deste padrão que dará suporte ao dominios onde as bancos
de dados orientadas a objeto estão sendo adotadas (ex. sistemas de Tempo real).
Nenhum comentário:
Postar um comentário