관계형 데이터 모델링 노트 - 03 데이터 통합과 서브타입 이야기

• 데이터 통합에 대한 사설
  • 데이터의 본질을 파악하여 분해하는 첫 번째 단계가 정규화며, 분해된 데이터를 묶는 마지막 단계가 통합화다.
  • 통합하기 위해서는 개별 데이터의 성격이 명확해야 한다.
  • 데이터 통합은 이론적이지 않기 때문에 개개인의 능력 차이가 큰 영역이다.
  • 통합하려는 데이터는 보통 핵심 데이터이며, 통합의 의미가 있는 선까지 일반화해야 한다.
• 일반화와 상세화 
  • 일반화
    • 유사한 것을 묶는 것을 일반화라고 하며, 기준을 어떻게 정하냐에 따라서 많은 방법으로 일반화할 수 있다.
    • 상향식 방법
  • 상세화
    • 뭉뚱그린 개념에서 구체적인 개념으로 만드는 것이다.
    • 하양식 방법
  • 엔터티를 일반화나 상세화하면 슈퍼타입과 서브타입이 생긴다.
• 데이터 통합과 엔터티 통합
  • 데이터 통합이란 데이터라는 대상을 물리적/논리적으로 일반화하는 것이다.
  • 엔터티 통합은 리버스 모델링에서 엔터티가 설계된 상태에서 두 엔터티를 통합하는 것이다. 보통 물리적인 개념에 한정되어 있다.
• 통합이 대세인가
  • 성능
    • 데이터 통합을 하여 성능에 문제가 생길 가능성이 있다면 다시 생각해 보아야 한다.
  • 정체성 희석
    • 지나치게 일반화하면 데이터의 정체성이 희석된다.
    • 데이터의 정의를 제대로 하고, 즉 정규화를 수행한 뒤, 통합이 필요하다면 통합해야 한다.
    • 엔터티는 다양한 기준에 의해 분류되는데 다른 분류의 엔터티 간에 통합이 발생하면 데이터의 정체성이 희석된다.
  • 무결성 저하
    • 통합해서 같이 사용하게 됨으로써 제약 조건을 생성하지 못하거나, 도메인을 정확히 설정하지 못할 수 있다.
    • 속성의 데이터 무결성이 다소 저하되는 단점이 있지만 데이터가 통합된 것의 장점이 훨씬 크다.
  • 마이그레이션 가능 여부
    • 마이그레이션에 시간이 오래 걸려 마감 시점까지 못 맞출 수도 있기 때문에 문제가 없는지 검토해야 한다.
• 어떤 경우에 통합을 고려하는가
  • 데이터의 성격이 유사할 때
    • 핵심적인 실체를 관리하는 데이터 중에서 데이터의 본질이 유사한 경우가 많다.
    • 데이터의 성격은 유사한데 업무에서 같이 사용하지 않을 수도 있고 서로 다른 업무에서 각자 엔터티를 사용한다는 이유로 데이터를 통합하지 않는 경우도 있다. 하지만 가장 먼저 고려해야 할 것은 데이터의 본질로서 데이터의 성격이 같다면 가능한 통합 한다.
  • 엔터티의 기초 속성이 유사할 때
    • 엔터티에서 관리하는 데이터의 본질은 속성으로 나타내며 속성이 유사하면 본질이 유사할 가능성이 높으며 더욱이 기초 속성이 유사하면 통합을 고려할 수 있다.
  • 데이터가 조회 등에 같이 사용될 때
    • 데이터를 같은 방법으로 사용한다면 유사한 데이터일 가능성이 높다.
  • 역할을 관리할 때
    • 역할을 관리하는 엔터티는 대체로 통합하는 것이 좋다.
  • 대칭적인 업무일 때
    • 업무 성격은 대칭적이지만 데이터 성격은 유사하다면 데이터 통합을 고려할 수 있다.
  • 계층 관계가 존재할 때
    • 엔터티 통합은 수평적인 관계의 엔터티가 통합돼 서브타입이 발생하지만, 계층 관계의 엔터티 통합은 수직적 통합으로 재귀 관계가 발생한다.
  • 공통 속성이 존재할 때
    • 공통 속성이 별도의 데이터 성격을 지닌다면 그 속성만을 분리해서 통합을 고려할 만하다.
    • Clob, Blob과 같은 특수 데이터 타입은 별도의 엔터티에서 통합 관리하는 것이 성능/관리 측면에서 효율적이다.
    • 통합 엔터티가 자식 엔터티가 되면 부모 엔터티와 배타 관계가 발생해서 변화에 매우 취약한 모델이 되기 때문에 원천 엔터티에 관계 속성으로 관리하는 것이 유연하다.
  • 배타 관계가 발생할 때
    
    • 배타 관계는 모델의 구조를 복잡하게 만들고, 복잡한 조인이 발생해 바람직하지 않은 관계지만 무조건 통합해서는 안된다. 특히 식별자가 다른 배타 관계일 때 통합은 주의해야 한다.
  • 집계 엔터티의 집계 대상이 같을 때
    • 집계 엔터티는 집계하려는 대상(데이터 성격)과 집계하려는 내용(집계 속성), 집계하려는 기준을 고려하여 통합을 검토해야 한다.
    • 집계 엔터티를 설계할 때, 집계하려는 대상이 집계 기준이 유사하거나 포함 관계가 있다면 통합을 검토해야 한다. 
    • 집계하려는 기준이 다른 성격이지만, 집계하려는 대상과 내용이 같다면 최소한 통합을 고려해 보자. 물론 집계 기준이 상세해져서 인스턴스가 더욱 많이 발생할 수도 있다.
  • 비정규화를 수행할 때
    • 비즈니스 요건에 따라 정규형 모델에 성능 문제가 발생하면 엔터티를 통합할 수 있다.
  • 일대일 관계일 때
    • 1:1 관계를 통합하는 것은 엔터티 합체이다.
    • 두 엔터티의 성격이 같은지와 관계비가 불변인지를 주의해야 한다.
  • 유사한 종류의 데이터를 하나의 기준으로 만들 때
    • 기준 엔터티를 제대로 통합해서 사용하면 기준이 명확해지기 때문에 업무의 혼선도 줄어들고, 데이터 무결성이 좋아지기 때문에 품질도 향상된다.
  • 업무가 변경될 가능성이 많을 때
    • 데이터를 일반화시킬수록 업무 변경에 유연한 모델이 된다.
  • 데이터의 본질이 유사하거나 식별자가 동일하면서 유사한 속성이 존재하거나 식별자는 다르지만 기초 속성이 유사하다면 통합을 구려해 보는 것이 좋다.
