본문 바로가기

데이터 Story

완전(Complete) 서브타입 & 불완전(Incomplete) 서브타입 지난 번에 서브타입을 구분하는 방법으로 배타(Exclusive)·중복(Inclusive) 서브타입을 설명했습니다. 이번에는 완전(Complete) 서브타입과 불완전(Incomplete) 서브타입을 설명하겠습니다. 완전(Complete) 서브타입은 슈퍼타입의 모든 인스턴스가 최소한 하나의 서브타입 인스턴스와 관계가 존재하는 서브타입입니다. 반면에 불완전(Incomplete) 서브타입은 슈퍼타입에만 인스턴스가 존재하고 서브타입에는 인스턴스가 존재하지 않는 서브타입입니다. 즉 고유 속성이 존재하지 않는 서브타입입니다. 이렇게 슈퍼타입 인스턴스와 서브타입 인스턴스의 관계를 인스턴스 제약(Instance Constraints)이라고 합니다. 인스턴스 제약에 따라 완전(Complete) 서브타입과 불완전(Incom.. 더보기
배타 서브타입 & 중복 서브타입 서브타입은 크게 배타 서브타입과 중복 서브타입으로 구분할 수 있습니다. 배타(Exclusive 또는 Disjoint) 서브타입은 서브타입 부분 집합 간에 공통 부분을 갖지 않는 서브타입입니다. [그림1]은 배타(Exclusive) 서브타입입니다. [그림1] 하나의 슈퍼타입 인스턴스는 단 하나의 서브타입과 관계(일대일 관계)가 존재합니다. 따라서 고객은 개인 고객이거나 사원 둘 중 하나입니다. 서브타입 간에 상호 배타적이므로 일반적으로 전체 서브타입의 합은 슈퍼타입이 됩니다. 즉 개인 고객과 사원을 합치면 전체 고객이 됩니다. [그림2]는 정보 공학(Information Engineering) 표기법의 배타 서브타입입니다. 서브타입 기호에 X 표시가 있습니다. [그림2] [그림3]은 중복(Inclusive.. 더보기
정규화에 대한 주절거림 블로그에 서브타입에 대한 글을 쓰고 있는데요. 변화를 위해 다양한 주제의 글을 올리겠습니다. 나이를 먹을수록 확실히 체력의 부담을 느낍니다. 일주일에 하나씩은 올리려는 생각이 한 달에 두 개로 줄고... 실제는 하나만 올라가기도 하고요. 최근에 정규화에 대해 다시 생각하고 있습니다. 지나치게 사적인 얘기지만 저는 모델링이 자신 있는데요. 남들이 뭐라하든... ㅎㅎ 오래 전부터 해 오던 훈련 때문입니다. 속성의 종속 관계를 파악해서 엔터티를 도출하는 훈련인데요. 쉽게 말해 속성이 엔터티에 속하는 게 옳은지를 판단하는 것입니다. 이 훈련의 핵심은 식별자와 종속성입니다. 엔터티를 대표하는 속성(업무 식별자)을 찾아야 하고요. 그 속성을 기준으로 대상 속성이 종속됐는지 여부를 판단합니다. 종속성이 없다면 다른 .. 더보기
서브타입은 어떻게 도출하는가? 서브타입을 도출하는 방법은 크게 두 가지입니다. 두 개 이상의 유사한 엔터티에서 공통 속성을 분류하는 방법과, 복잡한 엔터티에서 유사한 속성끼리 분류하는 방법이 있습니다. 전자는 엔터티를 통합(Generalization)하는 행위이고, 후자는 엔터티를 상세화(Specialization) 또는 논리화(Logicalization)하는 행위입니다. 모든 엔터티가 서브타입이 존재하는 것은 아닙니다. 서브타입이 도출되는 엔터티는 소수인데요. 통합할 수 있고 상세화할 수 있는 엔터티에서는 서브타입을 반드시 도출해야 합니다. 물리 모델링 단계에서 다시 하나의 엔터티로 통합되더라도 과정 중에는 도출해야 합니다. 모델링은 과정을 의미하니까요. [그림1] 모델에는 유사한 엔터티가 있습니다. 두 개 이상의 엔터티가 유사하다.. 더보기
서브타입(Subtypes)이란? 지금까지 통합에 대해 설명했습니다. 오늘부터는 서브타입에 대한 글을 올리겠습니다. 그런데 막상 서브타입을 정의하려니 어렵네요. 며칠 째 막혀있었는데, 사실 서브타입 정의 자체는 엔터티 정의와 동일합니다. 슈퍼타입과 한쌍을 이룬다는 게 일반 엔터티와 다른 점입니다. 서브타입(Subtypes)이란 서브타입 엔터티(Subtypes Entity)를 말합니다. 서브타입을 엔터티로 인식하는 게 좋습니다. 슈퍼타입(Supertypes)도 마찬가지로 슈퍼타입 엔터티(Supertypes Entity)입니다. 엔터티를 일반화(Generalization)하거나 상세화(Specialization)하면 슈퍼타입과 서브타입이 생깁니다. 일반화와 상세화는 아래 글을 참조하세요. 일반화(Generalization)와 상세화(Spec.. 더보기
어떤 경우에 통합을 고려하는가? – 다양한 경우 이번 글에서는 통합을 고려할 수 있는 다양한 경우를 설명하겠습니다. 다양한 케이스를 소개하지만 결국은 데이터의 본질이 유사하다는 것으로 통하게 됩니다. 역할을 관리하는 엔터티는 [그림1]과 같이 통합 모델을 사용할 때가 많습니다. [그림1] 사원은 특정 계좌에 대해 관리사원·유치사원·주문사원 등 여러 가지 역할을 할 수 있습니다. 여러 역할에 따른 엔터티가 개별로 존재하는 것이 아니라 계좌관계사원 엔터티와 같은 통합 엔터티로 존재하는 것이 바람직합니다. [그림2]와 같이 대칭적인 업무를 관리하는 데이터도 통합을 고려할 수 있습니다. [그림2] 이경우 업무 성격은 대칭적이지만 데이터 성격은 유사합니다. [그림2]는 식별자가 같지만 식별자가 다르더라도(매출전표번호와 매입전표번호) 통합할 수 있습니다. 매도와.. 더보기
어떤 경우에 통합을 고려하는가? - 두 번째 지난 번에 설명한 데이터 성격이 유사하다는 것이 데이터 통합을 고려할 가장 중요한 요소입니다. - 데이터의 성격(본질)이 유사할 때, 즉 집합의 정의가 유사할 때 [그림1]은 고객이 요청한 알림 서비스를 관리하는 엔터티입니다. [그림1] 고객알림서비스 엔터티는 고객별 알림 서비스를 관리하는 엔터티이고, 계좌알림서비스 엔터티는 계좌별 알림 서비스를 관리하는 엔터티입니다. 어떤 종류의 알림 서비스를 원하는지와 어떻게 알림 서비스를 받는지, 서비스 신청 일자와 알림을 몇 번 반복하는지 등의 데이터 성격은 두 엔터티가 동일합니다. 단지 고객을 지정해 서비스를 하는지, 계좌를 지정해 서비스를 하는지가 달라 주 식별자가 달라졌습니다. 그래서 엔터티가 통합되지 못한 예제인데 통합 대상입니다(주 식별자가 다른 여러 엔.. 더보기
데이터 통합이 어려운 이유 - 데이터 통합에 대한 불편한 진실 데이터 통합이 어려운 이유, 통합이 안 되는 이유는 크게 두 가지가 있습니다. 하나는 이전에 설명드린 통합의 단점 때문일 것입니다. 아래 글을 참고하세요. 통합이 대세인가? 통합 시 주의할 점 통합을 위한 통합은 경계하고, 단점은 충분히 고려해야 합니다. 오늘의 주제는 두 번째 이유입니다. 통합이 어려운 두 번째 이유는 조직에 있습니다. 조직 구조에 따라 통합되지 않는 경우가 빈번합니다. 단순하게 주식계좌 엔터티와 수익증권계좌 엔터티를 관리하는 담당자가 다르면 통합이 어렵습니다. 담당자만 달라도 어렵지만 담당자의 소속(팀)이 다르면 더욱 어렵고요. 이것의 근본적인 원인은 리소스입니다. 업무가 줄지 않는다면 다른 업무를 감당하기 벅차기 때문이죠. 진짜 감당하기 힘든지는 차치하고라도 지금보다 많아지는 것에 .. 더보기
어떤 경우에 통합을 고려하는가? 지난 달에 프로젝트를 마치고 중국 여행을 다녀왔습니다. 빚을 내서라도 애들하고 여행하라는 글을 자주 봐서 이번에 빚을 냈습니다. ㅎ 사실 여행에 대한 중요성은 이미 알고 있죠. 여유가 없었을 뿐이죠. 여행을 하면 시야가 넓어집니다. 많은 생각을 할 수 있어 좋고… 홀로 3개월을 돌아다니던 그때가 생각나네요. 어쨌든 고생해서 여행은 갔다왔는데 마음이 풀렸는지 블러그 슬럼프가 왔습니다. 그래서 다시 마음을 다잡고 글을 올리려고 합니다. 오늘부터 데이터를 통합할 수 있는 여러 가지 경우를 설명하겠습니다. 어떻게 통합하느냐에 대한 얘기보다 어떤 것(무엇)을 통합하느냐에 대한 얘기입니다. 가장 원론적인 원칙이 데이터의 성격이 유사할 때입니다. - 데이터의 성격(본질)이 유사할 때, 즉 집합의 정의가 유사할 때 데.. 더보기
통합이 대세인가? 통합 시 주의할 점 데이터(엔터티) 통합이 대세지만 통합 시 주의할 점이 있습니다. 일반적으로 많이 언급되는 것은 성능입니다. 데이터를 통합하면 데이터는 많아질 수밖에 없습니다. A집합과 B집합의 인스턴스 개수가 합쳐지기 때문에 데이터가 늘어납니다. 데이터가 증가하는 것과 성능은 유관합니다. 요건에 따라 때론 큰 차이가 생기고, 때론 미미한 차이가 생깁니다. 때론 성능이 좋아지기도 하고요. 통합해야 성능이 좋아지는 요건도 많아 저는 통합을 우선적으로 고려합니다. 그러면서 성능이 나빠질 수 있다는 점을 염두에 두죠. 흔하지는 않지만 대기 현상으로 인한 인서트 성능 저하를 고려할 때도 있습니다. 인서트가 많이 발생하는 엔터티에 어떤 엔터티를 통합하는 것은 바람직하지 않습니다. 인서트가 많다는 기준이 애매한데요. 참고로 말씀드리.. 더보기

티스토리툴바