Padrões de Projeto em Modelagem Orientada a Objetos Persistida em Banco de Dados Relacional

Transcrição

1 FACULDADE FARIAS BRITO CIÊNCIA DA COMPUTAÇÃO Thiago Vicente Benega Padrões de Projeto em Modelagem Orientada a Objetos Persistida em Banco de Dados Relacional Fortaleza 2010

2 Thiago Vicente Benega Padrões de Projeto em Modelagem Orientada a Objetos Persistida em Banco de Dados Relacional Monografia apresentada para obtenção dos créditos da disciplina Trabalho de Conclusão do Curso da Faculdade Farias Brito, como parte das exigências para graduação no Curso de Ciência da Computação. Orientador: MSc. Ricardo Wagner C. Brito Fortaleza 2010

3 PADRÕES DE PROJETO EM MODELAGEM ORIENTADA A OBJETOS PERSISTIDA EM BANCO DE DADOS RELACIONAL Thiago Vicente Benega PARECER NOTA: FINAL (0 10): Data: / / BANCA EXAMINADORA: Nome e titulação (Orientador) Nome e titulação (Examinador) Nome e titulação (Examinador)

4 RESUMO O uso do paradigma Orientado a Objetos se tornou o mais utilizado na área de desenvolvimento de sistemas devido a sua maior aproximação com os elementos do mundo real e sua facilidade de reutilização de código. No entanto, o mecanismo de armazenamento e recuperação de dados mais comumente utilizado - o Banco de Dados Relacional - não foi projetado para interagir diretamente com o paradigma OO e com suas particularidades. Desenvolver aplicações comerciais utilizando estes dois modelos com características tão diferentes é um problema conhecido na computação e novas soluções para este problema continuam sendo pesquisadas e desenvolvidas. Este trabalho se propõe a identificar um conjunto de problemas conhecidos na utilização destes dois modelos no desenvolvimento de software e propor soluções que venham a minimizar tais problemas.

5 SUMÁRIO INTRODUÇÃO Conceitos Básicos Persistências de Dados Modelo Orientado a Objeto OO X RELACIONAL Padrões de projeto Ferramentas ORM Hibernate Ibatis CocoBase Problemas Encontrados Carga de Dados Cargas Duplicadas Carga Desnecessária de Dados Tráfego de Carga Com Dados Redundantes Consultas Polimórficas Ou Hierárquicas Mapeamento Tabelas Com Colunas de Nomes Iguais Campos de Retorno Dinâmicos Acoplamento Com o Banco de Dados Descarga de Dados Descarregar Apenas o Necessário Descarregar Apenas Quando Necessário REPOO (Repositório Orientado a Objetos) Classes...38

6 3.2 Arquivos Funcionamento Consulta e Preenchimento Persistência Exclusão Soluções Propostas Cargas Cargas Duplicadas Carga Desnecessária de Dados Tráfego de Cargas Redundantes Consultas Polimórficas Ou Hierárquicas Mapeamento Tabelas com Colunas de Nomes Iguais Campos de retorno dinâmicos Acoplamento com o Banco de Dados Descarga de Dados Descarregar Apenas o Necessário Descarregar Apenas Quando Necessário Conclusão Análise comparativa Contribuições Trabalhos Futuros Referências Bibliográficas Material de Leitura...61

7 LISTA DE FIGURAS Figura 1. Duas hierarquias de objetos distintas...18 Figura 2. Mapeamento em uma única tabela...18 Figura 3. Mapeamento em classes concretas...19 Figura 4. Mapeamento para cada classe...19 Figura 5. Mapeamento para cada classe...20 Figura 6. Modelo de dados Aluno e Disciplinas...27 Figura 7. Camada REPOO...36 Figura 8. Propriedades, Campos e Colunas...38 Figura 9. Modelo Aluno alterado...52

8 LISTA DE TABELAS Tabela 1: Um select retornando os dados de um aluno...26

9 INTRODUÇÃO Persistência de dados consiste em manter certas informações em um estado não-volátil de forma que, ao desligar o computador, tais dados não sejam descartados. As primeiras versões do conceito de persistência de dados eram simples, baseadas em arquivos binários. A aplicação se encarregava de manter sua integridade e concorrência. Com o surgimento dos Sistemas Gerenciadores de Banco de Dados (SGBDs), o gerenciamento da persistência de dados foi desacoplado da aplicação e centralizado no SGBD. Dentre os vários tipos de modelos de dados utilizados ao longo dos últimos anos, o Modelo Relacional se consolidou como o mais popular, sendo amplamente utilizado na quase totalidade dos principais SGBDs atualmente disponíveis no mercado. O Modelo Relacional possui como elementos básicos as tabelas, as quais, por sua vez, são compostas de linhas (ou tuplas) e colunas (ou atributos). Em cada linha são armazenados valores relacionados a um determinado elemento (um aluno, uma disciplina ou um produto, por exemplo). As colunas agrupam valores homogêneos referentes a um determinado atributo dos elementos (nome, código, preço, etc). O desenvolvimento de sistemas também sofreu diversas alterações durante a história. Os primeiros paradigmas e linguagens definiam a forma de desenvolvimento de modo procedimental. O pensamento era similar ao de como o hardware funciona, de forma linear, e tinha uma aceitação razoável com o modelo de persistência relacional. Porém, esse modelo de desenvolvimento era de difícil manutenção e legibilidade. Em sequência a esse paradigma de desenvolvimento, surgiu o paradigma da Programação Orientada a Objetos (POO). Neste paradigma, propõe-se um distanciamento do hardware e uma aproximação do mundo real. Tudo é objeto, assim como no nosso mundo, e estes interagem através do envio de mensagens, tendo cada objeto suas próprias características, comportamento e