• 통합을 고려하지 않아도 되는 경우
  • 아래의 조건을 모두 만족하면 통합을 고려하지 않아도 된다.
    • 정보계 시스템을 포함하여 엔터티가 같이 조회되지 않는다면 통합을 고려하지 않을 수 있다. 같이 조회된다는 것은 Union 구문이 사용된다는 뜻이며, 반대로 Union 구분이 사용된다면 통합을 고려해야 한다.
    • 유사 종류의 엔터티가 향후에도 늘어나지 않을 때다. 데이터가 상호 배타적이며, 그 합이 전체이기 때문에 통합이 필요 없다.
    • 유사한 하위 엔터티가 없을 때도 통합을 고려하지 않을 수 있다.
• 데이터 통합이 어려운 또 다른 이유
  • 조직이 원인이 돼서 데이터가 통합되지 않은 경우가 빈번하다.
  • 다른 업무에 대해서 알지 못하거나 알아도 업무가 늘어난다면 모른 척 피하게 되기 때문에 통합이 어렵다.
  • 프로젝트가 커질수록 강력하고 추진력 있는 전사적인 데이터 관점에서 엔터티 통합 작업이 필요하다.
• 데이터 주제 영역이란
  • 주제 영역은 데이터 아키텍처의 최상위 단계로, 비즈니스의 목표를 달성하는 데 필요한 데이터 그룹을 의미한다.
  •  주제 영역을 구축하는 목적은 기업의 정보 체계 구조를 한눈에 파악하고 관리하기 위함이다.
  • 주제 영역별로 모델링을 수행하면 유연한 데이터 구조가 될 수 있다.
  • 주제 영역을 활영하려면 데이터 성격에 맞는 주제 영역을 도출해야 하며 기업의 조직 구조가 주제 영역과 유사해야 하지만, 현실적으로 기업의 조직 구조는 주제 영역과 무관하며 업무 영역에 의해 주제 영역이 정해진다.
  • 데이터 주제 영역을 구축하는 것 자체가가 어렵고 ISP나 EA프로젝트에서도 보통 원론적인 수준으로 구축되거나 일부 방법론에서 제시하는 일반적인 주제 영역을 그대로 사용하는 경우가 많다
  • 데이터 주제 영역이 제대로 구축되더라도 데이터 모델과 무관하면 효율이 반감된다.
