Bd Orientado A Objetos-2

Hoje, o banco de dados orientados a objeto é um fator emergente que integra banco de dados e a tecnologia de orientação a objetos. Por um lado, a necessidade de realizar manipulações complexas para os banco de dados existentes e uma nova geração de aplicações de banco de dados geralmente requisitam mais diretamente um banco de dados orientado a objeto. Por outro lado, aplicações de linguagens orientadas a objeto e sistemas estão exigindo capacidades de banco de dados, tais como continuidade, simultaneidade e transações, dos seus ambientes. Estas necessidades estão levando à criação de sistemas poderosos, chamados banco de dados orientados a objeto. Os bancos de dados orientados a objeto iniciaram-se primeiramente em projetos de pesquisa nas universidade e centros de pesquisa. Em meados dos anos 80, eles começaram a se tornar produtos comercialmente viaveis. Hoje, eles são mais de 25 produtos no mercado.

Conceitos Básicos O desenvolvimento dos Sistemas de Gerenciamento de Banco de Dados Orientado a Objetos (SGBDOO) teve origem na combinação de idéias dos modelos de dados tradicionais e de linguagens de programação orientada a objetos. No SGBDOO, a noção de objeto é usada no nível lógico e possui características não encontradas nas linguagens de programação tradicionais, como operadores de manipulação de estruturas, gerenciamento de armazenamento, tratamento de integridade e persistência dos dados. Os modelos de dados orientados a objetos tem um papel importante nos SGBDs porque, em primeiro lugar, são mais adequados para o tratamento de objetos complexos (textos, gráficos, imagens) e dinâmicos (programas, simulações). Depois, por possuírem maior naturalidade conceitual e, finalmente, por estarem em consonância com fortes tendências em linguagens de programação e engenharia de software. O casamento entre as linguagens de programação e banco de dados é um dos problemas que estão sendo tratados de forma mais adequada no contexto de orientação a objetos. Apresenta-se adiante os conceitos básicos de modelos de dados e SGBDs orientados a objetos.

Modelos de Dados Orientados a Objetos Superficialmente, pode-se dizer que orientação a objetos corresponde à organização de sistemas como uma coleção de objetos que integram estruturas de dados e comportamento. Além desta noção básica, a abordagem inclui um certo número de conceitos, princípios e mecanismos que a diferenciam das demais. Seus principais conceitos são apresentados em seguida. Abstração É a consideração apenas das propriedades comuns de um conjunto de objetos, omitindo os detalhes, utilizada com freqüência na definição de valores similares e na formação de um tipo a partir de outro, em diferentes níveis de abstração. O uso de abstrações permite a geração de tipos baseada em hierarquias de tipos e de relacionamentos. Os principais conceitos de abstração utilizados em banco de dados são generalização e agregação. A generalização corresponde à associação "é um" onde, a partir de propriedades comuns de diferentes entidades, é criada uma outra entidade. O processo inverso é a especialização. A agregação corresponde a associação "parte de".

