Persistência de Objetos
|
Persistência é a capacidade de um objeto de sobreviver fora dos limites da aplicação que o criou. Normalmente isto significa que o objeto tem que ser gravado em um meio de armazenamento persistente. Atualmente, a tecnologia mais utilizada para esse fim são os sistemas gerenciadores de bancos de dados relacionais (SGBDR), mas existem outras opções. O modelo relacional está baseado em uma única estrura de dados: a relação. Uma relação é uma tabela com linhas (tuplas) e colunas (atributos), as quais contêm um tipo de dado simples especificado (integer, character string,...). Aqui começa o problema de impedância entre a tecnologia de objetos e os bancos de dados relacionais. Os objetos podem ter estruturas complexas e, neste caso, será necessário um esforço adicional de programação para adaptá-los ao modelo relacional antes de armazená-los e outro para adequá-los novamente ao modelo de objetos no momento de recuperá-los. Esses esforços estão totalmente dissociados dos requisitos de negócio, trata-se de programação voltada à solução de problemas tecnológicos. Uma maneira de contornar esse problema de impedância é aplicar design patterns específicos para persistência de objetos [15]. Explicações detalhadas sobre o que são design patterns podem ser encontradas em livros [4] e em artigos publicados pelo próprio BateByte [5][6][7], mas resumindo, um pattern descreve um problema que se repete e o núcleo de uma solução para esse problema, de forma que se possa reutilizá-la diversas vezes. Outra alternativa é utilizar frameworks capazes de realizar o mapeamento objeto-relacional e vice-versa. Um framework é uma aplicação reusável, semi-completa que pode ser especializada para produzir aplicações customizadas [3][2]. Um exemplo de produto dessa natureza é o RW-Metro da Rogue Wave[12]. Segundo o fabricante, trata-se de um framework aberto, customizável e portável, destinado ao mapeamento de objetos para bancos de dados relacionais, o qual permite que o desenvolvedor se concentre apenas no modelo de objetos. A necessidade de armazenar e processar dados complexos em bancos de dados relacionais vem aumentando à medida que surgem sistemas de informação mais sofisticados, tais como aplicações multimídia para Web, aplicações na área de medicina, sistemas geográficos e espaciais, CAD/CAM, CASE, etc. [11]. Os bancos de dados relacionais oferecem o tipo BLOB (Binary Long Object) para esse fim, o qual é capaz de armazenar dados complexos como cadeias de bytes não interpretáveis. Isto significa que não é possível indexar uma coluna com esse tipo de dado, nem realizar query ou outras operações sobre essa coluna. Um BLOB tem que ser enviado à estação de trabalho, através da rede, para ser processado. Claramente, esta é uma situação bastante restritiva que foi solucionada por meio dos sistemas gerenciados de bancos de dados objeto-relacionais (SGBDOR). De um lado estavam os usuários de bancos de dados almejando pesquisar, acessar e manipular tipos de dados complexos com o padrão SQL, sem quebrar as regras do modelo relacional. Do outro lado estavam os fornecedores incapazes de implementar todos os tipos de dados e métodos de acesso requeridos pelos usuários. A solução foi tornar os SGBDs extensíveis, isto é, foi permitir a adição, a manipulação e a pesquisa eficiente de novos tipos de dados à medida que eles se fizessem necessários: assim surgiram os SGBDORs. Estender, neste contexto, significa adicionar tipos de dados definidos pelo usuário (UDTs – User-Defined Datatypes), adicionar funções definidas pelo usuário (UDFs – User-Defined Functions), adicionar métodos de acesso definidos pelo usuário e alterar o otimizador de query que também deve ser extensível. Usuários e aplicações simplesmente invocam UDFs e não precisam entender sua estrutura interna. A IBM, a Oracle e a Informix já entraram nesse mercado e a diferença entre os seus produtos está nos padrões adotados e no ambiente de desenvolvimento oferecido. Os Oracle Cartridges baseiam-se nos padrões CORBA 2.0 e IDL da OMG e podem ser aplicados no banco de dados, no servidor de aplicação e no cliente. Os DB2 Relational Extenders baseiam-se no padrão SQL3. E a Informix oferece o DBDK, um conjunto de ferramentas para o desenvolvimento, gerenciamento e integração dos databladers no servidor Informix [11]. Adicionar uma nova classe de objetos a um SGBD relacional não é uma tarefa trivial. É necessário definir o UDT, desenvolver várias UDFs, especificar estatísticas para o otimizador de query, implementar algumas verificações e restrições, empacotar tudo isso e instalar no servidor de banco de dados. Por esse motivo, os especialistas da área acreditam que um grande percentual de aplicações funcionará com os tipos de dados padrão oferecidos pelo SGBD. Dentre as aplicações restantes, grande parte será satisfeita com classes de objetos desenvolvidas por terceiros especializados. Além disso, acredita-se que os SGBDs vão incorporar os bons produtos desenvolvidos por terceiros. Atualmente, as classes ainda têm que ser portadas para cada SGBD. Será necessário um bom tempo e muita negociação para que as diferentes extensões de SGBD se tornem um padrão comum de implementação [11]. Representar um objeto complexo em um modelo relacional significa subdividir o objeto em um grande número de tuplas e realizar diversas operações join na hora de reconstruir o objeto. Isto é ruim. Representar um objeto complexo em um modelo objeto-relacional é difícil. Surge, então, uma nova alternativa para persistir objetos: são os sistemas gerenciadores de bancos de dados orientados a objetos (SGBDOO). Eles implementam de forma natural os modelos orientados a objetos, isto é, os conceitos de classe, objeto, tipo, identidade, igualdade, encapsulamento, herança, agregação, método e polimorfismo (overloading, overriding e late binding). Além disso, possuem mecanismos especiais para controlar transações entre objetos, técnicas de armazenamento que facilitam a recuperação rápida de objetos complexos (clustering) e funções adicionais para coordenar atividades cooperativas, tais como mecanismos para avisar os usuários sobre mudanças de estado nos objetos e para notificar a disponibilidade dos objetos. O acesso aos objetos é mais versátil quando se utiliza um SGBDOO, já que é possível fazê-lo de forma navegacional ou por meio de linguagens do tipo SQL. Usando SGBDRs, a única maneira de acessar os dados é através de linguagens de consulta. Há algum tempo a OMG [8] produziu a especificação de um serviço de persistência CORBA [9][10][13], a qual foi bastante contestada e acabou não sendo implementada por ninguém. Em julho deste ano, um grupo de empresas importantes submeteu à OMG uma especificação conjunta de um novo serviço de persistência denominado Persistent State Service 2.0. Entre essas empresas podemos destacar: FUJITSU, INPRISE, IONA, Objectivity, Oracale, Persistence Software, Secant Technologies, Sun Microsystems e TIBCO Software. Houve colaboração de outras empresas, tais como HP, IBM, Lucent Technologies, Novell, Object Design, Poet Software, Rogue Wave Software, Versant, etc. O padrão proposto se aproxima bastante do paradigma de bancos de dados orientados a objetos. Como se não bastassem todas essas alternativas de persistência, existe ainda um padrão de armazenamento de objetos definido pela ODMG: o ODMG 2.0. Ele foi construído sobre padrões existentes de linguagem de programação, objetos e bancos de dados com o objetivo de simplificar o armazenamento de objetos e garantir a portabilidade das aplicações [1]. O ODMG 2.0 estende Java, C++ e Smaltalk com facilidades completas para programação de banco de dados, de tal forma que os desenvolvedores podem trabalhar apenas dentro do ambiente nativo da linguagem. Eles podem armazenar objetos diretamente em bancos de dados relacionais, objeto-relacionais e orientados a objetos, que sejam compatíveis com o padrão ODMG 2.0 [1]. A maioria absoluta dos sistemas de informação voltados à gestão empresarial depende fortemente de objetos persistentes, o que torna a persistência um fator crítico de sucesso para essa categoria de sistemas. Já sabemos que existem diversas maneiras de armazenar objetos, mas não sabemos exatamente quais são as vantagens e as limitações de cada alternativa, conseqüentemente não sabemos quando utilizar cada uma delas. Nossa meta é estudar mais a fundo essas opções e propor uma solução de persistência para a CELEPAR que seja robusta e eficiente, sem a qual não será possível uma migração completa para a tecnologia de objetos. REFERÊNCIAS BIBLIOGRÁFICAS
|
 |