ORM 프레임워크를 사용하는 이유(ex. JPA..)

ORM(Object - realtional mapping) 

-> 객체는 객체대로 설계를 하고, DB는 Relational하게 설계를 하면서, 

이 2개의 패러다임의 차이로 생기는 [SQL 중심적인 개발]이라는 문제를

 [JPA와 같은 ORM 프레임워크]가 중간에서 매핑함으로써 해결해 준다. 

Object와 RDB의 차이

[1. 상속 관계의 유무]
-> RDB에도 [Super Type], [Sub Type]이 존재하지만, OPP에서의 그것들과는 다른 의미이다. 

Album 저장

1. 객체 분해 : RDB는 Album이라는 상속 관계에 의한 Table을 만들 수가 없으므로, 아래와 같이 SQL을 크게 2개로 나누어

서 작성을 해 줘야 한다. ( 만약 Album 객체의 부모 클래스가 100개 있다면??? -> 100개의 SQL문을 작성해야 한다)

2. INSERT INTO ITEM ...

3. INSERT INTO ALBUM …

Album 조회

1. 각각의 테이블에 따른 JOIN SQL 작성 : Album 객체의 상속 관계에 있는 테이블들을 상대로 JOIN SQL문을 작성하여, 

객체의 필드값을 출력하기 위한 Tuple을 생성해야 한다.  

2. 각각의 객체 생성 : RDB의 ITEM Table과 Album Table을 JOIN한 튜플을 하나 하나 GET하고, new Album()등의 코드를 

통해서, 객체를 생성을 한 뒤, 개발자가 직접 이 새롭게 생성한 객체에 삽입해야 할 필드값을 튜플에서 추출하여 일일이 매

핑해주는 작업을 코드로 해야 한다. ㅠㅠㅠㅠㅠ

3. 상상만 해도 복잡

4. 더 이상의 설명은 생략한다.

5. 그래서 DB에 저장할 객체에는 상속 관계 안쓴다.

[2. 연관(Assosication) 관계의 구현 방법]

a) 객체 : 연관 관계를 레퍼런스 변수(JAVA의 경우)로 나타낸다

b) RDB : 연관 관계를 Foreign Key로 나타낸다. 

Q. 그러면, RDB에 저장할 객체를 RDB 패러다임에 맞게 설계를 하면 되지 않을까?

더 정확히 말하면, 객체를 참조 변수(Team이라는 레퍼런스 변수)로 연관 관계를 맺게 하지 말고, Foreigh Key(ITEM_ID)로

맺을 수 있게 애초에 모델링을 해놓았다면??

A.  RDB에서 Select로 조회해 온 튜플들 중에서, 객체에 들어 가야할 attribute값을 개발자가 일일이 Mapping작업을 해줘야

한다. 

위와 같이 객체를 설계해버리면 우리는 OOP 개발을 버려야 한다. 

아래에서는 OOP에 맞추어 객체를 모델링 했을 때는 그럼 RDB와 어떤 문제점이 생기는지를 알아 보자. 

OOP적인 객체 모델링

 

 

-> 객체를 OOP적으로 모델링을 하게 되면, 후에 RDB에서 조회(SELECT)한 TUPLE을 

개발자가 일일이 객체에 정보를 넣어 주는 Mapping 작업을 해줘야 한다. 

(만약, 조회(select)한 Table들이 100개라면??)

[3. 데이터 타입]

a) java의 문자열 타입 : String or char 배열

b) RDB의 문자열 타입 : varchar(10) etc.

[4. 객체 그래프를 자유롭게 탐색하지 못한다]

-> RDB에서 SELECT하여 얻은 객체는 연관 관계에 있는 객체들을 존재를 보장받지 못한다. 

그럼, 어떤 개발자가 이렇게 질문을 할 수가 있다. 

개발자 A : RDB에서 모든 객체를 조회(SELECT)하여, 아래와 같이 상황에 따라서 필요한 객체를 연관 관계로 묶으면 되지

않냐?

현자 A : "해보거라" 

-> 개발자가 상황에 따른 모~~든 조회 메서드에 대해서, RDB의 조회(SELECT)결과 -> 객체로 [Mapping] 작업을 해줘야 한

다. 

-> 객체를 객체답게 모델링을 하면 할수록, RDB의 조회(SELECT) 결과를 객체에 매핑해야 하는 작업이 늘기만 한다. 

Q. 객체를 RDB에 저장할 때, 위의 것들을 전혀 고려하지 않고 JAVA Collection에 저장(INSERT),삭제(Delete), 조회(SELECT)하듯이 할 수는 없을까?

 

-> 위와 같이 객체를 RDB에 저장을 할 수 있게 된다면 개발자는 

객체와 RDB 사이의 패러다임의 차이점으로 인하여 생기는  [SQL 중식적인 개발]에서 벗어나

객체를 RDB에 훨씬 쉽게 삽입/삭제/조회 등을 할 수가 있어서,

개발 속도/생산성 등이 비약적으로 올라 갈 것이다. 

 

JPA와 같은 ORM 기술이 [SQL 중심적인 개발]에서 개발자들을 해방시켜 주었다

-> JPA와 같은 ORM 프레임워크는 객체와 RDB 사이의 이러한 [SQL 중심적인 개발]을 자동화시켜주고, 

객체를 마치 JAVA의 COLLECTION에 저장하듯 RDB에 저장할 수 있게 도와 준다.