관계형 데이터 모델링 노트 3장

'데이터모델링 도서인 `관계형 데이터 모델링 노트 개정판` 책의 `3장 데이터 통합과 서브타입 이야기` 요약 및 정리

정민호정민호
Table of Contents

1. 엔터티 이야기

2. 정규화 이야기

3. 데이터 통합과 서브타입 이야기

요약

  1. 데이터 통합화(Generalization)

    1. 데이터 통합이란?

      • 유사한 성격의 데이터를 합치는 것으로 데이터라는 대상을 논리적, 물리적으로 일반화 하는것을 말함

      • 데이터 통합은 정규화를 기반으로 이뤄져야하고 의미가 있는선까지 일반화 해야하며, 성능 측면도 검토해야함

      • 엔터티를 일반화하거나 상세화하면 슈퍼타입(Supertype)과 서브타입(Subtype)이 생김

    2. 통합시 주의할 점

      1. 성능

        • 데이터를 통합하면 A집합과 B집합의 인스턴스 개수가 합쳐지기 때문에 데이터가 늘어나며, 인서트가 많이 발생하는 엔터티에 다른 엔터티를 통합하는것은 바람직하지 않음

      2. 정체성 희성

        • 지나치게 일반화 하면 데이터 정체성이 희석되므로 통합에 실익이 있는지 고려해야하며, 업무적인 일대일 관계는 분리하는 것이 바람직

        • 엔터티는 실체, 행위, 기준, 가공 엔터티로 분류할 수 있으며, 다른 분류의 엔터티 간에 통합이 발생하면 데이터의 정체성이 희석됨

      3. 무결성 저하

        • 통합해서 같이 사용하게 됨으로써 제약 조건을 생성하지 못하거나, 도메인을 정확히 설정하지 못할 수 있음

        • 주로 Not Null 제약이나 참조무결성(IR) 제약을 생성하지 못함

        • 데이터를 일반화 할 수록 무결성이 떨어짐

      4. 마이그레이션 가능 여부

        • 현실적인 문제로, 다른 모든 조건을 만족하더라도 마이그레이션에 문제가 생기면 통합 모델을 사용할 수 없음

    3. 통합시 고려사항

      1. 요약

        • 데이터의 본질(설격)이 유사할 때

        • 식별자가 동일하면서 유사한 속성이 존재할 때

        • 식별자는 다르지만, 기초 속성이 유사할 때

      2. 데이터의 성격이 유사할 때

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

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

      5. 역할을 관리할 때

      6. 대칭적인 업무일 때

      7. 계층 관계가 존재할 때

      8. 공통 속성이 존재할 때

      9. 배타 관계가 발생할 때

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

      11. 비정규화를 수행할 때

      12. 일대일 관계일 때

      13. 유사한 종류의 데이터를 하나의 기준으로 만들 때

      14. 업무가 변경될 가능성이 많을 때

  2. 서브타입(Subtypes)

    1. 서브타입이란

      • 보통 서브타입이란 용어에는 슈퍼타입이 포함되어 있어서, 서브타입이라고만 표현해도 포괄적으로 슈퍼타입까지 포함됨

      • 서브타입이란 서브타입 엔터티(Subtypes Entity)를 말하며, 엔터티를 통합하거나 상세화한 결과가 서브타입으로 이는 모델의 확장성을 좋게함

      • 공통 속성은 슈퍼타입 엔터티에 속하고 고유 속성은 서브타입 엔터티에 속하며 고유 속성이 없는 서브타입(불완전(Incomplete) 서브타입)이 존재 할 수 있음

      • 슈터타입과 서브 타입은 부모·자식 관계가 아니라 동등한 관계로 슈퍼타입과 서브타입을 하나의 인스턴스로 인식해야함

      • 서브타입 엔터티 간의 관계는 일반적으로 상호 배타적(Exclusive)이지만, 간혹 포함적(Inclusive)일 때도 있음

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

      • 서브타입으로 도출된 엔터티는 핵심 엔터티일 가능성이 크므로 모델링시 심도있게 고민

    2. 서브타입 도출 방법

      1. 유사한 성격의 엔터티를 모아서 슈퍼타입을 생성하는 방법(Roll-Up Supertypes)

        • 두개 이상의 유사한 엔터티에서 공통 속성을 도출하는 방법이며, 엔터티 통합(일반화)라고 함

      2. 복잡한 엔터티를 분해해서 서브타입을 생성하는 방법(Break-Down Subtypes)

        • 복잡한 하나의 엔터티에서 유사한 속성끼리 분류하는 방법이며, 엔터티 상세화 또는 논리화(Logicalization)라고 함

        • 분류할 때 주요 속성부터 분석

    3. 서브타입과 코드의 차이점

      • 전체 집합의 성격을 파악하는 게 '서브타입’이고, 특정 속성의 성격을 파악하는게 '코드'

