태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

'참조 관계'에 해당되는 글 4건

관계선(Relationship Line)에는 여러 가지 의미가 포함돼 있습니다. 그으면 멋있을 거 같아서 관계선을 표현하진 않죠.

 

가장 중요한 의미는 관계선을 보고 업무 규칙을 알 수 있다는 것입니다. 관계를 정확히 표현했다면 관계선은 어떤 식으로든 두 엔터티 간의 업무 규칙을 보여줍니다.

 

그 업무 규칙은 기본적으로 종속 관계나 참조 관계냐로 구분할 수 있습니다. 종속 관계라면 두 엔터티는 뗄래야 뗄 수 없는 한 몸과 같은 관계이고요. 참조 관계는 없으면 그냥 허전한 관계입니다. 중요한 정보가 비는 거죠. 툴에서 이 둘을 구분하도록 해 주는 것도 의미가 있을 거 같습니다. 현재는 식별 관계냐 비식별 관계냐로 구분하는데 좀 부족한 거 같습니다.

 

업무 프로세스에 의해 발생되는 데이터면 관계선이 업무의 흐름을 의미하기도 합니다. 물론 업무의 흐름과 정반대의 관계선이 존재할 수도 있지만 일반적으로는 업무의 흐름과 관계선의 흐름은 일치합니다.

 

그리고 상위(부모) 엔터티의 주 식별자와 하위(자식) 엔터티의 속성을 연결시켜 주는 것이 관계선입니다. 하위(자식) 엔터티의 속성에 사용한 데이터는 상위(부모) 엔터티의 주 식별자에 가서 보면 존재해야 합니다. 하위(자식) 엔터티의 속성에 사용한 데이터가 널(Null)이든지요…

 

또한 관계선은 데이터를 입력할 때 입력 순서를 의미하기도 합니다. 이것도 반드시 그렇지는 않지만 일반적으로 그렇습니다. 그렇지 않다면 데이터 성격에 따르기 보다는 인위적인 경우가 많습니다. 제대로 된 관계선인지, 어쩔 수 없는 경우인지 반드시 검토해야 합니다.

 

관계선은 당연히 데이터를 조회할 때 조인(Join)하는 경로를 의미하기도 합니다. 관계선으로 연결된 상위 엔터티와 조인해야 조인 속성을 기준으로 같은 데이터만 결과로 가져오게 됩니다. PK가 같다고 엄한 엔터티와 조인하면 엄한 데이터 결과가 생성됩니다. 결과는 나오겠지만 원하는 결과는 아닌 것이죠…

 

관계선을 모델에 표현 안 해도 된다는 의견이 종종 있습니다. 복잡해 보인다는 것이 주요 이유인데요. 일일이 파악하는 것도 힘들고 관리하기도 쉽지는 않습니다. 하지만 입력사원번호 같은 시스템 속성과 ~구분코드와 같은 코드 속성을 제외하고 모든 관계는 표현해야 하는 게 원칙입니다.

 

위에서 설명한대로 관계선은 여러가지를 의미하기 때문에 모델에 표현하지 않아도 상관없는 선택 사항이 아니라 반드시 표현해야 하는 필수 사항입니다.

 


'데이터 Story > 모델링 이론' 카테고리의 다른 글

잘못 표현된 관계선 1  (4) 2011.02.16
관계 도출 시 핵심 요소  (0) 2011.02.16
관계선이 의미하는 것  (4) 2011.02.16
종속 관계와 참조 관계  (7) 2011.02.16
관계란?  (0) 2011.02.16
엔터티 도출 원칙 2  (1) 2011.02.16
블로그 이미지

블루퍼필

