05 데이터 통합 (Generalization)

 

 

 

 

 

 

 

- 유사한 성격의 데이터, 동질성을 가진 데이터를 더 큰 주제로 합치는 것

 

- 통합 대상에는 속성과 관계, 엔터티가 있지만 대부분 엔터티 통합이 주를 이룬다.

 

- 속성과 엔터티에 대한 명확한 이해가 선행돼야 하므로 정규화를 끝낸 다음에 엔터티를 통합해야 데이터 성격에 맞는 유연한 모델이 된다.

 

- 엔터티를 어떻게 정의하느냐에 따라 데이터 통합의 기준이 달라질 수 있다.

 

- 완전 정규형을 사용해 데이터 통합(일반화) 작업을 수행하고 비정규화가 필요하면 통합된 모델에서 수행한다.

 

- 업무가 바뀔 가능성이 많을수록 데이터를 일반화 시켜야 한다.

 

- 성격, 정체성, 주제 등으로 판단했을 때 동질성이 빈약한 데이터를 통합하는 것은 주의해야 한다.

 

- 엔터티를 통합하면 데이터는 많아질 수밖에 없다. 그러면 성능상 문제도 발생할 수 있으므로 성능 측면은 고려해야 한다.

 

- 실체 엔터티는 최대한 통합하고 행위 엔터티는 가능한 통합하는 것이 원칙이다. 그리고 실체, 행위, 기준 엔터티 간에는 통합하지 않아야 한다.

 

- 데이터 모델은 개발 영역별 개발 관점이 아닌 전사적인 데이터 관점에서 접근해야 한다. 개발 영역과는 무관하게 통합돼 전사에서 공유될 수 있어야 한다.

 

 

 

5.2. 데이터 통합의 장·단점

 

 

○ 데이터 통합의 장점

 

 

- 확장성, 즉 업무 변화에 유연하게 대처할 수 있고 신속하게 대응할 수 있다.

• 비슷한 유형의 업무가 발생했을 때 별도의 엔터티나 관계의 추가 없이 속성이나 속성 값을 추가해서 처리할 수 있다.

- 하위 엔터티에 배타 관계를 발생시키지 않게 된다.

• 배타 관계는 모델도 복잡하게 만들지만 액세스 경로를 복잡하게 만들어 조회 효율성이 떨어진다.

- 데이터 모델이 단순해진다.

 

 

○ 데이터 통합의 단점

 

 

- 데이터 통합에 대한 기준이 명확하지 않아 데이터를 통합할 때 마음대로 통합할 가능성이 있다.

 

- 데이터가 변질될 수 있다.

 

- 데이터 통합이 일정 범위를 넘으면 업무가 제대로 보이지 않는다.

 

- 데이터를 통합하면 성능에 악영향을 미칠 수 있다.

 

- 빈번하지 않지만 업무가 변경됐을 때 결과적으로 엔터티가 분할되는 예가 발생할 수 있다.

 

- 데이터가 통합되면 CASE 툴에 따라서 모델에 대한 이해도가 떨어질 수 있다.

 

- 데이터가 통합되면 자연히 업무 프로세스나 화면이 통합돼 어플리케이션 로직이 다소 복잡해지고 SQL도 복잡해질 수 있다.

 

- 데이터를 통합하면 널(Null) 값의 사용이 늘어난다.

 

- 현행 데이터가 존재하면 마이그레이션도 이슈가 될 수 있다. 마이그레이션은 데이터 모델링과 밀접하게 관련돼 있으므로 마이그레이션에 문제가 없는지를 심도 있게 고려해야 한다.

 

 

 

5.3. 엔터티 통합 대상

 

 

○ 엔터티를 통합하는 기준

 

 

- 데이터의 성격(주제)이 유사하다.

 

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

 

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

 

 

** 위와 같은 기준에 하나라도 해당하면서 아래와 같은 조건을 모두 만족하면 통합을 시도해야 한다.

 

 

○ 엔터티 통합 조건

 

 

- 별개의 요건으로 사용되지 않고 주로 같이 조회된다.

 

- 통합해서 성능 문제를 일으키지 않는다.

 

- 현행 데이터가 존재하며 마이그레이션하는 데 문제가 없다.

 

 

○ 통합 대상 엔터티 예

 

 

