본문 바로가기
데이터 모델링/모델링 노트 - 관계형 데이터 모델링

1. 엔터티 이야기 (4)

by Toddler_AD 2024. 11. 21.

1.7. 종속 엔터티의 종류

  • 종속 엔터티는 참조 엔터티에 비하면 그다지 많지 않지만, 아래와 같은 다양한 경우에 발생한다.
    •  부모 엔터티의 부가 데이터를 관리하는 엔터티
    • 1정규화에 의해서 발생한 엔터티
    • 이력 데이터를 관리하는 엔터티
    • 다대다 관계에서 발생한 교차 엔터티
    • 슈퍼타입에 대한 서브타입 엔터티
    • 엔터티 분류에 의한 일대일 관계의 엔터티
  • 부모 엔터티의 부가 데이터를 관리하는 엔터티

부가 데이터를 관리하는 종속 엔터티

  • 모델의 상품 가격 엔터티는 상품 엔터티의 일부 데이터를 더욱 상세하게 관리하는 엔터티다.
    • 상품가격은 상품 없이는 존재할 수 없는 데이터이므로, 상품가격 엔터티는 상품 엔터티의 종속 엔터티다.
    • 부모 엔터티의 일부로서 성격이 동일한 데이터라고 할 수 있다.
  • 부모 엔터티의 주 식별자는 보통 종속 엔터티의 식별자로서 상속된다.
    • 그리고, 상속된 식별자와 결합하여 종속 엔터티의 주 식별자 역할을 하는 속성이 추가 된다.
    • [그림1] 상품 가격 엔터티의 기준일자 속성이 이에 해당되는데, 이를 부분 주 식별자(Partial Primary Identifier)라고 한다.

  • 1정규화에 의해서 발생한 엔터티

1정규화에 의한 종속 엔터티

  • [그림2] 주문상품 엔터티는 1정규화에 의해서 발생한 엔터티다.
    • 주문상품 엔터티는 주문에 속한 상품을 관리하는 엔터티로, 주문 엔터티 없이는 존재할 수 없는 종속 엔터티다.

  • 이력 데이터를 관리하는 엔터티

이력 엔터티인 종속 엔터티

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

  • 다대다 관계에서 발생한 교차 엔터티

교차 엔터티인 종속 엔터티

  • [그림4] 주문상품 엔터티는 주문 엔터티와 상품 엔터티 간의 M:N(다대다) 관계에서 발생한 엔터티다.
    • M:N(다대다) 관계는 보통 두 개의 1:M(일대다) 관계로 표현되면서 종속 엔터티가 생긴다.
    • 이를 교차 엔터티(Association Entity, Relationship Entity, Intersection Entity)라고 한다.

  • 슈퍼타입에 대한 서브타입 엔터티

서브타입인 종속 엔터티

  • [그림5] 모델은 슈퍼타입/서브타입 모델을 물리 모델로 변환한 모델이다.
    • 서브타입인 개인고객, 법인고객 엔터티는 슈퍼타입인 고개 엔터티에 종속된 엔터티다.

  • 엔터티 분해에 의한 일대일 관계의 엔터티

일대일 관계의 종속 엔터티

  • [그림6] 모델은 성능이나 관리상의 이유로 속성을 나눠서 관리하는, 즉 엔터티를 수직 분해한 모델이다.
    • [그림6] 모델은 원래 같은 엔터티인데 1:1로 나눈 것이므로, 다시 합쳐도 아무 문제가 되지 않는다.
    • 고객상에 엔터티는 고객 엔터티가 없다면 존재할 수 없는 엔터티로 고객 엔터티에 종속된 엔터티다.
  • 이상으로 종속엔터티가 발생하는 이유를 간략하게 설명했다.
  • 위의 유형을 생각하면 종속 엔터티가 어떤 엔터티인지 더 명확해질 것이다.

 

1.8. 모델(ERD)과 메타 시스템의 속성 설명

  • 최근에는 엔터티와 속성 정보를 메타 시스템에서 관리한다.
    • 메타 데이터(Meta Data)를 관리하는 메타 시스템에는 엔터티를 관리하는 엔터티와 속성을 관리하는 엔터티가 필요할 것이다.
    • CASE 툴에서 설계한 ERD를 데이터로 관리할 때도, 엔터티와 속성을 관리하는 엔터티가 필요할 것이다.
    • 이는 종속 엔터티와 연관된다.

