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

1. 키

키는 릴레이션에서 튜플을 다른 튜플과 구별해서 유일하게 식별할 수 있게 해주는 속성, 또는 속성들의 조합을 의미한다. 키는 역할과 성격에 따라 여러 종류로 나뉜다.

슈퍼키

슈퍼키(Super Key)는 한 릴레이션 내에서 튜플을 유일하게 식별할 수 있는 속성들의 집합이다. 슈퍼키는 유일성(Uniqueness)만 만족하면 되기 때문에, 식별에 필요하지 않은 속성이 추가로 포함되어 있어도 슈퍼키가 될 수 있다. 예를 들어 학생 릴레이션에서 (학번, 이름)이라는 속성 조합은 학번만으로도 충분히 유일하게 식별할 수 있지만, 이름이 추가로 붙어 있어도 여전히 튜플을 유일하게 식별하므로 슈퍼키가 된다.

후보키

후보키(Candidate Key)는 슈퍼키 중에서도 최소성(Minimality)을 만족하는 키이다. 최소성이란 키를 구성하는 속성 중 어느 하나라도 제거하면 더 이상 유일성을 만족하지 못하게 되는 성질을 말한다. 즉 후보키는 튜플을 유일하게 식별하는 데 필요한 최소한의 속성들로만 구성된다. 학생 릴레이션에서는 학번이 후보키가 될 수 있고, 만약 주민등록번호 속성이 있다면 그것도 또 다른 후보키가 될 수 있다.

기본키

기본키(Primary Key)는 여러 개의 후보키 중에서 그 릴레이션을 대표하는 키로 선택된 하나를 의미한다. 하나의 릴레이션에는 여러 후보키가 존재할 수 있지만, 기본키는 단 하나만 지정할 수 있다. 기본키는 보통 값이 변하지 않고 간결하며, 추후 다른 릴레이션에서 참조하기에도 적합한 속성을 선택하는 것이 일반적이다.

대체키

대체키(Alternate Key)는 후보키 중에서 기본키로 선택되지 않은 나머지 후보키를 의미한다. 학생 릴레이션에서 학번을 기본키로 선택했다면, 주민등록번호처럼 또 다른 후보키 자격을 가진 속성은 대체키가 된다.

외래키

외래키(Foreign Key)는 어떤 릴레이션에 속한 속성이 다른 릴레이션의 기본키를 참조하는 경우를 의미한다. 외래키는 두 릴레이션 사이의 관계를 표현하는 핵심적인 도구이다. 예를 들어 수강 릴레이션에 있는 학번 속성이 학생 릴레이션의 기본키인 학번을 참조한다면, 수강 릴레이션의 학번은 외래키가 된다.

아래 그림은 지금까지 설명한 키들 사이의 관계를 정리한 것이다.

2. 무결성 제약조건

무결성 제약조건(Integrity Constraint)은 데이터베이스에 저장되는 데이터가 항상 정확하고 일관된 상태를 유지하도록 보장하기 위한 규칙이다. 아무리 키를 잘 정의해두었다고 해도, 실제 데이터를 다루는 과정에서 이 규칙들이 지켜지지 않으면 데이터의 신뢰성이 무너지게 된다. 무결성 제약조건은 크게 다음과 같이 나뉜다.

도메인 무결성

도메인 무결성(Domain Integrity)은 각 속성의 값이 그 속성에 정의된 도메인 안에 있는 값이어야 한다는 제약이다. 예를 들어 학년이라는 속성의 도메인이 1부터 4까지의 정수로 정의되어 있다면, 학년에 5나 "일학년" 같은 값이 들어가는 것은 도메인 무결성을 위반하는 것이다.

개체 무결성

개체 무결성(Entity Integrity)은 기본키를 구성하는 속성은 NULL 값을 가질 수 없다는 제약이다. 기본키는 튜플을 유일하게 식별하는 역할을 하는데, 만약 기본키 값이 NULL이라면 그 튜플이 어떤 개체를 가리키는지 알 수 없게 되므로 식별이라는 기본키의 존재 목적 자체가 무너진다.

