3장. 실전 데이터 모델링 이슈

3.1 M:N 관계해소 방법

\- M:N 관계 : 엔티티 상호간의 관계가 1:M, M:1로 되는 경우 (M:N 혹은 다대다 관계라 함)
\- M:N 관계의 예 : 학생 엔티티와 강의 엔티티. 한명의 학생은 여러 강의를 들을 수 있고 한 강의에는 여러 학생이 수강한다.

• 관계 엔티티타입 분리
• 주식별자 통합
• 부모 엔티티 타입에 속성 추가

① 기본적인 M:N 관계 해소 방법 - 관계 엔티티타입 분리

• 업무 규칙 예: "한번 납부할 때는 여러 개의 요금 고지서를 한꺼번에 납부할 수 있고, 또 다른 요금 고지서를 여러 번에 걸쳐 납부할 수 있다."
• 엔티티타입 : 요금, 납부

• M:N 관계 해소 방법 - 관계 엔티티타입 분리
  : 요금납부 라는 요금의 PK 속성과 납부의 PK 속성을 합쳐서 PK 속성으로 하는 관계 엔티티를 생성

② PK에 의한 M:N 관계의 해소 방법 - 주식별자 통합

• 업무 규칙: "한번 납부할 때는 여러 개의 요금 고지서를 한꺼번에 납부할 수 있고 또 하나의 요금 고지서를 여러 번에 걸쳐 납부할 수 있다."

• M:N 관계 해소 방법 - 주식별자 통합

• 업무 규칙에 대한 모델 반영 결과
    1) 하나의 요금 고지서를 여러 번에 걸쳐 납부 - 하나의 요금에 납부가 여러개 가능(납부순차번호)
    2) 한번 납부할 때 여러 개의 요금에 대해 납부 - 납부 엔티티타입에 PK가 납부번호와 요금납부순차전호로 되어 있음. 즉 요금번호는 납부 엔터티타입의 속성으로써 여러번 발생 가능

• 주식별자 통합이 가능한 경우
    1) 통합되는 엔티티타입의 속성이 많지 않고 데이터 수정이 많지 않으며 읽는 작업이 많이 발생하는 엔티티타입의 경우 적당
    2) 데이터 모델의 복잡도 감소, select 시 조인을 하지 않음(???)

③ 속성에 의한 M:N 관계의 해소 방법 - 부모 엔티티타입에 속성 추가

• 업무 규칙: "한번 납부할 때는 여러 개의 요금 고지서를 한꺼번에 납부할 수 있고 또 하나의 요금 고지서를 여러 번에 걸쳐 납부할 수 있다."
• 추가 업무 규칙: "하나의 요금고지서에 대해 최대 두 번까지는 분할 납부가 가능하다."
   
• M:N 관계의 해소 방법 - 속성에 의한 통합
   
  
• 속성 추가 방법이 가능한 경우
    1) 해당 업무 규칙의 최대값이 적은 것이어야 하며, 최대값이 변경될 가능성이 적어야 함
   

3.2 1:1 관계 해소 방법

① 별개의 엔티티타입으로 따로 표현하는 방법

• 장점
  1. 각각의 업무에서 추가적인 사항이 발생하여 엔터티타입이 변경될 경우 편리함. 즉 모델의 확장성이 좋다 (....)
  2. 각각의 엔터티타입이 다른 엔터티타입과의 관계를 명확히 표현. 업무 흐름이 명확해 짐 (.......)

• 단점
  1. 너무 많은 엔터티 타입으로 모델의 복잡성 증가
  2. 데이터를 통합 조회할 필요가 있을 경우 SQL의 복잡도 증가(join)

• 1:1 관계를 개별 엔티티타입으로 유지하는 경우
  1. 생성 시기가 명확하게 구분되고
  2. 타 엔티티타입과의 관계가 서로 다르며
  3. 데이터 선택 시 개별 테이블의 내용만을 따로 선택하는 경우가 많은 경우

② 하나의 엔티티타입으로 완전히 통합하는 방법

• 기준
  1. PK 가 동일하게 사용 가능
  2. 한 시점에서 두 엔티티타입이 동시에 발생되면 안 되고, 두 엔티티타입의 속성들이 비슷할 때는 하나로 통합

③ 부분 통합

• 기준
  1. PK 구조는 동일하더라도 그 내용은 다른 경우

• 특징
  1. 업무의 통합이 아니라 데이터 모델의 통합
  : 즉 각각의 업무에서 데이터가 발생될 경우 각각 Insert 가 발생함
  2. 데이터를 선택할 때 구분코드 값을 항상 조건으로 지정하여 데이터를 읽어야 함

• 부분통합 모델 수정안
  : 책에서 제안하는 모델의 경우 PK가 구성이...
  

④ 슈퍼 엔티티타입 생성

• 기준
  1. PK와 그 의미가 동일하고 속성의 일부만 다른 경우