10 responsabilidades. Esse modelo de analisar e desenvolver sistemas facilitou muito a vida dos desenvolvedores. Por sua vez, o modelo de persistência também vem sofrendo alterações, com o surgimento de outros paradigmas como é o caso dos SGBDs Orientados a Objetos (SGBDOO). Este modelo de banco de dados foi desenvolvido com o objetivo de tentar atender as características do paradigma OO que não são tratadas pelo modelo relacional. No entanto, diversos problemas foram encontrados ao se tentar substituir o modelo relacional por essa nova abordagem. Tais problemas serão analisados mais adiante neste trabalho. Atualmente, a solução mais amplamente utilizada é o paradigma OO de desenvolvimento persistindo em um paradigma relacional de armazenamento de dados. O problema dessa solução é que ela apresenta dois paradigmas diferentes com a dificuldade em compatibilizá-los. Na busca por soluções, surgem várias possibilidades e, com elas, um conjunto de ideias, tais como frameworks e bibliotecas que possuem vantagens e desvantagens. Algumas optam por desempenho e outras por flexibilidade. Este trabalho se propõe a apresentar um conjunto de soluções e práticas para o processo de intermediação entre os dois paradigmas citados, utilizando Padrões de Projetos e com base nas análises das ferramentas mais populares existentes no mercado (Hibernate, CocoBase, Ibatis, entre outras). Esse conjunto de soluções pretende atender a alguns casos específicos, que serão catalogados de acordo com análises realizadas. Para isso, tais ferramentas serão analisadas com base em certos critérios pré-definidos, os quais serão identificados mais adiante. A análise e o desenvolvimento das soluções terão como ênfase os aspectos de produtividade, simplicidade, e flexibilidade, permitindo o uso das soluções visando automatizar parte do esforço de desenvolvimento de uma forma simples, e possibilitando também o não acoplamento da aplicação com o banco de dados. Apesar da solução esperada - fornecer saídas para as duas etapas do processo de persistência de dados, carga ou consulta e armazenamento - o enfoque maior estará na etapa de consulta pela sua maior complexidade e importância. As consultas escritas em linguagem SQL 10

11 podem ser tão complexas quanto à necessidade do usuário e a maior incompatibilidade entre o modelo OO e o modelo relacional está na forma como essa consulta é retornada. 11

12 1 Conceitos Básicos Neste capítulo serão abordados alguns conceitos que envolvem a persistência de dados no ambiente de desenvolvimento de software, seguida pela explicação das dificuldades e das soluções atualmente utilizadas. 1.1 Persistências de Dados Memória em arquitetura de computadores é o módulo existente para o armazenamento dos dados. Sem este recurso, não seria possível executar nenhum programa com as arquiteturas atualmente utilizadas. Existem dois tipos de memórias no que se refere à persistência de dados: as voláteis, nas quais, ao se desligar o computador, todos os dados são perdidos e as nãovoláteis que mantêm seus dados após o reinício do computador ou do sistema (STALLING, 2002). Os sistemas desenvolvidos devem, de alguma maneira, gerenciar a persistência dos dados. A primeira forma de gerência utilizava simples arquivos binários e todo o controle ficava por conta do próprio sistema. Diversos programas são criados para controlar a armazenagem e a extração dos dados e, conforme novas regras e módulos são adicionados ao sistema, novos programas de controles precisam ser criados. Existia um forte acoplamento entre a aplicação e o gerenciamento de persistência. Era essa a realidade dos sistemas antes do advento dos Sistemas Gerenciadores de Banco de Dados (SGBDs). (SILBERSCHATZ, KORTH, SUDARSHAN, 2006). Com o surgimento dos SGBDs, o esforço computacional para se manter os dados é retirado da aplicação e todo o controle de persistência e regras é centralizado no SGBD. Em 12

13 Date (2004, p.16-18), são encontradas outras vantagens em se ter um sistema centralizado para gerenciamento de dados, tais como: - Os dados podem ser compartilhados. O acesso aos dados está desacoplado da aplicação. - A redundância pode ser minimizada. Em cenários sem a utilização de sistemas de banco de dados, cada aplicação possui seus próprios arquivos, não importando se já existem os arquivos desejados em outro local. - A inconsistência pode ser evitada (até certo ponto). O SGBD possui regras para manter a consistência dos dados, porém as relações e regras entre as tabelas devem ser devidamente estabelecidas, caso contrário, o SGBD não tem como garantir a consistência. - Suporte a transações. Transação em SGBD é uma unidade lógica de trabalho que garante a atomicidade das operações. Caso alguma interferência ocorra no meio de uma operação, o SGBD volta ao estado que estava ao iniciar a transação. - Integridade pode ser mantida. Assegura que os dados no banco estão corretos. Por estar centralizado, a manutenção da integridade se torna mais importante e mais fácil de ser mantida do que em um cenário sem a utilização dos sistemas gerenciadores de banco de dados. - Segurança. Existe o conceito de usuários dentro do SGBD, cada usuário possui níveis de restrições. Assim, usuários que necessitem apenas de consultas podem ter restrições quanto a efetuar alterações. - Requisitos contraditórios podem ser equilibrados. O SGBD pode ser configurado de forma a atender os requisitos que forem necessários para a empresa, atendendo a necessidades conflitantes. - Os padrões podem ser impostos. Como os dados estão centralizados, o acompanhamento dos padrões impostos pela empresa se torna possível. 13

14 Os primeiros SGBDs a serem utilizados em aplicações comerciais seguiam o modelo relacional e atendiam os critérios citados anteriormente (SILBERSCHATZ, KORTH, SUDARSHAN, 2006). Originalmente, os bancos de dados relacionais foram projetados para separar o armazenamento físico dos dados da sua representação conceitual. Os SGBDs introduziram uma linguagem de consulta de alto nível (SQL), facilitando e otimizando o acesso aos dados. Pela questão de desempenho, de facilidade e prática manutenção, o uso de banco de dados relacionais tornou-se comum na maioria dos computadores e sistemas até hoje (ELMASRI, NAVATHE, 2006). O banco de dados relacional armazena seus dados através de uma coleção de tabelas que se relacionam entre si. Cada tabela contém um nome e um conjunto de linhas não ordenadas, cada linha contém uma série de colunas, e cada coluna possui um nome, um tipo e um valor. A identidade de uma linha é garantida pelo conceito de chave primária, e o relacionamento entre as tabelas é possível pelo conceito de chave estrangeira. Chave primária e chave estrangeira seguem o conceito de chave, que é um conjunto de uma ou mais colunas que garantem identificação de uma linha perante as outras. A chave primária é usada como a primeira chave a identificar a linha, outras chaves podem ser criadas para garantir unicidade, estas levam o nome de chaves alternativas. Já a chave estrangeira permite a criação de relacionamentos entre as tabelas. (HEUSER, 2004). 1.2 Modelo Orientado a Objeto Em paralelo ao progresso de gerenciamento de dados, o desenvolvimento das aplicações também passou por grandes mudanças. Um dos primeiros paradigmas de desenvolvimento a se popularizar foi o procedimental ou estruturado. A maneira como se codificava era linear, muito próximo ao hardware e utilizava conceitos matemáticos para definir soluções. Um algoritmo é uma sequência ordenada e finita de etapas, cuja execução passo a passo resolve um determinado problema. (VILARIM, 2004, p.7). 14

