데이터 무결성은 데이터베이스 내의 데이터가 업무 규칙을 잘 따른다는 것을 확인해 줍니다. 데이터 무결성을 유지하는데 사용하는 주요 방법이 세 가지 있습니다.
      -  응용 프로그램 코드
      -  데이터베이스 트리거
      -  선언 무결성 제약 조건
세 가지 방법 중 하나를 사용하여 업무 규칙을 대응시키는 것이 바로 디자이너가 내리는 디자인 결정입니다. 데이터베이스 관리자는 디자이너가 선택한 방법을 구현하고 무결성 요구와 필요한 성능간의 균형을 잡아 주는데 관여합니다.
응용 프로그램 코드는 데이터베이스 내의 저장 프로시저, 또는 클라이언트에서 수행되는 응용 프로그램으로 구현될 수 있습니다. 본 장은 데이터베이스 트리거와 무결성 제약 조건을 사용하는데 초점을 두고 있습니다.

데이터베이스 트리거
데이터베이스 트리거는 테이블에서 열을 삽입하거나 갱신하는등의 이벤트가 발생할 때 수행되는 PL/SQL 프로그램입니다. 트리거는 enable될 수도 disable될 수도 있습니다. 즉, 이벤트가 발생했을 때 실행되도록 설정할 수도 있고, 비록 정의는 되었더라도 실행되지 않도록 설정할 수도 있습니다. 데이터베이스 트리거는 보통 무결성 제약 조건으로 정의될 수 없는 복잡한 업무 규칙을 적용할 때 주로 생성됩니다.

무결성 제약 조건
무결성 제약 조건은 업무 규칙을 적용할 때 주로 사용하는 방법으로 다음과 같은 특징을 갖습니다.
      -  향상된 성능 제공
      -  선언과 수정이 용이. 즉, 확장 코딩할 필요가 없습니다.
      -  규칙의 중앙 집중화
      -  융통성 제공(enable/disable)
      -  데이터 딕셔너리에 완전히 기록됨
다음 절에서는 무결성 제약 조건의 수행 방식과 오라클 서버에 의해 구현되는 방법에 대해 다룰 것입니다. 

 슬라이드에서 보듯이 선언 무결성 제약 조건에는 다섯 가지 유형이 있습니다. NOT NULL과 CHECK 제약 조건에 직접 DBA가 신경을 쓰지는 않더라도 기본 키, 유일 키, 그리고 외래 키 제약 조건은 높은 가용성과 쓸만한 성능 수준을 위해 관리해야 합니다.

제약 조건 상태

무결성 제약 조건은 다음 상태 중 하나입니다.

Disabled Novalidate

Disabled novalidate 제약 조건은 제약 조건 정의가 데이터 딕셔너리에 저장되어 있더라도 검사하지 않으며 입력 또는 갱신한 새로운 데이터 뿐만 아니라 테이블의 데이터도 해당 제약 조건에서 정의한 규칙을 따르지 않을 수 있습니다. 이것은 온라인 트랜잭션 처리를 위한 제약 조건 작업에서 정상적인 상태입니다.

Disabled Validate

제약 조건이 이 상태일 경우에는 제약 조건이 있는 열을 수정할 수 없으며 제약 조건에 대한 인덱스는 삭제되고 제약 조건은 비활성화됩니다.

고유 제약 조건에서 Diabled validate 상태면 ALTER TABLE 명령의 EXCHANGE PARTITION 옵션을 사용하여 분할되지 않은 테이블에서 분할된 테이블로 데이터를 효율적으로 로드할 수 있습니다.

참고 : 분할된 테이블은 이 과정에서 설명하지 않습니다.

Enabled Novalidate(Enforced)

제약 조건이 Enabled novalidate 상태면 제약 조건을 위반하는 새 데이터를 입력할 수 없지만 테이블에 적합하지 않은 데이터 즉, 제약 조건을 위반하는 데이터를 포함할 수는 있습니다. 따라서 대개 새로운 데이터를 모두 테이블로 받아들익 전에 확인하는 중간 단계가 여기에 해당됩니다.

Enabled Validate

제약 조건이 이 상태일 경우에는 테이블의 모든 데이터가 제약 조건을 준수하고 있음을 보장하며 적합하지 않은 데이터는 입력할 수 없습니다.

이 상태는 온라인 트랜잭션 처리를 위한 제약 조건 작업에서 정상적인 상태입니다.

