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 관계의 해소 방법 - 속성에 의한 통합

특징

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

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: 응답을 분리하여 설계