46 SQL Magazine - Tcnicas de mapeamento objeto relacional

A
DIOGO ALENCAR BERNARDI

Tcnicas de mapeamento objeto relacional

pesar do paradigma orientado a objetos estar sendo cada vez mais difundido no processo de desenvolvimento de software, no existem hoje solues comerciais robustas e amplamente aceitas neste paradigma para a persistncia de dados. Mercado este dominado pelos bancos de dados relacionais. Neste contexto, o mapeamento do modelo orientado a objetos para o relacional uma necessidade cada vez mais importante no processo de desenvolvimento. Embora o uso de frameworks de persistncia seja comum, fundamental o entendimento das tcnicas de mapeamento objeto relacional. Isso facilitar tanto o uso dos frameworks como tambm uma anlise mais criteriosa dos mapeamentos realizados de forma automtica caso seja necessrio algum ajuste no cdigo implementado.

Modelo relacional
A abordagem relacional est baseada no princpio de que as informaes em uma base de dados podem ser consideradas relaes matemticas e que esto representadas de maneira uniforme com o uso de tabelas bidimensionais. Ao se fazer a anlise para o desenvolvimento de uma aplicao, muito importante saber se os tipos de dados a serem armazenados so tipos simples, tais como strings e nmeros. Se este for o caso, mais indicada a utilizao de SGBDs relacionais.
Vantagens

Os SGBDs relacionais possuem uma caracterstica muito importante: so extremamente confiveis e mais eficientes, se comparados maioria dos SGBDs orientados a objetos disponveis no mercado. Alm disso, o modelo de dados relacional foi criado para permitir a representao de uma grande variedade de problemas usando um pequeno conjunto de conceitos simples. Atravs da linguagem de consulta SQL (Structured Query Language) possvel fazer a busca e recuperao dos dados neSQL40.indb 46 09.02.07 00:17:16

Edio 40 - SQL Magazine

47

MODELAGEM
cessrios de forma bastante eficiente. Dentre as vantagens do modelo relacional, talvez a mais importante esteja relacionada com a persistncia dos dados. As regras e rotinas para tratamento da persistncia dos dados podem ser criadas no prprio banco de dados relacional.
Desvantagens

Uma das grandes desvantagens do modelo relacional pode ser observada no momento da realizao da anlise de um sistema a ser implementado: a grande dificuldade em abstrair a realidade, ou seja, traduzir para um modelo de tabelas, com suas relaes entre si, suas chaves primrias e estrangeiras, um problema do mundo real.

Modelo orientado a objetos

O modelo de dados orientado a objetos uma extenso do paradigma orientado a objetos, possuindo basicamente os mesmos conceitos. O paradigma orientado a objetos se baseia na construo de aplicaes a partir de objetos abstrados da realidade, com dados e comportamento associados. Esses objetos possuem atributos (propriedades que contm valores que descrevem o objeto) e mtodos (especificaes de comportamentos dos objetos). Alm disso, o modelo Orientado a Objetos possui outras caractersticas importantes, dentre as quais se pode destacar as mostradas na Tabela 1 J na Tabela 2 podem ser observadas as principais caractersticas de um objeto.
Conceito Descrio Encapsulamento Os valores dos atributos e os detalhes da implementao dos mtodos esto escondidos de outros objetos. Em banco de dados se diz que um objeto est encapsulado quando o estado oculto ao usurio e o objeto pode ser consultado e modificado exclusivamente por meio das operaes a ele associadas. Mensagens Meio de comunicao entre objetos. Troca de mensagens significa chamar um mtodo do objeto. Herana Relacionamento entre classes numa hierarquia. a capacidade de criao de uma nova classe a partir de outra existente. Quando uma classe herda caractersticas de mais de uma classe, diz-se que houve herana mltipla. As principais vantagens de herana so prover uma maior expressividade na modelagem dos dados, facilitar a reusabilidade de objetos e definir classes por refinamento, podendo fatorar especificaes e implementaes como na adaptao de mtodos gerais para casos particulares. Polimorfismo Capacidade de existir diferentes implementaes para mtodos com a mesma assinatura em diferentes classes da mesma hierarquia de herana. Em sistemas polimrficos, uma mesma operao pode se comportar de diferentes formas em classes distintas. Tabela 1. Principais caractersticas do Modelo Orientado a Objetos. Caracterstica Descrio Estado Indica como se encontram as informaes encapsuladas pelo objeto. Comportamento Define o modo que um objeto age e reage em termos das suas mudanas de estado. Identidade a propriedade que distingue um objeto de outro. Cada objeto possui uma identidade nica. Tabela 2. Principais caractersticas de um Objeto.

