태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

판다곰과 원숭이와 바나나가 있습니다. 이중 두 가지를 묶는다면 어떤 것을 묶으시겠습니까?”

책을 읽다보면 모델링과 연관해서 생각할 때가 종종 있습니다. 일종의 직업병이죠. 생각하고 싶지 않은데 저절로 생각이 흐르니까 좋지 않은 병입니다.

서양과 동양의 차이를 설명한 책을 읽었는데1), 한 부분을 제가 이해한 방식으로 소개하겠습니다.

아리스토텔레스로 대표되는 서양 사람은 사물의 본질을 잘 파악한다고 합니다. 성격 그대로 생각하는 것이죠. 데이터 본질이 생각나더라고요.

반면, 공자로 대표되는 동양 사람에게는 사물의 본질과 함께 관계가 지대한 영향을 미친다고 합니다. ‘관시(관계)’라는 중국어를 강조하던 선배가 생각났고요. 모델링 관계가 생각났습니다.

서양 사람은 자기 자신을 잘 파악해서 개인주의 성향이 강합니다. 자신 외의 외부에 대해서는 별 상관하지 않습니다.

동양 사람은 타인과의 관계를 중요시합니다. 혼자서는 살아갈 수 없는 존재죠. 어릴 때는 이 말을 인정하지 않았는데, 이젠 어느정도 인정합니다. 나는 내 본질 이외의 것으로 이루어졌다는 것을요.

주제가 벗어났는데... 오늘은 범주에 대한 얘기를 하고 싶었습니다.

서양 사람이 범주라는 단어를 잘 이해합니다. 아리스토텔레스가 범주론2)을 쓴 이유이기도 하죠. 한번 읽어보세요. 모델러에게 도움이 될 것입니다.

반면 장자는 범주론을 경계했다고 합니다. 도덕경에 나온다는 아래 글이 마음에 듭니다.

섯 가지 색으로만 범주화하면, 우리 눈은 멀게 되고
다섯 가지 음으로만 범주화하면, 우리 귀도 멀게 되고
섯 가지 맛으로만 범주화하면, 우리 입맛은 짧아질 것이다

아리스토텔레스를 뛰어 넘는 경지인 것 같습니다. 범주화를 경계했다는 것은 이미 범주화를 했다는 것이니까요. 옆길로 또 샜는데요.

첫 줄의 질문은 동양과 서양 대학생들에게 한 설문 조사입니다. 여러분은 어떻게 묶으셨나요? 저는 주저 없이 원숭이와 바나나를 묶었습니다. 주변에도 물었는데 그렇게 묶었고요. 주저하지 않았습니다. 실험 결과도 대다수의 동양 학생은 그렇게 묶었습니다.

그런데 대다수 서양 학생은 판다곰과 원숭이를 묶었습니다. 판다곰과 원숭이는 동물이라는 동일한 범주에 속한다고 보고 묶은 것입니다. 예상하셨겠지만 동양 학생은 원숭이가 바나나를 먹는다는 관계에 근거해서 원숭이와 바나나를 묶었습니다.

이 질문에 판다곰과 원숭이를 묶으셨다면(아마 거의 없을 듯) 서양인의 피가 흐르거나 특이한 뇌구조를 가지고 있는 것입니다. 동양에서는 살기 힘든

만약 설문이 두 가지를 그냥 묶어라가 아니라(무의식을 살피기 위한), 범주화하라고 했다면 결과가 조금 달라졌을 것 같은데요. 어쨌든 모델링에서 시사하는 바가 있습니다.

세 사물의 특성을 보면 당연히 판다곰과 원숭이가 유사합니다. 속성이 유사하죠. 이는 데이터 통합에 그대로 적용됩니다.

엔터티를 통합하기 위해서는 엔터티의 속성(특성)을제대로 파악해야 합니다. 외부 관계에 현혹되면 안 됩니다. 다른 엔터티와의 관계나 프로세스, 화면, 조직(데이터 오너십) 등과 무관해야 합니다. 본질을 제외한 외부 환경의 작용은 없어야 합니다.

범주화에 대한 이해가 부족해 관계(행위) 엔터티를 실체 엔터티에 통합하는 예도 있습니다. 데이터 통합은 성질이 유사한 것끼리 통합하는 것입니다. 관계가 있는 엔터티끼리 통합하는 것이 아니고요.

모델링 측면에서는 판다곰과 원숭이를 묶는 것이 답입니다. 원숭이와 바나나를 묶었다면 시스템이 힘들어질 것입니다.

고대 그리스인이 사물 자체의 본질을 범주화의 기준으로 삼았듯이 엔터티를 통합할 때도 엔터티 자체의 본질이 기준이 되어야 합니다.

범주화는 논리적으로 사고하려는 사람에게 필요한 기법입니다. 모델러에게 큰 도움이되는 것은 분명합니다.

 

1) 생각의 지도/리처드 니스벳/최인철/김영사/2004
2) 범주들, 명제에 관하여/아리스토텔레스/김진성/이제이북스/2008

 

블로그 이미지

블루퍼필

