03. 데이터 통합과 서브타입 이야기 (1)

3.1 데이터 통합에 대한 서설

모델링의 처음과 끝 = 정규화와 통합화

데이터 통합은 정규화를 기반으로 이뤄져야 하며, 정규화가 기반이 되지 않은 통합은 의미가 없다.

 

3.2 일반화와 상세화

데이터 통합

• 일반화(Generalization): 유사한 것을 묶는 것(ex. 외국인 고객 → 고객)
• 상세화(Specialization): 차이를 도출하는 것(ex. 고객 → 개인고객, 법인고객 등)

엔터티를 일반화하거나 상세화하면 슈퍼타입과 서브타입이 생긴다.

 

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

데이터 통합: 유사한 성격의 데이터를 합치는 것

• 데이터라는 의미에는 아직 엔터티가 되기 이전 상태인 집합이라는 개념이 포함되어 있다.
• 데이터 통합이란 데이터라는 대상을 물리적, 논리적으로 일반화하는 것을 의미한다.

엔터티 통합: 이미 엔터티가 설계된 상태에서 두 엔터티를 통합하는 것을 의미

• 물리적인 개념에 한정되는 느낌이 강하다.
• 데이터 통합이 엔터티 통합에 비해 난이도가 높고 어려운 작업이다. 

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

 

3.4 통합이 대세인가?

데이터 통합 시 주의할 점

1. 성능
   • 데이터를 통합하면 데이터는 많아질 수밖에 없다. 데이터가 증가하는 것은 성능과 유관하다.
   • 데이터 증가와 성능은 상관관계가 있기 때문에 주의해서 살펴야 한다. 
   • 흔하지는 않지만 대기 현상으로 인한 쓰기 성능 저하를 고려할 때도 있다.(인서트가 많이 발생하는 엔터티에 다른 엔터티를 통합하는 것은 바람직하지 않다.)
2. 정체성 희석
   • 지나치게 일반화하면 데이터의 정체성이 희석된다.
   • 의도적이지 않은 통합(모르고 하는 통합)은 개별 데이터의 정체성이 잘못됐기 떄문에 통합의 적정성을 판단하기 어렵다. 즉, 데이터 정의에 근본적인 문제가 있어 분간이 힘들다.
   • 의도하지 않은 통합, 스스로도 잘 모르는 통합, 통합을 위한 통합을 하지 않기 위해서는 데이터 정의를 제대로 해야 한다.
3. 무결성 저하
   • 데이터를 통합하면 데이터 무결성이 저하될 수 있다. 통합해서 같이 사용하게 됨으로써 제약 조건을 생성하지 못하거나, 도메인을 정확히 설정하지 못할 수 있다.(ex. NOT NULL 제약을 생성하지 못하는 것)
   • 속성의 데이터 무결성이 다소 저하되는 단점보다는 데이터가 통합된 것의 장점이 훨씬 크지만, 데이터를 일반화할수록 무결성이 떨어질 수 있따는 점은 염두해 두어야 한다. 물론 데이터가 통합되면 특정 속성이 하나만 존재한다는 측면에서는 일종의 중복 속성이 없어지는 것이므로 무결성이 좋아진다고 볼 수 있다.
4. 마이그레이션 가능 여부
   • 통합하는 데 있어 모든 조건을 만족하더라도 마이그레이션에 문제가 생기면 통합 모델을 사용할 수 없다.
   • 마이그레이션하는 데 문제가 있는데도 불구하고 통합한다면 이는 무리한 통합니다.

 

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

데이터를 통합할 수 있는 여러 가지 경우

1. 데이터의 성격이 유사할 때
   • 데이터의 성격이 개념(본질)적으로 유사하면 통합할 수 있다.
   • ex. 주식계좌/선물옵션계좌/수익증권계좌, 개인고객/법인고객/가망고객 
2. 엔터티의 기초 속성이 유사할 때
   • 엔터티에서 관리하는 데이터의 본질은 속성으로 나타나므로 속성이 유사하면 본질이 유사할 가능성이 높다.
   • ex. 주식종목/선물옵션종목/CP종목, 국내고객/국제고객, HTS서비스/계좌이체서비스
