데이터베이스는 단순히 데이터를 쌓아두는 창고가 아니라, 정확하고 신뢰할 수 있는 정보를 제공해야 하는 시스템의 심장부입니다. 만약 은행 데이터베이스에 고객의 잔고가 음수로 기록되거나, 쇼핑몰에 존재하지도 않는 상품이 주문되는 일이 벌어진다면 어떻게 될까요? 상상만 해도 끔찍한 데이터의 대혼란이 발생할 것입니다. ‘데이터 무결성(Data Integrity)’은 바로 이러한 데이터의 오류, 불일치, 중복을 막고 데이터베이스에 저장된 데이터가 항상 정확하고 일관된 상태를 유지하도록 보장하는 핵심적인 성질입니다.
무결성은 데이터베이스 시스템이 스스로 데이터의 정합성을 지키도록 강제하는 규칙들의 집합으로, 데이터베이스 설계의 가장 중요한 목표 중 하나입니다. 이는 마치 사회의 질서를 유지하는 법과 같은 역할을 합니다. 이번 글에서는 데이터베이스의 신뢰도를 결정짓는 가장 중요한 5가지 무결성 제약조건, 즉 개체 무결성, 참조 무결성, 속성(도메인) 무결성, 사용자 정의 무결성, 그리고 이 모든 것의 기반이 되는 키 무결성에 대해 심도 있게 알아보고, 이들이 어떻게 유기적으로 작용하여 데이터의 가치를 지켜내는지 살펴보겠습니다.
개체 무결성 (Entity Integrity): 모든 데이터는 고유한 신분증을 가져야 한다
개체 무결성은 테이블 내의 모든 행(Row)이 고유하게 식별 가능해야 한다는 규칙입니다. 이는 마치 세상의 모든 사람이 각자 고유한 주민등록번호를 가지는 것과 같습니다. 만약 주민등록번호가 같은 사람이 둘 있다면, 그 둘을 명확히 구분할 수 없어 큰 혼란이 발생할 것입니다. 데이터베이스의 테이블에서도 마찬가지로, 각 행을 유일하게 식별할 수 있는 장치가 없다면 데이터를 정확하게 관리하고 참조하는 것이 불가능해집니다.
이러한 개체 무결성을 보장하기 위해 사용하는 핵심 도구가 바로 ‘기본키(Primary Key)’입니다. 기본키는 테이블의 수많은 속성 중에서 각 행을 대표하는 유일한 식별자로 선정된 키입니다.
기본키의 두 가지 약속
데이터베이스 시스템은 기본키에 두 가지 엄격한 제약 조건을 강제함으로써 개체 무결성을 실현합니다.
- 유일성(Uniqueness): 기본키로 지정된 열의 값은 테이블 내에서 절대 중복되어서는 안 됩니다. 예를 들어, ‘학생’ 테이블에서 ‘학번’을 기본키로 지정했다면, 동일한 학번을 가진 학생이 두 번 이상 등록될 수 없습니다. 시스템이 이를 원천적으로 차단합니다.
- NULL 값 불허(Not Null): 기본키 열에는 절대 NULL 값이 들어올 수 없습니다. NULL은 ‘값이 존재하지 않음’ 또는 ‘알 수 없는 값’을 의미하는데, 모든 개체를 식별해야 하는 신분증과 같은 기본키에 값이 없다는 것은 논리적으로 모순이기 때문입니다.
아래 ‘도서’ 테이블의 예를 살펴보겠습니다.
| 도서번호 (PK) | 도서명 | 저자 | 가격 |
| BK-101 | 데이터베이스의 이해 | 이지은 | 28000 |
| BK-102 | SQL 첫걸음 | 박서준 | 25000 |
| BK-101 | 네트워크 개론 | 김민수 | 30000 |
| NULL | 파이썬 프로그래밍 | 최수빈 | 27000 |
‘도서번호’를 기본키(PK)로 설정하면, 세 번째 행처럼 이미 존재하는 ‘BK-101’을 또다시 입력하려는 시도는 ‘유일성 위배’ 오류를 발생시키며 거부됩니다. 마찬가지로 네 번째 행처럼 도서번호를 비워두고(NULL) 데이터를 입력하려는 시도 역시 ‘NULL 값 불허’ 규칙에 따라 차단됩니다.
이처럼 개체 무결성은 기본키라는 강력한 제약을 통해 각 데이터 행이 자신만의 명확한 정체성을 갖도록 보장하며, 이는 데이터 관리의 가장 기본적인 출발점이 됩니다.
참조 무결성 (Referential Integrity): 관계는 허상을 좇지 않는다
참조 무결성은 두 테이블 사이의 관계가 항상 유효하고 일관된 상태를 유지해야 한다는 규칙입니다. 이는 주로 ‘외래키(Foreign Key)’를 통해 보장되며, 관계형 데이터베이스의 핵심적인 특징을 가장 잘 보여주는 개념입니다. 외래키는 한 테이블의 열이 다른 테이블의 기본키를 참조하여 테이블 간의 연결고리를 만드는 역할을 합니다.
참조 무결성의 핵심 원칙은 “자식 테이블의 외래키 값은 반드시 부모 테이블의 기본키 값 중 하나이거나, 혹은 NULL 값이어야 한다”는 것입니다. 여기서 부모 테이블은 기본키를 통해 참조되는 쪽이고, 자식 테이블은 외래키를 통해 참조하는 쪽입니다. 이 규칙은 현실 세계의 관계와 매우 유사합니다. 예를 들어, 어떤 학생의 ‘소속 학과’ 정보는 반드시 학교에 실제로 ‘존재하는 학과’ 중 하나여야 합니다. 존재하지도 않는 유령 학과에 소속될 수는 없는 노릇입니다.
관계의 일관성을 지키는 외래키
‘학과’ 테이블과 ‘학생’ 테이블을 예로 들어 참조 무결성을 살펴보겠습니다.
학과 테이블 (부모 테이블)
| 학과코드 (PK) | 학과명 |
| CS | 컴퓨터공학 |
| MG | 경영학 |
| DS | 디자인 |
학생 테이블 (자식 테이블)
| 학번 (PK) | 이름 | 소속학과 (FK) |
| 1001 | 김민준 | CS |
| 1002 | 이서연 | MG |
| 1003 | 박도윤 | EE |
‘학생’ 테이블의 ‘소속학과’ 열은 ‘학과’ 테이블의 ‘학과코드'(기본키)를 참조하는 외래키(FK)입니다. 이 관계가 설정되면, ‘학생’ 테이블의 ‘소속학과’에는 반드시 ‘학과’ 테이블의 ‘학과코드’에 존재하는 값(CS, MG, DS)만 들어올 수 있습니다. 따라서 세 번째 행처럼 존재하지 않는 ‘EE’라는 학과코드를 입력하려고 하면, 데이터베이스는 ‘참조 무결성 위배’ 오류를 발생시키며 이를 막습니다.
또한, 참조 무결성은 데이터의 변경 및 삭제 작업에도 영향을 미칩니다.
- 부모 테이블 데이터 삭제/변경 시: ‘학과’ 테이블에서 ‘CS’ 학과를 삭제하려고 할 때, ‘학생’ 테이블에 ‘CS’를 참조하는 학생(김민준)이 한 명이라도 존재한다면, 기본적으로 삭제가 제한됩니다. 이는 고아가 되는 데이터를 방지하기 위함입니다. 물론, 설정을 통해 부모 데이터가 삭제될 때 자식 데이터도 함께 삭제(ON DELETE CASCADE)되거나, 자식 데이터의 외래키 값을 NULL로 변경(ON DELETE SET NULL)하도록 지정할 수도 있습니다.
- 자식 테이블 데이터 삽입 시: 위에서 본 것처럼 존재하지 않는 부모 키 값을 참조하는 데이터는 삽입할 수 없습니다.
이처럼 참조 무결성은 테이블 간의 관계가 항상 논리적으로 타당한 상태를 유지하도록 강제하여, 데이터베이스 전체의 일관성과 안정성을 지키는 파수꾼 역할을 합니다.
속성(도메인) 무결성 (Attribute/Domain Integrity): 데이터는 제자리를 찾아야 한다
속성 무결성은 테이블의 특정 열(Attribute)에 입력되는 모든 데이터 값은 미리 정의된 데이터 타입과 형식, 그리고 값의 범위(Domain)를 반드시 따라야 한다는 규칙입니다. 이는 각 데이터가 자신의 성격에 맞는 옷을 입도록 강제하는 것과 같습니다. 예를 들어, ‘나이’ 열에는 숫자만 들어와야 하고, ‘성별’ 열에는 ‘남’ 또는 ‘여’라는 정해진 값만 들어와야 하며, ‘이메일’ 열에는 ‘@’ 기호가 포함된 형식의 문자열이 들어와야 합니다.
속성 무결성은 데이터가 애초에 잘못된 형태로 입력되는 것을 원천적으로 차단하여 데이터의 품질과 신뢰도를 높이는 가장 기본적인 방어선입니다. 이는 다음과 같은 제약 조건들을 통해 구현됩니다.
데이터의 형식을 정의하는 규칙들
- 데이터 타입(Data Type): 모든 열은 정의될 때 반드시 숫자(INTEGER, NUMBER), 문자열(VARCHAR, CHAR), 날짜(DATE, TIMESTAMP) 등 명확한 데이터 타입을 가져야 합니다. ‘나이’ 열에 ‘스무살’이라는 문자가 입력되는 것을 막아줍니다.
- NULL 값 허용 여부(NULL/NOT NULL): 개체 무결성의 기본키처럼, 일반 열에도 NOT NULL 제약 조건을 설정하여 필수 입력 항목에 값이 비는 것을 방지할 수 있습니다. 예를 들어, ‘회원’ 테이블의 ‘이름’ 열은 비워둘 수 없도록 설정할 수 있습니다.
- 기본값(DEFAULT): 데이터 입력 시 특정 열에 값이 주어지지 않았을 때 자동으로 입력될 기본값을 미리 지정할 수 있습니다. 예를 들어, ‘가입일’ 열의 기본값을 현재 시간으로 설정하거나, ‘포인트’ 열의 기본값을 0으로 설정할 수 있습니다.
- CHECK 제약: 특정 열에 입력될 수 있는 값의 범위나 조건을 직접 명시하는 강력한 규칙입니다.
나이 >= 19(19세 이상만 허용)성별 IN ('남', '여')(‘남’ 또는 ‘여’만 허용)가격 > 0(가격은 양수여야 함)이메일 LIKE '%@%.%'(이메일 형식 검사)
이러한 CHECK 제약은 비즈니스 로직 상 매우 중요한 규칙들을 데이터베이스 레벨에서 강제하여 응용 프로그램의 오류와 관계없이 데이터의 정합성을 보장해 줍니다. 예를 들어, 쇼핑몰의 ‘재고수량’이 음수가 되는 치명적인 오류를 데이터베이스 스스로가 막아줄 수 있습니다.
사용자 정의 무결성 (User-Defined Integrity): 우리 회사만의 특별한 규칙
지금까지 살펴본 개체, 참조, 속성 무결성이 대부분의 데이터베이스 환경에 공통적으로 적용되는 일반적인 규칙이라면, 사용자 정의 무결성은 각 시스템의 고유한 비즈니스 규칙과 요구사항을 데이터베이스에 직접 반영하는 것입니다. 이는 법률로 정해진 보편적인 규칙 외에, 특정 조직이나 회사 내부의 고유한 규정을 만드는 것과 같습니다.
사용자 정의 무결성은 주로 데이터베이스의 ‘트리거(Trigger)’나 ‘스토어드 프로시저(Stored Procedure)’와 같은 기능을 사용하여 구현됩니다.
비즈니스 로직을 자동화하는 트리거
트리거는 특정 테이블에 데이터의 삽입(INSERT), 수정(UPDATE), 삭제(DELETE) 같은 이벤트가 발생했을 때, 자동으로 실행되도록 미리 정의해 둔 SQL 코드 블록입니다. 이를 통해 복잡한 비즈니스 규칙을 데이터베이스가 스스로 실행하도록 만들 수 있습니다.
예를 들어, 다음과 같은 사용자 정의 무결성 규칙을 트리거로 구현할 수 있습니다.
- ‘주문’ 테이블에 새로운 주문이 들어오면(INSERT), 자동으로 ‘재고’ 테이블에서 해당 상품의 수량을 감소시킨다.
- ‘직원’ 테이블에서 직원의 급여를 수정할 때(UPDATE), 인상률이 20%를 초과하지 못하도록 검사하고, 만약 초과하면 변경을 취소시킨다.
- ‘게시글’ 테이블의 데이터가 삭제될 때(DELETE), 실제 데이터를 물리적으로 지우는 대신 ‘삭제여부’ 플래그만 ‘Y’로 변경하고, 삭제 로그 테이블에 관련 기록을 남긴다.
- 은행의 ‘계좌’ 테이블에서 출금 작업이 발생할 때, 출금액이 현재 잔고보다 클 수 없다는 규칙을 적용한다.
이처럼 사용자 정의 무결성은 데이터베이스가 단순한 데이터 저장소를 넘어, 비즈니스 로직의 일부를 능동적으로 수행하게 함으로써 데이터의 일관성을 더욱 강화하고, 응용 프로그램의 부담을 줄여주는 역할을 합니다.
키 무결성 (Key Integrity): 모든 무결성의 근간
키 무결성은 사실 독립적인 무결성이라기보다는, 위에서 설명한 개체 무결성과 참조 무결성을 포괄하고 지원하는 더 근본적인 개념입니다. 키 무결성은 테이블의 모든 키(기본키, 후보키, 외래키 등)가 가져야 할 제약 조건들이 항상 만족되어야 함을 의미합니다.
- 기본키(Primary Key)와 후보키(Candidate Key)는 반드시 유일한 값을 가져야 하며(유일성), NULL 값을 허용하지 않습니다(개체 무결성). 이를 통해 각 행을 고유하게 식별할 수 있습니다.
- 대체키(Alternate Key)는 기본키는 아니지만 유일성(UNIQUE 제약)을 가져야 하는 경우가 많습니다. 이는 이메일 주소나 주민등록번호처럼, 비록 기본 식별자는 아니지만 중복되어서는 안 되는 중요한 데이터의 무결성을 보장합니다(속성 무결성의 일부).
- 외래키(Foreign Key)는 참조하는 테이블의 기본키 값과 일치하거나 NULL이어야 합니다(참조 무결성). 이를 통해 테이블 간의 관계가 깨지지 않도록 보장합니다.
결국, 데이터베이스의 모든 무결성 규칙은 ‘키’라는 도구를 통해 정의되고 강제된다고 볼 수 있습니다. 적절한 키를 설계하고 제약 조건을 부여하는 것이야말로 데이터 무결성을 확보하는 가장 핵심적인 활동입니다. 키가 제대로 정의되지 않으면 개체 식별이 불가능해지고, 테이블 간의 관계도 신뢰할 수 없게 되며, 결국 데이터베이스 전체가 모래성처럼 무너져 내릴 수 있습니다.
마무리: 신뢰할 수 있는 데이터 시스템을 위한 약속
데이터 무결성은 데이터베이스의 생명과도 같습니다. 개체 무결성은 데이터의 정체성을, 참조 무결성은 데이터 간의 관계를, 속성 무결성은 데이터의 형식을, 사용자 정의 무결성은 비즈니스의 논리를, 그리고 키 무결성은 이 모든 것의 기반을 지켜주는 약속입니다. 이 다섯 가지 무결성 제약조건이 서로 얽히고설켜 견고한 그물망을 형성할 때, 비로소 우리의 데이터베이스는 어떠한 오류나 비일관성에도 흔들리지 않는 신뢰의 반석 위에 설 수 있습니다.
데이터베이스를 설계하고 운영할 때 이러한 무결성 규칙들을 깊이 이해하고 적극적으로 활용하는 것은 선택이 아닌 필수입니다. 이는 단순히 오류를 방지하는 소극적인 차원을 넘어, 데이터의 가치를 극대화하고, 데이터 기반의 의사결정이 항상 정확한 정보 위에서 이루어지도록 보장하는 가장 능동적이고 중요한 활동임을 반드시 기억해야 합니다.