본문으로 이동
메뉴 여닫기
환경 설정 메뉴 여닫기
개인 메뉴 여닫기
로그인하지 않음
지금 편집한다면 당신의 IP 주소가 공개될 수 있습니다.

Database Integrity

데이터베이스 무결성은 데이터의 일관성과 정확성을 유지하기 위한 규칙 및 제약 조건의 집합이다.

  • 예를 들면 기본 키는 반드시 Null이 되어서는 안되고 중복되지 않는 값을 가져야 한다는 규칙 등을 말한다. 3~5가지 정도로 나뉜다.

주요하게는 아래 3가지가 가장 많이 언급된다. 자세한 내용은 클릭하여 각 문서 확인.

  • 개체 무결성 (Entity Integrity)
    • 테이블의 각 행이 고유하게 식별될 수 있도록 하는 제약 조건으로, 주로 기본 키(primary key)를 사용해 한 행의 식별자를 null로 설정하지 못하게 하여 데이터의 무결성을 보장한다.
  • 참조 무결성 (Referential Integrity)
    • 테이블 간의 관계에서 외래 키(foreign key)를 통해 데이터의 일관성을 보장한다. 외래 키 값은 반드시 참조하는 테이블의 기본 키 값을 가져야 하며, 이를 통해 두 테이블 간의 관계가 깨지지 않도록 한다.
  • 도메인 무결성 (Domain Integrity)
    • 각 속성(컬럼)이 특정한 데이터 타입과 값의 범위를 가지도록 하는 제약입니다. 이는 속성에 허용되는 값이 미리 정의된 도메인 내에 있어야 하며, 데이터 타입이나 NULL 값의 사용 여부 등을 제한한다.

다만 좀 더 세부적으로 나누거나, 일부 중복이 포함된 개념 등을 포함하면 5가지 이상으로 나열할 수도 있다.

  • 키 무결성 (Key Integrity)
    • 키 무결성은 개체 무결성과 참조 무결성을 아우르는 표현이다. 둘의 구분이 명확하기에 굳이 키 무결성이 별도로 언급되는 경우는 흔치 않다.
  • 사용자 정의 무결성 (User-defined Integrity)
    • 사용자가 정의한 모든 다른 비즈니스 규칙이 사용자 정의 무결성에 포함될 수 있다. 의미적 무결성(Semantic Integrity)와 동일한 개념으로 보기도 한다. 차이점은 아래 섹션에서 확인 가능

갱신 연산과 제약조건 위반

편집 원본 편집

관계 데이터 모델의 기본 제약조건은 도메인 제약조건, 키 제약조건, 엔티티(개체) 무결성 제약조건, 참조 무결성 제약조건이다. 키 제약조건은 후보 키 값이 투플마다 달라야 한다는 것이고, 엔티티 무결성은 기본 키가 NULL 일 수 없다는 것이다. 갱신 연산마다 위배할 수 있는 제약조건이 다르다.[1]

연산 위배할 수 있는 제약조건 예
삽입(INSERT) 네 가지 모두 도메인 밖의 값(도메인), 이미 있는 키 값(키), 기본 키가 NULL(엔티티 무결성), 참조되는 릴레이션에 없는 외래 키 값(참조 무결성)
삭제(DELETE) 참조 무결성만 다른 투플이 외래 키로 참조하고 있는 투플을 지울 때. 거부(RESTRICT/NO ACTION), 연쇄 삭제(CASCADE), NULL 이나 기본값으로 바꾸기(SET NULL/SET DEFAULT) 가운데 하나로 처리한다
수정(UPDATE) 바꾸는 속성에 따라 네 가지 모두 일반 속성은 도메인만, 기본 키를 바꾸면 삭제 후 삽입과 같아 키·엔티티·참조 무결성, 외래 키를 바꾸면 참조 무결성과 도메인

제약조건을 어기는 갱신은 DBMS 가 거부한다. 오라클은 NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY, CHECK 제약조건을 데이터베이스가 직접 검사하고, 위반하는 DML 문은 오류를 내며 되돌린다고 설명한다.[2]

Integrity Rule

무결성 규정은 데이터베이스의 데이터가 언제나 정확하고 일관된 상태를 유지하도록, 데이터가 지켜야 할 조건을 명세한 것이다.

  • 구성 요소: 규정 이름, 규정을 검사할 시기, 데이터가 만족해야 할 제약 조건, 규정을 참조할 때 쓰는 식별자, 규정을 어겼을 때의 조치
  • 대상: 도메인, 키, 종속성(함수 종속 등)
  • 도메인 무결성 규정 - 각 속성 값이 도메인(형식·범위)에 맞는지 정한다
  • 릴레이션 무결성 규정(Relation Integrity Rules) - 릴레이션을 삽입·삭제·갱신하며 조작하는 과정에서 지켜야 할 의미적 관계(Semantic Relationship)를 명세한다

