3.1. 데이터 통합에 대한 서설

• 정규화(Nomalization)와 데이터 통합화(Generalization)는 모델링의 꽃이라 할만큼 중요한 부분이다.
• 정규화는 이론 영역이지만, 통합화는 직관적, 통찰력 기반으로 수행하는 영역이다.
• 데이터의 본질을 파악하여 분해하는 첫 번째 단계가 정규화이며, 분해된 데이터를 묶는 마지막 단계가 통합화다.
• 통합하려는 데이터는 핵심데이터일 가능성이 높다.(비핵심데이터는 무관심하기 때문에 통합대상에 거론되지 않는다.)
• 데이터 통합은 정규화를 기반으로 이뤄지므로 정규화를 우선 잘 해야 한다.

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

• 일반화 : 주민번호가 있는 개인, 사업자등록번호가 있는 사업자나 법인, 외국인등록번호가 있는 외국인 (개별적인 것) -> 자연인, 법인 (일반화) -> 고객(좀 더 일반화)
• 상세화 : 고객 (일반적인 것) -> 자연인 고객, 법인 고객 (구체적인 것)
• 엔터티를 일반화하거나 상세화하면 슈퍼타입과 서브타입이 생긴다.

3.3. 데이터 통합과 엔터티 통합

• 데이터 통합 : 유사한 성격의 데이터를 합치는 것을 말한다. 데이터라는 대상을 물리적/논리적으로 일반화하는 작업이다. 데이터 모델의 토대를 흔들 수 있는 만큼 많이 어렵다.
• 엔터티 통합 : 엔터티가 설계된 상태에서 두 엔터티를 통합하는 것을 의미한다. 데이터 통합에 비해 작업이 쉽다.

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

• 성능
  • 데이터를 통합하면 데이터는 많아질 수 밖에 없다. 따라서 성능이 나빠질 수 있다는 것을 염두에 둬야 한다.(반대로 성능이 좋아지는 경우도 있다.)
  • 인서트가 많이 발생하는 엔터티는 통합하지 않는 것이 좋다.(인서트시 대기시간이 길어져 성능이 나빠진다.)
• 정체성 희석
  • 지나치게 일반화하여 통합하면 데이터의 정체성이 희석된다.(예: 고객/사원/부서/거래처(개별적인 것) -> 파티(지나친 일반화, 파티에 뭐가 있는지 알 수 없다.) )
• 무결성 저하
  • 데이터를 통합함으로써 제약조건을 설정하지 못하거나, 도메인이 부정확해질 수 있다.
  • Not null 제약을 생성하지 못하는 것이 가장 흔하다. (예 : 외국인을 포함한 고객엔터티에 주민등록번호, 외국인등록번호를 고객식별번호라는 속성으로 관리하고자 할 때, 외국인 등록번호가 없는 외국인도 있다. 이 경우 고객식별번호를 not null 제약을 설정할 수 없다.)
  • 제약조건을 적게 설정함으로써 무결성이 떨어질 수 있다.
• 마이그레이션 가능여부
  • 통합을 위해 마이그레이션에 문제가 생기면 통합모델을 사용할 수 없다.

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

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

• 엔터티의 기초 속성이 유사할 때

• 데이터가 조회 등에 같이 사용될 때

• 역할을 관리할 때

• 대칭적인 업무일 때

• 계층 관계가 존재할 때

계층관계의 엔터티 통합은 수직적 통합으로 순환 관계가 발생한다.

• 공통 속성이 존재할 때

여러 엔터티에 공통으로 존재하는 통보주소/통보이메일/통보전화번호 속성은 별도의 엔터티로 빼서 통합 관리할 수 있다.
Clob 속성(그림 3.12)을 가진 엔터티를 별도의 엔터티로 따로 관리할 수 있다.(성능상의 이점)
그림 3.12처럼 통합엔터티가 하위(자식) 엔터티가 되면, 여러 상위 엔터티와 배타 관계가 발생하고, 상위 엔터티들의 식별자를 하위 엔터티(통합엔터티)에 모두 추가해야 하므로 관리하는데 어려움이 따른다. 그림 3.13처럼 관계속성으로 관리하는 게 좋다. (모델상에서는 통합엔터티가 상위 엔터티가 된다.)

