데이터베이스 설계와 구축 1부 논리 설계 - 3. 실전 데이터 모델링 이슈

데이터베이스 설계와 구축 - 성능까지 고려한 데이터 모델링 Part 1 논리설계

 

 

Chapter 2. 실전 데이터 모델링 이슈

 

1. M:N 관계 해소방법

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

* 관계가 있는 엔티티타입 이름을 붙여 관계 엔티티타입을 생성한다.

 

(2) 주식별자 통합

* 자식 엔티티타입이 부모 엔티티타입과 생사를 같이 하는지 검증한 후에 시행

* 엔티티타입의 속성이 적고 데이터 수정이 많지 않으며 읽는 작업이 많이 발생하는 엔티티타입의 경우 사용

 

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

* 엔티티타입간 관계를 검증하여 관계 엔티티타입을 도출하도록 해야함

* 업무 규칙의 최대값이 지정, 변경될 가능성이 적어야 가능

 

 

2. 1:1 관계 해소방법

(1) 별개의 엔티티타입으로 따로 표현 방법

* 개별 엔티티타입을 그대로 유지함

* 전체 업무 이해에 도움이 되며 관계 변경시 유연하게 변경이 가능하다(모델의 확장성이 좋다)

* 너무 많은 엔티티타입과의 관계로 모델 복잡성이 증가하고 물리 테이블로 구성 시 많은 읽기 작업으로 인해 성능에 영향을 미칠 수 있다.

 

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

* PK가 동일하게 사용될 수 있다면 두 엔티티타입을 통합

 

(3) 부분 통합을 하는 방법

* PK를 변경하여 하나의 엔티티타입으로 통합

* 또는 속성에 따라 별도의 업무에서 유용하게 사용되는 속성을 부분적으로 통합

 

(4) 슈퍼 엔티티타입을 생성하는 방법

* PK와 그 의미가 동일하고 속성의 일부가 다르다면 엔티티타입을 슈퍼타입으로 통합 정의

 

 

3. 엔티티타입의 통합

* 목적

- 정보 조회 작업 용이 : 조인 작업의 잦은 발생

- 엔티티타입간 중복성 제거 : 사용자 인터페이스가 바뀌지 않게 해야함. 만약 바뀐다면 모델 통합 이외에 업무 분석에 오류가 있음을 인지

- 동일 규칙에 따라 하나의 엔티티타입으로만 표현 가능 :

- ERD의 표현이 간편

 

* 문제점

- 업무의 확장성 감소

- 데이터 모델만으로 업무 흐름을 이해하기 어려움

- 시스템 성능 저하

- 속성에 제약을 걸지 못함

- 체크해야 할 조건이 늘어남

- SQL 문장 작성이 어려움

 

* 엔티티타입 통합시 고려사항

- PK가 동일한 엔티티타입

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

- 도메인이 비슷하고, 엔티티타입에 포함된 속성이 비슷할 경우

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

 

 

4. 코드 엔티티타입 설계 방법

* 데이터 모델링 방법

 

 - 코드값 하나가 반복적으로 나타나는 경우

  (1) 코드 구분에 대해 먼저 설계

  (2) 상세 코드와 코드값을 조사

  (3) 엔티티타입을 설계

  (4) 각 코드에 별도의 제약이 있을 수 있는 것을 가정하여 설계(Optional)

 

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

 

 

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

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

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

- 해당 업무에서 도미노가 발생할 수 있는 최대값을 정의하여 모델링 하는 방법

- 도미노 속성을 BOM을 이용하여 모델링 하는 방법

 

* 도미노 속성의 활용

- 도미노 속성 전체를 하나의 속성처럼 활용하는 형태

- 사용자 인터페이스에서 앞 값에 의해 뒤의 값이 한정되어 보여주는 경우

 

 

6. 메시지 엔티티타입 설계 방법

* 메시지 데이터 모델링 과정

(1) 개발하고자 하는 모든 시스템과 연관된 메시지 조사

(2) 메시지 성격에 맞게 데이터 모델링을 진행

 

 

7. 이력 엔티티타입 설계 방법

* 발생 유형

(1) 변경이력

(2) 발생이력

(3) 진행이력