[데이터베이스] 5. 다양한 관계 (동일 엔티티 셋 내 관계, 약개체, ISA 계층, 집단화)

같은 엔티티 집합 속 다른 역할 관계

 

엔티티가 관계를 맺을 때는 꼭 다른 엔티티 셋에 있는 엔티티끼리 관계를 맺지 않아도 괜찮다.

이 그림은 같은 employees 엔티티 셋 안에서 상사와 부하 직원 사이의 보고(reports to) 관계를 나타낸다.

이때 '보고 관계' 테이블에는 누가 상사이고 누가 부하직원인지 역할(role)을 명시해야하므로, 두 employees 의 ssn을 각각 상급자의 ssn, 부하직원의 ssn으로 재정의한 어트리뷰트를 갖는다.

 

 

약개체 (Weak Entities)

약개체는 관계를 맺고 있는 다른 엔티티(소유자 엔티티)의 PK에 의해서만 식별이 가능한 엔티티를 말한다.

이때 소유자 엔티티와 약개체는 반드시 1:N 관계를 가지며, 약개체는 그 관계에 대해 전체 참여해야 한다.

 

 

이 그림을 예시로 살펴보자.

직원(employees)이 자신의 부양 가족(dependents)을 위해 보험 증권을 구매할 수 있다고 할 때,

각 보험 증권이 어떤 피부양자를 보장하는지 보험 증권에 대한 데이터를 저장하려고 한다.

 

이때 보장을 받는 부양가족들은 특정 직원이 퇴사하면 보장 혜택 역시 같이 사라지게 되므로, 데이터베이스에서 함께 지워져야 한다.

이때 특정 직원의 부양가족들은 서로 다른 이름을 가질 수 있으므로 부양 가족을 식별하기 위해 이름을 식별자로 선택할 수 있다.

그래서 부양가족에 대한 엔티티를 위와 같이 pname, age 속성을 갖도록 설계했다고 해보자.

 

그런데 pname은 부양가족 엔티티 하나를 유일하게 식별하지 않는다. (다른 직원의 부양 가족 중에도 동일한 이름이 있을 수 있기 때문이다.) 이렇게 약개체는 자신의 엔티티를 식별할 수 있는 키를 갖지 않는다.

그 약개체와 관계를 맺는 엔티티가 있어야지만 비로소 유일하게 식별이 가능하다.

 

이 그림에서는 직원의 키인 ssn 과 약개체의 이름 pname 이 있을 때 비로소 하나의 약개체 엔티티가 식별된다.

그리고 pname과 같이 소유자 엔티티의 키가 주어져있을 때, 그 소유자의 키와 연관된 약개체 부분 집합 내에서 약개체 하나를 식별할 수 있는 속성을 부분키(partial key) 라고 부른다. 위 그림처럼 부분키는 점선으로 밑줄을 긋는다.

 

그리고 dependents가 약개체이고, policy 관계가 그 관계를 통해 약개체 하나를 유일하게 식별한다는 점을 강조하기 위해 관계를 나타내는 policy도 굵은선으로 표현한다.

 

테이블로 약개체를 구현할 때는 dependents는 별도의 테이블을 갖지 않고, policy 테이블에 함께 포함되어 존재한다.

이때 empolyees는 별도 테이블에 분리가 되어있고, policy테이블은 ssn을 FK로 갖는다.

만약 empolyees도 policy 테이블에 모든 데이터를 넣으면 어떻게 될까?

 

이렇게 구성하면 policy와 '관계' 를 맺는 것이 아니게 되고, 테이블에 null 값이 너무 많이 들어가는 문제가 있다.

(employees와 policy가 관계를 맺는데 부양가족은 없는 경우, 부양가족 관련 필드가 모두 null 이 될 것이다.)

 

 

 

ISA 계층 (클래스 계층)

 

위 그림과 같은 상황을 보자.

직원을 크게 시간제로 월급을 주는 비정규직 직원과, 정규직 직원으로 구분한다고 해보자.

이때 두 직원 모두 공통적으로 ssn, name, lot 필드를 갖는다.

 

이런 경우, 두 직원에 대한 공통 속성을 하나의 엔티티 집합으로 묶어서 슈퍼 클래스로 보낼 수 있다.

이렇게 한 엔티티 집합에 속한 엔티티들을 서브 클래스로 분리하는 경우, Hourly_Emps 는 Employees 를 상속한다고 말한다.

그리고 영어로는 Hourly_Emps ISA (is a) Employees 라고 말한다.

결국 이 ISA 관계를 사용하는 이유도, 모든 속성을 하나의 엔티티셋에 포함하다보면 불필요한 null 값을 많이 갖게 되기 때문에 그렇다.

 

ISA 관계에서는 두 가지 제약 조건을 고려할 수 있다.

 

1. Overlap constraints (중첩 제약조건)

어떤 직원이 Hourly_Emps 에 속하면서, 동시에 Contract_Emps 에도 속할 수 있는지, 중첩에 대한 제약 조건이다.

이런 제약 조건이 명시되어 있지 않다면, 일반적으로는 중첩되어 존재할 수 없다고 간주한다.

 