서브타입 코드

전체 집합에 대한 부분집합을 표현

특정 속성의 구분을 표현

전체 집합의 성격을 파악

한 속성의 성격을 파악

속한 속성이 여러 개 존재

속한 속성이 거의 존재하지 않음

한 엔터티에 하나만 존재

한 엔터티에 여러 개 존재

  1. 서브타입의 종류(Is-A, Part-Of)

    1. Is-A 서브타입

      • 인스턴스를 기준으로 묶으며, 서브타입과 연관

      • 데이터를 일반화 하면 부분집합은 전체 집합과 '이다'(Is-A) 관계가 성립하며, 역으로 '전체 집합 중에 부분집합이 존재한다’는 관계도 성립

      • 예) '개인고객(부분집합)은 고객(전체 집합)이다’는 관계가 성립하며, 역으로 '고객(전체 집합) 중에 개인고객(부분집합)이 존재한다’는 관계도 성립

    2. Part-Of 서브타입

      • 인스턴스를 기준으로 묶지 않으며, 수직분할(일대일 관계)과 연관

      • 요소(속성)를 기준으로 묶을 수 있는데, 이 때 '일부'(Part-Of) 관계가 성립

      • 예) '프로그램(부분집합)과 사용자매뉴얼(부분집합)은 소프트웨어(전체 집합)의 구성요소이다.'는 관계가 성립

      • 예) '프로그램은 소프트웨어이다', '사용자매뉴얼은 소프트웨어이다' 와 같이 '이다'(Is-A)관계가 성립하지 못함

      • 일대일(1:1) 관계를 서브타입으로 잘못 파악한 것이 아닌지 의심해 볼 것

  2. 서브타입 구분(배타, 중복, 완전, 불완전)

    1. 배타 서브타입(Exclusive Subtype 또는 Disjoint Subtype)

      • 배타 서브타입은 서브타입 부분집합 간에 중복이 발생하지 않는 서브타입

      • 하나의 슈퍼타입 인스턴스는 단 하나의 서브타입과 관계(일대일 관계)가 발생하며, 전체 서브타입의 합은 슈퍼타입이 됨

      • 상호 배타적이기 때문에 포함관계가 없어야함

    2. 중복 서브타입(Inclusive Subtype 또는 Overlapping Subtype)

      • 중복 서브타입은 서브타입 부분집합 간에 중복이 발생하는 서브타입

      • 서브타입 A와 B가 있을 때 A에도 속하고 B에도 속하는 인스턴스가 있는 서브타입

    3. 중복 서브타입 관리 방법

      1. 슈퍼타입 인스턴스와 서브타입 인스턴스가 일대일(1:1) 대응(논리적 관계비)

        • 서브타입 인스턴스의 개수를 합하면 슈퍼타입 인스턴스의 개수와 동일

      2. 슈퍼타입 인스턴스와 서브타입 인스턴스가 일대다(1:M) 대응(논리적 관계비)

        • 한 개의 슈퍼타입 인스턴스가 두 개의 서브타입 인스턴스와 대응

        • 실체(사람)와 역할(고객, 개인고객, 사원)을 관리하는 엔터티를 구분하여 설계하는 방법을 고려해 볼 것

    4. 배타 서브타입과 중복 서브타입 판단 기준

      • 배타 서브타입과 중복 서브타입을 판단하는 기준은 특정 시점에 동시에 발생할 수 있는지 여부

      • 배타 서브타입은 특정 시점에 중복이 발생하지 않으며, 중복 서브타입은 특정 시점에 중복이 발생할 수 있음

      • 이력 데이터의 경우 현재 시점을 기준으로 서브타입 양쪽에 데이터가 있는지를 따지면 배타 서브타입인지 중복 서브타입인지 알 수 있음

    5. 완전 서브타입(Complete Subtype)

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

      • 일반적이고 대부분을 차지하며, 서브타입에 인스턴스가 생성될 때 서브타입에도 인스턴스가 생성되면 완전 서브타입

    6. 불완전 서브타입(Incomplete Subtype)

      • 불완전 서브타입은 슈퍼타입에만 인스턴스가 존재하고 서브타입에는 인스턴스가 존재하지 않는 서브타입

      • 서브타입에 인스턴스가 생성될 때 서브타입에도 인스턴스가 생성되지 않으면 불완전 서브타입

    7. 서브타입 구분(배타, 중복, 완전, 불완전)별 특성