참조 무결성

참조 무결성(Referential Integrity)은 외래키 값이 그것이 참조하는 릴레이션의 기본키 값 중 하나와 일치해야 한다는 제약이다. 즉 존재하지 않는 값을 외래키로 가질 수 없다. 다만 외래키가 NULL을 허용하도록 설계된 경우에는, 아직 관계가 맺어지지 않았다는 의미로 NULL 값을 가지는 것은 허용된다.

아래 그림은 학생 릴레이션과 수강 릴레이션 사이의 참조 무결성을 예시로 보여준다. 수강 릴레이션에 있는 학번 2024099는 학생 릴레이션에는 존재하지 않는 값이기 때문에 참조 무결성을 위반한 상태이다.

키 무결성

키 무결성(Key Integrity)은 하나의 릴레이션 안에서 모든 튜플이 키 값으로 서로 구별되어야 한다는 제약이다. 같은 키 값을 가진 튜플이 두 개 이상 존재해서는 안 된다.

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

무결성 제약조건은 단순히 이론적인 규칙으로만 존재하는 것이 아니라, DBMS가 실제로 이를 강제하고 검사하는 기능을 수행한다.

제약조건의 정의 시점

대부분의 무결성 제약조건은 테이블을 생성하는 시점에 함께 정의된다. 기본키를 지정하거나, 외래키가 어떤 릴레이션의 어떤 속성을 참조하는지 명시하거나, 특정 속성에 NULL을 허용할지 여부를 정하는 것이 모두 이 단계에서 이루어진다. 이렇게 정의된 제약조건은 데이터베이스에 저장되어, 이후 모든 데이터 조작 작업에서 자동으로 검사된다.

데이터 조작 시의 검사

데이터를 삽입, 수정, 삭제할 때마다 DBMS는 정의된 무결성 제약조건을 위반하지 않는지 자동으로 검사한다.

새로운 튜플을 삽입할 때는 기본키가 NULL이 아닌지, 기존에 동일한 키 값을 가진 튜플이 있는지, 외래키 값이 참조하는 릴레이션에 실제로 존재하는지를 검사한다. 이 중 하나라도 위반되면 삽입 작업은 거부된다.

기존 튜플을 수정할 때도 마찬가지로 변경된 값이 도메인을 벗어나지 않는지, 기본키를 NULL로 바꾸려 하지는 않는지, 외래키 값이 여전히 유효한 참조를 가리키는지를 검사한다.

튜플을 삭제할 때는 특히 참조 무결성과 관련해서 신중한 처리가 필요하다. 만약 학생 릴레이션에서 어떤 학생을 삭제하려는데, 수강 릴레이션에 그 학생의 학번을 참조하는 튜플이 남아있다면 문제가 생긴다. 이런 상황을 처리하는 방식은 보통 다음과 같은 옵션 중 하나로 정해둔다.

연쇄 삭제(Cascade)는 참조하는 쪽의 튜플도 함께 삭제하는 방식이다.

널 처리(Set Null)는 참조하는 쪽의 외래키 값을 NULL로 바꾸는 방식이다. 이 방식은 외래키가 NULL을 허용하도록 설계되어 있을 때만 가능하다.

제한(Restrict)은 참조하는 튜플이 남아있는 한 삭제 자체를 거부하는 방식이다.

제약조건 위반 시의 처리

DBMS는 무결성 제약조건을 위반하는 작업이 시도되면 그 작업을 거부하고 오류를 반환한다. 이렇게 함으로써 데이터베이스에 잘못된 데이터가 들어오는 것을 사전에 차단한다. 결국 무결성 제약조건이 잘 정의되어 있고 DBMS가 이를 충실히 수행한다면, 응용 프로그램을 작성하는 개발자가 일일이 데이터의 정확성을 검사하는 코드를 작성할 필요가 줄어들게 된다.