2. Covering constraints (포괄 제약조건)

모든 직원이 hourly_emps 또는 contract_emps 에 속해야 하는지를 나타내는 제약조건이다.

즉, 모든 서브클래스 집합들이 슈퍼클래스의 모든 엔티티를 포함하는지를 나타낸다.

만약 제약조건이 명시되어있지 않다면, 서브클래스가 슈퍼클래스 전체를 포괄하지 않는다고 간주한다.

(즉, hourly_emps, contract_emps 모두에 해당하지 않는 직원이 존재할 수 있다.)

 

다만 한 가지 교수님이 강조하신 부분은, ISA 관계는 '관계 집합'은 아니다.

(만약 관계 집합이었다면 마름모로 표현했을 것이다..)

이 ISA를 구체적으로 데이터베이스에 어떻게 나타낼 것인지는 뒤에서 정리할 예정이다.

 

 

집단화 (Aggregation)

관계 집합 (relationship set) 은 일반적으로 엔티티 셋과 엔티티 셋 사이의 관계들을 원소로 갖는 집합이다.

그런데 어떤 경우에는 엔티티와 (엔티티-엔티티 사이 관계) 에 대해서 관계를 나타내주어야 할 때도 있다.

 

 

위 그림과 같은 상황을 보자.

이 다이어그램은 다음 상황을 나타낸 것이다.

 

회사에서 여러 개의 프로젝트를 진행하고 있고, 각각의 프로젝트는 하나 이상의 부서로부터 자금지원을 받는다.

어떤 프로젝트의 자금을 지원하는 부서는, 그 프로젝트를 감독하는 직원을 지정할 수 있다.

이때 '감독한다' 라는 행위는 직원과 (프로젝트-부서의 자금 지원 관계) 에 대해 형성되는 관계로서,

감독 직원은 프로젝트나 부서와는 관계를 맺지 않는다.

 

이렇게 엔티티와 관계 사이에 관계를 형성하는 것을 가리켜 '집단화' 라고 한다.

집단화를 통해 관계 집합이 다른 관계 집합에 참여하는 관계를 나타낼 수 있으며,

참여하는 관계집합과 관련된 다이어그램을 점선 사각형으로 둘러싸서 표현한다.

 

 

조금 더 쉽게 표현하면 이렇게 표현하는 것과 같다고 볼 수 있다.

'감독' 이라는 관계로 '직원' 이라는 엔티티 셋과 '지원' 이라는 관계 셋 사이에 관계를 형성하는 것이다.

 

여기에서 든 한 가지 의문점은, 왜 직원과 프로젝트가 감독 관계를 맺도록 설정하면 안되는 걸까?

요구사항을 보면, 부서는 프로젝트를 지원하고, 그 부서의 직원이 부서가 지원하는 프로젝트를 감독한다고 했다.

즉, 직원은 부서와 독립적으로 떨어져서 프로젝트를 감독하는 것이 아니라, '부서가 지원하는 프로젝트' 를 감독해야 하기 때문에 지원 관계에 대해 '감독 관계' 를 형성해야 하는 것이다.

 

그런데 누군가는 단순하게 부서, 프로젝트, 감독직원 사이에 관계가 있으니 이 세 엔티티를 삼진 관계로 표현하고자 할 수도 있다.

이를 삼진관계로 표현한다는 것은 곧, sponsor 관계 집합과 monitor 관계집합을 나누어서 생각하지 않고 하나로 묶어서 생각하겠다는 것과 같다.

 

이렇게 설계하는 경우에는 요구사항에 따라 문제가 생길 수 있다.

예를 들어서 감독하는 행위에 대해 '언제까지 감독했는지' 를 저장하는 until 속성이 필요하다고 해보자.

그러면 위 다이어그램과 같이 지금은 Monitor 관계 집합에 until 속성을 추가할 수 있다.

 

 

그런데 만약 위와 같이 Sponsor, Monitor 두 관계집합을 하나로 합쳐버리면 until 속성을 넣을 위치가 애매해져버린다.

그냥 Sponsor에 달아버리기에는 이 until 의 의미가 '언제까지 지원할 것인지' 를 의미하는 것이 될 수도 있고, '언제까지 감독할 것인지' 를 의미하게 될 수도 있다.

(그리고 위 그림과 같이 점선 사각형으로 묶은 상태에서 until 을 sponsor 에 붙이게 되면, 언제까지 지원할 것인지에 대한 의미로 해석하게 되므로, 올바른 해석이 아니기도 하다. 따라서 until 을 둘 곳이 없어지게 된다.)

 

또한 만약 각각의 sponsor 관계가 최대 1명의 감독자만 가질 수 있다는 제약이 걸린다면, 위와 같이 삼진관계로 나타낸 경우에는 화살표를 통해 키 제약조건을 나타냈을 때, 이 제약조건이 프로젝트에 대한 키 제약조건으로 해석될 수도, Department 에 대한 키 제약조건으로 해석될 수도 있어 모호해지기에 삼진관계를 사용하여 나타낼 수 없다. 

 

이와 관련된 내용은 여러가지 관계들 간의 비교를 정리하는 내용에서 더 자세히 정리하겠다.