태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

서브타입은 크게 배타 서브타입과 중복 서브타입으로 구분할 수 있습니다.

 

배타(Exclusive 또는 Disjoint) 서브타입은 서브타입 부분 집합 간에 공통 부분을 갖지 않는 서브타입입니다. [그림1]은 배타(Exclusive) 서브타입입니다.


[그림1]

 

하나의 슈퍼타입 인스턴스는 단 하나의 서브타입과 관계(일대일 관계)가 존재합니다. 따라서 고객은 개인 고객이거나 사원 둘 중 하나입니다.

 

서브타입 간에 상호 배타적이므로 일반적으로 전체 서브타입의 합은 슈퍼타입이 됩니다. 즉 개인 고객과 사원을 합치면 전체 고객이 됩니다.

 

[그림2]정보 공학(Information Engineering) 표기법의 배타 서브타입입니다. 서브타입 기호에 X 표시가 있습니다.


[그림2]

 

[그림3]중복(Inclusive 또는 Overlapping) 서브타입입니다.


[그림3]

 

중복 서브타입은 겹쳐지는 부분이 존재하는 서브타입입니다. 하나의 슈퍼타입 인스턴스가 두 개 이상의 서브타입과 관계가 존재할 수 있습니다. 따라서 고객은 개인 고객이거나 사원이거나, 또는 개인 고객과 사원 둘 다일 수 있습니다.

 

[그림4]는 중복 서브타입을 IE 표기법으로 표현한 모델입니다. 서브타입 기호에 X 표시가 없습니다.


[그림4]

 

실제로 발생하는 대부분의 서브타입은 배타(Exclusive) 서브타입입니다. 중복(Inclusive) 서브타입은 자주 발생하지 않습니다.

 

배타 서브타입의 개념은 쉬운데 혼란을 일으시킬 수 있는 부분이 있습니다. 이력과 연동된 내용인데 다음에 설명할 것이고요.

 

중복 서브타입은 데이터를 관리하는 방법이 혼란스러울 수 있습니다. 이 부분도 다시 상세하게 설명드리겠습니다.

 

해당 업무 요건이 배타 서브타입인지 중복 서브타입인지를 정확히 도출하는 것이 중요합니다. 중복 서브타입으로 도출해야 하는데 습관적으로 배타 서브타입으로 도출하면 업무를 반영하지 못하게 되므로 유의해야 합니다.




블로그 이미지

블루퍼필

댓글을 달아 주세요

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

[그림1]

 

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

 

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

 


[그림2]

 

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

 

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

 

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

 

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

 

 

블로그 이미지

블루퍼필

댓글을 달아 주세요

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

 

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

 

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



[그림1]

 

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

 

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

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

 

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

 

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



[그림2]

 

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


[그림3]

 

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

 

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


[그림4]

 

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

 

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

 

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

 

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



[그림5]

 

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

 

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

 

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

 

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

 

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

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

 

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

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

 

 

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


블로그 이미지

블루퍼필

댓글을 달아 주세요

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

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

 

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

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

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

 

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

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

 

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

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

 

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

 

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

 

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

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

 

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



[그림1]

 

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

 

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

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

 

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



[그림2]

 

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

 

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

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

 

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

 

 

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

 


블로그 이미지

블루퍼필

댓글을 달아 주세요

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

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

 

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

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

 

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

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

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

 

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

 

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

 

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

 

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

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

 

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

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

 

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

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

 

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

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

 

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

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

 

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

 

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

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


블로그 이미지

블루퍼필

댓글을 달아 주세요

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

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

 

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

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

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

 

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


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

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

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

 

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

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

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

 

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

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

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

 

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

 

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

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

 

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

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

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

 

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

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

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

 

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


블로그 이미지

블루퍼필

댓글을 달아 주세요