[오라클] Oracle® Database Concepts 챕터 5 한글 번역

torch·2024년 7월 17일

db oracle

Oracle

목록 보기

4/13

Reference : Database Concepts - 5. Data Integrity

*GPT 번역 기반으로 내용이 정확하지 않을 수 있습니다.

Data Integrity

이 장에서는 데이터베이스와 관련된 비즈니스 규칙을 강제하는 무결성 제약 조건이 데이터베이스 테이블에 잘못된 정보의 입력을 방지하는 방법에 대해 설명합니다.

이 장에는 다음과 같은 섹션이 포함되어 있습니다:

데이터 무결성 소개
무결성 제약 조건의 유형
무결성 제약 조건의 상태

Introduction to Data Integrity

데이터는 데이터베이스 관리자나 애플리케이션 개발자가 결정한 비즈니스 규칙을 준수함으로써 데이터 무결성을 유지하는 것이 중요합니다.

비즈니스 규칙은 항상 참이거나 항상 거짓이어야 하는 조건과 관계를 지정합니다. 예를 들어, 각 회사는 급여, 직원 번호, 재고 추적 등 자체 정책을 정의합니다.

Techniques for Guaranteeing Data Integrity

데이터베이스 애플리케이션을 설계할 때, 개발자는 데이터베이스에 저장된 데이터의 무결성을 보장하기 위해 여러 옵션을 사용할 수 있습니다.

이러한 옵션에는 다음이 포함됩니다:

트리거된 저장된 데이터베이스 절차로 비즈니스 규칙을 강제 실행
저장된 절차를 사용하여 데이터에 대한 액세스를 완전히 제어
데이터베이스 애플리케이션 코드에서 비즈니스 규칙을 강제 실행
Oracle 데이터베이스 무결성 제약 조건을 사용하여 데이터베이스에서 열 또는 객체 수준에서 정의된 규칙이 값을 제한

Advantages of Integrity Constraints

무결성 제약 조건은 SQL을 사용하여 생성 및 삭제되는 스키마 객체입니다. 데이터 무결성을 강제로 적용하려면 가능한 한 무결성 제약 조건을 사용하십시오.

데이터 무결성을 강제하는 대안에 대한 무결성 제약 조건의 이점은 다음과 같습니다:

선언적 용이성
- 무결성 제약 조건은 SQL 문을 사용하여 정의되므로 테이블을 정의하거나 변경할 때 추가 프로그래밍이 필요하지 않습니다. SQL 문은 작성하기 쉽고 프로그래밍 오류를 제거합니다.
중앙집중식 규칙
- 무결성 제약 조건은 테이블에 대해 정의되며 데이터 사전에 저장됩니다. 따라서 모든 애플리케이션에서 입력한 데이터는 동일한 무결성 제약 조건을 준수해야 합니다. 테이블 수준에서 규칙이 변경되면 애플리케이션을 변경할 필요가 없습니다. 또한, 애플리케이션은 데이터 사전의 메타데이터를 사용하여 데이터베이스가 SQL 문을 확인하기 전에 사용자에게 위반 사항을 즉시 알릴 수 있습니다.
데이터 로딩 시 유연성
- 대량의 데이터를 로딩할 때 성능 오버헤드를 피하기 위해 일시적으로 무결성 제약 조건을 비활성화할 수 있습니다. 데이터 로드가 완료되면 무결성 제약 조건을 다시 활성화할 수 있습니다.

Types of Integrity Constraints

Oracle 데이터베이스를 사용하면 테이블 및 열 수준에서 제약 조건을 적용할 수 있습니다.

열 또는 속성의 정의의 일부로 지정된 제약 조건은 인라인 사양입니다. 테이블 정의의 일부로 지정된 제약 조건은 아웃라인 사양입니다.

키는 특정 유형의 무결성 제약 조건의 정의에 포함된 열 또는 열 집합입니다. 키는 관계형 데이터베이스의 테이블 및 열 간의 관계를 설명합니다. 키의 개별 값은 키 값이라고 합니다.

다음 표는 제약 조건 유형을 설명합니다. 각각은 인라인 또는 아웃라인으로 지정할 수 있습니다. NOT NULL은 인라인으로만 지정해야 합니다.