• 주제 영역 설계 방법
  • 주제 영역을 설계하기 위해서는 기본적으로 모든 엔터티를 파악하고 정의하면서 유사한 엔터티를 묶는 일반화 과정을 거치면서 주제 영역을 설계한다.
  • 실체 주제 영역
    • 사람과 사물을 의미하는 데이터로 이루어진 주제 영역
    • 업무를 수행하는 주체와 대상, 자원 등과 관련된 데이터
  • 행위 주제 영역
    • 여러 가지 행위를 나타내는 데이터로 이루어진 주제 영역
    • 계약, 주문, 결제 등과 같은 주제 영역
    • 모델러에 따라 모델이 달라질 수 있음
  • 기준/가공 영역
    • 주제 영역은 원천 데이터만을 대상으로 설계하지만, 가공 데이터가 많은 부분을 차지하는 업무에서는 별도의 주제 영역으로 설계할 수 있다.
    • 실체/행위/기준/가공 주제 영역에는 하위 개념인 서브 주제 영역이 존재하는데 관리를 위해 서브 주제 영역을 포함해서 주제 영역 체계는 2~3단계가 적절하다.
  • 주제 영역을 설계할 때는 가능한 각 주제 영역의 엔터티 숫자가 균일하도록 하는 것이 좋다.
  • 중복되거나 유사한 주제 영역이 있어서는 안 되며, 업무 영역이나 조직 체계를 그대로 따라도 안 된다.
• 데이터 오너십과 모델 오너십
  • 데이터 오너십은 데이터에 대한 접근을 허용할지와 어떤 부서나 사람에게 접근을 허용할지 등의 권한 관리에 대한 것이다.
  • 모델 오너십은 엔터티가 어떤 주제 영역의 모델에 속하는지를 의미한다.
  • 업무(개발) 오너십은 애플리케이션이 속하는 영역(화면)을 의미한다.
  • 엔터티의 기초 속성을 기준으로 모델 오너십을 정할 필요가 있다. 기초 속성은 엔터티의 본직적인 성격을 나타내는 핵심적인 속성이다.
• 데이터 통합의 시발점
  • 데이터는 기업 전체의 공동 자산이라는 인식에서부터 시작된다. 특수한 데이터를 제외하고 어떤 데이터도 특정 팀이나 특정인에게 소속돼서는 안 된다.
• 데이터 통합과 정규화
  • 데이터 통합은 동질성을 가진 데이터를 합치는 것으로 동질성을 가진 데이터라는 판단을 하려면 데이터 성격을 규정하는 정규화를 끝낸 다음에야 엔터티를 통합할 수 있다.
  • 데이터 통합은 엔터티 정의에 종속된 개념이다. 엔터티를 어떻게 정의하느냐에 따라 데이터 통합의 기준이 달라진다.
  • 데이터 통합은 데이터뿐만 아니라 업무도 일반화하여 설계해야 확장성이 좋은 유연한 모델이 된다.
• 통합과 합체
  • 통합은 인스턴스를 통합하는 것이다.
    
    • 두 엔터티를 통합하면 슈퍼타입과 서브타입으로 나뉜다.
    • 인스턴스와 속성이 늘어난다.
  • 합체는 속성을 합치는  것이다.
    • 두 엔터티를 합치면 인스턴스가 늘어나지 않는다.
    • 속성이 늘어난다.
• 주 식별자가 다른 엔터티의 통합
  • 주 식별자 속성의 개수가 같을 때
    • A 주식별자와 B 주식별자를 통합하여 배타 속성을 만들고, 이 속성은 A 주식별자 값이나 B 주식별값 중 하나가 사용된다. 이를 구분하기 위해 구분코드 속성을 추가한다. 구분코드 속성을 PK에 포함하지 않는 게 좋다. A와 B의 길이가 다르다면 재일 긴 쪽을 선택해야 한다.
    • 인조 식별자를 사용하고 A 주식별자와 B 주식별자를 그대로 사용하고 구분코드 속성을 추가한다. 업무 식별자가 주 식별자가 아닌 점이 단점이다.
  • 주 식별자 속성의 개수가 다를 때
    • 두 엔터티의 주 식별자 개수가 다르고, 주 식별자에 공통 속성이 존재할 때 A 주식별자(1개)와 B 주식별자(2개)를 통합하고 구분코드 속성을 추가한다. 만약 A 주식별자 데이터만 들어올 경우 없는 B 주식별자는 기본값을 설정해 둔다. 
    • 인조식별자를 사용할 수도 있다. 단 주식별자였던 속성을 널 값을 허용해야 한다.
•  서브타입에 대한 사설
  • 슈퍼타입 속성을 서브타입에 상속된다. 따라서 서브타입 속성은 슈퍼타입에 속하지 않는다.
  • 슈퍼타입 속성은 일반적인 속성이지만, 서브타입 속성은 고유한 속성이다.
  • 데이터를 통합하면 서브타입이 도출되며, 서브타입은 모델의 확장성을 좋게 한다.
