엔티티 관계선

 

관계선

관계선은 반드시 참조 무결성 제약으로 구현돼야 합니다. 하위 엔티티 속성 값이 널이거나 상위 엔티티의 주 식별자에 존재할 때만 관계선을 표현해야 합니다. 하지만 실무에서는 무분별하게 표현하는 경우가 있습니다.

 

계좌 - 계좌번호 (PK) / 고객번호 / 계좌명 / 관리부서코드

-----

부서 - 부서코드 (PK) / 부서명

계좌 - 계좌번호 (PK) / 고객번호 / 계좌명 / 관리부서 코드(FK)

 

부서 - 계좌 (1:N)

 

관계선은 누락되었지만 실제 관리하고자 하는 관계 속성인 관리부서코드는 존재하기에 큰 문제가 되지 않습니다. 

 

관계선이 복잡해 보이는 이유로 관계선을 생락하면 안됩니다. 도출된 관계라면 생략해도 무관한 관계선은 존재하지 않습니다.

ERD(모델)에서 참조 무결성(RI) 제약을 추출해 DDL을 생성해서 DBMS에 실행하는 경우라면 FK가 존재해야 하므로 관계선을 반드시 표시해야 합니다.

 

반대로, 아래 모델은 실제 존재하지 않는 관계를 표현한 예시입니다.

거래내역 엔티티는 현금 거래에 대해서만 관리하는 엔티티입니다. 그리고 수표거래내역 엔티티는 수표 거래만 관리하는 엔티티입니다.

이때 거래내역 엔티티의 데이터와 수표거래내역 엔티티의 데이터는 상호 배타적 데이터로 아무 관계가 없습니다.

 

단순히 주 식별자(PK)가 같다는 이유로 두 엔티티 관계선을 표현한 잘못된 모델입니다.

 

거래내역 - 거래일자 (PK) / 거래순번 (PK) / 거래금액

수표거래내역 - 거래일자 (FK) / 거래순번 (FK) / 수표금액

 

이때 거래내역 엔티티의 데이터와 수표거래내역 엔티티의 데이터는 상호 배타적 데이터로 아무 관계가 없습니다. 하지만 단순히 주 식별자(PK)가 같다는 이유로 두 엔티티에 관계선을 표현한 잘못된 모델입니다.

 

참조 무결성 제약을 생성하면 수표거래내역 엔티티에는 데이터가 생성되지 못할 것입니다.

만약 수표에 대한 거래도 거래내역 엔티티에 포함되며 수표는 고유하게 관리할 속성이 있어 별도 상세 엔티티를 둔다는 요건이 있다면 두 엔티티 간에는 관계가 존재하므로 관계선이 존재하게 됩니다.

 

주 식별자가 같고 엔티티까지 유사하면 무조건 관계가 존재한다고 생각할 때가 많습니다.

 

아래 퇴직 사원 데이터는 사원 엔티티에 존재하지 않고 퇴직사원 엔티티에만 존재한다고 가정하면 사원과 퇴직 사원 엔티티는 서로 관계가 없어 관계선을 표현하면 안됩니다.

 

사원 - 사원번호 (PK) / 사원명 / 주민번호 / 전화번호

퇴직사원 - 사원번호 (FK) / 사원명 / 주민번호 / 전화번호

 

'사원' 엔티티에 존재하다 퇴직하면 '퇴직사원' 엔티티로 옮겨가게 됩니다. 둘 중 한 엔티티에만 데이터가 존재해서 관계가 존재하지 않으며, 데이터가 상태에 따라 옮겨지기 때문에 옳지 않으며 엔티티 통합 관리하는 것이 효율적입니다.

 

관계선은 상위 엔티티의 데이터를 하위 엔티티에 관리하려는 요건이 있을 때만 표현해야 합니다. 관리하려고 하는 관계여야 관계선으로 표현하는 것입니다.

 

관계선에 혼란스러운 것 중 하나는 프로세스를 관계로 표현하는 것입니다. 물론 프로세스가 관계로 표현되는 예도 있지만 그렇지 않은 예가 많기 때문에 프로세스 관계선 표현은 주의해야 합니다.

 