• 배타관계가 발생할 때

그림3.14처럼 베타 관계는 모델의 구조를 복잡하게 만들고, 복잡한 조인을 발생해 바람직하지 않다. 배타 관계를 발생시킨 엔터티(주식종목/채권종목/선물옵션종목/수익증권종목)을 통합하면 거래내역 엔터티에 배타 관계가 발생하지 않는다.

• 집계 엔터티의 집계 대상이 같을 때

월이 모여서 분기가 되기 때문에 월에 대한 총액만 있으면 이를 합해서 분기를 구할 수 있다.
그림3.16은 집계내용(속성)이 달라 서로 다른데이터처럼 보이지만, 집계 대상은 주문 데이터로 동일해서 그림3.17과 같이 통합관리할 수 있다.
집계하려는 대상(주문)과 내용(매출액)이 동일하므로, 상품번호와 부서번호를 합한 기준으로 매출액을 집계가능하다. (단, 집계기준이 상세해져 인스턴스가 많아지는 점이 있다. )

• 비정규화를 수행할 때

그림 3.19는 마스터와 상세(detail) 관계로, 주문상품을 빠르게 조회하는 요건이 최우선이라면 통합하는 것이 유리하다.

• 일대일(1:1) 관계일 때

• 유사한 종류의 데이터를 하나의 기준으로 만들 때
  • 우편번호, 금리, 환율 등의 기준 데이터는, 1개로 통합하여 사용한다.
  • 여러개의 엔터티에 존재하면 정합성(불일치)가 발생할 수 있다.

• 업무가 변경될 가능성이 많을 때
  • 데이터를 일반화하여 통합관리할 경우 업무변경에 유연하다.
  • 엔터티를 추가하는 방식이 아닌 인스턴스를 추가하는 방식으로 처리가 가능할 수 있다.

3.6. 데이터 통합이 어려운 또 다른 이유

• 통합이 어려운 이유는 데이터가 조직이나 담당자에게 종속되어 있기 때문이다.
• 데이터 모델은 개발영역별 개발관점이 아닌 전사적인 데이터 관점에서 접근해야 한다.
• 데이터가 특정 조직이나 담당자에게 종속된 것이 아니라 전사에서 공유할 수 있어야 한다.

3.7. 데이터 주제 영역(Subjec Area)이란?

• 주제영역은 데이터 아키텍츠의 최상위 단계로, 비즈니스의 목표를 달성하는 데 필요한 데이터 그룹을 의미한다.
• 데이터를 유사한 성격으로 묶어 놓은 것이 주제영역이다. (예 : 고객, 상품, 조직 등)
• 그러나 현실에서는 주제영역을 기준으로 모델링하기 보단, 업무영역이나 어플리케이션 영역을 기준으로 모델링을 하는 경우가 많다. (주제영역 자체를 제대로 구축하는 것이 매우 어렵기 때문이다.)

3.8. 주제 영역 설계 방법

• 주제영역을 설계하기 위해선 모든 엔터티를 파악해야 한다.
• 주제영역은 아래와 같이 4가지 영역으로 분류할 수 있다.

• 위와 같이 4가지 주제영역은 하위 개념인 서브 주제영역(sub subject area)을 가진 수 도 있다.
• 서브 주제영역을 포함해서 주제영역 체계는 2~3단계가 적절하다.
• 주제영역을 설계할 때는 각 주제영역의 엔터티 숫자가 균일하도록 하는 것이 좋다.
• 주제영역의 명칭은 서브 주제영역을 포함해서 유일해야 한다.
• 주제영역을 설계할 때 업무영역이나 조직체계를 그대로 따르는 것은 피해야 한다. (조직과 데이터 주제영역은 별개이기 때문이다.)
• 반대로 주제영역을 조직체계에 반영하는 것은 바람직하다.

