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)와 동일한 개념으로 보기도 한다. 차이점은 아래 섹션에서 확인 가능
그 외
의미적 무결성
Semantic Integrity
기존의 개체, 참조, 도메인 무결성과는 다른 개념으로, 비즈니스 규칙이나 데이터의 논리적 관계 유지, 값의 세부적인 조건 등을 정의하는 무결성을 말한다.
- 예를 들면 신용카드 신청 테이블에 값이 삽입되기 위해선 고객 테이블의 가입일로부터 3개월 이상 지나야 한다는 등의 비즈니스적인 조건이 이에 해당된다.
사용자 정의 무결성과의 관계
사용자 정의 무결성과 매우 유사하다. 그래서 의미적 무결성을 언급하는 책에서는 "사용자 정의 무결성"을 따로 언급하지 않는 경우가 많다. 만약 둘다 언급을 한다면 사용자 정의 무결성은 DDL 관점에서의 사용자 정의 무결성, 의미적 무결성은 그 외 애플리케이션에서 구현되어야 하는 무결성으로 구분하기도 한다. 이는 개체, 참조, 도메인 무결성이 모두 DDL로 구현이 되는데, 애초에 의미적 무결성은 DDL 관점을 벗어난 무결성으로 등장한 개념이기 때문이다. 하지만 최근 DBMS들의 기능이 향상되고 다양한 제약 조건들을 지원하면서 대부분 DDL 또는 DBMS 기능 자체로 제약 조건을 구현할 수 있게 되면서 구분이 애매해졌다.[1]
상태에 따른 무결성
이 또한 분류의 관점 자체가 다르므로 개체, 참조, 도메인과 함께 나열할 순 없다. 이는 상태의 변화를 기준으로 아래와 같이 나뉜다.
상태 제약 (State Constraints)
- 정의: 상태 제약은 데이터베이스의 현재 상태에서 데이터가 만족해야 하는 조건을 의미한다. 즉, 특정 시점에서 데이터가 유효한지 여부를 검증하는 제약이다.
- 예시: 고객 테이블에서 모든 고객의 나이는 18세 이상이어야 한다는 규칙을 설정할 수 있다. 이 경우, 데이터베이스에 저장된 모든 고객의 나이는 항상 18세 이상이어야 하며, 이를 어기면 데이터 입력이나 업데이트가 허용되지 않는다.
- 일반적으로 개체, 참조, 도메인 무결성 제약 조건을 모두 상태 제약 조건에 포함시킨다.
전이 제약 (Transition Constraints)
- 정의: 전이 제약은 데이터 상태 간의 변화를 규정하는 제약이다. 즉, 데이터베이스가 특정 상태에서 다른 상태로 전이될 때, 그 변화가 유효한지를 확인하는 규칙이다. 전이 제약은 데이터가 변할 때 그 변화를 허용할지 여부를 결정하는 데 중점을 둔다.
- 예시: 예를 들어, 직원의 직급은 절대 낮아질 수 없다는 규칙을 적용할 수 있다. 이 경우, 직원의 직급이 승진하는 것은 허용되지만, 강등되는 전이는 허용되지 않는다.
각주
- ↑ 국가마다 구현 스타일이 천차만별이긴 하지만 현재 추세는, 편의상 DB의 제약 조건을 최소화하고 애플리케이션에서 제약 조건을 구현하는 경우가 많다. 즉 DBMS에 기능은 충분히 있어서 거의 대부분의 검증이 DB 자체적으로 가능하지만 이런 경우 예외처리가 어려워지므로 애플리케이션에서 직접 구현하는 것이다.