태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

엔터티에 속한 속성이 많을 때, 성능이나 관리 측면에서 좋지 않은 영향을 미친다면 일부 속성을 별도의 엔터티로 분리할 수 있다.

 

이때 속성 성격에 따른 분리가 아닌 사용 빈도에 따른 분리일 경우, 즉 유사한 성격의 속성으로 분리할 수 없고 자주 사용되는 않는 속성, 덜 중요한 속성으로 분리할 때는 엔터티 명을 상위 엔터티 명+상세(Suffix)’ 형식으로 정한다.

 

이런 속성으로 구성된 엔터티는 특별한 데이터 성격이 없기 때문에 엔터티 명을 정하기가 어렵다. 이때는 상위 엔터티 명에 상세라는 접미어를 붙어서 정한다.

 

[그림1] 고객 엔터티에 속성이 많아 일부 속성을 별도의 엔터티로 분리해야 한다고 가정한다.


[그림1]

 

엔터티를 속성 기준으로 수직 분리할 때는 유사한 성격의 속성을 분리하는 것이 바람직하지만 속성의 성격으로 분리하기 어려울 때는 [그림2] 고객상세 엔터티처럼 덜 자주 사용돼서 중요하지 않은 속성을 분리해서 설계한다.


[그림2]

 

결혼이나 직장, 학력과 같이 덜 사용되는 속성으로 구성됐기 때문에 엔터티의 성격이 있는 것은 아니어서 엔터티 명을 정하기 애매하며, 고객 엔터티가 이미 존재하기 때문에 구분하기 위해 상위 엔터티인 고객에 접미어 상세를 붙인다.

 

이렇게 분리하면 고객 엔터티에는 자주 사용되는 속성이 존재하며, 고객상세 엔터티에는 자주 사용되지 않는 속성이 존재한다.

 

엔터티 명을 정하는 기준은 데이터의 성격이다. 데이터의 본질적 성격을 나타내야 한다. 하지만 자주 사용하지 않는 것은 데이터의 성격을 나타내는 것이 아니기 때문에 이런 속성으로 구성된 엔터티는 엔터티 명을 정하는 기준이 없는 것이다. 따라서 데이터 성격이 나타나지 않는 경우에는 엔터티 명을 정하기가 곤란해진다. 그래서 부득이하게 상세라는 접미어를 정해 이런 경우에 사용한다.

 

또한 고객 엔터티와 같은 주요 엔터티는 자주 사용되는 속성만으로 구성하는 것이 바람직하다. 가끔 사용되는 속성이나 널(Null) 값이 대부분인 속성은 원 엔터티에서 제외시키는 게 효과적이다.

 

물론 중요한 속성만을 사용하는 것이 아니고 전체 속성 위주로 사용한다면 굳이 엔터티를 분리할 이유는 없다. 적절한 이유 없이 엔터티가 많은 것은 바람직하지 않다.

 

주의할 것은 고객상세 엔터티에 자주 사용되지 않는다는 이유로 고객의 본질을 나타내는 기초 속성을 옮기면 안 된다는 것이다.

 

또한 분리한 속성이 특정 성격을 나타낸다면 해당 데이터 성격에 맞게 엔터티 명을 정해야 한다. 특정 성격의 데이터인데도 불구하고 데이터 성격을 표현하지 않고 ‘~상세접미어를 붙이면 안 된다.

 

[그림2] 고객상세 엔터티처럼 엔터티 명을 특정하게 정할 수 없을 때만 어쩔 수 없이 상세접미어를 붙여 고객 정보라는 정도만을 알 수 있도록 한다.



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

배타 서브타입 설계  (0) 2017.02.16
실체 엔터티 설계  (0) 2016.12.29
종속 엔터티의 엔터티 명  (0) 2016.12.08
기준 엔터티의 엔터티 명  (0) 2016.12.01
역할 엔터티의 엔터티 명  (0) 2016.11.18
소속 엔터티의 엔터티 명  (0) 2016.11.05
블로그 이미지

블루퍼필

댓글을 달아 주세요

식별(Identifying) 관계와 비식별(Non-Identifying) 관계는 단순한 개념입니다. 언제 적용해야 하는지를 결정하기가 어렵죠.

 

상위 엔터티의 주 식별자가 하위 엔터티에 주 식별자로 상속되면 식별(Identifying) 관계입니다. 엄밀히 말해 종속 엔터티와 무관합니다.

 

