데이터베이스 : ERD #3 (애트리뷰트 유형, 관계 타입, NOT NULL, PK)

지난 글에서는 주어진 mini-world를 한 문장씩 분석하며 ERD를 만들어 보았습니다.

이 때에도 다치 애트리뷰트, 약한 엔티티 타입과 식별관계, 부분 키 등을 소소하게 알아보았지만,

ERD에는 마저 다루지 못한 요소들이 아직 많이 남아있습니다.

이번에는 애트리뷰트의 유형, 관계 타입과 관계에 대한 제약조건, NULL에 대해 알아보겠습니다.

---

애트리뷰트의 유형은 다음과 같이 나뉠 수 있습니다.

- 단순(simple) 애트리뷰트 vs. 복합(composite) 애트리뷰트
- 단일 값(single value) 애트리뷰트 vs. 다치(multi-valued) 애트리뷰트
- 유도된(derived) 애트리뷰트

 

일단 단순, 단일 값 애트리뷰트는 우리가 알고 있는 애트리뷰트 입니다.

복합 애트리뷰트는 애트리뷰트의 집합인 애트리뷰트로, 더 작은 요소로 나뉠 수 있습니다.

예를 들어 아래 그림처럼 이름은 First name, Middle name, Last name으로 나뉘죠.

이 경우 애트리뷰트는 Fname, Minit, Lname, SSN, 주소로 총 5개가 됩니다.

 

다치 애트리뷰트는 애트리뷰트 하나가 여러 값을 가질 수 있는 것입니다.

한 사람이 여러 개의 전화번호를 가질 수 있다는 상황에서 사용할 수 있죠.

이전 글에서 다룬 부서의 위치 애트리뷰트가 이 다치 애트리뷰트 였습니다.

아래의 그림을 보면 알 수 있듯 이중 타원으로 표기합니다.

 

유도된 애트리뷰트는 실제로 존재하는 애트리뷰트는 아니지만,

다른 요소에 의해 그 값이 유도될 수 있는 애트리뷰트 입니다.

추후 설명할 count 명령어로 해당 부서에 소속한 사원의 수를 얻을 수 있는데,

이 때 사원의 수는 부서의 애트리뷰트로 따로 명시하지 않았지만

그 값을 충분히 유도할 수 있다는 점에서 유도된 애트리뷰트라 합니다.

유도된 애트리뷰트는 점선 타원으로 표기합니다.

 

유도된 애트리뷰트는 다음과 같은 상황에 활용할 수 있습니다.

판매 사원의 급여가 정규직이면 판매량으로, 인턴이면 근무 시간으로 정해진다고 합시다.

이 때 급여는 따로 애트리뷰트라고 정하여 값을 넣지 않아도,

아래의 판매량, 근무시간을 계산하여 급여의 값을 유도할 수 있습니다.

 

여기서 중앙의 d는 disjointness의 d로, 상속에 관한 이야기라 짧게만 설명하도록 하겠습니다.

판매 사원은 정규직과 인턴으로 이루어져 있다는 의미로, 정규직과 인턴 둘 다 사원에 속한다는 거겠죠?

이 때 정규직과 인턴 모두 판매 사원의 애트리뷰트를 상속합니다. d는 이를 의미합니다.

overlap와 union도 있지만.. 다음 EERD 시간에 알아보도록 하겠습니다.

---

관계 타입(Relationship types)은 엔티티 간 관계들의 집합을 뜻합니다.

위의 그림에서 SUPPLY가 관계 타입이며,

SUPPLIER 와 PROJECT 사이, PART 와 PROJECT 사이의 관계를 맺어주고 있습니다.

여기서 관계에 참여하고 있는 엔티티 타입의 수를 차수(degree)라고 하는데,

위의 그림처럼 관계가 맺어진다면 삼진(ternary) 관계, (degree=3)

만약 PART 엔티티가 없이 SUPPLIER ~ SUPPLY ~ PROJECT 만 있다면 이진(binary) 관계가 됩니다. (degree=2)

---

관계 타입에 이어, 관계 자체에 대한 두 가지 제약조건을 알아보겠습니다.

1. 카디널리티 제약조건 (Cardinality ratio) : 1:1 / 1:N / N:1 / M:N
2. 참여 제약조건 (Participation constraint) : 전체 참여 / 부분 참여

네, 사실 이미 앞서 다 설명한 것에 제약조건이라는 거창한 이름만 붙인 겁니다.

그런데 왜 다시 설명하냐면, 관계 타입과 애트리튜브에 큰 연관이 있기 때문입니다.

 

앞서 관계 타입도 엔티티 타입처럼 애트리뷰트를 가질 수 있다고 했죠?

예를 들어 "MANAGES" 라는 관계 타입에 관리자를 시작한 날짜로 "Start_date"를 포함시킬 수 있습니다.

근데 이 관계 타입의 애트리뷰트를 제약조건에 따라 엔티티 타입의 애트리뷰트로 이동시킬 수 있습니다.

1:1 관계에서는 자유롭게 양쪽 엔티티 타입으로 이동할 수 있습니다.

1:N 관계에서는 오직 N 쪽의 엔티티 타입으로만 이동이 가능합니다.

M:N 관계에서는 이동이 불가하며, 관계 타입의 애트리뷰트는 반드시 관계 타입에만 표현됩니다.

---

코딩을 해보셨다면 NULL이라는 단어가 익숙하실 겁니다.

데이터에도 물론 NULL 값이 존재합니다.

데이터베이스에서의 NULL의 의미는 다음과 같습니다.

1. 존재하나 알려지지 않음(unknown) : 핸드폰이 있지만 전화번호를 알지 못함
2. 존재하나 의도적으로 보류
3. 해당 튜플에는 정의되지 않는 값 : 동/호수는 단독 주택에 적용되지 않으므로 NULL

위의 내용은 가볍게 넘어가고, 중요한 것은 NOT NULL 입니다.

NOT NULL은 NULL이 되면 안되는 키 값으로, 예를 들어 학번, 이름 등이라고 볼 수 있죠.

왜 NOT NULL이 중요하냐면, 바로 이것이 PK(Primary key)의 조건이기 때문입니다.

 

PK의 조건은 다음과 같습니다.

1. NOT NULL
2. Unique : 이 key 만으로 튜플을 식별 가능한가?

 

<틀린 점이 있다면 지적 부탁드립니다. 감사합니다.>