IV_Teorico (2)

Prévia do material em texto

Inserir Título Aqui 
Inserir Título Aqui
Arquitetura de Software
Mapeamento Objeto-Relacional e Camada de Persistência
Responsável pelo Conteúdo:
Prof. Me. Wilson Vendramel
Revisão Textual:
Prof. Esp. Claudio Pereira do Nascimento
Nesta unidade, trabalharemos os seguintes tópicos:
• Mapeamento Objeto-Relacional e Camada de Persistência.
Fonte: iStock/Getty Im
ages
Objetivos
• Entender o mapeamento de objetos para o modelo relacional e a construção da camada 
de persistência.
Caro Aluno(a)!
Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o 
último momento o acesso ao estudo, o que implicará o não aprofundamento no material 
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.
Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você 
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns 
dias e determinar como o seu “momento do estudo”.
No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões 
de materiais complementares, elementos didáticos que ampliarão sua interpretação e 
auxiliarão o pleno entendimento dos temas abordados.
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de 
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de 
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de 
troca de ideias e aprendizagem.
Bons Estudos!
Mapeamento Objeto-Relacional 
e Camada de Persistência
UNIDADE 
Mapeamento Objeto-Relacional e Camada de Persistência
Contextualização 
Na maioria dos sistemas de software desenvolvidos que utilizam a tecnologia de orien-
tação a objetos e a tecnologia de banco de dados relacional, uma parte considerável do 
tempo de desenvolvimento geralmente é usado com o mapeamento objeto-relacional, 
uma tarefa relativamente complexa e propensa a erros. Apesar de serem tecnologias 
diferentes, muitos sistemas de software utilizam conceitos de ambas em sua construção. 
Em geral, as regras de negócio, interface de usuário e toda a camada de infraestrutura de 
software são construídas utilizando tecnologias que contemplam a orientação a objetos 
enquanto que os mecanismos de armazenamento físico de dados utilizam um Sistema 
Gerenciador de Banco de Dados Relacional (SGBDR). Em sistemas de software dessa 
natureza, inclusive aplicações Web, torna-se necessário que objetos de negócio de domínio 
persistam entre diferentes seções de uso do sistema, sendo requerido um esforço adicional 
para adaptar as estruturas de dados de objetos para estruturas relacionais (tabelas).
Um framework de mapeamento objeto-relacional pode ajudar a reduzir considera-
velmente a complexidade no processo de desenvolvimento de sistemas de software, 
diminuindo o tempo gasto na implementação e aumentando a qualidade do software. 
De qualquer forma, é preciso entender que a adoção de um framework objeto-relacio-
nal não resolverá todos os problemas causados pelas diferenças existentes entre essas 
duas tecnologias.
6
7
M apeamento Objeto-Relacional 
e Camada de Persistência
Este material teórico apresenta o mapeamento objeto-relacional e a camada de per-
sistência, enfatizando o mapeamento de objetos para o modelo relacional e o padrão de 
projeto para persistência de dados Data Access Object (DAO). Para facilitar a compre-
ensão da representação do mapeamento objeto-relacional e da camada de persistência 
de dados, serão utilizadas notações da Unified Modeling Language (UML), especifica-
mente os diagramas de classes, de pacotes e de implantação.
Modelo de Objetos Versus Modelo Relacional
As tecnologias que utilizam o paradigma orientado a objetos são comumente adotadas 
no desenvolvimento de aplicações de software, em contrapartida a tecnologia de banco 
de dados relacional também está bastante presente na maioria dos sistemas de software, 
inclusive nos sistemas distribuídos e baseados na Web. Apesar da utilização mútua dessas 
tecnologias, cada uma delas tem como fundamentos bem distintos. Enquanto no modelo 
de objetos, os elementos correspondem a abstrações de comportamento, no modelo 
relacional, os elementos correspondem aos dados no formato de tabela.
Em um sistema de software orientado a objetos, os elementos (objetos) podem ser 
transientes ou persistentes. Os objetos transientes só existem em tempo de execução, 
isto é, na memória da máquina durante uma sessão de uso do sistema. Os objetos visão 
e objetos controladores são exemplos típicos de objetos transientes. Os objetos persis-
tentes existem durante várias execuções do sistema; para tal, esses objetos precisam 
ser armazenados quando a sessão de uso termina e recuperados quando outra sessão 
é inicializada. Os objetos do tipo modelo são exemplos típicos de objetos persistentes. 
(BEZERRA, 2015)
No caso de objetos persistentes, surge o problema de conciliar as informações repre-
sentadas pelo estado de um objeto e pelos dados armazenados na forma de registros em 
uma tabela. Esse problema, denominado impedance mismatch, representa um conjun-
to de conceitos e dificuldades técnicas quando um banco de dados relacional é utilizado 
por um sistema de software orientado a objetos.
Informações mais técnicas sobre impedance mismatch podem ser encontradas em https://goo.gl/53lSls
Certo, há diferenças entre as representações do modelo de objetos e o modelo rela-
cional. Nesse caso, o que devemos fazer?
Um esforço significativo de desenvolvimento recai sobre a solução que o desenvolve-
dor de software deve dar a esse problema, tentando evitar a falta de consistência entre 
as informações quando os objetos vêm do banco de dados para a memória principal ou 
vão desta última para o banco de dados.
7
UNIDADE 
Mapeamento Objeto-Relacional e Camada de Persistência
Projeto de Banco de Dados
Na Unidade 1, foi apresentando um modelo geral do processo de design de sistema 
de software. Vamos lembrar rapidamente desse modelo? Eu penso ser importante rever 
este modelo antes de darmos sequência na explanação dos conceitos desta unidade. 
A figura 1 apresenta um modelo geral do processo de design de sistema de software 
(Sommerville, 2011). Observe que cada atividade de projeto resulta em uma saída de proje-
to. O projeto de arquitetura resulta na arquitetura de sistema; o projeto de interface resulta 
na especificação de interface; o projeto de componentes resulta na especificação de compo-
nentes e o projeto de banco de dados resulta na especificação de banco de dados. Observe 
ainda que o projeto de banco de dados é uma das atividades de projeto (design) e que apre-
senta relações com o projeto de arquitetura e o projeto de componentes, mostrando que 
o projeto de banco de dados é influenciado por ambos os projetos. Vale lembrar que todas 
essas saídas (especificações) compõem o projeto (design) de arquitetura de software. 
Figura 1 – Modelo geral do processo de design
Fonte: Sommerville, 2011 p.26
Outro aspecto importante é comparar brevemente o que cada unidade anterior desta 
disciplina abordou em relação ao modelo de processo de design apresentado na figura 1. 
Vamos lá!
A Unidade 1, conforme já foi dito, abordou o modelo geral do processo de design de 
sistema de software; a Unidade 2 abordou o projeto de arquitetura (padrões de projeto 
e padrões de arquitetura); a Unidade 3 refinou a abordagem do projeto de arquitetura 
(arquitetura lógica e arquitetura física), o projeto de interface (de classe, subsistema e 
componente) e o projeto de componentes. Já a Unidade 4 aborda o projeto de banco 
de dados. Desta forma, as quatro atividades de projeto (design) mencionadas na figura 1 
são contempladas nesta disciplina.
8
9
Quais são as principais atividades realizadas em um projeto (design) de banco de dados?
Inicialmente, você pode pensar na construção do esquema do banco de dados. Você 
está certo, porém essa não é a única atividade relacionada. Quando projetamosum 
banco de dados, nós pensamos também em outras atividades, como a criação de índi-
ces, a criação de visões, a permissão de direitos de acesso, o procedimento de backup 
dos dados. Isso significa que o projeto de um banco de dados vai além da construção 
do esquema do banco. Mesmo assim, esta unidade se concentra em criar o esquema do 
banco de dados. O diferencial é que o esquema será criado a partir do modelo de obje-
tos, especificamente do modelo de classes.
Para maiores detalhes sobre projeto de banco de dados, você também pode explorar o 
livro Banco de dados: projeto e implementação de Machado (2014), disponibilizado na 
Biblioteca Virtual Pearson, disponível em: https://goo.gl/g72tci
Mapeamento de Objetos
Ao utilizar tecnologias relacionadas com o paradigma orientado a objetos, principal-
mente uma linguagem de programação orientada a objetos para desenvolver sistemas de 
software, e um sistema gerenciador de banco de dados relacional para armazenamento 
físico dos dados, é necessário mapear os valores dos atributos de objetos persistentes 
para tabelas, por conta das diferenças conceituais e de tecnologia entre o modelo de ob-
jetos e o modelo relacional. É importante ressaltar que o mapeamento objeto-relacional 
não é algo exato e rígido, podendo ser adaptado de acordo com o problema em questão. 
Não é à toa que esse procedimento de transposição de objetos para tabelas é chamado 
de mapeamento.
Como é feito esse mapeamento?
O mapeamento de objetos para o modelo relacional é feito a partir do modelo de classes.
Outra forma bastante comum de criação do esquema do banco de dados é a partir do mape-
amento do Modelo Entidade-Relacionamento (MER), também conhecido como Modelo ER.
A construção do esquema do banco de dados a partir do modelo de classes é seme-
lhante ao mapeamento do modelo ER, mas não idêntico, pois o modelo de classes tem 
mais recursos do que o modelo ER. Além disso, o modelo ER é um modelo de dados, 
enquanto o modelo de classes representa objetos (dados e comportamento), sendo, por-
tanto, modelos de representação distintos.
Maiores informações sobre o Modelo ER podem ser encontradas em https://goo.gl/oOIpX3
A figura 2 mostra uma visão minimalista do mapeamento de objetos para o modelo 
relacional. Apesar dos diversos conceitos existentes em ambos os modelos, a ênfase está 
no mapeamento de classes e atributos para tabelas e colunas.
9
UNIDADE 
Mapeamento Objeto-Relacional e Camada de Persistência
Figura 2 – Visão minimalista do mapeamento de objetos para o modelo relacional
Fonte: Machado, 2014 p.233
Vamos agora mapear os objetos a partir do modelo de classes do projeto de sistema 
de software de locadora de carros abordado nas unidades anteriores?
Antes, para facilitar o entendimento, é interessante definir a forma de notação para 
representar o procedimento de mapeamento, sendo que não há uma notação universal 
para tal. O mapeamento deste material adotou as seguintes notações:
• cada relação (tabela) será representada pelo seu nome em negrito e suas colunas 
(campos) entre parênteses;
• a chave primária (primary key – PK) será representada em negrito;
• a chave estrangeira (foreign key – FK) será representada em itálico.
Para manter uma padronização nos objetos mapeados e por ser uma das melhores 
maneiras de associar identificadores a objetos mapeados para tabelas, uma coluna de 
implementação (id) é utilizada como chave primária de cada tabela, lembrando que essa 
coluna id é um identificador sem significado no domínio de negócio.
Para realizar o procedimento de mapeamento dos objetos a partir das classes do 
projeto de sistema de software de locadora de carros, vamo s utilizar como base o dia-
grama de classes de projeto apresentado na figura 3. Observe que o referido diagrama 
de classes apresenta somente classes que representam objetos persistentes, os quais o 
mapeamento tem interesse de mapear para tabelas do banco de dados relacional. Ob-
serve também que o escopo de classes foi ampliado, permitindo assim a aplicação de 
mais regras de mapeamento envolvendo classes, atributos e relacionamentos.
O procedimento mais simples é mapear cada classe como uma tabela e cada atributo como 
uma coluna, mas nem sempre há correspondência unívoca entre classes e tabelas. Quanto 
ao atributo, este pode ser mapeado para uma ou mais colunas, vai depender do contexto. ]
10
11
Figura 3 – Diagrama de classes de projeto
Font e: Elaborado pelo autor
As regras de mapeamento aplicadas no diagrama de classes do projeto de sistema 
de software de locadora de automóveis foram baseadas nos livros de Bezerra (2015), 
Machado (2014) e Waslawick (2015). É importante ressaltar que nem todas as regras 
de mapeamento apresentadas pelos referidos livros foram aplicadas nesta unidade, mas 
somente as regras necessárias para mapear o diagrama de classes de projeto da figura 
3. Tam bém é importante enfatizar que as regras de mapeamento não são rígidas, po-
dendo variar para cada situação. Isso significa que você pode encontrar diferenças no 
procedimento de mapeamento.
Vamos iniciar o mapeamento das classes relacionadas por meio de associações com 
conectividade um-para-muitos. A figura 4 mostra as classes selecionadas para este 
mapeamento. Ao realizar o mapeamento de uma relação com conectividade um-para-
-muitos, é importante verificar qual classe está com o lado muitos (*) do relacionamen-
to. Observe também o atributo idade na classe Cliente com a propriedade derivado 
(/). Atributos derivados não são mapeados, pois seus valores são derivados de outros 
atributos, havendo serventia somente em tempo de execução (na memória principal); 
os valores dos atributos derivados são transientes, não sendo relevantes para persis-
tência de dados.
Figu ra 4 – Classes relacionadas por meio de associação um-para-muitos
Fonte: Elaborado pelo autor
O resultado do mapeamento do diagrama de classes da figura 4 é apresentado no 
quadro 1. Note que cada classe foi mapeada para uma tabela e cada atributo para uma 
11
UNIDADE 
Mapeamento Objeto-Relacional e Camada de Persistência
coluna. A tabela Locação cujas linhas (registros) estão sujeitas de ocorrer diversas vezes 
é a que recebe as chaves estrangeiras correspondentes às tabelas Cliente e Carro. O 
atributo idade da Classe Cliente não foi mapeado para uma coluna da tabela Cliente por 
ser um atributo derivado.
Quadro 1 – Mapeamento das classes relacionadas por meio de associação um-para-muitos
Locacao (idLocacao, dataretirada, horaretirada, datadevolucao, horadevolucao, 
valorlocacao, idCliente, idCarro)
Cliente (idCliente, cpf, nome, email, data_nasc)
Carro (idCarro, modelo, chassi, cor, km, valordiaria)
Fonte: Elaborado pelo autor
O próximo mapeamento a ser realizado é o das classes relacionadas por meio de 
associações com conectividade muitos-para-muitos com classe associativa, também cha-
mada de classe de associação. A figura 5 mostra as classes selecionadas para este ma-
peamento. Ao realizar o mapeamento de uma relação com conectividade muitos-para-
-muitos com classe associativa, é importante notar que a classe associativa tem atributos 
associados às classes Carro e Acessório. Por exemplo, um carro pode ser locado com 
duas cadeiras de bebê e que essas cadeiras também podem ser acessórios para outros 
carros alugados, sendo necessário saber quantos itens de acessório foram contratados e 
o valor para cada um desses itens.
Figura 5 – Classes relacionadas por meio de associação muitos-para-muitos com classe associativa
F onte: Elaborado pelo autor
O resultado do mapeamento do diagrama de classes da figura 5 é apresentado no 
quadro 2. Note que cada classe foi mapeada para uma tabela e cada atributo para uma 
coluna. A classe associativa ItemAcessorio também foi mapeada para uma tabela, onde 
as colunas idCarro e idAcessorio formam uma chave primária composta e que também 
são chaves estrangeiras, fazendo referência às classes Carro e Acessório, respectivamente.
12
13
Quadro 2 – Mapeamento das classesrelacionadas por meio de 
associação muitos-para-muitos com classe associativa
Carro (idCarro, modelo, chassi, cor, km, valordiaria)
Acessorio (idAcessorio, descricao, valor)
ItemAcessorio (idCarro, idAcessorio, qtdeitem, valoritem)
Fonte: Elaborado pelo autor
O próximo mapeamento a ser realizado é o das classes relacionadas por meio de 
composição. A figura 6 mostra as classes selecionadas para este mapeamento. Vale 
lembrar que o relacionamento de composição representa uma relação todo-parte. O ma-
peamento dos relacionamentos de composição pode ser o mesmo adotado nos relacio-
namentos de associação, inclusive as conectividades. A diferença está na forma de como 
o banco de dados deve se comportar quando um registro da tabela correspondente ao 
todo deve ser excluído ou atualizado, ou seja, quando um objeto todo é excluído ou atu-
alizado, é natural excluir ou atualizar os objetos parte também.
A forma de como o banco de dados deve se comportar em relação aos registros de tabelas 
mapeadas a partir de classes relacionadas por meio de composição pode ser implemen-
tada por meio de recursos do próprio Sistema Gerenciador de Banco de Dados Relacional 
(SGBDR), tais como trigger e stored procedure.
 Figura 6 – Classes relacionadas por meio de composição
