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

3.20 서브타입과 코드

서브타입과 코드는 다르므로 구분해서 사용해야 한다.

 

서브타입	코드
전체 집합에 대한 부분집합을 표현	특정 속성의 구분을 표현
전체 집합의 성격을 파악	한 속성의 성격을 파악
속한 속성이 여러 개 존재	속한 속성이 거의 존재하지 않음
한 엔터티에 하나만 존재	한 엔터티에 여러 개 존재

 

서브타입 = 엔터티

코드 = 속성

 

3.21 Is-A 서브타입과 Part-Of 서브타입

 

이렇게 데이터를 일반화하면 부분집합은 전체 집합과 '이다'(Is-A)의 관계가 성립한다. 즉 '개인고객은 고객이다'라는 관계가 성립한다. 일반적인 서브타입은 전체 집합을 인스턴스 기준으로 묶어 집합을 만든다.

인스턴스를 기준으로 묶지 않고 요소(속성)를 기준으로 묶은 버전을 '일부'(Part-Of) 관계라고 한다. 즉 프로그램과 사용자매뉴얼은 둘 다 소프트웨어의 일부가 된다. '프로그램은 소프트웨어의 구성 요소다'와 같이 '일부'의 관계가 성립한다.

구성 요소를 서브타입으로 표현하는 방법은 엄밀히 말하면 서브타입 사용법이 아니다. 

'이다' 관계는 서브타입과 연관되고, '일부' 관계는 엔터티 수직 분할(일대일 관계)과 연관된다.

 

3.22 배타 서브타입과 중복 서브타입

배타 서브타입: 서브타입 부분집합 간에 중복이 발생하지 않는 서브타입. 즉, 서브타입 A와 B가 있다면 특정 인스턴스는 A이거나 B 둘 중 하나다.

• 배타 서브타입에서는 하나의 슈퍼타입 인스턴스는 단 하나의 서브타입과 관계(일대일 관계)가 발생한다.
• 전체 서브타입의 합은 슈퍼타입이 된다.
• 서브타입 간에 상호 배타적이기 때문에 포함관계가 없어야 한다.

중복 서브타입: 서브타입 부분집합 간에 중복이 발생하는 서브타입. 즉, 서브타입 간에 겹쳐지는 부분이 존재하는 서브타입으로, 두 서브타입 A와 B가 있다면 A에도 속하고 B에도 속하는 인스턴스가 있는 서브타입이다.

• 중복 서브타입에서는 하나의 슈퍼타입 인스턴스가 두 개 이상의 서브타입 엔터티와 관계가 존재할 수 있다.

실제로 발생하는 대부분의 서브타입은 배타 서브타입이다. 중복 서브타입은 자주 발생하지 않는다.

중복 서브타입으로 도출해야 하는데 습관적으로 배타 서브타입으로 도출하면 업무를 반영하지 못하게 되므로 유의해야 한다.

 

3.23 배타 서브타입과 이력 데이터

서브타입의 이력 데이터는 가능하면 별도의 엔터티에서 관리하는 것이 바람직하다. 서브타입 모델 대부분은 하위 엔터티가 많이 존재하기 때문에 이력 데이터를 같이 관리하는 것은 바람직하지 않다.

 

3.24 중복 서브타입에 대한 설계

중복 서브타입 모델에서 데이터를 관리하는 방법

1. 슈퍼타입 인스턴스와 서브타입 인스턴스가 일대일 대응
2. 슈퍼타입 인스턴스와 서브타입 인스턴스가 일대다 대응

3.25 중복 서브타입의 주의점

슈퍼타입과 서브타입은 상/하위 개념의 부모/자식 관계가 아니기 때문에 슈퍼타입과 전체 서브타입 관계비는 기본적으로 일대일(1:1)이다. 하지만 슈퍼타입과 전체 서브타입 관계비가 일대다(1:M)인 중복 서브타입이 존재할 수 있다.

 

'홍길동'은 고객이면서 사원일 수가 있기 때문에 이 스버타입은 중복 서브타입이다.

이를 슈퍼타입과 전체 서브타입 관계비를 일대다(1:M)로 관리하게 되면 아래와 같아진다.

 