제약 조건을 Disabled 상태에서 Enabled validate로 변경하면 테이블이 잠기고 테이블에 있는 모든 데이터에 대해 일치성이 검사되기 때문에 데이터 로드 같은 DML 작업이 대기할 수 있으므로 먼저 Diabled 상태에서 Enabled novalidate로 변경했다가 다시 Enabled validate로 변경하는 것이 좋습니다.

 

트랜잭션 시 제약 조건을 검사할 시점은 제약 조건을 적절히 정의하여 제어할 수 있습니다.

지연되지 않은 제약 조건, 또는 즉시(immediate) 제약 조건
즉시 제약 조건이라고도 불리우는 지연되지 않은 제약 조건은 모든 DML 문 끝에 적용 됩니다. 제약 조건에 위배되면 명령문을 롤백시키게 됩니다. 제약 조건이 연쇄 삭제(delete cascade) 같은 작업을 발생시키면 연쇄 작업은 그 작업을 발생시킨 명령문의 일부로 취급됩니다.
지연되지 않은 제약 조건을 트랜잭션 종료 시 적용되도록 수정할 수 없습니다.

지연된 (deferred)제약 조건
지연된 제약 조건은 트랜잭션 커밋 시에만 검사하는 제약 조건입니다. 커밋시 어떠한 제약 조건이라도 위배되면 전체 트랜잭션이 롤백 됩니다. 외래 키 관계인 부모 행(parent row)과 자식 행(child row)이 동시에 입력될 때 유용합니다. 예를 들어 주문 입력 시스템(order entry system)의 경우에는 주문과 주문에 따른 품목이 동시에 입력되는 경우입니다.

 제약 조건이 지연되려면 생성시 지연 가능한 제약 조건으로 정의되어야만 합니다. 지연될 수 있도록 정의된 제약 조건은 다음 중 하나로써 지정될 수 있습니다.
    -    initially immediate는 명시적으로 다르게 설정되지 않는 한 즉시 제약          조건으로써 작동 하도록 기본값으로 지정합니다.
    -    initially deferred는 트랜잭션이 끝날 때에만 제약 조건이 적용되도록           기본값으로 지정합니다.

지연 가능한 제약 조건의 적용 기본 모드로 정의되어 데이터 딕셔너리에 저장되더라도 응용 프로그램은 제약 조건을 지연된, 또는 즉시 제약 조건 방식으로 동작하도록 수정할 수 있습니다. 이러한 일은 아래에 보여지는 ALTER SESSION 명령이나 SET CONSTRAINT 명령을 사용하여 이룰 수 있습니다.
        ALTER SESSION
            SET CONSTRAINT[S] =
            {IMMEDIATE|DEFERRED|DEFAULT}

        SET CONSTRAINT[S]
            {constraint [ , constraint ] . . .
            |ALL        }
            {IMMEDIATE|DEFERRED}

 

 기본키와 유일키를 적용하는데 인덱스를 사용하며, 이때 인덱스의 위치와 유형을 제어할 수 있습니다.
오라클 서버는 유일 키와 기본 키 제약 조건을 구현하기 위해 다음 절차를 따릅니다.
  1   제약 조건이 disable이면 인덱스가 필요치 않습니다.
  2   제약 조건이 enable이고 제약 조건이 지정된 열이 인덱스의 선행 부분에
       해당하면 제약 조건을 적용하는데 그 인덱스가 사용될 것입니다.
  3   제약 조건이 enable이고 제약 조건이 지정된 열을 인덱스의 선행 부분으로   
     사용하는 인덱스가 없다면 제약 조건과 같은 이름을 가진 인덱스가 다음 규칙을 따라 생성됩니다.
        -    키가 지연 가능하면 키 열에 대해 nonunique 인덱스가 생성됩니다.
        -    키가 지연 가능하지 않다면 unique 인덱스가 생성됩니다.


외래 키 관계인 테이블들을 유지하려면 여러 가지 요인들을 고려해야 합니다.

부모 테이블에 관련된 DDL
   -  부모 테이블을 삭제하기 전에 외래 키가 먼저 삭제되어야 합니다. 다음 명령을 사용하여 한 문장으로 두 작업을 수행하십시오.
        DROP TABLE table CASCADE CONSTRAINTS
 -   부모 테이블은 외래 키를 삭제하거나 disable 시키지 않고는 잘라 버려질 수         없습니다.
 -   부모 테이블을 포함하고 있는 테이블스페이스를 삭제하기 전에 외래 키가 먼저 삭제되어야 합니다. 다음 명령을 사용하십시오.
        DROP TABLESPACE tablespace INCLUDING CONTENTS
               CASCADE CONSTRAINTS