인스턴스 제약 배타 중복

완전

EC(Exclusive-Complete) 서브타입

IC(Inclusive-Complete) 서브타입

- 슈퍼타입의 한 인스턴스는 하나의 서브타입 인스턴스와 관계 존재

- 슈퍼타입의 한 인스턴스가 두 개 이상의 서브타입 인스턴스와 관계가 존재할 수 있음

- 슈퍼타입의 모든 인스턴스는 서브타입 인스턴스와 관계가 존재

- 슈퍼타입의 모든 인스턴스는 서브타입 인스턴스와 관계가 존재

불완전

EI(Exclusive-Incomplete) 서브타입

II(Inclusive-Incomplete) 서브타입

- 슈퍼타입의 한 인스턴스는 하나의 서브타입 인스턴스와 관계 존재

- 슈퍼타입의 한 인스턴스가 두 개 이상의 서브타입 인스턴스와 관계가 존재할 수 있음

- 슈퍼타입의 어떤 인스턴스는 서브타입의 인스턴스와 관계가 존재하지 않음

- 슈퍼타입의 어떤 인스턴스는 서브타입의 인스턴스와 관계가 존재하지 않음

  1. 슈퍼타입·서브타입 논리 모델의 물리 모델 변환 방법

    1. 물리 모델로 변환시 고려 사항

      • 성능(논리적인 판단, 조회 범위 및 횟수)

      • 관리적인 측면

      • 사용 결합도

      • 통합 관점

    2. 서브타입별로 엔터티 분할(타입1-분할)

      • 서브타입마다 별도의 엔터티로 만드는 방법

      • 서브타입별로 엔터티를 각자 생성한 후에, 슈퍼타입의 주 식별자를 포함한 속성 전부를 양쪽 엔터티에 추가

      • 주 식별자의 값이 중복되면 안되므로 이를 체크하기 위한 로직 또는 엔터티가 필요함

    3. 슈퍼타입 엔터티 하나로 통합(타입2-통합)

      • 슈퍼타입에 서브타입을 통합하는 방법

      • 각 서브타입에 속하는 속성을 슈퍼타입에 포함시키고, 서브타입을 삭제해 슈퍼타입만 남김

      • 각 서브타입을 슈퍼타입으로 포함시킴으로써 서브타인간 식별할 수 있는 속성이 추가되어야하고, 속성의 널(Null) 값이 많이 발생되므로 이를 체크하기 위한 Check 제약이 필요함

    4. 슈퍼타입 엔터티와 개별 서브타입 엔터티로 분할(타입3-혼합)

      • 슈퍼타입과 개별 서브타입을 별도의 엔터티로 분할하는 방법

      • 슈퍼타입·서브타입 논리 모델 구조가 그대로 물리 모델로 변환되며, 이 때 두가지 방법이 있음

        1. 슈퍼타입과 서브타입의 관계가 일대일(1:1) 관계

        2. 슈퍼타입과 서브타입의 관계가 배타(Arc) 관계

      • 모델 구조적으로도 직관적이라 실무에서 주로 사용되는 모델이

      • 하지만 서브타입은 서로 배타적이어야하며(배타 서브타입), 모든 서브타입의 합집합이 전체 집합이 돼야 한다(완전 서브타입)는 서브타입의 일반적인 정의를 표현한 최적을 모델은 아님

      • 이 모델에서는 서브타입이 상위 엔터티의 성격을 지니며, 슈퍼타입의 주 식별자 값을 체크하기 위해 트리거가 필요함

      • 장점으로 모델 구조가 일종의 제약 역할을 하여 데이터를 더욱 정확하게 관리한다는 점

      • 단점으로 참조 무결성 제약을 생성할 수 없다는 점과 주 식별자 값을 생성하기 어려워 지고, 채번하기 복잡하다는 점

    5. 서브타입 모델을 물리 모델로 변활할 때의 선택 기준

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

        1. 선택기준

          • 서브타입별 업무가 서로 독립적일 때

          • 서브타입별 속성/관계가 많이 다를 때

          • 서브타입별 주 식별자가 상호 배타적이 아닐 때

          • 모든 서브타입을 동시에 조회하는 경우가 드물 때

          • 서브타입이 업무적으로 서로 약 결합(Loosely Coupled) 관계일 때

        2. 장점

          • 엔터티의 속성이 근본적으로 구분되므로 엔터티를 명확하게 관리할 수 있음

          • 대부분의 조회 요건이 개별 서브타입을 사용할 때 효율적

          • 각 엔터티에 해당하는 업무에 대해 상호 영향을 미치지 않고(Loosely Coupled) 처리할 수 있음

          • 즉 정규직사원 엔터티에 속성을 추가할 때 계약직사원 엔터티에 영향을 끼치지 않음

          • 각 엔터티의 크기가 줄어듦

          • 슈퍼타입과 서브타입 엔터티의 조인이 필요 없으므로 성능 면에서 유리

          • 널(Null) 값을 갖는 속성이 줄어듦

        3. 단점

          • 정규직 사원과 계약직 사원을 동시에 조회하는 요건이 있을 때(강 결합; Tightly Coupled)유니온이 발생하여 쿼리가 복잡해지고 성능 측면에서 불리해짐

          • 사원유형코드 속성과 같이 서브타입을 구분하는 속성을 사용하면 처리하기 불편함

          • 시퀀스나 채번 관리 엔터티를 사용해 주 식별자 값을 생성하기 복잡함

          • 업무가 개별적으로 처리되더라도 데이터는 통합된 모습이 아니므로 DW(Data Warehouse) 등의 요건에 의해 조회가 복잡해질 수 있음

          • 공통 속성이 개별 엔터티에 반복됨으로써 넓은 의미의 1정규형이 아님

      2. 슈퍼타입 엔터티 하나로 통합(타입2-통합)

        1. 선택기준

          • 서브타입별 고유 속성이 적을 때

          • 속성이 지속적으로 늘어날 가능성이 작을 때

          • 하나의 서브타입은 속성도 많고 업무도 중요하며, 나머지 서브타입은 속성도 적고 덜 중요할 때

          • 서브타입 전체를 대상으로 하는 업무가 빈번할 때

          • 데이터 건수가 많지 않을 때

          • 업무가 중요하지 않을 때

          • 서브타입의 중복 서브타입일 때

          • 서브타입이 업무적으로 서로 강 결합(Tightly Coupled) 관계일 때

        2. 장점

          • 슈퍼타입과 서브타입 엔터티의 조인이 발생하지 않아 조회 쿼리가 단순해지며 성능이 좋아질 때가 많음

          • 엔터티 수가 감소해 관리가 용이해짐

          • 복잡한 관계가 없어져 모델이 단순해지기 때문에 ERD를 관리하기 수월함

          • 전체 서브타입을 검색할 때 유니온이 발생하지 않아 성능 측면에서 효율적

        3. 단점

          • 엔터티의 속성 개수가 많아져 크기가 증가함

          • 널(Null) 값이 존재하는 속성이 많아짐

          • 업무가 추가되거나 변경되면 애플리케이션에 끼치는 영향이 커짐

          • 업무 규칙을 모델에 표현하기 어려움

          • 공통 속성만을 조회하는 요건이 빈번하거나 조회 범위가 넓으면 I/O가 많아져 성능이 나빠짐

          • 엔터티의 정체성이 희성될 수 있음

      3. 슈퍼타입 엔터티와 개별 서브타입 엔터티로 분할(타입3-혼합)

        1. 선택기준

          업무 연관성이 있을 때

          • 서브타입이 업무적으로 서로 강 결합(Tightly Coupled) 관계일 때

          주요 엔터티일 때

          • 업무의 변화가 빈번해 속성이 자주 추가될 때

          • 중요 속성과 참고 속성으로 분리될 수 있을 때

          공통 속성을 주로 사용할 때

          • 서브타입별 공통 속성을 대상으로 하는 업무가 빈번할 때

          • 슈퍼타입의 조회가 빈번하고 조회 범위가 넓을 때

          고유 속성이 많을 때

          • 서브타입별 고유 속성이 많을 때

          • 공통 업무와 고유 업무가 다양하게 존재할 때

          통합하면 속성 개수가 많아질 때

          • 통합(타입2)하면 속성 개수가 너무 많아질 때

          트랜잭션을 분리할 때

          • 트랜잭션의 락을 방지하기 위해 엔터티를 분리해야 할 때

        2. 장점

          • 슈퍼타입 엔터티의 한 블록에 많은 인스턴스가 저장되므로 핵심 조회 요건의 성능이 좋아질 때가 많음

          • 논리 모델과 유사한 구조이기 때문에 모델에 업무 규칙이 표현되므로 모델의 가독성이 높아짐

          • 추가 업무로 생기는 애플리케이션의 변경 영향을 줄일 수 있음

          • 집계나 DW의 요건을 만족할 가능성이 커짐(전사 차원에서 고려)

          • 데이터 저장 공간을 가장 효율적으로 사용

        3. 단점

          • 조회 요건에 따라 조인이나 조인 후의 유니온 쿼리 등이 발생해 성능 효율이 떨어질 수 있음

          • 여러 엔터티로 나뉘어 엔터티 개수가 늘어나며 관리가 어려워짐

          • 배타, 중복, 완전, 불완전 서브타입의 종류에 따라 인스턴스를 발생시킬 때 혼성이 발생할 수 있음

  2. 중첩 서브타입(Nested Subtype)

    • 중첩 서브타입은 서브타입 안에 다시 서브타입이 존재할 때 중첩 서브타입이라 하며, 물리적으로 구현되는 일은 적음

    • 중첩 서브타입에는 중첩된 서브타입의 수 만큼 구분자가 필요함

      1. 서브타입 간의 관계 관리 방법

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

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

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

    • 요건을 서브타입 엔터티 간의 관계로 관리하는 모델로 완전 서브타입 일 때만 사용할 수 있음

    • 업무 규칙을 가장 구체적으로 관리할 수 있는 모델이지만, 여러 관계를 관리하려면 관계 속성이 계속 늘어나기 때문에 유연하지 않은 모델

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

    • 다대다(M:M) 재귀 관계를 관리하는 BOM(Bill Of Materials) 모델

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

  • o

