[개발 공부 111일차] DB 개론 | 데이터 모델링 문제 및 해소

< 목차 >

0. TL;DR

1. 1:1 관계

2. M:N 관계

3. 엔티티 타입 통합

4. 이력(log, 기록) 엔티티 타입 설계

 

 

0. TL;DR

1. 1:1 관계
   1. 1개의 엔티티 타입으로 통합: PK가 동일하게 사용 or 한 시점에 2개의 엔티티 타입이 동시 발생 금지
   2. 부분 통합: PK 속성들의 구조가 모두 비슷한 경우, 편의상 하나로 통합하여 표현
   3. 슈퍼 엔티티 타입 생성: PK와 의미가 동일하고, 속성의 일부만 다를 경우 슈퍼 타입으로 통합
2. M:N 관계
   1. 관계 엔티티 타입 분리
   2. 주 식별자 통합
   3. 부모 엔티티 타입에 속성 추가
3. 이력 엔티티 타입 설계
   1. 이력 관리: 하나의 업무가 시간 흐름에 따라 발생하는 데이터
   2. 이력 데이터 발생 유형
      1. 발생 이력
      2. 변경 이력
      3. 진행 이력

 

 

1. 1:1 관계

: 엔티티 타입 간 관계가 1:1로 대응하는 것

즉, 해당 엔티티 타입의 PK가 동일한 경우를 나타낸다.

 

 

(1) 1개의 엔티티 타입으로 통합

• 동일한 PK 구조를 가지는 1:1 관계면 하나로 통합
• PK가 동일하게 사용 or 한 시점에 2개의 엔티티 타입이 동시 발생 금지: 순서대로 실행돼야 함을 의미. 청구가 실행되고 있는 시점에 지급이 실행되는 것처럼 동시에 실행되면 안 됨!
• 2개의 엔티티 타입의 속성들이 비슷할 땐 하나로 통합

 

 

(2) 부분 통합

• PK는 동일하더라도 내용이 다른 경우, 별도 엔티티 타입으로 유지하거나 1개의 엔티티 타입으로 통합할 때 PK를 변경하여 통합
• PK 속성들의 구조가 모두 비슷한 경우, 편의상 하나로 통합하여 표현

 

 

(3) 슈퍼 엔티티 타입 생성

• PK와 의미가 동일하고, 속성의 일부만 다를 경우 슈퍼 타입으로 통합
• 엔티티 타입의 PK가 같고, 동일한 속성을 가지고 있으며 일부 속성이 다르거나 각각의 관계가 다른 엔티티 타입과 상이할 때 적용

 

 

2. M:N 관계

: 2개의 테이블이 서로의 행에 대해서 여러 개로 연관돼 있는 상태

즉, 상호 간의 관계가 1:M, M:1로 구성된 상태다.

 

[예시] 학생 1명이 여러 개의 수업을 수강, 한 수업은 여러 학생을 포함하는 구조

 

 

(1) 관계 엔티티 타입 분리

• M:N 관계는 기본적으로 관계 엔티티 타입을 도출해 해소함
• 관계 엔티티 타입은 업무에 의한 것보다 데이터 모델링 작성 중 관계에 의해 발생, 엔티티 타입명이 실제 업무에 없는 경우가 많음
  • 이때는 적절하게 의미 있는 엔티티 타입명을 지정
  • 엔티티 발생 순서에 따라 엔티티 타입명 순서를 정하는 게 일반적

 

 

(2) 주 식별자 통합

• 데이터 모델 복잡도 감소
• 물리 테이블에서 데이터를 가져올 때, 여러 개의 테이블을 조인하지 않는 장점

 

 

(3) 부모 엔티티 타입에 속성 추가

• 해당 업무 규칙의 최댓값이 지정되고, 변경 가능성이 적은 것 선정
• 모델 복잡도 감소
• 물리 테이블 조인 감소

 

각 테이블의 PK를 FK로 참조하고, ‘연결 테이블(= 매핑 테이블)’을 사용해 해소

 

 

3. 엔티티 타입 통합

(1) 통합하는 목적

1. 복잡한 모델의 단순화
2. 엔티티 타입 간 중복성 제거
3. 동일한 규칙에 따라 1개의 엔티티 타입으로 표현 가능
4. ERD의 표현 단순화

 

 

(2) 통합할 시, 문제점

1. 업무의 확장성 감소
   • 특정 엔티티 타입만 관여하는 관계나 프로세스, PK, FK 구조에 제약
   • 업무 변경 시, 모델 변경이 쉽지 않음
2. 데이터 모델만으로 업무 흐름 파악 어려움
   • 병합 내용을 알고 있지 않는 사람은 모델만으로 이해 어려움
3. 시스템 성능 저하
   • 많은 양의 데이터가 한 곳으로 집약되므로 데이터 증가에 따른 성능 저하 가능성 발생
4. 속성에 제약조건 설정하기 어려움
   • Not Null, Check, Default Value를 지정할 때 제약사항 발생
5. 체크해야 할 조건 증가
   • 서로 다른 성격의 엔티티 타입이 한 군데에 모여 있어, 체크해야 할 조건이 증가
6. 복잡한 SQL 구문 필요
   • 각기 다른 PK를 가지면서 통합됐을 경우, 두 엔티티를 1개의 row로 표현하고 조회하기 위해 상대적으로 복잡한 SQL 구문 필요

 

 

4. 이력(log, 기록) 엔티티 타입 설계

(1) 이력 관리

: 하나의 업무가 시간 흐름에 따라 발생하는 데이터

 

• 과거와 현재의 데이터를 지속적으로 유지하는 관리법
• 이력 엔티티 타입: 이력 관리를 위한 엔티티 타입
• 과거 데이터 추적, 통계 데이터에 주로 적용

 

 

(2) 이력 데이터 발생 유형

 

1. 발생 이력: 시간에 따라 발생하는 데이터를 모두 관리하는 것
   • 5/1 판매 이력, 5/2 판매 이력
2. 변경 이력: 업무상 필요에 의해 수정되면서 변경 전/후 데이터를 관리하는 것
   • 주문 수량 변경, 상품 가격 변경
3. 진행 이력: 프로세스가 진행되는 상태를 모두 관리하는 것
   • 주문 확인, 배송 준비 중, 출고 완료, 배송 중, 배송 완료