외래 키 관계인 테이블 상의 DML
부모 테이블에서 행이 삭제될 때 DELETE CASCADE 옵션이 사용되지 않으면 오라클 서버는 외래 키에 대응되는 자식 테이블에 행이 없는지 확인해야만 합니다. 마찬가지로 변경하려는 키 값을 가진 자식 행이 없어야만 부모 키에 대한 갱신이 이루어집니다. 자식 테이블의 외래 키 상에 인덱스가 없으면 오라클 서버는 자식 테이블을 잠그고(lock) 참조 무결성을 위해 변경을 막습니다. 자식 테이블에 인덱스가 있으면 인덱스 엔트리를 잠그고 자식 테이블에 더 이상의 제한적인 잠금을 하지 않게 하면서 참조 무결성을 유지합니다. 부모 테이블과 자식 테이블이 서로 다른 트랜잭션에 의해 동시에 갱신되어야 하면 외래 키 열에 인덱스를 생성하십시오.
자식 테이블에 데이터가 삽입되거나 외래 키 열이 갱신될 때 오라클 서버는 참조 키를 적용하는데 사용되는 부모 테이블 상의 인덱스를 검사합니다. 그러므로 인덱스를 포함하고 있는 테이블스페이스가 온라인 상태일 때에만 작업이 성공적으로 수행됩니다. 자식 테이블에 대한 DML 작업을 수행하기 위해 부모 테이블을 포함하고 있는 테이블스페이스가 온라인 상태가 될 필요는 없음을 명심하십시오.

주
위에 언급된 장점 외의 성능에 대한 다른 장점들이 있으므로 외래 키 열에 인덱스를 생성할 것을 권장합니다. 

 


데이터베이스 트리거는 연관된 테이블에 DML 문이 수행될 때 암시적으로 수행되는 PL/SQL 프로그램입니다.

트리거 유형
트리거에 대해 지정할 수 있는 다음 세 가지 특성에 기초하여 테이블에 정의될 수 있는 트리거 조합은 12 가지 입니다.

DML 문
INSERT나 UPDATE, 또는 DELETE, 또는 이 명령문들의 조합이 테이블에 실행될 때 트리거가 실행되도록 설정할 수 있습니다. 갱신 트리거를 정의할 때 열 이름을 지정하면 트리거는 지정된 열이 갱신될 때만 수행됩니다.

시점(timing)
트리거는 트리거 문 이전, 또는 이후에 실행되도록 정의될 수 있습니다.

빈도(Frequency)
주어진 DML 문장에 대해 트리거가 몇 번 수행되도록 할 것인지 제어할 수 있습니다. ROW 트리거는 영향을 받는 매 행마다 한번씩 실행되고 STATEMENT 트리거는 영향을 받는 행의 수와는 관계없이 명령문에 대해 단 한번 실행됩니다.

 트리거 상태
트리거는 enable, 또는 disable 될 수 있습니다. Disable된 트리거는 대응되는 DML 작업이 테이블에 수행될 때 실행되지 않습니다. Enable된 트리거는 대응되는 DML 명령 실행시 실행됩니다. 트리거가 사건에 의해 실행되므로 트리거가 enable 될 때 기존 데이터에 작업을 수행하지는 않습니다.

트리거 생성의 예
다음 트리거는 사원의 이름을 저장하기 전에 INITCAP 함수를 사용하여 변환합니다.
        CREATE TRIGGER scott.emp_conv_ln
        BEFORE INSERT OR UPDATE OF last_name ON scott.employees
            FOR EACH ROW
        BEGIN
            :NEW.last_name := INITCAP(:NEW.last_name);
        END;

주
트리거는 PL/SQL Program Units 과정에서 더 자세히 다루어 집니다.

 

제약 조건은 테이블이 생성되거나 제약 조건을 추가하기 위해 테이블을 수정할 때 정의될 수 있습니다.