댓글을 달아 주세요

  • 혈기린 2011.07.08 14:06  댓글주소  수정/삭제  댓글쓰기

    종속관계 참조관게 = 식별관계 비식별 관계 인줄 알았는데
    종속관계를 비식별관계로도 할수 있다는간가요 앞에서 설명하신 느슨한 종속관계 개념일까요?
    식별자로 상속받지 못한경우 존재종속이라는것을 표현하는게 힘들지 않을까 하는데요?

    • 블루퍼필 2011.07.08 22:15 신고  댓글주소  수정/삭제

      질문을 정확히 이해했는지 모르겠습니다.

      종속 관계라도 비식별 관계일 수 있습니다.
      예를 들면 계좌가 있어야 존재하는 엔터티 중에 계좌번호가 주 식별자가 아닌 경우가 꽤 있습니다.
      많은 경우 바람직하지 않지만 유효한 방법입니다.

      그리고 딱히 존재 종속을 표현하는 방법은 없을 거 같은데요. 식별자로 상속 받았다고 해도요.
      식별 관계든 비식별 관계든 동일할 거 같습니다.

  • 혈기린 2011.07.11 11:04  댓글주소  수정/삭제  댓글쓰기

    식별관계이지만 인조 식별자로 대체하는 경우인가요?
    계좌가 있어야 존재하는 엔티티 이지만 인조 식별자를 사용하여 계좌번호를 일반속성으로 한다는것인가요?

    • 블루퍼필 2011.07.11 21:30 신고  댓글주소  수정/삭제

      예... 맞습니다.
      식별 관계지만 인조 식별자를 사용하는 경우가 있습니다.

      인조 식별자에는 부분 인조 식별자가 포함되고요. '일자+순번' 식별자에서 '순번'처럼요.

      또한 또 다른 후보 식별자를 채택하는 경우도 있습니다.
      ~순번 같은 부분 인조 식별자를 사용하는 엔터티는 바람직하지 않아 주의해서 봅니다.

      식별자의 복잡한 상속이 문제가 안 된다면 종속 관계는 식별자로 상속하는 것이 바람직합니다.