- 데이터의 성격이 유사한 경우

 

 

[그림 5.1] 계좌 엔터티, 실체 엔터티, 주 식별자 같음, 기초 속성 성격 유사

 

 

 

 

 

 

[그림 5.2] 고객 엔터티, 실체 엔터티, 주 식별자 같음, 기초 속성 성격 유사

 

 

 

 

 

 

 

 

- 역할을 관리하는 엔터티

 

 

[그림 5.3] 역할 관리 엔터티, 속성과 관계 유사

 

 

 

 

 

 

 

- 데이터 성격은 동일하나 주식별자가 다른 엔터티

 

 

[그림 5.4] 주 식별자가 다른 통합 대상 엔터티

 

 

 

 

 

 

 

[그림 5.5-1] 주 식별자를 통합

 

 

 

 

 

 

 

[그림 5.5-2] 인조 식별자를 사용, 고객계좌통합번호가 업무 식별자라는 것을 유니크 인덱스로 관리해야 함

 

 

 

 

 

 

[그림 5.6] 일반화해 통합할 수 있는 대상 엔터티 → 고객연락처 엔터티로 통합(일반화)

 

 

 

 

 

↓

 

고객연락처 엔터티로 통합(일반화)

 

↓

 

 

 

[그림 5.7-1] 고객의 연락처 데이터는 유형별로 별도의 인스턴스에서 관리, 널(Null) 값을 허용하지 않는 경우

 

 

 

 

 

위의 경우 실제 주소와 전화번호, 전자주소 데이터를 관리하며 값이 항상 존재해야 하므로 널(Null)이 허용되지 않아야 한다.

 

 

↓

 

속성의 분리가 필요한 경우

 

↓

 

 

[그림 5.7-2] 고객의 연락처 데이터는 유형별로 별도의 인스턴스에서 관리, 널(Null) 값을 허용하는 경우

 

 

 

 

 

우편주소, 전화번호, 전자주소 속성은 배타 속성이므로 연락처유형코드 속성에 따라서 셋 중의 하나의 값만 발생

따라서 우편주소, 전화번호, 전자주소 속성에 널(Null)을 허용해야 함

 

 

 

[그림 5.8] 대칭적인 업무로 데이터 성격이 유사한 경우, 매출과 매입, 매도와 매입, 입고와 출고 등

 

 

 

 

 

매출 전표번호와 매입 전표번호가 상호 배타적이 아니라면, 즉 중복될 수 있다면 통합한 전표 엔터티의 주 식별자에 전표구분코드가 포함돼야 한다.

 

 

 

- 공통 속성과 주 식별자가 같은 엔터티의 통합

 

 

[그림 5.9] 주식종목, 선물옵션종목, CP종목 엔터티: 주 식별자가 같고 유사성이 존재하므로 통합 대상, 종목별로 관리되는 개별 속성이 공통 속성보다 많이 존재하므로 서브타입별로 개별 속성을 관리하는 것이 바람직

 

 

 

 

• 미통합 시 새로운 종목이 추가될 때마다 엔터티, 배타관계 등이 늘어남

• 미통합 시 UNION 구문에 새로운 종목에 대한 구문의 추가, 성능, 프로그램 수정 등의 문제 발생

 

 

[그림 5.10] 국내고객, 국제고객 엔터티

 

 

 

 

 

 

 

[그림 5.11] 담보, 신용, 청약자금 대출 엔터티

 

 

 

 

 

- 엔터티의 데이터 성격은 다르나 엔터티의 속성이 유사한 경우

 

 

[그림 5.12] HTS서비스, 계좌이체서비스 엔터티

 

 

 

 

 

 

 

 

 

[그림 5.13] 본사 --> 부서 --> 팀 과 같이 계층관계의 엔터티 통합: 수직적 통합으로 순화(Recursive) 관계 발생

 

 

 

 

 

 

- 유사한 속성이 여러 엔터티에 존재하고, 그 속성이 별도의 데이터 성격을 지닌 경우: 해당 속성만을 통합

 

 

[그림 5.14, 15] 주식, 선물옵션, 수익증권 계좌 엔터티: 통보 데이터를 관리하는 속성이 공통으로 존재, 각 계좌 엔터티에서 통보 연락처 속성만을 분리해 통합

 

 

 

 

 

 

 