Fonte: Elaborado pelo autor
O resultado do mapeamento do diagrama de classes da figura 6 é apresentado no 
quadro 3. Note que cada classe foi mapeada para uma tabela e cada atributo para uma 
13
UNIDADE 
Mapeamento Objeto-Relacional e Camada de Persistência
coluna. Para assegurar a exclusão ou atualização dos registros das tabelas Motor e Roda 
quando algum registro da tabela Carro for excluído ou atualizado, a chave primária da 
tabela Carro também é chave primária das tabelas Motor e Roda, sendo nestas últimas 
também uma chave estrangeira que faz referência à tabela Carro.
Quadro 3 – Mapeamento das classes relacionadas por meio de composição
Carro (idCarro, modelo, chassi, cor, km, valordiaria)
Motor (idCarro, idMotor, torque, potencia, cavalos)
Roda (idCarro, idRoda, modelo, aro)
Fonte: Elaborado pelo autor
O próximo mapeamento a ser realizado é o das classes relacionadas por meio de ge-
neralização. Vale lembrar que o relacionamento de generalização representa uma relação 
de generalização/especialização (herança). A figura 7 mostra as classes selecionadas para 
este mapeamento. É importante saber que para esse tipo de relacionamento, há mais de 
uma alternativa de mapeamento, sendo que cada uma tem suas vantagens e desvantagens. 
A escolha de uma ou mais opções depende do sistema de software a ser desenvolvido e da 
equipe de desenvolvimento. De acordo com Bezerra (2015), as opções de mapeamento 
de generalização são: a) uma relação para cada classe da hierarquia; b) uma relação para 
toda a hierarquia; c) uma relação para cada classe concreta da hierarquia.
 Figura 7 – Classes relacionadas por meio de generalização