Vantagens

No modelo Orientado a Objetos, a abstrao da realidade mais simplificada, pois um objeto nada mais do que uma abstrao direta da realidade. Por exemplo: um computador tem teclado, cpu e mouse. O teclado um objeto, a cpu outro objeto e o mouse tambm um objeto. Outra grande vantagem deste modelo a questo da reutilizao. Um objeto pode ser facilmente reutilizado no mesmo programa ou at mesmo em programas diferentes. O modelo orientado a objetos foi projetado para a criao e representao de estruturas complexas de uma maneira coerente e uniforme. Isto representa uma grande vantagem em relao ao modelo de dados relacional, que foi criado sem se preocupar com o armazenamento de estruturas mais complexas. Outro ponto a favor do modelo orientado a objetos a facilidade em expressar relaes complexas entre objetos.
Desvantagens

O paradigma orientado a objetos apresenta um problema: os bancos de dados atuais no oferecem uma boa aderncia aos princpios da orientao a objetos. Isto , em termos de armazenamento, os bancos de dados orientados a objetos no conseguiram ainda substituir a tecnologia comprovadamente eficiente dos bancos de dados relacionais. Em funo disso, os administradores e desenvolvedores de bancos de dados acabam ficando em uma situao difcil, pois mesmo querendo adotar a orientao a objetos, eles tm que parar na hora de manipular seus dados. At mesmo linguagens de programao orientadas a objetos, como Java, acessam os bancos de dados de maneira convencional e utilizando SQL. Com isso, um mesmo programa acaba tendo uma parte orientada a objetos e outra parte estruturada, fazendo com que as caractersticas da orientao a objetos no possam ser exploradas na sua plenitude. Devido a isso, o que est ocorrendo nos dias de hoje que o desenvolvimento orientado a objetos, mas o banco de dados relacional ou objeto-relacional. No modelo orientado a objetos, a implementao acaba se tornando mais complicada do que no modelo relacional, pois as estruturas de dados usadas no banco e as usadas na programao podem ser completamente diferentes. Isso refora a necessidade da criao de uma camada de persistncia, fazendo com que se gaste um bom tempo do desenvolvimento para mapear as estruturas da programao em estruturas do banco de dados.
SQL40.indb 47 09.02.07 00:17:17

48 SQL Magazine - Tcnicas de mapeamento objeto relacional

Bancos de dados orientados a objetos
Os bancos de dados orientados a objetos podem ser divididos em dois grupos: Bancos de Dados Puramente Orientados a Objetos (BDPOO): baseia-se somente no modelo de dados orientado a objetos. Est baseado no conceito de objetos persistentes e usa declaraes de classes muito semelhantes s declaraes das linguagens orientadas a objetos; Bancos de Dados Objeto-Relacionais (BDOR): correspondem a bancos relacionais que possibilitam o armazenamento de objetos. Caractersticas dos BDPOO As principais caractersticas dos Bancos de Dados Puramente Orientados a Objetos so: Permitem a representao de relacionamentos 1-n, n-n