구문: In-Line 제약 조건
테이블에 생성될 때 제약 조건은 라인 내에 열을 정의하는 다음 구문을 사용하여 생성할 수 있습니다.
        column datatype [CONSTRAINT constraint]
            in_line_constraint
            [defer_spec]

            in_line_constraint :==
            { [NOT] NULL
            |PRIMARY KEY [USING INDEX index_clause]
            |UNIQUE         [USING INDEX index_clause]
            |REFERENCES [schema.]table [ (column) ]
                                   [ON DELETE CASCADE]
            |CHECK        (condition)
            }
                                    defer_spec :==
            [NOT DEFERRABLE
            |DEFERRABLE [INITIALLY {IMMEDIATE|DEFERRED} ]
            ]
            [DISABLE|ENABLE [VALIDATE|NOVALIDATE] ]

구문에서:
CONSTRAINT                 데이터 딕셔너리에 constraint라는 이름으로 저장되는                                     무결성 제약 조건을 나타냅니다.
USING INDEX                 유일키, 기본키 제약 조건의 경우 오라클 서버가 사용                                     하는 인덱스를 위해 사용되어야 하는 파라미터를                                     index_clause절에 지정합니다.(인덱스 이름은 제약 조건                                     이름과 동일합니다.)
DEFERRABLE                SET CONSTRAINT(S) 명령을 사용하여 트랜잭션이 끝날                                     때까지 제약 조건 검사를 지연할 수 있도록 합니다.
NOT DEFERRABLE         매 DML 문이 끝날 때마다 제약 조건이 검사되도록
                                    합니다.(NOT DEFERRABLE 제약 조건은 세션이나 트랜                                     잭션에 의해 지연될 수 없습니다. NOT DEFERRABLE 이                                     기본값입니다.)
INITIALLY IMMEDIATE     매 트랜잭션이 시작될 때 각 DML 문이 끝날 때마다 이                                      제약 조건을 검사하는 것을 기본값으로 합니다.                                    (INITIALLY 절이 지정되지 않으면 INITIALLY IMMEDIATE가                                     기본값입니다.)
INITIALLY DEFERRED     제약 조건은 DEFERRABLE상태이며 기본값으로 매 트랜                                     잭션이 끝날 때에만 제약 조건을 검사하도록 지정합니다.
DISABLE                       무결성 제약 조건을 disable합니다. 무결성 제약 조건이                                      disable되면 오라클 서버는 적용하지 않습니다.

 구문: Out-of-Line 제약 조건
제약 조건은 다음 구문을 사용하여 라인 밖에서 생성될 수도 있습니다.
        [CONSTRAINT constraint]
            out_of_line_constraint

            out_of_line_constraint :==
            {PRIMARY KEY (column [ , column ] . . .)
                                [USING INDEX index_clause]
            |UNIQUE         (column [ , column ] . . .)
                               [USING INDEX index_clause]
            |FOREIGN KEY (column [ , column ] . . .)
             REFERENCES [schema.]table [ (column [ , column ] . . .) ]
                                   [ON DELETE CASCADE]
            |CHECK          (condition)
            }
            [defer_spec]

주
   ?  제약 조건에 대한 표준 명명 규약을 채택하는 것이 좋습니다. CHECK 제약 조건의 경우       
   ? 동일한 제약 조건이 다른 이름으로 여러 번 생성될 수 있기 때문에 특별히 더 그렇습니다.
        out-of-line 제약 조건은 다음 경우에 필요합니다.
        - 제약 조건이 둘 이상의 열을 포함할 때
        - 테이블에 NOT NULL 제약 조건 외의 다른 제약 조건이 추가되어 고쳐질 때

테이블 생성한 후 제약 조건 정의의 예
        ALTER TABLE scott.employees
        ADD (CONSTRAINT emp_dept_fk FOREIGN KEY(deptno)
        REFERENCES scott.departments(deptno)
        DEFERRABLE INITIALLY DEFERRED);

주
본 장의 “제약 조건 Enable(Enabling Constraints)”에서 다루어질 EXCEPTIONS 절은 ALTER TABLE 명령을 사용하여 추가된 제약 조건에 위배되는 행을 찾아내는데 사용할 수 있습니다.

 

