Posts Tags Categories

Contents

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

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

 included in IT/DB/Architecture
   6003 words   12 minutes 
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. 데이터 통합에 대한 서설

3.2. 일반화와 상세화

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

3.4. 통합이 대세인가?

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

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

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

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

3.9. 주제 영역 설계 방법

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

3.11. 데이터 통합과 정규화

3.12. 통합과 합체

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

3.14. 서브타입에 대한 서설

3.15. 서브타입과 부분집합

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

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

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

3.19. 서브타입과 코드

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.34. 중첩 서브타입

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

3.36. 잘못된 서브타입

3.37. 범주에 대해서

Updated on 2023-01-15
CC BY-NC-ND 4.0
 Study-Group-Offline, DB/Modeling
Back | Home