다수의 관계 속성 & 하나의 관계 엔터티

이전 글에서 밝혔듯이 저는 관계를 속성이라고 생각합니다. 다른 엔터티와 연관성을 알 수 있는 속성으로요. 속성이 존재해야 관계가 성립되는 것입니다.

 

관계 속성은 데이터 생성 순서 개념이 존재하는 것이 일반 속성과 다른 점입니다. 하위 엔터티 속성의 데이터는 상위 엔터티의 속성(주 식별자)에 존재해야 하기 때문에요. 그 외에는 그냥 속성하고 같다고 생각됩니다.

 

이런 관계 속성은 엔터티 간에 두 개 이상일 수 있습니다. 하지만 실무 모델에서는 관계선을 정확하게 도출하지 않아 엔터티 간에 관계선이 여러 개가 존재하는 엔터티를 찾아보기 어렵습니다.

 

[그림1]은 보험 계약과 연관된 고객이 계약자, 피보험자, 연대보증인 등으로 세 명일 때의 모델입니다. 세 명이 전부라면 보험계약 엔터티에서 관계 속성으로 관리해도 문제가 없고요. 다만 관계선을 세 개 표현해야 하고요. 관계선이 여러 개이니 관계명에 롤(Role) 이름을 사용해야 합니다.

 

[그림1]

 

만약 [그림1] 모델에서 계약자는 한 명이지만 피보험자는 두 명, 연대보증인은 세 명까지 가능하다라는 요건이 생기면 모델은 [그림2]와 같이 달라집니다.

 

[그림2]

 

[그림2]와 같은 모델도 괜찮다고 판단할 수 있습니다. 이후에 관계 속성과 관계 엔터티의 장단점을 비교할테지만 일방적으로 좋은 건 없다는 게 원론적인 결론입니다.

 

하지만 비교적 절대적인 기준은 있는데요. [그림2] 모델과 같은 요건에서 연대보증인 숫자에 제한이 없다면 [그림2]와 같이 사용할 수는 없습니다. 간혹 논리적으로 10명까지 정도라고 해석하고 연대보증인고객번호10까지 관계 속성을 생성해서 사용하는 경우도 있긴 합니다만 바람직하지 않습니다.

 

이때는 [그림3]과 같은 모델을 사용해야 합니다. 보험계약당사자 같은 엔터티를 관계(역할) 엔터티라고 합니다. 두 엔터티 간에 많은 관계(역할)가 존재하면 이처럼 엔터티로 관리해야 합니다.

 

[그림3]

 

[그림1]과 같은 관계 속성이 완전히 100% 영원히 고정되지 않는 한 저는 [그림3]과 같은 관계 엔터티를 사용합니다.

 

다음 글에는 관계 엔터티의 유용한 점들에 대해 설명하겠습니다. 관계 속성을 사용하는 것의 단점을 포함해서요.