Fonte: Elaborado pelo autor
O resultado do mapeamento do diagrama de classes da figura 7 é apresentado no 
quadro 4. Note que a superclasse e cada subclasse foram mapeadas para tabelas distintas 
e cada atributo para uma coluna. Para refletir melhor o modelo de objetos, evitar pos-
síveis valores nulos e facilitar a manutenibilidade, foi escolhida a alternativa de mapear 
14
15
cada classe da hierarquia para uma relação, sendo que a chave estrangeira da tabela 
Passeio e da tabela Utilitário faz referência à chave primária da tabela Carro. Uma pos-
sível desvantagem desse mapeamento é a perda de desempenho por precisar manipular 
os relacionamentos entre as tabelas (joins), mas esse problema tende a acontecer com 
heranças profundas, ou seja, hierarquias de generalização e especialização com muitos 
níveis, o qual não é o caso do diagrama de classes mostrado na figura 7.
Quadro 4 – Mapeamento das classes relacionadas por meio de generalização
Carro (idCarro, modelo, chassi, cor, km, valordiaria)
Passeio (idCarroP, qtdelugares, idCarro)
Utilitário (idCarroU, capacidadecarga, idCarro)
Fonte: Elaborado pelo autor
Existem ferramentas que automatizam o mapeamento para a criação do banco de dados 
relacional a partir do modelo de classes. Mesmo assim, essas ferramentas não resolvem 
totalmente o problema do impedance mismatch. Além disso, nem sempre há uma ferra-
menta disponível e mesmo que haja, é importante o desenvolvedor de software ter conhe-
cimento, mesmo que básico, dos procedimentos de mapeamento.
Camada de Persistência
Além da construção do esquema de banco de dados, outros aspectos importantes e 
relacionados ao armazenamento de objetos em um banco de dados relacional devem ser 
definidos, principalmente a construção de uma camada de persistência.
O propósito de uma camada de persistência é isolar os objetos de negócio de um 
sistema de software dos detalhes de comunicação com o banco de dados. Havendo 
necessidade de alterações no esquema do banco de dados, os objetos da camada de 
negócio permanecem intactos. Se um banco de dados diferente tiver que ser utilizado 
pelo sistema de software, apenas a camada de persistência é modificada. Em síntese, a 
criação de uma camada de persistência diminui o acoplamento (dependência) entre os 
objetos de negócio da aplicação e a estrutura do banco de dados, tornando o sistema de 
software mais manutenível e portável (BEZERRA, 2015).
O padrão de projeto Data Access Object (DAO) é uma estratégia para se construir 
uma camada de persistência, pois possibilita o desacoplamento dos objetos de negócio 
 do banco de dados. 
