java - ORM

ORM(Object Relational Mapping) 정의
데이터베이스 연계처리를 위하여 기존의 SQL에 의존하는 것이 아니라, 직접 테이블의 컬럼을 자바 Class에 매핑하거나 XML 형태의 SQL을 실행하여 처리를 수행하는 Persistence Layer를 담당하는 Framwork 개발모델

등장배경
OOP에 있어서 관계형 데이터 베이스와의 연계성을 분명히 하자는 의도

ORM 개념도

ORM 종류

종류	SQL Mapping기반기술(Partial ORM)	Object Relation Mapping기반기술(Full ORM)
개요	SQL을 특정 name으로 정의하여 사용	내부 엔진에서 SQL 자동 생성
맵퍼	SQL Mapper	Object Relation Mapper
방법	-자바객체를 실제 SQL 문자에 매핑 -자바 코드에서 SQL관련 부분 제거 -XML에 임베디드 된 SQL	-Table Row와 자바객체를 동기화 -모든 SQL문은 프레임워크에서 생성하고 실행
종류	iBatis SQL Maps / Oracle SQLJ / Forte 4GL Embedded SQL/Pro*C Embedded SQL	Hibernate/TopLink/Cocobase/JPA(java Rersistent API)
장단점	-더 복잡한 데이터 전송방식 환경에서 효율적 -더 효율적으로 SQL의 장점 활용 가능	-O/R Mapper가 SQLMapper에 비해 더 효율적인 매핑 -O/R Mapper가 객체 모델과 DB 모델에 대한 광범위한 정보를 가지고 있음

 

일반적인 개발 vs ORM 구축 개발

특성	일반적인 개발	ORM 구축
매핑 적용	테이블 컬럼과 자바 클래스간 직접 매핑 필요	개발자가 직접 객체지향 관점에서 처리 가능
유연성	SQL 변경시 코드를 직접 변경하고 배포해야 됨	매핑 정보의 수정만으로 적용 가능
표준 패턴	패턴없음	매핑 정보, XML 등이 템플릿 형태로 적용됨
DB제어	직접적으로 DB 제어 가능	Mapping 경우 직접적인 제어가 어려울 수 있음
활용 기술	SQL	Persistence 프레임워크(Hibernate, iBatis)

출처 - http://blog.naver.com/yeonnim07?Redirect=Log&logNo=130148006542

===================================================================================

ORM의 기본적인 개념 및 활용방안

Table of Contents

• Introduction
• ORM
  • ORM 등장배경
  • ORM의 기본적인 개념
    • Mapping Concept
    • Transparent persistence
• ORM 활용방안
  • 가이드 라인
• 참고문헌

Introduction

본 문서는 최근 persistence layer를 처리하기 위한 다양한 개발방법 중에 ORM(Object-Relational Mappging)의 기본적인 개념과 실무에서 활용할 수 있는 방안을 고민해 본다.
먼저 ORM 프로그램 기법이 왜 생기게 되었는지를 등장배경으로 정리해 보고, ORM의 기본적인 개념을 대해서 살펴본 후, ORM 기법을 이용하여 실제적으로 활용할 수 있는 방안이 있는지를 계속해서 살펴보도록 한다.

ORM

ORM 등장배경

ORM이 등장하기 까지의 배경을 살펴보면 다음 그림과 같다. 각 개발 방식에 따라서 장/단점을 기술해 두었다.

Java 진영에서 웹 애플리케이션을 개발할 때 처음에는 JSP/Servlet에 View와 Business logic, 데이터 베이스 처리 모듈까지 모두 포함하여 개발함으로써, 유지보수의 어려움과 같은 많은 문제점이 발견되어 진다.
따라서 MVC 모델에 입각한 각 Layer를 구분하여 개발자로 하여금 business logic에 집중할 수 있는 컴포넌트와 같은 형태들이 제공되어 지는데 SUN에서는 J2EE 스팩안에 EJB를 넣음으로서 persisten layer를 컨테이너에게 담당하게 함으로써 이와 같은 문제점을 해결하고자 했다.

하지만 Model 2 방식에서 이와 같은 접근은(특히 EJB-CMP를 두고 말함) 각 WAS(Web Application Server) 제품에 따른 deploymement descriptor 파일을 각각 수정해야 하고, 낮은 개발자 생산성, 테스트의 어려움 등 다양한 단점이 발생하게 된다. 뿐 만 아니라 각 WAS에 따른 컨테이너의 처리 방식이 상이함에 따라 개발자들은 EJB 뿐 만 아니라, WAS에 대한 이해도 요구하게 되었다.
이러한 하나의 대안으로 DAO 클래스를 두고 데이터 베이스와의 처리를 DAO에서 처리하게 된다. DAO 클래스에서는 개발자의 특성에 따라서 트랙잭션 처리, Connection Pool 처리 등을 상이하게 개발하게 된다.

