잘못 표현된 관계선 1

관계선을 잘못 표현하는 유형은 크게 두 가지가 있습니다. 엔터티 간에 연관성이 존재하는데도 관계를 표현하지 않는 예가 있으며, 연관성이 없는데도 관계를 표현하는 예가 있습니다.

 

모델링을 수행할 때 가장 부족한 부분이 엔터티의 정의(엔터티 설명을 의미하는 것이 아님)와 관계선의 표현인데요. 아래 세 가지 정도를 항상 염두에 두면서 관계를 도출하면 좋을 거 같습니다.

 

- 속성으로 관리하려는 관계

- 참조 무결성 제약 Referencial Integrity Constraints

- 바로 상위의 1촌 관계

 

이전 글에서도 설명한 위의 세 가지 요소를 기준으로 해당 사항이 없으면 관계선으로 표현하면 안 됩니다.

 

보통 엔터티 간의 연관성이 조금이라도 보이면 관계선을 표현할 때가 많습니다. 흔한 예가 식별자가 유사할 때죠. 없어야 할 관계선이 표현되면 혼선을 일으킬 수 있습니다.

 

예전에는 엔터티 간 관계가 존재하는데 표현하지 않는 예가 많았는데 최근에는 존재하지 않는 관계를 표현하는 예가 많은 거 같습니다. 누락된 관계선도 문제지만 대강 그은 관계선도 문제입니다. 참조용 관계로 사용하는 가상(Pseudo) 관계를 남발하는 것도 원인인데 모델의 가독성을 떨어트리므로 주의해야 합니다.

 

잘못된 관계의 시발점은 잘못된 엔터티 도출일 때가 많습니다. 엔터티가 잘못 도출됐다면 그 간의 관계는 자연히 정확하지 않은 것입니다.

 

또한 잘못된 원칙도 원인일 수 있습니다. 이전 글에서 설명한 모델이 복잡해져서, 도출하기 힘들어서, 관리가 힘들어서 관계선을 생략하도록 원칙을 정하기도 합니다. 이런 원칙이 있다면 당연히 관계선은 많이 누락되겠죠.

 

그리고 모든 엔터티는 관계선으로 연결돼 있어야 한다는 원칙도 잘못된 원칙입니다. 집계나 기준 데이터를 관리하는 엔터티는 다른 엔터티와 어떠한 관계도 존재하지 않을 수 있습니다. 연관 관계가 있을 것 같다는 이유로 관계선을 표현할 때가 많으므로 주의해서 분석해야 합니다. 원천(Raw) 데이터와 연관성은 있지만 참조 무결성(RI) 관계는 없는 경우를요…

 

[그림1]은 1촌 관계를 위반한 예제입니다. 주문하기 전에 반드시 예약주문을 해야 한다는 업무 규칙을 반영한 모델입니다. 하지만 주문 엔터티의 고객번호 속성은 바로 위의 관계가 예약주문 엔터티의 고객번호 속성입니다. 고객 엔터티의 고객번호 속성이 아니고요. 상품번호도 마찬가지입니다.

 

[그림1]

 

관계가 위와 같을 때 주문고객관계와 주문상품관계는 추출 관계라고 볼 수도 있고, 중복 등의 이슈는 없다고 가정하더라도 문제가 발생할 수 있습니다. 아래 릴레이션이 [그림1] 모델에 대한 잘못 관리된 사례 데이터입니다.

 

[예약주문]

#고객번호	#상품번호	#예약주문일자	예약주문수량
123	A001	2025-03-31	3
234	A002	2025-04-30	2

 

[주문]

#고객번호	#상품번호	#예약주문일자	주문수량
123	A001	2025-03-31	3
234	A002	2025-04-30	2
345	A003	2025-05-05	1

 

위에서 예약주문 엔터티에는 존재하지 않는 ‘345’ 고객이 주문 엔터티에 존재해도 [그림1] 모델에서는 틀린 것이 아닙니다. ‘345’ 고객이 고객 엔터티에는 존재하기 때문에요. 하지만 주문을 하기 전에 예약주문이 존재해야 되기 때문에 위와 같은 데이터가 발생되면 안 됩니다.

 

무심코 표현한 주문고객관계는 단순히 추출 관계가 아니라 업무 무결성에 위배되는 잘못된 데이터를 관리하게 될 수도 있는 표현이므로 주의해야 합니다.

 

만약 예약주문 엔터티와 주문 엔터티가 관계가 없다면, 즉 예약주문과 주문을 별도로 관리하고 주문에 대한 예약주문이 어떤 것이었는지를 관리할 필요가 없다면 [그림2]의 관계선은 모두 맞습니다.

 

[그림2]