하지만 부모 엔터티에 존재 종속(Existence Dependency)된 종속 엔터티는 대부분 식별 관계로 상속받습니다. 이 원칙은 지켜주는 게 좋습니다. 두 엔터티가 관계가 있고 하위 엔터티가 종속 엔터티라는 것이 분명하다면, 식별 관계로 상속 받는 것이 좋습니다.

 

문제는 예외인데요. 나중에 설명하겠지만 업무 식별자를 주 식별자로 채택하는 것을 원칙으로 불가피할 경우 인조 식별자를 채택해야 하는데요. 인조 식별자를 사용해야 하는 대표적인 때가 주 식별자가 복잡할 때입니다.

 

[그림1] 고객주소 엔터티는 종속 엔터티입니다. 주 식별자는 상속받은 부모 엔터티의 주 식별자(고객번호)에 부분 주 식별자(주소순번)를 추가해 만듭니다.


 

[그림1]

 

[그림2]는 고객주소 엔터티와 관계가 존재하는 모델입니다. 집주소와 회사주소를 관리하기 위해 관계선이 2개가 필요합니다. 조금 복잡해 보이죠. 이 정도면 그렇게 복잡한 것은 아니지만 여러 단점이 존재할 수 있습니다.


 

[그림2]

 

위 모델이 단점이 있다고 가정하면 고객주소 엔터티의 주 식별자를 인조 식별자로 사용해야 하는데요. [그림3]과 같이요.


 

[그림3]

 

단순하게 판단할 문제는 아니지만 일반적으로 [그림2] 보다는 [그림3]이 단순한 모델이고, 단순한 모델이 좋은 모델이 될 가능성이 큽니다.

 

[그림3]과 같을 때 고객주소 엔터티는 [그림4]와 같이 비식별 관계가 됩니다. 업무 식별자에 해당하는 고객번호+주소순번 대신 인조 식별자인 주소번호를 사용한 거죠.


 

[그림4]

 

종속 엔터티라고 반드시 식별(Identifying) 관계로 상속받는 것은 아닙니다. 비식별 관계로 상속받을 때가 간혹 있습니다.

하지만 반대의 경우는 매우 드물 거 같습니다. 참조 엔터티인데 식별 관계로 상속 받는 것은 일반적으로 잘못된 모델 같습니다.




블로그 이미지

블루퍼필

댓글을 달아 주세요

  • 2012.01.13 14:14  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

    • 블루퍼필 2012.01.14 11:46 신고  댓글주소  수정/삭제

      예.. 안녕하세요.

      [그림3]과 같이 사용하는 이유는 [그림2]의 원장발송 엔터티의 관계 속성이 복잡하기 때문입니다.

      [그림2]는 간략하게 표현한 것인데 실무에서는 훨씬 복잡해서 제대로 관리가 안 될 때가 많습니다.

      예제로는 이해하기 힘드실 수 있으니, 실무에서는 항상 염두에 두고 생각해보는 습관을 가지시면 좋을 거 같습니다.

      열공하세요.

  • 2012.01.16 09:31  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

    • 블루퍼필 2012.01.16 09:43 신고  댓글주소  수정/삭제

      그림2에서 관계선은 2개입니다.
      원장발송 엔터티에서 고객의 집주소도 관리하고 회사주소도 관리하니까요.

      아래 정도의 구분이 될 거 같은데요.
      create table 원장발송2
      (
      원장발송번호 int identity primary key,
      발송일자 smalldatetime not null,
      고객번호1 int not null,
      고객주소순번1 tinyint not null,
      고객번호2 int not null,
      고객주소순번2 tinyint not null,
      constraint fk_원장발송2_고객주소2 foreign key (고객번호1,고객주소순번1) references 고객주소2(고객번호, 고객주소순번),
      constraint fk_원장발송2_고객주소2_2 foreign key (고객번호2,고객주소순번2) references 고객주소2(고객번호, 고객주소순번)
      )

  • 2012.01.16 10:18  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

종속 엔터티에는 몇 가지 종류가 있습니다.

 

- [그림1] 부모 엔터티의 추가 데이터를 관리하는 엔터티

- [그림2] 1정규화에 의해서 발생한 엔터티

- [그림3] 이력 데이터를 관리하는 엔터티

- [그림4] 다대다(M:M) 관계에서 발생한 교차 엔터티

- [그림5] 슈퍼타입과 관계된 서브타입 엔터티

- [그림6] 엔터티 분해에 의한 일대일(1:1) 엔터티

 

