데이터베이스 무결성: 두 판 사이의 차이

IT위키
편집 요약 없음
 
(같은 사용자의 중간 판 2개는 보이지 않습니다)
1번째 줄: 1번째 줄:
[[분류:데이터베이스]]
'''Database Integrity'''
;권한 부여된 사용자들에 의해 야기될 수 있는 의미적 에러를 방지하고, 데이터베이스가 현실 세계의 올바른 데이터를 갖도록 보장하는 특성
 
{| class="wikitable"
'''데이터베이스 무결성은 데이터의 일관성과 정확성을 유지하기 위한 규칙 및 제약 조건의 집합이다.'''
|-
 
! 구분 !! 설명 !! 예시
* 예를 들면 기본 키는 반드시 Null이 되어서는 안되고 중복되지 않는 값을 가져야 한다는 규칙 등을 말한다. 3~5가지 정도로 나뉜다.
|-
 
| 개체 무결성
== 종류 ==
(Entity Integrity)
주요하게는 아래 3가지가 가장 많이 언급된다. 자세한 내용은 클릭하여 각 문서 확인.
||
 
* 기본키는 반드시 값을 가짐(NOT NULL)
* '''[[데이터베이스 개체 무결성|개체 무결성 (Entity Integrity)]]'''
||
** 테이블의 각 행이 고유하게 식별될 수 있도록 하는 제약 조건으로, 주로 기본 키(primary key)를 사용해 한 행의 식별자를 null로 설정하지 못하게 하여 데이터의 무결성을 보장한다.
* PK is not null
* '''[[데이터베이스 참조 무결성|참조 무결성 (Referential Integrity)]]'''
|-
** 테이블 간의 관계에서 외래 키(foreign key)를 통해 데이터의 일관성을 보장한다. 외래 키 값은 반드시 참조하는 테이블의 기본 키 값을 가져야 하며, 이를 통해 두 테이블 간의 관계가 깨지지 않도록 한다.
| 참조 무결성
* '''[[데이터베이스 도메인 무결성|도메인 무결성 (Domain Integrity)]]'''
(Referential Integrity)
** 각 속성(컬럼)이 특정한 데이터 타입과 값의 범위를 가지도록 하는 제약입니다. 이는 속성에 허용되는 값이 미리 정의된 도메인 내에 있어야 하며, 데이터 타입이나 NULL 값의 사용 여부 등을 제한한다.
||
 
* 외래키는 참조되는 릴레이션의 PK거나 NULL이어야 함
다만 좀 더 세부적으로 나누거나, 일부 중복이 포함된 개념 등을 포함하면 5가지 이상으로 나열할 수도 있다.
||
 
* Foreign Key
* [[데이터베이스 키 무결성|'''키 무결성 (Key Integrity)''']]
|-
** 키 무결성은 개체 무결성과 참조 무결성을 아우르는 표현이다. 둘의 구분이 명확하기에 굳이 키 무결성이 별도로 언급되는 경우는 흔치 않다.
| 속성 무결성
* [[데이터베이스 사용자 정의 무결성|'''사용자 정의 무결성 (User-defined Integrity)''']]
(Attribute Integrity)
** 사용자가 정의한 모든 다른 비즈니스 규칙이 사용자 정의 무결성에 포함될 수 있다. 의미적 무결성(Semantic Integrity)와 동일한 개념으로 보기도 한다. 차이점은 아래 섹션에서 확인 가능
||
 
* 속성은 지정된 형식에 맞는 값이어야 함
== 그 외 ==
||
 
* Data Type
=== 의미적 무결성 ===
* Null/Not Null
'''Semantic Integrity'''
|-
 
| 키 무결성
기존의 개체, 참조, 도메인 무결성과는 다른 개념으로, 비즈니스 규칙이나 데이터의 논리적 관계 유지, 값의 세부적인 조건 등을 정의하는 무결성을 말한다.
(Key Integrity)
 
||
* 예를 들면 신용카드 신청 테이블에 값이 삽입되기 위해선 고객 테이블의 가입일로부터 3개월 이상 지나야 한다는 등의 비즈니스적인 조건이 이에 해당된다.
* 한 릴레이션에 각 키는 유일해야 한다.
 
||
'''사용자 정의 무결성과의 관계'''
* Primary Key
 
|-
사용자 정의 무결성과 매우 유사하다. 그래서 의미적 무결성을 언급하는 책에서는 "사용자 정의 무결성"을 따로 언급하지 않는 경우가 많다. 만약 둘다 언급을 한다면 사용자 정의 무결성은 DDL 관점에서의 사용자 정의 무결성, 의미적 무결성은 그 외 애플리케이션에서 구현되어야 하는 무결성으로 구분하기도 한다. 이는 개체, 참조, 도메인 무결성이 모두 DDL로 구현이 되는데, 애초에 의미적 무결성은 DDL 관점을 벗어난 무결성으로 등장한 개념이기 때문이다. 하지만 최근 DBMS들의 기능이 향상되고 다양한 제약 조건들을 지원하면서 대부분 DDL 또는 DBMS 기능 자체로 제약 조건을 구현할 수 있게 되면서 구분이 애매해졌다.<ref>국가마다 구현 스타일이 천차만별이긴 하지만 현재 추세는, 편의상 DB의 제약 조건을 최소화하고 애플리케이션에서 제약 조건을 구현하는 경우가 많다. 즉 DBMS에 기능은 충분히 있어서 거의 대부분의 검증이 DB 자체적으로 가능하지만 이런 경우 예외처리가 어려워지므로 애플리케이션에서 직접 구현하는 것이다.</ref>
| 사용자정의 무결성
 
도메인 무결성
=== 상태에 따른 무결성 ===
이 또한 분류의 관점 자체가 다르므로 개체, 참조, 도메인과 함께 나열할 순 없다. 이는 상태의 변화를 기준으로 아래와 같이 나뉜다.
 
==== 상태 제약 (State Constraints) ====
 
* '''정의''': 상태 제약은 데이터베이스의 '''현재 상태'''에서 데이터가 만족해야 하는 조건을 의미한다. 즉, 특정 시점에서 데이터가 유효한지 여부를 검증하는 제약이다.
* '''예시''': 고객 테이블에서 모든 고객의 나이는 18세 이상이어야 한다는 규칙을 설정할 수 있다. 이 경우, 데이터베이스에 저장된 모든 고객의 나이는 항상 18세 이상이어야 하며, 이를 어기면 데이터 입력이나 업데이트가 허용되지 않는다.
* '''일반적으로 개체, 참조, 도메인 무결성 제약 조건을 모두 상태 제약 조건에 포함'''시킨다.
 
==== 전이 제약 (Transition Constraints) ====


(Domain Integrity)
* '''정의''': 전이 제약은 '''데이터 상태 간의 변화'''를 규정하는 제약이다. 즉, 데이터베이스가 특정 상태에서 다른 상태로 전이될 때, 그 변화가 유효한지를 확인하는 규칙이다. 전이 제약은 데이터가 변할 때 그 변화를 허용할지 여부를 결정하는 데 중점을 둔다.
||
* '''예시''': 예를 들어, 직원의 직급은 절대 낮아질 수 없다는 규칙을 적용할 수 있다. 이 경우, 직원의 직급이 승진하는 것은 허용되지만, 강등되는 전이는 허용되지 않는다.
* 속성은 업무적으로 정합한 값이어야 함
||
* Check Constraint
* SW Validation
|}
* 이에 대한 표준은 정해져 있지 않은 것으로 보인다<ref>확인 필요</ref>
** 국내외 문서마다 분류 기준이 조금씩 다름
* '[https://raisonde.tistory.com/entry/데이터베이스-관계-데이타-모델과-관계-제약조건 제약조건]'의 관점에서 보느냐 '무결성'의 관점에서 보느냐의 차이도 존재함
* 초기 [[관계대수]]의 이론을 기준으로 보느냐, 현대 실무적 관점에서 보느냐의 차이도 존재함


