46 sql magazine

7/22/2019 46 SQL Magazine

1/8

46 SQL Magazine - Tcnicas de mapeamento objeto relacional

ADIOGO ALENCAR BERNARDITcnicas de

mapeamentoobjeto relacionalpesar do paradigma orientado a objetos estarsendo cada vez mais difundido no processode desenvolvimento de software, noexistem hoje solues comerciais robustas eamplamente aceitas neste paradigma para apersistncia de dados. Mercado este dominado pelos bancos dedados relacionais. Neste contexto, o mapeamento do modelo

orientado a objetos para o relacional uma necessidade cadavez mais importante no processo de desenvolvimento.Embora o uso de frameworks de persistncia seja comum, fundamental o entendimento das tcnicas de mapeamento objetorelacional. Isso facilitar tanto o uso dos frameworks comotambm uma anlise mais criteriosa dos mapeamentos realizadosde forma automtica caso seja necessrio algum ajuste nocdigo implementado.

Modelo relacionalA abordagem relacional est baseada no princpio de que asinformaes em uma base de dados podem ser consideradasrelaes matemticas e que esto representadas de maneirauniforme 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 armazenadosso tipos simples, tais como strings e nmeros. Se este for ocaso, mais indicada a utilizao de SGBDs relacionais.VantagensOs SGBDs relacionais possuem uma caracterstica muito importante:so extremamente confiveis e mais eficientes, se comparados maioria dos SGBDs orientados a objetos disponveis nomercado. Alm disso, o modelo de dados relacional foi criado parapermitir a representao de uma grande variedade de problemasusando um pequeno conjunto de conceitos simples.Atravs da linguagem de consulta SQL (Structured QueryLanguage) possvel fazer a busca e recuperao dos dados ne-SQL40.indb 46 09.02.07 00:17:16

Edio 40 - SQL Magazine 47


2/8

MODELAGEMcessrios de forma bastante eficiente.Dentre as vantagens do modelo relacional, talvez a mais importanteesteja relacionada com a persistncia dos dados. Asregras e rotinas para tratamento da persistncia dos dados podemser criadas no prprio banco de dados relacional.

DesvantagensUma das grandes desvantagens do modelo relacional podeser observada no momento da realizao da anlise de um sistemaa ser implementado: a grande dificuldade em abstrair arealidade, ou seja, traduzir para um modelo de tabelas, comsuas relaes entre si, suas chaves primrias e estrangeiras, umproblema do mundo real.

Modelo orientado a objetosO modelo de dados orientado a objetos uma extenso doparadigma orientado a objetos, possuindo basicamente osmesmos conceitos. O paradigma orientado a objetos se baseiana construo de aplicaes a partir de objetos abstrados darealidade, com dados e comportamento associados. Esses objetospossuem atributos (propriedades que contm valores quedescrevem o objeto) e mtodos (especificaes de comportamentosdos objetos).Alm disso, o modelo Orientado a Objetos possui outras caractersticasimportantes, dentre as quais se pode destacar asmostradas na Tabela 1 J na Tabela 2 podem ser observadas asprincipais caractersticas de um objeto.Conceito DescrioEncapsulamentoOs valores dos atributos e os detalhes daimplementao dos mtodos esto escondidosde outros objetos. Em banco de dados se dizque um objeto est encapsulado quando oestado oculto ao usurio e o objeto pode ser

consultado e modificado exclusivamente pormeio das operaes a ele associadas.MensagensMeio de comunicao entre objetos. Troca demensagens significa chamar um mtodo doobjeto.HeranaRelacionamento entre classes numa hierarquia. a capacidade de criao de uma nova classea partir de outra existente. Quando umaclasse herda caractersticas de mais de umaclasse, diz-se que houve herana mltipla. Asprincipais vantagens de herana so proveruma maior expressividade na modelagem dosdados, facilitar a reusabilidade de objetose definir classes por refinamento, podendo

fatorar especificaes e implementaes comona adaptao de mtodos gerais para casosparticulares.PolimorfismoCapacidade de existir diferentes implementaespara mtodos com a mesma assinatura emdiferentes classes da mesma hierarquia deherana. Em sistemas polimrficos, uma mesmaoperao pode se comportar de diferentesformas em classes distintas.Tabela 1. Principais caractersticas do Modelo Orientado a Objetos.Caracterstica DescrioEstado Indica como se encontram as informaesencapsuladas pelo objeto.Comportamento Define o modo que um objeto age e reage emtermos das suas mudanas de estado.

