DESENVOLVIMENTO WEB

E WEB SERVICES

Profa. Francielli Barbara Pinto

 Unidade 03

Camada de dados:
ORM e persistência
Sumário
Camada de Dados: ORM e persistência...............................................................................................3
1.1 Padrão ORM (Object-Relational Mapping)...................................................................................3
1.1.1 Mapeamento Relacional..............................................................................................................4
1.1.1.1 Mapeando os relacionamentos entre as entidades....................................................................6 25
1.1.1.1.1 Relacionamentos 1:n.............................................................................................................6
1.1.1.1.2 Relacionamentos 1:1.............................................................................................................7
1.1.1.1.3 Relacionamentos n:n.............................................................................................................9
1.1.2 Mapeamento Objeto-Relacional (ORM)....................................................................................10
1.2 Hibernate e JPA............................................................................................................................10
1.2.1 Hibernate e JPA em projetos Spring Boot.................................................................................11
Atividade............................................................................................................................................21
Referências.........................................................................................................................................22
CAMADA DE DADOS: ORM E PERSISTÊNCIA

A forma em que os dados de um sistema são armazenados em um banco de dados relacional

se difere bastante da forma em que são manipulados na aplicação via linguagem orientada a objetos
25
– na aplicação temos objetos com atributos e métodos, enquanto que no banco de dados temos
tabelas, colunas e tuplas.
O resultado disso é a integração entre aplicação e banco de dados, o que, muitas vezes,
envolve a escrita de códigos SQL em meio a códigos em linguagem utilizada para desenvolver
a aplicação, tendendo a consumir um tempo expressivo do desenvolvimento, é suscetível a erros e
dificulta a manutenção e migração de um Sistema Gerenciador de Banco de Dados (SGBD) a outro
– no “universo Java” esse é o problema que se tem quando se utiliza apenas JDBC.
Tendo em vista isso, esforços foram concentrados na tentativa de melhorar tal integração e,
neste contexto, destaca-se o padrão ORM e as tecnologias que o implementam, uma vez que ORM
visa justamente resolver esse problema. Precisamos então, primeiramente, entender o que é o
padrão ORM.

1.1 Padrão ORM (Object-Rela onal Mapping)

ORM é a sigla para Object-Relational Mapping, cuja tradução para português é

Mapeamento Objeto-Relacional. Quando falamos em Mapeamento Objeto-Relacional, podemos
relacionar esse termo ao mapeamento relacional, que muitas vezes aprendemos em disciplinas de
Banco de Dados e consiste em gerar as tabelas do banco de dados, ou a representação dessas tabelas
por meio de um diagrama, conhecido como Modelo Relacional, a partir da especificação das
entidades do sistema e seus relacionamentos, que, no “universo de Banco de Dados”, são
representados em um diagrama Entidade-Relacionamento (ER).
ORM realmente se assemelha a esse mapeamento relacional, porém, em ORM, as tabelas
do banco de dados são geradas/mapeadas a partir da definição das classes do sistema.
Mais especificamente, ORM relaciona classes e tabelas de modo que a diferença entre a
forma que os dados de uma aplicação são manipulados na aplicação e no banco de dados, citada
anteriormente, seja abstraída do programador. ORM faz então os seguintes mapeamentos:
tabela ↔ classe;
coluna ↔ atributo;
registro ↔ objeto. 25
ORM é um padrão de projeto que visa, portanto, abstrair ao máximo do desenvolvedor a
camada de dados da aplicação. Na prática, não será necessária, por exemplo, a escrita de códigos
SQL em meio ao código-fonte da aplicação.
Como ORM se assemelha ao Mapeamento Relacional, para um melhor entendimento,
vejamos como se dá esse Mapeamento Relacional.

1.1.1 Mapeamento Relacional

No Mapeamento Relacional, de um modo geral, as tabelas do banco de dados são

geradas/mapeadas a partir do Modelo Entidade-Relacionamento (ER) seguindo algumas regras
gerais, as quais citaremos aqui.
Como exemplo, considere um possível Modelo ER para um sistema de compras online,
apresentado a seguir:
 Figura 1 - Modelo Entidade-Relacionamento (ER) de um sistema de compras Online
Fonte: autora

25