15 O desenvolvimento de aplicações baseadas neste paradigma era de uma complexidade muito alta levando a descontinuação de vários projetos de software. Para tentar reverter essa realidade, foi criada uma nova abordagem de desenvolvimento, o Paradigma Orientado a Objetos. Este, por sua vez, permitia a criação de um código de melhor legibilidade, rotinas podiam ser mais facilmente reutilizadas e processos complexos podiam ser escritos de forma mais compreensível e de melhor manutenção. Segundo Deitel (2006), orientação a objetos é um paradigma que aproxima o programador do mundo real, no qual tudo pode ser visto como objetos, como por exemplo, livro, aluno, faculdade, etc. Antes da OO, o desenvolvimento se preocupava com as ações desses objetos, a programação se baseava nos verbos: alugarlivro, cadastraraluno, realizarmatricula, etc. O programador recebia os problemas em objetos e codificava em verbos. Com o advento da OO, o programador passou a codificar exatamente o que via. A modelagem passou a se basear nos substantivos, como, por exemplo, o livro, o aluno, etc.. Os objetos dentro da computação são unidades que encapsulam seu significado próprio, possuem estados e comportamento que podem ser reutilizáveis. Os objetos, assim como no mundo real, possuem relações e deveres com outros objetos. Ao desenvolver um sistema OO, não se analisa o problema linearmente. Primeiro se observa quais objetos estão interagindo entre si e qual a responsabilidade de cada um dentro do contexto do problema. Essa nova forma de raciocinar tornou sistemas grandes e complexos possíveis de serem realizados (DEITEL, 2006). Para a realização de um código mais legível e reutilizável, a POO emprega alguns conceitos em seu paradigma de desenvolvimento como: agregação, herança, polimorfismo, associações, entre outros (DEITEL, 2006): - Agregação: Estrutura todo-parte, conceito onde um objeto contém outros objetos dentro de si. Existem dois tipos: agregação e agregação por composição, ou apenas composição. A agregação consiste no relacionamento entre dois objetos, onde um pode viver sem a existência do outro, diferentemente de composição, um relacionamento forte onde um objeto necessita da existência do outro. Apesar dos dois conceitos serem diferentes 15

16 semanticamente, este trabalho não distinguirá os dois, visto que, quando se trabalha com persistência de dados, os dois conceitos não se diferenciam (MEDEIROS, 2006). - Herança: A herança é uma forma de reutilização de software em que o programador cria uma classe que absorve dados e comportamentos de uma classe existente e os aprimora com novas capacidades (DEITEL, 2006, p.502). Elementos mais específicos são completamente consistentes com o mais geral, podem acessar seus atributos e métodos e implementar novos (Medeiros, 2006). Com o recurso de herança podemos modelar uma hierarquia de classes. - Polimorfismo: O polimorfismo permite programar no geral em vez de programar no especifico. Em particular, o polimorfismo permite escrever programas que processam objetos de classes que fazem parte da mesma hierarquia de classes como se todos fossem objetos da classe básica da hierarquia. (DEITEL, 2006, p.546). Com o polimorfismo pode-se trabalhar com qualquer representação do objeto. Por exemplo, aluno e professor são objetos diferentes, porém ambos são pessoas, assim é possível trabalhar com os dois tipos diferentes utilizando o tipo pessoa. Claro que com as limitações de pessoa. 1.3 OO X RELACIONAL O modelo relacional de persistência de dados não atende muito bem ao paradigma OO. Os SGBDs não implementam nativamente o conceito de herança utilizado pelos objetos. Em casos simples, os dois paradigmas se mostram menos conflitantes. Porém, objetos podem ser tão complexos quanto necessário. Hierarquias extensas, muitas regras e relacionamentos tornam difícil a representação em um modelo simples de tabelas e relacionamentos (BAUER, KING, 2005). 16

17 Segundo Pinheiro (2005), os Bancos de Dados Orientados a Objetos não foram bem aceitos pela maioria dos sistemas comerciais devido à predominância do banco de dados relacional no mercado, com certa maturidade, estabilidade, com vários fornecedores e suporte, o que tornou difícil a sua substituição. Além disso, o tempo de respostas nas consultas do SGBDOO ainda são maiores do que o dos SGBDs relacionais. A migração das bases de dados existentes de um banco relacional para um orientado a objetos possui um alto custo, visto que se torna necessário analisar tabela por tabela e respectivos relacionamentos, muitas vezes complexos, e transpor para um novo banco com um novo paradigma. É necessário testar a aplicação inteira para garantir a funcionalidade e aceitação do sistema para com o novo banco. Com os SGBDs relacionais dominando o mercado, restavam duas alternativas: desenvolver as tabelas e relações de um modo a representar de forma mais adequada os objetos e seus conceitos, ou criar uma camada dentro da aplicação que mapeie os objetos com as tabelas sem alterar a base de dados existente. A primeira alternativa é mais organizada, as tabelas tentam representar da melhor forma o objeto e seus conceitos: hierarquia e polimorfismo, agregação, associações entre classes (KELLER, 1997). A segunda alternativa é, muitas vezes, mais interessante pela não necessidade de alterações no banco de dados. Em projetos que se iniciam do zero, as duas técnicas podem ser utilizadas juntas, as tabelas criadas de forma mais adequada ao POO e uma camada que faça o mapeamento dos dois paradigmas. A modelagem das tabelas para representar OO tem de mapear os conceitos de OO citados acima. Existem alguns padrões para tratar cada conceito (KELLER, 1997): Hierarquia e polimorfismo. Existem alguns padrões utilizados atualmente para representação da hierarquia de objetos dentro das tabelas, tratando também o polimorfismo. Esses padrões e seus respectivos exemplos podem ser visualizados na Figura 1 (AMBLER, on-line). - Tabela única para toda estrutura hierárquica: todos os atributos de todas as classes da estrutura hierárquica são mapeados em uma única tabela. Cada linha representa um objeto de uma subclasse especifica. Uma coluna extra é criada na tabela para controlar a distinção entre 17