표 5-1 무결성 제약 조건 유형

제약 조건 유형	설명	참고 자료
`NOT NULL`	지정된 열에서 null이 있는 행의 삽입 또는 업데이트를 허용하거나 금지합니다.	"NOT NULL 무결성 제약 조건"
고유 키	동일한 열 또는 열 조합에서 동일한 값을 가진 여러 행을 금지하지만 일부 값은 null일 수 있습니다.	"고유 제약 조건"
기본 키	`NOT NULL` 제약 조건과 고유 제약 조건을 결합합니다. 동일한 열 또는 열 조합에서 동일한 값을 가진 여러 행을 금지하고 값이 null인 것을 금지합니다.	"기본 키 제약 조건"
외래 키	열을 외래 키로 지정하고 외래 키와 기본 키 또는 고유 키(참조 키라고 함) 사이의 관계를 설정합니다.	"외래 키 제약 조건"
검사	데이터베이스 값이 지정된 조건을 준수하도록 요구합니다.	"검사 제약 조건"
`REF`	`REF` 열의 값에 허용되는 데이터 조작 유형을 지정하고 이러한 작업이 종속 값에 미치는 영향을 설명합니다. 객체 관계형 데이터베이스에서는 `REF`가 지정된 객체 유형의 행 객체에 대한 참조를 캡슐화하는 내장 데이터 유형입니다. `REF` 열에 대한 참조 무결성 제약 조건은 REF에 대한 행 객체가 있음을 보장합니다.	"`REF` 제약 조건에 대해 배우는 Oracle 데이터베이스 객체 관계형 개발자 가이드"

NOT NULL Integrity Constraints

NOT NULL 제약 조건은 테이블의 열이 null 값을 포함하지 않아야 함을 요구합니다. null은 값의 부재입니다. 기본적으로 테이블의 모든 열은 null을 허용합니다.

NOT NULL 제약 조건은 값이 부족해서는 안 되는 열에 적용됩니다. 예를 들어, hr.employees 테이블은 email 열에 값을 요구합니다. 이메일 주소 없이 직원 행을 삽입하려는 시도는 오류를 발생시킵니다:

SQL> INSERT INTO hr.employees (employee_id, last_name) values (999, 'Smith');
.
.
.
ERROR at line 1:
ORA-01400: cannot insert NULL into ("HR"."EMPLOYEES"."EMAIL")

테이블에 행이 없거나 기본 값을 지정하는 경우에만 NOT NULL 제약 조건이 있는 열을 추가할 수 있습니다.

Unique Constraints

고유 키 제약 조건은 열 또는 열 집합의 모든 값이 고유해야 함을 요구합니다. 고유 키 제약 조건이 있는 테이블의 행은 단일 열(고유 키) 또는 열 집합(복합 고유 키)에서 중복 값을 가질 수 없습니다.

참고: 키라는 용어는 무결성 제약 조건에 정의된 열에만 해당됩니다. 데이터베이스는 키 열에 암시적으로 생성되거나 재사용되는 인덱스를 사용하여 고유 제약 조건을 집행합니다. 때문에 때때로 고유 키라는 용어가 고유 키 제약 조건이나 고유 인덱스와 synonym으로 잘못 사용됩니다.

고유 키 제약 조건은 중복 값을 허용하지 않는 모든 열에 적합합니다. 고유 제약 조건은 각 테이블 행을 고유하게 식별하는 목적을 가진 기본 키 제약 조건과 다릅니다. 일반적으로 기본 키는 고유하기만 하면 되는 값들을 포함합니다. 고유 키의 예로는 다음이 있습니다:

고객 전화번호, 기본 키는 고객 번호입니다.
부서 이름, 기본 키는 부서 번호입니다.

예제 2-1에서 보여주듯이, hr.employees 테이블의 email 열에는 고유 키 제약 조건이 있습니다. 관련 부분은 다음과 같습니다:

CREATE TABLE employees    ( ...
    , email          VARCHAR2(25)
        CONSTRAINT   emp_email_nn  NOT NULL ...
    , CONSTRAINT     emp_email_uk  UNIQUE (email) ... );