• 서브타입과 부분집합
  • 부분집합은 개념적인 범주를 나타내는 용어지만 서브타입은 실제적인 엔터티를 나타내는 용어다.
• 서브타입은 어떻게 도출하는가
  • 엔터티를 통합 또는 일반화
    • 두 개 이상의 유사한 엔터티에서 공통 속성을 도출하는 방법
  • 엔터티 상세화 또는 논리화
    • 복잡한 하나의 엔터티에서 유사한 속성끼리 분류하는 방법
• 왜 서브타입을 사용하는가
  • 서브타입을 도출하여 데이터를 입체화하면 데이터가 어떤 집합으로 이루어졌는지 한눈에 보여줄 수 있기 때문이다.
  • 모델의 확장성을 고려할 때도 서브타입을 사용할 수 있다.
• 한 엔터티에 서브타입이 여러 개 존재한다
  • 한 엔터티에 서브타입 후보가 여러 개 존재할 때가 있지만 최종 서브타입은 그 집합을 가장 잘 표현한 한 개만 존재해야 한다.
  • 한 엔터티에 서브타입 후보가 여러 개 존재하는 이유
    • 집합을 나누는 관점에 따라 다양한 뷰가 존재
      • 여러 분류 중에 가장 의미 있는 분류를 서브타입으로 도출해야 하며, 정하기 어려울 경우는 고유 속성이 존재하는 분류를 서브타입으로 지정할 수도 있다.
    • 코드를 서브타입으로 표현하기 때문
      • 코드 속성에 존재할 수 있는 코드 명을 서브타입으로 표현하면 모델의 가독성이 높아져서 코드를 간혹 서브타입처럼 표현하는데 코드는 서브타입이 아니기 때문에 코드를 서브타입으로 표현하는 것은 바람직하지 않다.
•  서브타입과 코드
  • 가독성을 위해 코드를 서브타입처럼 표현하기도 하지만 잘못된 모델이다. 서브타입은 하나만 존재해야 물리적으로 변환이 가능하다.
  • 만약 가독성을 위해 코드를 서브타입처럼 표현하려고 할 때는 서브타입과 코드가 다르다는 것이 나타날 수 있게 표현해야 한다.
  • 서브타입
    • 엔터티
    • 전체 집합에 대한 부분집합을 표현, 접체 집합의 성격을 파악, 속한 속성이 여러 개 존재, 한 엔터티에 하나만 존재
  • 코드
    • 속성
    • 특정 속성의 구분을 표현, 한 속성의 성격을 파악, 속한 속성이 거의 존재하지 않음, 한 엔터티에 여러 개 존재
• Is-A 서브타입과 Part-Of 서브타입
  • Is-a - 개인고객은 고객이다
    • 개인고객 둘, 법인고객 하나면 세 개의 인스턴스가 존재
    • 인스턴스로 서브타입 구분(서브타입)
  • Part-Of - 프로그램/사용자매뉴얼은 소프트웨어의 구성 요소다
    • 프로그램과 사용자매뉴얼이 하나씩이면 한 개의 인스턴스 존재
    • 속성으로 구분(1:1 관계/수직분할)
  • 서브타입은 부분집합이며, 부분집합과 전체 집합 간에 이다(Is-A)의 관계가 성립한다.
  • 일부 관계의 서브타입이 있다면 1:1 관계를 서브타입으로 잘못 파악한 것이 아닌지 의심해야 한다.
• 배타 서브타입과 중복 서브타입
  • 배타 서브타입에서는 하나의 슈퍼타입 인스턴스는 단 하나의 서브타입과 관계가 발생한다.
  • 중복 서브타입에서는 하나의 슈퍼타입 인스턴스가 두 개 이상의 서브타입 엔터티와 관계가 존재할 수 있다.
• 배타 서브타입과 이력 데이터
  • 배타 서브타입은 이력 데이터 때문에 중복 서브타입과 혼란스러울 수 있지만 배타 서브타입을 판단할 때는 시점이 중요하다. 특정 시점에 동시에 중복이 발생하지 않으면 배타 서브타입니다. 동시에 중복이 발생한다면 중복 서브타입니다.
  • 현제 시점을 기준으로 서브타입 양쪽에 해당하는 데이터가 있는지를 판단하면 된다.
  • 일반적으로 별도의 릴레이션에서 이력 데이터를 관리하는 것이 명확하다.