3. 데이터가 조회 등에 같이 사용될 때
   • 데이터를 같이 본다는 측면이 통합하는 명분이 된다.(성격이 완전히 다른 데이터를 같이 볼 이유는 없으므로, 데이터를 같은 방법으로 사용한다면 유사한 데이터일 가능성이 높다.
   • ex. 고객우편주소/고객전자주소/고객전화번호
4. 역할을 관리할 때
   • 역할을 관리하는 엔터티는 대체로 통합하는 것이 좋다.
   • ex. 계좌관리사원/계좌유치사원/계좌주문사원
5. 대칭적인 업무일 때
   • 매도와 매입, 입고와 출고 등의 대칭적인 업무를 관리하는 데이터도 통합을 고려할 수 있다.
6. 계층 관계가 존재할 때
   • 대부분의 엔터티 통합은 수평적인 관계의 엔터티가 통합돼 서브타입이 발생하지만, 계층 관계의 엔터티 통합은 수직적  통합으로 재귀 관계가 발생한다.
   • ex. 본사/부서/팀
7. 공통 속성이 존재할 때
   • 공통 속성이 별도의 데이터 성격을 지닌다면 그 속성만을 분리해 통합을 고려할 만하다.
   • 여러 엔터티에 긴 텍스트나 특수 데이터가 존재할 때 그 데이터들을 별도의 엔터티에서 통합 관리할 수 있다.
   • ex. CLOB, BLOB 타입 데이터
8. 배타 관계가 발생할 때
   • 배타 관계는 모델의 구조를 복잡하게 만들고, 복잡한 조인이 발생해 바람직하지 않은 관계다. 따라서 배타 관계가 발생하지 않도록 설계하는 것이 바람직하다.
   • 물론 배타 관계가 발생했다고 무조건 통합해서는 안 된다. 특히 주 식별자가 다른 배타 관계일 때는 더욱 주의해야 한다.
9. 집계 엔터티의 집계 대상이 같을 때
   • 집계 엔터티를 설계할 때, 집계하려는 대상이 같다면 통합을 검토해야 한다. 집계 기준이 다르면 주 식별자가 달라지기 때문에 통합을 못 하지만, 집계 기준이 유사하거나 포함 관계가 있다면 통합하는 것이 좋다.
10. 비정규화를 수행할 때
    • 정규형 모델에 성능 문제가 발생하면 비정규화를 하면서 엔터티를 통합할 수 있다.
11. 일대일 관계일 때
    • 일대일(1:1) 관계가 발생한 엔터티는 통합할 수 있다.
    • 일대일 관계의 엔터티를 합칠 때는 두 엔터티의 성격이 같은지, 관계비가 불변인지 등을 검토해야 한다.
12. 유사한 종류의 데이터를 하나의 기준으로 만들 때
    • 기준 데이터는 업무의 기준이 되기 때문에 전사에서 하나만 존재해야 한다. 성격이 다른 경우가 아니라면 기준 데이터는 하나의 엔터티에서 통합 관리해야 한다.
    • 기준 엔터티를 제대로 통합해서 사용하면 기준이 명확해지기 때문에 업무의 혼선도 줄어들고, 데이터 무결성이 좋아지기 때문에 품질 또한 향상된다.
13. 업무가 변경될 가능성이 많을 때
    • 데이터를 일반화시킬수록 업무 변경에 유연한 모델이 된다.

 

결론: 아래 세 가지 조건 중에서 하나라도 만족하면 우선 통합을 고려해 보는 것이 좋다.

• 데이터의 본질(성격)이 유사하다
• 식별자가 동일하면서 유사한 속성이 존재한다
• 식별자는 다르지만, 기초 속성이 유사하다

 

3.6 통합을 고려하지 않아도 되는 경우

1. 엔터티가 같이 조회되지 않을 때
2. 유사 종류의 엔터티가 향후에도 늘어나지 않을 때 
3. 유사한 하위 엔터티가 없을 때

 

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

• 데이터 통합이 어려운 두 번째 이유는 조직 구조와 담당자 분리 때문으로, 업무 부담과 방어 심리가 통합을 방해한다.
• 프로젝트가 클수록 전사적 관점과 추진력 있는 통합 노력이 필요하다.
• 데이터 중심 조직 체계가 마련되지 않으면, 담당자 차이로 핵심 데이터조차 통합되지 않는 문제가 계속된다.
   

 

3.8 데이터 주제 영역이란?

주제영역: 데이터 타키텍처의 최상위 단계로, 비즈니스의 목표를 달성하는 데 필요한 데이터 그룹을 의미

• 여기저기 산재된 유사한 성격의 데이터를 체계화해 그룹으로 묶은 것을 의미한다.
• 주제 영역을 구축하는 가장 근본적인 목적은 기업의 정보 체계 구조를 한눈에 파악하고 관리할 수 있도록 하기 위해서다.
• 주제 영역은 이미 일반화 개념을 사용해 데이터를 분류한 것이므로, 그에 따른 모델도 자연히 통합된 관점을 유지할 수 있다. 또한 데이터나 모델 측면에서 통합돼 있기 때문에 원하는 데이터를 전사에서 쉽게 찾을 수 있으며, 그로 말미암아 쉽게 재사용이 가능하다.
• 주제 영역과 데이터 모델(ERD)이 일치하면 모델을 관리하기도 수월해진다.

 

3.9 주제 영역 설계 방법

주제 영역의 두 가지 분류

1. 실체 주제 영역(Thing Subject Area)
   • 사람과 사물을 의미하는 데이터로 이루어진 주제 영역
   • ex. 업무를 수행하는 주체와 대상, 자원 등과 관련된 데이터(고객, 계좌 조직 등)
2. 행위 주제 영역(Do Subject Area)
   • 여러 가지 행위를 나타내는 데이터로 이루어진 주제 영역
   • 업무를 수행한 결과가 모두 포함돼 너무 포괄적이라, 보통 행위 데이터를 다시 분류하여 계약/주문/결제 등과 같은 주제 영역으로 나눌 수 있다.

주제 영역을 설계하는 방법

• 실체, 행위, 기준, 가공 엔터티 집합으로 설계한 주제 영역에는 일반적으로 하위 개념인 서브 주제 영역이 존재한다.
• 서브 주제 영역을 구분하는 기준
  • 실체 주제 영역일 때는 실체의 종류가 기준이 됨
  • 행위 주제 영역일 때는 프로세스가 기준이 됨
• 주제 영역을 설계할 때는 가능한 각 주제 영역의 엔터티 숫자가 균일하도록 하는 것이 좋다.
• 주제 영역 명칭은 서브 주제 영역을 포함해서 유일해야 한다. 
• 업무 영역을 그대로 따르는 것은 피해야 한다.

 

3.10 데이터 오너십과 모델 오너십

특정 데이터를 제외한 모든 데이터는 누구나 사용할 수 있어야 하며, 특정 팀이나 특정 담당자의 소유가 아니므로 데이터에 대한 오너십은 기업 전체에 있는 게 원칙이다. 다만 데이터의 접근이나 생성/수정에 대한 권한을 관리해 데이터가 훼손되지 않고 품질이 유지될 수 있도록 해야 한다.

데이터 오너십은 데이터 통합에 반하는 개념 → 모델 오너십이라는 용어 사용

 

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

• 모델러에겐 엔터티가 어떤 주제 영역에 속하는지를 의미하는 모델 오너십이 중요하다.
• 엔터티의 기초 속성을 기준으로 모델 오너십을 정할 필요가 있다. 기초 속성이 아닌 담당자를 기준으로 판단하면 안 된다.
• 모델 오너십이 결정된 엔터티는 데이터 오너십이나 업무 오너십에 의해서 바꿔서는 안 된다.

 

3.11 데이터 통합의 시발점

데이터 통합의 시발점은 데이터는 기업 전체의 공동 자산이라는 인식에서부터 시작된다. 특수한 데이터를 제외하고 어떤 데이터도 특정 팀이나 특정인에게 소속돼서는 안 된다.

 

3.12 데이터 통합과 정규화

• 데이터 통합은 정규화를 기반으로 해야 하며, 정규화 없이 이루어진 통합은 의미가 없다.
• 정규화를 통해 데이터의 성격이 명확해져야 동질성 판단과 통합이 가능하다.
• 통합된 모델은 확장성과 유연성이 높아지며, 이는 정규화를 선행했기 때문에 가능한 결과이다.

 

3.13 통합과 합체

통합은 집합을 합치는 것을 의미한다. 두 개 이상의 집합을 합쳐서 하나의 집합을 만드는 것을 통합이라 한다.

합체는 일대일 관계의 엔터티를 합치는 것을 의미한다.

 

데이터 추출 시간을 줄이기 위한 일종의 비정규화 방법인 엔터티 합체와 데이터(엔터티) 통합은 엄밀히 다르지만, 넓게 보면 합체도 통합의 범주에 포함된다. 다만 통합과 합체가 다르다는 것을 인지하고 구별할 필요가 있다. 이는 엔터티를 이해하는 방법 중 하나며, 이런 방법들이 모이면 엔터티를 쉽게 이해하고 모델링을 수월하게 할 수 있다.

 

 

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

주 식별자 속성의 개수가 같을 때

• 아래의 두 엔터티를 통합하는 방법은 두 가지가 있다.

 

• 첫 번째 방법은 주 식별자를 통합하는 것이다.

• 두 번째 방법은 인조 식별자를 사용하는 것이다. 이 방법의 경우 첫 번째 방법에 비해 속성이 하나 더 사용됐고, 인덱스가 하나 늘어났으며 조회에 자주 사용되는 업무 식별자가 주 식별자가 아닌 점이 단점이다.

 

 

주 식별자 속성의 개수가 다를 때

주 식별자 속성의 개수가 다를 때의 통합은 다소 복잡해진다. 이때는 통합했을 때의 장/단점을 심도 있게 검토해야 한다.

• 아래 모델을 통합하는 방법은 두 가지가 있다.

• 첫 번째 방법은 종합계좌알림서비스 엔터티의 주 식별자가 고객알림서비스 엔터티의 주 식별자를 포함하기 때문에, 종합계좌알림서비스 엔터티의 주 식별자를 통합 엔터티의 주 식별자로 사용하는 것이다. 이때 데이터가 고객에 대한 알림서비스라면 종합계좌순번 속성에는 데이터가 존재하지 않는데, 주 식별자에는 널 데이터가 존재할 수 없기 때문에 종합계좌순번 속성에는 기본 값을 사용해야 한다.

• 두 번째 방법은 인조 식별자를 사용하는 것이다. 이 모델에서 고객에 대한 알림서비스라면 종합계좌순번 속성에 널 값을 허용해야 한다.

• 위 모델은 통합 대상 엔터티의 주 식별자가 다양할 때 사용할 수 있는 매우 유연한 모델이다. 이 모델은 일반적인 속성 명을 미리 정해놓고 대상이 추가될 때를 고려해서 사용하는 매우 유연한 모델이지만, 엔터티의 의미가 상당히 희석되며 너무 일반화돼서 사용하기 혼란스러운 단점이 있는 모델이다.

 

결론

통합 엔터티의 주 식별자는 가능하면 통합 대상 엔터티의 주 식별자를 활용하는 것이 좋다. 업무 식별자를 사용해야 데이터를 생성하는 기준이 명확해지기 때문이다. 하지만 인조 식별자를 사용해서라도 유사한 데이터를 관리하는 엔터티는 통합하는 것이 우선이다.

 

3.15 서브타입에 대한 서설

슈퍼타입과 서브타입의 일반적인 구조

 

• 슈퍼타입의 속성은 모든 서브타입으로 상속되는 공통 속성이며, 슈퍼타입과의 관계는 서브타입에도 해당되는 관계다.
• 슈퍼타입 속성은 일반적인 속성이다. 반면에 서브타입 속성은 고유한 속성이다. 따라서 서브타입 속성은 슈퍼타입에 속하지 않는다.
• 슈퍼타입과 서브타입 관계는 체계를 의미하는 상하 관계가 아니라 포함 관계다. 즉 서브타입은 슈퍼타입의 일부분이다.
• 슈퍼타입과 서브타입은 상/하위 개념의 부모/자식 관계가 아니라 동등한 관계다. 슈퍼타입과 서브타입을 하나의 인스턴스로 인식해야 한다.
• 서브타입 엔터티 간의 관계는 일반적으로 상호 배타적이지만, 간혹 포함적일 때도 있다. 

 

3.16 서브타입과 부분집합

서브타입을 이해하기 위해서는 부분집합(Subset)을 이해해야 한다. 전체 집합(Set)인 슈퍼타입을 부분집합으로 나눈 것이 서브타입이기 때문이다.

엔터티: 서로 명확하게 구별되는 데이터의 집합

집합의 원소: 업무 식별자로 대표되는 하나의 인스턴스를 의미

 

부분집합은 전체 인스턴스를 종으로 나눈 개념이다.

 

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

서브타입을 도출하는 방법

1. 두 개 이상의 유사한 엔터티에서 공통 속성을 도출하는 방법 → 엔터티를 통합하는 행위
2. 복잡한 하나의 엔터티에서 유사한 속성끼리 분류하는 방법 → 엔터티를 상세화/논리화하는 행위

 

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

• 데이터가 어떤 종류(집합)로 이루어졌는지를 한눈에 보여주기 위해
• 모델의 확장성을 고려할 때

서브타입 모델은 데이터가 어떤 종류(집합)로 구성됐는지를 입체적으로 보여주는 모델이다. 부분집합을 잘 정의할 수 있는 사람이 서브타입을 잘 설계하며, 서브타입을 제대로 설계하는 모델러가 좋은 모델러다.

 

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

서브타입이 여러 개 존재하는 이유

1. 집합을 나눈 관점에 따라 다양한 뷰가 존재하기 때문
   • 특정 집합은 기준이 무엇이냐에 따라 여러 가지로 분류할 수 있다. 그렇기 때문에 서브타입이 여러 개인 것처럼 보이지만 여러 분류 중에 가장 의미 있는 분류를 서브타입으로 도출해야 한다. 간혹 집합을 가장 잘 표현한 분류를 정하기 어려울 때가 있는데, 이때는 고유 속성이 존재하는 분류를 서브타입으로 정하면 된다.
2. 코드를 서브타입으로 표현하기 때문
   • 코드 속성에 존재할 수 있는 코드 명을 서브타입으로 표현하면 모델의 가독성이 높아져서 코드를 간혹 서브타입처럼 표현하는데 이는 바람직하지 않다.