Skip to main content
homem usando computador em uma mesa

Mapeamento objeto-relacional — tudo sobre!

Apesar das linguagens de programação modernas possuírem recursos da POO (Programação Orientada a Objetos), a maioria dos SGBD (Sistemas de Gerenciamento de Bases de Dados) é baseada no modelo relacional, onde temos tabelas ao invés de objetos.

Guardar instâncias de objetos em registros de tabelas é o objetivo das técnicas de MOR (Mapeamento Objeto Relacional).

A prática de mapear objetos relacionais tem grande importância no desenvolvimento de projetos. Hoje, eu manterei o foco em apresentar os pontos mais importantes da prática. Vamos lá!

Como funciona o mapeamento objeto-relacional?

programador e computador com códigos

O MOR (Mapeamento Objeto Relacional) nada mais é que o ato de conversão de objetos em memória para dados relacionais, e vice-versa.

Em geral, pressupõe-se que o modelo de dados já existe, e que temos que adaptar nosso sistema orientado a objetos para trabalhar com este esquema pré-existente. O modelo relacional é uma categoria que se destaca entre os SGBD.

Desde sua concepção, o SGBD tem provado ser um mecanismo eficiente e confiável de armazenamento de dados, que possibilita a manipulação, a manutenção da integridade e a segurança dos dados.

Os SGBDRs representam o mecanismo de persistência de maior aceitação e maturidade.

O propósito do MOR é, basicamente, prover uma camada de persistência transparente entre aplicação orientada a objeto e o mecanismo de persistência relacional.

O mecanismo de MOR atua na tradução transparente entre os modelos.

Persistência em SGBDR

homem programando

Por meio de MOR, é possível persistir os objetos em um SGBDR, obtendo-se todas as vantagens trazidas por ele, e evitando-se os problemas que aparecem ao realizar-se a persistência em OO, utilizando um modelo relacional (impedância de modelos).

A persistência de objetos por meio da técnica de MOR permite que se contorne a impedância existente entre as metodologias OO e Relacional, aproveitando assim os benefícios de ambas metodologias.

Persistência transparente refere-se à habilidade de se manipular os dados armazenados em um SGBDR diretamente pela linguagem orientada a objeto, e é o objetivo do MOR.

Isso retoma aos seguintes aspectos desejáveis em um sistema de persistência de objetos:

Persistência Ortogonal

Válida para todos os objetos do sistema, independente de seu tipo.

Persistência Transitiva

Se um objeto é persistente, todos os objetos referenciados por esse objeto devem ser promovidos a objetos persistentes.

A camada de persistência

aglomerado de códigos de programação

A camada de persistência deve intermediar a camada de dados e a camada de aplicação.

Esse tipo de solução tem como foco aplicações que necessitam acessar dados legados, bases heterogêneas, ou gerenciar objetos de negócio distribuídos e persistentes.

Deve apresentar recursos de consulta de dados, suporte a transações, concorrência (locking otimista ou pessimista) e, enfim, possibilitar a persistência transparente, encapsulando o acesso ao banco de dados relacional.

Objetos, além de dados, possuem comportamento. Objetos podem ser multivalorados, englobando objetos complexos ou mesmo outros objetos, e terem atributos provenientes de relacionamentos (herança) com outros objetos.

Estas, entre outras características, trazem uma camada de complexidade a mais no âmbito da persistência.

Os SGBDR são considerados sistemas críticos na maioria das organizações, enquanto os SGBDOO são adotados no desenvolvimento das aplicações de negócio.

Isso reforça a necessidade do uso de metodologias que permitam uma integração efetiva entre as interfaces, que tendem a ser orientadas a objetos, e os dados, armazenados no modelo relacional.

O modelo relacional envolve a existência de tabelas unidimensionais de armazenamento de dados, onde cada linha representa um determinado registro no banco de dados.

É uma abordagem simples e eficiente de persistência, entretanto, retorna-se ao problema inicial da impedância entre o modelo relacional e a POO.