그리고, 현재 ORM 프로그래밍 기법에 따른 persistence layer를 처리하는 Hibernate, iBatis, Oracle TopLink 와 같은 Framework가 등장하게 된다. EJB의 대안으로 등장하게 된 이와 같은 Framework는 각 Framework에 구현 방식에 따라 Query, Connection, transacation 처리 등을 Framework가 처리해 줌으로서 개발자로 하여금 business logic에 집중할 수 있도록 제공해 주게 된다.
하지만 이러한 프레임워크를 공부해야 하고 적응하는 데에도 시간이 필요하고, 경우에 따라서 유지보수의 어려움이 따르게 된다. 그러므로 각 개발환경에 맞는 적절한 개발방식을 선택할 수 있는 능력이 필요하게 된다.

ORM의 기본적인 개념

ORM의 기본적인 개념은 현재 살펴본 바로는 자바지기 스터디 1,2기에서 장진달님과 유성희님께서 수고한 덕분으로 이미 잘 정리된 문서가 존재함으로 먼저 소개하는 것으로 한다.

[Hibernate 프레임워크를 이용한 효율적인 개발 전략|http://wiki.javajigi.net/pages/viewpage.action?pageId=297#장진달] : 두 번째 목차인 "ORM - Obejct Relation Mappging"는 꼭 참조
[Object-Relational Mapping Strategies|http://wiki.javajigi.net/pages/viewpage.action?pageId=3081#유성희] : 두 번째 목차인 "Object-Relational Mapping이란?"는 꼭 참조

실제 Hibernate 문서와 위의 두 wiki 내용은 문서를 다시금 쉽게 정리해 보면 Object-Orientied programming에 있어서 관계형 데이터베이스와의 연계성을 분명히 하자는 것이다. 즉 Object-Relational Mapping은 다음과 같이 생각해 볼 수 있다. 우리가 '객체(Object)로 실세계의 현상(또는 구현하고자 하는 바)를 객체로 표현하여 좀 더 분명하고 쉽게 개발을 하자'라고 하는 게 객체지향 프로그래밍이라고 한다. 즉 개발자는 관계형 데이터베이스에 제약을 최대한 받지 않으면서(또는 한정되지 않고), 객체를 클래스(Bean)으로 표현하는 것과 같이 관계형 데이터베이스를 객체처럼 쉽게 표현 또는 사용하자는 것이다. 때문에 ORM이란 용어처럼 객체(Object)와 관계(Relation)을 연결(Mapping)해 주는 개념이 된다라고 생각할 수 있다.

다음 그림은 실세계에 존재하는 바를 왼쪽은 객체(Object) 형태로, 오른쪽은 데이터베이스의 테이블로 표현한 것이다.

위의 그림은 실세계를 표현하는 데 있어 객체와 테이블(관계형 데이터베이스)는 서로 다른 형태를 가지는 것을 볼 수 있다. 실제로 Object를 그대로 관계형 데이터베이스에 표현하면 좋다거나 관계형 데이터베이스의 테이블을 객체로 표현하면 좋은 경우가 있다. 하지만 서로다른 형태의 구조를 가진 객체와 테이블은 서로 배타적인 표현 때문에 개발자로 하여금 데이터베이스 프로그래밍을 처리하게 하는 것이다.
ORM에서의 mapping concept 중 'one-to-one' 개념 형태를 살펴보면 실제 데이터베이스와 객체를 1:1로 속성(객체의 attribute)와 row를 매핑해 주는 개념이 존재한다. 이러한 형태는 EJB Entity Bean이 가지고 있는 개념으로 데이터베이스의 테이블을 객체로 매핑해 주고 있는 것이다.

여기서 생각해 볼 문제는 위의 그림 예제와는 거꾸로 두 개의 테이블이 있다고 가정하면 각 테이블을 두 개의 객체로 표현해야 한다. 하지만 이를 OOP에서는 하나의 객체로 표현하는 게 좋을 경우도 있을 것이다. 이와 같은 경우 실제 객체와 데이터베이스와의 연결 구조를 어떻게 가져갈 것이냐? 라고 생각해 볼 수 있다.

이에 대해서는 이미 ORM에서 세 개의 mapping concept을 가지고 설명해 주고 있다. mapping concept에 대한 설명은 1기 장진달님께서 너무나도 잘 설명해 준 자료가 있어 소개한다.

Mapping Concept (Persistent class와 table사이의 mapping방법)

• one-to-one : 테이블의 모든 컬럼에 대하여 persistent class의 모든 변수가 표현되며 하나의 비지니스 클래스는 테이블의 할 row에 해당 한다.
• SUBSET Mapping : 하나의 테이블을 하나이상의 class로 mapping 하며 그 세부적으로 vertical mapping, horizontal mapping, filtered mapping이 있을 수 있다.
  • 간단 한 예로 각각의 설명을 해보겠다. 어떤 매장의 고객과 종업원을 관리하는 업무라고 할때 고객과 종업원은 아래와 Class Diagram으로 객체가 구성되었다면.
    
  • Vertical mapping: 하나의 테이블당 하나의 객체로 구현 되는 방식으로 아래와 같은 DB구조를 가지게 된다.

    Person Table	Employee Table	Customer Table
    PersonID	ID	ID
    LastName	PersonID	PersonID
    FirstName	Since	Terms
    Title	PayRate	Owes

  • Horizontal mapping : 하나의 테이블을 하나이상의 객체로 표현 하는 방식으로 위의 아래와 같은 DB구조를 위의 그림과 같은 객체로 mapping하는 방식이다.

    Employee Table	Customer Table
    ID	ID
    LastName	LastName
    FirstName	FirstName
    Title	Title
    Terms	Since
    Owes	PayRate

  • Filter mapping : Horizontal 방식과 동일한 계념이나 어떤 data의 값을 가지고 filtering 하여 객체를 mapping하는 방식으로 아래와 같이 Type 컬럼의 값을 가지고서 고객과 종업원을 구분 하는 형식이 될 수 있다.

    Person Table
    ID
    Type
    LastName
    FirstName
    Title
    Since
    PayRate_Owes
    Terms

• SUPERSET Mapping : 여러 테이블을 묶어서 하나의 class로 mapping 하는 방식으로 view의 편의성을 위하여 많이 구현 된다.
  • 간략하게 덧붙이자면 위의 경우에서 고객의 주소, 전화번호 같은 정보를 담고 있는 테이블 PersonInfo table이 존재할 경우 Person Table과 PersonInfo Table의 colum값을 모두 표현한는 객체로 mapping하는 방식이라 할 수 있는데 DB구조와 Class는 아래와 같은 구조로 보일 것이다.
  • 객체 구조

    Person
    LastName,FirstName,Address,Phone,Age

  • DB구조

    Person Table	PersonInfo Table
    ID	ID
    LastName	Address
    FirstName	Phone
    Title	Age
    Since	LastVisit
    PayRate_Owes
    Terms

Transparent persistence

ORM의 기본적인 개념에서 객체와 관계에 대한 이야기를 토대로 했을 때, transparent persistence가 비로써 이해가 된다. Transparent persistence는 O-R Mapping tool이 관계형 데이터베이스에 저장된 데이터를(오브젝트 프로그래밍 언어를 통해) 직접 조작하는 기능이다.
Transparent persistence에 대한 자세한 설명과 샘플예제는 다음의 링크를 참조하면 된다.

Transparent persistence : http://www.service-architecture.com/object-oriented-databases/articles/transparent_persistence.html
Transparent persistence sample : http://www.service-architecture.com/object-oriented-databases/articles/java_and_object_databases.html

ORM 활용방안

가이드 라인

ORM을 이용한 활용 방안은 특별한 정답이 없는 듯 하다. 무조건적으로 해당 프로젝트에 ORM을 도입할 수도 없다. 하지만 적절한 환경, 적절한 애플리케이션에 ORM을 적용함으로써 얻을 수 있는 장점이 있음으로 이를 이해하지 않고 있을 수도 없는 일이다. 다음은 참조문헌에 있는 내용을 발췌한 ORM을 도입하는 데 있어 가이드라인을 제시하고 있다. 이를 한 번 살펴보자.

타겟 데이타베이스를 이해하라. ORM 을 적용할 때 SQL 및 데이타베이스의 락킹(locking) 모델을 무시해도 된다고 생각하면 오산입니다. O-R 매핑은 작업을 쉽게 해 주는 툴이지, 구현되는 환경에 대한 이해를 불필요하게 만드는 툴은 아닙니다. (ORM 적용 환경에서 발생하는 많은 문제가 데이타베이스와 SQL의 문제를 간과함으로써 발생합니다.) 필요한 경우 SQL을 사용하는 것을 두려워하지 말라. 많은 시나리오에서 이 방법으로 효과를 볼 수 있습니다. TopLink와 같은 ORM 제품은 SQL 쿼리 작성 기능을 제공합니다. 하지만 경우에 따라 셋(set) 기반 업데이트 또는 저장 프로시저를 실행해야 할 수도 있습니다. O-R 매핑 제품을 선택하기 전에 충분히 검토하라. 모든 ORM 제품이 동일한 수준의 기능을 제공하는 것은 아닙니다. 요구사항을 반영하는 PoC(Proof of Concept) 환경을 구축하고 2~3 가지 제품을 비교 테스트해 보아야 합니다. 이 과정을 통해 ORM이 성능 기준을 만족하는지 검증할 수 있습니다. 엔터프라이즈 개발 과정의 다른 요소들과 마찬가지로, 프로젝트 라이프사이클의 초기 단계에서 성능과 관련한 리스크를 최소화하는 것이 중요합니다. 또 ORM 툴의 매핑 기능에 과도한 오버헤드가 수반되지 않는지 확인해야 합니다. ORM이 적절하게 사용될 수 있는 상황을 이해하라. ORM은 엔티티를 개별적으로 업데이트하고 간헐적으로 셋 기반 작업을 수행하는 OLTP 애플리케이션에 특히 적합합니다. 고객 레코드 및 주문 내역을 개별적으로 업데이트하는 애플리케이션이 좋은 예입니다. ORM이 적절하지 않은 경우를 이해하라. ORM은 만병통치약이 아닙니다. ORM이 적합하지 않은 경우가 아래와 같습니다: 많은 수의 레코드에 대해 잦은 빈도로 벌크 업데이트를 수행하는 애플리케이션 OLAP 애플리케이션 (데이타베이스가 내부적으로 제공하는 네이티브 프로그래밍 메커니즘을 효과적으로 활용할 수 없게 됩니다. 좀 더 일반적으로 말해서, J2EE는 OLAP 환경에 적합하지 않습니다.) 데이타의 인출 및 업데이트를 위해 핸드코딩으로 작성된 SQL 및 저장 프로시저를 이용하는 데이타베이스 환경. 이 경우 JDBC 기반의 접근 방법이 최선의 선택이 될 수 있습니다. iBATIS SQL Maps 역시 이러한 환경에서 빛을 발합니다. (하지만 TopLink와 같은 우수한 ORM 제품은 기존 스키마 및 저장 프로시저와 효과적으로 연동되므로, 이러한 환경에서도 ORM의 사용을 고려할 가치가 있습니다.) 순수 SQL 기반 접근 방법을 적용하는 것이 적절한 애플리케이션. 비즈니스 로직의 대부분이 데이타베이스에 이미 구현되어 있거나, 데이타베이스 무결성 제약(integrity constraint)이 적용되어 있는 경우 등을 그 예로 들 수 있습니다. 이러한 애플리케이션에서는 오브젝트 또는 ORM의 활용 여지가 매우 적으며, 데이타베이스 테이블을 도메인 오브젝트로 모델링 함으로써 기대할 수 있는 효과가 거의 없습니다. 현재 여러 종류의 ORM 툴이 상용 애플리케이션(Java ORM 제품으로 가장 오랜 역사를 가지고 있는 TopLink 등)과 오픈 소스(Hibernate 프레임워크, JDO 기반 솔루션 등)의 형태로 제공되고 있습니다. 이 제품 중에서 하나를 선택하는 것이 바람직하며, 내부적으로 ORM 툴을 직접 개발할 필요는 없습니다 (과거에는 기업 내부에서 ORM 프레임워크를 직접 개발하는 것이 일반적이었지만, 현재로서는 무의미합니다. 그 비용이 많이 들 뿐 아니라 상용/오픈 소스 솔루션에 근접하는 결과를 얻기도 어렵습니다.)

토의

• 대한민국 IT 환경에서의 ORM은 적합한가?
• 작은 규모의 프로젝트에서 ORM이 적합한가?
• 대형 규모의 프로젝트이거나 솔루션 기반의 프로젝트일 경우 데이터베이스의 비중과 ORM 도입에 있어서의 고민을 해 보아야 한다.

참조문헌

Persistence와 POJO: 오브젝트 및 관계형 모델의 통합
[ORM에 대한 기본적인 이해(Hibernate를 중심으로 한)|http://blog.naver.com/jdkim528/140010947478#김종대]
Hibernate 프레임워크를 이용한 효율적인 개발 전략 - 장진달
Object-Relational Mapping Strategies - 유성희
도메인모델을 이용한 엔터프라이즈 애플리케이션 구축 - 김형준
http://www.service-architecture.com/object-oriented-databases/articles/transparent_persistence.html
http://www.service-architecture.com/object-oriented-databases/articles/java_and_object_databases.html

문서에 대하여

최초작성자 : [OSS 3기:이상협]
최초작성일 : 2006년 9월 7일
최종수정일 : 2006년 9월 20일
버전 : 1.0
문서이력 :

• 2006년 9월 7일 이상협 문서 최초 생성 : 목차 및 초안 작성
• 2006년 9월 8일 이상협 : ORM 기본적인 개념 - mapping concept, transparent persistence 작성

출처 - http://javajigi.net/pages/viewpage.action?pageId=6560