18 as classes. A Figura 1 representa um exemplo com duas hierarquias distintas, a Figura 2 ilustra como é a representação das duas hierarquias utilizando essa técnica. Figura 1. Duas hierarquias de objetos distintas Figura 2. Mapeamento em uma única tabela Todos os atributos das classes Pessoa, Cliente, Empregado e Executivo (no caso, à direita), conforme a Figura 2, estão em uma única tabela onde existe um atributo (PessoaTipo) que identifica o tipo do objeto, se é um Cliente ou um Empregado. - Uma tabela para cada classe concreta: Para cada classe concreta existente na aplicação, existe uma tabela correspondente no banco de dados. A tabela contém colunas representando todos os atributos da classe inclusive os herdados pelas superclasses. A Figura 3 ilustra como fica o mapeamento utilizando essa técnica com base na Figura 1. 18

19 Figura 3. Mapeamento em classes concretas Conforme a Figura 3, os atributos de Cliente, Empregado e, no segundo caso, ainda o Executivo, possuem todos os atributos das superclasses. - Uma tabela para cada classe: para cada classe da estrutura hierárquica, existe uma tabela correspondente no banco de dados. A Figura 4 ilustra o mapeamento da Figura 1 utilizando essa técnica, onde cada objeto da hierarquia da Figura 1 possui uma classe respectiva na Figura 4. Figura 4. Mapeamento para cada classe 19

20 - Uma estrutura genérica de tabelas para todas as classes: Uma estrutura genérica não atende a uma hierarquia de classes específicas, é um molde para as classes da aplicação. Cada classe da Figura 1 é representada por uma linha dentro da tabela Classe na Figura 5. Os relacionamentos, atributos e valores seguem a mesma ideia. Figura 5. Mapeamento para cada classe Agregação Para representar agregação de objetos em tabelas relacionais, existem dois padrões: - Agregação em uma tabela: os objetos agregados ao objeto principal têm seus atributos inseridos na tabela relacionada com o objeto principal. - Agregação com chave estrangeira: Os objetos são mapeados em tabelas diferentes, a tabela do objeto principal se comunica com os objetos agregados através de chave estrangeira. Associação Objetos podem ter associações do tipo um-para-muitos (1:N) e muitos-para-muitos (N:M). Para o caso de 1:N, a associação pode ser feita utilizando apenas chaves estrangeiras. O objeto principal possui uma identificação e os objetos associados a ele possuem a mesma 20

21 identificação. No caso de N:M, é criada uma tabela para guardar as associações entre as duas tabelas. Para cada conceito de OO, existem alguns padrões para mapeamento, cada qual possui vantagens e desvantagens. É preciso analisar o cenário para identificar qual padrão é o mais adequado. Abstraindo-se disso, o uso desses padrões acarreta uma adaptação relevante entre os dois paradigmas OO e relacional. Entretanto, isso requer alterações nas estruturas de tabelas preexistentes no banco de dados. As empresas de desenvolvimento e seus clientes, em alguns casos, optam por não alterar a base de dados buscando preservar a integridade dos mesmos. Os dados são a base do sistema e, muitas vezes, vitais para o negócio do cliente. Perdas ou inconsistência de dados podem fazer com que o sistema pare de funcionar acarretando em grandes problemas para o cliente. Assim, a escolha pelo mapeamento sem modificar a base de dados costuma ser a uma opção considerada na área. 1.4 Padrões de projeto Como a implementação das soluções propostas será baseada em OO, torna-se interessante a utilização de soluções reutilizáveis de software orientada a objetos conhecidas como Padrões de Projetos ou Design Patterns (Gamma et al, 2005). Estes padrões definem meios de como projetar uma solução para diversas situações, as quais, com a sua utilização, são resolvidas de forma mais elegante e mais legível. Gamma et al (2005) explica a dificuldade que se tem em projetar softwares orientados a objetos de forma reutilizável. Enfatiza que os mais experientes projetistas afirmam ser difícil ou até mesmo impossível projetar um software reutilizável e flexível em sua versão inicial. Porém, os mais experientes tendem a realizar bons projetos, enquanto que projetistas iniciantes se deparam com uma gama de possibilidades e acabam por, nem sempre, escolher a melhor abordagem. O que Gamma et al (2005) propõe é a catalogação das soluções obtidas em projetos na forma de padrões de projetos. Assim, projetistas poderão obter o conhecimento de soluções que 21

22 deram certo e passar a utilizá-las, enquanto outros projetistas entenderão essas soluções, pois também terão o conhecimento das mesmas através desse catálogo. Os padrões de projetos foram divididos em três grupos de acordo com suas finalidades (Gamma, et al, 2005): - Criação: abstraem o processo de instanciação. Desacoplam o objeto do sistema. O desenvolvedor não precisa saber exatamente qual objeto está sendo instanciado e sim como sua interface funciona. Possibilita a manutenção do objeto escondido sem a interferência na aplicação do usuário. - Estruturais: ajudam na formação de estruturas maiores e mais complexas tanto com classes quanto com objetos. Descrevem meios de como estruturar classes e objetos que foram feitos separadamente para trabalharem juntos. - Comportamentais: preocupam-se com a responsabilidade entre objetos. Permitem ao desenvolvedor focar apenas na maneira em que os objetos são interconectados. Metsker (2004) classifica os padrões em outros cinco grupos, conforme o problema: - Interface: Auxiliam no desenvolvimento de interfaces. - Responsabilidade: Objetos delegam suas responsabilidades para outros objetos. Com esses padrões consegue-se extrair a complexidade de objetos e centralizá-las em outro, facilitando ao desenvolvedor entender o que o objeto faz, abstraindo o como. - Construção: Similar ao de criação de Gamma, abstrai o processo de instanciação do objeto. O cliente do objeto não precisa saber qual é seu construtor concreto, pode trabalhar com interfaces, utilizando padrões de construção evitando instanciar diretamente classes concretas. - Operação: Controlar os métodos e operações dos objetos, os padrões ajudam no desenvolvimento de objetos, facilitando a modelagem na utilização de métodos e operações de outros objetos e tornando mais legível a utilização dos mesmos. 22

