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

집합 형태의 최종 결정

데이터 집합을 크게 묶어서 통으로 가져갈지, 아니면 필요에 따라 구체적인 여러 개로 나눌지 결정하는 일은 어렵다. 예를 들어 사람을 하나의 집합으로 관리할지,  남자/여자로 나눌지, 유러피안/아시안/아프리칸 으로 분리할지, 그것도 아니면 남자+아시안/남자+유러피안/남자+아프리칸/여자+아시안/여자+유러피안/여자+아프리칸과 같이 개별 관점의 조합(2*3) 수 만큼으로 분할하지 결정하는 것은 대단히 어렵다. 다만 집합을 어떤 형태로 분리하든 그 덩어리 집합의 정체성이 명확하만 하다면 충분히 엔티티로서의 가치를 지닐 것이다. 문제는 그렇게 정의한 단위 집합이 얼마나 합리적이냐 하는 것이다. 모델링에서 이 단계가 가장 어려운 이유는 합리성이 인간의 종합적인 분석력,사고력,통찰력을 필요로 하기 때문이다. 또 이러한 분석과 통찰에는 업무규칙, 데이터의 사용 패턴, 성능 등을 포함한 여러 환경적 요소가 복합적으로 고려되야 한다.

 

집합은 구체적인 부분집합으로 분리할 수 있고, 집합의 성격을 확장해 다른 집합과 통합할 수도 있다. 여기에 한가지를 더해, 때에 따라서 일부를 중복 시킬 수도 있다. 물론 중복은 일반적으로는 바람직하지 않으니, 특수한 목적 때문에 중복하는 것임을 명확히 하고 사용하여야한다. 앞서 성격이 유사한 집합들은 적극적인 통합을 하더라도 집합의 본질에는 큰 영향을 미치지 않는다고 했다. 그에 반해, 유사하지 않은 집합을 무리하게 통합하면 집합의 정체성이 모호해지고 본질이 호도된다.

일상에서 흔히 접할 수 있는 예를 통해 집합의 형태를 구분하고 결정하는 원칙에 대해 알아보자 

 

그림 12-5 데이터 아키텍처 관련 자료를 관리하기 위한 폴더 구조

새로 산 PC에 데이터 아키텍처 관련 파일들을 관리하기 위해 [그림 12-5]와 같은 폴더 구조를 만들었다고 가정하자. 그런데 진흥원 자료는 모델링과 튜닝 및 표준화자료가 섞여 있다고 한다.  왜냐하면 진흥원 자료는 워낙 컬러가 강해, 비록 모델링과 성능 관련 파일이라 다른 폴더에 이미 존재하더라도, 별도의 폴더에 두어 참조하겠다는 명확한 기준을 세웠다. 또한 데이터 표준화 관련 자료는 큰 틀에서 모델링 영역에 속한다고 보고 <01. 모델링> 폴더에 통합하기로 했다. 그리고 선을 관련 모델링 자료는 모델링에 우선순위를 두어 <01모델링> 폴더에만 저장하기로 했다. 즉, 성능 관점의 모델링 자료지만 <02.성능,튜닝> 폴더에는 존재하지 않도록 하겠다는 뜻이다. 이상과 같은 규칙을 통해 폴더의 의미와 정의가 구체화되었다. 당연히 폴더에 저장될 자료들 역시 명확해 질 것이다. 

 

💡 tip) 데이터 표준화

데이터 표준화는 시스템별로 산재해 있는 데이터 정보 요소에 대한 명칭, 정의, 형식, 규칙에 대한 원칙을 수립하여이를 약속된 그룹내에 적용하는 것을 의미한다. 이러한 데이터 표준화 작업은 데이터의 정확한 의미를 파악할 뿐만 아니라 데이터에 대한 상반된 시각을 조정하는 역할을 수행한다.

이는 일상에서 누구나 한 번쯤 고민해봤을 상황이면 이런한 맥락과 엔티티의 통합, 분리는 사실 크게 다르지 않다. 이제 폴더 구조에 대한 고민이 엔티티 통합, 분리, 중복의 관점에서 무엇을 시사하는지 알아보자

 