e de herana; A representao de um relacionamento feita incluindose dentro de um objeto os object identifiers dos outros objetos com os quais ele se relaciona; o Object Identifier um identificador interno do banco de dados para cada objeto. Os object identifiers so atribudos e utilizados somente pelo SGBD, nunca pelos usurios. No possuem um padro nico de implementao como os bancos relacionais. Assim, cada produto tem a sua prpria especificao para criao de classes e relacionamentos; Os BDPOO tendem a seguir um padro estabelecido pelo ODMG (Object Database Management Group). A ltima verso disponibilizada pelo ODMG a verso 3.0, que pode ser obtida em no endereo www.odmg.org. Caractersticas dos BDOR Com relao aos Bancos de Dados Objeto-Relacionais, podese dizer que as principais caractersticas so: Um banco objeto-relacional um banco que permite o armazenamento de objetos em suas tabelas; Uma classe representa um domnio, atuando como um data type para uma coluna. A classe, diferentemente dos bancos orientados a objetos, no representa mais um elemento envolvido em relacionamentos; Todas as regras de um banco relacional continuam vlidas; Uma coluna cujo data type seja uma classe, s poder ter uma instncia desta classe. Imagine, por exemplo, uma coluna cujo data type seja uma classe TELEFONE. Nos BDOR, esta coluna no poder ter vrias instncias da classe TELEFONE, mas apenas uma. Se o banco fosse OO, poderia ter mais do que uma. Dentre as principais vantagens dos BDOR, pode-se citar que todo o suporte para ao paradigma orientado a objetos est presente. Alm disso, j existe um padro de implementao estabelecido, determinando uma certa facilidade de convivncia com os sistemas j existentes. Na Tabela 3 podem ser observados alguns dos principais BDOR disponveis no mercado.
Fabricante Descrio IBM Informix e DB2 Oracle Corporation Oracle 9i PostgreSQL Global Development Group PostgreSQL Micro Database System, Inc. TITANIUM Intersystems Cach Tabela 3. Principais BDOR no mercado.

Mapeamento objeto relacional

Em termos conceituais, uma Camada de Persistncia de Objetos uma biblioteca que permite a realizao do processo de persistncia (isto , o armazenamento e manuteno do estado dos objetos em algum meio no-voltil, como um banco de dados) de forma transparente. Dentre as diversas vantagens obtidas com a utilizao da Camada de Persistncia, pode-se destacar o fato do analista/programador poder trabalhar como se estivesse em um sistema completamente orientado a objetos. Outra vantagem muito importante que os acessos realizados diretamente ao banco de dados da aplicao so isolados, e os processos de construo de consultas e operaes de manipulao de dados so centralizados em uma camada de objetos inacessvel ao programador.

Esse encapsulamento torna as aplicaes mais confiveis, permitindo at mesmo que o prprio SGBD ou a estrutura de suas tabelas possam ser alterados sem a necessidade de revisar e recompilar os programas. Apesar disso, o modelo de classes de um projeto orientado a objetos no pode simplesmente ser traduzido em um script SQL de criao de banco de dados, necessrio realizar o mapeamento de objetos em um modelo de dados Entidade-Relacionamento.

Regras para mapeamento

Para garantir que todas as caractersticas do modelo de objetos sejam reproduzidas fielmente pelo banco de dados relacional, alguns aspectos merecem ser destacados. Os objetos formam unidades que encapsulam atributos e operaes. Os bancos de dados relacionais representam de forma bastante eficiente os atributos, mas so limitados na representao das operaes. Pode-se tentar estabelecer uma analogia entre objetos e tabelas, e entre atributos e colunas. Para mapear um objeto em uma tabela relacional, geralmente os atributos desse objeto so representados atravs de colunas na tabela. Entretanto, essa no uma regra que pode ser seguida ao p da letra, pois existem outras consideraes a serem feitas (tipos dos dados, tamanho dos campos, entre outras). Tais consideraes podem fazer com que um atributo seja mapeado em vrias colunas, ou ento que vrios atributos sejam mapeados em apenas uma coluna.
SQL40.indb 48 09.02.07 00:17:17

Edio 40 - SQL Magazine

49

