[DB] 무결성 제약조건

 

데이터베이스에 저장된 데이터는 결함이 없어야 하며 질의에 대해 신뢰성 있는 답을 제공해야 한다. 예를 들어 사람의 나이를 조회했을 때 200이 나오거나, 대학에서 수강인원이 40명인 과목에 41명이 수강신청이 되는 경우 등은 모두 무결성 제약조건을 위배한 것이다.

 

데이터를 저장하는데 있어서 데이터베이스는 일관성을 유지하고 중복을 제거하는 등 데이터의 신뢰도를 유지해야 한다. 따라서 데이터의 삽입, 삭제, 수정 시 여러 가지 제약조건이 따른다. 

 

키

 

관계 데이터베이스에서 키는 릴레이션에서 특정 튜플을 식별할 때 사용하는 속성 혹은 속성의 집합이다. 릴레이션은 중복된 튜플을 허용하지 않기 때문에 각각의 튜플에 포함된 속성들 중 어느 하나이상 값이 달라야 한다.

 

이제 서점 데이터베이스 예제를 확인하며 키의 종류와 각자의 역할에 대해 알아보자.

 

서점 데이터베이스

 

슈퍼키

 

슈퍼키는 튜플이 유일하게 식별할 수 있는 하나의 속성 혹은 속성의 집합을 말한다. 튜플은 유일하게 식별할 수 있는 값이면 모두 슈퍼키가 될 수 있다. 고객 릴레이션의 경우 고객번호와 주민번호를 포함한 모든 속성의 집합이 슈퍼키가 된다. 정의에 따라 고객 릴레이션의 슈퍼키를 나열하면 다음과 같다. 슈퍼키는 포함하지 않아도 되는 속성을 포함할 수 있다.

 

• 고객번호 : 고객별로 유일한 값이 부여되어 있기 때문에 튜플 식별 가능.
• 주민번호 : 개인별로 유일한 값이 부여되어 있기 때문에 튜플 식별 가능.
• 이름 : 동명이인이 있는 경우 튜플을 유일하게 식별할 수 없음.
• 주소 : 가족끼리는 같은 정보를 사용할 하기에 튜플을 식별할 수 없음.
• 핸드폰 : 한 사람이 여러 개의 핸드폰을 사용할 수 있고 반대로 핸드폰을 사용하지 않을 수 있기 때문에 식별할 수 없음.

 

(주민번호), (주민번호, 이름), (주민번호, 이름, 주소), (주민번호, 이름, 핸드폰) ...

 

후보키

 

후보키는 튜플을 유일하게 식별할 수 있는 속성의 최소 집합이다. 이는 효율성 측면에서 매우 중요하다. 고객 릴레이션의 경우 슈퍼키는 많지만 후보키는 "주민번호", "고객번호"만 해당될 수 있다. 

 

고객번호와 도서번호 각각의 경우 고객이 여러 개의 도서를 구매할 수 도 있고 같은 도서가 2개 이상될 수 있기 때문에 식별될 수 없다.

하지만 두 속성을 합친 경우 동일한 주문 기록이 없게 되므로 유일하게 식별할 수 있게 된다.

 

기본키

 

기본키는 여러 후보키 중 하나를 선정하고 대표로 삼는 키를 말한다. 후보키가 하나뿐이라면 그 후보키를 기본키로 사용하면 되고 여러 개라면 릴레이션의 특정을 반영하여 하나를 선택하면 된다. 키를 선택할 때 조건으로는 다음과 같이 있다.

 

기본키의 조건

• 릴레이션 내 튜플을 식별할 수 있는 고유한 값을 가져야 한다.
• NULL 값을 허용하지 않는다.
• 키 값의 변동이 일어나지 않아야 한다.
• 최대한 적은 수의 속성을 가진 것이어야 한다.
• 향후 키를 사용하는 데 있어서 문제 발생 소지가 없어야 한다.

 

대리키

 

