MAPEAMENTO OBJETO RELACIONAL

2.6 MAPEAMENTO OBJETO RELACIONAL

O termo Mapeamento Objeto Relacional refere-se a técnica de mapear os registro do Banco de Dados em objetos e persistir as informações contidas nos objeto em forma de linhas e colunas.

Como o próprio nome diz, Mapeamento Objeto / Relacional,é responsável por mapear classes e atributos do modelo orientado a objeto para tabelas e colunas do banco de dados.

Existem várias formas de fazer esse mapeamento. Alguns frameworks utilizam a linguagem XML, outros nos obrigam a implementar alguma Interface ou trabalhar com os atributos do .NET, mas o objetivo é sempre o mesmo: Permitir que o framework consiga gerar os comandos SQL dinamicamente. Uma outra característica deste modelo é a independência do banco de dados.

Devido a geração de comandos dinâmicos, o framework pode analisar qual banco de dados a aplicação está acessando e gerar os comandos no dialeto específico do banco de dados, ou seja, é possível mudar o banco de dados da aplicação apenas alterando um arquivo de configuração.

Mapeando objetos para tabelas:

Para permitir a correta persistência de objetos em um banco de dados relacional, algum acordo deve ser feito no tocante à forma como os dados serão armazenados. Existem diversas técnicas que permitem o mapeamento de conjuntos de objetos, cada qual com suas vantagens e desvantagens sobre as demais. Em geral, uma Camada de Persistência implementa uma destas técnicas, de forma que o desenvolvedor de software, ao escolher o mecanismo de persistência com o qual trabalhará, sabe como deve organizar as tabelas em seu banco de dados para suportar o esquema de objetos desejado. No decorrer deste artigo, detalhamos como é feito o mapeamento de cada um dos elementos de um objeto: seus atributos, relacionamentos e classes descendentes (herança). 22

Mapeando atributos

Ao transpor-se um objeto para uma tabela relacional, os atributos do mesmo são mapeados em colunas da tabela. Este processo de mapeamento deve levar em consideração fatores como a tipagem dos dados (alguns SGBDs podem não suportar tipos binários longos, por exemplo) e o comprimento máximo dos campos (no caso de números e strings).

Também é importante lembrar que, em diversos casos, atributos de um objeto não devem ter obrigatoriamente uma coluna em uma tabela que os referencie. Como exemplo, podemos citar o valor total de um pedido: este dado poderia ser armazenado no objeto para fins de consulta, mas mantê-lo no banco de dados talvez não seja uma idéia tão interessante, por tratar-se de um valor que pode ser obtido através de consultas. Além disso, existem casos onde um atributo pode ser mapeado para diversas colunas (exemplos incluem endereços completos, nome dividido em 'primeiro nome' e 'sobrenome' no banco de dados) ou vários atributos podem ser mapeados para uma mesma coluna (prefixo e número de telefone, por exemplo). As implementações de Camadas de persistência provêem, em alguns casos, suporte a este tipo de situação.

Mapeamento de classes em tabelas

O mapeamento de estruturas de classes em tabelas de uma base de dados relacional nem sempre é um processo simples: enquanto alguns acham interessante a adoção de "tabelões" (isto é, tabelas não-normalizadas agrupando dados de diversas entidades) como repositório para os dados, outros preferem ater-se às regras propostas pelas teorias de normalização de bancos de dados relacionais. As três técnicas de mapeamento de objetos mais comumente implementadas (inclusive em Camadas de Persistência) são detalhadas a seguir. É comum a adoção de uma destas técnicas, mesmo quando nenhum tipo de mecanismo de persistência automático é adotado no desenvolvimento.

Mapeamento de uma tabela por hierarquia

Segundo esta estratégia, toda a hierarquia de classes deve ser representada por uma mesma tabela no banco de dados: uma coluna que identifique o tipo do objeto serve para identificar a classe do objeto representado por cada linha na tabela, quando nenhum outro modo de identificação é viável. As desvantagens desta estratégia são evidentes: a ausência de normalização dos dados fere as regras comuns da teoria de modelagem de dados – além disso, para hierarquias de classes com muitas especializações, a proliferação de campos com valores nulos na maioria das linhas da tabela se torna também um problema potencial.

Mapeamento de uma tabela por classe concreta

Nesta estratégia, teremos uma tabela no banco de dados para cada classe concreta presente em nosso sistema. A tabela identifica a classe de todos os elementos contidos na mesma, tornando desnecessário o mecanismo de Object Type adotado na estratégia anterior. A estratégia de geração de uma tabela para cada classe concreta leva à redundância de dados: quaisquer atributos definidos em uma superclasse abstrata na hierarquia devem ser criados em todas as tabelas que representam subclasses da mesma.

Além disso, mudar o tipo (especializar ou generalizar) um objeto torna-se um problema, já que é necessário transferir todos os seus dados de uma tabela para outra no ato da atualização.

Mapeamento de uma tabela por classe

Na terceira estratégia proposta, criamos uma tabela para cada classe da hierarquia,

relacionadas através do mecanismo de especialização padrão do banco de dados (utilização de chaves estrangeiras). Segundo esta modalidade de mapeamento, tenta-se ao máximo manter a normalização de dados, de forma que a estrutura final das tabelas fica bastante parecida com a hierarquia das classes representada pela UML. A colocação de um identificador de tipo (Object Type) na classe-pai da hierarquia permite identificar o tipo de um objeto armazenado nas tabelas do sistema sem forçar junções entre as tabelas, garantindo melhorias na performance, e é uma estratégia comumente utilizada. Esta é a técnica que mais naturalmente mapeia objetos para bancos de dados relacionais, de forma 24que as Camadas de Persistência geralmente forçam a utilização de um esquema de dados que siga esta modalidade de mapeamento. A quantidade de junções (joins) entre tabelas para obter todos os dados de um objeto o seu principal ponto negativo.

A tabela 1 faz um comparativo destas três técnicas quanto à facilidade de consulta a dados interativa (ad-hoc reporting), facilidade implementação, facilidade de acesso aos dados, acoplamento dos dados das classes mapeadas, velocidade de acesso e suporte a