emp_email_uk 제약 조건은 다음 예제에서 보여주듯이 두 명의 직원이 동일한 이메일 주소를 가지지 않도록 보장합니다:

SQL> SELECT employee_id, last_name, email FROM employees WHERE email = 'PFAY';
 
EMPLOYEE_ID LAST_NAME                 EMAIL
----------- ------------------------- -------------------------
        202 Fay                       PFAY

SQL> INSERT INTO employees (employee_id, last_name, email, hire_date, job_id)    
  1  VALUES (999,'Fay','PFAY',SYSDATE,'ST_CLERK');
.
.
.
ERROR at line 1:
ORA-00001: unique constraint (HR.EMP_EMAIL_UK) violated

NOT NULL 제약 조건도 정의되지 않은 경우, null은 항상 고유 키 제약 조건을 만족합니다. 따라서 고유 키 제약 조건과 NOT NULL 제약 조건이 있는 열은 사용자가 고유 키에서 값을 입력하게 하고, 새 행 데이터가 기존 행 데이터와 충돌할 가능성을 제거합니다.

참고: 여러 열에 대한 고유 키 제약 조건의 검색 메커니즘 때문에, 부분적으로 null인 복합 고유 키 제약 조건의 비 null 열에 동일한 값을 가질 수 없습니다.

예제 5-1 고유 제약 조건

SQL> SELECT employee_id, last_name, email FROM employees WHERE email = 'PFAY';
 
EMPLOYEE_ID LAST_NAME                 EMAIL
----------- ------------------------- -------------------------
        202 Fay                       PFAY

SQL> INSERT INTO employees (employee_id, last_name, email, hire_date, job_id)    
  1  VALUES (999,'Fay','PFAY',SYSDATE,'ST_CLERK');
.
.
.
ERROR at line 1:
ORA-00001: unique constraint (HR.EMP_EMAIL_UK) violated

Primary Key Constraints

기본 키 제약 조건에서는 제약 조건이 적용된 한 개 이상의 열 그룹의 값이 행을 고유하게 식별합니다. 각 테이블은 하나의 기본 키를 가질 수 있으며, 이는 행을 명명하고 중복 행이 존재하지 않도록 보장합니다.

기본 키는 자연 키 또는 대리 키일 수 있습니다. 자연 키는 테이블의 기존 속성으로 만든 의미 있는 식별자입니다. 예를 들어, 조회 테이블에서 자연 키는 우편 번호일 수 있습니다. 반면에, 대리 키는 시스템이 생성한 증가 식별자로 테이블 내에서 고유성을 보장합니다. 일반적으로 시퀀스가 대리 키를 생성합니다.

Oracle 데이터베이스에서 기본 키 제약 조건의 구현은 다음 진술이 사실임을 보장합니다:

두 행이 지정된 열 또는 열 집합의 중복 값을 가지지 않습니다.
기본 키 열은 null을 허용하지 않습니다.

직원에 대한 숫자 식별자가 필요한 상황은 기본 키에 대한 전형적인 경우입니다. 각 직원은 고유한 ID를 가져야 합니다. 직원은 employees 테이블의 하나의 행만으로 설명되어야 합니다.

고유 제약 조건에서의 예제는 기존 직원이 직원 ID 202를 가지고 있으며, 직원 ID가 기본 키인 경우를 보여줍니다. 다음 예제는 동일한 직원 ID를 가진 직원을 추가하려는 시도와 ID가 없는 직원을 추가하려는 시도를 보여줍니다:

SQL> INSERT INTO employees (employee_id, last_name, email, hire_date, job_id)    
  1  VALUES (202,'Chan','JCHAN',SYSDATE,'ST_CLERK');
.
.
.
ERROR at line 1:
ORA-00001: unique constraint (HR.EMP_EMP_ID_PK) violated

SQL> INSERT INTO employees (last_name) VALUES ('Chan');
.
.
.
ERROR at line 1:
ORA-01400: cannot insert NULL into ("HR"."EMPLOYEES"."EMPLOYEE_ID")

데이터베이스는 인덱스를 사용하여 기본 키 제약 조건을 집행합니다. 일반적으로 열에 대해 생성된 기본 키 제약 조건은 암시적으로 고유 인덱스와 NOT NULL 제약 조건을 만듭니다. 다음과 같은 경우에 이 규칙의 예외가 있습니다:

일부 경우에는, 예를 들어 연기 가능 제약 조건으로 기본 키를 생성할 때, 생성된 인덱스는 고유하지 않습니다.

참고: CREATE UNIQUE INDEX 문을 사용하여 고유 인덱스를 명시적으로 생성할 수 있습니다.
기본 키 제약 조건이 생성될 때 사용 가능한 인덱스가 있는 경우, 제약 조건은 이 인덱스를 재사용하고 암시적으로 하나를 생성하지 않습니다.

기본적으로 암시적으로 생성된 인덱스의 이름은 기본 키 제약 조건의 이름입니다. 인덱스에 대한 사용자 정의 이름을 지정할 수도 있습니다. 제약 조건을 생성하는 데 사용되는 CREATE TABLE 또는 ALTER TABLE 문에 ENABLE 절을 포함하여 인덱스에 대한 저장 옵션을 지정할 수 있습니다.

Foreign Key Constraints

두 테이블이 하나 이상의 공통 열을 포함하는 경우, Oracle 데이터베이스는 외래 키 제약 조건을 통해 두 테이블 사이의 관계를 집행할 수 있습니다.

외래 키 제약 조건은 제약 조건이 정의된 열의 각 값에 대해 다른 지정된 테이블 및 열의 값이 일치해야 함을 요구합니다. 참조 무결성 규칙의 예는 직원이 오직 기존 부서에서만 일할 수 있다는 것입니다.

다음 표는 참조 무결성 제약 조건과 관련된 용어를 나열합니다.

표 5-2 참조 무결성 제약 조건 용어

용어	정의
외래 키	제약 조건의 정의에 포함된 열 또는 열 집합으로 참조 키를 참조합니다. 예를 들어, `employees` 테이블의 `department_id` 열은 `departments` 테이블의 `department_id` 열을 참조하는 외래 키입니다.
참조 키	외래 키가 참조하는 테이브의 고유 키 또는 기본 키입니다. 예를 들어, `departments` 테이블의 `department_id` 열은 `employees` 테이블의 `department_id` 열에 대한 참조 키입니다.
종속 또는 자식 테이블	외래 키를 포함하는 테이블입니다. 이 테이블은 참조된 고유 키 또는 기본 키에 존재하는 값에 의존합니다. 예를 들어, `employees` 테이블은 `departments`의 자식입니다.
참조 또는 부모 테이블	자식 테이블의 외래 키가 참조하는 테이블입니다. 이 테이블의 참조 키는 자식 테이블에서 특정 삽입 또는 업데이트가 허용되는지 결정합니다. 예를 들어, `departments` 테이블은 `employees`의 부모입니다.

그림 5-1은 employees.department_id 열에 외래 키를 보여줍니다. 이는 이 열의 모든 값이 departments.department_id 열의 값과 일치해야 함을 보장합니다. 따라서 employees.department_id 열에 잘못된 부서 번호가 존재할 수 없습니다.

그림 5-1 참조 무결성 제약 조건

Self-Referential Integrity Constraints

자체 참조 무결성 제약 조건은 동일 테이블 내의 부모 키를 참조하는 외래 키입니다.

다음 그림에서 자체 참조 제약 조건은 employees.manager_id 열의 모든 값이 employees.employee_id 열에 존재하는 값과 일치해야 함을 보장합니다. 예를 들어, 직원 102의 관리자는 employees 테이블에 존재해야 합니다. 이 제약 조건은 manager_id 열에 잘못된 직원 번호가 존재할 가능성을 제거합니다.

그림 5-2 단일 테이블 참조 제약 조건

Nulls and Foreign Keys

관계형 모델은 외래 키 값이 참조된 기본 또는 고유 키 값과 일치하거나 null일 수 있도록 허용합니다. 예를 들어, hr.employees의 행은 부서 ID를 지정하지 않을 수 있습니다.

복합 외래 키의 어떤 열이 null인 경우, 키의 비 null 부분은 부모 키의 해당 부분과 일치할 필요가 없습니다. 예를 들어, 예약 테이블은 table_id 및 date 열에 대한 복합 외래 키를 포함할 수 있지만 table_id가 null입니다.