기본키가 보안을 요하거나, 여러 개의 속성으로 구성되어 복잡하거나, 마땅한 기본키가 없을 때는 일렬번호 같은 가상의 속성을 만들어 기본키로 삼는 경우가 있다. 이러한 키를 대리키 혹은 인조키라고 한다. 대리키는 DBMS나 관련 소프트웨어에서 임의로 생성하는 값으로 사용자가 직관적으로 그 값의 의미를 알 수 없다.

 

대리키의 예를 주문 릴레이션을 통해 살펴보자.

 

 

주문번호라는 대리키를 생성하여 이전에 사용하던 방식인 고객번호 혹은 도서번호 키를 사용하지 않아 고객이 중복 주문을 하지 못하는 경우를 해결할 수 있다.

 

대체키

 

대체키는 기본키로 선정되지 않은 후보키를 말한다. 고객 릴레이션의 경우 고객번호와 주민번호 중 고객번호를 기본키로 정하면 "주민번호"가 대체키가 된다.

 

외래키

 

외래키는 다른 릴레이션의 기본키를 참조하는 속성을 말한다. 지금까지 살펴본 키들이 단일 릴레이션을 기준으로 설명하였다면 외래키는 다른 릴레이션의 기본키를 참조하여 관계 데이터 모델의 특징인 릴레이션 간의 관계를 표현한다.

 

주문 릴레이션의 기본키인 주민번호는 고객이 도서를 주문하면 생성된다. 이때 해당되는 고객번호와 도서번호도 주문 릴레이션에 저장된다. 주문 릴레이션에서 주문번호를 알면 어떤 고객이 어떤 도서를 구입했는지 알 수 있다.

외래키가 성립하기 위해서는 참조하고 참조되는 양쪽 릴레이션의 도메인이 서로 같아야 한다. 또한 참조되는 릴레이션의 기본키 값이 변경되면 이 기본키를 참조하는 외래키 값 역시 변경되어야 한다. 참조하는 외래키 값이 참조되는 기본키 값에 연동된다는 의미로, 외래키는 항상 데이터의 일관성을 유지해야 한다. 이러한 특징을 외래키 제약조건이라 한다.

 

외래키는 기본키와 다르게 NULL 값을 포함할 수 있고 중복값 또한 허용한다. 릴레이션이 참조를 할 때 꼭 같거나 다른 릴레이션일 필요는 없다. 자기 자신의 기본키를 참조할 수 도 있다.

 

외래키 특징

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

전체 정리

 

 

무결성 제약조건

 

데이터 무결성은 데이터베이스에 저장된 데이터의 일관성과 정확성을 지키는 것을 말한다. 일관성과 정확성을 잃어버린 데이터베이스는 정보로서의 가치에 심각한 문제가 있는 것이다. 일관성과 정확성을 가지고 구축된 데이터베이스가 계속해서 무결성을 유지하려면 튜플 삽입, 삭제, 수정 시 데이터의 제약조건 준수 여부를 확인하여야 한다.

 

3가지 제약 조건

 

1. 도메인 무결성 제약조건
   • 도메인 무결성 제약조건은 도메인 제약이라고도 하며, 릴레이션 내의 듀플들이 각 속성의 도메인에 지정된 값만을 가져야 한다는 조건이다. 예를 들어 주문 릴레이션에서 주문일자는 날짜 데이터만 사용해야 한다. 만약 영문자 등의 다른 자료형을 사용한다면 자료의 저장 및 검색에 큰 어려움이 따를 것이다. 도메인 무결성 제약조건은 속성 값과 관련된 무결성으로, SQL 문에서 데이터 형식, 널, 기본 값, 체크 등을 사용하여 지정할 수 있다. 일반적으로 프로그래밍 언어의 변수형 선언과 개념이 유사하다.