3.9. 데이터 오너십(Data Ownership)과 모델 오너십(Model Ownership)

3.10 데이터 통합의 시발점

• 데이터는 기업 전체의 공동 자산이라는 인식이 필요하다.
• 어떤 데이터도 특정 팀이나 특정인에게 소속돼서는 안된다.
• 업무영역과 개발 영역, 주제 영역이 반드시 일치할 필요는 없다.

3.11 데이터 통합과 정규화

• 데이터 통합은 정규화를 기반으로 이루어진다.
• 데이터 통합은 동질성을 가진 데이터를 합치는 것이다.
• 데이터 통합은 엔터티의 정의에 종속된 개념이다. 엔터티를 어떻게 정의하느냐에 따라 데이터 통합 기준이 달라질 수 있다. 엔터티의 정의는 정규화에 의해 명확해 진다.
• 데이터 통합은 정규화를 수행한 후에 고려하게 된다.
• 데이터 통합 작업을 수행한 후에 비정규화가 필요할 수 있으며, 비정규화를 한 후에 통합화를 해서는 안된다.

3.12 통합과 합체

통합	합체
*집합을 합치는 것을 의미한다. 2개 이상의 집합을 합쳐서 하나의 집합을 만드는 것이다 *성격이 유사하다 *인스턴스를 합치는 것으로 인스턴스가 증가한다.	*데이터 성격상 하나의 집합인데 성능상의 이유로 일부 속성을 분리한 1:1 관계를 다시 합치는 것을 의미한다. *성격이 동일하다. *속성을 합치는 것으로 엔터티의 속성이 증가한다.

3.13 주 식별자가 다른 엔터티의 통합

• 주 식별자 속성의 개수가 같을 때
  • 고객번호인지 계좌번호인지는 고객계좌구분코드 속성으로 구분할 수 있다.
  • 고객번호와 계좌번호의 길이로 식별이 가능하면, 고객계좌구분코드 속성을 생략가능하다.(가능한 추가하는 것이 좋다)

주 식별자를 통합하는 방법(주식별자의 길이가 구분코드에 따라 달라질 수 있다)
인조 식별자를 사용하는 방법(주식별자의 길이가 동일해진다. 인덱스가 하나 더 생성된다, 업무식별자가 주 식별자가 아니다.)

• 주 식별자 속성의 개수가 다를 때
  • 주 식별자의 개수는 다르나 공통속성이 존재하는 경우이다.
  • 그림 3.30은 종합계좌알림서비스 엔터티의 주 식별자를 통합엔터티의 주 식별자로 이용하였다.
  • 고객알림서비스라면 그림3.30 엔터티에서 종합계좌순번 속성에는 데이터가 존재하지 않으므로 기본값(default)을 사용해야 한다.(예: 9999)
  • 그림3.31처럼 인조식별자를 추가하여 통합할 수도 있다. 이 경우 고객에 대한 알림서비스라면, 종합계좌순번에 null을 허용해야 한다.(무결성이 낮아짐)

주 식별자는 통합하는 방법
인조식별자를 사용하여 통합하는 방법

• • 주 식별자에 공통속성이 존재하지만, 서로 개수도 다르고, 유사성이 없는 경우, 인조식별자를 사용한다.

인조식별자를 사용하여 통합하는 방법

• • 그림3.35은 상위 주식별자의 일부만 하위 엔터티의 식별자로 상속하고, 나머지를 하위 엔터티의 일반속성으로 상속한 경우로 원칙적으로 잘못된 모델이다. 성능향상을 위해 예외적으로 사용할 수는 있다. (상위 엔터티 주식별자를 모두 하위 엔터티 식별자로 상속하거나, 모두 일반 속성으로 상속하는 것이 바람직하다. "알림서비스순번" 같은 부분인조식별자도 가능한 쓰지말자)

원칙적으로 틀린(잘못된) 모델

• • 통합하려는 엔터티의 주 식별자가 전혀 다른 모델로, 인조식별자를 사용할 수 있다.

