관계 엔터티의 장점 2

관계 엔터티의 장점에 대한 두 번째 글입니다.

 

[그림1]과 같은 모델의 단점이 성능이 떨어지는 것이라고 생각하는 사람이 많은데요. 진짜인지 아닌지를 여기서 따지지는 않고요. ‘성능이 반드시 떨어진다’는 건 아니라는 전제하에 케이스별로 따지는 게 정답이라고 언급하고 글을 이어가겠습니다.

 

[그림1]

 

만약 성능에 문제가 된다면 비정규형을 고려해야 됩니다. 관계 속성을 나열해서 사용하는 것도 비정규형이지만, 그쪽으로 한번 가면 되돌아오기 어렵고요. 업무가 복잡할수록 누더기가 된다고 보여집니다.

 

[그림1]의 관계 엔터티에서 몇 가지 비정규형을 고려할 수 있습니다. 제 생각에는 [그림1]이 정규형이니까 모든 비정규형은 다 적용할 수 있다고 보는데요. 모든 경우를 장담할 수는 없겠죠.

 

[그림2]와 같이 중복 관계(계약자고객)를 채택할 수 있습니다. 만약 보험계약 당사자 중에 계약자는 모든 보험계약에서 언제나 한 명이고, 개별적으로 죄회할 때가 빈번하다면요.

 

[그림2]

 

물론 중복(추출) 관계가 바람직하진 않으므로 보험계약당사자 엔터티에서 계약자를 뺄 수 있습니다. 그러면 보험계약 엔터티의 계약자고객번호 속성은 중복 속성이 아니라 기초 속성이 됩니다.

 

[그림2]와 같은 모델은 계약자를 대량으로 조회하는 요건에 대해 성능이 최적화된 모델이라고 볼 수 있습니다. 오히려 관계 속성을 나열해서 사용한 모델 보다 나을 수 있습니다.

 

또한 중복 속성도 관리할 수 있습니다. 계약 당사자의 이름이 항상 같이 조회된다면 [그림3]과 같이 고객명 속성을 중복 관리할 수 있습니다.

 

[그림3]

 

만약 고객이력 엔터티가 존재하고 고객명이 이력 관리되면, 보험계약당사자 엔터티의 고객명은 당사자로서 체결할 당시의 고객명을 관리하는 요건으로 확대될 수도 있습니다.

 

관계 속성으로 관리한다면 대략 [그림4]와 같은 모델이 됩니다.

 

[그림4]

 

그리고 관계 엔터티는 [그림5]와 같이 자체적으로 이력 관리할 수 있는 구조입니다. 별도의 이력 엔터티(보험계약당사자이력)를 두어도 좋고요.

 

[그림5]

 

관계 속성 방식으로는 [그림6] 정도가 될 거 같습니다.

 

[그림6]

 

이밖에 다수의 관계 속성을 사용하는 방법의 단점은 여러 가지가 있습니다.

 

다수 속성으로 관계를 관리하면 인덱스의 숫자가 늘어나게 됩니다. 단순히 반복 속성의 인덱스 몇 개만 늘어나는 것이 문제가 아니라 반복 속성이 결합 인덱스에 사용되면 인덱스 관리는 대단히 힘들어집니다. 반면에 관계 엔터티를 사용하면 인스턴스 갯수가 많이 증가하는 것이 단점이 될 수 있습니다.

 

필자는 SQL이 쉬워지는 것을 장점으로 생각하지 않지만 [그림4] 보다는 [그림3]이 SQL이단순해집니다. [그림4]는 많은 ‘OR’ 조건이 사용돼 성능 비효율도 발생할 수 있습니다.

 

모든 면에서 관계 엔터티를 사용하는 것이 좋아 보이지만 몇 가지 선택 기준이 있습니다.