ORM(Object Relational Model)은 사물을 추상화시켜 이해하려는 OOP적 사고방식과 DataModel을 정형화하여 관리하려는 RDB 사이를 연결할 계층의 역할로 제시된 패러다임으로 RDB의 모델을 OOP에 Entity 형태로 투영시키는 방식을 사용한다.
이는 시스템에 따라, 사용하는 Database 및 DB Connector 에 따라 달라질 수 있는 데이터 매핑 구조를 객체지향형태로 통일시켜, SQL 구조의 Database를 OOP 구조의 형태로 매핑시키려는 패러다임이다.
OOP 적 구조와 SQL 구조의 차이는 데이터를 다루는 방법에서 나타난다. OOP 적 구조에서 모든 데이터는 객체이며, 각 객체는 독립된 데이터와 독립된 함수를 지닌다.
반면 SQL 에서 데이터는 테이블단위로 관리되며 객체들을 조회하기 위한 명령어를 사용한다.
ORM 은 각 테이블 또는 구분하고자하는 데이터 단위로 객체를 구현하고, 데이터간의 관계를 형성한다. 가령 개인 정보 저장을 위한 RDB의 테이블 Personal 은 다음과 같은 객체 Personal 로 매핑될 수 있다.
이러한 ORM을 구현하는 대표적인 프레임워크가 Hibernate이며, 이를 Java 표준 방식으로 정의한 것이 JPA이다. 실무에서 개발을 할 때에는 JPA 와 Hibernate 를 같이 사용한다.
위와 같은 매핑을 ORM 을 제공하는 프레임워크들은 매우 간단한 방식으로 지원한다. 가령 JPA와 Hibernate 와 같은 Java 의 ORM 들은 Annotation 을 이용해서 간단한 매핑이 가능하다.
이러한 중간 계층을 Persistence Layer라 하며, ORM 프레임워크 들은 기존의 Entity Bean이 수행하던 Persistence Bridge 의 역할을 ORM 패러다임의 Entity 방식으로 가능하게끔 한다.
적용되는 기준은 Data Entity와 Object 모델이 Getter와 Setter 그리고 Repository를 이용한 표준 형식으로 정의되며, RDB에서 표현할 수 있는 Join 관계 및 참조 관계, Native 쿼리 등 거의 모든 부분의 매핑이 가능하다.
ORM 은 데이터를 다루는 새로운 관점을 제시하지만 적용하는 데 있어 몇가지 고려해야할 장단점을 갖고 있다. 이는 ORM이 흔히 겪는 RDB와 OOP 사이의 아직 풀지 못한 숙제들을 말하며 다음과 같다.
1. 세밀함의 불일치(RDB 데이터 타입은 Vendor마다 다르며, 더이상 정규화가 힘들다.)
2. 하위 타입 문제 (RDB에는 상속의 개념이 없다.)
3. 동일성 문제(Java의 경우 Equals로 평가 가능하지만, DB는 PK 기준으로 한다.)
4. 연관 관계 – FK는 연관의 방향성을 갖지 못하기 때문에 N:N 모델의 경우 Link 테이블을 도입해야 한다.
5. 데이터 검색 – RDB는 한번에 많이 가져올지(메모리) 빈번하게 데이터를 가져올지(성능) 고민해야 한다.
위의 장단점은 표준 ORM 패러다임이 기존 시스템에 비해 갖는 괴리감 및 과제들이며, 많은 프레임워크들이 위의 숙제를 해결하기 위한 기능들을 제공한다.
하지만 무엇보다도 ORM 을 도입하는 데 있어서 중요하게 생각해야 할 점은 ORM 은 결코 RDB를 개발자로부터 분리시키는 기술이 아니라, 오히려 개발자에게 높은 RDB 지식을 요한다는 사실이다.
개발자는 객체 구조의 설계 시에도 Database 의 스키마를 고려해야하는 숙제를 갖게 되는 것이다.
이는 진입 장벽이 높아지는 단점으로 여겨질 수도 있으나 오히려 숙련된 개발자가 있다면, DB와 코드를 좀 더 직관적으로 연결하고 다룰 수 있게 하는 기술이 될 수 있다.
ORM 의 개념은 아직 우리나라에서는 익숙하지 않다. 아직 많은 개발자들이 SQL Mapper로 대표되는 MyBatis를 선호하는 추세이지만 전세계적으론 Application Service 기술 동향에 있어서 데이터를 다루는 기술의 하나로 각광받고 있다.
* 향후 포스팅의 카테고리를 옮길 예정입니다.