23 - Extensão: Padrões para tratar o acesso a uma hierarquia de objetos já existentes. Projeções e técnicas para acessar informações de objetos com o intuito de alterar o mínimo possível o código existente. Os padrões de projeto serão importantes para o desenvolvimento do repositório de soluções, o qual será descrito mais adiante. Conforme os problemas vão sendo analisados, os padrões serão um guia para modelar as soluções de forma adequada. 1.5 Ferramentas ORM Object Relational Mapping (ORM) são ferramentas ou frameworks complexos que realizam o mapeamento do objeto no modelo relacional de forma automatizada e transparente (Bauer, King, 2005). Algumas ferramentas reduzem significantemente o trabalho braçal dos desenvolvedores para persistir os objetos. Em Bauer et King (2005 p ) os autores fazem uma análise sobre a importância das ferramentas ORM. Eles afirmam que as ferramentas trazem um ganho considerável em termos de produtividade para o projeto. Afirmam ainda que, embora ocorra certa penalidade no desempenho da aplicação, isso se torna válido visto o ganho em produtividade. Alegam também que, desenvolver uma aplicação com bom desempenho para diversos tipos de banco de dados é uma tarefa árdua e nem sempre se escolhem os comandos mais performáticos, o que não ocorre em uma ferramenta ORM com anos no mercado. Esta possui conhecimento suficiente para decidir qual o melhor comando para cada banco e, assim, compensar a questão de desempenho perdido. Embora as ferramentas ORM facilitem o trabalho do desenvolvedor em relação à persistência de dados relacionais, é importante o conhecimento do mesmo sobre a relação de suas tabelas no banco e sobre a linguagem SQL. Assim, é possível ter um código de maior qualidade no acesso ao banco, pois o desenvolvedor ainda precisa especificar como será realizado o acesso à base de dados Hibernate 23

24 Hibernate é uma das ferramentas ORM mais utilizadas no ambiente corporativo. Atende a todos aos requisitos de uma ORM. Implementada no ambiente Java com código aberto (OpenSource), o Hibernate provê uma arquitetura flexível e configurável (Bauer; King, 2005). Essa ferramenta disponibiliza algumas maneiras de obter dados do banco, através de uma linguagem de consulta própria (Hibernate Query Language ou HQL), parecida com SQL e uma API de consulta por critérios (QBE), um modo seguro para expressar consultas. Assim, o desenvolvedor não precisa se preocupar com uma linguagem diferente para cada tipo de banco. A ferramenta, no entanto, aceita linguagem SQL, ideal para soluções complexas ou que necessitem de um melhor desempenho. Segundo Bauer et King (2005), um dos objetivos do Hibernate é automatizar 95% do trabalho de persistência realizado pelo desenvolvimento sem uma ORM, resultando em um ganho de produtividade, um requisito importante em grandes projetos. A forma como deve ser feito o mapeamento das tabelas no modelo relacional para os objetos da aplicação OO é definida através de arquivos de configuração escritos em XML. Em alguns casos mais simples, o próprio Hibernate configura o mapeamento, porém Bauer afirma que essa decisão é sensível, e pode não ter sucesso em casos com maior complexidade. Existe também um projeto de código aberto similar ao Hibernate para o ambiente.net chamado NHibernate Ibatis Ibatis é uma ferramenta utilizada em Java, Ruby e.net. Oferece ao usuário uma camada simples de separação entre a aplicação OO e o modelo relacional. O mapeamento dos objetos é realizado através de documentos XML. A escrita dos documentos de configuração é simples, não exige declarações complexas para unir tabelas, por exemplo, (IBATIS, on-line). Essa ferramenta suporta diversos tipos de bancos de dados e tipos diversos de projeto OO na aplicação são bastante tolerantes ao projeto do modelo das tabelas. Alguns frameworks têm dificuldade em se integrar com projetos mal-elaborados, porém o Ibatis possui certa tolerância a esse tipo de projeto. Podendo assim ser uma interessante solução para o caso em 24

25 que se tem uma aplicação OO tentando se comunicar com um banco de dados relacional (IBATIS, on-line). Para o auxílio da geração dos arquivos de configuração em XML e outros artefatos, existe um produto chamado Ibator. Esse produto possui algumas formas de distribuições, uma delas é como plugin para o Eclipse (IDE famosa para desenvolvimento em Java), onde, além dos arquivos de configuração podem ser geradas classes de persistência em Java, e executáveis.jar caso o usuário utilize outra ferramenta além do Eclipse (Ibatis, on-line) CocoBase O CocoBase é um framework ORM para ambiente Java que oferece aumentos de até 25% de produtividade. O fabricante afirma ser o único framework ORM comercial com certificação JPA (API de Persistência do Java) e que, em muitos casos, é mais eficiente que um framework livre de código aberto. O fabricante afirma ainda ter cerca de 200% a 400% mais desempenho que o Hibernate e outras ferramentas (CocoBase c, on-line). No documento (CocoBase b, on-line) entende-se que o mapeamento realizado pelo CocoBase é realizado de forma transparente e dinâmica. Transparente, pois seu mecanismo de persistência não precisa herdar ou implementar classes diferentes e seus objetos e fontes ficam intactos. A arquitetura dinâmica do CocoBase permite que o mesmo mapeamento seja compartilhado por: modelos de Objetos, Servlet, JSP, Applets, EJB e objetos Java. Isso implica em diversos componentes distintos utilizando o mesmo mapeamento no banco de dados. (CocoBase a, on-line). A respeito dos artefatos, seus arquivos de configuração podem ser salvos em qualquer formato, XML, binário, bancos de dados, etc. O CocoBase possui uma ferramenta chamada de Magic Mapper que auxilia na criação dos mapeamentos automaticamente, não necessitando o desenvolvedor criar um mapeamento manualmente para cada relação tabela / classe. Possui aceitação com diversas ferramentas para ambiente Java, como Eclipse, no qual, através de um plug-in, facilita-se a geração dos artefatos (CocoBase c, on-line). 25