Identidade a propriedade que distingue um objeto deoutro. Cada objeto possui uma identidade nica.Tabela 2. Principais caractersticas de um Objeto.


3/8

VantagensNo modelo Orientado a Objetos, a abstrao da realidade mais simplificada, pois um objeto nada mais do que umaabstrao direta da realidade. Por exemplo: um computadortem teclado, cpu e mouse. O teclado um objeto, a cpu outroobjeto e o mouse tambm um objeto.

Outra grande vantagem deste modelo a questo da reutilizao.Um objeto pode ser facilmente reutilizado no mesmoprograma ou at mesmo em programas diferentes.O modelo orientado a objetos foi projetado para a criaoe representao de estruturas complexas de uma maneira coerentee uniforme. Isto representa uma grande vantagem emrelao ao modelo de dados relacional, que foi criado sem sepreocupar com o armazenamento de estruturas mais complexas.Outro ponto a favor do modelo orientado a objetos afacilidade em expressar relaes complexas entre objetos.DesvantagensO 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 dearmazenamento, os bancos de dados orientados a objetos noconseguiram ainda substituir a tecnologia comprovadamenteeficiente dos bancos de dados relacionais.Em funo disso, os administradores e desenvolvedores debancos de dados acabam ficando em uma situao difcil, poismesmo querendo adotar a orientao a objetos, eles tm queparar na hora de manipular seus dados. At mesmo linguagensde programao orientadas a objetos, como Java, acessam osbancos de dados de maneira convencional e utilizando SQL.Com isso, um mesmo programa acaba tendo uma parte orientadaa objetos e outra parte estruturada, fazendo com que ascaractersticas da orientao a objetos no possam ser exploradas

na sua plenitude.Devido a isso, o que est ocorrendo nos dias de hoje que odesenvolvimento orientado a objetos, mas o banco de dados relacional ou objeto-relacional. No modelo orientado a objetos,a implementao acaba se tornando mais complicada doque no modelo relacional, pois as estruturas de dados usadasno banco e as usadas na programao podem ser completamentediferentes. Isso refora a necessidade da criao de umacamada de persistncia, fazendo com que se gaste um bomtempo do desenvolvimento para mapear as estruturas da programaoem 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 objetosOs bancos de dados orientados a objetos podem ser divididosem dois grupos:Bancos de Dados Puramente Orientados a Objetos (BDPOO):baseia-se somente no modelo de dados orientadoa objetos. Est baseado no conceito de objetos persistentese usa declaraes de classes muito semelhantes sdeclaraes das linguagens orientadas a objetos;Bancos de Dados Objeto-Relacionais (BDOR): correspondema bancos relacionais que possibilitam o armazenamentode objetos.Caractersticas dos BDPOOAs principais caractersticas dos Bancos de Dados Puramente

Orientados a Objetos so:Permitem a representao de relacionamentos 1-n, n-n


4/8

e de herana;A representao de um relacionamento feita incluindo-se dentro de um objeto os object identifiers dosoutros objetos com os quais ele se relaciona;o Object Identifier um identificador internodo banco de dados para cada objeto. Os object

identifiers so atribudos e utilizados somentepelo SGBD, nunca pelos usurios.No possuem um padro nico de implementaocomo os bancos relacionais. Assim, cada produto tema sua prpria especificao para criao de classes erelacionamentos;Os BDPOO tendem a seguir um padro estabelecido peloODMG (Object Database Management Group). A ltima versodisponibilizada pelo ODMG a verso 3.0, que pode serobtida em no endereo www.odmg.org.Caractersticas dos BDORCom relao aos Bancos de Dados Objeto-Relacionais, podesedizer que as principais caractersticas so:

Um banco objeto-relacional um banco que permite oarmazenamento de objetos em suas tabelas;Uma classe representa um domnio, atuando como umdata type para uma coluna. A classe, diferentemente dosbancos orientados a objetos, no representa mais umelemento envolvido em relacionamentos;Todas as regras de um banco relacional continuamvlidas;Uma coluna cujo data type seja uma classe, s poderter uma instncia desta classe. Imagine, por exemplo,uma coluna cujo data type seja uma classe TELEFONE.Nos BDOR, esta coluna no poder ter vrias instnciasda classe TELEFONE, mas apenas uma. Se o banco fosseOO, poderia ter mais do que uma.Dentre as principais vantagens dos BDOR, pode-se citar quetodo o suporte para ao paradigma orientado a objetos est presente.Alm disso, j existe um padro de implementao estabelecido,determinando uma certa facilidade de convivnciacom os sistemas j existentes.Na Tabela 3 podem ser observados alguns dos principaisBDOR disponveis no mercado.Fabricante DescrioIBM Informix e DB2Oracle Corporation Oracle 9iPostgreSQL Global Development Group PostgreSQLMicro Database System, Inc. TITANIUMIntersystems Cach