• 중복 서브타입에 대한 설계
  • 중복 서브타입은 서브타입끼리 겹치는 부분이 존재하는 서브타입이기 때문에 중복 서브타입의 개념이 견고하지 않아 제대로 설계하지 못하는 경우가 발생한다.
  • 슈퍼타입 인스턴스와 서브타입 인스턴스가 일대일 대응
    • 고객 3, 개인고객 1, 법인고객 2와 같이 1:1 대응
    • 변화에 유연한 모델
    • 고객 상세 정보 데이터에 중복이 발생하기 때문에 실체를 관리하는 별도의 엔터티를 만들어야 한다.
  • 슈퍼타입 인스턴스와 서브타입 인스턴스가 일대다 대응
    • 고객 1, 개인고객 1, 법인고객 1과 같이 1:M 대응
    • 변화에 유연하지 않은 모델
    • 고객 상세 정보 데이터에 중복이 발생하지 않음.
• 중복 서브타입의 주의점
  • 엔터티의 실체를 관리하는 것이 아니라 역할을 관리하는 엔터티 일 경우에 슈퍼타입 인스턴스와 서브타입 인스턴스가 1:1 대응이 되어야 한다. 
  • 슈퍼타입과 서브타입의 관리 수준이 서로 일치해야 한다.
• 완전 서브타입과 불완전 서브타입
  • 슈퍼타입 인스턴스와 서브타입 인스턴스의 관계를 인스턴스 제약이라고 한다.
  • 인스턴스 제약에 따라 완전 서브타입와 불완전 서브타입으로 구분하며 완전 서브타입은 슈퍼타입의 모든 인스턴스가 최소한 하나의 서브타입 인스턴스와 관계가 존재한다. 불완전 서브타입은 슈퍼타입에만 인스턴스가 존재하고 서브타입에는 인스턴스가 존재하지 않는 서브타입이다.
  • 일반적으로 대부분 완전 서브타입을 차지하지만, 실무에서 불완전 서브타입을 주의해서 구별할 수 있어야한다.
  • 엔터티를 과감하게 통합하거나 업무에 따라 생길 수 있다.
• 서브타입의 오해 - 슈퍼타입과 서브타입은 부모 자식 관계다
  
  • 논리적 모델에서 언터티 위치상 부모/자식 관계처럼 보이지만 데이터 성격상으로 슈퍼타입과 서브타입을 합쳐야 온전한 인스턴스가 되므로 두 엔터티는 같은 엔터티다.
  • 슈퍼타입과 서브타입은 동일한 성격의 데이터를 관리하는 동등한 엔터티이다.
• 슈퍼타입/서브타입 논리 모델의 물리 모델 변환
  • 서브타입 별로 엔터티 분할
    • 서브타입마다 별도의 엔터티로 만드는 것
    • 서브타입 별로 엔터티를 각자 생성한 후에, 슈퍼타입의 주 식별자를 포함한 속성 전부를 양쪽 엔터티에 추가
    • 엔터티를 통합하여 서브타입을 도출할 때, 개별 엔터티를 대상으로 통합할 때가 많음.
    • 서브타입별 업무가 서로 독립적일 때
    • 서브타입별 속성이 많이 다를 때
    • 서브타입별 관계가 많이 다를 때
    • 모든 서브타입을 동시에 조회하는 경우가 드물 때
    • 서브타입별 주 식별자가 상호 배타적이 아닐 때
    • 서브타입이 업무적으로 서보 약 결합 관계일 때
  • 슈퍼타입 엔터티 하나로 통합
    • 슈퍼타입에 서브타입을 통합
    • 각 서브타입에 속하는 속성을 슈퍼타입에 포함시키고, 서브타입을 삭제해 슈퍼타입만 남김
    • 서브타입별 고유 속성이 적을 때
    • 속성이 지속적으로 늘어날 가능성이 작을 때
    • 하나의 서브타입은 속석도 많고 업무도 중요하며, 나머지 서브타입은 속성이 적도 덜 중요할 때
    • 서브타입 전체를 대상으로 하는 업무가 빈번할 때
    • 데이터 건수가 많이 않을 때
    • 업무가 중요하지 않을 때
    • 서브타입이 중복 서브타입일 때
    • 서브타입이 업무적으로 서로 강 결합 관계일 때
  • 슈퍼타입 엔터티와 개별 서브타입 엔터티로 분할
    • 슈퍼타입과 개별 서브타입을 별도의 엔터티로 분할
    • 서브타입별 공통 속성을 대상으로 하는 업무가 빈번할 때
    • 통합하면 속성 개수가 너무 많아질 때
    • 업무의 변화가 빈번해 속성이 자주 추가 될 때
    • 서브타입별 고유 속성이 많을 때
    • 트랜잭션의 락을 방지하기 위해 엔터티를 분리해야 할 때
    • 공통 업무와 고유 업무가 다양하게 존재할 때
    • 중요 속성과 참고 속성으로 분리될 수 있을 때
    • 슈퍼타입의 조회가 빈번하고 조회 범위가 넓을 때
    • 서브타입이 업무적으로 서로 강 결합 관계일 때
  •  서브타입으로 도출됐다면 중요한 엔터티일 가능성이 높으며 하위 엔터티가 상당히 많을 수 있기 때문에 물리 구조를 어떻게 설계하느냐에 따라 모델의 전체 구조가 바뀌기 때문에 많은 고민이 필요하다.
  • 조회에 대한 사용 결합도와 성능적인 측면으로 서브타입을 독립적으로 조회하는지, 공통속성에 대해서만 조회하는지, 전체 데이터를 조회하는지, 횟수는 어떤지를 고려해야 한다.
  • 관리 효율성에서 서브타입이 지속적으로 늘어나는데 서브타입별로 엔터티를 분리하면 모델을 확정하기 어렵다. 