[그림1]은 종속 관계입니다. 상품가격 데이터는 상품이 존재하지 않으면 존재할 수 없으므로(존재 존속됐으므로두 엔터티의 관계는 완전한 종속 관계입니다.


 

[그림1]

 

두 엔터티가 종속 관계면 엔터티명도 보통 유사합니다. 그리고 보통 부모 엔터티의 식별자는 자식 엔터티의 식별자로 상속됩니다.

 

[그림2]도 종속 관계이지만 팀은 특정 리그에 속해 있어야 한다는 요건이 있어야 종속 관계로 도출할 수 있습니다. 만약 일반적인 요건이라면 리그와 팀은 별개로 존재할 수 있습니다.


 

[그림2]

 

팀이 생기면 한 리그에만 속해야 한다는 요건에 따라 종속 관계로 도출됐고 식별자로서 상속했는데요. [그림1] 모델과 약간 다른 면이 있습니다. 요건이 바뀔 가능성이 있다는 것이고요. 팀 엔터티는 실체 엔터티라 식별자를 단순하게 만들 필요가 있다는 것입니다.

 

사회인 야구 팀이라면 리그에 속하지 않을 수 있습니다. 프로야구 팀이라도 리그가 바뀔 여지는 있고요. 이런 가능성은 염두에 둬야 합니다그리고 팀 엔터티의 주 식별자는 팀번호가 되는 게 간명합니다. 실체 엔터티의 주 식별자 속성이 두 개 이상이 되면 바람직하지 않습니다.

 

그래서 [그림3] 모델과 같이 단독 속성으로 주 식별자를 정하면 리그번호는 자연스럽게 일반 속성이 됩니다.


 

[그림3]

 

하지만 [그림3] 모델과 같은 관계선으로(참조 관계로) 표현하면 팀이 리그에 종속돼 있다는 요건이 관계에 의해서 관리되지 않고 업무 규칙에 의해서 관리됩니다. 즉 요건이 깨질 수도 있다는 것을 의미합니다.

 

이와 같이 종속 관계를 느슨하게 관리하면 확장성은 좋아지게 됩니다. , 확장성을 고려하면 종속 관계가 느슨해지는(Loosely Coupled) 것이죠. 존재 종속이라는 데이터 성격과 주 식별자의 효율성, 업무의 변경 가능성 등을 고려해 판단할 필요가 있습니다.

 

[그림4] 모델은 종속 관계가 아닙니다. 팀 엔터티에 관계 속성인 리그번호 값이 널(Null)을 허용하므로 팀은 리그가 없어도 별도로 존재할 수 있습니다. , 팀은 창단됐지만 리그에 참여하지 않은 상태로 존재할 수 있다는 요건이 있는 것입니다. 따라서 단순 참조 관계입니다.


 

[그림4]

 

[그림5]의 두 엔터티도 참조 관계입니다. 관계를 삭제해 사원 엔터티에서 부서코드 속성이 삭제 되더라도 사원 데이터는 존재할 수 있습니다. 중요한 속성을 관리하지 못할 뿐이지 사원의 존재 자체가 문제 되는 것은 아닙니다.

 

 

[그림5]

 

필자는 참조 관계일 때 부서 엔터티를 부모 엔터티라고 표현하지 않습니다. 그리고 사원 엔터티를 자식 엔터티라고도 표현하지 않습니다. 단순히 상위 엔터티, 하위 엔터티라고 표현하는데요. 부서 엔터티는 참조되는(Referenced) 상위 엔터티이고 사원 엔터티는 참조하는(Referencing) 하위 엔터티입니다.

 

엔터티 간에 종속 관계가 존재하면 부모 엔터티의 주 식별자를 자식 엔터티의 주 식별자로 상속합니다. 물론 [그림3]과 같이 전략적으로 부모 엔터티의 주 식별자를 자식 엔터티의 일반 속성으로 상속할 수도 있습니다.

 

하지만 참조 관계의 엔터티는 상위 엔터티의 주 식별자를 하위 엔터티의 주 식별자로 상속하지 않습니다. 일반 속성으로 상속하지 않고 주 식별자로 상속하는 것은 일반적으로 잘못된 모델입니다. 존재 종속Existence Dependency이 없음에도 주 식별자로 말미암아 존재 종속되기 때문에 주의해야 합니다.

 

종속 관계는 생각보다 많지 않습니다. 시스템 마다 틀릴 수 있지만 20% 정도가 종속 관계라고 느껴집니다. 몇 번 강조했듯이 두 엔터티의 관계가 종속 관계인지 참조 관계인지를 따지는 것은 상당히 의미 있는 작업입니다. 관계 도출의 시발점입니다.

 

 


'데이터 Story > 모델링 이론' 카테고리의 다른 글

관계 도출 시 핵심 요소  (0) 2011.02.16
관계선이 의미하는 것  (4) 2011.02.16
종속 관계와 참조 관계  (7) 2011.02.16
관계란?  (0) 2011.02.16
엔터티 도출 원칙 2  (1) 2011.02.16
엔터티 도출 원칙 1  (0) 2011.02.16
블로그 이미지

블루퍼필

댓글을 달아 주세요

  • extremedb 2011.02.25 11:02 신고  댓글주소  수정/삭제  댓글쓰기

    안녕하세요. 오동규 입니다.
    식별/비식별에 관한 좋은글 입니다.
    저는 관계를 전달/조회관계로 나누기도 합니다.
    아래의 글을 참조하세요.
    http://scidb.tistory.com/entry/관계선을-함부로-긋는-이유

    • 블루퍼필 2011.02.25 22:04 신고  댓글주소  수정/삭제

      글 잘 봤어요.

      조회관계가 좀 어렵지만... 추출 관계에는 RI 제약을 생성하지 않아야 된다는 거 같아요. 아마 정확하게 이해하진 못했을 거에요. ㅎㅎ

      참조 무결성을 높이려고 RI 제약을 사용하는 것이라 굳이 FK가 필요 없을 거 같지는 않은데... 어쨌든 조회관계라는 용어가 흥미로운데 만나서 자세히 얘기해야겠어요.

  • extremedb 2011.02.28 13:59 신고  댓글주소  수정/삭제  댓글쓰기

    데이터가 부서테이블로 부터 insert/update 되지 않기 때문에 RI는 의미가 없습니다.
    부모와 전달관계가 없는데 전달관계의 제약을 달려면 특별한 이유가 필요하겠죠.

    개념/논리모델 단계에서에서 관계의 역정규화를 나타낸 다는 것이 옳은 것인지.....
    개념/논리모델 단계에서 조회관계선을 긋는 순간 관계의 역정규화를 하는 것이 됩니다.
    논리모델단계 까지는 관계선을 긋지 말고,물리모델 단계에서 조회관계임을 표시하는 것이 더 좋은
    방법이라고 이야기 한것입니다. 모델러에 따라 입장이 다를 수는 있습니다.

    모델링은 완벽한 답안이라는 것은 없으니, 더 자세한 이야기는 다음에 하시죠.

  • 혈기린 2011.07.05 14:53  댓글주소  수정/삭제  댓글쓰기

    그림2] 요건중에 팀이 생기면 한 리그에만 속해야 한다는 요건에 따라 종속 관계로 도출됐다고 하셨는데 이렇게 하면 한팀이 여러리그에 존재할수 있는거 아닌가요 예를 들어 A리거-1번순번-A팀 B리거-2번순번-A팀 이렇게요
    전 존재종속이면 무조건 부모엔티티의 식별자가 자식 엔티티의 식별자로 상속된다구 생각했었는데 느슨하게 관리하기위해 일반 속성으로도 상속시킬수 있는거였군요 알면 알수록 어려워지는 모델링 ㅎㅎ

    • 블루퍼필 2011.07.05 23:15 신고  댓글주소  수정/삭제

      [그림2] 팀 엔터티는 팀을 관리하기 때문에 업무 식별자가 팀명 속성이라고 봐야죠. ㅎㅎ
      스키마 만으로는 인스턴스를 정확히 관리할 수 없어 유니크 인덱스 제약이 필요합니다.
      실제로 [그림2] 모델은 사용 안 할 거 같습니다. 개념을 설명하기 위한 모델입니다.

  • 초심자 2011.08.28 20:40  댓글주소  수정/삭제  댓글쓰기

    그림1이 책에선 잘못나와있습니다.
    그리고 그림1은 바커표기법인제 그림1을 제외한 나머지 그림들은 관곈는 ie 표기법 ,엔티티는 바커 표기법으로 표현한거 같은데 제가 잘못이해한건가요 책을 보다가 ERD 표현이 이해가 안되서 이렇게 글을 남깁니다.

    • 블루퍼필 2011.08.28 21:41 신고  댓글주소  수정/삭제

      몰랐는데요. 예리하십니다. ㅎㅎ

      제 책에서는 거의 대부분 Barker 표기법을 사용했는데요.
      이해가 편할 거 같아서 관계를 설명하는 예제, 특히 카디널러티와 옵셔널러티에 대한 예제에서는 IE 표기법을 사용했습니다.

      같은 페이지에서는 번갈아 사용하면 헷갈리는데 놓친 거 같습니다.

      감사합니다. ㅎㅎ