Parent Key Modifications and Foreign Keys

외래 키와 부모 키 사이의 관계는 부모 키 삭제 시 발생하는 일에 대한 함의를 가집니다. 예를 들어, 사용자가 이 부서의 기록을 삭제하려고 시도하면 이 부서에 속한 직원들의 기록은 어떻게 됩니까?

부모 키가 수정될 때, 참조 무결성 제약 조건은 자식 테이블의 종속 행에 수행할 다음 작업을 지정할 수 있습니다:

삭제 또는 업데이트 시 아무런 조치도 취하지 않음
- 일반적인 경우, 사용자는 결과가 참조 무결성을 위반할 경우 참조 키 값을 수정할 수 없습니다. 예를 들어, employees.department_id가 departments의 외래 키이고 직원들이 특정 부서에 속해 있다면, 이 부서의 행을 삭제하려는 시도는 제약 조건을 위반합니다.
삭제가 연쇄됨
- 삭제가 연쇄될 때(DELETE CASCADE) 참조 키 값을 포함하는 행이 삭제되면, 종속 외래 키 값을 포함하는 자식 테이블의 모든 행도 삭제됩니다. 예를 들어, departments의 행이 삭제되면 이 부서에 속한 모든 직원의 행이 삭제됩니다.
삭제 시 null 설정
- 삭제 시 null을 설정하면(DELETE SET NULL) 참조 키 값을 포함하는 행이 삭제되어, 종속 외래 키 값을 포함하는 자식 테이블의 모든 행이 해당 값을 null로 설정하게 됩니다. 예를 들어, 부서 행의 삭제는 이 부서에 속한 직원들의 department_id 열 값을 null로 설정합니다.

표 5-3은 부모 테이블의 키 값과 자식 테이블의 외래 키 값에 대해 허용되는 다양한 참조 작업에 따른 DML 문을 개요합니다.

표 5-3 업데이트 및 삭제 작업 없음에 의해 허용되는 DML 문

DML 문	부모 테이블에서 발행	자식 테이블에서 발행
`INSERT`	부모 키 값이 고유한 경우 항상 OK	외래 키 값이 부모 키에 존재하거나 부분적 또는 전체적으로 null인 경우에만 OK
`UPDATE NO ACTION`	자식 테이블의 행이 참조된 부모 키 값 없이 남지 않도록 하는 경우 허용	새 외래 키 값이 참조된 키 값을 여전히 참조하는 경우 허용
`DELETE NO ACTION`	자식 테이블의 행이 부모 키 값을 참조하지 않는 경우 허용	항상 OK
`DELETE CASCADE`	항상 OK	항상 OK
`DELETE SET NULL`	항상 OK	항상 OK

참고: Oracle 데이터베이스의 FOREIGN KEY 무결성 제약 조건에서 지원하지 않는 다른 참조 작업은 데이터베이스 트리거를 사용하여 집행할 수 있습니다.

Indexes and Foreign Keys

원칙적으로 외래 키는 인덱스되어야 합니다. 일치하는 고유 키 또는 기본 키가 결코 업데이트되거나 삭제되지 않는 경우에만 예외입니다.

자식 테이블의 외래 키를 인덱싱하면 다음과 같은 이점이 있습니다:

자식 테이블에 전체 테이블 잠금을 방지합니다. 대신 데이터베이스는 인덱스에 행 잠금을 획득합니다.
자식 테이블의 전체 테이블 스캔이 필요 없습니다. 예를 들어, 사용자가 departments 테이블에서 부서 10의 기록을 제거한다고 가정해 보십시오. employees.department_id가 인덱싱되지 않은 경우 데이터베이스는 부서 10에 속한 직원이 있는지 확인하기 위해 employees를 스캔해야 합니다.

Check Constraints

열 또는 열 집합에 대한 검사 제약 조건은 모든 행에 대해 지정된 조건이 참이거나 알려지지 않은 경우를 제외하고는 항상 참이어야 합니다.

DML이 제약 조건의 조건을 평가하여 거짓으로 만들 경우, SQL 문은 롤백됩니다. 검사 제약 조건의 주요 이점은 매우 구체적인 무결성 규칙을 집행할 수 있다는 것입니다. 예를 들어, hr.employees 테이블에서 다음 규칙을 집행하기 위해 검사 제약 조건을 사용할 수 있습니다:

salary 열에 10000보다 큰 값이 있어서는 안 됩니다.
commission 열에는 급여보다 큰 값이 있어서는 안 됩니다.

다음 예제는 employees에 대해 최대 급여 제약 조건을 만들고 문장이 최대 급여를 초과하는 급여를 포함하는 행을 삽입하려고 할 때 발생하는 상황을 보여줍니다:

SQL> ALTER TABLE employees ADD CONSTRAINT max_emp_sal CHECK (salary < 10001);
SQL> INSERT INTO employees (employee_id,last_name,email,hire_date,job_id,salary)
  1  VALUES (999,'Green','BGREEN',SYSDATE,'ST_CLERK',20000);
.
.
.
ERROR at line 1:
ORA-02290: check constraint (HR.MAX_EMP_SAL) violated

단일 열에는 열의 정의에서 참조되는 여러 검사 제약 조건이 있을 수 있습니다. 예를 들어, 급여 열은 10000 이상의 값을 방지하는 제약 조건과 500 미만의 값을 방지하는 별도의 제약 조건을 가질 수 있습니다.

열에 대한 여러 검사 제약 조건이 있는 경우, 그 목적이 상충하지 않도록 설계되어야 합니다. 조건의 평가 순서는 가정할 수 없습니다. 데이터베이스는 검사 조건이 상호 배타적이지 않음을 확인하지 않습니다.

States of Integrity Constraints

제약 조건 정의의 일부로, Oracle 데이터베이스가 제약 조건을 언제 어떻게 집행해야 하는지 지정할 수 있으므로 제약 조건 상태를 결정할 수 있습니다.

Checks for Modified and Existing Data

데이터베이스를 사용하면 제약 조건이 기존 데이터 또는 향후 데이터에 적용되는지 여부를 지정할 수 있습니다. 제약 조건이 활성화된 경우 데이터베이스는 입력되거나 업데이트되는 새 데이터를 확인합니다. 제약 조건을 준수하지 않는 데이터는 데이터베이스에 입력될 수 없습니다.

예를 들어, employees.department_id에 NOT NULL 제약 조건을 활성화하면 모든 향후 행에 부서 ID가 있어야 합니다. 제약 조건이 비활성화된 경우 테이블에는 제약 조건을 위반하는 행이 포함될 수 있습니다.

다음 두 가지 유효성 검사 모드 중 하나를 제약 조건에 설정할 수 있습니다:

VALIDATE
- 기존 데이터는 제약 조건을 준수해야 합니다. 예를 들어, employees.department_id에 NOT NULL 제약 조건을 활성화하고 VALIDATE로 설정하면 기존의 모든 행에 부서 ID가 있는지 확인합니다.
NOVALIDATE
- 기존 데이터는 제약 조건을 준수할 필요가 없습니다. 사실상 이것은 "나를 믿어" 모드입니다. 예를 들어, 로드한 모든 판매에 날짜가 있다고 확신하는 경우 날짜 열에 NOT NULL 제약 조건을 만들고 제약 조건을 NOVALIDATE로 설정할 수 있습니다. 무시된 제약 조건은 일반적으로 머티리얼라이즈된 뷰와 쿼리 재작성에만 유용합니다.
- NOVALIDATE 모드의 제약 조건의 경우 RELY 매개변수는 옵티마이저가 조인 정보를 결정하는 데 제약 조건을 사용할 수 있음을 나타냅니다. 제약 조건이 데이터 검증에 사용되지 않더라도, 이는 머티리얼라이즈된 뷰에 대한보다 정교한 쿼리 재작성을 가능하게 하며, 데이터 웨어하우징 도구가 데이터 사전에서 제약 조건 정보를 검색할 수 있도록 합니다. 기본값은 NORELY이며, 이는 옵티마이저가 제약 조건을 인식하지 못한다는 것을 의미합니다.

VALIDATE 및 NOVALIDATE의 동작은 항상 제약 조건이 활성화되었는지 비활성화되었는지 여부에 따라 달라집니다. 다음 표는 관계를 요약합니다.