댓글을 달아 주세요

  • 혈기린 2012.04.16 10:35  댓글주소  수정/삭제  댓글쓰기

    전 완전 동양사람이네요 관계먼저 ㅡㅡ;; 모델러 되기는 힘든건지 ㅎㅎ 울 와이프는 바로 본질적으로 동물로 묶어 버리네요 그래서 와이프 한테 기창님 책줘서 읽어보라구 햇습니다 모델러 양성 ㅎㅎ

  • 핫신 2013.02.08 10:43  댓글주소  수정/삭제  댓글쓰기

    판다곰과 원숭이를 본능적으로 묶었는데, 이거 모델러 직업병인가요? 제가 특이한 뇌구조인것 같네요.. 너무 좋은 실험이네요. 조만간 지인들에게 써먹어 보로돌 하겠습니다.

    • 블루퍼필 2013.02.11 14:41 신고  댓글주소  수정/삭제

      회사 직원들한테 간혹 문제를 내는데, 판다곰과 원숭이를 주로 묶네요.
      확실히 연관이 있는 거 같습니다.
      아니면 문제가 이미 노출됐든지... ㅎ

  • 정유성 2013.08.14 13:29  댓글주소  수정/삭제  댓글쓰기

    유형에 따라 두 종류로 묶이네요.
    아무래도 작년에 이 글을 읽은 영향 같습니다. ㅎㅎ

  • 클락 2013.08.28 12:40  댓글주소  수정/삭제  댓글쓰기

    몇명아니되지만 엔지니어인 분은 서양적으로 생각하고 영업맨은 분들은 동양적으로 생각하더군요 ㅎㅎㅎㅎ

  • 킷츄 2013.09.06 17:08 신고  댓글주소  수정/삭제  댓글쓰기

    굉장히 인상 깊게 읽었습니다. 많은 생각을 하게 하는 글이네요. ㅎㅎ

    덧붙여서, 판다곰과 원숭이를 묶었다는 사실이 기쁘기도, 복잡하기도 하고 그렇습니다 ㅎㅎ

지금까지 통합에 대해 설명했습니다.

오늘부터는 서브타입에 대한 글을 올리겠습니다.

 

그런데 막상 서브타입을 정의하려니 어렵네요. 며칠 째 막혀있었는데, 사실 서브타입 정의 자체는 엔터티 정의와 동일합니다. 슈퍼타입과 한쌍을 이룬다는 게 일반 엔터티와 다른 점입니다.

 

서브타입(Subtypes)이란 서브타입 엔터티(Subtypes Entity)를 말합니다. 서브타입을 엔터티로 인식하는 게 좋습니다. 슈퍼타입(Supertypes)도 마찬가지로 슈퍼타입 엔터티(Supertypes Entity)입니다.

 

엔터티를 일반화(Generalization)하거나 상세화(Specialization)하면 슈퍼타입과 서브타입이 생깁니다. 일반화와 상세화는 아래 글을 참조하세요.

 

일반화(Generalization)와 상세화(Specialization)

 

엔터티를 통합하거나 분리하는 행위의 결과가 서브타입입니다. 도출된 서브타입이 결국 테이블로 변환되는지와는 별개로 과정에 서브타입이 있어야 합니다.

 

서브타입을 보면 차이점을 알기 쉽습니다. 유사한 엔터티에서 공통 속성은 슈퍼타입 엔터티로 가고, 고유 속성은 서브타입 엔터티로 가는데요. 이렇게 설계하면 공통점과 차이점을 보기 쉽습니다.

 

[그림1]은 고객과 관련된 릴레이션입니다.

 

-------------------------------------------------

[그림1]

 

[그림1]에서 위쪽의 그림보다 아래쪽 그림이 이해가 잘 됩니다. 사전 지식이 없는 사람이 봐도 아래 그림이 쉽게 눈에 들어올 것입니다. 있는 그대로 공통점과 차이점을 보여주니까요.

 

[그림2]는 슈퍼타입과 서브타입 구조를 표현한 그림입니다.

 


[그림2]

 

슈퍼타입 속성은 모든 서브타입으로 상속(Inheritance) 되는 공통 속성이며, 슈퍼타입과의 관계는 서브타입에도 해당되는 관계입니다. 반면에 서브타입에는 해당 서브타입에서만 사용되는 고유 속성이 존재하며, 관계 또한 서브타입별 엔터티의 고유한 관계가 됩니다.

 

서브타입과 슈퍼타입은 공통점과 차이점을 보기 위한 유용한 방법입니다. 작게 나눈 세분화된 부분 집합은 전체 집합보다 이해하기 쉬워지고요. 슈퍼타입의 공통 속성과 공통 관계, 서브타입별 고유 속성과 고유 관계가 표현돼 업무 규칙을 모델에 표현하기도 쉽습니다.

 

모델링을 수행할 때 가장 중요한 요소 중의 하나는 모델의 확장성을 고려하는 것인데요. 데이터를 통합하면 서브타입이 도출되며 확장성이 좋아집니다.

 

슈퍼타입·서브타입 도출은 모델링 과정에서 반드시 필요합니다. 가장 효율적인 물리 구조를 결정하기 위해서 거쳐야 하는 모델링의 중요한 과정입니다.

 

 

블로그 이미지

블루퍼필

댓글을 달아 주세요

이번 글에서는 통합을 고려할 수 있는 다양한 경우를 설명하겠습니다. 다양한 케이스를 소개하지만 결국은 데이터의 본질이 유사하다는 것으로 통하게 됩니다.

 

역할을 관리하는 엔터티는 [그림1]과 같이 통합 모델을 사용할 때가 많습니다.



[그림1]

 

사원은 특정 계좌에 대해 관리사원·유치사원·주문사원 등 여러 가지 역할을 할 수 있습니다. 여러 역할에 따른 엔터티가 개별로 존재하는 것이 아니라 계좌관계사원 엔터티와 같은 통합 엔터티로 존재하는 것이 바람직합니다.

 