[그림1]의 상품가격 엔터티는 상품 엔터티의 일부 데이터를 더욱 상세하게 관리하는 엔터티입니다. 상품 가격은 상품이 존재하지 않는 한 존재할 수 없는 데이터이므로 상품가격 엔터티는 종속 엔터티입니다. 부모 엔터티의 일부로서 성격이 동일한 데이터라고 할 수 있습니다.


 

[그림1]

 

[그림2] 주문상품 엔터티는1정규화에 의해서 발생한 엔터티입니다. 주문상품 엔터티는 비정규화를 하면 주문 엔터티에 합쳐지기도 하는 엔터티로 주문 엔터티가 없이는 존재할 수 없습니다.


 

[그림2]

 

[그림3]은 이력 데이터를 관리하는 예제입니다. 상품가격이력 엔터티는 상품 가격에 대한 변경 데이터를 관리하기 때문에 원 엔터티인 상품 엔터티 없이는 존재할 수 없습니다.


 

[그림3]

 

위와 같이 부모 엔터티와 종속 엔터티의 관계가 일대다(1:M)일 때는 보통 부모 엔터티의 주 식별자를 종속 엔터티의 식별자로서 상속합니다. 그리고 종속 엔터티 자체의 식별자인 부분 주 식별자(Partial Primary Identifier)가 추가됩니다.

 

[그림4]는 다대다(M:M) 관계에서 발생한 엔터티로, 다대다 관계가 두 개의 일대다(1:M) 관계로 표현되면서 종속 엔터티가 생깁니다. 이를 교차 엔터티(Association Entity, Relationship Entity, Intersection Entity)라고 합니다. 교차 엔터티에 대해서는 별도로 자세하게 설명하겠습니다.


 

[그림4]

 

[그림5] 모델은 슈퍼타입과 서브타입의 관계를 나타냅니다. 서브타입인 법인고객·개인고객은 슈퍼타입은 고객에 종속된 엔터티입니다. 슈퍼타입의 종류에 따라 반대일 수도 있는데 서브타입도 별도로 설명하겠습니다.


 

[그림5]

 

[그림6]은 성능이나 관리 상의 이유로 속성을 분할해서 관리하는, 즉 엔터티를 수직 분해한 예제입니다.


 

[그림6]

 

이상으로 종속 엔터티가 발생하는 예를 간략하게 설명했습니다. 이런 유형을 생각하면 종속 엔터티가 어떤 엔터티인지 더 명확해질 것입니다.


블로그 이미지

블루퍼필

댓글을 달아 주세요

  • 혈기린 2011.06.02 17:30  댓글주소  수정/삭제  댓글쓰기

    그림1도 그림3과 마찬가지로 이력을 관리하는것이 아닐까요?
    부모엔티티의 추가데이타를 관리하는것도 어찌 보면 1정규형과맥락을 같이 하는것은아닌가요?
    아니면 이력과 내역의 차이일까요? 이력관리는 어렵네요 -.-; 종속엔티티를 이렇게 분류하여 설명하니 더 쉽게 이해가 되네요 감사합니다.

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

      오랜만입니다. 반갑네요..

      종속 엔터티를 설명하는데 이력 관리를 물으시니 더 헷갈리네요. 그렇지 않아도 헷갈리는데요.

      상품가격 엔터티는 내역 데이터입니다. 아직까지 제 기준으로는요.

      하지만 이력 설계 방법에 포함시켰는데.. 아래 글을 참조해보세요. 고민이 있습니다..

      http://dataprofessional.tistory.com/60

      1정규형에 대한 논란도 많은데요. 모든 속성을 하나의 인스턴스에 관리하는 게 가능은 하므로 [그림1]이 반복되는 상품가격 속성을 별도의 엔터티로 1정규화했다고 볼 수 있습니다.

      반복속성을 어떻게 보느냐에 대한 논란이 있습니다. 좀 더 고민할 부분입니다.

      계속 좋은 의견 기대하겠습니다. ㅎ

자립(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] 예제에서 고객 엔터티는 직업 엔터티의 종속 엔터티가 아닙니다.
    가 아닌지 문의 드립니다.

엔터티를 구분하는 방법은 여러 가지가 있습니다.
 
뭔가를 분류하는 것은 그것을 이해하는 데 보통 도움을 줍니다.
저는 다음과 같이 엔터티를 분류합니다.
-
 
- 만질 수 있는 것 & 만질 수 없고 개념으로 존재하는 것
-- 자립 엔터티 & 종속 엔터티
-- 실체 엔터티 & 행위 엔터티 & 가공 엔터티 & 기준 엔터티
 