관계(Relationships)가 두 개 이상의 엔터티 간에 존재하는 연관성이라는 정의 자체는 어렵지 않습니다. 하지만 관계는 모델링에서 가장 잘못 사용하고 있는 것 중에 하나입니다.

 

제가 관계를 따질 때 중요하게 생각하는 것은 두 가지입니다. 하나는 참조 무결성(Referencial Integrity) 관계가 있느냐이고, 다른 하나는 바로 위의 관계만을 표현하고 있느냐입니다. 사실 두 개는 비슷한 얘기입니다. RI 관계1촌 관계를 우선 기억했으면 합니다.

 

엔터티 간의 연관성에는 두 가지 종류가 있습니다. 하나는 종속 관계(Dependent Relationships)이고 다른 하나는 참조 관계(Referential Relationships)입니다. 종속 관계는 종속 엔터티(Dependent Entity)와 같은 개념입니다.

 

종속 관계는 부모 엔터티와 자식 엔터티 간의 관계로 부모 엔터티가 없으면 자식 엔터티가 존재할수 없는 관계입니다. 관계를 삭제하면 자식 엔터티는 존재할 수 없게 됩니다. 자식 엔터티는 부모 엔터티에 존재 종속(Existence Dependency) 되므로 홀로 존재할 수 없습니다.

 

반면에 참조 관계(Referential Relationships)는 단지 어떤 엔터티와 연관성이 존재해서 관리하려는 관계일 뿐 상위(부모) 엔터티가 없다고 존재할 수 없는 관계는 아닙니다. 단순히 참조 데이터를 관리하므로 관계를 삭제하더라도 한 속성의 연관성을 모르게 될 뿐 하위(자식) 엔터티가 존재할 수 없는 것은 아닙니다

 

우리가 흔히 알고 있는 관계가 종속 관계입니다. 그리고 잘못 알고 있는 부분이 모든 관계는 종속 관계인 것처럼 알고 있다는 것입니다. 원서에서 Parent Entity, Child Entity라는 용어를 사용해서 이런 인식이 더욱 굳어진 거 같습니다.

 

하지만 대부분의 관계는 단지 참조 관계입니다. 관계가 엔터티 존재 자체와 연관되는 것이 아니라 속성 하나와 연관됩니다.

 

모델링의 모든 요소가 상호 밀접하게 연관돼 있는데 관계 또한 엔터티와 연관돼 있습니다. 엔터티 정의 자체가 완전하지 않으면 그 사이의 관계를 따진다는 것이 무의미해집니다. 관계를 도출하기 위해서는 엔터티가 명확하게 도출돼 있어야 합니다.

 

종속 관계냐 참조 관계냐를 따지는 것은 엔터티 정의와도 연관돼 있지만 식별 관계와 비식별 관계를 선택하는 기준이 되기 때문에 의미가 있습니다. 특히 종속 관계인지를 알기 위해서는 양쪽 엔터티 정의를 다시 한번 되새겨야 하기 때문에 의미가 있습니다.

 

다음에 예제를 사용해서 종속 관계와 참조 관계를 자세하게 알아보겠습니다.

 


