Guia para Mapeamento Objeto Relacional
Propaganda
Guia para Mapeamento Objeto Relacional Metodologia Celepar Agosto 2009 Sumário de Informações do Documento Documento: guiaModelagemObjetoRelacional.odt Número de páginas: 15 Versão Data Mudanças 1.0 11/03/2008 1.0 26/08/09 Revisão e Alteração 1.0 07/10/13 Correção figura 5 , o diagrama de classes estava com as duas classes iguais. criação Autor Marcos Chiarello Danielle Mayer e Marcos Chiarello Danielle Mayer Sumário 1 INTRODUÇÃO................................................................................................................................4 1.1 Visão Geral ..............................................................................................................................4 2 CAMADA DE PERSISTÊNCIA.....................................................................................................4 3 Vantagens da utilização....................................................................................................................5 3.1 Requisitos de uma camada de persistência...............................................................................5 3.1.1 Suporte a diversos tipos de mecanismos de persistências:...............................................5 3.1.2 Encapsulamento Completo da Camada de Dados:...........................................................5 3.1.3 Ações com Multi­Objetos.................................................................................................5 3.1.4 Transações.........................................................................................................................6 3.1.5 Extensibilidade..................................................................................................................6 3.1.6 Identificadores de Objetos................................................................................................6 3.1.7 Cursores e Proxies.............................................................................................................6 3.1.8 Registros............................................................................................................................6 3.1.9 Arquiteturas Múltiplas......................................................................................................7 3.1.10 Diversas Versões de Banco de Dados e Fabricantes.......................................................7 3.1.11 Múltiplas Conexões.........................................................................................................7 3.1.12 Queries sql.......................................................................................................................7 3.1.13 Controle de Concorrência...............................................................................................7 4 MAPEAMENTO OBJETO­RELACIONAL...................................................................................8 4.1 Identificação de chave primária................................................................................................8 4.2 OIDs (Objects Identifiers)........................................................................................................9 4.3 Mapeamento de Classes em Tabelas........................................................................................9 4.4 Mapeamento de Atributos em Colunas...................................................................................10 4.5 Mapeamento de Herança........................................................................................................10 4.6 Mapeamento de Associações..................................................................................................12 4.7 Associações do tipo 1 para 1 (1:1).........................................................................................12 4.8 Associações do tipo 1 para n (1:n)..........................................................................................12 4.9 Associação do tipo n para n (n:n)...........................................................................................13 5 MAPEAMENTO DE ASSOCIAÇÕES TODO/PARTE...............................................................13 6 CONSIDERAÇÕES FINAIS.........................................................................................................14 7 REFERÊNCIAS ............................................................................................................................14 4 1 INTRODUÇÃO Este guia tem por objetivo de orientar a atuação do Analista de Sistemas no mapeamento das classes persistentes para tabelas em bancos relacional. 1.1 Visão Geral A adoção de metodologias de desenvolvimento Orientadas a Objetos como um padrão levou a uma mudança radical na estruturação e organização de informação. Contudo, a utilização de bancos de dados relacionais ainda é uma prática comum e será mantida por um longo período de tempo. Graças à necessidade de se trabalhar com estas bases de dados relacionais para o armazenamento persistente de dados, é comum a adaptação dos modelos de objetos na tentativa de compatibilizá­los com o modelo relacional. Para piorar ainda mais este quadro, é notório o esforço aplicado no processo de persistência manual dos objetos no banco de dados – o que força os desenvolvedores de aplicações a ter que dominar a linguagem SQL e utilizá­la para realizar acessos ao banco de dados. Estas duas questões principais levam a uma redução considerável na qualidade do produto final, construção de uma modelagem “orientada a objetos” inconsistente e a um desperdício considerável de tempo na implementação manual da persistência. Apesar disso, não é possível ignorar a força e confiabilidade dos Sistemas de Gerenciamento de Bancos de Dados (SGBDs) relacionais nos dias de hoje – após anos de desenvolvimento e ajustes de performance fazem dos bancos de dados relacionais a opção mais eficiente, se comparados à maioria dos SGBDs Orientados a Objetos. Para permitir um processo de mapeamento entre sistemas baseados em objetos e bases de dados relacionais, foram propostas diversas idéias que convergiram para o conceito de Camada de Persistência. 1 CAMADA DE PERSISTÊNCIA Conceitualmente, uma Camada de Persistência de Objetos é uma biblioteca que permite a realização do processo de persistência (isto é, o armazenamento e manutenção do estado de objetos em algum meio não­volátil, como um banco de dados) de forma transparente. Graças à independência entre a camada de persistência e o repositório (backend) utilizado, também é possível METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR 5 gerenciar a persistência de um modelo de objetos em diversos tipos de repositórios, teoricamente com pouco ou nenhum esforço extra. A utilização deste conceito permite ao desenvolvedor trabalhar como se estivesse em um sistema completamente orientado a objetos – utilizando métodos para incluir, alterar e remover objetos e uma linguagem de consulta para SGBDs Orientados a Objetos – comumente a linguagem OQL – para realizar consultas que retornam coleções de objetos instânciados. 2 VANTAGENS DA UTILIZAÇÃO As vantagens decorrentes do uso de uma Camada de Persistência no desenvolvimento de aplicações são evidentes: a sua utilização isola os acessos realizados diretamente ao banco de dados na aplicação, bem como centraliza os processos de construção de consultas (queries) e operações de manipulação de dados (insert, update e delete) em uma camada de objetos inacessível ao programador. Este encapsulamento de responsabilidades garante maior confiabilidade às aplicações e permite que, em alguns casos, o próprio SGBD ou a estrutura de suas tabelas possam ser modificados, sem trazer impacto à aplicação nem forçar a revisão e recompilação de códigos. 2.1 Requisitos de uma camada de persistência 2.1.1 Suporte a diversos tipos de mecanismos de persistências: Um mecanismo de persistência pode ser definido como a estrutura que armazenará os dados – seja ela um SGBD relacional, um arquivo XML ou um SGBD OO, por exemplo. Uma Camada de Persistência deve suportar a substituição deste mecanismo livremente e permitir a gravação de estado de objetos em qualquer um destes meios. 2.1.2 Encapsulamento Completo da Camada de Dados: O usuário do sistema de persistência de dados deve utilizar­se, no máximo, de mensagens de alto nível como save ou delete para lidar com a persistência dos objetos, deixando o tratamento destas mensagens para a camada de persistência em si. 2.1.3 Ações com Multi­Objetos METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR 6 Suportar listas de instâncias de objetos e retornadas da base de dados deve ser um item comum para qualquer implementação, tendo em vista a freqüência desta situação. 2.1.4 Transações Ao utilizar­se da Camada de Persistência, o programador deve ser capaz de controlar o fluxo da transação – ou ter garantias sobre o mesmo, caso a própria Camada de Persistência preste este controle. 2.1.5 Extensibilidade A Camada de Persistência deve permitir a adição de novas classes ao esquema e a modificação fácil do mecanismo de persistência. 2.1.6 Identificadores de Objetos A implementação de algoritmos de geração de chaves de identificação garante que a aplicação trabalhará com objetos com identidade única e sincronizada entre o banco de dados e a aplicação. 2.1.7 Cursores e Proxies As implementações de serviços de persistência devem ter ciência de que, em muitos casos, os objetos armazenados são muito grandes – e recuperá­los por completo a cada consulta não é uma boa idéia. Técnicas como o lazy loading (carregamento tardio) utilizam­se dos proxies para garantir que atributos só serão carregados à medida que forem importantes para o cliente e do conceito de cursores para manter registro da posição dos objetos no banco de dados (e em suas tabelas específicas). 2.1.8 Registros Apesar da idéia de trabalhar­se apenas com objetos, as camadas de persistência METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR 7 devem, no geral, dispor de um mecanismo de recuperação de registros ­ conjuntos de colunas não encapsuladas na forma de objetos, como resultado de suas consultas. Isto permite integrar as camadas de persistência à mecanismos de geração de relatórios que não trabalham com objetos, por exemplo, além de permitir a recuperação de atributos de diversos objetos relacionados com uma só consulta. 2.1.9 Arquiteturas Múltiplas O suporte a ambientes de programas stand­alone, cenários onde o banco de dados encontra­se em um servidor central e mesmo arquiteturas mais complexas (em várias camadas) deve ser inerente à Camada de Persistência, já que a mesma deve visar a reusabilidade e fácil adaptação a arquiteturas distintas. 2.1.10 Diversas Versões de Banco de Dados e Fabricantes A Camada de Persistência deve tratar de reconhecer diferenças de recursos, sintaxe e outras minúcias existentes no acesso aos bancos de dados suportados, isolando isto do usuário do mecanismo e garantindo portabilidade entre plataformas. 2.1.11 Múltiplas Conexões Um gerenciamento de conexões (usualmente utilizando­se de pooling) é uma técnica que garante que vários usuários utilizarão o sistema simultaneamente sem quedas de performance. 2.1.12 Queries sql Apesar do poder trazido pela abstração em objetos, este mecanismo não é funcional em cem porcento dos casos. Para os casos extremos, a Camada de Persistência deve prover um mecanismo de queries que permita o acesso direto aos dados – ou então algum tipo de linguagem de consulta simular à SQL, de forma a permitir consultas com um grau de complexidade maior que o comum. 2.1.13 Controle de Concorrência METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR 8 Acesso concorrente a dados pode levar a inconsistências. Para prever e evitar problemas decorrentes do acesso simultâneo, a Camada de Persistência deve prover algum tipo de mecanismo de controle de acesso. Este controle geralmente é feito utilizando­se dois níveis – com o travamento pessimístico (pessimistic locking), as linhas no banco de dados relativas ao objeto acessado por um usuário são travadas e tornam­se inacessíveis a outros usuários até o mesmo liberar o objeto. No mecanismo otimístico (optimistic locking), toda a edição é feita em memória, permitindo que outros usuários venham a modificar o objeto 3 MAPEAMENTO OBJETO­RELACIONAL Utiliza­se uma abstração bastante intuitiva no sentido de que uma classe do tipo persistente pode ser mapeada para uma tabela no banco de dados relacional e atributos da classe para campos da tabela. Porém, algumas diferenças entre os dois modelos , como OID (Object Identifiers – Identificador de Objetos), tipos de dados, herança e associações, demandam um estudo mais detalhado das estratégias de mapeamento. 3.1 Identificação de chave primária As linhas das tabelas precisam ter identidade exclusiva. Elas são identificadas com exclusividade pelos valores de suas chaves primárias e conseqüentemente, nunca devem ser alteradas. Os nomes em texto sem formatação não são adequados, pois, geralmente, representam um overhead operacional para o recurso relacional persistente, além do que os nomes não são exclusivos. Como as comparações numéricas consomem menos recursos computacionais, as chaves primárias devem ser numéricas e, preferencialmente, não devem refletir domínio de negócio, para que não sejam alteradas. METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR 9 3.2 OIDs (Objects Identifiers) Os OIDs são identificadores únicos que representam um objeto, em linguagens de programação, existentes, este objeto é implícito e criado quando ocorre a criação de um novo objeto, já em um banco de dados relacional cabe ao desenvolvedor a responsabilidade desta criação. Quando ocorre o mapeamento, recomenda­se armazenar no banco de dados relacional o identificador do objeto como chave primária, ou qualquer outro atributo do objeto que possa identificá­lo como único, exemplo o CPF. Existem várias estratégias para atribuir OIDs para objetos, inclusive pode­se criar uma ou mais classes cuja responsabilidade específica é a de atribuir OIDs para objetos, sendo estas estratégias separadas das classes que implementam as regras de negócio. É considerada uma boa prática de desenvolvimento separar a estratégia de atribuição de OIDs das classes de negócio, evitando utilizar um atributo qualquer da classe para ser o identificador. Identificadores que possuem um significado de negócio, certamente mudam em algum momento, pois as regras de negócio mudam freqüentemente, e o esforço necessário para realizar esta modificação pode ser imensurável. 3.3 Mapeamento de Classes em Tabelas O mapeamento de classes pode ser feito mediante a paridade entre classe e tabela, ou seja, uma classe é mapeada para uma tabela. Este mapeamento direto de classes para tabelas representa a forma mais simples de mapeamento, tornando mais fácil o entendimento e a manutenção de uma aplicação. Com um modelo de classes bastante simples isto poderia ser feito. Porém, nem sempre é simples assim. No caso de uma estrutura hierárquica, várias classes podem ser mapeadas para uma tabela, como também uma classe pode ser mapeada para várias tabelas. Ainda, classes com atributos multivalorados ou compostos podem ser mapeadas para mais de uma tabela, Figura 1. METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR 10 Figura 1. Mapeamento de Classes em Tabelas 3.4 Mapeamento de Atributos em Colunas Ao tratar do mapeamento de atributos de uma classe para colunas em tabelas de um banco de dados relacional, deve­se levar em conta que os atributos podem ser de tipos de dados simples ou primários como: inteiros, ponto flutuante, caracteres, boleanos e binários, mas também podem ser de tipos de dados complexos como tipos baseados em outras classes. Os atributos podem ser ainda multivalorados (listas de objetos), o que viola as regras de normalização do modelo relacional. Além disso, podem existir atributos de controle ou utilizados em cálculos, que geralmente não necessitam ser mapeados. Desta forma, os atributos simples podem ser mapeados diretamente para colunas em uma tabela, já os atributos complexos e multivalorados podem necessitar de tabelas adicionais para seu armazenamento. Estes atributos complexos geralmente possuem características recursivas, ou seja, são classes que possuem outros atributos e assim sucessivamente. 3.5 Mapeamento de Herança Existem fundamentalmente três estratégias para mapear herança em um banco de dados relacional, exemplificado pela Figura 2 ● Uma tabela por hierarquia: Mapear toda a hierarquia de classes para uma tabela, onde todos os atributos das classes da hierarquia são armazenados nesta única tabela. A desvantagem desta estratégia é que toda vez que um objeto da hierarquia for persistido no banco, é necessário persistir também os valores das demais classes vazios, causando uma grande quantidade de campos inutilizados. Entretanto o acesso ao banco para a manipulação METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR 11 dos dados é mais rápido, uma vez que todos os dados estão em somente uma tabela. É adicionada uma coluna (Object Type) na tabela que referência qual o tipo do objeto, ou seja, de qual classe aqueles dados pertencem; ● Uma tabela por classe concreta: Cada classe concreta mapeada reflete uma tabela com todos os atributos herdados das super classes abstratas. A vantagem desta estratégia é a facilidade de manipulação de dados, uma vez que todos os dados de cada classe estão em apenas uma única tabela. Como desvantagem, destaca­se que quando se modifica uma classe abstrata, é necessário modificar todas as tabelas geradas pelas classes filhas no modelo relacional; ● Uma tabela por classe: Cada hierárquica mapeada reflete uma tabela, relacionadas através do mecanismo de especialização padrão do banco de dados relacional (utilização de chaves estrangeiras). Segunda 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 na UML. Esta é a técnica que mais naturalmente mapeia objetos para banco de dados relacionais. Tabela 1 representa uma comparação entre as técnicas de mapeamento. Figura 2. Exemplo de técnicas de mapeamento. Uma tabela por Uma tabela por classe Uma tabela por classe hierarquia de classes concreta Ad­hoc reporting Simples Médio Médio/Difícil Facilidade de Simples Médio Difícil implementação METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR 12 Facilidade de acesso Simples Simples Médio/Difícil Acoplamento Muito alto Alto Baixo Velocidade de acesso Rápido Rápido Médio/Rápido Suporte a polimorfismo Médio Baixo Tabela 1. Comparação entre as técnicas Alto 3.6 Mapeamento de Associações As associações entre classes no modelo orientado a objetos é conceitualmente bastante similar ao relacionamento entre tabelas no modelo relacional. Este fato permite que tais associações sejam mapeadas para relacionamentos, podendo utilizar chaves estrangeiras ou tabelas auxiliares. 3.7 Associações do tipo 1 para 1 (1:1) A associação deste tipo entre classes é mapeada colocando o atributo identificador da classe referenciada na classe que o referência, criando então o conceito de uma chave estrangeira no modelo relacional, como demonstrado na Figura 3. Figura 3. Associação do tipo 1 para 1 3.8 Associações do tipo 1 para n (1:n) Da mesma forma que a associação do tipo 1:1, o relacionamento 1:n também é mapeado colocando o atributo identificador da classe referenciada na classe que o referência, criando então o conceito de uma chave estrangeira no modelo relacional, como demonstrado na Figura 4. METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR 13 Figura 4. Associação do tipo 1 para n 3.9 Associação do tipo n para n (n:n) Para mapear uma associação do tipo n:n, é necessário utilizar o conceito de tabela associativa, cujo propósito é manter o relacionamento entre duas ou mais tabelas do modelo relacional. Cria­se então uma tabela associativa com os OID’s das classes que se referenciam, garantindo a navegabilidade do relacionamento, como exemplificado na Figura 5. Figura 5. Associação do tipo n para n 4 MAPEAMENTO DE ASSOCIAÇÕES TODO/PARTE As associações todo/parte geralmente são representadas como agregações ou composições. As agregações são associações que representam uma relação grupo/membro, ou seja, onde o objeto agregado pode existir independente dos objetos que o constituem. Já a composição representa um tipo de associação onde o todo não existe sem sua(s) parte(s). Neste caso, tanto agregações quanto METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR 14 composições são mapeadas para tabelas de duas formas: utilizando uma única tabela com todos os atributos da classe que representa o todo e das classes que representam suas partes, ou mais de uma tabela, uma para cada classe envolvida no modelo. 5 CONSIDERAÇÕES FINAIS O objetivo de qualquer projeto é, dentre outros aspectos, eliminar os riscos técnicos e produzir uma arquitetura estável, com uma baseline adequada. Em muitos sistemas de negócios, o mau desempenho resultante de um modelo de dados projetado incorretamente é uma das principais preocupações em termos de arquitetura. Como conseqüência, a modelagem de dados e a elaboração de um rascunho da estrutura do software em desenvolvimento, que permita a avaliação do desempenho do banco de dados , é essencial para a obtenção de uma boa arquitetura. As principais estruturas do banco de dados, dentre elas; tabelas, índices, colunas de chave primária e chave estrangeira, devem ser usadas para suportar cenários significativos do ponto de vista da arquitetura. Além disso, grandes volumes de dados devem ser carregados nos bancos relacionais para suportar testes de desempenho do sistema. Com base nos resultados desses testes, talvez o modelo de dados precise ser otimizado, incluindo, dentre outros, desnormalização, otimização de atributos de armazenamento físico, distribuição ou indexação. Durante o projeto, colunas adicionais podem ser incluídas nas tabelas, visões que suportem requisitos de consulta e relatório podem ser criadas e índices podem ser elaborados para otimizar o desempenho. Não devem ocorrer grandes reestruturações da tabela ao longo do projeto do sistema, pois isso demonstra que a arquitetura não está estabilizada. 6 REFERÊNCIAS Mapeando Objetos para Bancos de Dados Relacionais: técnicas e implementações ­ Disponível em <http://www.md.cefetpr.br/pos/informaticaIV/professor/rosane/POO_UML/Mapeando%20Objetos %20para%20Banco%20de%20Dados%20Relacional.pdf>: Acesso em março de 2008. Norma para Mapeamento Objeto­Relacional – Processo de Desenvolvimento de Sistemas do Tribunal de Contas da União. METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR 15 METODOLOGIA DE DESENVOLVIMENTO ­ CELEPAR
