Escolar Documentos
Profissional Documentos
Cultura Documentos
Metodologia Celepar
Agosto 2009
Sumário de Informações do Documento
Documento: guiaModelagemObjetoRelacional.odt Número de páginas: 14
Danielle Mayer e Marcos
1.0 26/08/09 Revisão e Alteração
Chiarello
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 MultiObjetos.................................................................................................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 OBJETORELACIONAL...................................................................................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ãovolá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 utilizarse, 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 MultiObjetos
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 utilizarse 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
2.1.6 Identificadores de Objetos
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) utilizamse 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
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
2.1.10 Diversas Versões de Banco de Dados e Fabricantes
2.1.11 Múltiplas Conexões
Um gerenciamento de conexões (usualmente utilizandose 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 utilizandose 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 tornamse 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 OBJETORELACIONAL
Utilizase 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)
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, devese 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, destacase 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, tentase 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.
METODOLOGIA DE DESENVOLVIMENTO CELEPAR
12
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)
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.
Criase 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
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
METODOLOGIA DE DESENVOLVIMENTO CELEPAR
14
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 ObjetoRelacional – Processo de Desenvolvimento de Sistemas do
Tribunal de Contas da União.
METODOLOGIA DE DESENVOLVIMENTO CELEPAR