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

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

그림 10.7

• 어떤 사원에 대해서는 부서를 모른다는 것을 의미
• 잘못된 값이 입력되지 못하도록 하는 것이 참조 무결성(Referential Integrity)제약

그림 10.9

• 만약 사원이 존재하려면 부서가 반드시 선행으로 존재해야 한다는 업무규칙이 있따면 두 엔터티의 관계는 종속관계(Dependent Relationships)
• 그림 10.7과 그림 10.9에서 관계선의 이름은 '현재근무부서'이지만 실질적으로 중요한 것은 사원 엔터티의 현재근무부서번호(FK)속성이다.

그림 10.10

• 계좌 엔터티에서 관리할 속성 중에 계좌 개설을 권유한 사원, 계좌를 관리하는 사원, 실적을 받는 사원을 관리하는 속성이 존재
• 각사원은 상위 엔터티의 주 식별자인 사원번호와 연관돼 각 사원의 의미에 맞도록 속성명이 정해지며 그림 10.10모델과 같이 속성명과 연관된 관계명이 정해지게 된다.

그림 10.11

• 보험계약에 계약자와 피보험자, 연대보증인을 관리한다는 단순 요건이 존재할 때의 모델
• 계약자는 한명이지만 피보험자와 연대보증인은 여러명일수 있다는 요건이 생기면 모델은 달라진다.

그림 10.12

• 피보험자는 2명까지 생길 수 있고 연대보증인은 3명까지 생길수 있다는 요건

그림 10.13

• 그림 10.12와 같이 많은 관계선과 속성으로 관리하기 어렵다면 보험계약당사자 엔터티를 생성해서 보험계약과 관련된 모든 고객을 관리한다.
• 보험계약당사사엔터티 = 관계엔터티

그림 10.14

• 그럼 10.14과 같이 계약자는 보험계약 엔터티에서 별도로 관리할 수 있다. 동시에 보험계약당사자 엔터티에서 계약자를 관리하지 않게 된다.|
• 확장성을 감안해서 이미 다수 관계가 존재하고 지속적으로 늘어날 가능성이 크면 관계 엔터티를 채택하는 것이 효율적
• 그림10.12처럼 관계를 속성으로 관리하다 보험료 납부자나 공동 계약자 같은 다른 관계가 추가되면 수정하기 쉽지않다.
• 관계 엔터티로 관리하면 보험료 납부자가 추가돼도 당사자 구분(코드값)만 추가해 인스턴스나 생성시키면된다.
• 성능이슈가 없다면 확장성 등을 고려해 보험계약당사자 엔터티를 사용하는 것이 효율적

그림 10.15

• 유효기간을 추가해서 이력 데이터까지 관리 가능

그림 10.16

• 관계 엔터티도 고유의 속성을 가지게 될 때가 있다. 계약자의 신용정보 활용에 대한 동의 데이터를 보험계약별로 관리할 수 있다.
• 연대보증인에 대해서는 책임 금액을 관리할 수도 있다. 이렇게 관계 엔터티에서 관계만을 관리하는 것이 아니라 속성도 관리할 수 있다.

그림 10.17

• 고유속성 이외도중복 성격의 시점 데이터를 관리할 수 있다.
• 고객 엔터티에 고객 이름이 존재하지만 그림 10.17과 같이 보험 계약 당사자 엔터티에서 계약 시점의 이름을 관리할 수 있다.
• 고객이력 엔터티에서 고객 데이터를 이력 관리하면 보험계약당사자 엔터티의 고객명은 중복 속성이다.
• 보험계약 당사자의 계약 당시의 이름이 자주 사용되면 중복속성을 채택하는 비정규형은 필요할 수 있다.

그림 10.18

• 다수의 관계속성으로 관리하는방법과 하나의 관계엔터티로 관리하는 방법은 1정규화와 동일한 개념
• 반복되는 속성은 1:M관계의 새로운 엔티티를 추가하는 것이 1정규화

그림 10.19