Objeto Os objetos são abstrações de dados do mundo real, com uma interface de nomes de operações e um estado local que permanece oculto. As abstrações da representação e das operações são ambas suportadas no modelo de dados orientado a objetos, ou seja, são incorporadas as noções de estruturas de dados e de comportamento. Um objeto tem um estado interno descrito por atributos que podem apenas ser acessados ou modificados através de operações definidas pelo criador do objeto. Um objeto individual é chamado de instância ou ocorrência de objeto. A parte estrutural de um objeto (em banco de dados) é similar à noção de entidade no modelo Entidade-Relacionamento. Identidade de Objeto Num modelo com identidade de objetos, estes têm existência independente de seus valores correntes e dos endereços de armazenamento físico. A identidade do objeto é geralmente gerada pelo sistema. A impossibilidade de garantir a identificação de objetos exclusivamente através de suas propriedades estruturais e comportamentais motivou a definição de identificadores únicos de objetos, que persistem no tempo de forma independente ao estado interno do objeto. A identidade de objetos elimina as anomalias de atualização e de integridade referencial, uma vez que a atualização de um objeto será automaticamente refletida nos objetos que o referenciam e que o identificador de um objeto não tem seu valor alterado. Objetos Complexos Os objetos complexos são formados por construtores (conjuntos, listas, tuplas, registros, coleções, arrays) aplicados a objetos simples (inteiros, booleanos, strings). Nos modelos orientados a objetos, os construtores são em geral ortogonais, isto é, qualquer construtor pode ser aplicado a qualquer objeto. No modelo relacional este não é o caso, visto que só é possível aplicar o construtor de conjuntos às tuplas e o construtor de registro a valores atômicos. A manutenção de objetos complexos, independente de sua composição, requer a definição de operadores apropriados para sua manipulação como um todo, e transitivos para seus componentes. Exemplos destas operações são: a atualização ou remoção de um objeto e cópia profunda ou rasa. Encapsulamento O encapsulamento possibilita a distinção entre a especificação e a implementação das operações de um objeto, além de prover a modularidade que permite uma melhor estruturação das aplicações ditas complexas, bem como a segurança dentro do sistema. Em banco de dados se diz que um objeto está encapsulado quando o estado é oculto ao usuário e o objeto pode ser consultado e modificado exclusivamente por meio das operações a ele associadas. Existe uma certa discussão sobre as consultas em banco de dados quando está incorporada a noção de encapsulamento: Deve-se tornar visível apenas as operações e deixar ocultos os dados e as implementações ? É interessante relaxar o encapsulamento apenas para as consultas ? Como deve ser realizada a otimização de consultas em SGBDOO com encapsulamentos ? Tipo de Objetos O tipo de objeto pode ser visto como a descrição ou especificação de objetos. Um tipo possui duas partes, interface (visível para o usuário do tipo) e implementação (visível só para o usuário construtor do tipo). Existem várias vantagens em se ter um sistema de tipos em um modelo de dados. Além de modularidade e segurança, do ponto de vista da evolução do sistema os tipos são especificações do comportamento que podem ser compostos e modificados incrementalmente, para formar novas especificações.

Classes Um conjunto de objetos que possui o mesmo tipo (atributos, relacionamentos, operações) pode ser agrupado para formar uma classe. A noção de classe é associada ao tempo de execução, podendo ser vista como uma representação por extensão, enquanto que o tipo é uma representação intencional. Cada classe tem um tipo associado, o qual especifica a estrutura e o comportamento de seus objetos. Assim, a extensão da classe denota o conjunto dos objetos atualmente existentes na classe e o tipo provê a estrutura destes objetos. Herança Herança é um mecanismo que permite ao usuário definir tipos de forma incremental, por refinamento de outros já existentes, permitindo composição de tipos em que as propriedades de um ou mais tipos são reutilizadas na definição de um novo tipo. De fato, ela corresponde a transferência de propriedades estruturais e de comportamento de uma classe para suas subclasses. As principais vantagens de herança são prover uma maior expressividade na modelagem dos dados, facilitar a reusabilidade de objetos e definir classes por refinamento, podendo fatorar especificações e implementações como na adaptação de métodos gerais para casos particulares, redefinindo-os para estes, e simplificando a evolução e a reusabilidade de esquemas de banco de dados. Tipos de Herança Os dois tipos de herança, simples e múltipla, são descritos a seguir: Herança Simples: Na herança simples um certo tipo pode ter apenas um supertipo, da mesma forma uma subclasse só herda diretamente de uma única classe. Podemos classificar esta herança em quatro subtipos: de substituição, de inclusão, de restrição e de especialização. Herança Múltipla: Nesta herança um tipo pode ter supertipos e os mesmos refinamentos de herança simples. Há basicamente dois tipos de conflitos referentes à herança múltipla: entre o tipo e o supertipo e entre múltiplos supertipos. O primeiro pode ser resolvido dando-se prioridade à definição presente no tipo, e não a no supertipo. Com os conflitos entre múltiplos supertipos, como uma resolução por default pode causar heranças não desejadas, a abordagem mais segura é baseada na requisição explícita da intervenção do usuário. Métodos e Mensagens Um método, em relação a um objeto, corresponde ao comportamento dos objetos, implementando uma operação associada a uma ou mais classes, de forma similar aos códigos dos procedimentos usados em linguagens de programação tradicionais, que manipula o objeto ou parte deste. Cada objeto tem um certo número de operações para ele definida. Para cada operação pode-se ter um ou mais métodos de implementação associados. As mensagens são a forma mais usada para se ativar os métodos. Num SGBDOO os objetos se comunicam e são ativados através de mensagens enviadas entre eles. Polimorfismo Em sistemas polimórficos uma mesma operação pode se comportar de diferentes formas em classes distintas. Como exemplo temos o operação print que será implementada de forma diferente se o objeto correspondente for um texto ou uma imagem: dependendo do objeto teremos um tipo de impressão. Tem-se também polimorfismo quando ocorre a passagem de diferentes tios de objetos como parâmetros enviados a outros objetos Um mesmo nome pode ser usado por mais de uma operação definida sobre diferentes objetos, o que caracteriza uma sobrecarga (overloading). A redefinição do operador para cada um dos tipos de objetos definidos caracteriza uma sobreposição (overriding). As operações são ligadas aos programas em tempo de execução caracterizando o acoplamento tardio ou late binding. Outros conceitos Finalmente há duas propriedades fundamentais para a construção de um SGBDOO: extensibilidade e completude computacional. A primeira garante que o conjunto de tipos oferecidos pelo sistema permite a definição de novos tipos e não há distinção entre os tipos