== [[참조 무결성 제약]] ==
== 각주 ==
;Relational Integrity Constraint
[[분류:데이터베이스]]
{| class="wikitable"
|-
! 기능 !! 구분
|-
| Restrict ||
* 부모 테이블의 참조 대상 키가 삭제 또는 변경되는 것을 불허
* 자식 테이블의 참조값을 변경하는 경우, 부모 테이블에 있는 참조 대상 키가 있는 경우만 허용
|-
| Cascade || 부모 테이블의 참조 대상 키가 삭제되면 자식 테이블의 참조 튜플 삭제
|-
| Nullify || 부모 테이블의 참조 대상 키가 삭제되면 자식 테이블의 참조값을 Null로 변경
|-
| Default || 부모 테이블의 참조 대상 키가 삭제되면 미리 정의한 Default 값으로 변경
|}

2024년 9월 27일 (금) 00:20 기준 최신판

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)[편집 | 원본 편집]

  • 정의: 전이 제약은 데이터 상태 간의 변화를 규정하는 제약이다. 즉, 데이터베이스가 특정 상태에서 다른 상태로 전이될 때, 그 변화가 유효한지를 확인하는 규칙이다. 전이 제약은 데이터가 변할 때 그 변화를 허용할지 여부를 결정하는 데 중점을 둔다.
  • 예시: 예를 들어, 직원의 직급은 절대 낮아질 수 없다는 규칙을 적용할 수 있다. 이 경우, 직원의 직급이 승진하는 것은 허용되지만, 강등되는 전이는 허용되지 않는다.

각주[편집 | 원본 편집]

  1. 국가마다 구현 스타일이 천차만별이긴 하지만 현재 추세는, 편의상 DB의 제약 조건을 최소화하고 애플리케이션에서 제약 조건을 구현하는 경우가 많다. 즉 DBMS에 기능은 충분히 있어서 거의 대부분의 검증이 DB 자체적으로 가능하지만 이런 경우 예외처리가 어려워지므로 애플리케이션에서 직접 구현하는 것이다.