As tabelas do banco de dados deste sistema podem então ser definidas seguindo-se as
seguintes regras:
1. Para cada entidade, é criada uma tabela correspondente, seguindo algumas
regras de nomenclatura – para a entidade Produto, será criada a tabela produto; para
a entidade Usuario será criada a tabela usuario; para a entidade OrdemDeCompra
será criada a tabela ordem_de_compra e, para a entidade Item, será criada a tabela
item;
2. Para cada atributo de cada entidade, é criada uma coluna na tabela
correspondente (falaremos sobre os tipos de dados mais à frente), seguindo-se
também um padrão de nomenclatura – será criada, por exemplo, na tabela
ordem_de_compra, a coluna data_da_compra;
3. Cada tabela deve ter uma chave primária. No exemplo demonstrado a seguir, foi
criada uma chave primária para cada tabela, de nome id;
4. Por último, é feito o mapeamento dos relacionamentos entre as entidades,
conforme tipo e cardinalidade do relacionamento, o que veremos na subseção a
seguir.
1.1.1.1 Mapeando os relacionamentos entre as en'dades

Como mencionado acima, os relacionamentos entre as entidades são mapeados conforme

tipo e cardinalidade dos mesmos. Considerando o exemplo do sistema de compras online,
25
abordaremos inicialmente somente o mapeamento quanto à cardinalidade dos relacionamentos.

1.1.1.1.1 Relacionamentos 1:n

Analisando o Modelo ER apresentado na Figura 1, identificamos que todos os

relacionamentos são 1:n (lê-se “um para n”) – uma OrdemDeCompra é criada por um Usuario (1) e
um Usuario cria nenhuma ou muitas OrdemDeCompra (n); uma OrdemDeCompra tem um ou
muitos Item (n) e um Item está relacionado a uma única OrdemDeCompra (1); por fim, um Item
possui um Produto (1) e um Produto está relacionado a nenhum ou muitos Item (n).
Mapear um relacionamento do modelo conceitual – Modelo ER – para o modelo lógico
relacional – que representa as tabelas do banco de dados –, implica, a grosso modo, fazer com que
as tabelas se relacionem de alguma forma no banco de dados e isso é feito através das chaves
estrangeiras, em que uma tabela referencia – ou faz referência a – uma coluna de outra tabela.
Em um relacionamento 1:n, a tabela que possui relação “n” com a outra tabela irá receber
uma chave estrangeira referenciando a chave primária da outra tabela. Ou seja, no relacionamento
entre OrdemDeCompra e Usuario, a tabela ordem_de_compra possui relação “n” com a tabela
usuario, uma vez que um Usuario pode criar n OrdemDeCompra, e, portanto, a tabela
ordem_de_compra irá receber uma chave estrangeira (que foi nomeada de usuario_id no exemplo
apresentado a seguir) referenciando o id da tabela usuario; no relacionamento entre Item e Produto,
a tabela item (relação “n”) irá receber uma chave estrangeira (produto_id) referenciando o id da
tabla produto; e no relacionamento entre Item e OrdemDeCompra, novamente a tabela item
(relação “n”) irá receber uma chave estrangeira (ordem_de_compra_id) referenciando o id da tabela
ordem_de_compra.
Dessa forma, o Modelo Relacional do sistema de compras online resultante do Mapeamento
Relacional ficará conforme demonstrado a seguir:

Figura 2 - Modelo Relacional do sistema de compras online resultando do Mapeamento Relacional

Fonte: autora

25

1.1.1.1.2 Relacionamentos 1:1

Como no exemplo do nosso sistema de compras online não há nenhum relacionamento 1:1
(lê-se um para um), consideremos o exemplo a seguir:
 Figura 3 - Relacionamento 1:1 exemplo: Modelo ER
Fonte: autora

25

Esse Modelo ER exemplo nos diz que um Servidor dirige nenhum ou um Campus (1) e um
Campus é dirigido por um Servidor (1). Temos, portanto, um relacionamento 1:1.
Em um relacionamento 1:1, escolhe-se uma das tabelas para receber uma chave estrangeira
que referenciará uma coluna da outra tabela. Nesse caso, então, tanto faz se servidor receber uma
chave estrangeira ou se campus receber. Contudo, como no exemplo Campus obrigatoriamente
deve ser dirigido por um Servidor e nem todo Servidor irá dirigir um Campus, escolheremos a
tabela campus para receber a chave estrangeira.
O Modelo Relacional resultante, portanto, ficaria como demostrado abaixo:

Figura 4 - Relacionamento 1:1 exemplo: Modelo Relacional

Fonte: autora
1.1.1.1.3 Relacionamentos n:n