주식을 주문하고 체결, 결제된 데이터를 관리하는 모델이 있습니다.

하나의 주문이 여러 건 체결되므로 주문과 체결 사이 관계는 이상이 없습니다.

하지만 체결 한 건에 대해 여러 건의 결제 데이터를 관리하지 않습니다.

데이터가 생성되는 순서는 주문, 체결, 결제가 맞지만 데이터 생성 순서와 관계선은 별개로 아래와 같이 데이터 처리 순서에 따라 관계선을 표현하면 안됩니다.

 

주문 - 주문번호(PK)

체결 - 체결번호 / 주문번호(FK)

결제 - 결제번호(PK) / 체결번호(FK)

 

주문 - 체결 (1:N) >> 체결 - 결제 (1:N)

 

만약 체결 가격이 같은 데이터는 하나의 결제로 처리한다는 업무 규칙이 있을 때 모델은 아래와 같다.

 

주문 - 주문번호(PK)

체결 - 체결번호(PK) / 주문번호(FK)

결제 - 결제번호(PK)

 

주문 - 체결 (1:N)

결제 - 체결 (1:N)

 

체결 엔티티에서 결제, 주문 번호 속성을 참조키(FK)로 사용했다.

업무 규칙이나 처리 프로세스는 위와 같아도 체결 엔티티에 결제번호 데이터를 관리할지는 다시 고려해야 합니다. 

 

만약, 관계의 상속 단계가 깊지 않다면 원칙적으로 추출 관계를 고려하지 말아야 합니다.

성능 향상을 위한 목적으로 반드시 필요한 경우만 추출 관계를 고려해야 합니다.

 

상위 엔티티 주 식별자가 복합 주 식별자일 때는 몇 가지 주의사항이 있습니다. 상속받은 관계 속성이 상위 엔티티의 주 식별자와 순서가 일치하지 않으면 안됩니다.

 

 

계좌 - 계좌지점(PK) / 계좌상품(PK) / 계좌순번(PK)

주식잔고 - 계좌지점 (FK) / 계좌순번 (FK) / 종목코드 (FK) / 계좌상품 (FK) / 수량 / 금액

주식종목 - 종목코드(PK) / 종목명

 

상위 엔티티의 주식별자와 순서가 일치하지 않는 관계속성

계좌 - 주식잔고 (1 : N)

주식잔고 - 주식종목 (N : 1)

 

'계좌' 엔티티의 주식별자와 동일하게 '주식잔고' 엔티티의 주 식별자도 계좌지점, 계좌상품, 계좌순번 순서가 돼야 합니다.

주식종목 엔티티 주 식별자인 종목코드 속성이 상속받은 계좌 식별자 사이에 위치하면 안됩니다.

 

부모 엔티티의 주 식별자가 하위 엔티티로 상속될 때는 전체가  식별자로 상속되던지 일반 속성으로 상속되던지 해야 합니다.

 

그리고 아래와 같이 여러 속성을 하나의 속성으로 변환해서 상속하면 안됩니다.

계좌 - 계좌지점(PK) / 계좌상품(PK) / 계좌순번(PK)

주식잔고 - 계좌번호 (FK) / 종목코드 (FK) / 수량 / 금액

 

계좌지점 + 계좌상품 + 계좌순번 속성을 합친 계좌번호를 의미해서 하위 엔티티에 상속한 관계를 맺으면 가독성에도 문제가 있지만 조인에도 문제가 있어 정당한 관계라고 볼 수 없습니다. 부득이하게 사용해야 한다면 관계선은 생략해야 합니다.

 

상위 엔티티 주 식별자는 상속될 때 Null/Not Null 이 부분적으로 지정돼도 안됩니다.

일반 속성으로 상속받은 주문일자, 계좌지점, 주문순번 속성 중에서 일부만 Null이 허용돼서는 안됩니다.

 

주문 - 주문일자(PK) / 계좌지점(PK) / 주문순번(PK)

주문체결 - 체결번호 (PK) / 주문일자 Null (FK) / 계좌지점 Null (FK) / 주문순번 Not null (FK) / 체결수량 / 금액

상속받은 복합 주 식별자가 Null과 Not Null로 지정된 모델