데이터 모델링 - 실전 데이터 모델링 이슈

 

M:N 관계 해소 방법

 

M:N 관계는 "한번 납부할 때는 여러 개의 요금 고지서를 한꺼번에 납부할 수 있고, 또 하나의 요금 고지서를 여러 번에 걸쳐 납부할 수 있다." 처럼 두 개개의 엔티티가 다수의 관계를 맺는 관계이다.

 

 

[요금 M:N 납부]

 

M:N 관계를 해소하기 위한 방법은 다음과 같다.

 

 

첫 번째, 관계 엔티티타입 분리

 

 

요금과 납부의 M:N 관계를 분리하기 위해 요금납부 관계 엔티티로 분리한다.

 

 

두 번째, Primary key에 의한 관계 해소

 

 

위 방법은 다음과 같이 설명할 수 있다.

 

"하나의 요금 고지서를 여러 번에 걸쳐 납부한다." 는 납부 엔티티타입에 요금번호(FK)가 존재함으로 성립된다.

"한번 납부할 때 여러 개의 요금에 대해 납부할 수 있다."는 납부 엔티티타입에 primary key가 납부번호와 요금납부 순차번호로 될수 있다.

 

Primary key를 사용한 해소는 통합되는 엔티티타입의 속성이 많지 않고, 데이터 수정이 많지 않으며 읽는 작업이 많이 발생하는 엔티티타입의 경우 적당하다. Primary key를 사용하여 관계 해소를 실시하면 데이터 모델이 단순해 질 수 있으며, 조인이 불필요하게 된다.

 

 

세 번째, 속성에 의한 통합

 

 

속성에 의한 통합을 실시할 때는 해당 업무 규칙의 최대값이 적은 것이어야 하며, 최대값이 변경될 가능성이 적어야 한다.

 

 

 

 

1:1 관계 해소 방법

 

"한 번의 청구에 대해서는 한 번의 출금이 발생되고 출금이 한 번 발생할 때는 반드시 하나의 청구서에 의해서만 출금될 수 있다."처럼 '청구'와 '출금'이 1:1 관계를 가지는 엔티티들은 개별 엔티티를 유지하는 것도 좋은 방법이다.

 

 

 

하지만 통합을 해도 좋은 관계는 통합을 실시하는 것이 좋다. 통합을 실시하는 방법은 다음과 같다.

 

 

첫 번째, 하나의 엔티티로 통합(완전 통합)

 

 

청구와 출금을 하나로 통합하여 '청구출금'으로 통합할 수 있다. 이 경우는 두 엔티티타입을 업무상 구분할 필요가 없는 경우이다.

 

 

두 번째, 하나의 엔티티로 통합(부분 통합)

 

 

이 때 청구 번호와 출금 번호가 각각 다른 의미를 가질 때는 '청구출금번호'와 '발생순번'으로 청구와 출금을 통합할 수 있다.

 

 

세 번째, 엔티티 통합(수퍼 타입)

 

해당 엔티티타입의 PK의 그 의미가 동일하고 속성의 일부만 다르다고 하면 엔티티타입을 수퍼타입으로 통합하는 것도 좋은 방법이다.

 

 

 

 

 

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

 

엔티티타입 통합의 목적은 여러 엔티티타입에 있는 비슷한 정보를 한군데서 표현하므로 종합적으로 정보를 조회하는데 작업이 용이 해진다. 또한 비슷한 속성이 합해지므로 중복성이 제거되고, 비슷한 유형의 엔티티타입이 발생할 경우 동일한 규칙에 따라 하나의 엔티티타입으로만 표현이 가능해진다.

 

단점은 업무의 확장성이 감소되고, 업무 흐름을 엔티티만 가지고는 파악이 어려우며, 많은 데이터가 한 군데 집약되어 있으므로 시스템 성능이 저하될 수 있으며, 여러 엔티티타입의 속성이 존재하므로 필요시 속성에 제약을 걸아야 하는데 제약을 걸지 못하는 경우가 발생한다.

 

 

 

코드 엔티티타입 설계 방법

 

 

코드 값이 반복적으로 나타나는 경우 데이터 모델링은 다음과 같이 한다.

 

우선, 코드부분에 대해서 먼저 설계를 한다. 그리고 상세 코드와 코드값을 조사하여 엔티티타입을 설계한다. 설계가 끝난 코드 엔티티 데이터 모델은 다음과 같다.

 

 

 

앞의 값에 규칙적인 제약이 연쇄적으로 발생되는 도미노 속성에 대한 데이터 모델링 방법은 다음과 가탇.

 

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

 

 

 

 

출처: http://www.gurubee.net/pages/viewpage.action?pageId=1966777