무결성과 보안

편집 원본 편집
  • 무결성은 허가받은 사용자가 데이터를 갱신할 때 실수나 잘못된 값으로 데이터의 정확성·일관성이 깨지지 않게 지키는 것이다
  • 보안은 허가받지 않은 사용자의 불법적인 접근·갱신·파괴로부터 데이터를 지키는 것이다 → 데이터베이스 보안
  • "정식으로 허가받지 않은 불법적인 사용자에 의한 갱신으로부터 데이터베이스를 보호하는 규정"은 보안의 설명이지 무결성 규정의 설명이 아니다

의미적 무결성

편집 원본 편집

Semantic Integrity

기존의 개체, 참조, 도메인 무결성과는 다른 개념으로, 비즈니스 규칙이나 데이터의 논리적 관계 유지, 값의 세부적인 조건 등을 정의하는 무결성을 말한다.

  • 예를 들면 신용카드 신청 테이블에 값이 삽입되기 위해선 고객 테이블의 가입일로부터 3개월 이상 지나야 한다는 등의 비즈니스적인 조건이 이에 해당된다.

사용자 정의 무결성과의 관계

사용자 정의 무결성과 매우 유사하다. 그래서 의미적 무결성을 언급하는 책에서는 "사용자 정의 무결성"을 따로 언급하지 않는 경우가 많다. 만약 둘다 언급을 한다면 사용자 정의 무결성은 DDL 관점에서의 사용자 정의 무결성, 의미적 무결성은 그 외 애플리케이션에서 구현되어야 하는 무결성으로 구분하기도 한다. 이는 개체, 참조, 도메인 무결성이 모두 DDL로 구현이 되는데, 애초에 의미적 무결성은 DDL 관점을 벗어난 무결성으로 등장한 개념이기 때문이다. 하지만 최근 DBMS들의 기능이 향상되고 다양한 제약 조건들을 지원하면서 대부분 DDL 또는 DBMS 기능 자체로 제약 조건을 구현할 수 있게 되면서 구분이 애매해졌다.[3]

상태에 따른 무결성

편집 원본 편집

이 또한 분류의 관점 자체가 다르므로 개체, 참조, 도메인과 함께 나열할 순 없다. 이는 상태의 변화를 기준으로 아래와 같이 나뉜다.

상태 제약 (State Constraints)

편집 원본 편집
  • 정의: 상태 제약은 데이터베이스의 현재 상태에서 데이터가 만족해야 하는 조건을 의미한다. 즉, 특정 시점에서 데이터가 유효한지 여부를 검증하는 제약이다.
  • 예시: 고객 테이블에서 모든 고객의 나이는 18세 이상이어야 한다는 규칙을 설정할 수 있다. 이 경우, 데이터베이스에 저장된 모든 고객의 나이는 항상 18세 이상이어야 하며, 이를 어기면 데이터 입력이나 업데이트가 허용되지 않는다.
  • 일반적으로 개체, 참조, 도메인 무결성 제약 조건을 모두 상태 제약 조건에 포함시킨다.

전이 제약 (Transition Constraints)

편집 원본 편집
  • 정의: 전이 제약은 데이터 상태 간의 변화를 규정하는 제약이다. 즉, 데이터베이스가 특정 상태에서 다른 상태로 전이될 때, 그 변화가 유효한지를 확인하는 규칙이다. 전이 제약은 데이터가 변할 때 그 변화를 허용할지 여부를 결정하는 데 중점을 둔다.
  • 예시: 예를 들어, 직원의 직급은 절대 낮아질 수 없다는 규칙을 적용할 수 있다. 이 경우, 직원의 직급이 승진하는 것은 허용되지만, 강등되는 전이는 허용되지 않는다.
  1. ↑ Ramez Elmasri, Shamkant B. Navathe, 『Fundamentals of Database Systems』 7판, Pearson, 2016, 5.3 Update Operations, Transactions, and Dealing with Constraint Violations.
  2. ↑ 「Data Integrity」, Oracle Database Concepts 19c, Oracle, https://docs.oracle.com/en/database/oracle/oracle-database/19/cncpt/data-integrity.html, 확인일: 2026-11-04.
  3. ↑ 국가마다 구현 스타일이 천차만별이긴 하지만 현재 추세는, 편의상 DB의 제약 조건을 최소화하고 애플리케이션에서 제약 조건을 구현하는 경우가 많다. 즉 DBMS에 기능은 충분히 있어서 거의 대부분의 검증이 DB 자체적으로 가능하지만 이런 경우 예외처리가 어려워지므로 애플리케이션에서 직접 구현하는 것이다.