Objetos incluem estruturas de dados como listas e mapas, e utilizam herança e ligações diretas entre os objetos para se relacionarem entre si. Além disso, os objetos são criados e modificados em memória, sendo necessário coordenar o que ocorre na memória com o que ocorre em disco.

De uma forma geral, na persistência de objetos em SGBD, a identidade dos objetos, seus relacionamentos (herança, agregação e associação) e seu estado devem ser preservados nas tabelas relacionais.

Qual problema a camada de persistência resolve?

A criação de uma camada de persistência de objetos permite diminuir o acoplamento entre o banco de dados e a aplicação.

Desta forma, uma mudança em um modelo pode ser traduzida no outro, sem que haja a necessidade de se reestruturar toda a aplicação.

Por meio da camada de MOR, pequenas mudanças no esquema relacional deixam de afetar o código orientado a objeto como um todo e, assim, evita-se a necessidade do desenvolvedor da aplicação de atuar também como um administrador de dados, a partir do momento que o conhecimento do esquema do banco deixa de ser fundamental.

Tipos comuns de MOR

A principal tarefa do MOR envolve a identificação das construções da orientação a objetos que se deseja extrair do esquema relacional, entre elas a identificação das classes e dos relacionamentos.

As principais técnicas de mapeamento de objetos em SGBDR podem ser descritas como:

Mapeamento Classe – Tabela

Mapeamento de uma classe em uma ou mais tabelas, ou de uma tabela para uma ou mais classes, e mapeamento de herança.

Mapeamento Atributo – Coluna

Mapeamento de tipos em atributos.

Mapeamento Relacionamento – Chave estrangeira

Mapeamento dos relacionamentos OO em relacionamentos entre tabelas.

Categorias da estratégia de mapeamento classe-tabela

Mapeamento de Subset

Onde os atributos da classe persistente representam algumas ou todas colunas de uma tabela.

Esta estratégia convém para casos onde todos os atributos de uma classe persistente são mapeados a uma mesma tabela, e onde não há preocupação de incluir as colunas que não fazem parte do modelo de negócios. Pode referir-se também à herança de tabelas simples.

Mapeamento de Superset

Onde os atributos da classe persistente são derivados de colunas de múltiplas tabelas.

Este tipo de mapeamento é usado para criar “classes de visão”, que ocultam o modelo físico de dados, ou para mapear uma árvore de herança de classes utilizando o mapeamento vertical.

Atributos de uma classe

Atributos Primitivos

Atributo de uma classe que é mapeado a uma coluna de uma tabela. Valor de um tipo de dados específico (int, float, double, dentre outros).

Atributos de Referência

Atributos que representam relacionamentos com outras classes. Atributos cujo tipo é uma referência a outro objeto ou conjunto de objetos (composição).

As relações entre objetos são implementadas explicitamente através de atributos de referência, enquanto as relações entre tabelas são realizadas através de associações de chaves estrangeiras.

O mapeamento de associações preocupa-se, basicamente, com algumas categorias de relacionamentos entre objetos.

Uma baseia-se na multiplicidade, outra baseia-se em dois tipos de direcionalidade (Relacionamentos Unidirecionais e Relacionamentos Bidirecionais).

Outra forma de relacionamento entre objetos são os Relacionamentos Recursivos (por exemplo, um time pode ser integrante de outros times).

Um aspecto essencial da POO é a herança. A herança permite que dados e comportamentos de uma superclasse sejam reaproveitados por subclasses. Bancos de dados relacionais não possuem o conceito de herança.

Entidades não podem herdar atributos de outras entidades.

Principais técnicas de representação de hierarquias em esquema relacional

Mapeamento Distribuído de Herança (Horizontal e Vertical)

Forma mais difícil de ser implementada quando coleções heterogêneas de objetos precisam ser recuperadas. Cada subclasse é mapeada em uma tabela separada, e todos os atributos herdados são replicados na tabela.

Mapeamento de Filtro de Herança

Forma mais rápida de mapeamento. Custo de manutenção e espaço. As classes são representadas em uma única tabela. Cada registro da tabela utiliza atributos pertinentes à sua subclasse, enquanto os outros atributos são mantidos nulos.

O que é preciso atentar?