[그림 1.9] 종속 엔터티인 속성 엔터티

  • [그림 1.9] 모델에서 속성 엔터티는 종속 엔터티다.
    • 속성 엔터티는 엔터티 번호 속성을 식별 관계로 상속받아서 엔터티에 대한 속성을 관리한다.
    • 그 속성의 이름과 설명, 엔터티 내에서의 순서 등을 관리하는 엔터티다.
    • 속성은 엔터티에 속하기 때문에 [그림 1.9]는 당연한 모델처럼 보인다.
    • 하지만, 속성 자체도 독립된 데이터가 될 수 있어 [그림 1.10] 모델과 같이 설계할 수 있다.

[그림 1.10 교차(관계) 엔터티

  • [그림 1.10] 모델은 엔터티와 속성을 개별적인 독립 실체로 보고 각자 엔터티에서 관리한다.
    • 그리고, 교차(관계)엔터티를 통해 엔터티에 속한 속성을 관리한다. 엔터티속성관계 엔터티에서 주의할 속성은 속성순서 속성이다.
    • 엔터티 내에서 해당 속성이 위치한 순서를 의미하기 때문에 엔터티속성관계 엔터티에 존재한다.
    • 이 모델에서 속성은 엔터티에 존재 종속된 것이 아니라 연관성이 존재하는 것이다. 
    • 즉, 식별 관계가 아니라 단지 관계가 존재하는 것이다.
      • 물론, 엔터티, 속성 엔터티, 엔터티속성관계 엔터티는 종속 관계이다.
  • 엔터티에 속한 속성을 [그림 1.9] 모델에서는 종속 엔터티로 설계했고, [그림 1.10] 모델에서는 자립 엔터티로 설계했다.
    • [그림 1.9] 속성 엔터티는 엔터티가 기준이 되는 속성을 관리한다.
    • 속성 명이나 속성 설명은 해당 엔터티 내에서의 이름과 설명이다.
    • 혹 다른 엔터티에 이름이 같은 속성이 있더라도, 속성 설명은 달라질 수 있다는 것을 의미한다.
  • 속성 순서 역시 해당 엔터티 내에서의 속성의 위치를 나타낸다.
    • 반면에, [그림1.10] 모델은 엔터티와 속성을 개별적으로 설계하고, 엔터티에 소속된 속성은 둘 사이의 관계로서 설계한다.
    • 따라서, 속성 설명은 속성 엔터티에서 정의한 대로 사용하게 된다.
  • [그림 1.9] 모델은 CASE 툴에서 설계한 ERD를 데이터로 관리할 때 사용할 수 있는 모델이다.
    • ERD 내에서 속성이 개별적으로 분리된 CASE 툴은 없고(있긴 하나 궁극적으로는 엔터티에 속성이 포함되는 것이므로 없는 것과 마찬가지다.),
    • 엔터티를 그린 후에 그 속에 속성을 메타 시스템에서는 속성이 ERD 처럼 사용되지 않는다.
  • 메타 시스템에는 속성을 표준화하여 먼저 등록한다.
    • 이렇게 표준화한 속성은 여러 엔터티에서 사용된다.
    • 엔터티를 기준으로 엔터티에 속한 속성을 등록하는 것이 아니라, 
    • 엔터티와 무관한 속성을 등록한다.
    • 속성 자체가 하나의 개체(실체)이기 때문이다.
  • 이와 같을 때, 속성 설명은 [그림 1.9]와 [그림 1.10] 모델에서 서로 다른 역할을 한다.
    • 메타 시스템에서 속성을 등록할 때 기술한 속성 설명은 대표적인 의미가 있고, 
    • ERD에서 사용하는 속성 설명은 엔터티의 개별적인 의미가 있다.
    • 즉, 둘다 나름의 의미가 있다.
  • 이처럼 메타 시스템과 ERD에 존재하는 속성 설명은 서로 의미가 다르다.
    • 하나는 일반화된 표준 설명이고, 하나는 개별적으로 특화된 설명이다.
    • 후자가 더욱 중요할 수 있다.
    • 따라서, ERD에 존재하는 속성의 설명 대신 메타 시스템에 등록한 표준 속성의 설명을 사용하는 것은 바람직하지 않다.
    • ERD에 존재하는 속성 설명은 해당 엔터티의 속성에만 고유한 설명이기 때문이다.
  • 실무에서 속성 설명을 어떻게 관리할지에 대한 혼란이 있다.
    • ERD의 속성 설명을 중요하게 생각한다면,
    • 표준 속성을 등록하면서 그에 대한 정의를 적는 것에 큰 의미를 두지 않아도 괜찮다.
    • 하지만, 표준 속성을 먼저 등록하고 ERD에 그것을 차용하는 개념이기 때문에 일반적인 속성 설명은 필요할 것이다.
    • 표준은 기준을 의미하기도 하고, 토대가 되기도 한다.
    • 다만, 메타 시스템의 속성 설명보다는 ERD의 속성 설명이 더욱 의미가 있다는 것을 간과하면 안 된다.