[JPA] 객체와 데이터베이스의 패러다임 불일치

이 글은 혼자 학습한 내용을 바탕으로 작성되었습니다.

틀리거나 잘못된 정보가 있을 수 있습니다.

댓글로 알려주시면 수정하도록 하겠습니다.

---

1. 패러다임 불일치

프로그램 작성 중 특정 객체 정보를 영구 저장하기 위해서는 메모리가 아닌 다른 저장소 등에 저장되어야 합니다.

 

저장된 객체는 필요시 저장소에서 데이터를 가지고와 객체를 재 생성하여 사용하는 방식으로 사용됩니다.

 

객체의 경우 상속이나 다른 객체의 참조 등이 있는 경우도 빈번히 발생하게 됩니다.

 

이러한 경우 저장이 까다로워지지만 Java의 경우 직렬화와 역직렬화를 통해 파일에 저장하거나 파일로부터 데이터를 읽어와 객체를 생성할 수 있습니다.

 

하지만 직렬화가 된 경우 조회가 사실상 불가능하게 되어 직렬화 후 파일에 저장 방법을 사용하기 어렵습니다.

 

그래서 우리는 보통 객체의 속성 정보의 영구 보관 저장소로 DB를 많이 사용하고 있습니다.

 

이때 객체와 DB의 기능과 표현방법에 있어 차이가 발생하게 됩니다.

 

하나의 예로 상속관계가 있는 객체를 DB 테이블에 표현하기와 같은 차이가 발생합니다.

 

이러한 차이를 패러다임 불일치라고 합니다.

 

2. 연관관계

객체는 참조를 이용하여 연관관계를 맺고 연관관계를 맺고 있는 객체의 정보 조회는 참조하고 있는 객체에 접근하여 정보를 조회합니다.

 

반면 DB의 경우 연관된 테이블과 외래 키를 이용하여 연관관계를 맺고 연관관계를 맺고 있는 테이블의 정보 조회는 외래 키를 이용하여 조인을 통해 연관 테이블을 조회합니다.

 

객체가 상속을 한 경우 객체와 DB의 차이를 확인해 보겠습니다.

객체UML

ERD

Album Class의 객체를 저장 한다고 가정했을 때 DB에는 각 속성을 맞게 저장 후 상속관계를 나타내기 위해 FK를 이용하여 ITEM 테이블과 ALBUM 테이블을 연결한다 하지만 이후 DB에서 객체로 불러오려는 경우 자식 Class 타입을 알 수가 없으므로 ITEM 테이블에 DTYPE이라는 속성을 추가하여 해당 ITEM의 자식 Class가 무엇인지 저장하게 된다.

 

상속의 경우는 어느정도 해결이 가능은 하지만 참조의 경우는 객체와 DB의 패러다임 불일치를 극복하기 어렵다.

 

또한 객체가 여러 객체들과 참조 관계를 맺어 객체 그래프를 형성할 수도 있다 이경우는 더더욱 패러다임 불일치를 극복하기 어렵다.

 

JPA는 이러한 객체들의 상속 참조 등의 패러다임 불일치를 극복하기 위해 지연 로딩을 이용하여 객체를 사용하는 시점에 적절한 SQL을 실행하여 필요한 참조 객체를 이용할 수 있도록 하였습니다.