Para o mapeamento de um relacionamento n:n (lê-se n para n), consideremos o seguinte

exemplo:

25
Figura 5 - Relacionamento n:n exemplo: Modelo ER
Fonte: autora

O Modelo ER exemplo nos diz que uma Conta pertence a um ou muitos Cliente (n) e um
Cliente possui nenhuma ou muitas Conta (n). Temos, então, um relacionamento n:n.
Para mapear um relacionamento n:n, uma outra tabela é então definida, chamada de tabela
de relacionamento. Essa tabela irá conter duas chaves estrangeiras, cada uma referenciando a
chave primária de cada uma das tabelas do relacionamento.
O Modelo Relacional ficaria, portanto, conforme demonstrado abaixo:

Figura 6 - Relacionamento n:n exemplo: Modelo Relacional

Fonte: autora
1.1.2 Mapeamento Objeto-Relacional (ORM)

Vejamos agora, portanto, como ocorre o Mapeamento Objeto-Relacional (ORM). Nesse

mapeamento, a geração das tabelas do banco de dados é feita seguindo-se as regras citadas
anteriormente, porém a partir da definição das classes do sistema e não do Modelo ER. Temos então
25
as seguintes regras:
Para cada classe uma tabela associada é gerada;
Para cada atributo da classe, uma coluna na tabela correspondente é criada. O
tipo da coluna a ser criada é definido de acordo com o tipo do atributo da classe –
por exemplo, para um atributo do tipo String, é gerada uma coluna de tipo VARCHAR.
Os relacionamentos entre as classes também são mapeados conforme as regras
citadas na seção anterior.
É feita, portanto, uma associação entre classe e tabela e entre atributo e coluna.
Existem, portanto, diversas tecnologias que implementam o padrão ORM. Em Java, as mais
populares são Hibernate e EclipseLink. Na próxima seção falaremos sobre Hibernate.

1.2 Hibernate e JPA

Hibernate é um framework Java que implementa o padrão ORM. Em termos práticos,

com a utilização de Hibernate, as tabelas do banco de dados são geradas a partir de configurações
feitas pelo desenvolvedor e operações CRUD (Create-Read-Update-Delete) são executadas
simplesmente a partir de chamadas a métodos da API do Hibernate – veja que não é necessário,
portanto, a escrita de códigos SQL em meio a códigos Java, o que traz ganhos significativos de
produtividade e evita erros. Mas vale destacar também que, caso o desenvolvedor queira ou precise
manipular queries em SQL – isso talvez seja necessário, se tratando, por exemplo, de operações não
suportadas pelo Hibernate ou quando o programador precisa otimizar determinadas buscas –, o
framework permite que isso seja feito.
JPA, por sua vez, é a sigla para Java Persistence API. O objetivo de JPA é padronizar as
interfaces dessas tecnologias Java que implementam o padrão ORM, de forma que todas elas
utilizem as mesmas interfaces (especificação de nome de método, tipo de retorno e parâmetros, por
exemplo). Isso é útil quando, por exemplo, se deseja trocar a tecnologia que estiver sendo utilizada
no projeto – utiliza-se Hibernate e deseja-se passar a utilizar EclipseLink, por exemplo.
JPA trata-se, portanto, de uma especificação e toda implementação ORM para Java deve
seguir a especificação JPA. Então, para que seja possível alternar entre tecnologias sem impactar a 25
implementação da aplicação, para ser genérico, deve-se utilizar todos os pacotes JPA na
implementação da aplicação – e não as do Hibernate diretamente, por exemplo.

1.2.1 Hibernate e JPA em projetos Spring Boot