표 5-4 수정 및 기존 데이터 확인

수정된 데이터	기존 데이터	요약
`ENABLE`	`VALIDATE`	기존 및 미래 데이터는 제약 조건을 준수해야 합니다. 채워진 테이블에 새 제약 조건을 적용하려고 하면 기존 행이 제약 조건을 위반하는 경우 오류가 발생합니다.
`ENABLE`	`NOVALIDATE`	데이터베이스는 제약 조건을 확인하지만, 모든 행이 참일 필요는 없습니다. 따라서 기존 행은 제약 조건을 위반할 수 있지만, 새로운 행이나 수정된 행은 규칙을 준수해야 합니다. 이 모드는 이미 무결성이 검증된 기존 데이터를 포함하는 데이터 웨어하우스에서 자주 사용됩니다.
`DISABLE`	`VALIDATE`	데이터베이스는 제약 조건을 비활성화하고, 인덱스를 삭제하며, 제약된 열의 수정을 방지합니다.
`DISABLE`	`NOVALIDATE`	제약 조건이 확인되지 않으며 반드시 참일 필요는 없습니다.

When the Database Checks Constraints for Validity

모든 제약 조건은 연기 불가능(기본값) 또는 연기 가능 상태 중 하나입니다. 이 상태는 Oracle 데이터베이스가 제약 조건의 유효성을 확인하는 시기를 결정합니다.

다음 그래픽은 연기 가능 제약 조건에 대한 옵션을 보여줍니다.

그림 5-3 연기 가능 제약 조건 옵션

Nondeferrable Constraints

연기 불가능 제약 조건에서는 Oracle 데이터베이스가 트랜잭션의 끝이 아니라 각 문의 끝에서 제약 조건의 유효성 검사를 연기하지 않습니다. 대신, 데이터베이스는 문의 끝에서 제약 조건을 확인합니다. 제약 조건이 위반되면 문이 롤백됩니다.

예를 들어, employees.last_name 열에 대한 연기 불가능 NOT NULL 제약 조건이 있습니다. 세션이 last_name 없이 행을 삽입하려고 하면 데이터베이스는 즉시 문을 롤백합니다. 왜냐하면 NOT NULL 제약 조건이 위반되었기 때문입니다. 행이 삽입되지 않습니다.

Deferrable Constraints

연기 가능 제약 조건은 트랜잭션이 SET CONSTRAINT 절을 사용하여 이 제약 조건의 확인을 COMMIT 문이 발행될 때까지 연기할 수 있도록 허용합니다. 데이터베이스에 제약 조건을 위반할 수 있는 변경 사항을 만드는 경우, 이 설정은 사실상 모든 변경이 완료될 때까지 제약 조건을 비활성화할 수 있도록 합니다.

데이터베이스가 연기 가능 제약 조건을 확인하는 시기에 대한 기본 동작을 설정할 수 있습니다. 다음 두 가지 속성 중 하나를 지정할 수 있습니다:

INITIALLY IMMEDIATE
- 데이터베이스는 각 문이 실행된 직후 제약 조건을 확인합니다. 제약 조건이 위반되면 데이터베이스는 문을 롤백합니다.
INITIALLY DEFERRED
- 데이터베이스는 COMMIT이 발행될 때 제약 조건을 확인합니다. 제약 조건이 위반되면 데이터베이스는 트랜잭션을 롤백합니다.

employees.last_name에 대한 연기 가능 NOT NULL 제약 조건이 INITIALLY DEFERRED로 설정된 것을 가정해 보십시오. 사용자는 last_name에 대해 null 값이 포함된 100개의 INSERT 문을 포함하는 트랜잭션을 만듭니다. 사용자가 커밋을 시도하면 데이터베이스는 모든 100개의 문을 롤백합니다. 그러나 이 제약 조건이 INITIALLY IMMEDIATE로 설정된 경우, 데이터베이스는 트랜잭션을 롤백하지 않습니다.

제약 조건이 작업을 유발하는 경우, 데이터베이스는 이 작업을 발생시킨 문의 일부로 간주합니다. 예를 들어, departments에서 행을 삭제하면 삭제된 부서 행을 참조하는 모든 employees 행도 삭제됩니다. 이 경우, employees에서의 삭제는 departments에 대해 실행된 DELETE 문의 일부로 간주됩니다.

