태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

'유연한 모델'에 해당되는 글 2건

엔터티 간의 관계에서 생기는 관계 속성은 한 엔터티에 여러 개가 있을 수 있으며, 그 관계 속성 중에는 유사한 성격의 속성이 있을 수 있다. 이때 유사한 관계 속성이 두 개 이상이며, 추가될 가능성이 조금이라고 있다면 별도의 관계 엔터티로 설계한다.

 

[그림1] 보험계약 엔터티에는 세 개의 관계 속성이 존재한다.

 


[그림1]

 

보험을 계약한 고객과 보험의 피보험자 고객, 보험의 연대보증 고객이 누구인지를 관리하는 속성이 관계 속성이다. 따라서 계약고객번호/피보험고객번호/연대보증고객번호 속성은 관계 속성이며, 관계선이 세 개이므로 관계 속성과 마찬가지로 관계 명에도 역할(Role) 이름을 사용한 모델이다.

 

이미 세 개의 관계 속성이 존재하지만 연대 보증인의 경우에는 여러 명을 관리할 수도 있어서 관계 속성이 더 늘어날 가능성이 있다. 이렇게 관계 속성이 늘어날 가능성이 있을 때는 아래 모델처럼 별도의 엔터티에서 관계를 관리한다.

 

[그림2]

 

보험계약당사자 엔터티는 관계(역할) 엔터티(Relationship Entity). [그림1] 보험계약 엔터티에 있던 관계 속성을 관리하는 엔터티다.

 

이와 같이 엔터티에서 관계를 관리하면 관계가 늘어나더라도 보험계약당사자 엔터티의 인스턴스만 늘어나므로 모델에는 영향을 미치지 않는다. 계약자/피보험자/연대보증인 이외의 다른 유형이 생겨도 당사자유형코드에 인스턴스만 추가하면 된다.

 

[그림2] 모델은 매우 유연한 모델이다. 업무 자체가 변경되지 않는 경우를 제외하면 관계 엔터티와 같은 정규형 엔터티를 사용해야 한다.

 

만약 관계 속성의 수가 완전히 고정적이라면 [그림1] 모델과 같이 관계 속성으로 관리할 수 있다. 업무가 변하지 않아서 계약자/피보험자/연대보증인 고객이 각각 한 명이고, 다른 유형의 고객은 생길 수 없다면 관계 속성으로 관리하는 게 바람직하다.

 


블로그 이미지

블루퍼필

댓글을 달아 주세요

  • 최상운 2017.03.22 01:12  댓글주소  수정/삭제  댓글쓰기

    머라고 불러야 하나...김이사는 좀 그렇고...그냥 이름 부를게 기창!!

    1년만에 소속을 듣네...뉴질랜드에 갔군...

    우리 나이가 되면 '내가 잘 살고 있나?' 라고 한 번쯤은 생각을 하지...삶에 터닝 포인트를 만들고 싶지만 운신의 폭은 그리 넓지 않지...가진건 별로 없지만 그나마 있는 것이라도 지키고 싶어서...

    자네의 결정이 좋을 결정이 되길 바래. 돌아 오는 날까지 자네와 집 사람 그리고 아이들 건강하고

    난 여전히 회사에 있어...나에게도 좀 작은 변화를 주려고 노력 하고 있고...시간되면 연락줘 이메일이 좋겠군 samuelc@empal.com

관계 엔터티의 장점은 유연하다는 것입니다. 반면에 다수의 관계 속성을 사용하는 방식의 단점은 유연하지 않다는 것입니다.

 

이전 글에서 설명했듯이 관계 속성을 사용하다 당사자 유형 중에서 연대보증인이 늘어날 때, 보험료 납부자와 같은 당사자 유형(서브타입) 자체가 늘어날 때 난감해집니다. 관계 엔터티를 사용하면 당사자구분코드에 ‘납부자’를 추가하면 약간의 수정이 발생할 뿐이죠. 어플리케이션이나 SQL의 수정을 최소화시키는 유연한 모델이 되는 것입니다.

 

관계 엔터티에서는 다른 속성(부가 데이터)을 관리하기 수월해집니다. [그림1] 모델과 같이 관계 엔터티도 고유의 속성을 가지게 될 때가 있습니다. 계약자와 피보험자의 신용정보 활용에 대한 동의 데이터를 관리할 수 있습니다.


 

[그림1]

 

만약 관계 속성을 사용하면 [그림2] 정도가 될 거 같습니다.


 

[그림2]

 

드물긴 하지만 관계 엔터티의 하위 엔터티가 생길 수 있습니다. [그림3]은 창작한 모델인데요. 만약 보험과 연관된 피보험자의 법정대리인을 관리해야 된다면 관계 엔터티의 하위 엔터티를 생성해 관리할 수 있습니다.


 

[그림3]

 

그런데 관계 엔터티와 같은 역할을 관리하는 교차 엔터티는 하위 엔터티가 존재하지 않는 것이 일반적이라는 게 제 경험입니다. 케이스별로 달라질 것이지만 대체로요. 위의 가상 모델에서도 법정대리인은 고객 엔터티의 하위 데이터라고 봐야 될 거 같습니다.

 

[그림3]을 관계 속성으로 관리하려면 스키마는 [그림4] 정도가 될 것이고요. 대략 a관계는 보험계약 속성이 피보험자고객번호일 때만 성립한다는 로직 정도가 별도로 관리돼야겠네요. 이 정도 되면 그야말로 끼워맞추기식 모델이 됩니다. 일반적으로 알고 있는 표기법대로 해석해서는 알 수 없는 암호와 같은 모델이 되죠.


 

[그림4]

 

제가 약간 소설을 쓰긴 했지만 위와 같은 모델을 실무에서 종종 봅니다. 일반적으로 생각하면 이해할 수 없는 모델이요. 다수의 모델러가 이해할 수 없는 모델은 일단 의심해봐야 됩니다.

 

 


블로그 이미지

블루퍼필

댓글을 달아 주세요