'홍길동'은 슈퍼타입인 고객 엔터티에 한 개의 인스턴스만 존재한다. 그리고 이 인스턴스와 관계되는 서브타입 인스턴스는 개인고객 서브타입과 사원고객 서브타입에 각각 존재한다.

 

위 모델의 문제점

• 위 모델에서 고객 엔터티는 특정 실체의 사람을 관리하는 엔터티가 아니다. 즉 '홍길동'이라는 사람을 관리하는 데이터가 아니다. 슈퍼타입은 서브타입과 동일한 성격의 데이터를 관리하는데 서브타입인 개인고객과 사원고객은 실체를 의미하기보단 역할을 의미한다. 따라서 이와 동일한 성격의 데이터인 고객 엔터티도 실체를 관리하는 것이 아니라 역할을 관리하는 엔터티가 돼야 한다.
• 고객유형코드 속성을 사용하기가 까다로워진다. 전체 개인고객을 조회하려면 고객 릴레이션의 고객유형코드 속성 값이 '개인고객'이거나 '개인고객+사원고객'인 경우를 함께 조회해야 한다. 그리고 만약 다른 종류의 서브타입인 '사업자고객'이 생기면 고객유형코드가 4개 늘어난다.('사업자고객', '개인고객+사업자고객', '사원고객+사업자고객', '개인고객+사원고객+사업자고객')    → 오류의 가능성도 크지만 'OR' 구문이 반복돼 성능 비효율이 발생할 수 있다.

위 모델은 사용하지 않아야 하지만 부득이하게 사용해야 한다면, 소수의 서브타입이 존재하고 향후 서브타입이 추가되지 않을 때만 사용을 고려할 수 있다.

 

 

코드 값으로 관리하는 서브타입을 여부 속성으로 관리하는 모델

 

위 모델의 문제점

• 변화에 취약하다.
• 모델만 봐서는 서브타입 개념이 명확히 보이지 않는다.

결론: 실무에서 중복 서브타입이 존재하면 데이터를 어떻게 관리하는 것이 효율적인지부터 숙고해야 한다. 데이터를 어떻게 관리하는지에 따라 조회 방법이 달라질 수 있으며, 때에 따라서 모델 구조가 달라질 수 있으며 심하면 집합의 정의까지 달라질 수 있다. 서브타입으로 도출된 엔터티는 핵심 엔터티일 가능성이 크므로 심도 있게 고민해야 한다.

 

3.26 완전 서브타입과 불완전 서브타입

완전 서브타입: 슈퍼타입의 모든 인스턴스가 최소한 하나의 서브타입 인스턴스와 관계가 존재하는 서브타입

불완전 서브타입: 슈퍼타입에만 인스턴스가 존재하고 서브타입에는 인스턴스가 존재하지 않는 서브타입(고유 속성이 존재하지 않는 서브타입)

슈퍼타입에 인스턴스가 생성될 때 서브타입에도 인스턴스가 생성되면 완전 서브타입, 그렇지 않으면 불완전 서브타입이다.

 

3.27 서브타입과 슈퍼타입의 관계

인스턴스 제약	배타	중복
완전	EC(Exclusive-Complete) 서브타입 - 슈퍼타입의 한 인스턴스는 하나의 서브타입 인스턴스와 관계 존재 - 슈퍼타입의 모든 인스턴스는 서브타입 인스턴스와 관계가 존재	IC(Inclusive-Complete) 서브타입 - 슈퍼타입의 한 인스턴스가 두 개 이상의 서브타입 인슽언스와 관계가 존재할 수 있음 - 슈퍼타입의 모든 인스턴스는 서브타입 인스턴스와 관계가 존재
불완전	EI(Exclusive-Incomplete) 서브타입 - 슈퍼타입의 한 인스턴스는 하나의 서브타입 인스턴스와 관계 존재 - 슈퍼타입의 어떤 인스턴스는 서브타입의 인스턴스와 관계가 존재하지 않음	II(Inclusive-Incomplete) 서브타입 - 슈퍼타입의 한 인스턴스가 두 개 이상의 서브타입 인스턴스와 관계가 존재할 수 있음 - 슈퍼타입의 어떤 인스턴스는 서브타입의 인스턴스와 관계가 존재하지 않음

 

