어떤 경우에 통합을 고려하는가?

지난 달에 프로젝트를 마치고 중국 여행을 다녀왔습니다.

빚을 내서라도 애들하고 여행하라는 글을 자주 봐서 이번에 빚을 냈습니다. ㅎ

 

사실 여행에 대한 중요성은 이미 알고 있죠. 여유가 없었을 뿐이죠.

여행을 하면 시야가 넓어집니다.

많은 생각을 할 수 있어 좋고… 홀로 3개월을 돌아다니던 그때가 생각나네요.

 

어쨌든 고생해서 여행은 갔다왔는데 마음이 풀렸는지 블러그 슬럼프가 왔습니다.

그래서 다시 마음을 다잡고 글을 올리려고 합니다.

 

오늘부터 데이터를 통합할 수 있는 여러 가지 경우를 설명하겠습니다.

어떻게 통합하느냐에 대한 얘기보다 어떤 것(무엇)을 통합하느냐에 대한 얘기입니다.

 

가장 원론적인 원칙이 데이터의 성격이 유사할 때입니다.

 

- 데이터의 성격(본질)이 유사할 때, 즉 집합의 정의가 유사할 때

 

데이터의 성격이 개념(본질)적으로 유사하면 통합할 수 있습니다.

주로 핵심적인 실체를 관리하는 데이터 중에 본질을 따지면 유사한 경우가 많습니다.

 

[그림1]은 계좌를 관리하는 엔터티입니다. 주식을 거래할 수 있는 계좌와 선물옵션을 거래할 수 있는 계좌, 수익증권을 거래할 수 있는 계좌가 별도로 존재합니다.

[그림1]

 

계좌는 계약을 통해 개설되는, 거래를 위해 사용하는 매개인데요. 거래되는 자산에 따라 계좌를 분리할 이유는 별로 없습니다.

 

거래 대상(상품)이 무엇이 되더라도 각각의 계좌 엔터티에서 관리하는 속성(기초 속성)은 기본적으로 유사합니다. 계좌라는 본질이 같기 때문이죠.

유사하지 않은, 계좌별로 고유한 속성은 별도의 엔터티에서 관리할 수 있고요.

 

[그림2]와 같은 고객 데이터는 또 다른 1순위 통합 후보입니다. 개인 고객과 법인 고객, 더욱 확장하면 가망 고객¹⁾까지 관리 속성은 본질적으로 유사합니다.

[그림2]

 

고객의 이름, 연락처 등의 기본 데이터를 관리하는 속성(기초 속성)을 통합하고 차별화된 일부 개별 속성은 별도로 관리하는 방법은 거의 정형화됐습니다.

 

슈퍼타입과 서브타입이 생성되는 일반적인 통합 모델이죠.

이젠 마치 바둑처럼 정석화됐지만, 아직도 통합이 안 되는 경우가 있습니다.

 

다음 글에서 그 이유를 간략하게 설명하겠습니다.

 

 

1) 흔히 계약 성사 여부를 기준으로 고객 범주를 판단해 가망 고객이 통합에서 제외되는데, 데이터 통합의 판단 기준은 데이터 본질이 돼야 하므로 가망 고객도 통합하는 게 맞다고 생각합니다.