데이터 모델링19 - 데이터에는 유형, 종속관계, 계층구조가 존재한다3-2

최상위의 데이터, 마스터 데이터2

그림 9-6 서비스 제공을 위한 개념 모델

[그림 9-6]은 고객에게 서비스 상훔을 제공하고 계약 기간 동안 비용을 청구하는 일반적인 기업의 데이터 모델 원형에 가까운 개념 모델이다. 다소 복잡해 보일 수도 있으나 구조적인 관점에서 보면 크게 어렵지 않다. <고객>은 다수의 <서비스상품>을 포함하는 <서비스계약>을 할 수 있고, 이 계약의 실사용자와 명의자는 다를 수 있다. <서비스계약>에 대한 비용 청구는 <청구계정>이라는 단위로 이루어진다. 여기서 하나의 <청구계정>은 일반적으로 하나의 <서비스 계약>과 관계가 있으나, 다수의 <서비스계약>을 묶을 수도 있는 구조다.

 

청구 부분에 집중해보자. 서비스업체(누가)가 고객(무엇)을 대상으로 청구라는 업무행위를 하는 것이다.(업체는 명확한 단일 개체이므로 모델에서는 생략되었다.)이 청구에 대해 고객에게 돈을 받는 업무 프로세스가 분명 존재할 것이다. 그러면 돈을 받는 행위의 주체는 누구일까? 서비스를 제공한 업체인가? 여기서 잘 생각해 보아야한다. 데이터 모델링 관점에서 돈을 받는 주체는 업체가 아니라 '청구'라는 행위가 된다. 다시 말해 사람도 사물도 아닌 다른 업무 행위가 주체가 된다.

 

예를 들어 3~5월분 요금을 연체 중인 고객이 돈을 납부하면 통신사가 3월분 미납금부터 순차적으로 제거해나가는 것이 아니라, 고객이 특정한 청구 건인 4월분 미납 금만 낼 수도 있도록 하는 것이 일반적이다. 만약 전자와 같은 업무 규칙을 갖고 있다면 수납의 주체는 업체가 맞다. 그러나 고객이 특정 청구를 명시해서 돈을 낸 것이라면 업체가 아니라  청구 그 자체가 고객에게 돈을 요구한 셈이 된다. 즉, 청구라는 행위가 다른 해위의 주체로 상승한 것이다.

 

이러한 개념을 이해하지 못하면 수납 엔티티의 관계선을 청구에 긋지 못하거나 청구라는 중요한 엔티티를 도출하지 못하게 된다. 이로 말미암아 모델의 골격이 틀어지며 데이터는 정확한 단위로 관리되니 못한다. 결국 프로그램은 수많은 예외 처리로 복잡도가 급격히 높아져서 유지보수라기도 벅찬 모습이 되어 버린다.

 

그림 9-7 유형 관점에서 정리한 데이터 모델

앞의 데이터 모델을 위화 같이 엔티티의 유형으로 정리해보면 모델의 계층구조와 패턴이 더 또렷이 드러난다. 모델이 다단계로 부모 - 자식 관계를 갖는 이유는 업무 행위이가 다른 업무 행위의 주체가 될 수도 있고, 논리적인 개념 역시 상위 집합에 위치할 수 있기 때문이다.

 

<서비스계약>엔티티는 특정 <고객>이 <서비스상품>을 대상으로 계약이라는 행위를 한 트랜잭션 엔티티다. 계약과 상품의 관계 때문에 별도의 <계약별상품> 엔티티가 관계 엔티티로 추가된 것이다. 동시에 <서비스계약 > 엔티티는 <계약상품별사용량>이라는 또 다른 트랜잭션이 태어나게 한 부모 역할을 한다.

 

정리해보면 데이터 모델은 'A와 B가 C를 낳고, C는 D와 만나 E를 낳고...'와 같은 다단계 계층을 이루게 되므로, 모델링을 할 때나 기존 모델을 분석할 때는 족보의 뿌리를 찾아가듯 최상위의 행위자와 행위 대상을 명확히 정의하고 식별해야 한다.

 

지금까지의 설명을 기반으로 개념 데이터 모델을 그리는 순서를 살펴보면 다음과 같다. 이 순서는 운영 중인 데이터베이스에서 데이터 모델을 추출하는 리버스 모델링에도 그대로 적용된다.

 

http://www.gurubee.net/lecture/3644

리버스 모델링

 

1. 최상위의 고객과 상품을 찾는다.

2. 고객과 상품 수준의 다른 주체와 대상도 찾는다.

3. 고객과 상품이 행한 업무 트랜잭션(주로 계약 수준)을 찾는다.

4. 트랜책션을 주체로 이루어진 하위 트랜잭션을 찾는다.

5. 관계를 찾아 연결한다.

6. 각 엔티티를 주요 속성부터 채워간다.

7. 이력(log)등 기타 엔티티를 고려하며 전체 모델을 상세화한다.

 

[출처 - 프로젝트의 성패를 결정짓는 데이터 모델링 이야기 , 김상래 저]