ORM, JPA, Hibernate, JDBC, JPQL, DDL, DML e DQL: descomplicando a sopa de letrinhas do Java

Neste post, vamos destrinchar essa famosa “sopa de letrinhas” do mundo Java: ORM, JPA, Hibernate, JDBC, JPQL, DDL, DML e DQL. A ideia é explicar, de forma direta, o que cada sigla significa, como se relacionam entre si e onde entram no dia a dia de desenvolvimento.

Começando por ORM (Object-Relational Mapping): trata-se de um conceito que define como converter dados entre o modelo de objetos de uma linguagem orientada a objetos e o modelo relacional de um banco de dados. Em outras palavras, o ORM faz a ponte entre classes e tabelas. ORM não é algo exclusivo de Java: cada linguagem costuma ter seus próprios frameworks, como Java (Hibernate, EclipseLink), .NET (Entity Framework) e Python (SQLAlchemy).

Já a JPA (Java Persistence API) é a especificação padrão de como fazer ORM no ecossistema Java. Ela define a “contrato”, como mapear entidades, como funcionam operações de persistência, consultas, transações e assim por diante. Para que isso tudo rode de verdade, precisamos de uma implementação dessa especificação, como o Hibernate, que é o framework concreto responsável por executar o que a especificação define como se fosse a relação entre uma interface e sua implementação. Um ponto importante: hoje o nome oficial da especificação é Jakarta Persistence; o termo “JPA” ficou associado às versões mantidas pela Oracle e não é mais usado para as versões open da comunidade.

Até aqui, podemos resumir assim: ORM é o conceito; Jakarta Persistence (antiga JPA) é a especificação de ORM no mundo Java; e o Hibernate é o framework ORM que implementa essa especificação.

Agora, entrando em JDBC (Java Database Connectivity). O JDBC é a API de baixo nível do Java para conversar com o banco de dados: abrir conexão, preparar e executar SQL, tratar resultados, entre outras operações. Todo framework ORM em Java usa JDBC por baixo; o ORM não substitui o JDBC, ele o abstrai. Com JDBC puro, é possível controlar diretamente as conexões e os comandos SQL, mas isso também aumenta o risco de problemas como múltiplas conexões abertas sem necessidade, falhas de tratamento de erros ou vulnerabilidades como SQL injection, se o código não for bem cuidado. Por isso, o uso de JDBC puro costuma ficar restrito a cenários em que controle fino e desempenho máximo são essenciais.

Com isso em mente, fica mais fácil visualizar a pilha: quando usamos Jakarta Persistence com o Hibernate como implementação, o framework cuida das entidades e consultas em nível de objeto e, por baixo dos panos, utiliza JDBC para se conectar ao banco de dados e executar os comandos SQL.

Falando agora das ações no banco de dados, entramos nas siglas DDL, DML e DQL.

• DDL (Data Definition Language) é o conjunto de comandos usados para definir ou alterar estruturas, como CREATE TABLE e ALTER TABLE.




• DML (Data Manipulation Language) cuida da manipulação de dados, com comandos como INSERT, UPDATE e DELETE.




• DQL (Data Query Language) é focada em consultas de dados, basicamente o SELECT.

No cotidiano de uma aplicação, usamos essas linguagens o tempo todo, mesmo sem perceber. Por exemplo: ao subir uma aplicação que cria as tabelas no banco, estamos executando DDL. Quando a aplicação recebe uma requisição POST e grava os dados em uma tabela, isso envolve DML. E quando chega um GET para buscar informações, é executada uma consulta DQL. Essas coisas acontecem automaticamente via framework, mas é importante saber o nome e o papel de cada tipo de comando.

Por fim, temos o JPQL (Java Persistence Query Language). Ela é a linguagem de consultas orientadas a objetos definida pela especificação JPA/Jakarta Persistence. Em vez de trabalhar diretamente com tabelas e colunas, o JPQL opera sobre classes e atributos, o que ajuda a abstrair o banco de dados. Quando usamos Jakarta Persistence em conjunto com o Hibernate, as consultas JPQL são traduzidas para SQL (normalmente DQL) e executadas via JDBC no banco de dados.

A tabela foi criada para que seja mais claro e objetivo a função de cada item que foi mencionado.

Para tornar mais claro o entendimento no cotidiano do trabalho foi criado um fluxo para melhor entendimento em cada etapa da relação do Java com banco de dados.