• 서브타입 모델의 물리 모델 변환 - 서브타입 별로 엔터티 분할
  • 서브타입 엔터티 명은 슈퍼타입 엔터티를 차용하여 정한다.
  • 만약 상위 엔터티가 둘 다 존재 한다면, 각 엔터티의 주 식별자 값이 중복되면 안된다는 점을 주의해야 한다.
  • 서브타입을 사용하는 엔터티가 서로 완전히 독립적이라면 사용할 수 있지만 성능 문제만 없다면 비슷한 유형의 엔터티를 통합하기 위해 일반화한 것이기 때문에 통합 모델로 사용하는 것이 바람직하다.
  • 장점
    • 엔터티의 속성이 근본적으로 구분되므로 엔터티를 명확하게 관리
    • 대부분의 조회 요건이 개별 서브타입을 사용할때 효율적
    • 각 엔터티에 해당하는 업무에 대해 상호 영향을 미치지 않게 처리
    • 각 엔터티의 크기가 줄어듬
    • 슈퍼타입과 서브타입의 엔터티 조인이 필요 없으므로 성능상 유리
    • 널 값을 갖은 속성이 줄어들어 데이터 질이 올라감
  • 단점
    • 서브타입 모두 조회하는 요건이 있을 때 union이 발생하여 쿼리가 복잡해지고 성능 측면에서 불리
    • 서브타입을 구분하는 속성을 사용하면 처리가 불편(인덱스 생성 등)
    • 시퀀스나 채번 관리 엔터티를 사용해 주 식별자 값을 생성하기 복잡함
    • 업무가 개별적으로 처리되더라도 데이터는 통합된 모습이 아니므로 DW 등의 요건에 의해 조회가 복잡
    • 공통 속성이 개별 엔터티에 반복됨으로써 넓은 의미의 1정규형이 아님
• 서브타입 모델의 물리 모델 변환 - 슈퍼타입 엔터티로 통합
  • 엔터티명은 슈퍼타입으로 하며, 주식별자도 그대로 사용함
  • 서브타입에 존재하던 고유 속성을 슈퍼타입 엔터티에 추가하고 서브타입을 구분하는 속성을 필수 값으로 넣음
  • 모델만으로 업무 규칙을 알 수 없기 때문에 제약조건으로 관리함
    • 예시) 구분 값이 a면 a값과 관련있는 값은 NOT NULL로 설정하고 a값과 관련 없는 값은 NULL 값 설정
  • 서브타입이 업무적으로 서로 강 결합 관계일 때 사용
  • 서브타입별 고유 속성이 적을 경우 사용
  • 데이터는 가능한 통합하는 것이 원칙이기 때문에 핵심적인 엔터티가 아니면 하나로 통합하는게 바람직함
  • 서브타입별 속성이 지속적으로 늘어날 가능성이 있다면 사용하는데 주의
  • 서브타입이 중복 서브타입일 경우 사용하는데 주의
  • 서브타입이 애플리케이션에서 빈번히 사용되는 중요한 엔터티라면 사용하는데 주의
  • 장점
    • 슈펕타입과 서브타입 엔터티의 조인이 발생하지 않아 조회 쿼리가 단순해지며 성능이 좋아짐
    • 엔터티 수가 감소해 관리가 용이
    • 복잡한 관계가 없어져 모델이 단순해지기 때문에 ERD 관리에 수월
    • 전체 서브타입을 검색할 때 유니온이 발생하지 않아 성능이 좋아짐
  • 단점
    • 엔터티의 속성 개수가 많아져 크기가 증가
    • 널 값이 존재하는 속성이 많아짐
    • 서브타입에 대한 업무가 추가되거나 변경되면 애플리케이션에 끼치는 영향이 커짐
    • 업무 규칙을 모델에 표현하기 어려움
    • 공통 속성을 조회하는 요건이 빈번하거나 조회 범위가 넓으면 I/O가 많아져 성능이 나빠짐
    • 엔터티의 정체성이 희석됨
