Mapeamento Objeto-Relacional

Mapeando Objetos para Bancos de Dados Relacionais: técnicas e implementações

Introdução

A adoção das metodologias de desenvolvimento Orientadas a Objetos como um padrão de mercado levou a uma mudança radical na estruturação e organização de informação. Contudo, a utilização de bancos de dados relacionais ainda é uma prática comum e será mantida por um longo período de tempo. Graças à necessidade de se trabalhar com estas bases de dados relacionais para o armazenamento persistente de dados, é comum a adaptação dos modelos de objetos na tentativa de compatibilizá-los com o modelo relacional. Para piorar ainda mais este quadro, é notório o esforço aplicado no processo de persistência manual dos objetos no banco de dados – o que força os desenvolvedores de aplicações a ter que dominar a linguagem SQL e utiliza-la para realizar acessos ao banco de dados. Estas duas questões principais levam a uma redução considerável na qualidade do produto final, construção de uma modelagem "orientada a objetos" inconsistente e a um desperdício considerável de tempo na implementação manual da persistência. Apesar disso, não é possível ignorar a força e confiabilidade dos Sistemas de Gerenciamento de Bancos de Dados (SGBDs) relacionais nos dias de hoje – após anos de desenvolvimento e ajustes de performance fazem dos bancos de dados relacionais a opção mais eficiente, se comparados à maioria dos SGBDs Orientados a Objetos.

Para permitir um processo de mapeamento entre sistemas baseados em objetos e bases de dados relacionais, foram propostas diversas idéias que convergiram para o conceito de Camada de Persistência.

Evolução dos modelos de Persistência de Objetos

No processo de desenvolvimento de aplicações Orientadas a Objetos, nem sempre é dada a devida atenção à forma como a persistência de objetos será gerenciada e implementada. Na grande maioria dos sistemas, incluir código SQL para acesso ao SGBD em meio ao restante da lógica do sistema é a solução adotada, graças à rapidez de implementação. Esta é uma escolha perigosa: sua adoção implica, muitas vezes, no acoplamento do sistema ao SGBD utilizado, o que dificulta o processo de manutenção de código. Além disso, quaisquer mudanças na estrutura (ou mesmo na nomenclatura de colunas) das tabelas existentes no Banco de Dados trazem o caos à aplicação – todo o código SQL codificado na aplicação tem que ser reescrito, recompilado e testado novamente.

Para diminuir este acoplamento, surge uma segunda opção: separar o código SQL das classes da aplicação, de forma que as alterações no modelo de dados requerem modificações apenas nas classes de acesso a dados (Data Access Classes), restringindo o impacto das mudanças no sistema como um todo. Esta estratégia, trás um maior controle quanto ao escopo dos possíveis erros gerados por mudanças no esquema de dados do sistema. No entanto, apesar da limpeza de código e melhor divisão de responsabilidades trazidas pela adoção das Data Classes, a solução está longe do ideal, por ainda manter os dois mundos (objetos e dados relacionais) intimamente ligados.

A principal função de uma camada de abstração de acesso a dados é garantir aos desenvolvedores de software a total independência entre o modelo de objetos e o esquema de dados do banco, permitindo que a base ou detalhes do esquema de dados sejam substituídos sem impacto nenhum na aplicação. Mais que isso, uma Camada de Persistência pode permitir o armazenamento dos dados em outros tipos de bases de dados (mecanismos de persistência) diferentes dos relacionais, incluindo os SGBDs Orientados a Objetos, Objeto-Relacionais e arquivos XML, por exemplo.

Camadas de Persistência

Conceitualmente, uma Camada de Persistência de Objetos é uma biblioteca que permite a realização do processo de persistência (isto é, o armazenamento e manutenção do estado de objetos em algum meio não-volátil, como um banco de dados) de forma transparente. Graças à independência entre a camada de persistência e o repositório (backend) utilizado, também é possível gerenciar a persistência de um modelo de objetos em diversos tipos de repositórios, teoricamente com pouco ou nenhum esforço extra. A utilização deste conceito permite ao desenvolvedor trabalhar como se estivesse em um sistema completamente orientado a objetos – utilizando métodos para incluir, alterar e remover objetos e uma linguagem de consulta para SGBDs Orientados a Objetos – comumente a linguagem OQL – para realizar consultas que retornam coleções de objetos instanciados.

Vantagens da utilização

As vantagens decorrentes do uso de uma Camada de Persistência no desenvolvimento de aplicações são evidentes: a sua utilização isola os acessos realizados diretamente ao banco de dados na aplicação, bem como centraliza os processos de construção de consultas (queries) e operações de manipulação de dados (insert, update e delete) em uma camada de objetos inacessível ao programador. Este encapsulamento de responsabilidades garante maior confiabilidade às aplicações e permite que, em alguns casos, o próprio SGBD ou a estrutura de suas tabelas possam ser modificados, sem trazer impacto à aplicação nem forçar a revisão e recompilação de códigos.

Requisitos de uma Camada de Persistência

Segundo Scott Ambler, pesquisador e autor de diversos livros, uma Camada de Persistência real deve implementar as seguintes características:

• Dar suporte a diversos tipos de mecanismos de persistência: um mecanismo de persistência pode ser definido como a estrutura que armazenará os dados – seja ela um SGBD relacional, um arquivo XML ou um SGBD OO, por exemplo. Uma Camada de Persistência deve suportar a substituição deste mecanismo livremente e permitir a gravação de estado de objetos em qualquer um destes meios.

• Encapsulamento completo da camada de dados: o usuário do sistema de persistência de dados deve utilizar-se, no máximo, de mensagens de alto nível como save ou delete para lidar com a persistência dos objetos, deixando o tratamento destas mensagens para a camada de persistência em si.

• Ações com multi-objetos: Suportar listas de objetos sendo instanciadas e retornadas da base de dados deve ser um item comum para qualquer implementação, tendo em vista a freqüência desta situação.

• Transações: ao utilizar-se da Camada de Persistência, o programador deve ser capaz

...