[DB 설계]데이터베이스 상속? 슈퍼타입-서브타입 모델

슈퍼타입-서브타입 모델이란? DB를 설계하는 개념적 모델로써,

어떤 개체들 사이에 공통 속성과 특수 속성이 존재할 때, 공통 속성을 '슈퍼타입'  /  특수 속성을 '서브타입'으로 나누어 개념적으로 표현하는 모델이다.

 

예를 들어, 사람, 학생, 교수, 직원 이라는 엔티티가 있다고 해보자.

이때, 학생/교수/직원은 사람(이름,주민번호,주소,연락처 등)이라는 공통 속성을 가진다.

아마도  우리가 이를 자바같은 객체지향 프로그래밍으로 구현한다면 아마도 '클래스 상속'을 사용할 것이다.

하지만 데이터베이스에서는 '상속'이라는 개념은 없지만 이를 비슷한 구조로 '구현' 할 수는 있다.

슈퍼타입-서브타입 모델 중 Identity라는 전략을 통해서다.

 

슈퍼타입-서브타입 모델은 3가지 전략을 가진다.

• Roll-up 전략
• Roll-down 전략
• Identity 전략

---

1.Roll-Up전략

일단 먼저 그냥 단순하게 구현하는 방법에 대해 생각해보자.

그냥 사람이라는 한 테이블만 만들고 모든 속성을 이 사람 테이블에 다 때려박는 방법이 하나 있다.

즉, 하나의 물리적 테이블로 통합해서 구현한 것이다.

 

사람이라는 엔티티를 만들고 사람이 가지는 속성과  학생 고유의 속성인 학과,학년,학번도 넣고 교수 고유의 속성인 교수번호,연구실도 넣고 직원 고유의 속성인 직원번호,직급 이 모든 필드를 다 넣었다. 그리고 type 칼럼으로 학생인지 교수인지 직원인지 구분한다.(속성에 대한 예시가 완벽하지 않으나, 그냥 전반적인 이해를 위해 넘어가자)

즉, 모든 속성을 하나의 테이블에 두고 type컬럼으로 구분하는 방식이다.

당연히 이렇게 안할 것이다. null값도 많이 생기고 유지보수에서도 최악이다.

 

 

2.Roll-down 전략

그렇다면 가장 일반적으로 짠다고 생각하면 그냥 학생,교수,직원 3개의 엔티티를 만들고 사람의 공통된 속성(이름,성별,주소,연락처)는 각각의 엔티티의 속성으로 들어가는 것이다.

즉, 슈퍼타입 없이 서브타입만 존재하면 공통 속성을 각 서브타입 테이블에 중복되어 저장시키는 형태다

이렇게 하면, 테이블 구조가 단순하고 조회시 조인이 필요없다.

(조인이 필요없다는 것은 아래 전략을 보고오면 이해가 될 것이다)

그러나 공통된 속성이 변경시 모든 테이블 수정이 필요하다는 단점이 있다. 예를 들어 주소필드의 타입을 VARCHAR(100)->VARCHAR(200)바꾼다거나 하는 향후 유지보수가 발생시 모든 서브타입 테이블을 하나씩 수정해야한다. 

3.Identity

공통된 속성을 지닌 슈퍼타입의 엔티티를 만들고 서브타입 테이블은 고유속성을 가진 채 슈퍼타입의 기본키를 외래키로 사용하여 연결하는 형태다. 이때 슈퍼타입의 id가 서브타입의 외래키id값이 될 것이고 이거를 하나로 연결하여 사실상 하나의 아이덴티티(?), 즉 한 개체가 되는 형태인 것이다. 

 

db 설계시 데이터 중복을 최대한 제거한 형태라 정규화가 잘되어 있고 공통 속성 수정시 하나의 테이블만 수정하면 된다는 점에서 유지보수 측면에서 좋다.

다만 이 방식은 조인쿼리가 필요하다.

예를 들어 한 학생에 대한 정보를 조회할 때 사람과 학생 테이블을 조인하여 결과를 가져와야한다.

또한 한 객체를 추가할 때도 사람테이블에만 데이터를 추가시키는 게 아니라 연관된 테이블에도 데이터를 추가해야한다.

 

---

 

그렇다면 공통속성과 특수속성을 가진 객체에 대한 모델링을 할 때 어떤 전략이 좋을까?

당연히 Roll-up전략은 완전 아니니까 넘기고, 사실상 Roll-down과 Identity전략 둘 중 하나다.

나 같은 경우는 아직까지는 직관적이고 무엇보다 굳이 조인을 쓰지 않아도 되는 Roll-down 전략이 좋다고 생각한다.

그러나 실제 실무에서는 Identity 전략이 많이 쓰이는 곳도 있는 것 같다.

실무에서는 데이터의 정합성과 특히 유지보수성이 더 많이 신경쓰이게 되고 하나의 슈퍼타입을 기준으로 통합 조회하거나 분석하는 일도 많기 때문이라고 한다.

 

그럼에도 불구하고, 대규모 서비스를 생각한다면 Identity 전략은 지양해야하는게 아닌가 싶다.

왜냐하면 공통된 속성을 지닌 슈퍼타입 테이블이 너무 비대해지기 때문이다.

예를 들어, 어떤 교수만 조회하면 되는데 이 경우에는 사람에 JOIN 을 걸어 사람테이블과 교수테이블을 같이 조회해야한다. 그런데 슈퍼타입인 사람 테이블에는 교수 뿐만 아니라 학생,직원 너무나 많은 회원들의 row도 함께 있다.

이 경우 교수가 아닌 학생,직원 row까지도 탐색해야하므로 조회나, 검색같은 성능의 질이 떨어질 것이다.

type = 교수라고 WHERE 조건을 걸고 조회한다해도 필터링 하는 데서도 작업이 일어나니 대규모 서비스를 생각한다면 그냥 중복데이터를 감안하더라도 Roll-down으로 각기 테이블을 분리하는게 맞을 듯 싶다.