EC 서브타입

• 실무에서 대부분을 차지하는 가장 일반적인 종류의 서브타입
• 각 서브타입 엔터티의 인스턴스 개수를 합하면 슈퍼타입 엔터티의 인스턴스 개수와 일치한다.

EI 서브타입

• 슈퍼타입 엔터티의 인스턴스 개수가 많다.

IC 서브타입

• 슈퍼타입에 하나의 인스턴스가 생성될 때 서브타입에는 하나 이상의 인스턴스가 생성될 수 있으므로 서브타입 엔터티의 인스턴스 개수가 슈퍼타입 인스턴스보다 많거나 같다.

II 서브타입

• 슈퍼타입과 서브타입 간 인스턴스 개수의 상관 관계가 없다.

 

모든 종류의 서브타입에서 슈퍼타입 인스턴스를 삭제하면 관련된 서브타입의 모든 인스턴스도 삭제해야 한다.

 

3.28 서브타입의 오해 - 슈퍼타입과 서브타입은 부모 자식 관계다

서브타입 인스턴스는 슈퍼타입 인스턴스와 다른 데이터를 의미하는 것이 아니라 동일한 데이터를 의미한다. 동일한 성격의 데이터를 관리하는 엔터티이므로 부모/자식 관계의 별도 엔터티가 아니라, 하나의 엔터티를 성능 등의 이유 때문에 일대일(1:1) 관계로 분리한 것과 같은 엔터티다.

 

3.29 슈퍼타입/서브타입 논리 모델의 물리 모델 변환

슈퍼타입/서브타입 모델을 물리 모델로 변환하는 방법

1. 서브타입 별로 엔터티 분할
   • 서브타입마다 별도의 엔터티로 만드는 것
2. 슈퍼타입 엔터티 하나로 통합
   • 각 서브타입에 속하는 속성을 슈퍼타입에 포함시키고, 서브타입을 삭제해 슈퍼타입만 남긴다.
3. 슈퍼타입 엔터티와 개별 서브타입 엔터티로 분할
   • 슈퍼타입/서브타입 논리 모델 구조가 그대로 물리 모델로 변환된다. → 서브타입 개념을 가장 잘 반영한 물리 모델

타입	선택 기준
분할	- 서브타입별 업무가 서로 독립적일 때 - 서브타입별 속성이 많이 다를 때 - 서브타입별 관계가 많이 다를 때 - 모든 서브타입을 동시에 조회하는 경우가 드물 때 - 서브타입별 주 식별자가 상호 배타적이 아닐 때 - 서브타입이 업무적으로 서로 약 결합(Loosely Coupled) 관계일 때
통합	- 서브타입별 고유 속성이 적을 때 - 속성이 지속적으로 늘어날 가능성이 작을 때 - 하나의 서브타입은 속성도 많고 업무도 중요하며, 나머지 서브타입은 속성이 적고 덜 중요할 때 - 서브타입 전체를 대상으로 하는 업무가 빈번할 때 - 데이터 건수가 많지 않을 때 - 업무가 중요하지 않을 때 - 서브타입이 중복 서브타입일 때 - 서브타입이 업무적으로 서로 강 결합(Tightly Coupled) 관계일 때
혼합	- 서브타입별 공통 속성을 대상으로 하는 업무가 빈번할 때 - 통합하면 속성 개수가 너무 많아질 때 - 업무의 변화가 빈번해 속성이 자주 추가될 때 - 서브타입별 고유 속성이 많을 때 - 트랜잭션의 락을 방지하기 위해 엔터티를 분리해야 할 때 - 공통 업무와 고유 업무가 다양하게 존재할 때 - 중요 속성과 참고 속성으로 분리될 수 있을 때 - 슈퍼타입의 조회가 빈번하고 조회 범위가 넓을 때 - 서브타입이 업무적으로 서로 강 결합(Tightly Coupled) 관계일 때

 

 

 

위 모델을 앞서 말한 세 가지 방법으로 물리 모델 변환해보기

 

1. 서브타입 별로 엔터티 분할

 

