Mapeamento Objeto-Relacional
Tecnologia, impedância, herança

Toda evolução da tecnologia exige uma evolução nas pessoas e nos processos. Neste artigo, vamos explicar sobre o mapeamento objeto-relacional e as diferenças existentes no modelo de objetos para o modelo de dados e a visão das tabelas do sistema. O objetivo aqui é apresentar conceitos da tecnologia ORM, mostrando algumas limitações e fundamentos importantes para a consolidação do seu conhecimento.

Poucas tecnologias ofereceram tanto impacto no dia-a-dia dos desenvolvedores como os frameworks de mapeamento objeto-relacional ou simplesmente ORM. A tecnologia da orientação a objetos ofereceu um novo horizonte e uma caixa de ferramentas muito mais poderosa para implementar soluções de sucesso, fáceis de manter e de evoluir. Porém, o modelo relacional e as tabelas do banco de dados ainda são realidade nos projetos de software. Isso se deve pelo fato que, a teoria relacional de Edgar Frank Codd, com grande contribuição de Chris J. Date, perdura desde os anos 60 como a melhor maneira de se arranjar, armazenar e recuperar dados facilmente. Um resumo da teoria relacional seria “dados organizados em colunas e tabelas, permitindo imposição de restrições de consistências”. Esta teoria ainda é fundamentalmente válida sendo base de todos os bancos de dados do mercado.
O modelo de objetos surgiu estabelecendo um novo paradigma, principalmente sobre o modelo procedural. O modelo procedural é altamente dependente do modelo relacional, em que os dados existem, porém, procedures e functions muitas vezes são difíceis de manter e evoluir, pois a consistência e a coesão dos programas são muito fracas. O modelo de objetos foi proposto exatamente para aumentar essa coesão, porém, uma característica de um objeto de negócio é manter o seu estado para uma posterior recuperação. Muitas vezes isso é decorrência de uma necessidade do fluxo do negócio, ou simplesmente os dados devem ser gravados para uma posterior análise de valor (principalmente estatística). Nesse quesito, o modelo de objetos é relativamente pobre comparado com o modelo relacional. Uma solução proposta foi juntar o melhor de cada modelo, deixando os objetos responsáveis pelas regras de negócio e o banco de dados responsável por garantir um estado persistente dos objetos, e ao mesmo tempo facilitando a busca e análise das informações. Uma das maneiras de se alcançar esse objetivo é o Mapeamento Objeto-Relacional (no inglês: Object-Relational Mapping, ou simplesmente ORM).

Hibernate para Milhares de Registros
Veja na prática como retirar as amarras desse fantástico framework e permitir a manipulação de mais de 500 mil objetos com apenas uma transação

Atualmente, o Hibernate é um dos mais populares frameworks de persistência do mundo Java. Quando lidamos com uma quantidade muito grande de dados, o Hibernate apresenta uma série de problemas. Isso se deve ao fato do Hibernate ser disponibilizado numa configuração Default para uso geral. Neste artigo, veremos como alterar essas configurações e algumas opções que facilitam a manipulação de grandes massas de dados.

o mundo da informática, os dados existem aos milhares, aos milhões, aos mega, giga e terabytes. Quando ocorre a necessidade da manipulação de grandes quantidades desses dados, começam a surgir problemas. Em locais onde o Hibernate é utilizado, esses problemas podem se tornar críticos com um volume de dados inferior ao de outras tecnologias (ex.: JDBC).
Como foco deste artigo, vamos procurar explorar alguns features do Hibernate para manipulação de grandes volumes de dados. O conteúdo deste artigo cobre bem a manipulação de 100 mil registros ou mais. Nele, tentaremos cobrir as quatro operações do CRUD (Create, Retrieve, Update and Delete).
O Hibernate nos fornece uma série de featues: mapeamento objeto-relacional, cache, HQL, criterias, entre outros. Apesar de features importantes, todas essas contribuem com certo overhead, que pode tornar o uso do hibernate inviável em determinadas situações.
Para este artigo, irei utilizar o JavaDB (Apache Derby) como SGBD (os exemplos demonstrados neste artigo poderão ser utilizados com qualquer SGBD). O JavaDB foi escolhido devido a sua inclusão no JDK 6.0 e devido ao seu driver suportar algumas features avançadas que serão demonstradas aqui.

Dados, dados e mais dados...

O primeiro obstáculo seria distribuir um DUMP com 100 mil registros. Gerar dados dinamicamente poderia ser uma solução, porém muito artificial. Para suprir essa deficiência, vamos recorrer ao Wikipedia. Neste artigo, iremos utilizar a base de dados do Wikipedia, que em português possui mais de 500 mil registros, possibilitando assim demonstrar o uso do Hibernate num volume grande de dados.
A Wikimedia Foundation disponibiliza DUMPs completos da base de dados do Wikipedia no seguinte endereço: http://download.wikimedia.org/. Quando comecei a escrever este artigo, o DUMP mais recente era o de 01/02/2007. Recomendo o download do DUMP encontrado neste link:

http://download.wikimedia.org/ptwiki/20070201/ptwiki-20070201-pages-meta-current.xml.bz2

Esta versão não contém os históricos de alteração dos documentos contidos no Wikipedia, apenas a sua versão mais recente. O DUMP do Wikipedia é um XML compactado. Na Listagem 1 temos um Outline do XML utilizado pela Wikimedia.

Leia os artigos completos na revista MUNDOJAVA, já nas bancas!