• 서브타입의 모델의 물리 모델 변환 - 슈퍼타입/서브타입 개별 생성
  • 슈퍼타입 엔터티와 서브타입 엔터티가 1:1 관계로 실무에서 주로 사용하는 일반적인 모델
  • 슈퍼타입에 서브타입을 구분하는 속성이 필수로 존재해야 함
  • 업무 연관성이 있을 경우
    • 슈퍼타입과 서브타입이 업무적으로 서로 강 결합 관계일 때 사용(동시에 조회)
  • 주요 엔터티일 경우
    • 해당 엔터티가 중요하게 사용되어 다양한 조회를 만족하기 위해서는 공통 속성과 고유 속성이 구분된 모델이 효과적임
    • 주요 엔터티는 변경이 빈번하여 확장하기 좋을 모델이여야 하기 때문에 개별 생성이 좋음
    • 특별히 중요하게 사용하지 않은 서브타입 모델은 통합하여 사용
  • 공통 속성을 주로 사용하는 경우
    • 서브타입별 공통 속성을 대상으로 하는 업무가 많을 때 사용
      • 서브타입별 고유속성은 특별할 때 사용하고, 대부분 공통 속성으로 업무가 이루어질 경우
    • 공통 속성이라도 성능 저하에 영향을 미치면 통합을 고려
  • 고유 속성이 많을 경우
    • 서브타입별 고유 속성이 많은데 통합하면 하나의 엔터티에서 관리하기 어려우며 널 값이 많이 생김
    • 서브타입별 고유 속성이 많다는 것은 서브타입 간에 데이터 성격이 다소 다르다는 것을 의미함
    • 서브타입의 고유 업무가 다양하게 존재할 경우 사용
  • 속성이 빈번하게 추가될 경우
    • 업무 변화가 심해서 속성이 자주 추가될 때 사용
    • 추가 속성이 공통 속성이라면 슈퍼타입에 추가하지만, 중요하지 않은 속성이라면 서브타입 엔터티에 추가
  • 트랜잭션을 분리할 경우
    • 데이터의 트랜잭션 처리를 원활하게 할 경우 사용
    • 슈퍼 엔터티와 서브 엔터티도 별도의 트랜잭션으로 사용해야 할 경우
  • 통합하면 속성 개수가 많아질 경우
  • 해당 엔터이가 업무에서 자주 사용되는 중요한 엔터티며, 슈퍼타입 엔터티 만으로 업무가 빈번하게 처리될 경우
  • 장점
    • 슈퍼타입 엔터티는 한 블록에 많은 인스턴스가 저장되므로 핵심 조회 요건의 성능이 좋아짐
    • 논리 모델과 유사한 구조이기 때문에 업무 규칙이 표된되므로 모델의 가독성이 높아짐
    • 추가 업무로 생기는 애플리케이션의 변경 영향을 줄임
    • 전사 차원에서 집계나 DW의 요건을 만족할 가능성이 높아짐
    • 데이터 저장 공간을 가장 효율적으로 사용
  • 단점
    • 조회 요건에 따라 조인이나 조인 후의 유니온 쿼리 등이 발생해 성능 효율이 떨어짐
    • 여러 엔터티로 나뉘어 엔터티 개수가 늘어나 관리가 어려움
    • 배타/중복/완전/불완전 서브타입의 종류에 따라 인스턴스를 발생시킬 때 혼선이 발생할 수도 있음
