자바에서는 데이터를 객체로, 관계형DB는 테이터를 테이블에 저장합니다.
이 처럼 자바와 DB가 데이터를 다루는 기본에 차이가 있기 때문에 때문에 자바에서 DB데이터를 바로 다루기는 어려움이있습니다.
때문에 DB에서 받아온 데이터를 객체처럼 다룰 수 있도록 매핑하는 작업이 필요합니다. 이것을 ORM, Object Relational Mapping이라고 합니다.
객체와 테이블의 차이
상속
자바에서는 객체간 상속의 개념이있지만, DB에서는 상속이 없고 모두 동등한 입장에서 조인을 통해 연관관계를 맺습니다.
이 때문에 위 그림과같은 데이터에서 Album요소를 추가하기 위해서 자바는 list.add(album); 으로 간단하게 처리할 수 있지만 DB는 Album테이블과 Item 테이블에 맞는 정보를 각각 따로 저장해 주어야 합니다.
연관 관계
자바에서는 Member정보안에 Team정보를 넣고싶었다면 단순히 Member객체 안에 Team객체를 넣었습니다. 때문에 Member에서는 Team을 조회할 수 있지만, Team에서는 Member를 조회할 수 없었죠.
이와는 다르게 테이블은 외래키를 통해 연관관계를 맺습니다. 떄문에 Team에서도 Member를 조회할 수 있습니다.
매핑 문제점.
1. 테이블에 맞춘 객체 모델링
이러한 차이들 때문에 아래 그림처럼 객체를 아얘 테이블에 맞추어 모델링 하는 경우도 있었습니다. (Member 객체에 Team 객체를 저장하지 않고 외래키를 저장함)
하지만 이는 결코 객체지향적이지 못합니다. 힘들게 객체지향적으로 프로그램을 만들었건만 데이터객체 때문에 틀이 무너진다면 안돼잖아요.
2. 객체 -> 테이블, 테이블 -> 객체 매핑 비용
위 뮌제를 해결하기 위해 데이터가 프로그램 속에서 움직일 때는 객체로서, 그리고 DB에서는 튜플, 테이블로써 저장되도록 하는 방식이 발전하게 되었습니다. 아래 그림처럼요.
하지만 객체를 저장할 때도 member.getTeam().getId()로 외래키를 꺼내서 저장해야하는 번거로움이 있고, 조회할 때는 테이블을 조인해서 데이터를 받아오고.. 각각 객체를 만들고.. 받아온 데이터에서 각 객체에 관련된 정보를 따로 입력해주고.. 연관관계를 설정해주고...
유지보수하기 굉장히 어려울 것 입니다.
또 어떻게 매핑을 하더라도 아직 문제점이 남아있습니다.
3. 엔티티 신뢰의 문제
위 그림에서 Member객체는 Order와 Team 객체를 담고있습니다. 때문에 우리가 Member객체를 받았다면 언제든 Order와 Team 객체를 조회할 수 있어야합니다.
그러나 RDB의 경우 처음 실행하는 SQL에 따라 탐색 범위가 결정됩니다.
예를들어 아래 그림처럼 Member와 Team만 조인해 데이터를 받아온다면, 받아온 Member객체에서 Order를 조회할 수 없게됩니다.
기억력 좋은 개발자가 혼자 코딩한다면 이 때 불러온 Member객체에는 Order객체가 없구나 하고 알 수 있겠지만. SQL을 까보지 않은 개발자 입장에서는 member객체에 getOrder(); 메서드가 있으니 당연히 Member안에 Order객체가 있을거라고 생각하고 코딩할 것입니다. 하지만 Member에는 Order가 없죠.. 즉 SQL을 까보기 전에는 이 객체를 신뢰할 수 가 없는 것 입니다.
이를 해결하고자 DB에서 Member객체를 받아올 때마다 모든 아이들을 조인해 받아올 수 는 없는 노릇입니다.
4. 비교하기
자바는 같은 컬렉션에서 가져온 데이터는 언제 어디서 가져오더라도 같은 데이터라 인식합니다.
그러나 DB에서 받아온 데이터는 그렇지 못합니다.
이처럼 자바에서 DB의 데이터를 다루기 위해 매핑하는데 많은 에너지를 소모하게 됩니다. 프로그램을 좀 더 객체지향적으로 설계하면 할 수 록 이 매핑이 점점더 복잡하고 어려워지게 되는 것 입니다.
객체를 자바 컬렉션에 저장하듯 DB에 저장할 수 는 없을까?
라는 질문에서 탄생한 것이 바로 ORM입니다.
