서브타입 해체하기

지난번에 서브타입에 대해 소개해 드린적이 있습니다. (서브타입 사용하기)

그때 서브타입은 Relational Database에서 구현할 수 없는 개념적인 것이니 언젠가는 없애야 한다고 했었지요. 오늘은 그 해체 작업을 어떻게 하는지 살펴보도록 하겠습니다. 

최근에 모델을 보다가 조금 특이한 서브타입 구조를 발견했습니다.

신청처리는 신청 자체를 접수하는 것도 있고, 승인하는 것도 있는데, - 여기까지는 일반적인 서브타이핑이죠 - 그 승인이 신청에 의거하여 발생 하기도 하고, 또 가끔은 그냥 승인 처리만 일어나기도 하는 경우입니다. 

약간 사족을 달아보자면, 양쪽이 optional 인 관계는 사용을 지양!해야하는 관계 유형 입니다. 왜냐하면 양쪽이 optional이라는 것은 매우 약한 관계이다보니 서로 관계없는 엔터티 간을 연결 해놓는 경우가 많거든요. 이런경우 실제 누적된 데이터를 살펴보면 양쪽 테이블 간 관계되는 데이터가 거의 전혀 발견되지 않습니다. 하지만 이번에는 잘못 사용된 사례는 아니었구요 (연관된 데이터들이 실제 꽤 들어 있었기 때문에) 양쪽이 optional이기 때문에 서브타입으로써 용인될 수 있는 경우라고도 생각됩니다. 만약 한쪽이라도 optional이 아니라고 한다면 서브타입의 대상이라기 보다는 일반적인 업무 흐름으로 접수:승인 이 1:N으로  연결되는 것이 훨씬 자연스럽거든요. 

이제다시 본론으로 돌아와서요. 이러한 서브타입을 어떻게 해체할 수 있는지 보도록 할께요.

흠... 조금 욕심을 내다보니 서브타입 엔터티(접수,승인)간 관계가 있는 예제를 가지고 설명을 드리게 되어서 다소 복잡하다 느끼 실수도 있겠네요. 관계 이해가 어려우시면 엔터티 위주로 보셔도 전체 맥락 이해에는 지장이 없습니다. ;-) 

첫째로 접수와 승인에 특화된 속성이 많지 않거나, 전체 건수가 많지 않거나, 조회시에도 접수와 승인건을 함께 보는 경우가 많다면 수퍼타입(신청처리)과 서브타입(접수, 승인)을 하나로 통합할 수 있습니다.

그럼 이런 모양이 되죠. 이렇게 정리하는 것을 Roll-up 이라고 부르기도 합니다.

둘째로 접수와 승인이 따로따로 특징이 뚜렸하면서 조회도 따로되는 경향이 있다면 서브타입(접수,승인)에 해당하는 두 개의 엔터티로 처리 할 수 있습니다. 그럼 신청처리의 속성은 접수에도 승인에도 중복해서 존재하게 되겠지요. 이걸 Roll-down이라고 부르기도 하더군요.

셋째로 각각의 속성의 개수가 많으면서, 화면에서 신청처리 전체 리스트를 보여주다가 개별 건을 조회한다든지 하는 형태로 사용되는 경우라면 하나하나를 별도의 엔터티로 구성하는 방안을 생각해 볼 수 있습니다. 

그때는 이런 형태를 가지게 됩니다.

지금까지 서브타입을 해체하는 방법 세가지를 살펴 봤습니다.

어떠한 형태로 서브타입을 해체할 것인지는 속성의 개수, 데이터의 건수, 조회 형태 등을 분석해서 결정하게 됩니다. 어짜피 없앨것을 왜 서브타입을 쓰는가 하실 수 있지만, 서브타입은 업무를 이해하는데 유용해서 그 자체로써 의미가 충분히 있습니다. 모델을 작성하면서 필요하다 생각될 때는 과감히 사용 하시구요, 충분히 모델을 통해 업무를 이해해서 해체방안을 명확히 결정할 수 있을정도의 정보를 파악한 시점에 해체를 하시는게 올바른 접근이 아닌가 생각합니다.