그림 12-6 사원과 인턴을 개별 엔티티로 관리하는 모델

인턴으로 들어온 A라는 사람 개체가 있다고 가정하가. 이 개체정보의 학력과 가족 관계등 상세 정보는 <인턴>의 하위 엔티티에 다양하게 연결되어 있다. 근데 A가 인턴 생활을 끝내고 이 회사의 정식 사원이 되었다. 이때 [그림 12-6]과 같이 <사원>과 <인턴>이 개별 엔티티로 존재한다면 <사원> 엔티티에도 이제는 A의 정보가 존재해야한다.(혹은 회사의 업무 규칙에 따라 <인턴>에 있던 기존 정보는 삭제하고 그대로 사원 쪽으로 이관되어야 할지도 모른다.)

 

인턴에서 사원으로 위치가 바뀌긴 했지만. 어째든 동일한 개체임에 불구하고 <인턴>과 <사원>양쪽에 개별 식별자를 가지게 되므로 이 둘이 동일한 개체라는 것을 명시해주어야 한다. A가 더 이상 인턴이 아니라고 해서 <인턴> 엔티티에서 삭제한다면 인턴 기간에 발생한 평가 결과 등 상세 정보도 같이 삭제되고 만다. 왜냐하면 인턴 기간의 발생한 평가 정보는 <인턴> 엔티티에 종속되어 있기 때문이다.

 

이처럼 고민스러운 상황도 두 엔티티를 통합하는 순가 모두 해결된다. A라는 개체는 그대로며 변경된 직책은 서브타입 구분으로 속성값만 사원으로 바꾸면된다. 이미 통합되 수준으로 관리되고 있으므로 인턴 시절에 발생한 정보도 전혀문제 없다.(여기서 통합된 주순이라고 해서 반드시 물리적으로 통합된 하나의 테이블이라는 의미는 아니다. 논리적인 묶음 단위로서의 수준이다.) 문론 회사의 업무 규칙이 인턴 수행 후 대부분 정식 사원으로 채용되는 형태가 아닐 수 있다. 그렇다면 인턴과 사원이 맥락적 관계, 즉 동질성이 거의 없음으로 사원과 인턴 엔티티를 분리하여 독립된 개체로 관리하는 것이 더 바람직할 수 도 있다. 이처럼 통합과 분리의 절대적 기준은 존재하지 않으며 업무 규칙과 상황에 따라 데이터를 바라보는 다양한 관점에 따라 판단되고 결정 될 수 밖에 없다.

 

결국 통합하면 유연성이 좋아지고 구조가 단순해진다. 데이터 모델에서 유연선은 비지니스가 변화해도 구조 변화가 최소화된다는 뜻이다. 다시 말해 기존 엔티티에 속성이 추가되거나 새로운 엔티티가 생성된다든가, 기존 관계에 변화가 생기는 일이 줄어듦을 의미한다. 비지니스 변화가 데이터 모델이 아니라 데이터값의 변화로 충분이 감당할 수 있도록 하는 것이 모델이 유연성을 갖도록 하는 것이다. 구조 변경이 아닌 부분집합의 증가나 행의 추가로 나타나도록 유도하는 것이다.

---

그림 12-7 형태 #1 - 물리 개체와 논리 개체의 통합

논리 개체와 물리 개체를 관리하는 세 가지 방법에 대해 알아보자. 게시글 [데이터 모델링6 - 엔티티의 본질]에서 은행, 직원, 고객, 물품 공급자 역할을 하는 은행원의 예를 기억할 것이다. 그 은행원의 이름을 '최영희'이라 하고, 지금 까지 학습한 내용을 바탕으로 최영희 개체를 얻허게 담을지 고민해보자. 직원, 고객, 사무용품을 공급하는 개인 사업자로서의 행위 주체는 이제부터 설명하듯이 여러 형태로 모델링할 수 있다.

 

[그림 12-7]의 형태#1은 물리적인 개체와 논리적인 개체를 <은행전사관계자> 하나로 통합한 경우다. 자연인 이영희와 직원, 고객, 공급자로서의 논리적 역할 개체까지 총 4개의 인스턴스가 ID1001 ~ ID1004의 서로 다른 식별자로 존재한다. 자연인 이영희 개체와 논리적 역할의 이영희 개체들을 동일인으로 인식시켜줄 관계 엔티티가 필요함을 알 수 있다.

 