No processo de mapeamento também é importante levar em consideração quais informações adicionais deverão ser mantidas pelo objeto, por exemplo, informação de chave primária, de contadores e números de versionamento.

Outra informação relevante refere-se à existência do objeto no banco de dados, o que resultaria na decisão entre um comando UPDATE da linguagem SQL, ou de um comando INSERT.

Uma técnica para isto seria implementar uma variável booleana a cada classe persistente. Essas informações não precisam ser implementadas nos objetos de negócio, mas devem ser tratadas de alguma forma pela aplicação de MOR.

Como foi visto, há mais de uma forma de efetuar-se o mapeamento entre o modelo de objetos e o modelo de dados relacional.

A estratégia de encapsulamento do acesso ao banco de dados determinará como será implementado o mapeamento.

>> Quiz recomendado:
Quiz do SQL
: o quanto você manja?

Padrões de MOR

Padrões de projeto são modelos conceituais que podem ser aplicados em determinadas áreas de uma aplicação de acordo com a necessidade.

Em geral, as ferramentas de MOR são desenvolvidas para trabalhar com um “Modelo de Domínios” (Domain Model).

Sua base é a criação de um modelo de objetos que incorpora ambos os dados e o comportamento, criando uma rede de objetos interligados.

É similar a um modelo de banco de dados, mas envolve dados e processos, atributos multivalorados e herança. Confira os 4 principais modelos padrão de arquitetura:

Row Data Gateway

É um objeto que age como um gateway para um único registro no banco de dados, ou seja, um objeto que reflete um registro de uma tabela.

Table Data Gateway

Age sobre uma tabela, mantendo todo o código SQL de acesso, encapsulando a lógica de acesso do banco de dados.

Active Record

Combina o gateway e o objeto de domínio em uma única classe, combinando a lógica de negócio e o acesso ao banco de dados.

Data Mapper

O mais flexível e o mais complexo. Age como um mediador entre os objetos em memória e o banco de dados, podendo ignorar completamente o layout de banco de dados.

Sua responsabilidade é transferir dados entre ambos e geralmente é utilizado com um “Modelo de Domínios”. Há também outras duas questões envolvidas no processo de mapeamento:

Diferença de representação

Os objetos são referenciados em tempo real e em memória, enquanto os dados relacionais são referenciados por chaves que estão alocadas em outras tabelas.

Atributos multivalorados

Os objetos lidam com múltiplas referências em único campo, através de coleções, enquanto não há campos multivalorados no modelo relacional.

Uma forma de lidar com o primeiro problema é através da manutenção da identidade relacional de cada objeto com a adição de um campo identificador (armazenamento da chave primária nos atributos do objeto).

Para o segundo caso, geralmente utiliza-se uma técnica chamada de lazy loading, onde o objeto não contém todos os dados: os dados são atribuídos ao objeto apenas quando necessário.

Estruturas de herança de um modelo de objetos para um modelo relacional

Herança de tabela simples

Onde uma tabela representa todas as classes da hierarquia.

Herança horizontal

Onde cada classe não-abstrata é associada à sua respectiva tabela, incluindo os atributos da classe herdada.

Herança vertical

Onde cada classe da hierarquia, inclusive classes abstratas, é associada a uma tabela separada no banco de dados.

Sobre MOR, qual a conclusão?

homem sentado e fazendo anotações

A utilização de técnicas de MOR possibilita às empresas que tem como base SGBDR, direcionarem seus investimentos em inovação e tecnologia, com a utilização de soluções OO, e ao mesmo tempo, manterem a confiabilidade, segurança, e tradição dos bancos de dados relacionais.

Por meio do MOR diminui-se o acoplamento entre o modelo de dados relacional e a aplicação OO, permitindo a portabilidade e a escalabilidade futura das aplicações.

Desenvolvendo projetos desta maneira você estará contribuindo para a reutilização do seu código em diferentes áreas do seu sistema e até mesmo de projetos futuros, sem falar da legibilidade e do aspecto profissional agregado ao seu código.

Até a próxima!



Mapeamento objeto-relacional — tudo sobre!
5 (100%) 5 votes