Para se utilizar Hibernate e JPA em projetos Spring Boot, deve-se seguir um conjunto de
quatro passos que serão descritos a seguir.
1o passo: incluir nas dependências do projeto o Spring Data JPA e o Driver JDBC do SGBD
a ser utilizado – no exemplo, utilizaremos MySQL, então incluiremos no projeto a dependência
MySQL Driver. Para isso, realize os seguintes passos:
i. Abra o arquivo build.gradle, localizado na pasta raiz do projeto;
ii. Em "dependencies", adicionaremos a dependência Spring Data JPA, que é
necessária em tempo de implementação (“implementation”), e a dependência
MySQL Driver, que é necessária em tempo de execução (runtime), acrescentando as
instruções abaixo:
implementa'on 'org.springframework.boot:spring-boot-starter-data-jpa'
run'meOnly 'mysql:mysql-connector-java'
2o passo: configurar os parâmetros para conexão com o banco de dados (BD) – antes de
realizar esse passo, é necessário ter criado um banco de dados que irá receber as tabelas geradas
pelo Hibernate e, posteriormente, os dados da aplicação – isso pode ser feito utilizando-se o
MySQL Workbench. Para configuração dos parâmetros para conexão com o BD, siga os seguintes
passos:
i. Abra o arquivo application.properties, localizado na pasta do projeto
src/main/resources;
ii. Devemos indicar neste arquivo:
a) O modo de criação das tabelas, que irá determinar a estratégia adotada pelo
Hibernate para geração das tabelas do banco de dados durante o
desenvolvimento e que pode ser um dentre os seguintes modos:
create – quando a aplicação for iniciada, as tabelas do banco de dados 25
serão criadas, caso não existam;
create-drop – quando a aplicação for iniciada, as tabelas serão
criadas, caso não existam, e, ao ser finalizada, as tabelas do banco de
dados serão excluídas (é recomendado que esse modo não seja
utilizado em ambiente de produção);
update – semelhante ao modo create, porém verifica-se também se há
a necessidade de criação de novas colunas nas tabelas (esse modo é o
mais recomendado para ambiente de desenvolvimento);
none – nenhuma alteração no banco de dados é feita. Esse é o valor
default e, portanto, assumido caso não seja especificado
Em ambiente de desenvolvimento, é comum utilizar o modo update. Para isso,
deve-se incluir no arquivo application.properties a seguinte definição:
spring.jpa.hibernate.ddl-auto=update
b) A URL para conexão com o banco de dados. Adicionaremos então ao
arquivo application.properties, a declaração – considerando que o banco de
dados criado tem nome telefonia e que o servidor de banco de dados esteja em
execução na máquina local, porta 3306:
spring.datasource.url=jdbc:mysql://localhost:3306/telefonia
c) Usuário e senha para acesso ao banco de dados. Adicionaremos, também
em application.properties, a declaração – considerando que o nome do usuário
é adminTel e a senha é 1234telAdmin:
spring.datasource.username=adminTel
spring.datasource.password=1234telAdmin
 d) O nome do driver JDBC para conexão com o banco de dados (mesmo
utilizando JPA, o driver JDBC é necessário, pois toda implementação de ORM
utiliza internamente JDBC). Adicionaremos, também em
application.properties, a declaração – considerando que estamos utilizando o
SGBD MySQL: 25
spring.datasource.driver-class-name = com.mysql.jdbc.Driver
3o passo: mapear as classes que implementam as entidades do sistema, conforme as etapas
descritas a seguir:
i. Para cada classe, adicionar um @En'ty acima da declaração da classe, conforme
demonstrado no exemplo abaixo, indicando para o Hibernate que se trata de uma
entidade do sistema e que ele deverá mapear uma tabela correspondente – para isso,
é necessário importar a classe javax.persistence.En'ty:
import javax.persistence.En'ty;

@En'ty
public class Plano{

}
ii. Indicar para qual atributo da classe será criada uma chave estrangeira. Neste caso, a
estratégia mais adotada é criar, para cada classe, um atributo inteiro id e deve-se,
então, adicionar a esse atributo a anotação @Id. Caso queira que esse id seja gerado
automaticamente, adicionar a anotação
@GeneratedValue(strategy=Genera'onType.AUTO), conforme exemplo abaixo –
para isso, é necessário importar as classes javax.persistence.GeneratedValue,
javax.persistence.Genera'onType e javax.persistence.Id:
public class Plano{
@Id
@GeneratedValue(strategy=Genera'onType.AUTO)
 private long id;
}
iii. Para os atributos dos tipos Date ou Calendar é necessário ainda adicionar a anotação
@Temporal, especificando que se trata de um dado temporal, e especificando ainda
um dos três tipos temporais: 25
a) TemporalType.DATE – quando se deseja armazenar somente a data;
b) TemporalType.TIME – quando se deseja armazenar somente a hora;
c) TemporalType.TIMESTAMP – quando se deseja armazenar data e hora.
Exemplo:
public class Ligacao{
@Temporal(TemporalType.TIMESTAMP)
private Date data;
}
iv. Outras anotações podem ser usadas para especificar configurações diferentes das
default, como, por exemplo, nome de tabela, nome de coluna, etc – confira exemplos
em https://www.baeldung.com/jpa-entities.
4o passo: mapear os relacionamentos entre as classes. O mapeamento deve ser feito
conforme cardinalidade e se o relacionamento é uni ou bidirecional. Relacionamentos de herança
também deverão ter um tratamento especial. Portanto, em resumo, o que se faz é analisar as
características do relacionamento para determinar quais alterações deverão ser feitas nas classes que
implementam as entidades envolvidas no relacionamento, conforme é listado a seguir:
i. Para relacionamentos um-para-muitos (1:n ou one-to-many):
a) Se o relacionamento é unidirecional:
Na entidade correspondente ao todo do relacionamento, no atributo cujo
tipo é correspondente à parte do relacionamento, adicionaremos a
anotação @OneToMany, conforme exemplo apresentado a seguir;
É necessário também informar que deve ser criada uma chave
estrangeira na tabela correspondente à parte do relacionamento (relação
 n) – do contrário, o Hibernate irá gerar uma tabela de relacionamentos,
