[Key] 키와 무결성 제약조건

 

 

Key는 주어진 릴레이션에서 모든 인스턴스 가운데 유일함(Unique)을 보장해주는 하나 이상의 애트리뷰트의 집합이다.

Edgar Codd 

데이터베이스에서 각 인스턴스를 식별할 때는 중복을 피해야 하는데, 이런 유일함을 보장해주는 것이 Key이다.

중요한 것은 이 Key가 꼭 단 하나의 속성만으로 이루어질 필요는 없다는 것이다.(Key != 속성)

물론 단 하나의 속성만으로 Key를 구성하는 것이 가장 바람직하겠지만, 데이터 저장상태 상 그럴 수 없는 상황에서는 여러 속성을 합쳐서 유일성을 확보할 수 있다면, 그렇게 Key를 구성할 수 있다는 것이다.

이렇게 하나 이상의 속성으로 구성된 Key를 "복합Key"라고 한다.

 

유일성 : 단 하나의 인스턴스(튜플)를 골라낼 수 있는가의 여부

최소성 : 유일성을 막 만족시키기 시작하는 속성의 개수인가의 여부. *"최소"라고 꼭 하나의 속성이 아니다. 속성이 3개는 합쳐져야 유일하게 식별가능하면 3개가 최소인 것임.

 

슈퍼키 : 유일성만 만족하면 됨. 최소성은 위배되든 말든 상관않음.

후보키 : 유일성과 최소성을 모두 만족해야 함.

 

기본키 : 후보키에서 선택된 키로, 중복이나 널값이 될 수 없다.

대체키 : 후보키에서 선택되지 않은 키

 

---

무결성이란, "결함이 없는" 것으로 현실 세계에 존재하는 개념과 이를 컴퓨터에 저장한 형태가 서로 동일한 것을 의미한다.

무결성이 깨지면 데이터베이스에 저장한 의미가 없는 쓰레기가 될 뿐이다.

무결성을 지키기 위한 제약조건은 대표적으로 다음과 같다.

 

1. 개체무결성제약 : 한 릴레이션의 "기본키"를 구성하는 어떠한 속성값도 Null이나 중복값을 가질 수 없다. ex 중복ID 회원가입 불가

 

2. 참조무결성제약 : "외래키"를 가지고 그 외래키를 기본키로 가지고 있는 상대 릴레이션으로 찾아갔을 때(n에서 1로 가는 상황), 거기에 값이 없으면 안된다.

*외래키의 값은 Null이어도 상관없지만, 그 Null을 가지고 원본으로 찾아가는 상황이 문제인 것이다.

*외래키를 가진 곳이 [n, 참조하는 테이블, 자식테이블] 이고, 그 외래키를 기본키로 가지고 있는 원본 테이블이 [1, 참조테이블, 부모테이블] 이다.

 

예를 들어 <학생> 테이블과 <학과> 테이블이 있다고 해보자.

학생 개체는 단 하나의 학과에 소속될 수 있지만, 학과 개체는 여러 학생들로부터 참조될 수 있다.

그렇기 때문에 관계는 학생 : 학과 = n : 1 이다.

따라서 n에 해당하는 <학생> 테이블은 <학과> 테이블의 학과코드를 외래키로 삼아야 하고, 이로써 모든 학생들은 학과가 겹치더라도 <학과> 테이블의 정보를 읽어올 수 있는 것이다. (만약 반대로 <학과> 테이블이 <학생> 테이블의 학번코드를 외래키로 삼)

 

그런데 이렇게 정보를 읽어올 때 외래키에 존재하는 A001이라는 학과코드가, 막상 학과코드를 기본키로 가지고 있는 <학과> 테이블에는 없는 값이라면(학과 폐쇄?) 참조 무결성에 위배되는 것이다. 이는 데이터베이스 작업에서 심각한 문제이기 때문에, 다음과 같은 방법으로 오류를 방지해야 한다.

1) 기본키의 값을 아예 못 지우게 한다(RESTRICT).

2) 기본키의 값을 정 지우고 싶다면, 이를 참조하고 있는 외래키의 값들도 함께 지워지게 한다(CASCADE). 이러면 그 외래키 속성 내 값은 Null이 되며(SET NULL), 이를 가지고 다시 기본키 테이블을 조회하지 않으면 그만이다.

3) 기본키의 값을 지우고 이를 참조하는 외래키의 값을 미리 약속한 기본값으로 바꾼다(SET DEFAULT).

 

3. 도메인무결성 제약 : 주어진 속성의 값이 도메인에 속한 값이어야 한다.

외래키 테이블에 값을 추가할 때는, 반드시 그 외래키가 참조하고 있는 기본키 테이블의 기본키 속성 도메인 범위 내의 값으로 한다.