26 2 Problemas Encontrados Neste capítulo serão abordados alguns dos problemas encontrados na persistência de objetos em um sistema relacional. Esses problemas foram separados em três categorias, cargas de dados, mapeamento e descarga de dados, os quais serão detalhados seguidos de uma breve descrição de como deve ser solução proposta nesse trabalho. As soluções serão inteiramente discutidas no capitulo três. O trabalho irá adotar em seus exemplos como tema principal o sistema acadêmico de uma faculdade. Consiste em um sistema simples de cadastro de alunos e suas respectivas disciplinas. Conforme os problemas vão sendo explorados o modelo de exemplo pode sofrer adaptações. O modelo padrão das tabelas do sistema de cadastro de alunos e disciplinas está ilustrado no Figura 6. São basicamente três tabelas: ALUNO representando um objeto aluno, DISCIPLINA representando um objeto disciplina e ALUNO_DISCIPLINA que representa o relacionamento 1:N entre Aluno e Disciplinas. 26

27 Figura 6. Modelo de dados Aluno e Disciplinas 2.1 Carga de Dados Os dados de uma aplicação estão mantidos normalmente em um servidor de banco de dados, o qual, muitas vezes, está instalado em um computador diferente do servidor de aplicação. Para que a aplicação possa manipular esses dados faz-se necessária a realização de consultas no banco, através de algum tipo de linguagem específica para este fim, sendo a SQL (Structured Query Language) a mais comum. Em seguida, devem-se preencher os objetos com os respectivos dados retornados pela consulta Cargas Duplicadas Em um sistema de grande porte, diversas consultas são criadas com o intuito de se realizar operações necessárias ao funcionamento do sistema. Certas consultas podem trazer dados já previamente carregados em memória por consultas anteriores. O que normalmente ocorre é o preenchimento de um novo objeto com esses novos dados, o que acaba se tornando uma réplica de outros objetos já existentes na memória. Objetos iguais mesmo em locais diferentes na aplicação não precisam ter suas propriedades replicadas, podem ter suas propriedades referenciadas pelos objetos. 27

28 Outro empecilho da duplicação dos dados é a dificuldade em se manter consistência entre os dados. Alterações em propriedades não serão refletidas nas propriedades replicadas. //Obtém os alunos do curso de computação //Todos os objetos Aluno estão preenchidos com suas disciplinas List<Aluno> alunos = ObterAlunosComputacao(); //Bloco de código utilizando os alunos //Obtém disciplina LP1 Disciplina disciplina = ObterDisciplina( LP1 ); //alterando o nome para Linguagens de Programação disciplina.setnome( Linguagens de Programação ); //Código que deverá exibir todas as disciplinas de todos os alunos //... O código acima irá exibir a disciplina de LP1 como LP1 e não Linguagens de Programação, pois os objetos disciplina foram replicados. Uma solução comum é carregar novamente do banco as disciplinas dos alunos, para recebê-las com a alteração. A solução proposta é a criação de uma camada através da qual os retornos de todas as consultas realizadas no banco de dados devem passar. Assim, é possível o gerenciamento do acesso aos dados, o que se reflete nos objetos de negócio Carga Desnecessária de Dados Frequentemente são necessárias todas as propriedades de um determinado objeto para resolver um problema. Assim, quando esse objeto é carregado a partir do banco de dados utiliza-se, desnecessariamente, a largura de banda da rede e a memória do servidor. Além disso, dependendo de como as tabelas utilizadas na formação do objeto estejam organizadas, buscas pelos dados de uma ou mais tabelas podem também ser evitadas. Uma das técnicas utilizadas para solucionar esse problema é o uso do lazy load, a qual consiste em carregar do banco os dados necessários para preencher certa propriedade do objeto 28

29 apenas quando a mesma é solicitada. Ou seja, são carregadas algumas informações essenciais ao objeto e só são carregadas as demais propriedades quando as mesmas forem necessárias. Métodos get são os casos onde normalmente se utiliza o lazy load. Caso a propriedade esteja nula, é realizada a consulta para preencher esta propriedade e somente então o valor é retornado pelo método. Essa é uma das maneiras mais simples de se implementar essa técnica sem a utilização de frameworks de persistência. O uso do lazy load precisa ser balanceado. Se muitas propriedades são chamadas usando essa técnica, serão geradas muitas consultas desnecessárias ao banco. Nesse contexto, um carregamento completo do objeto poderia ser uma opção mais interessante. Carregar apenas uma vez e somente os dados que serão usados é o ideal, mas nem sempre é possível saber quais dados serão necessários ou, quando se sabe, é preciso o desenvolvedor indicar tais dados em algum lugar (arquivo de configuração, por exemplo), gerando um esforço significativo no desenvolvimento de grandes aplicações. Teoricamente, a melhor solução seria o programa sozinho prever quais dados serão necessários e então chamar todos de uma só vez sem a necessidade do desenvolvedor informar isso em algum local. Em situações simples isso é possível salvando um log com as propriedades utilizadas em determinadas partes do programa. Porém, programas podem ser muito dinâmicos e nem sempre as propriedades que foram utilizadas em um determinado local serão as mesmas em outra execução do programa. A solução proposta neste trabalho envolve algumas práticas a serem detalhadas, uma delas é a utilização de auto-aprendizagem com logs, junto com estatísticas para carregar os dados da melhor forma possível através de uma média de acesso aos dados a fim de tratar o problema de dados dinâmicos Tráfego de Carga Com Dados Redundantes Para preencher um objeto complexo (objeto que possui outros objetos e regras dentro de si), normalmente é preciso acessar várias tabelas. Se apenas uma consulta for realizada para preencher esse objeto, haverá vários dados redundantes, pois os dados para preencher os objetos pai estarão se repetindo em todos os registros acompanhando os dados dos objetos filhos ou coleções, conforme pode ser visualizado na Tabela 1. 29