o que não é necessário. A tabela de relacionamentos é necessária
somente em relacionamentos n:n. Para isso, adiciona-se ao mesmo
atributo citado anteriormente a anotação
@JoinColumn(name="nome_da_classe_id"). 25
Exemplo:
@En'ty
public class Operadora{
@OneToMany
@JoinColumn(name="operadora_id")
Set<Plano> planos;
}
b) Se o relacionamento é bidirecional:
Na classe correspondente à parte do relacionamento, adicionaremos a
anotação @ManyToOne – com isso, uma chave estrangeira será criada
na tabela correspondente;
Exemplo: considere como exemplo um relacionamento bidirecional 1:n
entre Cliente-Endereco, onde Cliente possui n Endereços, um Endereço
pertence a um Cliente e Cliente é o todo do relacionamento:
@En'ty
public class Endereco{
@ManyToOne
Cliente cliente;
}
Já na classe correspondente ao todo do relacionamento, adicionaremos
a anotação @OneToMany e especificaremos que o relacionamento está
sendo mapeado através da chave estrangeira
(mappedBy=nome_do_atributo_correspondente), conforme exemplo
 apresentado abaixo:
@En'ty
public class Cliente{
@OneToMany(mappedBy="cliente")
Set<Endereco> enderecos; 25
}
ii. Para relacionamentos muitos-para-um (n:1 ou many-to-one):
a) Se o relacionamento é unidirecional:
Deve-se adicionar, na classe correspondente ao todo do relacionamento,
no atributo cujo tipo é correspondente à parte do relacionamento, a
anotação @ManyToOne:
Exemplo: considere, como exemplo, que Endereco esteja relacionado a um
Cliente e Cliente pode estar relacionado a n Endereços, porém desconheça
seus Endereços – o todo do relacionamento, neste caso, é Endereco e não
Cliente:
@En'ty
public class Endereco{
@ManyToOne
Cliente cliente;
}
b) Se o relacionamento é bidirecional: é semelhante ao relacionamento um-para-
muitos bidirecional.
iii. Para relacionamentos muitos-para-muitos (n:n ou many-to-many):
a) Se o relacionamento é unidirecional:
Deve-se adicionar, na classe correspondente ao todo do relacionamento, ao
atributo cujo tipo é correspondente à parte do relacionamento, a anotação
@ManyToMany:
Exemplo: considere como exemplo o relacionamento entre Conta-Cliente, em
 que uma Conta pode estar relacionada a muitos Clientes, um Cliente pode
estar relacionado a muitas Contas, Conta é o todo do relacionamento e Cliente
desconhece suas Contas (relacionamento unidirecional):
@En'ty
public class Conta{ 25
@ManyToMany
Set<Cliente> clientes;
}
b) Se o relacionamento é bidirecional:
Ambas as classes do relacionamento receberão, em seus atributos
correspondentes, a anotação @ManyToMany a, na classe correspondente à
parte do relacionamento, indicar um mappedBy, conforme exemplo
apresentado abaixo:
Exemplo: considerando o exemplo anterior, considere agora que Cliente
conhece suas Contas (relacionamento bidirecional). Temos, portanto:
@En'ty @En'ty
public class Conta{ public class Cliente{
@ManyToMany @ManyToMany(mappedBy = "clientes")
Set<Cliente> clientes; Set<Conta> contas;
} }

iv. Para relacionamentos um-para-um (1:1 ou one-to-one):