• 서브타입 모델의 물리 모델 변환 - 슈퍼타입/서브타입 개별 생성(배타 관계)
  • 슈퍼타입과 서브타입의 관계가 서브타입으로 상속된 1:1 관계
  • 슈퍼타입과 서브타입 논리 모델을 그대로 엔터티로 생성하고 서브타입 엔터티의 주 식별자를 슈퍼타입 엔터티로 상속
    • 슈퍼타입에 발생한 유니크한 배타 관계속성으로 상호 배타적이라는 제약 설정(바타 서브타입)
    • 서브타입에서 슈퍼타입으로 관계를 상속함으로써 서브타입의 전체 인스턴스 합이 슈퍼타입이됨(완전 서브타입)
  •  서브타입이 상위 엔터티의 성격을 지니며 하위 엔터티인 슈퍼타입은 공통 속성을 모아놓은 엔터티가 됨
    • 슈퍼타입 엔터티에 서브타입의 유형코드와 상속받은 식별자 값을 묶어 유니크 인덱스로 생성
    • 서브타입 엔터티가 값이 먼저 입력된 후에 슈퍼타입 엔터티에 값이 입력됨
    • 서브타입의 엔터티의 식별자가 변경될 수 있으며 암호화가 될 수 있는 경우
      • 서브타입 엔터티도 슈퍼타입 엔터티와 마찬가지로 슈퍼타입의 인조 식별자를 사용
        • 하나의 서브타입 엔터티에 값을 입력할 때 중복된 식별자 값이 없는지 체크하는 트리거나 비지니스 로직이 필요함
  • 장점
    • 모델 구조가 일종의 제약 역할을 하여 데이터를 더욱 정확하게 관리하며 업무 파악이 쉬움
  • 단점
    • 참조 무결성 제약을 생성할 수 없기 때문에 비지니스 로직이 필요함
    • 식별자를 채번하는 트리거나 비지니스 로직이 필요함
• ERWin 툴의 서브타입 표기법
  • 서브타입을 어떤 물리 모델로 변환할지 정했다고해서 논리 모델을 물리 모델과 동일하게 표현하면 안됨
  • 논리 모델에서는 논리 모델처럼 보이고 물리 모델에서도 물리 모델로 보이는게 가장 이상적임
• 중첩 서브타입
  • 서브타입 안에 다시 서브타입이 존재하는 것을 중첩 서브타입이라 함
  • 기초 속성은 유사하지만, 고유 속성이 존재하는 다수의 엔터티를 통합하는 과정에서 생김
  • 개념 모델링이나 초기 논리 모델링 단계에서 보이지만 실무에서 물리적으로 구현되는 일은 드묾
  • 대부분 1단계 서브타입을 대상으로 엔터티로 설계함
  • 계층 서브타입은 주로 첫 번째나 마지막 서브타입을 기준으로 물리 모델을 생성함
  • 계층 서브타입을 모두 물리 모델로 생성하면 엔터티 관계가 복잡해지며 실익이 없음
  • 대부분 데이터가 통합된 것이 중요할 뿐 계층이 중요하지 않기 때문에 물리 모델에서 중첩 서브타입을 구현할 때는 신중히 검토해야 함
• 서브타입 간의 관계 표현법
  • 서브타입 간에도 관계가 존재할 수 있는데 서브타입의 성격이 다를수록, 즉 엔터티를 일반화할수록 발생할 가능성이 높음
  • 슈퍼타입 엔터티에 재귀 관계 도출
    • 슈퍼타입에 재귀 관계를 관리하기 위해 일반화한 속성을 추가
    • A서브타입과 B서브타입이 1:M 관계 일 경우에만 사용가능
    • 여러 관계를 관리하기에는 관계 속성이 늘어나서 유연하지 않은 모델
  • 서브타입 엔터티 사이의 관계 도출
    • 일반적인 엔터티 간의 관계와 동일한 관계
    • 완전 서브타입일 경우에만 사용 가능(확장성이 떨어짐)
    • 불완전 서브타입일 때는 서브타입 엔터티가 존재하지 않기 때문에 사용 불가능
    • 업무 규칙을 가장 구체적으로 관리할 수 있는 모델
  • 슈퍼타입 엔터티에 별도의 관계 엔터티 도출
    • 가장 일반적인 방법
    • M:M 재귀 관계를 관리하는 BOM 모델
    • 관계를 엔터티로 관리
    • 슈퍼타입 엔터티에서 관계를 관리
• 잘못된 서브타입
  • 서브타입을 단지 개념적으로만 표현할 경우 잘못 설계할 확률이 높음
  • 개념 모델에 서브타입을 설계했다면 그 서브타입은 논리 모델과 물리 모델에 그대로 이어져야함
  • 서브타입도 엔터티이기 때문에 모델링이 진행되더라도 구조는 그대로 유지되며, 속성이나 주변 엔터티가 생김
  • 서브타입은 DB에 생성되는 엔터티라는 사실이 중요
• 범주에 대해서
  • 엔터티를 통합하기 위해서는 엔터티의 속성을 제대로 파악해야 함
  • 다른 엔터티와의 관계나 프로세스, 화면, 조직 등과 무관하기에 데이터 본질을 제외한 외부 환경의 작용은 없어야함
  • 데이터의 통합은 성질이 유사한 것끼리 통합하는 것이지 관계가 있는 엔터티끼리 통합하는 것이 아님
  • 범주화는 논리적으로 사고하려는 사람에게 필요한 기법으로 모델러에게 큰 도움이 됨