[그림2]와 같이 대칭적인 업무를 관리하는 데이터도 통합을 고려할 수 있습니다.



[그림2]

 

이경우 업무 성격은 대칭적이지만 데이터 성격은 유사합니다. [그림2]는 식별자가 같지만 식별자가 다르더라도(매출전표번호와 매입전표번호) 통합할 수 있습니다.

 

매도와 매입, 입고와 출고 등도 대칭적인 업무에 해당하는 데이터입니다.

 

[그림3]은 계층 관계가 존재하는 엔터티입니다. 계층 관계도 통합을 고려해야할 주요 대상입니다.



[그림3]

 

엔터티 통합은 대부분 수평적인 관계의 엔터티가 통합돼 서브타입(Subtypes)이 발생하지만, 계층 관계의 엔터티 통합은 수직적 통합으로 순환(Recursive) 관계가 발생합니다.

 

[그림3]은 계층 때문에 다른 데이터간의 상하 관계처럼 보이지만 결국은 유사한 데이터입니다.

 

[그림4] 엔터티에는 공통 속성이 보이는데, 이때 공통 속성이 별도의 데이터 성격을 지닌다면 통합을 고려할만 합니다.



[그림4]

 

여러 계좌 엔터티에 통보 연락처를 관리하는 속성이 공통으로 존재합니다. 통보 주소·이메일·전화번호는 이전 글의 [그림5]와 유사하게 별도의 엔터티에서 통합할 수 있습니다.

 

아래의 [그림5]는 배타 관계가 발생한 모델인데요. [그림4]까지 모델은 순수하게 엔터티를 통합하는 개념이지만 [그림5]는 관계를 통합하는 개념이 포함돼 있습니다.



[그림5]

 

[그림5]의 거래내역 엔터티에 많은 관계가 배타 관계로 존재합니다. 배타 관계는 모델의 구조를 복잡하게 만들고, 자연히 복잡한 조인(Join)이 발생해 바람직하지 않은 관계입니다. 이에 대해서는 후에 자세하게 설명하겠습니다.

 

어쨌든 거래내역 엔터티에 배타 관계를 발생시킨 엔터티(주식종목·채권종목·선물옵션종목·수익증권종목)를 통합하면 거래내역 엔터티에는 배타 관계가 발생하지 않습니다.

 

그리고 통합해야 좋은 대표적인 엔터티는 집계 엔터티입니다. 집계 엔터티는 집계하려는 기준에 따라 디멘젼이 달라집니다. 디멘젼이 다르면 식별자가 달라지는데요. 디멘젼이 유사하거나 포함 관계가 있다면 통합하는 것이 좋습니다(물론 집계하려는 내용이 같아야죠).

 

[그림6] 모델은 디멘젼이 다르긴 하지만 유사하고, 집계하려는 내용은 매출 총액으로 같습니다.



[그림6]

 

[그림6]의 디멘젼에는 포함 관계가 있습니다. 즉 월이 모여서 분기가 됩니다. 따라서 월에 대한 총액만 있어도 분기는 합쳐서 구할 수 있습니다.

 

상품별월매출 엔터티에서 2030 1월부터 3월까지 매출 총액을 더하면 분기의 총액이 됩니다. 굳이 상품별분기매출 엔터티를 만들어 위에서 더한 값과 2030 1분기 매출 총액이 달라지는 것을 걱정할 필요가 없습니다(간혹 성능 때문에 중간 단계의 엔터티를 만드는데 반드시 필요한지 숙고해야 합니다).

 

(화면)가 달라서 데이터를 별도로 보관하는 것은 무결성 차원에서 바람직하지 않습니다. 정정 데이터에 대한 처리 문제와 성능 문제 등으로 데이터를 별도로 저장해서 관리해야 할 때가 있지만 여느 엔터티와 마찬가지로 유사한 집계 엔터티는 통합하는 것이 좋습니다

 

[그림7]은 집계하려는 내용까지 약간 다릅니다. [그림6]에서 조금 더 달라진 모델이죠.



[그림7]

 

월별 데이터는 매출 총액과 반품 총액을 관리하고 분기별 데이터는 매출 총액과 배송료 총액, 수수료 총액을 관리합니다.

 

비록 관리하는 속성이 약간 다르지만 데이터를 생성할 때 조금만 신경 쓰면 굳이 두 개의 엔터티를 관리하지 않아도 될 모델입니다.

 

[그림8]은 이전 모델보다는 디멘젼이 많이 다릅니다. 디멘젼 사이에 포함 관계도 없고요.



[그림8]

 

상품코드와 부서코드라는 전혀 다른 성격의 기준(Dimension)으로 집계를 했지만 집계하려는 내용은 같습니다. 이 경우도 엔터티 생성을 남발하는 것보다는 상품코드와 부서코드를 기준으로 매출액을 집계하면 하나의 엔터티에서 관리할 수 있습니다. 물론 이때는 기준이 달라져서 인스턴스가 더욱 많이 발생합니다.

 

인스턴스가 지나치게 증가하거나 집계 기준이 지나치게 복잡해질 때는 최종적으로 통합이 적합하지 않을 수도 있지만, 최소한 통합을 고려해보는 것은 의미가 있습니다.

 

이처럼 집계 엔터티는 집계하려는 내용(데이터 성격)과 집계하려는 기준(Dimension)을 고려하여 통합을 고민해 보는 것이 좋습니다. 사실 이걸 고민하는 것이 집계 데이터에 대한 요건을 만드는 것입니다.

 

