INTEGRAÇÃO ENTRE AS TECNOLOGIAS DE BANCO DE DADOS E ORIENTAÇÃO A OBJETOS Visão geral do modelo ODMG.
O modelo JDO.
ODL – a linguagem de definição de objetos.
VISÃO GERAL DO MODELO ODMG
PADRÕES PARA SGBDOOS
O sucesso dos sistemas de banco de dados relacionais não resulta apenas de um nível mais alto de independência de dados e um modelo de dados mais simples do que os sistemas anteriores. Seu sucesso se deve também à padronização que sofreram. A aceitação do padrão SQL permite o alto grau de portabilidade e interoperabilidade entre sistemas, simplifica o aprendizado de novos SGBDs relacionais e representa um amplo endosso da abordagem relacional. Portabilidade é a capacidade de executar um programa de aplicação particular em diferentes sistemas com modificações mínimas no programa. Interoperabilidade se refere à habilidade de uma aplicação em acessar múltiplos sistemas distintos. Em termos de banco de dados, isso significa que um mesmo programa de aplicação pode acessar alguns dados armazenados segundo um certo SGBD e outros dados armazenados por um outro SGBD.
Esses fatores são importantes também para SGBDs orientados a objetos. Na indústria de software há vários grupos trabalhando sobre padrões que afetam os SGBDOOs: o ODMG - Object Database Management Group (padrões gerais para SGBDOOs), o OMG - Object Management Group (padrão CORBA – Commom Object Request Broker Architecture, que permite que uma ampla variedade de objetos interaja em um ambiente distribuído), ANSI X3H2 (SQL padrão), ANSI X3J16 (C++ padrão), ANSI X3J20 (Smalltalk padrão). Esses padrões visam a portabilidade de código em alguma maneira.
Com relação a SGBD orientados a objetos, há três padrões: SQL-92, ODMG-93 e SQL3. Os dois principais grupos que trabalham sobre padrões para SGBD são o ODMG e o ANSI X3H2.
ANSI X3H2 é um comitê técnico do American National Standards Institute (ANSI), formado em 1978, para a definição de uma linguagem para bancos de dados CODASYL ou redes. Em 1982, o modelo relacional estava adquirindo importância, o que levou o comitê X3H2 a ser solicitado para desenvolver o padrão SQL. A versão corrente da SQL é a SQL-92, que é a culminação de trabalhos sobre várias versões anteriores. Ela é baseada na SQL-89, que por sua vez foi baseada na SQL-86.
SQL-92 é o padrão para SGBDs Relacionais. SQL-92 não introduz conceitos de objetos. O comitê reconheceu a importância de adição de objetos à sua especificação e tem trabalhado visando à definição da SQL3, que estende a SQL-92 para suportar objetos.
SQL3 mantém a compatibilidade com a SQL-92 (e versões anteriores do padrão), o que interfere na forma de seu suporte a objetos. Estes, no modelo de objetos da SQL3, são armazenados em tipos especiais de colunas em relações particulares. Assim, objetos não são considerados “primeira classe” porque eles não podem existir separadamente das relações, o que afeta operações tais como consultas. Não é possível acessar um objeto diretamente em SQL3; é necessário fazê-lo através da relação. Esse passo extra, de acesso a relação para poder recuperar o objeto, pode afetar o desempenho da aplicação, conforme avaliado em (Barry 1996).
SQL3 difere do resto dos padrões industriais de objeto. É um sistema fechado, definido somente em função de suas antecessoras. Ela não usa nenhum dos padrões do OMG ou da comunidade de programação de objeto.
ODMG-93
ODMG (Object Database Management Group) é um consórcio de vendedores e grupos de interesse que trabalham na criação de padrões para SGBDOOs. Ele foi concebido em 1991 e a versão 1.0 da especificação do padrão ODMG-93 (também chamado ODMG 1.0) foi publicada em agosto de1993. Em 1995 o grupo terminou a versão 1.2 do padrão ODMG-93 e posteriormente foi revisado e chamado ODMG 2.0.
A linguagem de consulta a Objeto (OQL) do ODMG-93 é baseada na porção de consulta da SQL-92, porém com algumas variações, pois a SQL-92 assume um modelo relacional e a OQL assume um modelo de objeto.
A meta do ODMG é tornar disponível um conjunto de padrões permitindo que um cliente de SGBDOO escreva aplicações portáveis, isto é, aplicações que possam ser executadas por diferentes SGBDOOs. Assim, os esquemas de dados, ligações com linguagens de programação; manipulação de dados e linguagens de consulta devem ser portáveis.
Segundo Cattell, em (Cattell 1996), as companhias que são membro do ODMG (Cattell é um dos membros do grupo), representando quase toda a indústria de SGBDOO, estão suportando esse padrão. A meta não é a produção de SGBDOOs idênticos, e sim, portabilidade de código fonte. Haverá diferenças entre produtos relativas a desempenho, linguagens suportadas, funcionalidade única para segmentos particulares do mercado, ferramentas de construção de aplicações, construtores de interfaces de usuário gráficas (GUI), entre outros.
O trabalho de padronização, apresentado pelo grupo, é derivado, principalmente, pela combinação das características mais fortes dos SGBDOOs correntemente disponíveis.
O grupo define um SGBDOO como sendo um SGBD que integra capacidades de banco de dados com capacidades de linguagem de programação orientada a objetos. Um SGBDOO faz com que objetos do banco de dados apresentem-se como objetos de linguagem de programação, em uma ou mais linguagens existentes. Os SGBDOOs têm sido integrados com C++, C, Smalltalk, LISP e Java.
Os principais componentes do ODMG-93 são: - um Modelo de Objetos
- uma Linguagem de Definição de Objetos (ODL), Object Definition languagem que equivale a DDL dos SGBD convencionais.
- uma Linguagem de Consulta a Objetos (OQL) declarativa (não procedural) para consultar e atualizar objetos do banco de dados. Foi usado o padrão SQL como base, porém OQL suporta capacidades mais poderosas. O grupo espera que SQL3 irá convergir com a OQL futuramente.
- Ligação com a linguagem C++. Isso inclui uma versão da ODL que usa a sintaxe de C++, um mecanismo para invocar OQL e procedimentos para operações sobre banco de dados e transações.
Várias das idéias embutidas no modelo de objetos ODMG são baseadas em duas décadas de pesquisa em modelagem conceitual e bancos de dados orientados a objetos realizados por muitos pesquisadores.
Arquitetura de um sistema gerenciador de base de objetos no padrão ODMG.
Várias companhias passaram a suportar esse padrão em seus produtos a partir final de 1995.
MODELO DE OBJETOS ODMG
O modelo de objetos do ODMG é o modelo de referência para um banco de dados orientado a objetos. Esse modelo especifica construções que são suportadas por um SGBDOO, tais como: características dos objetos, relacionamentos entre os objetos, e como os objetos podem ser nomeados e identificados.
As principais características do modelo de objetos ODMG são:
• As primitivas do modelo, objeto, que possui um identificador único (pode ser referenciado), e literal, que não possui identificador (não pode ser referenciado);
• O estado de um objeto é definido pelos valores de suas propriedades (atributos e relacionamentos);
• O comportamento de um objeto é determinado pelo conjunto de operações (apenas as assinaturas das operações);
• Tanto objetos quanto literais podem ser de um tipo. Todos os elementos de um determinado tipo possuem um mesmo conjunto de propriedades e comportamento;
• Um modelo específico é construído usando a ODL (independente de linguagem ou não). TIPOS
O conceito de tipo no ODMG possui dois aspectos importantes em sua definição, os quais se referem aos níveis de abstração:
• Uma especificação externa (nível de especificação) - é uma definição abstrata de operações que podem ser chamadas, de propriedades (atributos e relacionamentos) que cada objeto possui e de exceções que podem ser sinalizadas;
• Uma ou mais implementações (nível de implementação) - é a implementação das operações e outros detalhes internos em uma ou mais linguagens específicas de programação.
Existem três formas para especificações externas:
• Definição de interface - define apenas o comportamento de um tipo objeto e não pode ser instanciada;
• Definição de classe - define o estado e o comportamento de um tipo objeto e pode ser instanciada;
• Definição de literal - define apenas o estado de um tipo literal.
A implementação define uma representação da especificação em uma determinada linguagem de programação da seguinte forma:
• Associa a cada propriedade abstrata uma variável de instância, de acordo com a LPOO escolhida;
• Define para cada operação abstrata um método (corpo de um procedimento que implementa a operação).
A forma de mapear conceitos abstratos para uma LPOO varia de linguagem para linguagem. Por exemplo, um literal struct é mapeado no C++ diretamente para o equivalente, porém em Java ou Smalltalk, ele é mapeado para uma classe sem métodos. No caso de um literal
float em C++ e Java tem-se o equivalente, porém em Smalltalk é transformado para a classe Float.
HERANÇA
A herança pode ser definida de duas formas:
• ISA ou is-a - representa herança de comportamento. Neste caso, apenas interfaces podem ser herdadas, mas tanto classes quanto interfaces podem herdá-las. Pode-se ter herança múltipla, ou seja, é possível herdar de várias interfaces. A forma de representá-la é através de dois pontos (:). Por exemplo:
• Extends - representa herança de estado e comportamento. Neste caso, a herança é dada apenas entre classes, não podendo haver herança múltipla. A forma de representá-la é através da palavra extends. Por exemplo:
A mesma classe pode também apresentar os dois tipos de herança, por exemplo:
Logo, uma interface, ou uma classe, pode apresentar herança do tipo is-a de várias outras interfaces, e uma classe pode ter herança do tipo extends de, no máximo, uma outra classe.
EXTENT
A extensão de um tipo (extent) é formada por todas as instâncias deste tipo que existem no banco de dados. Se o projetista desejar, esta extensão é mantida automaticamente pelo SGBDOO. A manutenção do extent envolve a inclusão e remoção de instâncias, bem como a criação e manutenção de índices para estas. Por exemplo, na classe Pessoa, pode-se declarar o seu extent conforme descrito a seguir:
CHAVES
O conceito de chaves no modelo de objetos ODMG é apenas uma restrição de unicidade de valor e não tem o papel de OID, nem de referência entre objetos. Portanto, chave em ODMG corresponde a um ou a mais atributos cujos valores identificam uma instância dentro de uma extensão. Essa chave deve ser definida pelo usuário, enquanto o OID é definido pelo sistema.
OBJETOS
Existem alguns aspectos que devem ser considerados em relação aos objetos:
• O OID de um objeto o diferencia dos demais objetos dentro do BD, sendo gerado pelo SGBD. O OID se mantém imutável durante toda a vida do objeto. A estrutura do identificador não é definida pelo modelo e sim na implementação;
• Dois objetos são considerados iguais quando possuem os mesmos valores para os seus atributos;
• Dois objetos são considerados idênticos (isto é, o mesmo objeto) quando se referenciam ao mesmo OID;
• O método same_as() testa se dois objetos possuem o mesmo OID;
• O método copy() faz uma cópia de determinado objeto, o que resulta em dois objetos iguais;
• O método delete() remove o objeto da memória e do banco de dados;
• Os métodos same_as(), copy(), delete(), entre outros, estão definidos na interface Object, que é herdada por qualquer objeto definido pelo usuário;
• Acesso, criação, alteração ou remoção de objetos persistentes devem ser feitos dentro do escopo de uma transação;
• É permitido associar um ou mais nomes a um objeto. Este nome não é armazenado no objeto e sim mantido pelo SGBD, que fornece uma função que mapeia um nome de objeto para o objeto em si. É importante enfatizar que nomes de objetos não devem ser confundidos com chaves ou OIDs;
• Um objeto pode ser persistente (sobrevive à execução de um programa), ou transiente (ao terminar a execução do programa deixa de existir). Os dois podem ser manipulados pelas mesmas operações. Esses dois conceitos são independentes de tipo, pois um mesmo tipo pode possuir algumas instâncias persistentes e outras transientes;
• Um objeto pode ser do tipo atômico (definido pelo usuário), coleção ou estruturado;
• Os elementos de um objeto coleção devem ser todos de um mesmo tipo, podendo ser de um dos tipos de literais ou de um dos tipos de objetos. Os tipos de coleções são:
o Set<t> (conjunto) - sem ordenação e sem duplicatas; o Bag<t> (conjunto) - sem ordenação, mas aceita duplicatas; o List<t> (lista) - com ordenação e aceita duplicatas;
o Array<t>(arranjo) - com ordenação, aceita duplicatas e permite a localização de elementos por posição;
o Dictionary<t,v> (lista indexada) - com ordenação, aceita duplicatas e permite a localização de elementos por chave associada a cada elemento.
• Vários métodos podem ser aplicados a coleções, tais como - new(), is_empty(), contains_element(), etc.;
• Os objetos estruturados são: Date, Time, Timestamp e Interval. LITERAIS
Como visto anteriormente, os literais não possuem identificadores. Três tipos de literais são suportados pelo Modelo de Objetos:
• atômico - é representado por números e caracteres, tais como: long, short, unsigned long, unsigned short, float, double, boolean, octet, char, string, enum (enumeração);
• Coleção - é semelhante a um objeto coleção, porém não possui identificador de objeto. Os literais coleção existentes são: set<t>, bag<t>, list<t>, array<t>, dictionary<t>. Seus elementos podem ser de tipos literais ou tipos objetos.
• Estruturado - é representado por: date, interval, time, timestamp e definidos pelo usuário (structure<>).
Enquanto os atributos e os relacionamentos modelam o estado, as operações definem o comportamento.
O valor de um atributo é sempre um literal ou um identificador de objeto. No exemplo a seguir, os atributos nome e idade são literais, e depto é um identificador de objeto de uma instância de Departamento.
Os relacionamentos são propriedades definidas entre, no máximo, dois tipos, em que cada tipo participante do relacionamento tem que possuir um OID. O ODMG permite apenas relacionamentos binários, podendo ter cardinalidade um-para-um, um-para-muitos ou muitos-para-muitos.
Um relacionamento é definido explicitamente pela declaração de caminhos que permitem à aplicação usar as conexões lógicas entre os objetos envolvidos no relacionamento. Esses caminhos são declarados em pares, um para cada direção. A seguir, é mostrado um exemplo em que um professor ensina um conjunto de disciplinas, e uma disciplina é ensinada por um professor. O relacionamento declarado nas duas direções é apresentado nas duas classes Professor e Disciplina:
O SGBDOO é responsável por manter a integridade referencial dos relacionamentos. Se um objeto que participa de um relacionamento for removido, então qualquer caminho para aquele objeto deve ser removido também.
As operações são representadas apenas pelas suas assinaturas, que contêm o nome da operação, nome e tipo de cada argumento, tipo de valor retornado e exceções que podem ser sinalizadas pela operação.
O nome de uma operação deve ser único apenas dentro de uma definição de tipo. Assim, tipos diferentes podem ter operações definidas com o mesmo nome. Nestes casos, quando uma operação é chamada, uma operação específica deve ser selecionada para execução. Esta seleção é feita pegando-se o tipo mais específico do objeto fornecido como primeiro argumento da chamada.
Operações podem criar exceções, e estas podem passar os resultados das exceções. Quando uma exceção é criada, as informações sobre a sua causa são passadas para o manipulador de exceções como propriedades de uma exceção.
ODL – A LINGUAGEM DE DEFINIÇÃO DE OBJETOS
A ODL é a linguagem de definição para a especificação de tipos de objeto de acordo com o Modelo de Objetos ODMG. A ODL apresenta as seguintes características:
• Suporta todas as construções semânticas do modelo de objetos ODMG;
• Não é uma linguagem de programação completa, mas sim uma linguagem de definição para especificação de objetos;
• É independente de LPOO, o que permite que os usuários a usem para definir semânticas de esquema de uma forma independente de linguagem;
• É extensível, permitindo a especificação de tipos, incluindo propriedades e operações (somente assinaturas);
• Define as propriedades e operações dos tipos objeto, sendo que para as operações é descrita apenas a assinatura.
Gráfico de representação de esquema
Este padrão não especifica uma OML - Object Manipulation Language.
Definição utilizando ODL
OQL - LINGUAGEM DE CONSULTA A OBJETOS
A OQL é uma linguagem declarativa para consultar os objetos do BD proposta pelo modelo de objetos ODMG. As principais características da OQL são:
• Suporta as cláusulas SELECT, FROM, WHERE, GROUP BY, HAVING e ORDER BY;
• Pode ser usada por usuários ou embutida de uma linguagem de programação;
• Fornece primitivas de alto nível para lidar com set, structure, list e array, tratando estas construções com a mesma eficiência;
• Possui uma sintaxe baseada no SQL, mas a composição é mais livre;
• Pode chamar métodos dos tipos envolvidos na consulta;
• Não fornece operadores para atualização, mas pode chamar operações definidas nos objetos para realizar esta tarefa. Assim, não viola a semântica do modelo de objetos, o qual, por definição, é gerenciado pelos métodos especificados no objeto;
• É possível definir um nome para uma determinada consulta, que é armazenada no BD. Para uso posterior, a consulta é referenciada através do nome definido;
• Apresenta construtores de objetos, structure, set, list, bag e array.
A sintaxe básica da OQL é uma estrutura select... from... where, igual a da SQL. É possível fazer consultas sobre extensões de classes, como também nomes de objetos. Para ilustrar a primeira situação, é mostrado um exemplo em que se tem um tipo Pessoa com o extent Pessoas, com atributos nome, data de nascimento e sexo e com a operação idade. A consulta apresentada a seguir recupera o conjunto de Pessoas chamadas "Carlos", juntamente com suas diferentes idades.
Exemplo de Consulta
Existem três opções sintáticas para especificar variáveis de iteração. p in pessoas
pessoas p pessoas as p
A possibilidade de utilizar o método na consulta é uma característica importante desta linguagem. Na consulta apresentada anteriormente, por exemplo, é utilizado o método idade. Utilizando DISTINCT é retornado um set<integer>; caso contrário, seria retornado um bag<integer>. Se além do DISTINCT fosse utilizado o termo ORDER BY, o retorno seria um list<integer>.
EXPRESSÕES DE CAMINHO
As expressões de caminho servem para navegar através de relacionamentos (um-para-um) e objetos complexos, sendo representadas por "."ou !. Podem existir chamadas a métodos no meio destas expressões. A seguir, é mostrado um exemplo em que a partir de uma Pessoa p, deseja-se saber o nome da cidade onde o cônjuge desta pessoa mora.
SELECT DISTINCT p.idade FROM p in pessoas
WHERE p.nome = “Carlos”
Esta consulta começa por uma pessoa p, pega seu cônjuge que é outra pessoa, vai dentro do atributo complexo do tipo endereço para pegar o objeto cidade e, então, acessa o nome da cidade.
Porém, deve-se ter cuidado quando o resultado esperado é um conjunto. Por exemplo, a consulta a seguir retorna o nome dos filhos de uma pessoa.
Se for utilizado apenas p.filhos.nome, o resultado será o nome da lista dos filhos e não o nome dos filhos. Como filhos é uma lista de referências, o resultado da consulta seria um valor indefinido.
VALORES INDEFINIDOS
Uma propriedade não definida referencia o objeto nil, que, se for acessado, devolve como resultado o valor undefined. O undefined é um valor literal especial que, dentro da OQL, é tido como valor válido para qualquer tipo literal ou objeto. Algumas das regras que envolvem este valor são:
• is_defined(predicado) e is_undefined(predicado) testam se um predicado é definido ou não;
• Se o predicado definido em uma cláusula WHERE retorna undefined, isto é tratado como se fosse retornado false;
• O valor undefined é válido para a operação count, ou seja, é considerado da mesma forma que qualquer outro valor;
• O undefined é um valor válido para expressões de construção (construção de objetos, estruturas, sets, lists, bags e arrays);
• Qualquer outra operação com operandos undefined resultam em undefined.
A seguir são mostrados alguns exemplos de consultas com seus respectivos resultados, considerando que o BD contém três pessoas: uma morando em Porto Alegre, outra em Caxias e a última com endereço nil.
SELECT f.nome FROM p.filhos f
Exemplos de consulta
JDO – JAVA DATA OBJECTS
O Java Data Objetcs (JDO) teve sua primeira versão disponibilizada em 2002 e mais tarde em 2003 sofreu uma manutenção. Esta primeira versão disponibilizada criou uma abstração do banco de dados que permitiu o acesso aos dados armazenados sem a necessidade do conhecimento intrínseco da API dos bancos de dados. O objetivo é separar a manipulação dos dados realizada pela linguagem de programação da manipulação dos dados realizada pelo SGBD. Esta separação de interesses permite um alto grau de independência da visão de dados do Java em relação à visão dos dados do banco de dados.
As interfaces definidas para o usuário são:
- PersistenceManager – é o componente responsável pelo ciclo de vida das instâncias persistentes, fábrica de consultas (Query), e acesso a transações (Transactions);
- Query – componente responsável por consultar os dados armazenados e retornar as instâncias persistentes ou os valores;
- Transaction – é o componente responsável por iniciar e completar as transações.
O JDO foi desenvolvido pela empresa Sun Microsystems que decidiu doá-lo para a comunidade de código livre. Desde então as especificações ficaram submetidas ao projeto denominado Apache JDO que tem o foco principal na construção de uma interface e testes de compatibilidade das implementações no JDO. Implementações comerciais e de código livre estão disponíveis para banco de dados relacionais e orientados a objetos além dos sistemas de arquivos.
A estas implementações algumas características têm sido incluídas. Dentre elas se destacam:
- Mapeamento do banco de dados relacional, vendedores diferentes do padrão JDO têm implementado mapeamentos diferentes para os diversos bancos de dados existentes no mercado e o mapeamento deixa de ser portável entre os vendedores. A comunidade JCP, Java Community Process através do pedido de especificação Java (JSR – Java Specification Request) mapeou um formato comum que permitirá uma grande portabilidade das aplicações e;
- Extensões para a consulta JDO, JDOQL fornece uma maneira padronizada para acessar instâncias baseada em valores e relacionamentos, mas isto é limitado no que pode ser retornado como valor. Os valores de retorno serão estendidos para incluir campos projetados, coleções de instâncias identificadas em expressões navegacionais e dados agregados como MIN, MAX, SUM, AVG e COUNT. Métodos adicionais serão definidos para permitir a manipulação de cadeia de caracteres (string) em filtros.
As especificações vêm criando uma camada de acesso a dados com diversas vantagens que proporcionam benefícios nas implementações das aplicações, benefícios como:
- serem fáceis de utilizar, pois os programadores focam no modelo de negócio deixando os detalhes sobre o armazenamento ser tratado pelo JDO;
- são portáveis, as aplicações podem ser executadas em múltiplos sistemas sem a necessidade de alteração no código fonte;
- são independentes de banco de dados, as aplicações podem comunicar com os diferentes bancos de dados existentes no mercado e;
- têm alta performance, uma vez que os detalhes da comunicação com os dados estão na camada JDO ocorre uma otimização do acesso aos mesmos.
Novas especificações, freqüentemente, são submetidas à comunidade JSP para aprovação e conseqüente alteração na camada JDO, desta maneira, é muito importante ao iniciar um trabalho que utilizará a camada JDO verificar as especificações aprovadas e as que estão em aprovação para usufruir ao máximo dos recursos disponibilizados por esta tecnologia de acesso a banco de dados.
BIBLIOGRAFIA
ELMASRI, R. & NAVATHE, S. B. Sistemas de Bancos de Dados – Fundamentos e Aplicações. 4a Edição. São Paulo: Pearson, 2005.
Barry, D.K. The Object Database Handbook. John Wiley & Sons, Inc. 1996.
Bertino, E.; Martino, L. (1993). Object-Oriented Database Systems: Concepts and Architectures. Addison-Wesley, 1993.
Blaha, M.; Premerli, W. Object-Oriented Modeling and Design for Database Applications. Prentice-Hall, 1998.
Cattel, R.G.G. Object-Oriented and Extended Relational Database Systems. Addison-Wesley, 1994.
Cattell, R.G.G.; Barry, D.K. The Object Database Standard: ODMG-3.0. Morgan Kaufmann Publishers, inc., 2000.
Hughes, J.G. Object-Oriented Databases. Prentice-Hall, 1991.
Khoshafian, S. Banco de Dados Orientado a Objeto. Livraria e Editora Infobook S.A., 1994.
Vieira, M.T.P. (1991) Um modelo de Objetos para um Sistema de Gerência de Objetos em Ambiente de Desenvolvimento de Sistemas Interativos. Tese de Doutorado, Departamento de Informática, PUC-RJ, 1991.
Zand, M.; Collins, V.; Caviness, D. A Survey of Current Object-Oriented Databases. In: DATA BASE Advances in Information Systems, Vol.26, No. 1, February, 1995.