2. 개체 무결성 제약조건
   • 개체 무결성 제약조건은 기본키 제약이라고 한다. 릴레이션은 기본키를 지정하고 그에 따른 무결성 원칙 즉, 기본키는 NULL 값을 가져서는 안 되며 릴레이션 내에 오직 하나의 값만 존재해야 한다는 조건이다. 개체 무결성 제약조건은 참조 무결성 제약조건과 함께 관계 데이터 모델의 핵심 개념이다. 앞에서 말한 고객번호, 도서번호, 주문번호가 기본키로 선언되었고 각각의 기본키는 NULL 값이 없는 유일한 값이기에 개체 무결성 제약조건을 지키고 있다.
3. 참조 무결성 제약조건
   • 참조 무결성 제약조건은 외래키 제약이라고 한다. 릴레이션 간의 참조 관계를 선언하는 제약조건이다. 일반적으로 참조되는 릴레이션을 부모 릴레이션, 참조 릴레이션을 자식 릴레이션이라고 한다. 참조 무결성 제약조건은 자식 릴레이션의 외래키는 부모 릴레이션의 기본키와 도메인이 동일해야 하며, 자식 릴레이션의 값이 변경될 때 부모 릴레이션의 제약을 받는다는 것이다. 즉 부모 릴레이션의 도메인과 다른 값으로 삽입, 수정될 경우 거부되고, 반대로 자식 릴레이션에서 참조하고 있는 값을 부모 릴레이션에서 삭제하거나 다른 값으로 변경하려고 하면 거부된다.
    

 

무결성 제약조건의 수행

 

릴레이션은 데이터의 변경이 일어날 때 제약조건에 위배될 수 있다. 따라서 제약조건의 준수 여부는 데이터 변경(삽입, 수정, 삭제)이 있을 때마다 확인해야 한다. 예를 들어 기존의 기본키와 같은 값을 가진 튜플을 삽입하거나, 기존의 기본키 값을 다른 튜플의 기본키와 같은 값으로 변경하다면 그 연산은 거부된다. 또 부모 릴레이션에서 튜플을 삭제할 경우 자식 릴레이션도 같이 처리해야 한다.

 

1. 개체 무결성 제약 조건
   • 관계 데이터베이스 시스템에서 DBMS는 튜플을 삽입하거나 수정할 때마다 개체 무결성 제약 조건을 지키는지 확인한다. 기본키 값이 유일한지, NULL 값이 아닌지 검사하고 맞지 않는다면 오류 메시지를 전송한다.
   • 삽입 : 기본키를 검색해 해당 값이 존재하는지 안 하는지를 검색하고 있다면 거부
   • 수정 : 수정 연산 역시 삽입 연산과 동일한 제약에 따라 처리된다. 
   • 삭제 : 특별한 확인이 필요하지 않으며 즉시 수행한다. 하지만 참조 무결성 제약조건에 의하여 학생 릴레이션의 기본키를 다른 릴레이션에서 외래키로 참조하고 있으면 바로 삭제하지 않는다.
2. 참조 무결성 제약조건
   • 참조 무결성 제약조건은 개체 무결성 제약과 다르게 단일 릴레이션이 아니기에 참조 무결성 제약조건을 지키려면 두 릴레이션 간의 참조 관계에 따라 좀 더 복잡한 처리를 수행해야 한다.
   • 삽입 : DBMS는 먼저 도메인 무결성 제약조건을 확인한 후 개체 무결성 제약조건에 위배되는 값이 없는지 확인을 한다. 이후 부모 릴레이션의 기본키에 존재하는 확인 한다. 부모 릴레이션에 해당 값이 없으면 삽입 거부.
   • 수정 : 수정은 삭제와 삽입 명령이 연속해서 수행된다고 보면 된다. 부모 릴레이션의 수정이 일어날 경우 삭제 옵션에 따라 처리된 후 문제가 없으면 다시 삽입 제약조건에 따라 처리된다.
   • 삭제 : 삽입과는 반대로 자식 릴레이션에서 튜플이 삭제되는 경우 부모 릴레이션에는 아무런 영향을 주지 않으므로 바로 삭제가 가능하다. 그러나 부모 릴레이션에서 튜플이 삭제되는 경우에 문제가 발생할 수 있다.