'데이터 Story > 모델링 이론' 카테고리의 다른 글

관계선이 의미하는 것  (4) 2011.02.16
종속 관계와 참조 관계  (7) 2011.02.16
관계란?  (0) 2011.02.16
엔터티 도출 원칙 2  (1) 2011.02.16
엔터티 도출 원칙 1  (0) 2011.02.16
기준 엔터티란?  (0) 2011.02.16
블로그 이미지

블루퍼필

댓글을 달아 주세요

자립(Independent Entity 또는Strong Entity, Dominant Entity) 엔터티는 다른 엔터티에 의존적이지 않고 스스로 존재하는 엔터티라고 했습니다. 어떤 엔터티에도 존재 종속(Existence Dependency)되지 않는 엔터티입니다.

 

종속(Dependent Entity 또는Weak Entity, Subordinate Entity) 엔터티는 상위(부모) 엔터티가 존재하지 않으면 존재할 수 없는 엔터티입니다.

 

자립 엔터티와 종속 엔터티는 비즈니스에서 관리하는 데이터의 범위에 따라 자립 엔터티가 종속 엔터티가 될 수도 있고 종속 엔터티가 자립 엔터티가 될 수도 있습니다.

 

특정 대학의 교수 엔터티는 자립 엔터티입니다. 교수 엔터티 상위에 반드시 존재해야 할 엔터티가 존재하지 않습니다. 하지만 전국 대학의 교수를 관리한다면 교수 엔터티는 종속 엔터티가 될 수 있습니다.

 

대학에 소속된 교수를 관리하니 대학이 상위 엔터티에 존재해야 하고요. 주민번호가123456인 홍길동교수는 여러 대학에서 강의할 수 있으므로 주 식별자가 ‘대학번호+주민번호’와 같이 될 수 있습니다.

 

이 경우에도 실제 업무에 따라 주 식별자가 단순히 주민번호가 될 수도 있지만 종속 엔터티는 주로 상위 엔터티의 주 식별자를 식별자로 상속합니다. 반면에 자립 엔터티일 경우에는 상위 엔터티의 주 식별자를 식별자로 상속하면 잘못된 것입니다.

 

[그림1] 예제에서 고객 엔터티는 직업 엔터티의 종속 엔터티가 아닙니다. 직업 엔터티가 부모 엔터티인 것처럼 보이지만 직업 엔터티가 없어도 고객 엔터티는 존재할 수 있으므로 고객 엔터티는 종속 엔터티가 아니라 자립 엔터티입니다.


 

[그림1]

 

위와 같은 관계는 흔히 얘기하는 부모/자식 관계가 아니라 참조 관계(Referential Relationships)라고 합니다. 그래서 직업 엔터티의 주 식별자인 직업코드는 고객 엔터티에 주 식별자로 상속하지 않고 참조 데이터로서 일반 속성으로 관리합니다.

 

이렇게 직업 엔터티와 같이 참조되는 엔터티를 부모 엔터티라고 표현하지 않고 상위 엔터티라고 표현합니다. 존재 종속 관계가 있어야 부모 엔터티라고 표현하며 일반적으로 상위(부모) 엔터티라고 표현합니다.

 

단순히 참조 정보를 관리하는 관계와 부모 관계를 관리하는 관계는 구분해야 합니다. 이를 분명하게 구분하면 엔터티 정의와 주 식별자, 관계 정의, 식별자 상속 등과 같은 복잡한 문제가 풀리기도 합니다.

 

종속 엔터티는 부모 엔터티와 종속 관계가 있는 엔터티입니다. 이때 부모 엔터티의 인스턴스가 삭제되면 종속 엔터티의 인스턴트도 삭제해야 합니다. 존재 종속(Existence Dependency)됐기 때문에 생사를 같이 하게 됩니다.

 

많은 CASE 툴에서 자립 엔터티와 종속 엔터티를 달리 표현할 만큼 엔터티의 성격을 가름하는 요소 중의 하나이므로 엔터티를 정의할 때 주의해서 살펴야 합니다.



블로그 이미지

블루퍼필

댓글을 달아 주세요

  • 김상일 2013.11.05 17:06  댓글주소  수정/삭제  댓글쓰기

    안녕하세요. 글내용이 좋아 몇번씩 다시 읽고 있습니다.
    [그림1] 예제에서 직업 엔터티는 고객 엔터티의 종속 엔터티가 아닙니다.
    =>
    [그림1] 예제에서 고객 엔터티는 직업 엔터티의 종속 엔터티가 아닙니다.
    가 아닌지 문의 드립니다.