데이터 모델링26 - 데이터 집합의 분리, 확장, 통합2

엔티티 통합과 테이블 통합

엔티티 내부를 들여다보면 서브타입은 엔티티가 어떠한 개체 유형들의 집합인지 상세히 규명하는 도구로 활용될 수 있음을 확인했다. 서브타입에 대해 고민하다 보면 통합의 결과로서 서브타입을 포함한 큰 집합이 만들어지는 것인지, 아니면 집합을 분할하기 위해 서브타입을 기준으로 분리해야 하는 건지 모호할 때가 있다. 집합의 통합과 분리를 이야기할려면 앞서 언급한 논리 모델과 물리 모델의 경계, 그리고 엔티티 통합과 테이블 통합을 구체적인 기준을 가지고 구분해야한다. 먼저 논리모델과 물리 모델을 통합과 분리라는 관점에서 다시 살펴보자

 

테이블, 파티셔닝 수준의 물리 모델링 단계에서 반드시 수반되는 것이 논리 모델의 수정이다. 논리 모델은 업무에서 어떤 데이터가 어떻게 발생하고 존재하는지 인간이 이해하기 좋은 수준으로 묶은 형태다. 다시 말해 현실 업무의 모습을 정형화하여 박스와 관계선으로 표현하며, 설계자와 사용자 등의 이해관계자가 쉽게 이해할 수 있도록 하는데 그 목적이 있다. 따라서 논리 모델이 실제 물리모델에 구현될때는 수정이 불가피하다. 논리 모델은 DBMS나 이를 운용하는 하드웨어를 위한 것이 아니기 때문이다.

 

반면 물리 모델은 말 그대로 물리적 요소인 하드웨어가 최고의 성능을 발휘하도록 만들어야 한다. 

 

그림 12-4 게시판 모델 - 분리한 형태(왼쪽)와 통합한 형태(오른쪽)

[그림 12-4] 의 왼쪽은 <게시물> 집합을 정의하고 그 하위 요소로 <첨부파일>을 별개의 집합으로 정의하고 관계로 관리하는 모델이다.(이 때 첨부파일은 게시물 당 1개만 가능하다고 가정한다.) 이처럼 둘을 분리하여 표현하는 것이 개별 정보가 발생하는 시점이나 데이터 집합의 의미 차이를 인간이 이해하는데 도움이 된다.

 

하지만 물리 모델링에서는 이러한 관점들을 통합하는 등 논리 모델에 칼을 대는 작업이 수반된다. 힘들게 도출하여 정의하고 분리하고 유형화한 개체들을 다시 모으는 작업이 이해되지 않을 수도 있다. 하지만 모델링은 점진적으로 상세히 업무데이터를 그려가는 과정이다. 논리 모델은 정규화 이론에 기반하여 데이터 무결성을 극한 까지 끌어올리는 것이 좋을수 있다. 반면 물리 모델은 논리 모델의 무결성과 정합성을 깨는 것을 최소화하면서 성능 위주로 트랜잭션시 성능을 최적화하는 데 목표가 있다. 이 둘의 목적과 관점은 유사한듯 다르다.

 

지금까지 논리 모델과 물리 모델에 대한 이해도를 높였다면, 좀 더 확장하여 엔티티 통합과 테이블 통합을 구분해보기로 하자.

 

논리 모델에서 통합할 것이지 분리할 것인지 애매한 집합은 일단 통합하고 시작한다. 그리고 상세화하는 과정에서 분리하는 쪽이 효율적이라 판단되면 물리 모델로 넘어가기 전이라도 분리를 하고, 그렇지 않다면 통합된 상태로 두면된다. 그런데 정규화라는 것이 결국 함수 종속성에 기반하여 집합을 분리하는 것이라고 볼 수 있으니, 일단 통합상태로 두는 것이  정규화에 배치된다고 생각할 수도 있다. 하지만 그것보단 이것을 관점의 차이라고 생각하면 좋다. 여기서 말하는 통합은, 법인 고객이라는 집합이 있다고 가정하면 집합의 범위를 확장해서 통합 고객으로 관리하는, 즉 개인 고객까지 동질성을 확대한 집합으로써 고객을 관리하는 관점에 도달하는 것이 그 예이다.

 

통합과 분할의 일차적 기준은 데이터의 성격이어야 한다. 데이터가 비지니스적으로 말하고자 하는 주제, 데이터 정체성, 본질을 기준으로 하되 상위 엔티티들, 즉 업무 행위의 주체와 대상, 그리고 업무 행위의 최상위에 놓이는 Account 등이 1차 타깃이다. 다시 말해 마스터 데이터들은 유사하다는 기준을 다소 관대하게 적용해서 강하게 통합해도 괜찮다. 단, 통합된 것들의 독립성을 유지하기 위해 서브타입을 명확히 표현해야 한다.

 

계층 최상위 엔티티들을 통하하기는 이유는 통합하지 않을 경우 모델 구조가 복잡해지기 쉽고, 그에 따라 SQL 구현 난이도 어려워지고, 성능 이슈 등 위험요소가 많지며, 업무 변화에 유연하게 대응하기도 어렵게된다. 무엇보다 상위 계층의 복잡도로 인해 하위 엔티티는 더욱 복잡하고 성격 또한 불명확하게 된다.

 

데이터 모델링에서 주제영역(subject area)이라고 흔히 부르는것이 바로 이러한 최상위 엔티티들이 다시 추상화된 영역이라고 보면된다. 그리고 업무 행위, 즉 트랜잭션수준의 엔티티도 그것들의 하위 엔티티들과 유사성을 기준으로 통합할 수 있다. 이러한 관점으로 논리모델은 통합되어야 한다. 다만 앞서의 <게시물>-<첨부파일> 예처럼 업무데이터를 사람이 인식하기 좋은 수준으로 분류하는 논리적 모델을 위한 작업은 다른 관점의 이야기이다.

 

논리 모델 분리와 관련해서 주의할 점이 있다. 결국에 물리 모델 단계에도 집합을 분리하게 되라라 판단을 일찍감치 분리해버리는 편이 바람직하다. 상위 모델의 골격이 바뀌면 하위 엔티티와 관계 등 전반적인 형태가 틀어지는 등 영향도(side effect)가 크기 때문이다. 하지만 통상적으로 상위 엔티티는 통합된는 것이 이익이 많으니 분리할 때는 충분한 검토가 필요하다.

 

그림 11-16 서브타입으로 상세화된 집합을 테이블로 전환하는 세가지 기준

 

이제 테이블 통합을 생각해보자. 앞서 스토리 11에서 서브타입의 물리 모델 전환 방법엔느 3가지가 있다고 했다(그림 11-16)

 

1. 하나의 테이블로 통합(Roll-Up)

2. 서브타입별 테이블로 분할분리(분리, Roll-Down)

3. 공통 속성만 통합하고 공통적이지 않은 속성은 1:1로 분할(혼합,Hacksaw)

 

여기에 한 가지 더 추가해서 기본 키(Primary Key:PK)와 최소 속성만 통합하고 나머지(공통적으로 갖는 속성)는 모두 분할하는 방법도 있을 수 있다. 

 

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