3.1.1. d

  • d

3.2. 일반화와 상세화

  • o

3.2.1. d

  • d

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

  • o

3.3.1. d

  • d

3.4. 통합이 대세인가?

  • o

3.4.1. d

  • d

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

  • o

3.5.1. d

  • d

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

  • o

3.6.1. d

  • d

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

  • o

3.7.1. d

  • d

3.8. 데이터 주제 영역이란?

  • o

3.8.1. d

  • d

3.9. 주제 영역 설계 방법

  • o

3.9.1. d

  • d

3.10. 데이터 오너십과 모델 오너십과데이터 통합의 시발점

  • o

3.10.1. d

  • d

3.11. 데이터 통합과 정규화

  • o

3.11.1. d

  • d

3.12. 통합과 합체

  • o

3.12.1. d

  • d

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

  • o

3.13.1. d

  • d

3.14. 서브타입에 대한 서설

  • o

3.14.1. d

  • d

3.15. 서브타입과 부분집합

  • o

3.15.1. d

  • d

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

  • o

3.16.1. d

  • d

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

  • o

3.17.1. d

  • d

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

  • o

3.18.1. d

  • d

3.19. 서브타입과 코드

  • o

3.19.1. d

  • d

3.20. Is-A 서브타입과 Part-Of 서브타입

  • o

