by-nc-sa     개발자, DBA가 함께 만들어가는 구루비 지식창고!

관계와 속성 그리고 엔터티




10.2 관계와 속성 그리고 엔터티

상위 엔터티의 주 식별자가 하위엔터티의 속성으로 관리될 때만 관계를 표현한다.
하위엔터티 속성의 데이터는 상위 엔터티의 속성(주식별자)에 데이터로서 존재해야 한다.

  • 어떤 사원에 대해서는 부서를 모른다는 것을 의미
  • 잘못된 값이 입력되지 못하도록 하는 것이 참조 무결성(Referential Integrity)제약
  • 만약 사원이 존재하려면 부서가 반드시 선행으로 존재해야 한다는 업무규칙이 있따면 두 엔터티의 관계는 종속관계(Dependent Relationships)
  • 그림[10.7][그림 10.9]에서 관계선의 이름은 '현재근무부서'이지만 실질적으로 중요한 것은 사원 엔터티의 현재근무부서번호(FK)속성이다.
  • 계좌 엔터티에서 관리할 속성 중에 계좌 개설을 권유한 사원, 계좌를 관리하는 사원, 실적을 받는 사원을 관리하는 속성이 존재
  • 각사원은 상위 엔터티의 주 식별자인 사원번호와 연관돼 각 사원의 의미에 맞도록 속성명이 정해지며 [그림 10.10]모델과 같이 속성명과 연관된 관계명이 정해지게 된다.
  • 보험계약에 계약자와 피보험자, 연대보증인을 관리한다는 단순 요건이 존재할 때의 모델
  • 계약자는 한명이지만 피보험자와 연대보증인은 여러명일수 있다는 요건이 생기면 모델은 달라진다.
  • 피보험자는 2명까지 생길 수 있고 연대보증인은 3명까지 생길수 있다는 요건
  • [그림 10.12]와 같이 많은 관계선과 속성으로 관리하기 어렵다면 보험계약당사자 엔터티를 생성해서 보험계약과 관련된 모든 고객을 관리한다.
  • 보험계약당사사엔터티 = 관계엔터티
  • [그럼 10.14]과 같이 계약자는 보험계약 엔터티에서 별도로 관리할 수 있다. 동시에 보험계약당사자 엔터티에서 계약자를 관리하지 않게 된다.
  • 확장성을 감안해서 이미 다수 관계가 존재하고 지속적으로 늘어날 가능성이 크면 관계 엔터티를 채택하는 것이 효율적
  • [그림10.12]처럼 관계를 속성으로 관리하다 보험료 납부자나 공동 계약자 같은 다른 관계가 추가되면 수정하기 쉽지않다.
  • 관계 엔터티로 관리하면 보험료 납부자가 추가돼도 당사자 구분(코드값)만 추가해 인스턴스나 생성시키면된다.
  • 성능이슈가 없다면 확장성 등을 고려해 보험계약당사자 엔터티를 사용하는 것이 효율적
  • 유효기간을 추가해서 이력 데이터까지 관리 가능
  • 관계 엔터티도 고유의 속성을 가지게 될 때가 있다. 계약자의 신용정보 활용에 대한 동의 데이터를 보험계약별로 관리할 수 있다.
    연대보증인에 대해서는 책임 금액을 관리할 수도 있다. 이렇게 관계 엔터티에서 관계만을 관리하는 것이 아니라 속성도 관리할 수 있다.
  • 고유속성 이외도중복 성격의 시점 데이터를 관리할 수 있다.
  • 고객 엔터티에 고객 이름이 존재하지만 [그림 10.17]과 같이 보험 계약 당사자 엔터티에서 계약 시점의 이름을 관리할 수 있다.
  • 고객이력 엔터티에서 고객 데이터를 이력 관리하면 보험계약당사자 엔터티의 고객명은 중복 속성이다.
  • 보험계약 당사자의 계약 당시의 이름이 자주 사용되면 중복속성을 채택하는 비정규형은 필요할 수 있다.
  • 다수의 관계속성으로 관리하는방법과 하나의 관계엔터티로 관리하는 방법은 1정규화와 동일한 개념
  • 반복되는 속성은 1:M관계의 새로운 엔티티를 추가하는 것이 1정규화

문서정보

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.