[DB] 무결성 제약조건

1. Key

• 특정 튜플을 식별할 때 사용하는 속성(의 집합)
• 릴레이션은 중복된 튜플을 허용하지 않음
  • 각 튜플에 포함된 속성들 중 어느 하나(이상)는 값이 달라야 함
  • 키가되는 속성(의 집합)은 반드시 값이 달라서 튜플들을 서로 구별할 수 있어야 한다.
• 릴레이션 간에 관계를 맺는 데에도 사용된다.

1.1. 마당서점 릴레이션 예시

고객

고객번호	이름	주민번호	주소	핸드폰
1	박지성	810101-1111111	영국 맨체스타	000-5000-0001
2	김연아	900101-2222222	대한민국 서울	000-6000-0001
3	장미란	830101-2333333	대한민국 강원도	000-7000-0001
4	추신수	820101-1444444	미국 클리블랜드	000-8000-0001

도서

도서번호	도서이름	출판사	가격
1	축구의 역사	굿스포츠	7000
2	축구아는 여자	나무수	13000
3	축구의 이해	대한미디어	22000
4	골프 바이블	대한미디어	35000
5	피겨 교본	굿스포츠	8000

주문

고객번호	도서번호	판매가격	주문일자
1	1	7000	2014-07-01
1	2	13000	2014-07-03
2	5	8000	2014-07-03
3	2	13000	2014-07-04
4	4	35000	2014-07-05
1	3	22000	2014-07-07
4	3	22000	2014-07-07

2. Key의 종류

• 슈퍼키(super key)
• 후보키(candidate)
• 기본키(primary)
• 대리키(surrogate)
• 대체키(alternate)
• 외래키(foreign)

위 키들의 포함 관계를 앞서 요약하면 다음 그림과 같다.

키들의 포함 관계 정리

2.1. 슈퍼키(super key)

• 튜플을 유일히 식별하는 하나의 속성(의 집합)

2.1.1. 예시: 고객 릴레이션

• 고객번호: 튜플 식별 가능
• 이름: 동명이인 있을 경우 식별 불가
• 주민번호: 식별 가능
• 주소: 식별 불가
• 핸드폰: 식별 불가

고객 릴레이션은 고객번호, 주민번호를 포함한 모든 속성의 집합이 모두 슈퍼키가 될 수 있다.

• 예시: (주민번호), (주민번호, 이름), (주민번호, 이름, 주소), (주민번호, 이름, 핸드폰), (고객번호), (고객번호, 이름, 주소), (고객번호, 이름, 주민번호, 주소, 핸드폰) 등

2.2. 후보키(candidate key)

• 튜플을 유일하게 식별하는 속성의 최소 집합
• 기본키가 될 수 있는 후보
• 유일성, 최소성을 동시에 만족해야 함
• 2개 이상의 속성으로 이루어진 키를 복합키(composite key)라고 한다.

예시로, (주민번호, 이름)은 슈퍼키는 될 수 있지만, 후보키는 될 수 없다.

2.2.1. 예시: 주문 릴레이션

• 고객번호: 유일하게 식별 불가
  • 한 고객이 여러 주문을 할 수 있음
• 도서번호: 유일하게 식별 불가
  • 한 도서가 여러 번 주문될 수 있음

주문 릴레이션에서의 후보키는 따라서, 두 개의 속성을 합한 (고객번호, 도서번호)가 후보키가 되어야 한다.

하지만 한 고객이 같은 책을 여러 권 주문할 수 있는 경우 (고객번호, 도서번호)는 후보키가 될 수 없다. 이를 해결하는 방법은 뒤에서 언급된다.

2.3. 기본키(primary key)

• 여러 후보키 중 하나를 선정해 대표키로 삼는 키
• 후보키가 하나뿐이면, 그것을 곧 기본키로 사용함
• 후보키가 여러개이면 릴레이션의 특성을 고려하여 하나만 선택함
• 릴레이션 스키마에 밑줄을 그어 표시함
  • 예시: 고객(고객번호, 이름, 주민번호, 주소, 핸드폰)

2.3.1. 선정 시 고려사항

• 튜플 식별할 수 있는 고유한 값
• NULL은 허용 X
• 변동되면 안 됨
• 최대한 적은 수의 속성을 가져야 함
• 향후 키 사용에 있어 문제 발생 소지가 있으면 X
  • 개인정보 등이 포함되면 X

2.4. 대리키(surrogate key)

• 기본키가 보안을 요하거나, 복잡하거나, 마땅한 것이 없을 때 대신해서 사용하는 키
• 임의의 일렬번호를 가진 속성을 만들어서 사용
• _인조키(artificial key)_라고도 하지만 자주 사용되지는 않음
• DBMS 소프트웨어에서 임의로 생성하는 값이므로, 의미가 X

2.5. 대체키(alternate key)

• 후보키 중 기본키로 선정되지 않은 키

2.5.1. 예시: 고객 릴레이션

• 고객번호가 기본키라면, 주민번호는 대체키가 됨

2.6. 외래키(foreign key)

• 다른 릴레이션 기본키를 참조하는 속성
  • 이렇게 함으로써 릴레이션 간의 관계(relationship)를 표현한다.

2.6.1. 특징