[그림 5.16] 내용 속성만을 통합한 모델

 

 

 

 

 

위 엔터티의 참조내용 속성과 같은 긴 텍스트 내용을 관리하면 인스턴스가 길어져 한 블록(Block)에 많은 인스턴스를 저장하지 못한다.

 

 

↓

 

텍스트 내용을 관리하는 속성 분리

 

 

 

 

 

인스턴스 길이가 축소되어 핵심 속성으로 구성된 많은 인스턴스를 한 블록에 저장할 수 있다.

텍스트 내용은 보통 상세 조회 화면에서 보여주므로 인스턴스별로 조회가 이루어져 많은 I/O가 발생할 수 있으나 단 건이므로 성능에 영향이 적음

단, 텍스트 내용을 대량으로 조회하는 요건이 있다면 성능에 문제가 발생할 수 있음

 

 

 

- 배타 관계로 인한 통합 대상 엔터티

 

• 배타관계가 발생하면 조인하기 불편하고, 요건에 따라 성능에 치명적인 영향을 미친다.

• 배타관계를 없애기 위해서는 배타 관계를 발생시킨 엔터티를 통합하면 된다.

 

 

[그림 5.17] 배타 관계로 인한 통합 대상 엔터티

 

 

 

 

[ 이미지출처: http://www.gurubee.net/lecture/3602 ]

 

 

 

 

[그림 5.18] 배타 관계를 발생시킨 엔터티의 통합: 주식종목, 채권종목, 선물옵션종목, 수익증권 종목 엔터티를 종목 엔터티로 통합

 

 

 

 

 

[ 이미지출처: http://www.gurubee.net/lecture/3602 ]

 

 

 

 

- 유사한 데이터지만 화면이나 레포트 등 요구하는 뷰(View)의 형태에 따라 엔터티가 별도로 존재하는 경우의 통합

 

 

[그림 5.19] 집계 기간이 다른 통합 대상 엔터티

 

 

 

월별 매출액을 합하면 분기별 매출액을 구할 수 있어 상품별분기매출 엔터티는 굳이 필요 없다.

 

 

 

 

[그림 5.20] 집계 속성이 다른 엔터티의 통합

 

 

 

 

 

 

 

[그림 5.21] 집계 기준(Dimension)이 다르지만 데이터가 유사한 엔터티의 통합

 

 

 

 

 

'부서별상품별월매출' 엔터티처럼 디멘젼을 통합하고 디멘젼에 따른 인스턴스를 생성할 수 있는지를 고려해 가능하면 통합

 

 

- 엔터티 간 일대일(1:1) 관계일 경우의 통합

 

 

 

[그림 5.22] 일대일 관계

 

 

 

 

 

일대일 관계의 엔터티는 개념 모델링이나 논리 모델링 단계에서 정확히 도출 후

분해, 통합을 고려해야 함

 

 

 

 

[그림 5.23] 일대일 관계를 통합한 엔터티

 

 

 

 

 

입고와 출고를 개별적인 인스턴스로 관리하는 방법

하나의 고유한 제품에 대해 두 개의 인스턴스가 생성될 수 있다. 즉 제품코드와 입출고구분코드 속성이 업무 식별자임

 

 

 

 

 

하나의 제품에 대해 하나의 인스턴스가 발생

제품코드만 업무 식별자이며 입고될 때 생성된 인스턴스에 대해 해당 제품이 출고될 때

출고일자, 출고부서코드, 출구사원번호 속성을 업데이트하게 된다.

 

 

• 업무에 따라 판단이 달라질 수 있지만 입고에 대한 출고만 존재하면 아래 모델이 사용하기 편리하며 성능 측면에서도 유리하다.

• 만약 입고에 대해서 출고가 여러 번 발생하면 아래 모델은 사용할 수 없을 것이다.

 

 

5.4. 데이터 오너십

 

 

- 기초 속성과 모델 오너십

 

 

 

 

 

 

 

- 데이터 오너십: 실무에서도 명확한 구분이 없음

 

- 모델 오너십(Model Ownership): 엔터티가 어떤 주제영역의 모델(ERD)에 속하는지를 의미한다.

 

- 업무 오너십: 어플리케이션을 개발할 때, 업무를 분류하는 기준을 의미, 주제영역과는 무관하다.