생성이 다소 번거롭더라도 데이터 정합성에 문제가 발생하지 않아야 하는 것은 집계 엔터티에도 마찬가지로 적용하는 기본 원칙입니다.

 

마지막으로 엔터티 합체와 관련된 내용인데요. 엔터티 합체에도 데이터 통합 개념이 적용됩니다.

 

[그림9]와 같이 일대일 관계가 발생한 엔터티는 통합할 수 있습니다. 물론 이는 여러 번 언급했듯이 엄밀히는 엔터티 합체입니다.




[그림9]

 

첫 번째 모델은 성능을 고려해 덜 사용하는 속성을 분리한 것이고요(하지만 데이터 본질은 동일합니다). 두 번째 모델은 프로세스 흐름을 엔터티로 표현한 것입니다.

 

기본적으로 바람직하지 않지만 프로세스대로 엔터티를 분리하는 게 명확할 때도 있습니다. 이때 주의할 점은 결과(계약승인)를 여러 번에 걸쳐 입력할 수 있는지입니다. 즉 일대다 관계가 될 수 있는지 주의해야 합니다. 현재는 아니라도 미래에 그럴 수 있는지를요.

 

만약 일대다 관계일 수 있는데 합쳐 놓으면 일대다 관계로의 검토 자체가 불가능해집니다. 분리하려 해도 쉽지 않고요. 일대다 관계가 될 가능성이 있다면 반드시 [그림9]와 같이 엔터티를 분리해야 합니다.

 

비정규화를 하면서 엔터티가 통합될 수도 있습니다. [그림10]과 같은 정규형 모델에 성능 문제가 발생하면 엔터티를 합칠 수 있습니다. 즉 이 경우도 엔터티 합체에 가깝습니다.


 

[그림10]

 

주문의 기본 데이터를 관리하는 주문 엔터티와 주문 상품을 관리하는 주문내역 엔터티는 마스터(Master), 상세(Detail) 관계이면서 일대다(1:M) 관계의 모델인데요.

 

만약 주문한 상품을 빠르게 조회해야 하는 최우선의 요건이 있다면 주문내역 엔터티를 기준으로 마스터 성격의 데이터인 주문 엔터티를 합체하는 것이 유리합니다. 즉 주문내역 엔터티의 속성은 그대로 두고 주문 엔터티의 속성을 포함해 중복 관리합니다.

 

2정규형이나 3정규형 등의 모델도 하나의 엔터티로 합체할 수 있습니다.

 

이상으로 여러 가지 통합 대상 엔터티를 설명했는데요. 통합하거나 통합하지 않았다는 결과보다는 과정이 중요합니다. 과정은 깊게 고민해야 합니다.

 

통합하는 기준을 다시 간략하게 정리하면요. 아래 기준 중에 하나라도 만족되면 일단 통합을 고려하는 것이 좋습니다. 일반화의 정도에 따라 다르겠지만 아마 웬만하면 첫 번째 기준에 해당될 것입니다.

 

● 데이터의 본질(성격)이 유사하다

● 식별자가 동일하면서 유사한 속성이 존재한다

● 식별자는 다르지만 기초 속성이 유사하다

 

통합할 때는 아래와 같은 문제도 고민해야 합니다.

 

● 통합해도 성능 문제를 일으키지 않는다

● 현행 데이터를 마이그레이션하는 데 문제가 없다

 

통합 시 주의할 점에 대한 글도 참고하세요.

 

통합이 대세인가? 통합 시 주의할 점

 

이상으로 통합을 고려할 엔터티에 대해 설명했습니다. 통합(Generalization)은 정규화(Normalization)와 함께 중요한 부분입니다. 많이 고민하여 기준을 세우는 것이 좋습니다.






블로그 이미지

블루퍼필

댓글을 달아 주세요

지난 번에 설명한 데이터 성격이 유사하다는 것이 데이터 통합을 고려할 가장 중요한 요소입니다.

 

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

 

[그림1]고객이 요청한 알림 서비스를 관리하는 엔터티입니다.



[그림1]

 

고객알림서비스 엔터티는 고객별 알림 서비스를 관리하는 엔터티이고, 계좌알림서비스 엔터티는 계좌별 알림 서비스를 관리하는 엔터티입니다. 어떤 종류의 알림 서비스를 원하는지와 어떻게 알림 서비스를 받는지, 서비스 신청 일자와 알림을 몇 번 반복하는지 등의 데이터 성격은 두 엔터티가 동일합니다.

 

단지 고객을 지정해 서비스를 하는지, 계좌를 지정해 서비스를 하는지가 달라 주 식별자가 달라졌습니다. 그래서 엔터티가 통합되지 못한 예제인데 통합 대상입니다(주 식별자가 다른 여러 엔터티를 통합하는 방법은 별도로 설명하겠습니다).

 
사실 데이터의 본질이 유사한지 따지는 것 자체가 어려운 일입니다. 지금 몇 장에 걸쳐 설명하고있는 내용이기도 하고요.

 

엔터티에서 관리하는 데이터의 본질은 속성으로 나타납니다. 따라서 속성이 유사하면 본질이 유사할 가능성이 높습니다. 더욱이 기초 속성1)이 유사하면 통합을 고려할 수 있습니다.

 

[그림2]는 속성이 유사한 예제이고요. 이전 글의 계좌 엔터티나 고객 엔터티와 마찬가지로 대표적인 통합 대상 엔터티입니다.



[그림2]

 

