by-nc-sa     개발자, DBA가 함께 만들어가는 구루비 지식창고!

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




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

3.1 M:N 관계해소 방법

① 기본적인 M:N 관계 해소 방법 - 관계 엔티티타입 분리
- 업무 규칙: "한번 납부할 때는 여러 개의 요금 고지서를 한꺼번에 납부할 수 있고 또 하나의 요금 고지서를 여러 번에 걸쳐 납부할 수 있다."

- M:N 관계 해소 방법 - 관계 엔티티타입 분리

② PRIMARY KEY에 의한 M:N 관계의 해소 방법 - PRIMARY KEY 통합

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

- M:N 관계 해소 방법 - PRIMARY KEY 통합


- 추가 설명
  1) "하나의 요금 고지서를 여러 번에 걸쳐 납부한다." - 납부 엔티티타입에 요금번호(FK)가 존재 함으로 성립
  2) "한번 납부할 때 여러 개의 요금에 대해 납부할 수 있다." - 납부 엔티티타입에 PRIMARY KEY가 납부번호와 요금납부순차전호로 되어 있음.
  3) 위 관계는 자식 엔티티타입과 부모 엔티티타입과 반드시 필수관계인지 검증 후에 적용해야함.
- 특징
  1) 통합되는 엔티티타입의 속성이 많지 않고 데이터 수정이 많지 않으며 읽는 작업이 많이 발생하는 엔티티타입의 경우 적당(속성이 많을 경우 데이터 중복 발생)
  2) 데이터 모델이 단순해 질 수 있으며, 조인이 불필요하게 됨
 
③ 속성에 의한 M:N 관계의 해소 방법 - 부모 엔티티타입에 속성 추가
- 업무 규칙: "한번 납부할 때는 여러 개의 요금 고지서를 한꺼번에 납부할 수 있고 또 하나의 요금 고지서를 여러 번에 걸쳐 납부할 수 있다."
- 추가 업무 규칙: "하나의 요금고지서에 대해 최대 두 번까지는 분할 납부가 가능하다."
 
- M:N 관계의 해소 방법 - 속성에 의한 통합
 

- 특징
  1) 해당 업무 규칙의 최대값이 적은 것이어야 하며, 최대값이 변경될 가능성이 적어야 함
 

3.2 1:1 관계 해소 방법

  (1) 1:1 관계 해소 방법 - 개별 엔티티타입 유지
       - 업무 규칙: "한 번의 청구에 대해서는 한 번의 출금이 발생되고 출금이 한 번 발생할 때는 반드시 하나의 청구서에 의해서만 출금될 수 있다."


  (2) 1:1 관계 해소 방법 - 하나의 엔티티타입 통합(완전 통합)
       - 업무 규칙: "한 번의 청구에 대해서는 한 번의 출금이 발생되고 출금이 한 번 발생할 때는 반드시 하나의 청구서에 의해서만 출금될 수 있다."

  (3) 1:1 관계 해소 방법 - 하나의 엔티티타입 통합(부분 통합)
       - 업무 규칙: "한 번의 청구에 대해서는 한 번의 출금이 발생되고 출금이 한 번 발생할 때는 반드시 하나의 청구서에 의해서만 출금될 수 있다."
       - 추가: "청구 번호와 출금 번호 각각이 다른 의미를 가진다."

   (4) 1:1 관계 해소 방법 - 엔티티 타입 통합(수퍼 타입)
        - 해당 엔티티타입의 PK의 그 의미가 동일하고 속성의 일부만 다르다고 하면 엔티티타입을 수퍼타입으로 통합하는 것도 좋은 방법임

3.3 엔티티타입의 통합은 어떻게 할 것인가?

 * 엔티티타입 통합의 목적
   (1) 여러 엔티티타입에 있는 비슷한 정보를 한군데서 표현하므로 종합적으로 정보를 조회하는데 작업이 용이(조인 불필요)
   (2) 비슷한 속성이 합해지므로 엔티티타입 간 중복성이 제거
   (3) 비슷한 유형의 엔티티타입이 발생할 경우 동일한 규칙에 따라 하나의 엔티티타입으로만 표현이 가능

* 엔티티타입 통합의 단점
   (1) 업무의 확장성이 감소할 수 있음
   (2) 업무 흐름을 엔티티타입만 가지고는 파악이 어려움
   (3) 많은 데이터가 한 군데 집약되어 있으므로 시스템 성능이 저하될 수 있음
   (4) 여러 엔티티타입의 속성이 존재하므로 필요시 속성에 제약을 걸어야 하는데 제약을 걸지 못하는 경우가 발생

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

* 엔티티타입을 통합하는 경우등
   (1) PK가 동일한 엔티티타입의 통합 - 완전 통합
        - 두 엔티티타입을 업무상 일부러 구분할 필요가 없는 경우

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

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

   (4) PK가 비슷한 엔티티타입 통합
   (5) PK, 도메인, 속성이 비슷한 엔티티타입 통합
   (6) 복합 PK 구성 중 동일 속성에 의한 엔티티타입의 통합
 

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

  (1) 한가지 코드 값이 반복적으로 나타나는 경우 데이터 모델링 방법

    - 복잡한 데이터 모델

     - 설계 순서
       1) 코드구분에 대해서 먼저 설계한다.
       2) 상세 코드와 코드값을 조사한다.
       3) 엔티티타입을 설계 한다.

     - 변경된 데이터 모델
    (2) 한 가지 코드 속성에 대해 여러개의 속성이 반복되어 나타나는 경향이 있는 유형에 대한 데이터모델링
       - 속성이 여러개인 부서코드는 별도의 통합코드 엔티티타입이 필요하지 않음

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

* 도미노 속성: 앞의 값에 규칙적인 제약이 연쇄적으로 발생하는 경우
 
1) 도미노 속성 데이터 모델: 속성 규칙의 최대값이 지정된 경우

2) 도미노 속성 데이터 모델 - Bill of Material (BOM) 이용

 
 
* 도미노 속성의 활용
   1) 도미노 속성 전체를 하나의 속성처럼 활용하는 형태
   2) 사용자 인터페이스에서 앞 값에 의해 뒤의 값이 한정되어 보여주는 경우
 

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

* 메시지의 종류: 정보, 경고, 에러
 
* 방법1: 하나의 엔티티타입으로 설계

* 방법2: 응답을 분리하여 설계

 

문서에 대하여

  • 이 문서는 오라클클럽 [대용량 데이터베이스 스터디] 모임에서 작성하였습니다.
  • 이 문서의 내용은 데이터베이스 설계와 구축(개정판) 이춘식 저 서적을 스터디 하면서 정리한 내용 입니다.
  • 이 문서를 다른 블로그나 홈페이지에 게재할 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^

문서정보

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.