3.20.1. d

  • d

3.21. 배타 서브타입과 중복 서브타입

  • o

3.21.1. d

  • d

3.22. 배타 서브타입과 이력 데이터

  • o

3.22.1. d

  • d

3.23. 중복 서브타입에 대한 설계

  • o

3.23.1. d

  • d

3.24. 중복 서브타입의 주의점

  • o

3.24.1. d

  • d

3.25. 완전 서브타입과 불완전 서브타입

  • o

3.25.1. d

  • d

3.26. 서브타입과 슈퍼타입의 관계

  • o

3.26.1. d

  • d

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

  • o

3.27.1. d

  • d

3.28. 슈퍼타입·서브타입 논리 모델의 물리 모델 변환

  • o

3.28.1. d

  • d

3.29. 서브타입 모델의 물리 모델 변환 - 서브타입별로 엔터티 분할

  • o

3.29.1. d

  • d

3.30. 서브타입 모델의 물리 모델 변환 - 슈퍼타입 엔터티로 통합

  • o

3.30.1. d

  • d

3.31. 서브타입 모델의 물리 모델 변환 - 슈퍼타입·서브타입 개별 생성

  • o

3.31.1. d

  • d

3.32. 서브타입 모델의 물리 모델 변환 - 슈퍼타입·서브타입 개별 생성(배타 관계)

  • o

3.32.1. d

  • d

3.33. ERWin 툴의 서브타입 표기법

  • o

3.33.1. d

  • d

3.34. 중첩 서브타입

  • o

3.34.1. d

  • d

3.35. 서브타입 간의 관계 표현법

  • o

3.35.1. d

  • d

3.36. 잘못된 서브타입

  • o

3.36.1. d

  • d

3.37. 범주에 대해서

  • o

3.37.1. d

  • d