[JPA] 탄생 배경 - SQL 에 의존적인 개발에서 벗어나자

 예전 Java 개발자들은 데이터베이스에 접근해서 데이터를 가져오기 위해 직접 SQL문을 짰었습니다. 지금도 JPA 대신 JdbcTemplate 을 사용해보면, 얼마나 소모적인 작업인지 알 수 있습니다. 그래서 이 때에 많은 개발자들은 테이블을 객체로 매핑시켜주는 라이브러리 혹은 프레임워크를 개발하기 위해 많은 노력을 들였다고 합니다. 그럼 저희가 그 때 당시의 개발자라고 생각해보면서 먼저 객체와 테이블 간의 차이에 대해 정리해보겠습니다.

 

[ 객체와 관계형 데이터베이스 간의 차이 ]

 두 가지가 다르다는 것을 확인시켜주는 중요한 2가지 개념이 존재합니다. 

상속

 첫 번째로는 '상속' 개념입니다. 객체에는 상속을 할 수 있지만, 관계형 데이터베이스 테이블(이하 '테이블'이라고 칭함)에는 슈퍼타입 서브타입이 존재한다. 하지만 테이블로 데이터를 삽입하기 위해선, SQL 두 개를 작성해야 한다. 

Table의 슈퍼타입 서브타입

 즉, Album 테이블에 데이터를 넣기 위해선 Item 테이블에 먼저 튜플을 삽입하고 그 이후, Album에 튜플을 삽입해야 한다. 그뿐만이 아니라, 테이블로 조회할 때에도 문제가 된다. 각각의 테이블에 맞는 조인 SQL을 작성해야 한다. 

 하지만, 만약 객체로 Album을 삽입 / 조회한다면? 매우 간편해진다! 뿐만 아니라, 부모 타입 객체로 '다형성'도 활용할 수 있다는 큰 장점이 존재한다. 

 

연관관계

 연관관계를 가질 때, 객체는 참조를 사용하고, 테이블은 외래 키(FK : Foreign key)를 사용한다. 객체에 대해 먼저 살펴보겠습니다. 

객체의 연관관계

 객체의 경우, Member에서 Team을 조회할 수 있지만, Team에서 Member를 조회할 순 없다. 하지만, 테이블에서는 외래 키와 PK 를 사용해서 Member에서도 Team을 조회할 수 있고, Team에서도 Member를 조회할 수 있게 된다. 즉, 테이블은 양방향으로 조회할 수 있지만 객체에서는 단방향으로만 조회를 할 수 있다. 그래서 객체로 연관관계 설정을 해주기 위해선, Member 객체를 만들고, 해당 member가 속할 Team 객체를 만들어주기 까지 해야한다. 2가지 테이블만 사용되었는데 프로세스가 조금 복잡해진다.

 

객체 그래프 탐색

 객체는 그래프처럼 탐색할 수 있어야 한다. 즉, member.getOrder().getDelivery() 나 member.getTeam() 함수 모두 제대로 실행이 되어야 한다. 하지만, SQL의 경우에는 실행 시점에서의 SQL문에 의해 조회범위를 정하게 되므로, member 테이블과 team 테이블을 조인해서 조회했다면 Order, Delivery에 대한 정보는 조회할 수 없게 된다.

 

결론

 이렇기에 이전의 Java 개발자들은 객체 형태로 관계형 데이터베이스 테이블을 다룰 수 있는 프레임워크를 만들게 됩니다. 즉, 관계형 데이터베이스는 관계형 데이터베이스에 맞게 설계하고 객체는 객체답게 설계를 해도 중간에서 매핑해주는 작업을 ORM 프레임워크가 해주는 것입니다. Java 에서 대표적인 ORM 기술로 JPA 가 존재합니다.

• Java 뿐만이 아니라, 대중적인 언어들에서는 대부분 ORM 기술이 존재합니다.

JPA 구조