• 슈퍼, 서브 타입 표현법의 다른 예 (Baker 표기법-DA#)
  
  
  

3.3 엔티티타입의 통합

• 엔티티타입 통합 목적

1. 정보를 조회 작업이 용이
   : 조인 불필요
2. 엔티티타입 간 중복성이 제거
   : 동일한 속성을 다른 엔티티타입에서 중복으로 관리하지 않아도 됨
3. 동일한 규칙에 따라 하나의 엔티티타입으로만 표현이 가능
   : ?? 다시 풀어보면 -> 동일한 업무 규칙을 가지는 서로 다른 업무는 통합 가능 (예. AS서비스 업체의 전화접수, 방문접수)
4. ERD 표현이 간편해 짐

• 엔티티타입 통합 시 문제점

1. 업무의 확장성이 감소할 수 있음
   : 특정 엔티티타입만 관여하는 관계 혹은 특정 엔터티타입에 해당되는 업무가 변경된 경우 반영이 힘듬
2. 데이터 모델만으로 업무 흐름을 이해하기 쉽지 않음
   : 모델 표현법에 따라 다름
   
3. 시스템 성능이 저하될 수 있음
   : 데이터 양 증가에 따른 성능 저하 가능성 있음
4. 속성에 제약을 걸지 못하는 경우가 발생
   : 업무 특성에 따라 청구 엔터티타입 속성에서는 청구지명이 Not Null 이지만 출급 엔터티타입에서는 Nullable 임. 통합 테이블에서는 Not Null 속성으로.
5. 체크 조건이 늘어남
   : 구분코드를 조건에 항상 넣어야 함
6. SQL 문장을 작성하기 힘듬

• 엔티티타입 통합의 순서
  • 엔티티타입의 PK 그리고 PK와 관련된 업무 규칙을 통합
  • 관계와 관계에 의해 발생된 FK 또는 FK와 관련된 업무규칙을 통합
  • 속성과 속성에 관련된 업무 규칙을 통합

1. 엔티티타입을 통합하는 경우
(1) PK가 동일한 엔티티타입
■ PK가 동일한 엔티티타입의 통합 - 완전 통합
: 업무상 구분될 필요가 없는 동일한 데이터를 분리해 놓은 경우

■ PK가 동일한 엔티티타입의 통합 - 추가 속성
: PK 구조가 동일하나 두 엔티티타입에 대한 구분이 필요한 경우

■ 엔티티타입 통합 수퍼/서브타입으로 통합
: 추가적인 구분 속성이 필요한 경우 사용

(2) PK가 일치하지는 않지만, 엔티티타입의 성격이 비슷하여 둘 중 하나의 PK를 선택하여 통합하여도 나머지 PK는 AK(Alternate Key)로 이용 될 수 있는 경우

(3) PK가 일치하지는 않지만 도메인이 비슷하고, 엔티티타입에 포함된 속성이 비슷할 경우
: 동일한 PK 구조를 가진 엔터티타입의 통합 시 데이터는 하나의 로우에서 관리됨을 의미
: But 데이터 모델의 PK 구조가 비슷하여 통합한 경우는 데이터를 새로운 로우로써 추가됨을 의미

(4) 복합 PK를 가진 엔티티타입에서 두 엔티티타입의 PK 구성이 전혀 다르더라도 PK를 구성하는 복합 속성 중 일부 비슷한 속성을 이용하여 통합
■ 복합 PK 구성 중 동일 속성에 의한 엔티티타입의 통합 대상

■ 복합 PK 구성 중 동일 속성에 의한 엔티티타입의 통합 결과

3.4 코드 엔티티타입 설계 방법

• 코드화
  정보화 시스템을 구축할 때 어떤 업무의 데이터 단위를 일정한 체계로 구분하는 단위를 코드화라 한다.

(1) 한가지 코드 값이 반복적으로 나타나는 경우

• 일반적으로 코드구분, 코드, 코드값 으로 데이터 모델을 설계
  : 책에는 없지만 상위코드값 속성도 같이 관리하는 경우도 많음

: 코드에 제약사항을 코드규칙으로 넣은 내용은 별도의 규칙 엔티티타입으로 도출하는 것이 바람직하지 않을까...

(2) 한 가지 코드에 대해 여러개의 속성이 반복되어 나타나는 경우

• 일반적인 엔티티타입 설계와 동일하게 설계
  : ex. 부서코드

3.5 도미노 속성에 대한 데이터 모델링 방법

• 도미노 속성
  : 앞의 값에 규칙적인 제약이 연쇄적으로 발생하는 경우
  

• 도미노 속성의 데이터 모델링 방법

1. 해당 업무에서 도미노가 발생할 수 있는 최대값을 정의하여 모델링하는 방법
   
2. 도미노 속성을 BOM( Bill of Material)을 이용하여 모델링하는 방법
   : Bill of Material - M:N의 속성을 자기 참조 관계로 풀어주는 데이터 모델링 방법
   

• 도미노 속성의 활용

1. 도미노 속성 전체를 하나의 속성처럼 활용하는 형태
   : 연쇄적으로 발생하는 코드값들을 하나로 엮어서 보여줄 때
2. 사용자 인터페이스에서 앞 값에 의해 뒤의 값이 한정되어 보여주는 경우
   : 첫번째 도미노 값에 따라 다음 도미노 값에 나타날 값들이 달라짐

3.6 메시지 엔티티타입 설계 방법

• 메시지의 종류
  : 정보, 경고, 에러
  : 메시지 모델은 정해진 답이 없으므로 업무적으로 발생하는 특수성을 감안하여 설계
  

3.7 이력 엔티티타입 설계 방법

• 시간이 흐름에 따라 발생하는 과거와 현재 데이터를 지속적으로 유지하는 관리방법을 이력관리
  : 이러한 이력관리를 위해 만든 엔티티타입을 이력 엔티티타입 이라 함

• 이력 데이터 발생의 세 가지 유형

1. 변경 이력
   : 이미 관리하는 데이터에 대해 변경이 발생한 경우, 업무상 필요에 의해 신구 데이터를 모두 관리하는 것
2. 발생 이력
   : 시간에 따라서 발생하는 데이터를 모두 모아서 관리하는 것(예를 들어 월별 발생하는 급여 데이터)
3. 진행 이력
   : 업무가 진행되는 상태를 모두 관리하는 것 (예를 들어 공사 착공, 기초공사, 본공사 등 공사 진행에 대한 이력 데이터)

• 이력 데이터 모델링 방법