30 Tabela 1: Um select retornando os dados de um aluno ALUNO_NOME ALUNO_MATRICULA ALUNO_CURSO DISCIPLINA_NOME Thiago Benega Computação Programação 1 Thiago Benega Computação Estrutura de dados 1 Thiago Benega Computação Redes 1 Por outro lado, essa redundância pode ser evitada através da realização de várias conexões em vez de apenas uma. Assim, cada objeto contido dentro de um objeto complexo seria preenchido por vez, para depois consultar e preencher o objeto complexo. As duas abordagens prejudicam a rede que conecta o banco de dados com o servidor de aplicação. A primeira consome largura de banda desnecessariamente transportando dados redundantes, e a segunda realiza várias chamadas ao banco em vez de apenas uma. A solução proposta consiste em carregar todos os dados necessários de uma vez e não transportá-los de forma tabular (como visto na Tabela 1), e sim na forma de objetos, fazendo a conversão dos dados antes de enviar para a aplicação Consultas Polimórficas Ou Hierárquicas Na seção 1.3 deste trabalho foi descrita a dificuldade de se representar uma estrutura hierárquica de classes nas tabelas do banco de dados relacional e suas respectivas técnicas para lidar com o problema. Consultas polimórficas são buscas por entidades de mais alto nível dentro de uma estrutura hierárquica. Considere uma estrutura onde temos dois tipos de classes relativas aos alunos: Aluno_de_Colegio e Aluno_de_Faculdade, ambos herdando de Aluno, a qual, por sua vez, possui uma propriedade nome. Uma consulta por todos os alunos de nome João é considerada polimórfica, pois trará tanto alunos de colégio quanto de faculdade. (BAUER; KING, 2005) A forma como a consulta deve ser criada para realizar esse tipo de consulta depende de qual técnica foi utilizada para mapear a estrutura hierárquica no banco de dados. Com exceção da técnica Tabela única para toda estrutura hierárquica, (seção 1.3) as outras técnicas utilizam 30

31 mais de uma tabela para representar a estrutura hierárquica. Assim para realizar esse tipo de consulta é necessária a utilização de operações de uniões para trazer todos os resultados em uma única consulta ou realizar várias consultas de acordo com o número de tabelas. Segundo Bauer e King (2005) o Hibernate não tem suporte para utilizar uniões nesse contexto, sendo necessário realizar várias consultas ao banco. Como já discutido nesse trabalho, o uso de várias consultas tem suas desvantagens. A dificuldade encontrada aqui é a execução desse tipo de consultas com simplicidade, porém com desempenho adequado e a possibilidade de trazer os dados com apenas uma consulta. Solução proposta: Ter uma estrutura que facilite o trabalho do desenvolvedor, porém sem ocasionar limitações, ser aberta de forma que o desenvolvedor possa realizar o mapeamento e a consulta da forma como desejar. 2.2 Mapeamento Mapear, no contexto desse trabalho, consiste em preencher o objeto de negócio a partir de um banco de dados relacional. As propriedades do objeto são relacionadas com as colunas das tabelas no banco de dados. O objeto Aluno tem sua propriedade Nome relacionada com a coluna NOME da tabela ALUNO, por exemplo. A relação entre propriedade do modelo OO e coluna do Modelo Relacional não precisa ser 1:1, podendo ser N:M. Uma propriedade pode ser a junção de duas ou mais colunas e vice-versa. Porém, o mais comum é a relação 1:1 e esta será a mais abordada no trabalho Tabelas Com Colunas de Nomes Iguais Um objeto pode ser formado a partir de várias tabelas no banco de dados. Trazer todos os dados em uma única consulta pode gerar alguns conflitos de nomes, pois diferentes tabelas podem conter colunas de mesmo nome. Assim o retorno da consulta deve diferenciar quais são os atributos de cada tabela. Ex: as tabelas ALUNO e DISCIPLINA possuem uma coluna chamada NOME. A solução proposta é a utilização de um prefixo de forma a diferenciar e garantir a unicidade do nome da coluna. 31

32 2.2.2 Campos de Retorno Dinâmicos A solução de carga parcial utilizando o lazy load proposta nesse trabalho usa o conceito de retornar os campos que estão sendo mais requisitados, assim as colunas escolhidas para carregar o objeto precisam estar na consulta. Assim temos duas opções: retornar todas as colunas ou deixar o retorno de colunas dinâmico. Retornar todas as colunas seria um desperdício de memória e banda. A solução mais interessante em termos de desempenho é o retorno de colunas dinâmico. Solução proposta: O desenvolvedor não deve então informar as colunas de retorno, estas devem ser escritas dinamicamente pelo sistema de acordo com a necessidade da lógica do lazy load. As duas soluções precisam se comunicar para o funcionamento completo Acoplamento Com o Banco de Dados Existem soluções no mercado que tornam a aplicação acoplada à estrutura do banco de dados. Caso ocorra alguma mudança nas tabelas os objetos da aplicação precisam ser modificados para aceitar a nova estrutura. Algumas soluções apenas necessitam mudar arquivos de configuração (ex: hibernate e Ibatis), que definem o mapeamento objeto tabela. Mesmo com os arquivos de configurações alterados para comportar as mudanças das tabelas, muitos arquivos ou classes com consultas, inserções, atualizações e deleções, criados conforme o modelo de dados antigo, terão de mudar os nomes das tabelas e colunas. Isso pode ser bastante trabalhoso. Os objetos da aplicação provavelmente sofrerão modificações também. Seja inclusão ou deleção de propriedades ou alteração na lógica de manipulação das propriedades. Um exemplo de modificação simples que necessita de alteração no objeto: Suponha-se que a tabela ALUNO retirou a coluna NOME e criou as colunas PRIMEIRO_NOME, SOBRENOME. O objeto Aluno possui os métodos getnome e setnome, os quais terão que implementar uma lógica para manipular as duas colunas ou então criar métodos getprimeironome, getsobrenome etc.. Porém, isso pode resultar em modificações maiores dentro da aplicação. 32