Tabela 3. Principais BDOR no mercado.Mapeamento objeto relacionalEm termos conceituais, uma Camada de Persistncia de Objetos uma biblioteca que permite a realizao do processo depersistncia (isto , o armazenamento e manuteno do estadodos objetos em algum meio no-voltil, como um banco dedados) de forma transparente.Dentre as diversas vantagens obtidas com a utilizao da Camadade Persistncia, pode-se destacar o fato do analista/programadorpoder trabalhar como se estivesse em um sistemacompletamente orientado a objetos. Outra vantagem muitoimportante que os acessos realizados diretamente ao bancode dados da aplicao so isolados, e os processos de construode consultas e operaes de manipulao de dados so centralizadosem uma camada de objetos inacessvel ao programador.


5/8

Esse encapsulamento torna as aplicaes mais confiveis,permitindo at mesmo que o prprio SGBD ou a estrutura desuas tabelas possam ser alterados sem a necessidade de revisare recompilar os programas.Apesar disso, o modelo de classes de um projeto orientadoa objetos no pode simplesmente ser traduzido em um

script SQL de criao de banco de dados, necessrio realizaro mapeamento de objetos em um modelo de dadosEntidade-Relacionamento.

Regras para mapeamentoPara garantir que todas as caractersticas do modelo de objetossejam reproduzidas fielmente pelo banco de dados relacional,alguns aspectos merecem ser destacados. Os objetosformam unidades que encapsulam atributos e operaes. Osbancos de dados relacionais representam de forma bastanteeficiente os atributos, mas so limitados na representao dasoperaes. Pode-se tentar estabelecer uma analogia entre objetose tabelas, e entre atributos e colunas.Para mapear um objeto em uma tabela relacional, geralmente

os atributos desse objeto so representados atravs decolunas na tabela. Entretanto, essa no uma regra que podeser seguida ao p da letra, pois existem outras consideraesa serem feitas (tipos dos dados, tamanho dos campos, entreoutras). Tais consideraes podem fazer com que um atributoseja mapeado em vrias colunas, ou ento que vrios atributossejam mapeados em apenas uma coluna.SQL40.indb 48 09.02.07 00:17:17

Edio 40 - SQL Magazine 49MODELAGEMAo se realizar uma transposio de um modelo orientado aobjetos 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 identificadorde objetos (OID Object IDentifier). Esse OID geradopelo sistema, no podendo ser alterado pelo usurio. Seuvalor no depende dos valores dos atributos do objeto.Para fazer essa implementao no modelo relacional, deveser criado um atributo OID para cada tabela. Na Figura 1 mostrado um exemplo de como seria o mapeamento do objetoPedido para a tabela Pedido.2. Mapeamento de atributos. Existem trs tipos de atributospara serem mapeados. Os atributos simples so mapeados

para colunas. Os atributos compostos podem ser mapeadosem vrias colunas. J os atributos multivalorados devem sermapeados em tabelas onde a chave primria composta pela chave primria da tabelaque representa a classe que contm o atributomultivalorado e pela chave primria que representao atributo multivalorado. Na Figura2 pode ser observado um exemplo de mapeamentode um atributo simples (Nome e Dt-Nascimento) e de um atributo composto (Endereco).J na Figura 3 pode ser observadoum exemplo de mapeamento de um atributomultivalorado (Telefone).

3. Herana: pode-se mapear este conceitode trs formas. A primeira simplesmente criar uma tabelapara cada classe. A segunda forma criar uma nica tabela


6/8

para toda a hierarquia de classes. Por ltimo, pode-se criaruma 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 (Figura4), os atributos da tabela so os atributos especficos da classee mais uma coluna de chave estrangeira que referencia a chaveprimria da tabela pai. As desvantagens do uso dessa tcnica que so geradas muitas tabelas no banco de dados, fazendocom que haja uma demora maior para ler e gravar os dados. Poresse 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 umobjeto 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 atributosespecficos, quanto os atributos herdados da classe que ela representa.Como os dados de uma classe ficam todos em umanica tabela, as consultas so facilitadas.SQL40.indb 49 09.02.07 00:17:18

