태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

'관계 속성'에 해당되는 글 4건

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

 

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

 


[그림1]

 

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

 

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

 

[그림2]

 

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

 

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

 

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

 

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

 


블로그 이미지

블루퍼필

댓글을 달아 주세요

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

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

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

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

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

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

모델링의 3요소는 엔터티, 속성, 관계입니다.

엔터티 정의는 중요하기 때문에 어려운 반면, 속성 정의는 많은 개수 때문에 어려움을 겪습니다. 엔터티나 관계에 비해 압도적으로 많죠
.

속성은 엔터티의 성격을 상세하게 기술하는 요소입니다. 속성을 모두 도출(정의)하면 해당 엔터티가 관리하는 데이터가 무엇인지 알기 쉽습니다.

속성은 데이터의 값을 저장하는 저장소입니다. 데이터를 저장하는 가장 작은, 독립된 저장 단위죠. 이렇게 저장된 데이터가 엔터티를 자세하게 묘사합니다.

 

속성을 모두 도출해야 엔터티가 온전해집니다. 속성이 채워지지 않는 한 모델링은 끝난 것이 아닙니다. 결국 속성을 상세하게 분석하는 시간이 많을수록 데이터 모델의 완성도는 높아집니다.

 

이를 역으로 표현하면 모델링 시간이 충분히 주어질수록 속성을 상세하게 분석할 수 있어 모델의 완성도가 높아지게 됩니다. 결국 모델링 시간이 충분하지 않으면 속성과 관련된 작업이 부실해지게 됩니다.

 

속성의 정의 자체는 어렵지 않습니다. 하지만 속성의 진정한 쓰임새를 알려면 속성의 종류를 아는 것이 좋습니다. 속성의 다양한 분류법을 통해 속성이 무엇인지 더욱 상세하게 알 수 있을 것입니다.

 

다음과 같은 다양한 방법으로 속성을 구분할 수 있습니다.

 

-식별자(Key) 속성 & 비식별자(Non-Key) 속성
-
기초(Basic) 속성 & 관계(Relationship) 속성 & 추출(Derived) 속성 & 시스템(System) 속성
-
원본(Raw) 속성 & 추출(Derived) 속성
-
단일 값(Single-Valued) 속성 & 다가(Multivalued) 속성
-
필수(Mandatory) 속성 & 선택(Optional) 속성
-
코드(Code) 속성 & 비코드(Non-Code) 속성

 

위와 같은 방법으로 어떤 속성을 명확히 분류할 수 있다면, 속성이 무엇인지 온전히 안다고 할 수 있습니다.

 

위의 분류를 앞으로 하나씩 상세하게 설명하겠습니다.



블로그 이미지

블루퍼필

댓글을 달아 주세요

  • 금땡이 2012.02.28 14:08  댓글주소  수정/삭제  댓글쓰기

    바쁘신 와중에도 꾸준이 글을 올려 주시니 고맙습니다. 책 내용도 좋아 3번이나 읽었네요.
    프로젝이 다르다 보니 자주 뵙지도 못하고 블로그로 위안을 삼아야겠네요.^^

    • 블루퍼필 2012.02.28 19:45 신고  댓글주소  수정/삭제

      ㅎㅎ 누군가 했어요.

      긴 프로젝트 끝내서 시원섭섭하겠어요.
      재충전할 시간이 있을려나 모르겠네요.

      가끔 들러서 좋은 글 남겨주시고...
      그래도 심심하면 분당으로 놀러와요... ㅎ

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

 

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


 

[그림1]

 

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

 

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

 

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


 

[그림2]

 

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

 

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

 

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


 

[그림3]

 

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

 

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


 

[그림4]

 

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


 

[그림5]

 

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


 

[그림6]

 

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

 

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

 

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

 

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

 

 


블로그 이미지

블루퍼필

댓글을 달아 주세요

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

 

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

 

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

 

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


 

[그림1]

 

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


 

[그림2]

 

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

 

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

 

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


 

[그림3]

 

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

 

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

 


블로그 이미지

블루퍼필

댓글을 달아 주세요