제약 조건을 정의할 때 다음 지침 사항이 유용할 것입니다.
   ?  기본 키와 유일 제약 조건을 적용하는데 사용하는 인덱스를 테이블과는 별도의 테이블스페이스에 위치시키십시오. USING INDEX 절을 지정하거나   테이블을 생성하고 인덱스를 생성한 후 테이블을 고쳐서 제약 조건을 추가하거나 enable시키면 됩니다.
   ?  데이터가 테이블로 자주 대량 로드되면 제약 조건을 disable시킨 후  로드를 수행하고 제약 조건을 enable시키는 것이 더 나을 것입니다. 기본 키나  유일 제약 조건을 적용하기 위해 unique 인덱스가 사용되면 이 인덱스는  제약 조건이disable될 때 삭제되어야 합니다. 이러한 상황에서 기본 키나 유일 제약 조건을 적용하기 위해 nonunique 인덱스를 사용함으로써 성능이 향상될 수 있습니다. 지연 가능하도록 키를 생성하거나 또는 키를 정의하거나   enable하기 전에 인덱스를 생성하면 됩니다.
    ?   테이블이 자기 참조 외래 키를 가지고 있으면 데이터를 로드할 때 다음 중 한가지 방법을 사용하십시오.
        -       처음 로드한 후 외래 키를 정의하거나 enable시킴
        -       제약 조건을 지연 가능하도록 정의
     데이터가 자주 로드될 경우 두번째 방법이 유용합니다.

 

구문
다음 명령을 사용하여 제약 조건을 disable하십시오.
        ALTER TABLE [schema.]table
        DISABLE {CONSTRAINT constraint
                      | PRIMARY KEY
                      | UNIQUE ( column [ , column ] . . .) }
               [ CASCADE ]

제한 사항
        기본 키, 또는 유일 제약 조건을 제외한 모든 제약 조건은 이름이 지정되어야        합니다.
        기본 키나 유일 제약 조건이 외래 키에 의해 참조되면 기본 키나 유일 제약          조건을 disable하기 전에 CASCADE 키워드를 사용하여 외래 키를             disable시키십시오. 

 

현재 diable된 제약 조건은 다음 두 가지 방법 중 하나로 enable될 수 있습니다:
        Enable NOVALIDATE
        Enable VALIDATE

Enable NOVALIDATE
제약 조건을 novalidate로 하는 것이 제약 조건을 validate로 enable 하는것 보다 더 빠릅니다. 왜냐하면 지연 가능하다면 기존 데이터가 제약 조건에 위배되는지 검사하지 않기 때문입니다. 제약 조건을 enable할 때 이 옵션을 사용하면 테이블이 잠기지도 않습니다. OLTP 환경처럼 테이블에 DML 작업이 많이 가해질 때는 이 방법이 적절합니다.

구문
제약 조건을 novalidate로 enable하려면 다음 명령을 사용하십시오.
        ALTER TABLE [schema.]table
        ENABLE NOVALIDATE {CONSTRAINT constraint
                       | PRIMARY KEY
                       | UNIQUE ( column [ , column ] . . . ) ]
             [ USING INDEX index_clause ]

 제한 사항
USING INDEX 절은 기본 키나 유일 제약 조건이 지연 가능으로 생성되고 다음 중 하나가 참일 경우에만 적용 가능합니다.
        -       제약 조건이 disable로 생성되었는가?
        -       제약 조건이 disable 되어 있고 인덱스가 삭제되었는가?
하지만, 인덱스가 생성되어야 할 때 제약 조건을 enable하기 위해 이 방법을 사용하는 것은 오라클 서버가 인덱스를 구축하기 위해 테이블을 잠궈(lock)버리기 때문에 validate로 enable하는 것 보다 현저한 장점을 제공하지는 못합니다.


Enable VALIDATE
제약 조건을 validate로 enable하면 기존 데이터도 제약 조건에 위배되지 않는지 검사합니다. 제약 조건이 enable될 때는 이것이 기본값입니다. Disable된 제약 조건에 수행되면 다음과 같은 효과를 갖습니다.
     -   테이블이 잠겨져 기존 데이터에 대한 적합성 여부 판정이 완료될 때까지는          테이블에 대한 변경이 금지됩니다.
     -   오라클 서버는 인덱스 열에 인덱스가 존재하지 않으면 하나 생성합니다.          지연 가능하지 않은 기본 키나 유일 제한 조건을 enable할 때 인덱스를 생성         합니다.지연 가능한 기본 키나 유일 제한 조건에 대해서는 유일하지 않은         인덱스가  구축됩니다.
제약 조건이 적용되고 있을 때 이 명령이 실행되면 적합성 여부를 판정하는 동안 어느 테이블도 잠기지 않습니다. 시행된 제약 조건은 적합성 여부를 판정하는 동안 어떠한 위배 사항도 받아들여지지 않도록 합니다. 이 방법은 다음과 같은 장점을 가집니다.
    -    모든 제약 조건이 동시에 enable됩니다.
    -    각 제약 조건들은 내부적으로 병렬화되어 있습니다.
    -    테이블에 동시 작업이 허용됩니다.

 구문