다각도로 분류해 보는 것이 좋기 때문에 분류법도 다양합니다.
 
엔터티를 정의할 가장 우선적으로 판단하는 것은 보이는 물체냐라는 것입니다.
사람, 사물과 같이 실제로 존재하는 물건인지, 만져서 느낄 수 있는지부터 따져보게 됩니다.
 
이런 성격의 엔터티는 계약서나 카드, 통장 등을 포함시킨다고 해도 실제로 그다지 많지는 않습니다.
그보다 개념으로 존재하는 것(Conceptual)을 표현한 데이터가 훨씬 많습니다.
행위는 다소 애매하지만 물체나 실상은 아니며 개념과 비슷할 거 같습니다.
 
어쨌든 만질 수 있는지부터 따져보면 약간 도움이 됩니다.
 
또 다른 측면에서의 분류에는 자립 엔터티와 종속 엔터티가 있습니다.
자립 엔터티(Independent Entity)는 다른 엔터티에 의존적이지 않고 스스로 존재하는 엔터티입니다.
종속 엔터티(Dependent Entity)는 상위(부모) 엔터티가 존재하지 않으면 존재할 수 없는 엔터티입니다.
 
존재 종속(Existence Dependency)도 중요한 개념입니다.
엔터티 B가 존재하려면 엔터티 A가 반드시 존재해야 하면 B는 A에 존재 종속(Existence Dependency)됐다고 합니다.
이때 엔터티 B는 분명 종속 엔터티입니다. 반면에 엔터티 A는 자립 엔터티일 수도 있고 종속 엔터티일 수도 있습니다.
 
자립 엔터티와 종속 엔터티에 대한 자세한 설명은 다음에 하겠는데요.
자립 엔터티인지, 다른 어떤 엔터티엔가 존재 종속된 종속 엔터티인지를 판별하는 것은 대단히 중요합니다.
 
‘만질 수 있냐 없냐’로 간단히 성격을 판단하고 ‘데이터가 자립했는지 아닌지’를 심도 있게 판단해야 합니다.
여기까지 분석되면 엔터티 정의하기가 수월해집니다.
 
마지막 분류인 실체, 행위, 가공, 기준 엔터티로 구분하는 것은 일반적으로 많이 알려진 분류법입니다.
핵심, 행위, 목적 등으로 분류할 수도 있고요.
 
엔터티가 어디에 속하는지를 고민해보는 것은 엔터티를 정의하는 데 도움이 됩니다.
엔터티를 정의할 때 위와 같은 다양한 분류법으로 분석을 해보는 것이 좋습니다.
어떤 분류에 속한다는 것을 선언하는 것이 중요한 게 아니라 단지 어떤 데이터인지를 잘 분석하기 위해서요.
 
흔히 데이터 구조가 중요하다는 말을 많이 합니다.
유연해서 확장성도 좋은 구조, 견고해서 흔들리지 않는 구조를 만들어야 하는데요.
 
이런 구조가 되려면 엔터티 정의가 제대로 이루어져야 합니다.
엔터티를 구성한 데이터의 성격이 바뀌지 않는 한 엔터티 정의가 바뀌면 안 됩니다.
 
종속 엔터티인데 자립 엔터티로 잘못 정의하거나 실체 엔터티인데 행위 엔터티로 잘못 정의하면 데이터 구조가 튼튼할 수 없습니다.
데이터의 성격만을 판단해 엔터티를 정확히 정의하는 것이 모델링의 시발점입니다. 


블로그 이미지

블루퍼필

댓글을 달아 주세요

  • 혈기린 2011.06.02 17:07  댓글주소  수정/삭제  댓글쓰기

    엔티티를 만질수 있는것과 개념적으로 존재하는것을 엔모회사 세미나 참석했들때 물리적 집합과 논리적 집합으로 설명을 하더군요 이화식씨 말로는 물리적 집합으로 논리적집합을 도출하는데 이 논리적 집합을 잘 도출하는 사람이 훌륭한 모델러라고 하더군요
    역시 모델링에서 가장 도출하기 힘든게 아마도 엔티티 일거 같네요

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

      모델링에서 관계가 가장 중요하다는 사람이 다수인데요..

      저는 엔터티가 가장 중요하고, 가장 어려운 분야라고 생각합니다.

      엔터티를 얼마나 정확히 도출(정의)하느냐가 좋은 모델러의 기준이라고 확신합니다.