장점	단점
•  엔터티의 속성이 근본적으로 구분되므로 엔터티를 명확하게 관리할 수 있다. •  대부분의 조회 요건이 개별 서브타입을 사용할 때 효율적이다. •  각 엔터티에 해당하는 업무에 대해 상호 영향을 미치지 않고(Loosely Coupled) 처리할 수 있다. 즉 정규직사원 엔터티에 속성을 추가할 때 계약직사원 엔터티에 영향을 끼치지 않는다. •  각 엔터티의 크기가 줄어든다. •  슈퍼타입과 서브타입 엔터티의 조인이 필요 없으므로 성능 면에서 유리하다. •  널 값을 갖는 속성이 줄어든다.	•  정규직사원과 계약직사원을 동시에 조회하는 요건이 있을 때(Tightly Coupled), 유니온이 발생하여 쿼리가 복잡해지고 성능 측면에서 불리해진다. •  사원유형코드 속성과 같이 서브타입을 구분하는 속성을 사용하면 처리하기 불편하다. •  시퀀스나 채번 관리 엔터티를 사용해 주 식별자 값을 생성하기 복잡하다. •  업무가 개별적으로 처리되더라도 데이터는 통합된 모습이 아니므로 DW 등의 요건에 의해 조회가 복잡해질 수 있다.  •  공통 속성이 개별 엔터티에 반복됨으로써 넓은 의미의 1정규형이 아니다.

 

 

2. 슈퍼타입 엔터티로 통합

 

장점	단점
•  슈퍼타입과 서브타입 엔터티의 조인이 발생하지 않아 조회 쿼리가 단순해지며 성능이 좋아질 때가 많다. •  엔터티 수가 감소해 관리가 용이해진다. •  복잡한 관계가 없어져 모델이 단순해지기 때문에 ERD를 관리하기 수월하다. •  전체 서브타입을 검색할 때 유니온이 발생하지 않아 성능 측면에서 효율적이다.	•  엔터티의 속성 개수가 많아져 크기가 증가한다. •  널 값이 존재하는 속성이 많아진다. •  정규직사원이나 계약직사원에 대한 업무가 추가되거나 변경되면 애플리케이션에 끼치는 영향이 커진다. •  업무 규칙을 모델에 표현하기 어렵다. •  공통 속성만을 조회하는 요건이 빈번하거나 조회 범위가 넓으면 I/O가 많아져 성능이 나빠진다. • 엔터티의 정체성이 희석될 수 있다.

 

 

3. 슈퍼타입/서브타입 개별 생성

장점	단점
•  슈퍼타입인 사원 엔터티는 한 블록에 많은 인스턴스가 저장되므로 핵심 조회 요건의 성능이 좋아질 때가 있다. •  논리 모델과 유사한 구조이기 때문에 모델에 업무 규칙이 표현되므로 모델의 가독성이 높아진다. •  추가 업무로 생기는 애플리케이션의 변경 영향을 줄일 수 있다. •  집계나 DW의 요건을 만족할 가능성이 커진다.  •  데이터 저장 공간을 가장 효율적으로 사용한다.	•  조회 요건에 따라 조인이나 조인 후의 유니온 쿼리 등이 발생해 성능 효율이 떨어질 수 있다. •  여러 엔터티로 나뉘어 엔터티 개수가 늘어나며 관리가 어려워진다. •  배타/중복/완전/불완전 서브타입의 종류에 따라 인스턴스를 발생시킬 때 혼선이 발생할 수 있다.

 

 

3-1. 슈퍼타입/서브타입 개별 생성(배타 관계)

• 배타 서브타입과 완전 서브타입을 강제로 제약할 수 있는 모델
• 장점: 모델 구조가 일종의 제약 역할을 하여 데이터를 더욱 정확하게 관리할 수 있음
• 단점: 개인고객, 법인고객 엔터티와 고객 엔터티에 대해 참조 무결성 제약을 생성할 수 없음

 

3.35 중첩 서브타입

중첩 서브타입: 서브타입 안에 다시 서브타입이 존재하는 것

• 하나 이상의 서브타입 구분자가 필요하다
• 구분자 사이에 계층 체계가 존재한다.