그림 12-8 형태 #2 - 물리 개체와 논리 개체의 통합. 단, 개별 속성은 1:1 분리

[그림 12-8]의 형태 #2는 첫 번째 모델과 같지만, 통합 엔티티에는 주 식별자와 최소한의 공유 속성만 만기고 나머지는 1:1 역할로 엔티티로 분리한 경우다. 자연인 이영희과 역할별 이영희는 역시 다른 식별자를 가지면 여전히 관계 엔티티가 필요하다.

 

그림 12-9 형태 #3 - 물리 개체 기준으로 식별자 생성. 역할별 엔티티는 별도로로 식별자 상속 

[그림 12-9]의 형태 #3은 물리 개체를 기준으로 식별자를 생성하며, 역할별 엔티티는 별도로 만들어 상위 물리 개체의 식별자를 상속받는다. 따라서 관계 엔티티는 불필요하며 엔티티명이 역할명이 된다.

 

형태 #1은 역할별 개체의 식별자가 다르므로 데이터로 개체의 역할 확인이 가능하다. 다만 통합된 모델이다 본니 역할 하나의 개체에 속성이 너무 많이 존재하게된다. 관계 엔티티 추가가 필요하다. 형태 #2는 #1과 유사하며 개별 속성을 분리된 역할별 엔티티로 확인 할 수 있어 가독성에 이익이 있다. #3은 물리 개체와 논리 개체의 식별자가 같아져서 관계 엔티티가 필요 없지만, 데이터만으로 역할을 확인할 수 없다.

 

이제 상위의 묶음 단위가 생겼다는 것이 어떤 의미인지 이해했을 것이다. 데이터 모델링에서 이러한 묶음의 단위, 즉 수준의 개념은 정말 중요하다. 패키지 솔루션에서는 이러한 묶음 단위를 만들기 위해 헤더 정보만 위로 올리고 상세 정보는 하에서 관리하는 등의 처리를 하는 경우도 많다. 주의할 점은 집합의 통합과 곽장의 반드시 본질이 유사한 것들을 대상으로 해야 한다는 것이다. 

 

정리

최상위 부모 엔티티들은 상대적으로 너그럽게 통합되어도 괜찮다. 만약 하위에서 배타적 관계가 많이 나타난다면 분리한 것에 문제가 있어 상위 개체가 통합되어야 한다는 신호로 보아야 한다. 물론 무리하게 통합하여 집합의 본질이 희석되면 안되니, 통합은 반드시 데이터의 성격과 정체성의 기반해야한다.

---

그림 12-10 교집합이 있는 경우

마지막으로 교집합이 있는 경우의 처리 기준을 알아보자.

 

집합 간의 교집합이 있으면 1)중첩된 개체를 한쪽 집합에만 존재하도록 그 소유를 분명하게 정의하는 것이 하나의 방법이 될 수 있고  2)집합의 중복되도록, 즉 개체가 여러 집합에 공존하게 하는 것이 그 대안이 될 수 있다.

 

1)과 같은 방법은 개체의 소속을 명확하게 하지만. 새로운 형태의 집합이 발생했을 때 대응할 수 있는 유연성은 떨어진다. 그래서 확장성보다 집합의 의미를 구체적으로 정의하는 쪽에 비중을 두어야 할 때 사용한다.

 

2) 와 같은 형태는 일반적으로 바람직하지 않지만, 현실적으로는 충분히 발생할 수 있는 유형이다. 사실 엔티티를 정의할 때 어느 정도의 중복은 피할 수 없다. 통합했더니 좋지 않았고, 반대로 분리했더니 기존 집합의 의미가 훼손되어 중복을 명확히 인지하서 허용한 경우라고 보면 된다. 집합의 독자적인 존재 가치가 있는 경우로, 앞서 설명한 폴더 구조 사례(그림 12-5)에서 <03.데이터베이스진흥원자료>폴더가 이에 해당한다.

 

 

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