4. Associaes Muitos-para-Muitos: neste caso devemoscriar uma tabela associativa em que a chave primria compostapelas chaves primrias das tabelas associadas famosa ej conhecida entidade ou tabela associativa. Na Figura 7 podeser visto um exemplo da transposio de uma associao muitos-para-muitos. No modelo orientado a objetos havia doisobjetos (Aluno e Disciplina), que no modelo relacional passarama ser representados por trs tabelas (Aluno, Disciplinae Frequenta).5. Associaes Muitos-para-Muitos com Classe de Associao:neste caso, aplica-se a regra da associao muitos-paramuitose os atributos da classe associativa permanecero na tabelaque gerada para mapear a associao. Na Figura 8 podeseobservar um exemplo de como feita a transposio de umassociao de muitos para muitos.6. Associaes Um-para-Muitos: neste caso, a tabela cujosregistros podem ser endereados diversas (lado Muitos do relacionamento)vezes a que herda a referncia da tabela cujacorrespondncia 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 osatributos da classe associativa so herdados como atributos normaispela tabela que herda a chave estrangeira (verFigura 10).8. Associaes Um-para-Um: nesse tipo de associao, oanalista 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


7/8

MODELAGEMSe for escolhida a primeira opo, os atributos da classeagregada devem ser colocados na mesma tabela da classe agregadora.Nessa tcnica, a performance melhor, pois precisoacessar uma nica tabela. Alm disso, o objeto agregado automaticamenteexcludo quando o objeto agregador eliminado,

no havendo a necessidade da implementao de triggersou rotinas especiais na aplicao para garantir a consistnciado banco de dados. A grande desvantagem dessa tcnica quea incorporao dos atributos aumenta a quantidade de pginasque so recuperadas em cada acesso tabela.No caso da opo ser pela gerao de duas tabelas, uma delasdeve herdar como um atributo normal (chave estrangeira) achave primria da outra tabela. Essa tcnica facilita a manutenodas tabelas e torna a estrutura do banco de dados maisflexvel. Porm, as consultas necessitam de uma operao dejuno (join) ou pelo menos dois acessos ao banco de dados. Seo 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 geraruma tabela para cada classe que para manter a consistnciado banco de dados entre essas tabelas, por ocasio de operaesde excluso de objetos, necessrio implementar triggersou rotinas especiais na aplicao.Na Figura 11 pode ser observado um exemplo da utilizaoda tcnica de gerao de uma nica tabela, com a utilizao deum prefixo para distinguir os atributos (PagCh). Os objetos Pedidoe Pagto em cheque so transpostos na tabela Pedido. J naFigura 12 demonstrada a utilizao da segunda tcnica (geraode duas tabelas), onde os objetos Pedido e Pagto em chequeso transpostos nas tabelas Pagamento e PagamentoCheque.

Exemplo de mapeamentoA Figura 13 mostra como seria o mapeamento de um sistemasimplificado de controle de uma biblioteca. Atravs desteexemplo, pode-se observar a aplicao de algumas das regrasexplicadas na seo anterior. importante lembrar que as regrasdescritas admitem uma certa variao, no sendo totalmentergidas.

ConclusoNos casos onde se faz necessrio realizar o mapeamento deum modelo orientado a objetos para um modelo relacional,mais do que qualquer outro fator, o mais importante realizaruma anlise criteriosa, analisando cada caso individualmente.O fundamento dessa anlise deve estar baseado nas regras de

mapeamento existentes, porm, como todas as regras, sempreexistem excees que precisam ser analisadas com cuidado.As regras de mapeamento j adquiriram certa maturidade, umavez que vm sendo propostas e aperfeioadas h vrios anos. Algunsautores definem as regras de forma bastante genrica, enquantooutros especificam detalhadamente cada regra, preocupando-se com as possveis excees e at mesmo subdividindoalgumas regras. Porm, todos so unnimes em afirmar que umaboa anlise individual sobre cada caso, verificando os objetos in-Figura 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 decontrole bibliotecrio simples.

dividualmente e como um todo, muito importante. At mesmo

quando so utilizadas ferramentas que fazem o mapeamento deforma automtica, deve-se analisar o modelo obtido para verificar


8/8

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

46 sql magazine

Documents