중첩 서브타입이 존재한다는 것은 많은 데이터를 통합했다는 것을 의미한다. 자칫 무리하게 통합할 때 발생하기도 하는데, 대상 자체가 빈번하지 않기 때문에 중첩 서브타입은 자주 발생하지 않는다.

 

3.36 서브타입 간의 관계 표현법

서브타입 간에도 관계가 존재할 수 있다. 이런 관계는 서브타입의 성격이 다를수록, 즉 엔터티를 일반화할수록 발생할 가능성이 높다.

이 모델은 성격이 다소 다른 개인고객과 사원, 부서를 통합하여 개인고객/사원고객/부서 서브타입이 생긴 모델이다. 따라서 개인고객/사원고객/부서 서브타입 사이에 관계가 발생할 수 있다. 이 관계는 다음과 같이 세 가지 방법으로 관리할 수 있다.

 

1. 슈퍼타입 엔터티에 재귀 관계 도출
2. 서브타입 엔터티 사이의 관계 도출
3. 슈퍼타입 엔터티에 별도의 관계 엔터티 도출

 

슈퍼타입 엔터티에 재귀 관계 도출

사원이 개인고객을 관리한다는 요건으로 인해 슈퍼타입에재귀 관계가 생긴 모델

 

위 모델의 고객 엔터티에 대한 릴레이션

 

만약 사원의 부서장도 관리하고, 소속 부서도 관리하는 방식으로 여러 관계를 별도로 관리한다면 아래 모델을 사용해야 한다.

 

 

위 모델은 관계가 어떤 관계인지 명확한 반면, 관계가 늘어나면 속성도 늘어나게 되는 유연하지 않은 모델이다.

 

서브타입 엔터티 사이의 관계 도출

아래는 사원이 개인고객을 관리한다는 요건을 서브타입 엔터티 간의 관계로 관리하는 모델이다.

 

 

불완전 서브타입일 때는 서브타입 엔터티가 존재하지 않기 때문에 이 방법을 사용할 수 없다. 완전 서브타입일 때만 사용할 수 있으며, 여러 관계를 관리하려면 관계 속성이 계속 늘어나기 때문에 유연하지 않은 모델이다. 반면에 업무 규칙을 가장 구체적으로 관리할 수 있는 모델이기도 하다. 관계 속성을 바로 인지할 수 있으므로 관계를 명확히 관리할 수 있다.

 

슈퍼타입 엔터티에 별도의 관계 엔터티 도출

관계 엔터티를 사용하는 모델

 

위 모델에 대한 릴레이션

 

엔터티를 일반화해서 통합한 모델일 경우에는 서브타입 사이의 관계가 지속적으로 늘어날 수 있으므로 관계의 확장성까지 고려한다면 위 모델과 같이 관계 엔터티를 사용하는 것이 바람직하다.

 

3.37 잘못된 서브타입

만약 개인고객과 법인고객을 관리하고 개인고객의 가족 데이터도 관리하며, 개인고객의 가족은 고객으로 등록하지 않는다는 요건을 반영한 모델을 설계하고자 할 때 아래 모델은 잘못 설계한 모델이다.

 

개인고객의 가족은 고객에 통합되지 않는다는 요건에 반해 통합한 것으로 잘못 설계한 모델이다. 이와 같이 서브타입을 잘못 설계한 모델은 개념 모델에서 더 자주 볼 수 있다. 이는 서브타입을 이해하지 못해서이기도 하지만, 개념 모델이 물리적인 모델과는 무관하며 개념적으로만 존재하는 모델이라고 인식하는 데서 발생하기도 한다.

 

위 요건을 제대로 설계한 모델은 아래와 같다.

개인고객의 가족은 고객에 통합되지 않기 때문에 고유한 고객번호가 없다. 또한 가족은 여러 명일 수 있어 개인고객 엔터티와 당연히 일대다(1:M) 관계다. 

 

3.38 범주에 대해서

데이터 통합은 관계가 아닌 속성의 유사성, 즉 본질적 특성에 기반해야 한다.
외부 환경(프로세스, 조직, 화면 등)이 아니라 엔터티 자체의 속성이 통합 기준이 되어야 한다.
본질 중심의 범주화 사고는 모델링을 논리적이고 견고하게 만드는 핵심 기법이다.





Ask ChatGPT