자료 모음
ORM
DB란?
DB는 엑셀과 비슷한 표 형태이다. 비슷한 데이터끼리 테이블에 묶여 데이터가 저장되는 형태이다. 데이터를 저장한다는 건 컴퓨터 전원을 꺼도 남아 있어야 한다는 의미이다. 메모리의 경우엔 휘발성이라 전원을 끄면 날아간다. 대표적인 예로 컴퓨터를 껐다가 메모리 위에 윈도우를 다시 띄우는 부팅이 있다. 예전엔 일일이 파일에다 저장했지만, 큰 데이터를 다루기엔 제약이 많고 느린 속도를 비롯해서 불편한 점이 많았다.
관계형 데이터베이스(RDB)
프로그래밍에서는 실제 세계를 소프트웨어로 옮기는 방식이 자주 사용된다. 거기에서 바로 '객체'와 '관계'로 데이터를 저장해보자는 아이디어가 나오게 된다. 예를 들어 회원 Entity와 주문 Entity 간의 관계는 일대다 관계이다.
- ERD -> 객체 간의 관계 중심으로 디자인하는 방식
- RDB -> 관계형 데이터 베이스
DB를 제어하기 위해서는 SQL 언어가 사용되었다.
객체지향 프로그래밍(OOP)
그 와중에 개발에서 여러 명이 하나의 프로그램을 작성할 때 복잡성에 대한 화두가 등장한다. 그에 부응하여 OOP(객체지향 프로그래밍)이 등장하게 된다. 모든 프로그램을 객체로 대체하여 작성하며 복잡성은 줄어들었다. 모든 과정을 전부 노출할 필요가 없다는 전제하에 추상화, 캡슐화 등의 원칙이 등장하게 된다. Java, C#이 객체지향 언어의 선두 주자로 대세를 타게 된다.
객체는 복잡함을 숨겨주는 역할을 한다. (내부에서 돌아가는 모든 과정을 다 알 필요가 없다.)
ORM의 등장
이제 ORM을 설명하기 위한 두 가지 키워드가 다 나왔다.
- RDB
- OOP
당시 개발자들은 가장 핫했던 이 두 가지 방식으로 개발을 했다. 그러나 데이터를 전달하는 지점에서 패러다임 불일치 문제가 발생한다. 코드를 객체지향으로 짰지만 DB에는 그 객체 그대로 넣을 수 없었다. 그 이유는 아래와 같았다.
- 코드는 메모리 참조(referance)로 서로 객체를 연결하지만, 데이터 베이스는 외부키(FK)로 객체를 연결한다.
- 코드에서는 상속이 가능하지만 RDB는 상속이 불가능하다.
그래서 그 사이를 변환해주기 위해 매번 SQL로 미친듯이 코드를 짰다. (이게 무슨 이사 상자를 잘 쌌더니 창고 규격에 안 맞는다고 다 띁고 다시 포장하는 소리야.) 너무 성가시고 번잡스러운 작업이었다. 게다가 만일 mysql을 oracle로 바꾼다고 한다면, 그 중간 코드들을 전부 다 바꿔야하기에 DB를 바꿀 수가 없었다.
그래서 이 이슈를 해결하기 위해 나온 게 ORM이다. Object와 Relation을 Mapping해주는 역할을 수행한다. OOP로 코드를 짜서 RDB로 저장하려고 하면 중간에 ORM을 거치고, ORM이 알아서 데이터베이스 종류에 따라서 SQL문을 짜준다. (테이블을 알아서 만들어준다거나...) 그렇기에 대부분의 ORM은 여러 개의 관계형 데이터베이스를 지원한다.