Nessa estratégia, um sistema de software orientado a objetos obtém acesso a objetos 
de negócio através de uma interface, denominada interface DAO. As classes que imple-
mentam essa interface transformam informações provenientes do mecanismo de arma-
zenamento em objetos de negócio e vice-versa. Nesse caso, o sistema de software se co-
munica com o objeto DAO através de uma interface, sendo que a implementação desse 
objeto não faz diferença para a aplicação, já que o objeto DAO isola completamente os 
15
UNIDADE 
Mapeamento Objeto-Relacional e Camada de Persistência
objetos consumidores da aplicação dos mecanismos de armazenamento físico de dados. 
(BEZERRA, 2015)
A figura 8 mostra a estrutura do padrão de projeto para persistência de Dados DAO. 
Observe alguns aspectos interessantes nessa figura: a RegiãoCliente representa o con-
junto de objetos consumidores que se comunica com o objeto DAO através da interface; 
a classe DAO está encapsulada por trás da interface; a classe DAO precisa conhecer a 
estrutura da ClasseEntidade para poder restaurar, atualizar ou excluir o objeto modelo 
em questão; a fonte de dados está sendo acessada e manipulada por meio da classe 
DAO. Em suma, os objetos de negócio da aplicação estão isolados do banco de dados 
utilizado pela aplicação, devido à construção de uma camada de persistência de dados.
 Figura 8 – Estrutura do padrão DAO