다음 명령을 사용하여 제약 조건을 validate로 enable 하십시오.
        ALTER TABLE [schema.]table
        ENABLE [ VALIDATE ] {CONSTRAINT constraint
                      | PRIMARY KEY
                      | UNIQUE ( column [ , column ] . . . ) }
            [ USING INDEX index_clause ]
        [ EXCEPTIONS INTO [schema.] table]

주
    -  VALIDATE 옵션이 기본값이므로 disable된 제약 조건을 enable할 때          지정하지 않아도 됩니다.
    -  테이블 내의 데이터가 제약 조건을 위배하면 명령문은 롤백되고 제약 조건은 disable인 채로 남아 있게 됩니다.
    -  EXCEPTIONS 절의 사용법은 다음 절에서 다루어 집니다.

 


EXCEPTIONS 절은 현재 enable 하려는 제약 조건을 위배하는 행을 찾아내는데 도움을 줍니다. 제약 조건에 위배된 것을 검출해 내고 교정한 후 제약 조건을 다시 enable 시키려면 다음 절차에 따르십시오.
1       exceptions 테이블이 생성되어 있지 않으면 관리 디렉토리 내의 utlexcpt.sql                스크립트를 실행시켜 exceptions 테이블을 생성하십시오.
        SVRMGR> @?/rdbms/admin/utlexcpt
        Statement processed.
        SVRMGR> DESCRIBE exceptions
        Name                   Null?     Type
        ---------------------  --------  ----------------------
        ROW_ID                           UNDEFINED
        OWNER                            VARCHAR2(30)
        TABLE_NAME                       VARCHAR2(30)
        CONSTRAINT                       VARCHAR2(30)

Windows NT의 경우에는 %ORACLE_HOME%\RDBMS80\ADMIN 디렉토리에 있습니다.

2       EXCEPTIONS 절을 포함하는 ALTER TABLE 명령을 실행하십시오.
        SVRMGR> ALTER TABLE scott.employees
                2> ENABLE VALIDATE CONSTRAINT emp_dept_fk
                3> EXCPTIONS INTO system.exceptions;
        ALTER TABLE scott.employees
        *
        ORA-02298: cannot enable (SCOTT.EMP_EMPT_FK) - parent keys not   
  found
        SVRMGR>
        EXCEPTIONS 테이블의 소유자는 이름을 지정하지 않았을 경우 변경하는 테이블의
     소유자로 간주합니다.
        행들이 EXCEPTIONS 테이블에 삽입됩니다. 명령을 재실행할 경우 EXCEPTIONS
     테이블을 잘라 버려(truncate) 기존 행을 제거하십시오.
3       EXCEPTIONS 테이블에 서브쿼리를 사용하여 부적합한 데이터를 가려 내십시오.
        SVRMGR> SELECT rowid, empno, last_name, deptno
                2> FROM scott.employees
                3> WHERE ROWID in (SELECT row_id
                4> FROM exceptions)
                5> FOR UPDATE;
        ROWID                  EMPNO   LAST_NAME       DEPTNO
        --------------------   -----   -------------   ----------
        AAAAeyAADAAAAA1AAA     1003    Pirie           50
        1 row selected.
4       데이터 내의 에러를 바로 잡으십시오.
        SVRMGR> UPDATE scott.employees
                2> SET deptno=10
                3> WHERE rowid=‘AAAAeyAADAAAAA1AAA’;
        1 row processed.
        SVRMGR> COMMIT;
        Statement processed.
5       EXCEPTIONS 테이블을 잘라 버리고 제약 조건을 다시 enable하십시오.
        SVRMGR> TRUNCATE TABLE exceptions;
        Statement processed.
        SVRMGR> ALTER TABLE scott.employees
                2> ENABLE VALIDATE CONSTRAINT emp_dept_fk
                3> EXCEPTIONS INTO system.exceptions;
        Statement processed. 

 


디폴트로 트리거는 생성될 때 enable되어 있습니다.

트리거 disable하기
다음 경우 트리거를 disable해야 할 필요가 있습니다.
        트리거가 참조하는 오브젝트가 사용 가능하지 않은데 테이블에의 작업을 멈출        수 없을 때
        트리거를 가진 테이블에의 다량의 데이터 로드 속도를 높일 때
트리거를 disable하려면 다음 명령을 사용하십시오.
        ALTER TRIGGER [schema.]trigger DISABLE