33 Resumindo: modificações feitas no banco que impliquem na aplicação indicam um acoplamento da aplicação com o modelo de dados. A solução proposta vai além de simples arquivos de configuração. Ter uma camada intermediária entre os objetos e as tabelas. Dessa forma, as mudanças nas tabelas exigem alterações, até certo ponto, apenas dessa camada intermediária. 2.3 Descarga de Dados A descarga consiste em persistir os dados manipulados pelos objetos de negócio da aplicação no banco de dados. Utiliza os critérios de mapeamento pré-definidos entre os objetos e suas respectivas tabelas para poder salvar os dados dos objetos Descarregar Apenas o Necessário Um objeto muito complexo é comumente alterado apenas em parte de suas propriedades. Executar uma atualização no banco de dados com todas as propriedades é desperdício de banda da rede, visto que propriedades inalteradas serão trafegadas pela rede que conecta a aplicação com o banco, e, dependendo do SGBD, terá uma sobrecarga desnecessária. Esse tipo de problema a maioria dos frameworks ORM resolve, o problema é que alguns SGBDs possuem melhor desempenho quando todas as colunas são atualizadas, mesmo que apenas uma tenha sido alterada. O hibernate trata as duas formas, escolhendo a que for melhor pro SGBD em questão. (BAUER; KING, 2005). O caso onde o SGBD tem melhor desempenho com a atualização de todas as colunas, a rede, no entanto, será penalizada, pois irá carregar dados que não foram atualizados. Neste caso o ideal seria alcançar o melhor desempenho do SGBD sem penalizar a rede. Solução proposta: ter uma estrutura no lado do servidor de banco de dados, e outro no lado da aplicação, então controlar mudanças nas propriedades dos objetos para poder ser enviado para estrutura do lado do banco apenas as colunas alteradas, e esta por sua vez altera todas as colunas no banco. 33

34 2.3.2 Descarregar Apenas Quando Necessário No desenvolvimento da aplicação, cabe ao desenvolvedor informar os pontos em que os dados devem ser salvos no banco. O comando commit deve ser executado quando se deseja garantir que tudo já enviado ao banco ocorreu com sucesso e deve ser persistido. Caso algum erro ocorra na aplicação, o comando commit não será executado, e sim um rollback o qual desfaz todas as alterações no banco realizadas durante a transação. Em casos como este, todos os comandos enviados foram apenas desperdício de banda de rede e de processamento no banco de dados. Outra questão a ser analisada é que durante a execução do código o desenvolvedor pode executar alterações no banco em partes diferentes do programa e, muitas vezes, os dados não necessitavam ser inseridos no banco no exato momento. Pode ser mais interessante para a aplicação e o banco de dados, executar todos os comandos de uma vez só. No entanto, realizar essa lógica manualmente exige um esforço a mais do programador, o qual precisa analisar se os dados a serem inseridos no banco serão utilizados em alguma consulta futura ou não, porém ao longo do desenvolvimento o programador deve rever se essa questão se mantém diante das alterações. Solução proposta: Manter os dados na camada entre aplicação e banco de dados até que um commit seja executado ou alguma consulta necessite acessar alguma tabela que esteja sendo mantida na camada. 34

35 3 REPOO (Repositório Orientado a Objetos) Esse capítulo descreve o que vem a ser o Repositório Orientado a Objetos, a base para solucionar os problemas encontrados e catalogados no capítulo dois deste trabalho. O REPOO não é um framework ORM ou uma biblioteca. É uma sugestão, ou guia de implementação que tenta tratar de uma forma diferente alguns problemas relacionados com o relacionamento entre persistência de dados relacionais com orientação a objetos. A ideia base do REPOO é ser uma camada de transição entre aplicação (OO) e o banco de dados (relacional). Essa camada tenta representar as colunas e os relacionamentos entre as tabelas de forma orientada a objetos. As colunas se unem formando uma rede, deixando de se representar de forma tabular. A Figura 7 exemplifica a representação de um cenário entre as três camadas, temos um aluno e suas respectivas disciplinas. Na camada relacional representa-se isso através de três tabelas, ALUNO, DISCIPLINA e ALUNO_DISCIPLINA que mantém o relacionamento entre um aluno com suas respectivas disciplinas, utilizando os conceitos de chave estrangeira. Na camada do REPOO temos dois Containers, ContainerAluno e ContainerDisciplina, os containers mantém os objetos Campos que fazem o mapeamento com as colunas das tabelas, dentro de AlunoContainer tem um objeto do tipo CampoList (Disciplinas), este possui uma lista de ContainerDisciplina e faz o mapeamento e tratamento da junção no modelo relacional. Na camada da aplicação, temos o objeto Aluno que possui uma lista de objeto disciplina. Estes objetos, como já citado, não possuem propriedades, e sim métodos que fazem uso dos Campos relacionados. 35

36 Figura 7. Camada REPOO A camada do REPOO, diferentemente das soluções comuns encontradas no mercado, não é apenas um mapeamento entre propriedades dos objetos e colunas das tabelas do banco, e sim uma camada intermediária que suporta implementação por parte do desenvolvedor. Nas soluções ORM é comum a utilização de arquivos de configuração para realizar o mapeamento 36

37 entre objetos e tabelas, não apenas relacionamentos simples, relacionamentos um para muitos mapeando uma lista de objetos também são aceitos. Porém tais arquivos de configuração são limitados ao que a ferramenta oferece, a camada do REPOO permite implementação, podendo retirar qualquer tipo de lógica de persistência dos objetos de negócio. Em Padrões de Projetos é visto que objetos podem delegar suas responsabilidades para outros melhorando o entendimento, a legibilidade e manutenibilidade do código. O REPOO permite que a complexidade de persistência de dados seja extraída dos objetos da aplicação, pois os mesmos não possuem atributos ou propriedades dentro de si, apenas métodos de acesso gets e sets que fazem referência aos objetos na camada do REPOO. A Figura 8 mostra o relacionamento entre as três camadas, Aplicação, REPOO e Banco de dados. Na camada de aplicação temos os objetos, que por sua vez possuem propriedades, em boas práticas de OO as propriedades são privadas e podem ser acessadas por métodos, get<nome da propriedade> e set<nome da propriedade>. Neste trabalho os objetos apenas possuem os métodos de acesso, suas propriedades são os objetos Campo, assim quando é dito que uma propriedade se relaciona com determinados objetos Campo, significa que os métodos de acesso manipulam diretamente os objetos Campo relacionados. Na camada do REPOO temos os objetos Campo, os mesmos guardam os valores manipulados pelos objetos da aplicação e no momento certo realizam a persistência destes dados nas colunas relacionadas no banco de dados. O contrário também ocorre, os dados das colunas são carregados do banco para os determinados objetos Campo e os objetos da aplicação fazem uso dos mesmos. 37