[그림3]은 속성은 다소 다르지만 기초 속성이 유사한 통합 대상 엔터티입니다.


[그림3]

 

모두 결국 데이터의 본질이 유사하다고 볼 수 있습니다.

 

[그림4]는 이제까지의 예제와 달리 데이터 본질 측면에서는 유사성이 가장 떨어집니다.


[그림4]

 

하지만 역시 몇몇 기초 속성이 유사해 통합 대상인데요. 데이터 성격이 다소 달라서, 고객이 약정한 서비스를 함께 보여주지 않는다면 통합을 숙고해야 합니다. 즉 데이터를 같이 본다는 측면이 통합을 하는 명분이 됩니다.

 

사실 성격이 완전히 다른 데이터를 같이 볼 이유는 없죠. 비슷하니까 같이 보게 됩니다. 데이터를 같은 방법으로 사용한다면 유사한 데이터일 가능성이 높습니다.

 

일반적으로 [그림4]와 같은 엔터티를 부가서비스라는 상위 개념으로 일반화하는 건 좋은 생각입니다. 한번 더 일반화를 한다면 서비스라는 개념이 되겠고요.

 

아래 [그림5]도 일반화를 한 예제입니다.



[그림5]

 

고객의 집주소·회사주소 등은 매우 유사해서 고객우편주소 엔터티로의 일반화가 자연스럽고요. 고객의 개인이메일·회사이메일·홈페이지·메신저 등도 유사한 편이라 고객전자주소 엔터티로 일반화가 됩니다. 집전화·회사전화·휴대전화·팩스도 마찬가지로 고객전화번호 엔터티로 일반화됩니다.

 

이를 한 번 더 일반화한 게 고객연락처 엔터티입니다.

 

엄격히 보면 집 주소와 이메일 주소는 유사한 데이터가 아닙니다. 전화번호는 더욱 그렇고요. 하지만 고객한테 연락할 곳이라는 개념에서는 유사성이 있습니다.

 

[그림4]와 마찬가지로 여러 연락처를 함께 볼(사용) 가능성도 높습니다.

 

데이터를 일반화(Generalization)하면 엔터티가 통합됩니다.

일반화 강도에 대한 고민은 항상 하지만 기본적으로 일반화하는 것을 검토합니다.

 

이번에는 주로 데이터 성격이 유사한 경우를 설명드렸습니다.

통합을 고려해야 할 다양한 경우를 이어서 설명하겠습니다.

 

 

1) 기초 속성(Basic Attributes): 엔터티의 본질을 설명하는 속성으로 업무 식별자와 후보 식별자, 엔터티의 성격을 대표할 수 있는 핵심 속성, 업무를 정의하는 코드 속성 등이 기초 속성에 포함된다.


블로그 이미지

블루퍼필

댓글을 달아 주세요

데이터 통합이 어려운 이유, 통합이 안 되는 이유는 크게 두 가지가 있습니다.

 

하나는 이전에 설명드린 통합의 단점 때문일 것입니다. 아래 글을 참고하세요.

 

통합이 대세인가? 통합 시 주의할 점

 

통합을 위한 통합은 경계하고, 단점은 충분히 고려해야 합니다.

 

오늘의 주제는 두 번째 이유입니다. 통합이 어려운 두 번째 이유는 조직에 있습니다.

 

조직 구조에 따라 통합되지 않는 경우가 빈번합니다.

단순하게 주식계좌 엔터티와 수익증권계좌 엔터티를 관리하는 담당자가 다르면 통합이 어렵습니다.

담당자만 달라도 어렵지만 담당자의 소속()이 다르면 더욱 어렵고요.

 

이것의 근본적인 원인은 리소스입니다.

업무가 줄지 않는다면 다른 업무를 감당하기 벅차기 때문이죠.

진짜 감당하기 힘든지는 차치하고라도 지금보다 많아지는 것에 대한 거부감은 분명 존재합니다.

 

이때 모델러는 난감해지고 많은 사람이 딜레마에 빠집니다.

분명 통합하면 좋다는 것을 모두 공감하고 있는데요.

엔터티를 받아야 할 당사자가 대승적으로 결정하면 해결될텐데 총대 메고 나서기 쉽지 않아 결과적으로 통합이 되지 않습니다.

 

이와 같은 이유로 통합하지 못하는 횟수는 적지만 상당히 핵심적인 엔터티와 관련있어 통합 못한 효과는 작지 않습니다.

 

그리고 프로젝트가 커질수록 이런 현상이 커지는데요. 프로젝트가 커질수록 방어 심리도 더 커지는 거 같습니다.

 

타 영역에 비슷한 엔터티가 있는지도 모를 때가 많고, 있는 것을 알더라도 모른 척하게 됩니다.

자연히 없어서는 안 될 필수적인 연관 관계만을 파악하고, 효율적인 연관 관계에는 관심을 두지 않는 경향이 있습니다.

 

그래서 프로젝트가 커질수록 강력하고 추진력 있는 엔터티 통합 작업이 필요합니다. 데이터 모델은 개발 영역별 개발 관점이 아닌 전사적인 데이터 관점(Enterprise Data Architecture)에서 접근해야 합니다.

데이터는 개발 영역별로 존재하고 사용되는 것이 아니라 통합돼 전사에서 공유할 수 있어야 합니다.

 

바람직한 것은 전사 관점에서 생각하는 것입니다.

모델러로서 많은 사람과 일하지만 대승적으로, 전향적으로 생각하는 사람이 드문 게 사실입니다.

 

