[Chap 2-2] 개체-관계 모델(Entity-Relationship mode)

2.5 키(Keys)

- ER(Entity Relation) 모델에서 객체는 결국 그 객체의 속성 값으로 구별함.

- 데이터베이스에서 조건에 맞는 튜플의 속성을 찾거나 순서대로 정렬을 할 때 기준이 되는 속성으로 키를 사용.

- 앞서 소개될 키들(SK, CK, PK, FK)는 모두 속성의 집합

1) 슈퍼 키(SK: Super Key)

- 한 관계(Relation = table)에서 그 Relation 튜플(Tuple)들을 유일하게 식별해 주는 속성(Attribute)들의 집합

- 즉, 슈퍼키가 되기 위해서는 그 릴레이션의 슈퍼 키 속성들의 값이 모두 같은 튜플이 존재해서는 안됨. 튜플들을 유일하게 식별하는 것을 유일성(Unique)라고 하는데, 그 슈퍼 키는 유일성을 만족함. 

- 슈퍼키는 관련 없는 속성들을 포함하고 있을 수 있음. 즉, 어떤 속성을 빼도 유일성을 만족할 수 있다는 말임.이렇게 슈퍼 키에 속하는 속성들 중 어떤 하나를 빼도 유일성을 만족할 수 있기 때문에, 슈퍼키는 최소성(Minimality)을 만족하지 않음

2) 후보 키(CK: Candidate Key)

- 역시 릴레이션의 속성의 집합으로 릴레이션의 튜플을 유일하게 식별

- 유일성을 만족시키는 슈퍼 키의 최소한의 부분집합을 후보 키라고 함.

- 슈퍼 키와는 달리 유일성과 최소성을 모두 만족.

- 기본 키(Primary key)의 후보가 도니다고 해서 후보 키 라고 함.

3) 기본 키, 주 키(PK: Primary Key)

- 후보 키(Candidate Key)중에서 선정된 키. 설계자에게 선택된 하나의 후보 키

- 당연히 릴레이션의 속성 집합으로 구성되고, 유일성과 최소성을 모두 만족.

- 허나 NULL값을 절대 갖을 수 없음

4) 대체 키(AK: Alternate Key)

- 후보 키에서 기본키를 뺸 모든 후보 키

5) 외래 키(FK: Foreign Key)

- 어떤 릴레이션 r1의 속성(Attribute)이 다른 릴레이션 r2의 주 키(PK)를 포함하고 있는 경우가 있을 수 있음. 이때 r1에서부터 r2를 참조하는 속성들의 집합을 외래 키(FK)라고 함.

- 이때, r1을 Referencing Relation이라 하고, r2를 Referenced Relation이라 함. 

- 쉽게 말해, FK는 다른 릴레이션의 주 키를 참조하는 속성들의 집합을 말함.

예) 학생 개체 집합

학번	이름	주민번호	전화번호	학과 번호

위와 같은 속성들을 가질 때, 속성들 중에 슈퍼키가 될 수 있는 속성들의 집합을 생각해보자.

일단 먼저 학번과 주민번호 속성이 super key가 될 수 있다. 이 속성들로 튜플들을 유일하게 구분할 수 있기 때문.

또한 이 두 튜플이 들어간 속성들의 부분집합이 SK가 될 수 있다. 예를 들어 (학번, 이름), (학번, 주민번호), (학번, 이름, 전화 번호) ... 과 같은 부분 집합. 이는  SK가 최소성을 만족하지 않고 유일성만 만족하면 되기 때문. 즉, 요약하면 학번 또는 주민번호가 들어간 어떤 조합이든지 SK가 될 수 있음

그렇다면 후보키는? (학번, 이름)이 후보키가 될 수 있을까? 될 수 없다. 최소성을 만족시키기 위해서는 (학번)이 후보키가 될 수 있다. 그러면 (학번, 주민번호)는 CK가 될 수 있을까? 이것 또한 불가능. 유일성을 만족하면서 최소성이 만족해야하기 때문에 튜플을 유일하게 구분하는 두 속성이 같이 조합되어도 안됨.

그러면 수강표에서 SK(학번, 과목번호)는 CK가 될 수 있을까? (학번)도 (과목번호)도 따로 있을 때는 SK가 안됨. 따라서 이는 CK 가 될 수 있음.

일차 키(PK)의 경우, 후보키중에 하나가 선택 된 키. 따라서 위의 예에서는 만약 후보키 중 학번을 일차 키(PK)로 선택한다면 주민번호는 후보키로 남을 것임.

예) 외래키(FK)

학적: {학번, 이름, 전화번호} 

수강: {학번, 과목번호}

수강 테이블의 {학번}이 학적 테이블에서 일차 키임. 수강 테이블의 {학번}을 외래 키라고 함. 

그러면 여기서 강의 개설: {과목번호, 교수번호}표에서 {과목번호}가 수강표를 참조하는 FK일까? 수강표의 PK는 {학번, 과목번호}로 과목번호를 포함 하고 있다고? 아니다. 안된다. 대체키를 만들거나 두개 모두 외래키로 지정해줘야한다.

예) 학적=(학번, 소속학과, ...); PK=(학번), FK=(학번) references 학생 정보

     학생 정보=(학번, 이름, ...); PK=(학번), FK=(학번) references 학적

이와 같은 경우는 Cyclic reference문제가 생김. 두 표에서 각각 PK=FK이면 두 집합을 하나로 하여 하나의 집합으로 만드는 것이 바람직함...

#PK는 꼭 있을까? 꼭 적어야 하나?

학생 테이블을 참조하는 수강 스키마를 SQL로 나타내면 다음과 같다

create table 수강(학번 char(7), 과목번호 char(7), primary key (학번, 과목번호), foreign key(학번) references 학생);

개념상 SK는 반드시 하나는 있다. minimal SK가 있으며, 그것이 CK가 됨. CK가 있으면 PK도 있다.(개체 집합에 꼭 같은 객체는 없다.)

하지만 SQL(구현부분)에서는 테이블에 PK를 지정하지 않아도 된다. 표 안에 겹치는 투플을 허용할 수도 있고, 허용하지 않을 수도 있다.

#PK, FK는 어디에 쓰나?

- 개체 집합에 PK값이 같은 개체가 둘 이상 있을수 없다. 

예) 학생표에서 학번이 같은 사람이 둘 있을 수 없다. 

- PK에 대하여 index를 만들 때가 흔히 있는데, PK를 잘 모르면 index를 만들기가 어렵다.(또는 잘못 만든다)

예) 학생표에서 {학번, 이름}을 PK라 잘못 생각하고 index를 {학번, 이름}에 대하여 만들면, 이 index의 활용도가 떨어짐. 왜냐하면, 학번만으로 찾지 못하고, 반드시 학번과 이름을 모두 알아야 이 index를 쓸 수 있음.)

- 참조 무결성(referential integrity)을나타내기 위해 FK가 필요함.

- FK개념은 결국 PK개념을 필요로 한다. 표1의 FK가 표2를 참조하면 -> 표1의 KF = 표 2의 PK

- 뒤에서 배울 FD(Functional Dependency)와 정규화(Normalization) 등에서 쓴다.