ORM
in Web
본 글은 기존 노션에서 작성된 내용을 이전한 문서입니다.
사전 지식
영속성(Persistence)
영속성이란
- 데이터를 생성한 프로그램이 종료되더라도 사라지지 않는 데이터의 특성
- 영속성을 갖지 않는 데이터는 단지 메모리에서만 존재하기 때문에 프로그램을 종료하면 모두 잃어버리게 됨
Object Persistence(영구적인 객체)
- 메모리 상의 데이터를 파일 시스템, 관계형 데이터베이스 혹은 객체 데이터베이스 등을 활용하여 영구적으로 저장하여 영속성을 부여한다.
- 데이터를 데이터베이스에 저장하는 3가지 방법 (자바 기준)
- JDBC
- Spring JDBC
- Persistence Framework
Persistence Layer
- 프로그램의 아키텍처에서 데이터에 영속성을 부여해주는 계층
- JDBC를 이용하여 직접 구현할 수 있지만 Persistence framework를 이용한 개발이 많이 이루어짐
Persistence Framework
- JDBC 프로그래밍의 복잡함이나 번거로움 없이 간단한 작업만으로 데이터베이스와 연동되는 시스템을 빠르게 개발할 수 있으며 안정적인 구동을 보장함
- SQL Mapper와 ORM으로 나눌 수 있음
- ex) JPA, Hibernate, Mybatis 등
ORM
ORM이란
- Object Relational Mapping, 객체-관계 매핑
- 객체와 관계형 데이터베이스의 데이터를 자동으로 매핑(연결)해주는 것을 의미
- 객체 지향 프로그래밍은 클래스를 사용하고, 관계형 데이터베이스는 테이블을 사용함
- 객체 모델과 관계형 모델 간에 불일치가 존재함
- ORM을 통해 객체 간의 관계를 바탕으로 SQL을 자동으로 생성하여 불일치를 해결
- 데이터베이스 데이터 ← 매핑 → Object 피륻
- 객체를 통해 간접적으로 데이터베이스 데이터를 다룸
- Persistance API라고도 할 수 있음
- ex) JPA, Hiberante 등
ORM의 장점
- 객체 지향적인 코드로 인해 더 직관적이고 비즈니스 로직에 더 집중할 수 있게 해줌
- ORM을 이용하면 SQL Query가 아닌 직관적인 코드(메서드)로 데이터를 조작할 수 있어 개발자가 객체 모델로 프로그래밍하는 데 집중할 수 있도록 도와줌
- 선언문, 할당, 종료 같은 부수적인 코드가 없거나 급격히 줄어듦
- 각종 객체에 대한 코드를 별도로 작성하기 때문에 코드의 가독성이 올라감
- SQL의 절차적이고 순차적인 접근이 아닌 객체 지향적인 접근으로 인해 생산성이 증가함
- 재사용 및 유지보수의 편리성 증가
- ORM은 독립적으로 작성되어있고, 해당 객체들을 재활용 할 수 있음
- 때문에 모델에서 가공된 데이터를 컨트롤러에 의해 뷰와 합쳐지는 형태로 디자인 패턴을 견고하게 다지는데 유리함
- 매핑정보가 명확하여, ERD를 보는 것에 대한 의존도를 낮출 수 있음
- DBMS에 대한 종속성이 줄어듦
- 객체 간의 관계를 바탕으로 SQL을 자동으로 생성하기 때문에 RDBMS의 데이터 구조와 언어의 객체지향 모델 사이의 간격을 좁힐 수 있음
- 대부분 ORM 솔루션은 DB에 종속적이지 않음
- 종속적이지 않다는것은 구현 방법 뿐만 아니라 많은 솔루션에서 자료형 타입까지 유효하다는 의미
- 프로그래머는 Object에 집중함으로 극단적으로 DBMS를 교체하는 거대한 작업에도 비교적 적은 리스크와 시간이 소요됨
- 또한 자바에서 가공할경우 equals, hashCode의 오버라이드 같은 자바의 기능을 이용할 수 있고, 간결하고 빠른 가공이 가능함
단점
- 완벽한 ORM 으로만 서비스를 구현하기가 어려움
- 사용하기는 편하지만 설계는 매우 신중하게 해야함
- 프로젝트의 복잡성이 커질경우 난이도 또한 올라갈 수 있음
- 잘못 구현된 경우에 속도 저하 및 심각할 경우 일관성이 무너지는 문제점이 생길 수 있음
- 일부 자주 사용되는 대형 쿼리는 속도를 위해 SP를 쓰는등 별도의 튜닝이 필요한 경우가 있음
- DBMS의 고유 기능을 이용하기 어려움 (하지만 이건 단점으로만 볼 수 없다 : 특정 DBMS의 고유기능을 이용하면 이식성이 저하됨)
- 프로시저가 많은 시스템에서는 ORM의 객체지향적인 장점을 활용하기 어려움
- 이미 프로시저가 많은 시스템에선 다시 객체로 바꿔야하며, 그 과정에서 생산성 저하나 리스크가 많이 발생할 수 있음
연관 관계 매핑
- 테이블 간의 연관 관계가 있을 때 객체지향 스럽게 사용하는 방법을 제공
- 기존의 데이터베이스에서는 외래키를 사용하나 JPA(본 문서 작성 시 참고한 ORM)에서는 객체를 참조하는 방식으로 연관관계를 매핑할 수 있음
- 용어
- 방향 : 단방향, 양방향
- 다중성 : 다대일, 일대다, 일대일, 다대다
- 연관관계의 주인 : 객체 양방향 연관관계는 관리 주인이 필요
- 용어
- 객체를 협력 관계를 만들고자 한다면 객체 중심으로 테이블을 설계 해야함
- 테이블 중심으로 모델링을 하게 되면, 외래 키를 가지고 데이터를 찾기 때문에 객체지향스럽지가 못하기 때문에 객체 중심으로 관계를 매핑하고 모델링하는 것이 중요
- 연관 관계의 주인
- 실제 테이블 관계에서 존재하지 않는 관계가 양방향 연관 관계
- JPA에서 프로그래밍적으로 사용할 수 있는 방법
- 양쪽에서 참조할 수 있도록 하는 것이 양방향 연관 관계
- 권장되는 방식은 단방향 관계
- 일반적으로 외래키가 있는 테이블을 대변하는 엔티티를 연관 관계의 주인으로 지정하는 게 좋음
- 차후 발생할 수 있는 성능 이슈가 없을 뿐더러 쿼리문에 대한 직관성도 높아짐
- 일반적으로 외래키가 있는 테이블을 대변하는 엔티티를 연관 관계의 주인으로 지정하는 게 좋음
- 실제 테이블 관계에서 존재하지 않는 관계가 양방향 연관 관계
양방향 매핑 시 가장 많이 하는 실수 (주의 사항)
- 연관 관계의 주인이 아닌 값에 입력하는 것
- mappedBy에 필드 값을 수정하는 것
- 이 필드는 읽기 전용이 되는 것을 꼭 명심해야 함
- 양방향 매핑시에 무한 루프 조심
다대일 (@ManyToOne)
- 가장 많이 사용되는 연관 관계
- ex) Team / Member와 같은 관계에서 사용
- 양방향 관계를 맺어주기 위해서는 양측 참조를 생성하면 됨
일대다 (@OneToMany)
- 일(1)이 연관 관계의 주인이 됨
- 일대다 관계는 항상 다(N) 쪽에 외래키가 있음
- 실무에서 거의 적용하지 않는 연관 관계
- 일대다 단방향 매핑보다 다대일 양방향 매핑을 사용하자
@OneToOne
- 다대일과 사용방법이 매우 유사
- 주 테이블에 외래 키 or 대상 테이블에 외래 키
- 주 테이블 외래키
- 객체지향 개발자 선호
- JPA 매핑 편리
- 장점 : 주 테이블만 조회해도 대상 테이블에 데이터가 있는지 확인 가능
- 단점 : 값이 없이면 외래 키에 null 허용
- 대상 테이블 외래 키
- 전통적인 데이터베이스 개발자 선호
- 장점 : 주 테이블과 대상 테이블을 일대일에서 일대다 관계로 변경할 때 테이블 구조 유지
- 단점 : 프록시 기능의 환계로 지연 로딩으로 설정해도 항상 즉시 로딩
- 주 테이블 외래키
다대다 (@ManyToMany)
- 실무에서 사용하면 안되는 관계
- 관계형 데이터베이스에서는 다대다 관계를 표현할 수 없음
- 연결 테이블을 추가해서 일대다 다대일로 풀어내야 함
Reference
[DB] ORM이란 - Heee’s Development Blog
JPA - 연관 관계 매핑 (@OneToMany , @ManyToOne , @OneToOne , @ManyToMany )