결국 더 효과적인 게 무엇일지, 전사에 더 도움이 되는 게 어떤 것일지 생각한다면 최소한 내 일, 우리 팀원 일이 많아진다는 이유 때문에 통합되면 좋은 데이터가 통합이 안 되는 일은 없을 것입니다.

 

여러 번 주장했듯이 이런 문제가 최소화될 수 있는 조직 체계, 즉 데이터 주제 영역 기준의 조직 체계가 생길 거라 기대합니다.

 

최소한 담당자가 달라서 데이터를 통합하지 못하는 일은 없어야 하겠습니다.





블로그 이미지

블루퍼필

댓글을 달아 주세요

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

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

 

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

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

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

 

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

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

 

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

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

 

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

 

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

 

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

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

 

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



[그림1]

 

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

 

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

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

 

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



[그림2]

 

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

 

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

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

 

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

 

 

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

 


블로그 이미지

블루퍼필

댓글을 달아 주세요

데이터(엔터티) 통합이 대세지만 통합 시 주의할 점이 있습니다.

 

일반적으로 많이 언급되는 것은 성능입니다.

 

데이터를 통합하면 데이터는 많아질 수밖에 없습니다.

A집합과 B집합의 인스턴스 개수가 합쳐지기 때문에 데이터가 늘어납니다.

 

데이터가 증가하는 것과 성능은 유관합니다.

요건에 따라 때론 큰 차이가 생기고, 때론 미미한 차이가 생깁니다.

때론 성능이 좋아지기도 하고요.

 

통합해야 성능이 좋아지는 요건도 많아 저는 통합을 우선적으로 고려합니다.

그러면서 성능이 나빠질 수 있다는 점을 염두에 두죠.

 

흔하지는 않지만 대기 현상으로 인한 인서트 성능 저하를 고려할 때도 있습니다.

인서트가 많이 발생하는 엔터티에 어떤 엔터티를 통합하는 것은 바람직하지 않습니다.

 

인서트가 많다는 기준이 애매한데요. 참고로 말씀드리면 제 기준으로 이제껏 경험한 엔터티는 다섯 개 이하입니다.

 

데이터 통합 시 실무자들이 가장 우려하는 것이 성능입니다.

성능 문제만 없다면 데이터 통합을 그다지 반대하지 않았습니다.

 

성능 다음으로 많이 언급되는 것이 지나친 일반화입니다(지나치다는 판단 또한 개인마다 기준이 다를 수 있습니다).

 

맞긴 하지만 뭔가 좀 그런 느낌이 들 때가 있습니다.

 

최근 파티(Party)라는 개념이 간혹 사용되고 있습니다.

간단히 설명하면 고객·사원·부서·거래처 등 행위의 모든 주체를 통합하는 것인데요.

 

상황에 따라 판단해야 하지만 저는 일반적으로 반대하는 개념입니다.

고객 데이터와 부서 데이터는 다른 성격의 데이터라고 보기 때문에요.

 

~'이 존재하는 데이터를 한 엔터티에서 관리한다는 생각은 지나칠 수 있습니다.

그중에는 사람도 있을 수 있고 상품도 있을 수 있으므로 성격에 맞게 구분하는 것이 바람직합니다.

 

이와 같이 성격이 다른 데이터를 지나치게 일반화해서 통합한 사례는 흔치 않습니다(초기 개념 모델 혹은 개괄 모델에서는 지나친 통합이 사용되기도 합니다).

 

이런 통합은 의도된 통합이라 장점도 있을 것입니다.

하지만 의도되지 않은 지나친 통합이 있습니다.

 

유사하지 않은 데이터인데 유사하게 선언해 통합할 때, 이때는 통합의 적정성을 판단하기 어렵습니다.

데이터 정의에 근본적인 문제가 있기 때문에 분간이 힘듭니다.

 

다른 데이터라도 정의만 유사하게 선언하면 그럴듯한 통합처럼 보입니다.

 

파티(Party)와 같은 지나친 일반화는 개념은 맞지만 좀 꺼림칙한 것인데 반해 이건 아예 틀린 것입니다.

 

이에 대한 해법은 우선 데이터 정의를 제대로 하는 것인데요. 먼저 정규화가 진행돼야 합니다.

 

정규화는 정의를 하는 단계에서 사용하기 때문에, 근본적인 것이기 때문에 아무리 강조해도 부족함이 없습니다. 선택 사항이 아닙니다.

 

그리고 통합 시 주의할 할 점 중에 실전에서 많이 볼 수 있는 것이 있습니다.

 

엔터티는 어떤 기준에 의해 구분할 수 있는데요.

저는 주로 실체·행위·기준·가공 엔터티로 나눕니다

 

엔터티 분류

 

이때 실체 엔터티와 행위 엔터티 간에 통합이 발생하면 안 됩니다.

그게 현재 일대일 관계고 미래에도 계속 일대일 관계라고 해도요.

 

실무에서 실체와 행위, 실체와 기준, 실체와 가공, 기준과 행위 데이터가 합쳐진 엔터티를 자주 보게 됩니다.

합쳐서 사용이 가능하고, 당장 보이는 부작용이 없다고 할지라도 분리하는 것이 바람직합니다.

 

최근 데이터 통합이 대세입니다.

누구나 통합을 얘기하고 서브타입을 얘기합니다

 

통합을 위한 통합을 하지 않도록 주의해야 합니다.

 

대세를 따르는 것은 좋지만 생각하고 따르는 것이 중요합니다.

실익이 있는지 따져보고 숙고해야 합니다.