트리거 enable하기
트리거를 enable하려면 다음 명령을 사용하십시오.
        ALTER TRIGGER [schema.]trigger ENABLE
테이블의 모든 트리거를 enable하거나 disable하려면 다음 구문을 사용하십시오.
        ALTER TABLE [schema.]table
        { DISABLE | ENABLE } ALL TRIGGERS

 


다음과 같은 때 제약 조건이 삭제할 수 있습니다.
     -   제약 조건이 더 이상 필요하지 않을 때
     -   제약 조건이 수정되어야 하는데 직접 수정할 수 없고 삭제한 후 추가해야만 할 때

구문
제약 조건을 삭제하려면 다음 명령을 사용하십시오.
        ALTER TABLE [schema.]table
        DROP {CONSTRAINT constraint
                 | PRIMARY KEY
                 | UNIQUE ( column [ , column ] . . . ) }
             [ CASCADE ]

주
 -  외래 키가 참조하는 제약 조건을 삭제하려면 CASCADE 옵션을 사용하십시오.
 -  기본 키나 유일 제약 조건이 삭제될 때는 관련된 unique 인덱스도 삭제됩니다.
 -  기본 키나 유일 제약 조건이 nonunique 인덱스를 사용하여 구현되었다면 관련된 인덱스는 삭제되지 않습니다. 따라서 더 이상 필요치 않으면 수동으로 삭제해야 합니다.

 부모 테이블 삭제
외래 키에 의해 참조되는 테이블은 외래 키가 삭제되어야만 삭제할 수 있습니다. 다음 명령을 사용하십시오.
      -  DROP [schema.]table
      -  CASCADE CONSTRAINTS
부모 테이블이 재구성될 때 이것이 필수적일 수도 있습니다.

 

다음 명령을 사용하여 더 이상 필요하지 않은 트리거를 삭제하십시오.
DROP TRIGGER [schema.]trigger


 제약 조건과 그 상태
SCOTT의 EMP 테이블에 대한 모든 제약 조건의 이름, 유형, 그리고 상태를 알고 싶으면 다음 질의문을 사용하십시오.
        SVRMGR> SELECT constraint_name, constraint_type, deferrable,
                2>        deferred, validated
                3> FROM dba_constraints
                4> WHERE owner=‘SCOTT’
                5> AND table_name=‘EMPLOYEES’;
CONSTRAINT_NAME   C  DEFERRABLE      DEFERRED    VALIDATED
----------------  -  --------------  ----------  -------------
EMP_DEPT_FK       R  DEFERRABLE      DEFERRED    VALIDATED
EMP_PK            P  DEFERRABLE      IMMEDIATE   VALIDATED
SYS_C00565        C  NOT DEFERRABLE  IMMEDIATE   VALIDATED
3 rows selected

다음 표는 DBA_CONSTRAINTS 뷰 내의 일부 열들에 대한 설명입니다.

 이름

 설명

 CONSTRAINT_TYPE

제약 조건의 유형은 기본 키이면 P, 유일 키이면 U, 외래 키이면 R, 검사(Check)이면 C입니다. NOT NULL 제약조건은 검사 제약조건으로 저장됩니다.

 SEARCH_CONDITION

검사 제약 조건으로 지정된 조건을 보여 줍니다.

 R_OWNER
 R_CONSTRAINT_NAME

외래 키가 참조하는 제약 조건의 소유자와 이름을 정의합니다.

 GENERATED

제약 조건의 이름이 시스템에 의해 생성되었는지 여부를 보여 줍니다.(가능한 값은 ‘USER NAME과GENARATED NAME’입니다.)

 BAD

제약 조건이 Y2K 문제 같은 것들을 피할 수 있도록 쓰여졌는지를 보여 줍니다.(오라클 이전 버전에서 검사 제약 조건에 두 자리수로 년도를 지정할 수 있게 허용했기 때문에 발생할 수 있습니다.)

 LAST_CHANGE

제약 조건이 마지막으로 enable되거나 disable된 날짜입니다.


제약 조건의 열
SCOTT의 EMP 테이블에 대한 제약 조건의 열을 알고 싶으면 다음 질의문을 사용하십시오.
        SVRMGR> SELECT c.constraint_name, c.constraint_type,
                2>         cc.column_name
                3> FROM dba_constraints c, dba_cons_columns cc
                4> WHERE c.owner=‘SCOTT’
                5> AND c.table_name=‘EMPLOYEES’
                6> AND c.owner = cc.owner
                7> AND c.constraint_name = cc.constraint_name
                8> ORDER BY cc.position;
        CONSTRAINT_NAME         C   COLUMN_NAME
        ---------------------   -   ----------------
        EMP_DEPT_FK             R   DEPTNO
        EMP_PK                  P   EMPNO
        SYS_C00565              C   LAST_NAME
        3 rows selected.