MODELAGEM
Ao se realizar uma transposio de um modelo orientado a objetos para um modelo relacional, algumas regras devem ser seguidas (vale destacar aqui que essas regras no so rgidas): 1. Todas as tabelas (ou relaes) devem ter uma chave primria. Em um sistema orientado a objetos, cada objeto nico. Essa unicidade garantida atravs da introduo de um identificador de objetos (OID Object IDentifier). Esse OID gerado pelo sistema, no podendo ser alterado pelo usurio. Seu valor no depende dos valores dos atributos do objeto. Para fazer essa implementao no modelo relacional, deve ser criado um atributo OID para cada tabela. Na Figura 1 mostrado um exemplo de como seria o mapeamento do objeto Pedido para a tabela Pedido. 2. Mapeamento de atributos. Existem trs tipos de atributos para serem mapeados. Os atributos simples so mapeados para colunas. Os atributos compostos podem ser mapeados em vrias colunas. J os atributos multivalorados devem ser mapeados em tabelas onde a chave primria composta pela chave primria da tabela que representa a classe que contm o atributo multivalorado e pela chave primria que representa o atributo multivalorado. Na Figura 2 pode ser observado um exemplo de mapeamento de um atributo simples (Nome e DtNascimento) e de um atributo composto (Endereco). J na Figura 3 pode ser observado um exemplo de mapeamento de um atributo multivalorado (Telefone). 3. Herana: pode-se mapear este conceito de trs formas. A primeira simplesmente criar uma tabela para cada classe. A segunda forma criar uma nica tabela

para toda a hierarquia de classes. Por ltimo, pode-se criar uma tabela para cada classe concreta.
Figura 1. Exemplo 1. Figura 2. Atributos simples e compostos. Figura 3. Atributos multivalorados. Figura 4. Mapeamento de uma tabela por classe. Figura 5. Uma nica tabela para toda a hierarquia de classes.

Na tcnica de criao de uma tabela para cada classe (Figura 4), os atributos da tabela so os atributos especficos da classe e mais uma coluna de chave estrangeira que referencia a chave primria da tabela pai. As desvantagens do uso dessa tcnica que so geradas muitas tabelas no banco de dados, fazendo com que haja uma demora maior para ler e gravar os dados. Por esse mesmo motivo, algumas consultas acabam sendo bastante dificultadas, obrigando a criao de views para agilizar o processo. Se for utilizada a segunda forma (Figura 5), a classe raiz tomada por base, pois nela que todos os atributos so armazenados. Essa tcnica facilita as consultas, pois os dados de um objeto esto em uma nica tabela O principal problema que, potencialmente, h um desperdcio de espao no banco de dados. Alm disso, a performance pode ser prejudicada. Caso se opte por criar uma tabela para cada classe concreta (Figura 6), deve-se incluir em cada tabela tanto os atributos especficos, quanto os atributos herdados da classe que ela representa. Como os dados de uma classe ficam todos em uma nica tabela, as consultas so facilitadas.
SQL40.indb 49 09.02.07 00:17:18

4. Associaes Muitos-para-Muitos: neste caso devemos criar uma tabela associativa em que a chave primria composta pelas chaves primrias das tabelas associadas famosa e j conhecida entidade ou tabela associativa. Na Figura 7 pode ser visto um exemplo da transposio de uma associao muitospara-muitos. No modelo orientado a objetos havia dois objetos (Aluno e Disciplina), que no modelo relacional passaram a ser representados por trs tabelas (Aluno, Disciplina e Frequenta). 5. Associaes Muitos-para-Muitos com Classe de Associao: neste caso, aplica-se a regra da associao muitos-paramuitos e os atributos da classe associativa permanecero na tabela que gerada para mapear a associao. Na Figura 8 podese observar um exemplo de como feita a transposio de um associao de muitos para muitos. 6. Associaes Um-para-Muitos: neste caso, a tabela cujos registros podem ser endereados diversas (lado Muitos do relacionamento) vezes a que herda a referncia da tabela cuja correspondncia unitria. Na Figura 9 pode-se observar um exemplo onde a tabela Pedido possui uma chave estrangeira (FK) que referencia a tabela Cliente. 7. Associaes Um-para-Muitos com Classe de Associao: neste caso, aplica-se a regra da associao um-para-muitos e os atributos da classe associativa so herdados como atributos normais pela tabela que herda a chave estrangeira (ver Figura 10). 8. Associaes Um-para-Um: nesse tipo de associao, o analista deve optar por gerar uma nica tabela no modelo relacional, ou ento gerar duas tabelas (uma para cada classe).
Figura 6. Uma tabela para cada classe concreta. Figura 10. Associao um-para-muitos com agregao. Figura 9. Associao um-para-muitos. Figura 8. Associao muitos-para-muitos com agregao. Figura 7. Associao muitos-para-muitos.
SQL40.indb 50 09.02.07 00:17:18