a) Se o relacionamento é unidirecional:
Adiciona-se a anotação @OneToOne ao atributo cujo tipo é
correspondente à parte do relacionamento na classe correspondente ao
todo do relacionamento:
Exemplo: considere como exemplo o relacionamento Campus-Servidor, em
que um Campus é dirigido por um Servidor e um Servidor pode dirigir um
Campus, porém desconhece o Campus ao qual dirige (relacionamento
unidirecional):
 @En'ty
public class Campus{
@OneToOne
Servidor diretor;
} 25
b) Se o relacionamento é bidirecional:
Semelhante aos outros relacionamentos bidirecionais descritos, ambas as
classes terão um @OneToOne em seus atributos correspondentes e a classe
correspondente à parte do relacionamento deverá indicar um mappedBy,
conforme exemplo apresentado abaixo:
Exemplo: considere o exemplo anterior, porém considere agora que Servidor
conhece o Campus ao qual dirige (relacionamento bidirecional). Temos então:
@En'ty @En'ty
public class Campus{ public class Servidor{
@OneToOne @OneToOne(mappedBy = "diretor")
Servidor diretor; Campus campusDirigido;
} }
v. Para relacionamentos de herança:
Existem algumas estratégias de mapeamento. Aqui, demonstraremos a que é
conhecida como single table (tabela única), em que uma única tabela é gerada
para todas as classes com uma superclasse em comum. Para essa tabela, será
gerada uma coluna correspondente a cada atributo da superclasse e uma coluna
correspondente a cada atributo das subclasses, além de uma coluna
“descriminatória” para determinar a qual entidade “pertence” cada registro –
informações sobre outras estratégias podem ser encontradas em
https://www.baeldung.com/hibernate-inheritance;
A fim de implementar esse mapeamento, devemos adicionar na superclasse as
anotações @Inheritance(strategy = InheritanceType.SINGLE_TABLE) – aqui
estamos definindo a estratégia de mapeamento – e @DiscriminatorColumn(name
= "nome_da_coluna") – estamos definindo o nome a ser dado para a coluna
“descriminatória” – conforme exemplo a seguir:
@En'ty
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "class")
public class Cliente{ 25

}
E, nas subclasses, devemos adicionar a anotação
@DiscriminatorValue(value="nome_do_valor_dado_a_registros_da_en'dade"),
determinando assim qual o valor para a coluna descriminatória os registros
daquela classe terão. Exemplos:
@En'ty
@DiscriminatorValue(value="ClientePessoaFisica")
public class ClientePessoaFisica{

@En'ty
@DiscriminatorValue(value="ClientePessoaJuridica")
public class ClientePessoaJuricica{

}
Considerando, portanto, os exemplos apresentados, uma única tabela será criada
para as classes Cliente, ClientePessoaFisica e ClientePessoaJuridica. Essa
tabela conterá uma coluna para cada atributo da classe Cliente, uma coluna para
cada atributo definido em ClientePessoaFisica, uma coluna para cada atributo
definido em ClientePessoaJuridica e uma coluna “descriminatória” de nome
class. Registros de ClientePessoaFisica serão armazenados guardando-se em
class o valor ClientePessoaFisica e registros de ClientePessoaJuridica serão
armazenados guardando-se em class o valor ClientePessoaJuridica. Dessa forma,
todos os registros de ClientePessoaFisica, por exemplo, podem ser obtidos a
partir da execução da query SELECT * FROM cliente WHERE class =
‘ClientePessoaFisica’. 25
 A'vidade

1) Instale o MySQL, caso não o tenha feito ainda.

2) Crie o bando de dados telefonia. 25

3) Faça as configurações no projeto e o mapeamento das entidades do sistema Telefonia para

Hibernate, conforme os quatro passos descrição deste material, na subseção 1.2.1.

4) Rode a aplicação. Ao término da execução da aplicação, caso você tenha feito as configurações e
implementações corretamente, você deverá observar que algumas tabelas são geradas pelo
Hibernate (no banco de dados telefonia), conforme Mapeamento Objeto-Relacional descrito neste
material. Analise cada uma das tabelas geradas.
REFERÊNCIAS

RICHARDSON, Chris. ORM in dynamic languages. Queue, v. 6, n. 3, p. 28-37, 2008.

WEBB, Phillip et al. Spring boot reference guide. Spring Boot features, v. 24, 2013.

WEISSMAN, Henrique Lobo. Falando de Grails: altíssima produtividade no desenvolvimento 25

Web. Casa do Código, 2014.