인조 식별자를 사용하여 통합하는 방법

• • 일반적인 속성명을 미리 정해놓고 대상이 추가될 때를 고려해서 사용하는 매우 유연한 모델이다. 엔터티의 의미가 너무 희석되어 사용하기 혼란스러운 단점이 존재한다.

매우 유연한 모델

3.14 서브타입에 대한 서설

• 엔터티를 일반화하거나 상세화하면 슈퍼타입과 서브타입이 생긴다.
• 일반화를 수행하는 과정에서 서브타입의 공통 속성을 슈퍼타입으로 도출한다.
• 슈퍼타입은 일반적인 속성으로 모든 서브타입으로 상속되는 공통속성이다.
• 슈퍼타입과 서브타입은 부모/자식의 상하관계가 아니라 동등한 관계이다. 슈퍼타입과 서브타입을 하나의 인스턴스(1개의 row)로 인식해야 한다.
• 공통점과 차이점을 보기 위한 유용한 방법이다.
• 서브타입은 슈퍼타입의 부분집합이다.
• 서브타입 인스턴스에는 그에 해당하는 슈퍼타입의 인스턴스가 존재하나, 반대의 경우는 성립하지 않을 수 있다. 즉, 자신의 고유속성을 갖지 않는 서브타입이 존재할 수 있다.
• 서브타입 엔터티 간의 관계는 일반적으로 상호 배타적이지만, 간혹 포함적일 때도 있다.

슈퍼타입과 서브타입의 예

3.15. 서브타입(SubType)과 부분집합(Subset)

• 서브타입 : 전체 집합인 슈퍼타입을 부분집합으로 나눈 것이 서브타입이다. 서브타입에는 부분집합 개념이 포함돼 있다.
• 부분집합 : 전체 인스턴스를 종(縱)으로 나눈 개념이다.

3.16. 서브타입은 어떻게 도출하는가?

• 두 개 이상의 유사한 엔터티에서 공통 속성을 분류하는 방법과 (엔터티의 통합-Generalization)
• 복잡한 하나의 엔터티에서 유사한 속성끼리 분류하는 방법이 있다. (엔터티의 상세화-Specialization)
• 슈퍼타입 엔터티에는 서브타입을 구분할 수 있는 속성을 관리해야 하는데, 이를 서브타입 구분자라고 한다. (슈퍼타입 엔터티의 고유속성)

엔터티를 통합하는 과정에서 생기는 서브타입 예제
엔터티를 상세화 하는 과정에서 생기는 서브타입 예제

3.17. 왜 서브타입을 사용하는가?

• 데이터가 어떤 종류(집합)으로 이루어졌는지를 한눈에 보여주기 위함이다.

고객의 종류를 추측할 수는 있으나 확신할 수 없는 모델
고객의 종류가 개인고객, 법인고객임이 분명한 모델
업무 규칙까지 확인 할 수 있는 모델(개인고객의 취미를 여러개 관리하며, 법인고객의 주요제품의 총판매액을 관리함, 주요제품은 개인고객과는 관련이 없음
확장성을 고려한 모델 (향후 DVD등을 판매하기 위해 기타 서브타입을 도출함

3.18. 한 엔터티에 서브타입이 여러 개 존재한다?

• 한 엔터티에 서브타입의 후보가 여러 개 존재할 때가 있다.
• 하지만 최종 서브타입은 그 집합을 가장 잘 나타내는 1개만 존재해야 한다. 그렇지 않으면 물리 모델로 변환할 수 없다.
• 간혹 집합을 가장 잘 표현한 분류를 정하기 어려울 때가 있는데, 이때는 고유속성이 존재하는 서브타입을 분류로 결정한다.

바커 표기법
IE 표기법

• 슈퍼타입에 존재하는 속성과 서브타입에 존재하는 속성을 합하면 전체 속성이 되어야 하나, 그림 3.52는 그렇지 못하다.

• 그림3.52에서 주식/채권 분류를 서브타입으로 설정한 경우로, 매수/매도, 국내/국외는 코드로 도출했다.