Examples of Constraint Checking

다음 예제는 Oracle 데이터베이스가 제약 조건을 확인하는 방법을 도움이 됩니다.

다음을 가정합니다:

employees 테이블은 "자체 참조 무결성 제약 조건"에 표시된 구조를 가지고 있습니다.
자체 참조 제약 조건은 manager_id 열의 항목이 employee_id 열의 값에 의존합니다.

예: 부모 키 값이 없는 경우 외래 키 열에 값 삽입

이 예는 employees 테이블에 첫 번째 행을 삽입하는 것과 관련이 있습니다. 아직 행이 없으므로 manager_id 열의 값이 존재하는 employee_id 열의 값을 참조할 수 없는 경우 행을 어떻게 입력할 수 있습니까?

일부 가능성은 다음과 같습니다:

manager_id 열에 NOT NULL 제약 조건이 정의되어 있지 않은 경우, 첫 번째 행의 manager_id 열에 null을 입력할 수 있습니다.
- null이 외래 키에 허용되므로 Oracle 데이터베이스는 이 행을 테이블에 삽입합니다.
employee_id 및 manager_id 열에 동일한 값을 입력하여, 직원이 자신의 관리자임을 지정할 수 있습니다.
- 이 경우 Oracle 데이터베이스가 문 실행 후 제약 조건 검사를 수행함을 보여줍니다. 부모 키와 외래 키에서 동일한 값을 가진 행을 입력할 수 있도록 하려면 데이터베이스는 먼저 새 행을 삽입한 다음 테이블에 manager_id가 employee_id와 일치하는 행이 있는지 결정해야 합니다.
중첩된 SELECT 문을 포함한 INSERT 문과 같은 다중 행 INSERT 문은 서로를 참조하는 행을 삽입할 수 있습니다.
- 예를 들어, 첫 번째 행은 직원 ID로 200을, 관리자 ID로 300을 가질 수 있으며, 두 번째 행은 직원 ID로 300을, 관리자 ID로 200을 가질 수 있습니다. 제약 조건 검사는 INSERT 문의 완전한 실행 후에 연기됩니다. 데이터베이스는 모든 행을 삽입한 다음 모든 행에 대해 제약 조건 위반을 확인합니다.

기본 값은 문이 구문 분석되기 전에 INSERT 문의 일부로 포함됩니다. 따라서 기본 열 값은 모든 무결성 제약 조건 검사의 대상입니다.

예: 모든 외래 키 및 부모 키 값 업데이트

이 예에서는 자체 참조 제약 조건이 employees의 manager_id 열 항목을 employee_id 열 값에 의존하게 만듭니다.

회사가 매각되었습니다. 이 판매로 인해 모든 직원 번호는 새 회사의 직원 번호와 일치하도록 현재 값에 5000을 더해 업데이트되어야 합니다. 다음 그래픽에서는 일부 직원이 관리자이기도 한 것을 보여줍니다:

그림 5-4 업데이트 전의 employees 테이블

관리자 번호도 직원 번호이기 때문에 관리자 번호도 5000만큼 증가해야 합니다. 다음 SQL 문을 실행하여 값을 업데이트할 수 있습니다:

UPDATE employees SET employee_id = employee_id + 5000,
  manager_id = manager_id + 5000;

각 manager_id 값이 employee_id 값과 일치하는지 확인하기 위해 정의된 제약 조건이 있음에도 불구하고, 앞의 문은 유효합니다. 왜냐하면 데이터베이스는 문이 완료된 후에 제약 조건을 확인하기 때문입니다. 그림 5-5는 데이터베이스가 문의 전체 동작을 수행한 후 제약 조건을 확인함을 보여줍니다.

그림 5-5 제약 조건 확인

이 섹션의 예제들은 INSERT 및 UPDATE 문 동안 제약 조건 검사 메커니즘을 보여줍니다만, 데이터베이스는 모든 유형의 DML 문에 대해 동일한 메커니즘을 사용합니다. 데이터베이스는 자체 참조 제약 조건뿐만 아니라 모든 유형의 제약 조건에 대해 동일한 메커니즘을 사용합니다.