pré-definidos e os definidos pelo usuário. A segunda implica que a linguagem de manipulação de um banco de dados orientado a objetos pode exprimir qualquer função computacional.

o modelo objecto (SGBDO, Sistema de gestão de bases de dados objecto): os dados são armazenados sob a forma de objectos, quer dizer, de estruturas chamadas classes que apresentam dados membros. Os campos são instâncias destas classes

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. 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. Segundo, os dados são geralmente manipulados pela aplicação escrita usando linguagens de programação orientada a objetos, como C++, C#, Java ou Delphi, 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 80, buscando ter sustentação intrínseca da gerência da base de dados para objetos gráfico-estruturados. O termo “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 90 vimos novos produtos comerciais entrarem no mercado. Deste inclui-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), O2[2] (O2 Technology, surgiu de várias companhias, adquirido pela Informix, 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 mantem 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 da programação orientada a objetos. No ínicio 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 90, o C++ dominou o mercado comercial de Gerenciadores de Banco de Dados Orientados a Objetos. Os vendedores acrescentaram o Java no final dos anos 90 e mais recentemente o C#.

Adoção de Banco de Dados Orientado a Objetos Banco de dados orientados a objetos baseados numa programação persistente adquiriram um nicho nas áreas como banco de dados espaciais, telecomunicações, e áreas científicas como física de alta energia e Biologia molecular. Eles tiveram pouco impacto nas principais aplicações comerciais de processamento de dados, embora sejam utilizados em algumas áreas especializadas em serviços financeiros. Há também que notar que estes bancos guardam a maior base de dados do mundo ( mais de 1000 Terabytes da Stanford Linear Accelerator Center) e tem a maior taxa de inserção atingida por um banco de dados comercial ( mais de um Terabyte por hora). Iniciando em 2004, os bancos de dados orientados a objetos tiveram um segundo período de crescimento quando os projetos de banco de dados livres surgiram com diversos recursos e de fácil uso, porque eles eram totalmente escritos em linguagens orientada a objetos, como o Java, C++ ou 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 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. Isso é na área das linguagens de consulta orientada a objetos, e 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 são geralmente nã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 banco 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 banco de dados orientados a objetos ainda provem 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 eficientemente 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 as 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.

Padrões 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 idéias 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).