• 관계 데이터 모델의 릴레이션 간 관계를 표현함
• 다른 릴레이션의 기본키를 참조하는 속성
• 참조하고(외래키), 참조되는(기본키) 양쪽 릴레이션의 도메인은 서로 같아야 함
• 참조되는(기본키) 값 변경 시, 참조하는(외래키) 값이 변경됨
• NULL 허용
• 중복값 허용
• 외래키는 기본키의 일부가 될 수 있다.

2.6.2. 릴레이션 간 참조 관계

릴레이션 간 참조 관계

2.6.3. 자기 자신을 참조하는 외래키

• 자기 자신의 기본키를 참조하는 외래키도 가능하다.
• 참조하는 릴레이션과 참조되는 릴레이션이 꼭 다를 필요는 없다.

자기 자신을 참조하는 외래키의 예

3. 무결성 제약조건

데이터 무결성(integrity, 無缺性)이란 결점 없는 성질을 의미하며, DB에 저장된 데이터의 일관성과 정확성을 지키는 것을 말한다.

무결성 제약조건을 앞서 정리하면 다음 표와 같다.

무결성 제약 조건의 정리

3.1. 도메인 무결성 제약조건

• 도메인 제약(domain constraint)이라고도 함
• 릴레이션 내 튜플들이 각 속성의 도메인에 지정된 값만을 가져야 한다는 조건
• SQL문에서 데이터 형식(TYPE), 널(NULL/NOT NULL), 기본 값(DEFAULT), 체크(CHECK) 등을 사용해 지정 가능함

3.2. 개체 무결성 제약조건

• 기본키 제약이라고도 함
• 릴레이션은 기본키를 지정하고, 그에 따른 무결성 원칙을 지켜야 한다는 조건
• 무결성 원칙
  • 기본키는 NULL 값을 가질 수 X
  • 릴레이션 내 오직 하나의 값만 가질 수 있음

3.4. 참조 무결성 제약조건

• 외래키 제약이라고도 함
• 릴레이션 간 참조 관계를 선언하는 제약 조건
• 아래를 만족해야 함
  • (자식 릴레이션 외래키의 도메인) $=$ (부모 릴레이션 기본키의 도메인)
  • 부모(parent) 릴레이션: 참조되는(제공하는) 릴레이션 → 자식의 외래키가 자신의 기본키임
  • 자식(child) 릴레이션: 참조하는(제공받는) 릴레이션 → 부모의 기본키를 자신의 외래키으로 가짐
• 자식 릴레이션의 값이 변경될 때 부모 릴레이션의 제약을 받는다.
  • 부모 릴레이션 도메인과 다른 값으로 수정되거나,
  • 자식 릴레이션에서 참조하는 값을 부모 릴레이션에서 삭제/변경 시 거부된다.

4. 무결성 제약조건의 수행

릴레이션은 데이터 변경이 일어날 때 제약조건에 위배될 수 있으므로, 제약조건의 준수 여부는 데이터의 변경(CRUD)이 있을 때마다 확인되어야 한다.

4.1. 개체 무결성 제약조건

• 삽입: 기본키 값 같으면 삽입 금지됨
• 수정: 수정할 기본키가 중복되거나 NULL이면 수정 금지됨
• 삭제: 특별한 확인 필요치 않고 즉시 수행
  • 단 다른 릴레이션에서 외래키로 참조되고 있을 경우 바로 삭제하지는 않음

4.2. 참조 무결성 제약조건

4.2.1. 삽입

• 부모 릴레이션(학과): 특별한 조건 없이 정상 삽입됨
• 자식 릴레이션(학생): 부모 릴레이션에 외래키에 해당하는 값이 없으므로 삽입이 금지됨

4.2.2. 삭제

• 부모 릴레이션(학과): 참조하는 테이블을 같이 삭제할 수 있어 금지되거나, 다른 추가작업이 필요함
• 자식 릴레이션(학생): 바로 삭제 가능

부모 릴레이션에서 튜플 삭제할 경우 참조 무결성 조건 수행하기 위한 고려사항

1. 즉시 작업 중지
   • RESTRICTED
2. 자식 릴레이션의 관련 튜플 삭제
   • CASCADE
3. 초기 설정된 다른 어떤 값으로 변경
   • DEFAULT
4. NULL값으로 변경
   • NULL

명령어	의미	예시
RESTRICTED	자식 릴레이션에서 참조하고 있을 경우 부모 릴레이션의 삭제 작업을 거부함	학과 릴레이션의 튜플 삭제 거부
CASCADE (사용 주의)	자식 릴레이션의 관련 튜플을 같이 삭제 처리함	학생 릴레이션의 관련 튜플 삭제
DEFAULT	자식 릴레이션의 관련 튜플을 미리 설정해둔 값으로 변경함	학셍 릴레이션의 학과가 다른 학과로 자동 배정
NULL1	자식 릴레이션의 관련 튜플을 NULL값으로 설정함 (NULL 값을 허용한 경우)	학과 릴레이션의 학과가 NULL값으로 변경됨

• 삭제 예시

4.2.3. 수정

• 삭제 후 삽입하는 명령의 연속된 수행
  1. 삭제를 먼저 고려한 후
  2. 이후에 삽입한다.
• 부모 릴레이션에서 수정이 일어난 경우:
  • 삭제 옵션 따라 처리된 후, 문제 없으면 다시 삽입 제약조건에 따라 처리됨

---

각주

1. Data는 최대한 null이 없는게 중요하다. 이 옵션은 임시 땜빵용이라고 생각하자. ↩