Edio 40 - SQL Magazine

51

MODELAGEM
Se for escolhida a primeira opo, os atributos da classe agregada devem ser colocados na mesma tabela da classe agregadora. Nessa tcnica, a performance melhor, pois preciso acessar uma nica tabela. Alm disso, o objeto agregado automaticamente excludo quando o objeto agregador eliminado, no havendo a necessidade da implementao de triggers ou rotinas especiais na aplicao para garantir a consistncia do banco de dados. A grande desvantagem dessa tcnica que a incorporao dos atributos aumenta a quantidade de pginas que so recuperadas em cada acesso tabela. No caso da opo ser pela gerao de duas tabelas, uma delas deve herdar como um atributo normal (chave estrangeira) a chave primria da outra tabela. Essa tcnica facilita a manuteno das tabelas e torna a estrutura do banco de dados mais flexvel. Porm, as consultas necessitam de uma operao de juno (join) ou pelo menos dois acessos ao banco de dados. Se o acesso aos dados de ambas as tabelas no for muito freqente, esta alternativa aceitvel, caso contrrio, essa alternativa pode no ser a mais adequada. Outra desvantagem de gerar uma tabela para cada classe que para manter a consistncia do banco de dados entre essas tabelas, por ocasio de operaes de excluso de objetos, necessrio implementar triggers ou rotinas especiais na aplicao. Na Figura 11 pode ser observado um exemplo da utilizao da tcnica de gerao de uma nica tabela, com a utilizao de um prefixo para distinguir os atributos (PagCh). Os objetos Pedido e Pagto em cheque so transpostos na tabela Pedido. J na Figura 12 demonstrada a utilizao da segunda tcnica (gerao de duas tabelas), onde os objetos Pedido e Pagto em cheque so transpostos nas tabelas Pagamento e PagamentoCheque.

Exemplo de mapeamento
A Figura 13 mostra como seria o mapeamento de um sistema simplificado de controle de uma biblioteca. Atravs deste exemplo, pode-se observar a aplicao de algumas das regras explicadas na seo anterior. importante lembrar que as regras descritas admitem uma certa variao, no sendo totalmente rgidas.

Concluso
Nos casos onde se faz necessrio realizar o mapeamento de um modelo orientado a objetos para um modelo relacional, mais do que qualquer outro fator, o mais importante realizar uma anlise criteriosa, analisando cada caso individualmente. O fundamento dessa anlise deve estar baseado nas regras de mapeamento existentes, porm, como todas as regras, sempre existem excees que precisam ser analisadas com cuidado. As regras de mapeamento j adquiriram certa maturidade, uma vez que vm sendo propostas e aperfeioadas h vrios anos. Alguns autores definem as regras de forma bastante genrica, enquanto outros especificam detalhadamente cada regra, preocupandose com as possveis excees e at mesmo subdividindo algumas regras. Porm, todos so unnimes em afirmar que uma boa anlise individual sobre cada caso, verificando os objetos inFigura 11. Associao um-para-um uma nica tabela. Figura 12. Associao um-para-um uma tabela para cada classe. Figura 13. Mapeamento do modelo de dados de um sistema de controle bibliotecrio simples.

dividualmente e como um todo, muito importante. At mesmo quando so utilizadas ferramentas que fazem o mapeamento de forma automtica, deve-se analisar o modelo obtido para verificar

como ficaram as tabelas, pois pode haver excees que precisam ser tratadas de forma manual.
SQL40.indb 51 09.02.07 00:17:18