블로그 이미지

블루퍼필

댓글을 달아 주세요

  • 혈기린 2011.11.17 14:36  댓글주소  수정/삭제  댓글쓰기

    저도 party라는 개념으로 모두 통합하는건 이해는가지만 현실성은 별로없다라고 생각을 하고 있었습니다. 엔모사 컨설턴트에게 물어보니 자기들도 회의적이라고 하긴 하더군요 기창님 말씀대로 지나친 일반화이지 않을까 합니다. 모델링 공부할수록 어려워요 ㅜㅜ

    • 블루퍼필 2011.11.17 22:43 신고  댓글주소  수정/삭제

      오랜만입니다..
      최근 느끼는 감정이라 마지막 말이 여운이 남네요.
      아예 철학을 공부할까도 생각중이에요. 너무 복잡해요. ㅎㅎ
      그래도 계속 열심히 하세요.

데이터 통합이란 유사한 성격의 데이터를 합치는 것을 말합니다.

 

통합하면서 더 포괄적인(일반적인) 데이터를 도출하므로, 데이터를 통합하는 과정을 일반화(Generalization)라고 합니다.

 

통합에서는 집합의 개념이 포함됩니다. A 집합과 B 집합을 합쳐서 C 집합을 만드는 것이죠.

A, B가 개념적인 정의가 될 수도 있고 엔터티가 될 수도 있습니다.

 

이와는 조금 다른 통합이 있는데요.

 

일대일 관계의 엔터티 중에는 그 자체로 이미 하나의 집합인데 성능 등의 이유로 일부 속성을 분리한 경우가 있습니다.

 

이런 일대일 엔터티를 합치는 것을 저는 엔터티 합체라고 합니다. 데이터 통합에 포함시키지 않습니다.

합체라는 단어의 어감이 유아틱하지만 통합과 구분하기 위해 사용합니다.

 

성격 자체가 동일한(같은 집합인) 일대일 엔터티를 합치는 것과 성격이 유사한 다른 집합을 합치는 것은 다릅니다. 후자가 진짜 합치는 거죠.

 

둘 다 합치는 것이라 넓은 의미로 일대일 엔터티 합체도 데이터 통합에 포함시키기도 하지만, 구분해서 분명하게 이해할 필요가 있습니다.

 

그리고 엔터티 통합이란 용어도 약간 다르게 사용합니다.

이는 주로 리버스 모델링에서, 즉 이미 엔터티가 도출된 상태에서 두 엔터티를 통합할 때를 의미합니다.

 

그래서 데이터 통합은 엔터티 통합보다 더 큰 개념이죠.

엔터티를 도출하기 전에 두 집합을 개념적으로 도출한 후에(두 집합을 정의한 후에) 합치는 것이니까요.

 

데이터 통합이 엔터티 통합을 포함하는 개념이므로 주로 데이터 통합이란 용어를 사용합니다.

 

제가 용어에 민감해서, 스스로에게 엄격하게 적용합니다.

용어는 이쯤에서 끝내고요.

 

데이터 통합은 쉬운 작업이 아닙니다.

 

데이터 모델의 토대(구조)를 흔들 수 있는 어렵고 중요한 결정이 데이터 통합입니다.

 

통합에 대한 심적 부담이 컸던 적이 한 번 있는데요. 고객 전체가 주시하는 극도의 부담이었습니다.

반면, 엔터티 합체는 모델 구조를 조금 흔들죠. 부담되는 경우는 거의 없습니다.

 

부담스런 결정이라 어려운 것도 있지만, 데이터의 성격을 정의하는 것 자체가 어려워 데이터 통합이 어렵습니다.

동질성을 가진 데이터라는 판단을 하려면 데이터의 성격을 정의해야 하니까요.

 

데이터 통합은 데이터(엔터티) 정의에 종속된 개념입니다. 데이터 정의에 따라 데이터 통합의 기준이 달라지죠.

 

데이터에 대한 명확한 정의 없이 데이터 통합을 논하는 건 의미가 없다는 점을 항상 염두에 둬야 합니다.


블로그 이미지

블루퍼필

댓글을 달아 주세요

데이터 통합과 관련된 용어로 일반화(Generalization)와 상세화(Specialization)가 있습니다.

이에 대해 간략하게 언급하겠습니다.

 

많은 분야에서 사용하는 용어일텐데, 이번 글에서는 데이터 모델링에서 사용하는 의미로 한정하겠습니다.

일반적인 용어를 공개적으로 설명하는 것은 용기가 필요하니 약간의 장치가 있어야죠. ㅎㅎ

 

모델링에서 일반화한다는 것은 데이터 통합을 의미합니다.

유사한 것을 묶는 것을 일반화라고 합니다.

원래 유사한 것을 묶을 수도 있고, 인위적으로 유사하게 만들어 묶을 수도 있습니다.

 

정의를 어떻게 하냐에 따라 유사한 것일 수도 있고, 유사하게 만든 것일 수도 있습니다(이 부분이 데이터 통합도 어렵게 하고 이에 대한 설명도 어렵게 하죠).

 

사전에서 찾은 '일반화하다'의 뜻은 아래와 같습니다.

 

"개별적인 것이나 특수한 것이 일반적인 것으로 되다. 또는 그렇게 만들다"

 

뜻 자체로만 보면 묶는다는 개념이 없는 거 같은데요.

그냥 만드는 것으로 끝난다면 의미가 없을 거 같습니다(모델링에서요).

 

