서브타입 사용하기

오늘은 서브타입에 관한 이야기를 해보겠습니다. 아래와 같이 생긴것이 서브타입인데요.

( 앗... 무료 툴인 DB Designer 에서는 서브타입 관계가 제공되질 않네요. 그래서 부랴부랴 파워포인트로 그렸습니다. ERwin에만 너무 익숙하다보니 당연하게 있을거라 생각했습니다. 그런데, 데이터베이스에 구현할 수 없는 개념이고 보니 가벼운 도구들에서는 생략할 법도 하다는 생각이 드네요. :-) )

 

 

상위(수퍼타입=대출자) 엔터티가 하위(서브타입=직원,회원)의 몇가지 유형으로 나뉠때 이를 표현하는 방법입니다. 예제에서와 같이 대출자는 직원과 회원이 있구요, 사람은 남자와 여자가 있구요, 동물은 사자와 호랑이... 이쯤되면 아 객체지향의 상속과 유사하다는 점을 떠올리시는 분들이 꽤 있을 것 같습니다. 네 개념상 정말 많이 유사합니다. ;)

 

그렇지만 '난 이런기호 ERD에서 못 봤다!'하는 분들이 많을텐데요. 실제 데이터베이스에는 구성할 수 없는 개념적인 모습이기 때문입니다.

 

그렇다면 구현단계에는 없어질 수밖에 없는 이 기호를 왜 쓰는걸까요? 필요할까요?

네... 저는 확실히 필요하다고 생각합니다.

데이터 모델링의 초기인 개념 모델링 단계에서는 업무를 간단히 표시하고, 쉽게 이해하는 것이 가장 중요한데, 이때 효과가 있기 때문입니다.

대출은 어떤 사람들이 하는건지, 대출하는 사람의 유형에 따라서 어떤 데이터가 다르게 발생하는지를 한눈에 파악할 수 있거든요.

 

하지만 필요한 곳에 사용해야 하는데요. 그 판단 기준은 다음과 같습니다.

첫째, 서브타입 중에서 일부만이 가지는 추가적인 관계가 있다면 이때는 망설이지 말고 서브타입을 그리세요.

 

이때에는 대출자 중에서도 회원만 회원증을 갖는다는 정보를 확실하게 전달할 수 있으니까요. 

둘째, 서브타입에 따라 가지고 있는 속성이 달라지는것이 있어야 합니다. 이게 기본인데, 그 속성이 많을 수록 필요성이 높다고  보면 됩니다. 대출자로써의 직원은 직원번호 정보가 있어야 하는데, 직원은 필요없다든지 하는 경우입니다.

 

셋째 서브타입은 구분자가 매우 중요합니다. 수퍼타입은 해당 데이터가 서브타입 중 어느 유형에 해당하는 지를 결정해 줄  수 있는 구분자를 가지고 있어야 합니다. 그런데 이것이 '구분 유형'이어야지 '상태 유형'이면 안됩니다. 만약 회원이 '접수 신청 중 회원'에서 처리가 되고 나면 '정식 회원'이 되는데, 이 둘을 별도의 서브타입으로 뽑는것은 상태 유형이기 때문에 안된다는 말입니다.

 

 

그렇다면 여기까지 읽으셨으니 일단 서브타입이 필요하다는데는 동의하셨다 치구요, :-) 서브타입이 잘못 적용된 사례를 좀 알아 보도록 하겠습니다.

 

수퍼타입과 서브타입은 본래 동일한 실체이기 때문에 관계가 1:1 입니다. 따라가 키가 동일해야 하지요. 그런데, 서브타입 중 하나가 동일한 키로는 식별이 되지 않는 경우가 있습니다.

 

 

위와같이 대출은 일반대출과 기간 연장을 위한 대출이 있다고 모델링 했는데, 업무 규칙 상  연장은 대출 한건에 대해 여러번 등록 할 수 있다면 위 내용은 잘못된 서브타이핑이 되는 겁니다. (물론 상위의 대출 엔터티가 실제 책을 빌려가는 행위에 대해서만 한 번 씩 발생하는 개념이라고 전제 해야 겠죠.) 

누가 저렇게 서브타입을 뽑겠냐고 하실 수 있겠지만, ERD 검토에서 종종 발견됩니다. 처음에는 서브타입을 키까지 점검해서 잘 구성해 두었겠지만, 서브타입이라는 건 유연한게 장점이니까 하면서 서브타입을 이것저것 추가하다 보면 실수를 하게 되죠.

 

레벨이 너무 깊은 경우도 피해야 합니다. 저는 아무리 깊어도 3레벨이 최대다 라고 말씀드리고 싶습니다.

 

 

실제 정보(대출자)는 여러가지 유형을 가지기 때문에 얼마든지 다양하고 깊은 레벨의 서브타입이 가능합니다. 하지만 우리는 시스템을 위한 데이터 모델링을 하는 것이기 때문에 만들고자 하는 시스템에서 의미가 있는 수준에서만 적용해야 합니다.

 

프로세스를 서브타입으로 만드는 것도 지양해야 합니다.

 

 

대체로 주요 프로세스는 아래와 같이 별도의 엔터티로 도출하고 그들간에 적절한 관계를 맺어주는 것이 자연스럽습니다. 위와같이 도서에 이렇게 4가지 유형이 있는 것이 아니라요.

 

 

마지막으로, 데이터 모델링이 마무리되고  데이터베이스로 구축이 되기 전에 서브타입을 없애주어야 한다는 점을 알려드려야 겠네요.

이때는 수퍼/서브타입 모든 엔터티를 통합해 하나의 엔터티로 갈 수도 있고, 아니면 모든 수퍼/서브타입들을 개별 엔터티로 만들 수도 있습니다. 또 그 사이 어딘가 - 몇개는 통합하고 몇개는 분리하는-도 가능합니다.

 

이 결정은 화면에서 한번에 조회하는 정보의 패턴이나  SQL을 살펴보는 것이 가장 중요하구요. 추가적으로 각 서브타입별로 데이터의 기존 량과 증가 속도가 어떤지를 보는것도 필요합니다.

 

오늘은 서브타입에 대해서 살펴 보았는데요. 의외로 많은 분들이 서브타입을 낯설어 하셔서 정리해 보았습니다. 서브타입은 모델링 초기 단계에 이해하기 좋은 모델을 만드는데 꼭 필요한 도구라고 생각하니 친근하게 사용해 보시길 바랍니다.