Fonte: Bezerra, 2015 p. 384
Maiores informações sobre o padrão de projeto DAO podem ser encontradas em 
https://goo.gl/fLWfR5 e em https://goo.gl/8JWF
Para facilitar a compreensão da representação da camada de persistência de dados, o 
diagrama de pacotes da figura 9 exibe um subsistema (pacote) DAO com as classes DAO 
alocadas nele. Para cada classe que representa um objeto de negócio (objeto modelo) do 
projeto de sistema de software de locadora de carros, foi criada uma classe DAO. Essa 
figura representa o subsistema DAO em uma arquitetura lógica.
Figura 9 – Subsistema (Pacote) DAO
Fonte: Elaborado pelo autor
16
17
A camada de persistência de dados também pode ser representada no diagrama de 
implantação, conforme mostra a figura 10. O componente de persistência é represen-
tado em um nó de processamento referente à camada de dados. Essa figura representa 
o subsistema DAO em uma arquitetura física, denominado componente de persistência. 
Observe que esse componente representa uma camada intermediária entre o servidor 
de aplicação e o banco de dados, isolandoos componentes da aplicação onde se en-
contram os objetos de negócio do Sistema Gerenciador de Banco de Dados (SGBDR).
Figura 10 – Diagrama de implantação com alocação do componente de persistência
Fonte: Elaborado pelo autor
Na plataforma Java, há um framework para mapeamento objeto-relacional chamado 
Hibernate. Na plataforma Microsoft, esse framework se chama NHibernate. Maiores infor-
mações sobre o framework Hibernate podem ser encontradas em https://goo.gl/aHFndK e 
em https://goo.gl/1zbDsG
Este material teórico aplicou algumas regras de mapeamento de objetos para o modelo 
relacional. Vale lembrar que nem todas as regras de mapeamento foram aplicadas nesta 
unidade, mas somente as regras necessárias para mapear o diagrama de classes do projeto 
de sistema de software de locadora de carros. Também é importante enfatizar que as re-
gras de mapeamento não são exatas nem rígidas, podendo variar para cada situação. Isso 
significa que você pode se deparar com o procedimento de mapeamento objeto-relacional 
realizado de formas diferentes. De qualquer forma, é importante você buscar maiores in-
formações sobre o tema nas referências utilizadas e no material complementar. 
Eu encerro esta disciplina por aqui. Muito obrigado pela sua atenção!
17
UNIDADE 
Mapeamento Objeto-Relacional e Camada de Persistência
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Sites
Hibernate
https://goo.gl/1zbDsG
Biblioteca virtual Cruzeiro do Sul
https://goo.gl/g72tci
Oracle
https://goo.gl/8JWF
 Leitura
Object-relational impedance mismatch
https://goo.gl/53lSls
Hibernate
https://goo.gl/aHFndK
Objeto de acesso a dados
https://goo.gl/fLWfR5
18
19
Referências
BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. 3. ed. São 
Paulo: Elsevier, 2015.
MACHADO, F. N. R. Banco de dados: projeto e implementação. 3. ed. São Paulo: 
Érica, 2014.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
WASLAWICK, R. S.; Análise e design orientados a objetos para sistemas de 
informação: modelagem com UML, OCL e IFML. 3. ed. Rio de Janeiro: Campus 
Elsevier, 2015. 
19