예를 들어, 미국에서 태어나 서울에서 일시적으로 살고 있는 외국인을 고객으로 볼 것인지에 대해서요.

외국인 고객을 넓게 보면 고객으로 볼 수 있습니다. 이게 일반화이고요.

 

이미 고객이라는 데이터가 있을테니 외국인 고객은 고객에 흡수됩니다. 통합되죠.

외국인 고객을 고객이라고 일반화하고 고객 데이터에 속하지 않게 할 수는 없습니다.

고객 데이터에 속하지 않게 하려면 고객이라고 일반화하지 않아야죠.

 

이해 되시나요? 가끔 예가 더 어려울 때가 있습니다. ㅎㅎ

데이터를 일반화하면 자연스럽게 통합이 된다는 것입니다. 자연히 묶게 됩니다.

 

일반화는 상세한 것에서 출발해 일반적(포괄적)인 것을 도출합니다.

상향식(Bottom-Up) 방법과 유사합니다.

 

주민번호 있는 개인, 사업자번호 있는 사업자나 법인, 외국인번호 있는 외국인, 우리회사의 사원이나 관계사 등은 자연인(自然人)과 법인(法人)으로 일반화할 수 있습니다.

자연인과 법인은 고객으로 한번 더 일반화할(묶을) 수 있습니다.

 

일반화의 상대 개념은 상세화(Specialization)입니다. 특수화라고도 하고요.

저는 차별화가 더 와 닿는데, 혼란을 일으킬 거 같아 제 책에서도 무난하게 상세화라고 했습니다.

 

상세화는 하향식(Top-Down) 방법으로써 차이를 도출하는 것이 주요 행위입니다.

 

고객이라는 일반적인 개념에서 자연인 고객, 법인 고객 등으로 더 구체적으로 따져서 다른 점을 강조합니다.

뭉뚱그린 개념에서 구체적인 개념으로 만드는 것이죠.

 

엔터티를 일반화하거나 상세화하면 슈퍼타입(Supertype)과 서브타입(Subtype)이 생깁니다.

결과적으로 슈퍼타입과 서브타입이 없을 수는 있지만, 모델링 중에는 반드시 도출해야 합니다.

 

데이터 통합과 일반화, 서브타입은 유사한 개념입니다.

 

일반화와 상세화 모두 결국은 차이점을 보기 위한 것입니다.

묶었지만 차이도 볼 수 있는 게 데이터 통합입니다.


블로그 이미지

블루퍼필

댓글을 달아 주세요

데이터 통합은 모델링에서 가장 어려운 주제 중의 하나입니다.

또한 모델러 개개인의 능력 차이가 발생하는 부분입니다.

 

보통 통합하려는 데이터는 핵심적으로 사용되는 데이터일 가능성이 큽니다.

통합에 대한 이슈가 발생할 수 있는 데이터는 더욱 핵심 데이터이고요.

핵심적이지 않은 데이터는 무관심해서 통합과 관련된 이슈가 발생하지 않습니다.

 

정규화는 이론에 대한 이견은 거의 없고(조금 있고), 다만 적용 여부에 대한 논란(어느 정규형까지 적용해야 하는지에 대한 논란)이 많습니다데이터 통합은 모델러마다 이견이 생길 수 있습니다.


통합해야 좋다
, 통합하면 안 좋다는 이견은 언제나 있습니다.

물론 전문가 간에는 의견이 거의 일치한다고 봅니다.

어쨌든 모델러 간에 의견 일치가 어려운 부분이 데이터 통합입니다.

 

데이터를 어떻게 통합했느냐에 따라 모델은 상당히 달라지는데요.

상대적으로 데이터 통합은 이론적인 명확한 규칙에 의해서보다는 직관에 의해 통합하는 경우가 많습니다.

직관에 의해 통합된 모델의 미묘한 차이가 모델러의 커다란 차이를 나타내기도 합니다.

 

데이터 통합은 정규화와 밀접하게 연관돼 있습니다(이에 대해서는 별도로 설명하겠습니다).

따라서 데이터 통합은 정규화를 기반으로 이루어져야 합니다.

정규화가 기반이 되지 않은 통합은 의미가 없고요.

 

또 한가지는, 최근에 데이터 통합이 강조되다 보니 통합을 위한 통합을 하는 경향이 있습니다. 이는 지양해야 합니다.

 

데이터 통합은 모델링에서 중요한 부분입니다. 어느 프로젝트나 데이터 통합을 강조합니다.

하지만 데이터 통합이 자주 언급되는 것만큼 쉬운 일은 아닙니다.

 

데이터를 제대로 통합하기 위해서는 엔터티를 제대로 정의할 수 있어야 하고요(이 단계를 잘못하면 이후는 의미가 없습니다).

어느 선까지 일반화(Generalization)할지를 결정해야 합니다.

그리고 성능과 연관되므로 성능 측면을 검토해야 합니다.

 

유사한 종류의 데이터가 통합되지 못하고 여기 저기에 존재한다는 것은 어플리케이션의 중복 문제와도 무관하지 않습니다.
당연히 데이터 오너십, 모델 오너십과도 연관되고요.

최근에는 MDM(Master Data Management)과도 연관됩니다.

어느 조직이나 데이터 통합은 해결해야 하는 어려운 주제입니다
.

 

이 서브타입(Subtype) 카테고리에서는 데이터 통합과 그 결과를 표현하는 방법인 슈퍼타입/서브타입에 대한 설명을 하겠습니다.


블로그 이미지

블루퍼필

댓글을 달아 주세요