2024. 9. 27. 07:13ㆍCS/Database System
Relationship Types, Relationship Sets, Roles, and Structural Constraints
Relationship 또한 집합이고 Relationship의 인스턴스 집합을 Relationship Set, Relationship의 entity의 역할을 Role이라 한다.
Refining the initial design by introducing relationships
ER 다이어그램에서의 relationship을 보자.
ER 모델은 보통 다음 세 사항을 포함한다.
- entities (and their entity types and entity sets)
- attributes (simple, composite, multivalued)
- relationships (and their relationship types and relationship sets)
DEPARTMENT의 Manager를 생각해보면 Manager는 EMPLOYEE와 연관된다.
PROJECT의 Controlling_department, EMPLOYEE의 Department는 DEPARTMENT와 연관된다.
요구사항을 통해서 위와 같은 연관성을 찾아내야 한다.
Relationship and Relationship Types
Relationship
- 두 개 이상의 entity의 관련성을 나타낸다.
- 예를 들어 EMPLOYEE John Smith works on the ProductX PROJECT, or EMPLOYEE Franklin Wong manages the Research DEPARTMENT. 이 요구사항에서 works on을 보면 EMPLOYEE와 PROJECT는 관계가 존재한다는 것을 알 수 있다. 또 manages를 보면 EMPLOYEE와 DEPARTMENT도 관계가 존재한다는 것도 알 수 있다.
- 같은 타입의 relationship을 묶어서 집합을 만들 수 있고 그게 relationship type이 된다.
- 예를 들어 EMPLOYEE와 PROJECT 사이의 WORKS_ON relationship type이 존재한다.
- relationship type degree는 몇 개의 entity가 연관되어 있냐는 것이다.
- MANAGES, WORKS_ON은 두 개가 참여하므로 binary라 한다.
위의 그림은 N:1 Relationship이다. 일반적으로 생각해보면 위의 entity, relationship 모두 집합이기에 table로 만들 수 있다.
따라서 EMPLOYEE, WORKS_FOR, DEPARTMENT 집합으로 세 개의 테이블을 만들 수 있다. 실제로는 EMPLOYEE에 relationship을 하나의 field로 집어넣어서 두 개의 테이블만 만든다.
위의 그림에서 집중해야할 부분은 위의 관계가 N:1 관계라는 점이다. 여러 명의 EMPLOYEE는 하나의 DEPARTMENT에 속할 수 있다는 뜻이다. 이런 N:1도 ER 다이어그램에 포함되어야 한다.
EMPLOYEE와 PROJECT를 생각해보면 여러 명의 EMPLOYEE가 여러 개의 PROJECT에 WORKS_ON 할 수 있고, 따라서 M:N 관계이다.
M:N 관계에 존재하는 RELATIONSHIP은 테이블로 따로 만들어야 한다.
세 개의 테이블이 존재하게 되는 것이다.
Relationship Type
- intension을 의미한다.
- relationship을 설명하는 스키마이다.
- relationship name과 그에 속하는 entity type을 식별한다.
- 1대1, 1대n 등 relationship constraints를 확인한다.
Relationship Set
- extension을 의미한다.
- 관계의 인스턴스 집합이다.
- Relationship type의 현재 상태이다.
ER 다이어그램에서 relationship type은 diamnod-shaped box로 나타나고 왼쪽에서 오른쪽, 위에서 아래로 읽는다.
위의 다이어그램을 읽어보면 EMPLOYEE가 DEPARTMENT에서 WORKS_FOR 한다. 이런식으로 왼쪽에서 오른쪽으로 읽는다.
Relationship 또한 요구사항에서 찾아내는 것이다.
요구사항을 보고 관계를 찾아보면 다음과 같다.
- WORKS_FOR (between EMPLOYEE, DEPARTMENT)
- MANAGES (also between EMPLOYEE, DEPARTMENT)
- CONTROLS (between DEPARTMENT, PROJECT)
- WORKS_ON (between EMPLOYEE, PROJECT)
- SUPERVISION (between EMPLOYEE (as subordinate), EMPLOYEE (as supervisor))
- DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)
degree는 모두 2차가 된다. 이를 바탕으로 ER 다이어그램을 그려보자.
1. WORKS_FOR (between EMPLOYEE, DEPARTMENT)
2. MANAGES (also between EMPLOYEE, DEPARTMENT)
3. CONTROLS (between DEPARTMENT, PROJECT)
이 순서들도 다 의미가 있다. 위에서 아래로 DEPARTMENT가 N개의 PROJECT를 CONTROL 한다고 표시해줘야 한다.
4. WORKS_ON (between EMPLOYEE, PROJECT)
5. SUPERVISION (between EMPLOYEE (as subordinate), EMPLOYEE (as supervisor))
6. DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)
같은 엔티티 사이에 여러 개의 관계가 존재할 수 있다.
- 예를 들어 MANAGES 와 WORKS_FOR은 EMPLOYEE와 DEPARTMENT 사이의 별개의 relationship type이다.
Constraints on Relationships
Relationship Type에 두 가지 Constraints가 중요하다.
- Cardinality Ratio, 기수성을 ER 다이어그램에 적어준다.
- One to one
- One to many or Many to one
- Many to Many
- Existence Dependency Constraint
- zero (optional participation)
- one to more (mandatory participation)
위의 두 가지 제약 사항을 알아두면 된다. 자세히 알아보자.
one-to-one 관계이다.
Many to one 관계이다.
many to many 관계이다.
ER 다이어그램을 그리는 툴마다 기수성 관계를 표시하는 방법이 달라질 수 있다.
이런식으로 many to many 관계를 표시할 수 있다.
테이블로 만든다면 many to many 관계를 테이블로 만들어야한다. 이 부분을 실제 테이블로 만들 때 놓칠 수 있다. 다이어그램이 m : n 관계를 잘 나타내지 않기 때문이다.
그래서 나중에 테이블로 만들 때 이렇게 바꿔줘야 한다.
세 개의 entity가 참여하는 relationship을 Ternary Relationship이라 한다.
Recursive Relationship Type & Weak Entity Types
동일한 엔터티 타입이 서로 다른 역할을 가지고 참여하는 relationship type을 말한다.
SUPERVISION이 한 예시이다.
이 표를보고 잘 해석해보자.
e_1은 r_1 관계에 의해 e_2를 관리감독하고 r_2에 의해 e_3를 관리감독 한다.
기수성을 ER 다이어그램에 기록을 해줘야하고 recursive type은 그 role도 기록을 해줘야 한다.
Weak Entity Types
- 독립적인 key attribute를 가지지 않고 다른 entity type에 의존적인 entity이다.
- 아까의 예시에서 DEPENDENT는 EMPLOYEE 없이 존재할 수 없다.
- Weak Entity는 다른 entity type과 반드시 관계를 가져야 한다.
- EMPLOYEE 쪽에 있는 entity와 같이 써야 DEPENDENT를 구별할 수 있다. 그 key를 partial key라 한다.
- 예를 들어 DEPENDENT의 first name을 가지고 구별할 수 있다면, 그렇다면 first name이 DEPENDENT의 key가 된다. 하지만 ER 다이어그램에서 EMPLOYEE가 있어야 어떤 EMPLOYEE의 부양 가족인지 구별할 수 있으므로 Weak Entity이고 first name이 partial key 이다.
Existence Dependency Constraint
이걸 또 보면 모든 EMPLOYEE는 모든 PROJECT에 속해야하고 모든 PROJECT는 EMPLOYEE를 가져야 한다.
한줄로 되어있는 관계는 optional이다. 모든 EMPLOYEE가 DEPARTMENT를 관리하는 것은 아니고 EMPLOYEE 일부가 DEPARTMENT를 관리하므로 optional, 실선이다.
DEPARTMENT는 반드시 MANAGER가 있어야 하므로 total, double line이다.
Relationship Attribute
Relationship Type도 attribute를 가질 수 있다. 예를 들어 WORKS_ON을 보자.
요구사항부터 보면 DB는 emoployee가 각 프로젝트에서 주당 일하는 시간을 track 해야 한다고 한다.
그래서 WORKS_ON의 attribute로 hours를 넣어 주는 것이다.
모든 RELATIONSHIP이 attribute를 갖는 것은 아니고 대부분은 M:N Relationship이 attribute를 갖는다.
M:N Realationship만이 테이블을 따로 갖기 때문이다.
중요한건 relationship type도 attribute를 가질 수 있고 요구사항에서 찾아내야 한다는 것이다.
1:N 관계에서는 table을 따로 만들지 않고 attribute를 N쪽 side entity type으로 보내야 한다.
Number_of_employees는 유도된 attribute라고 하며 점선으로 나타낸다. 요구사항에는 등장하지 않고 필요에 의해 생성된 attribute이다.
그 외에도, Alternative (min, max) notation for relationship structural constraints가 있는데, min, max notation 처럼 다른 필요한 제약사항을 표시할 수 있다.
ER Diagrams, Naming Conventions and Design Issues
ER 다이어그램을 그리는데 굉장히 많은 tool들이 있고 UML을 이용해서도 그릴 수 있다.
이정도 symbol은 다 배웠고 min, max는 optional이라 알아만 두면 된다.그 외에도 굉장히 다양한 notation들이 많다.
Relationship Types of Degree Higher than Two
Relationship Type 중 entity가 2개가 참여하는, degree가 2인 것은 binary라 부르고 3개가 참여하면 ternary, n개가 참여하면 n-ary라 부른다.
n-ary relationship은 n개의 binary relationship과 동치가 아니다.
higehr degree 쪽은 제약사항을 설정하기가 더 어렵다.
위의 그림은 (s, j, p) = SUPPLIER가 PROJECT에 PART(납품)한다.
그림은 ternary relationship이 3개의 binary relationship과 동치가 아니라는 것을 말한다.
두 그림의 차이점을 잘 파악해두자.
밑의 그림은 (s, j), (s, p), ( j, p)를 말한다. Project에서 해당 부품을 사용하지 않더라도 반드시 제공해야 한다. 위의 그림은 종속이 확실하지만 아래 그림은 종속을 나타내지 못하는 것이다.
따라서 weak relationship을 두면 종속관계가 발생하므로 n-ary를 binary로 나타낼 수 있다.
요구사항을 다 반영하다보면 위와 같은 그림이 나올 수 있다.
예를 들어
교수가 데이터베이스를 2학기때 가리킬 수 있다.
교수가 데이터베이스를 2학기때 가리킬 것이다.
데이터베이스 과목은 2학기때 개설된다.
이렇게 중복된 요구사항때문에 위와 같이 그려질텐데 이런 er 다이어그램을 보면 날릴 것은 날릴 수 있다.
교수가 2학기에 데이터베이스를 가리킨다
→ 2학기에 개설됨 → OFFERED_DURING 날려도됨
→ 교수가 2학기때 가르킴 → TAUGHT_DURING 날려도됨
→ 교수가 데이터베이스 가르킴 → CAN_TEACH 날려도됨
역은 성립하지 않는다.
이런걸 생각해볼 수 있다는 점만 알아두자. 요구사항을 통해 위와 같이 그림이 나오면 다시 분석해보고 날릴 수 있으면 날리자.