기본 키 - 외래 키 관계 찾기
SCOTT의 EMP 테이블의 외래 키와 부모 제약 조건을 찾으려면 다음 질의문을 사용하십시오.
        SVRMGR> SELECT c.constraint_names AS “Foreign Key”,
                2> p.constraint_name AS “Referenced Key”,
                3> p.constraint_type,
                4> p.owner,
                5> p.table_name
                6> FROM dba_constraints c, dba_constraints p
                7> WHERE c.owner=‘SCOTT’
                8> AND c.table_name=‘EMPLOYEES’
                9> AND c.constraint_type=‘R’
         1      0> AND c.r_owner=p.owner
         1      1> AND c.r_constraint_name = p.constraint_name;
        Foreign Key   Referenced Key   C   OWNER      TABLE_NAME
        ------------  --------------   -   --------   ----------------
        EMP_DEPT_FK   DEPT_PK          P   SCOTT      DEPARTMENTS
        1 row selected.

 

트리거와 트리거 열
SCOTT의 EMP 테이블에 대한 모든 트리거의 이름과 UPDATE OF 절의 열을 알고 싶다면 다음 질의문을 사용하십시오.
        SVRMGR> SELECT t.owner, t.trigger_name, t.trigger_type,
                2     t.triggering_event, t.status,
                3     c.column_name, o.status as “VALIDITY”
                4       FROM dba_triggers t, dba_trigger_cols c,
                5            dba_objects o
                6       WHERE t.owner = c.trigger_owner (+)
                7       AND t.trigger_name = c.trigger_name (+)
                8       AND t.owner = o.owner
                9       AND t.trigger_name = o.object_name
         1      0       AND o.object_type = ‘TRIGGER’
         1      1       AND t.table_owner = ‘SCOTT’
         1      2       AND t.table_name = ‘EMPLOYEES’;
        
        OWNER        RIGGER_NAME  TRIGGER_TYPE     TRIGGERING_EVENT STATUS
        -----------  -----------  ------------     ---------------- ------              COLUMN_NAME  VALIDITY
        -----------  ----------
        SCOTT        EMP_CONV_LN  BEFORE STATEMENT INSERT OR UPDATE ENABLED
  LAST_NAME    VALID
        SCOTT        T1           BEFORE STATEMENT UPDATE           ENABLED             EMPNO        INVALID
        2 rows selected.

 

요약참조

관련내용

 참조

 초기화 파라미터

 없슴

 동적 성능 뷰

 없슴

 데이터 딕셔너리 뷰

 DBA_CONSTRAINTS
 DBA_TRIGGERS
 DBA_TRIGGER_COLS

 명령어

 CREATE TABLE ... CONSTRAINT
 ALTER TABLE ADD CONSTRAINT ...
 EXCEPTIONS INTO
 CREATE OR REPLACE TRIGGER
 ALTER TABLE ... DISABLE CONSTRAINT
 ALTER TABLE ... ENABLE NOVALIDATE
 CONSTRAINT
 ALTER TABLE ... ENABLE VALIDATE
 CONSTRAINT ... EXCEPTIONS INTO
 ALTER TRIGGER ... DISABLE
 ALTER TABLE ... DISABLE ALL TRIGGERS
 ALTER TRIGGER ... ENABLE
 ALTER TABLE ... ENABLE ALL TRIGGERS
 ALTER TRIGGER ... COMPILE
 ALTER TABLE ... DROP CONSTRAINT
 DROP TABLE ... CASCADE CONSTRAINTS
 DROP TRIGGER

 패키지 프로시저와 함수

 없슴

 Deferred Constraints에 대한 설명으로 틀린 것은?
A. PK나 UK일 경우, non-unique Index를 생성한다.
B. Transaction이 commit되었을 때, constraint의 check가 일어난다.
C. Commit할 때 error가 발생하면, 마지막 문장이 rollback된다.
D. Initially immediate이면, alter session 명령어를 이용하여 deferred로 설정해야 한다.
답

X 정답:C


X 정답:A


X 정답:B


O


O