연락처
IBSurgeon
이 페이지는 기계 번역되었습니다. 영어 원본을 읽어보세요. English

IBSurgeon 라이브러리

Firebird 및 InterBase의 데이터베이스 제약 조건

NOTICE: This document is the chapter from the book “The InterBase World” which was written by Alexey Kovyazin and Serg Vostrikov.

이 장은 InterBase 및 Firebird 데이터베이스의 제약 조건(constraints)에 대해 다룹니다. 데이터베이스 제약 조건은 테이블 간의 관계를 정의하고 데이터베이스의 데이터를 검사하고 수정할 수 있는 규칙입니다. 이러한 규칙은 특수한 데이터베이스 객체로 구현됩니다. 제약 조건을 사용하는 주요 장점은 데이터 검사와 애플리케이션의 비즈니스 로직 일부를 데이터베이스 수준에서 구현할 수 있다는 점입니다. 즉, 이를 중앙화하고 단순화하여 데이터베이스 애플리케이션 개발을 더 쉽고 안정적으로 만들 수 있습니다.

초보 개발자들은 제약 조건이 창의적인 작업을 방해한다고 생각하여 종종 이를 무시합니다. 그러나 실제로 이러한 생각은 데이터베이스 설계의 이론과 실무에 대한 충분한 지식이 없기 때문에 생긴 것입니다.

동시에 가장 경험 많은 설계자들은 일부 유형의 제약 조건 사용을 과감히 거부하기도 하며, 그 결과 그들의 애플리케이션은 속도에서 이점을 얻습니다. 전문 설계자의 경험은 서버의 작동 방식을 매우 잘 이해하고 복잡한 경우에서의 동작을 정확히 예측할 수 있게 해주므로, InterBase 초보 프로그래머들은 경험 많은 동료들의 유사한 행동을 따라 하지 않는 것이 좋습니다.

이 책에서는 데이터베이스 설계를 다루지 않으므로, 이 질문에 대한 자세한 정보는 책 끝에 있는 참고 문헌 목록을 참조하십시오. 여기서는 InterBase 데이터베이스의 모든 유형의 제약 조건을 검토하고 적용 예를 살펴보겠습니다.

데이터베이스의 제약 조건 유형

InterBase 데이터베이스에는 다음과 같은 유형의 제약 조건이 있습니다:

  • PRIMARY KEY;
  • UNIQUE KEY;
  • FOREIGN KEY

- 자동 트리거를 켤 수 있음 - ON UPDATE 및 ON DELETE;

  • CHECK

이전 장에서는 자료의 논리적 전개를 위해 이러한 제약 조건 중 일부를 언급했지만, 이제는 그 구문, 적용 및 구현을 더 자세히 살펴보겠습니다. 데이터베이스 제약 조건은 두 가지 유형이 있습니다 - 하나의 필드에 기반한 것과 테이블의 여러 필드에 기반한 것입니다. 두 유형의 제약 조건 구문은 아래에 나와 있습니다.

= [CONSTRAINT constraint]

[ …]

= {UNIQUE | PRIMARY KEY

| CHECK ( )

| REFERENCES other_table [( other_col [, other_col …])]

[ON DELETE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]

[ON UPDATE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]

}

여러 필드에 기반한 제약 조건의 구문은 다음과 같습니다:

= [CONSTRAINT constraint]

[< tconstraint> …]

= {{PRIMARY KEY | UNIQUE} ( col [, col …])

| FOREIGN KEY ( col [, col …]) REFERENCES other_table[( other_col [, other_col …])]

[ON DELETE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]

[ON UPDATE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]

| CHECK ( )}

하나의 필드에 기반한 제약 조건과 여러 필드에 기반한 제약 조건의 구문 차이는 명확합니다 - 후자의 경우 제약 조건에 포함된 여러 필드를 지정할 수 있습니다. 하나의 필드에 기반한 제약 조건의 경우, 설명된 모든 옵션은 현재 필드에만 적용됩니다. 물론 이 두 유형의 제약 조건은 적용 방식이 다릅니다: 하나의 필드에 기반한 제약 조건은 단순히 해당 필드의 정의에 추가되고, 여러 필드에 기반한 제약 조건은 테이블의 일반 정의에서 쉼표 뒤에 지정됩니다. 자세한 예는 이 장의 다음 부분에서 제공됩니다.

일반적인 제약 조건의 예

실제로 하나의 필드에 기반한 제약 조건은 여러 필드에 기반한 제약 조건의 특수한 경우입니다.

이 두 가지 다른 접근 방식을 사용하여 기본 키 제약 조건을 만드는 예가 아래에 나와 있습니다. 하나의 필드만 포함하는 테이블을 만들고 여기에 기본 키 제약 조건을 설정해 보겠습니다.

하나의 필드에 기반한 제약 조건 구문을 사용한 기본 키의 예:

CREATE TABLE test1( ID_PK INTEGER CONSTRAINT pktest NOT NULL PRIMARY KEY); 이 예에서는 ID_PK 필드에 대해 pktest라는 이름의 기본 키가 생성됩니다. 그 결과 한 줄로 매우 간결한 설명이 만들어집니다. 같은 목적으로 여러 필드에 기반한 제약 조건 구문을 사용할 수도 있습니다: CREATE TABLE test2( ID_PK INTEGER NOT NULL, CONSTRAINT pktst PRIMARY KEY (ID_PK));

제약 조건 생성

제약 조건 생성을 더 자세히 살펴보겠습니다. 일반 제약 조건 구문 설명의 첫 번째는 [CONSTRAINT constraint] 옵션입니다. 보시다시피 이 옵션은 대괄호 안에 있으므로 선택 사항입니다.

이 옵션을 사용하면 하나의 필드에 기반한 제약 조건 구문을 적용하는 경우와 여러 필드에 기반한 제약 조건의 경우 모두 생성된 제약 조건에 이름을 설정할 수 있습니다. 제약 조건에 이름을 지정하지 않으면 InterBase가 자동으로 생성합니다. 그럼에도 불구하고 데이터베이스 스키마의 가독성을 높이고 나중에 제약 조건 관리를 단순화하기 위해 생성된 제약 조건에 이름을 설정하는 것이 좋습니다.

제약 조건에 이름을 설정한 후에는 해당 유형을 정의해야 합니다. 일반 제약 조건 구문 설명에 표시된 순서대로 다양한 유형의 제약 조건을 살펴보겠습니다.

기본 키 및 고유 키

기본 키는 데이터베이스 제약 조건의 주요 유형 중 하나입니다. 테이블의 레코드를 고유하게 식별하는 데 사용됩니다. 데이터베이스에 사람 목록을 저장한다고 가정해 보겠습니다. 같은 성, 이름, 부칭을 가진 두 명(또는 그 이상)의 사람이 있을 가능성이 있습니다. 한 사람을 다른 사람과 어떻게 구별할 수 있을까요? (물론 질문은 데이터베이스에 저장된 정보에 따라 한 사람을 다른 사람과 구별하는 것입니다.)

이 경우 “사람"은 테이블의 한 레코드로 표현되므로 더 일반적인 질문을 할 수 있습니다 - (임의의) 테이블의 한 레코드를 같은 테이블의 다른 레코드와 어떻게 구별할 수 있을까요? 이를 위해 기본 키 제약 조건이 사용됩니다. 기본 키는 테이블의 하나 또는 몇 개의 필드를 나타내며, 그 조합은 모든 레코드에 대해 고유합니다. 한 테이블에는 기본 키의 반복 값이 없습니다.

고유 키도 같은 기능을 수행합니다 - 테이블의 레코드를 고유하게 식별하는 역할도 합니다. 기본 키와 고유 키의 차이점은 테이블에는 기본 키가 하나만 있을 수 있고, 고유 키는 여러 개일 수 있다는 것입니다. 기본 키와 고유 키 모두 외래 키의 참조 기준으로 사용될 수 있습니다(자세한 내용은 아래 참조).

기본 키와 고유 키의 개념 및 기타 중요한 정의에 대한 공식적인 설명은 책 끝에 있는 부록 “용어집"에서 찾을 수 있습니다. 고유한 필드에 기반한 기본 키와 고유 키를 만드는 구문은 다음과 같습니다:

< pkukconstraint > = [CONSTRAINT constraint] {PRIMARY KEY | UNIQUE}

기본 키와 고유 키의 예:

CREATE TABLE pkuk( pk NUMERIC(15,0) NOT NULL PRIMARY KEY, /*기본 키*/

uk1 VARCHAR(50) NOT NULL UNIQUE,/*고유 키*/

uk2 INTEGER NOT NULL UNIQUE /\* 또 다른 고유 키 */);

여러 필드에 기반한 기본 키와 고유 키를 만드는 구문:

= [CONSTRAINT constraint] {PRIMARY KEY | UNIQUE} ( col [, col …])

이러한 구문을 사용하면 필드 조합을 기반으로 키를 만들 수 있습니다. 여러 필드에서 기본 키와 고유 키를 만드는 예는 다음과 같습니다:

CREATE TABLE pkuk2( Number1 INTEGER NOT NULL, Name1 VARCHAR(50) NOT NULL, Kol INTEGER NOT NULL, Stoim NUMERIC(15,4) NOT NULL, CONSTRAINT pkt PRIMARY KEY (Number1, Name1), /*두 필드에 기반한 기본 키 pkt*/ CONSTRAINT ukt1 UNIQUE (kol, Stoim)); /*두 필드에 기반한 고유 키 ukt1*/

기본 키와 고유 키에 포함된 모든 필드는 NOT NULL로 선언되어야 합니다. 이러한 키는 정의되지 않은 값을 가질 수 없기 때문입니다. 테이블 생성 시 기본 키와 고유 키 제약 조건을 만드는 것 외에도 이미 존재하는 테이블에 제약 조건을 추가할 수 있습니다. 이 경우 DDL: ALTER TABLE 문이 사용됩니다. 기존 테이블에 기본 키 또는 고유 키 제약 조건을 추가하는 구문은 위에서 설명한 것과 유사합니다:

ALTER TABLE tablename ADD [CONSTRAINT constraint] {PRIMARY KEY | UNIQUE} ( col [, col …])

ALTER TABLE을 사용하여 기본 키와 고유 키를 생성하는 예를 살펴보겠습니다:

CREATE TABLE pkalter( ID1 INTEGER NOT NULL, ID2 INTEGER NOT NULL, UID VARCHAR(24));

그런 다음 키를 추가합니다. 먼저 기본 키:

ALTER TABLE pkalter ADD CONSTRAINT pkal1 PRIMARY KEY (id1, id2);

그 다음 고유 키: ALTER TABLE pkalter ADD CONSTRAINT ukal UNIQUE (uid);

이 테이블의 소유자 또는 시스템 관리자 SYSDBA만이(소유자 및 SYSDBA 사용자에 대한 자세한 내용은 “InterBase의 보안: 사용자, 기능 및 권한” - 4부 참조) 테이블에 기본 키 및 고유 키를 추가(및 삭제)할 수 있다는 점을 명심해야 합니다.

외래 키

InterBase 데이터베이스에서 자주 사용되는 다음 제약 조건은 외래 키 제약 조건입니다. 이는 데이터베이스에서 참조 무결성을 제공하는 매우 강력한 도구로, 데이터베이스에 올바른 참조가 존재하는지 감독할 수 있을 뿐만 아니라 이러한 참조를 자동으로 제어할 수도 있습니다!

외래 키를 생성하는 요점은 다음과 같습니다: 두 테이블이 상호 관련된 정보를 저장하는 데 사용된다면, 이 상호 관계가 항상 올바르게 유지되도록 보장해야 합니다. 예를 들어, 일반 헤더(날짜, 운송장 번호 등)와 상세 레코드 집합(상품 설명, 수량 등)을 포함하는 “운송장” 문서가 있습니다.

이러한 문서를 저장하기 위해 데이터베이스에 두 개의 테이블이 생성됩니다 - 하나는 운송장 헤더를 저장하고, 두 번째는 운송장 내용(상품 및 수량에 대한 레코드)을 저장합니다. 이러한 테이블을 기본 테이블과 하위 테이블 또는 마스터 테이블과 세부 테이블이라고 합니다.

상식에 따르면, 운송장의 내용은 헤더가 없으면 존재할 수 없습니다. 즉, 운송장 헤더를 생성하지 않았다면 상품에 대한 레코드를 삽입할 수 없고, 상품에 대한 레코드가 있다면 헤더 레코드를 삭제할 수 없습니다. 이러한 동작을 구현하기 위해 헤더 테이블과 세부 테이블은 외래 키 제약 조건으로 연결됩니다.

운송장 정보를 포함하는 테이블의 예를 통해 외래 키 제약 조건 설정의 의미를 살펴보겠습니다. 이를 위해 운송장 저장을 위한 두 개의 테이블을 생성합니다 - 헤더 저장을 위한 TITLE 테이블과 운송장에 포함된 상품 정보 저장을 위한 INVENTORY 테이블입니다.

CREATE TABLE TITLE( ID_TITLE INTEGER NOT NULL Primary Key, DateNakl DATE, NumNakl INTEGER, NoteNakl VARCHAR(255));

헤더 테이블에서 ID_TITLE 필드를 기반으로 기본 키를 즉시 정의했다는 점에 주목하세요. TITLE 테이블의 나머지 필드에는 운송장 헤더에 대한 기본 정보(날짜, 번호, 설명)가 포함됩니다.

이제 운송장에 포함된 상품 정보를 저장할 테이블을 정의해 보겠습니다:

CREATE TABLE INVENTORY( ID_INVENTORY INTEGER NOT NULL PRIMARY KEY, FK_TITLE INTEGER NOT NULL, ProductName VARCHAR (255), Kolvo DOUBLE PRECISION, Positio INTEGER);

INVENTORY 테이블에 포함된 필드를 살펴보겠습니다. 첫째, ID_INVENTORY - 이 테이블의 기본 키입니다. 그 다음으로 운송장 헤더 테이블의 ID_TITLE 헤더 식별자에 대한 참조 역할을 하는 정수 필드 FK_TITLE이 옵니다. 그 다음에는 상품 설명, 수량 및 운송장 내 위치를 설명하는 ProductName, Kolvo 및 Positio 필드가 옵니다. FK_TITLE 필드는 이 예에서 가장 중요합니다. 특정 운송장의 상품 정보를 출력하려면 mas_ID_TITLE 매개변수가 헤더 식별자를 정의하는 다음 쿼리를 사용해야 합니다:

SELECT * FROM INVENTORY I1 WHERE I1.FK_TITLE=?mas_ID_TITLE

사실상, 설명된 상황에서는 TITLE 테이블에 존재하지 않는 레코드를 참조하는 레코드로 INVENTORY 테이블을 채우는 것을 막을 수 없습니다. 또한 이미 존재하는 운송장의 헤더를 삭제하는 것도 방해받지 않으며, 이로 인해 상품에 대한 레코드가 “주인 없는” 상태가 될 수 있습니다. 서버는 이러한 모든 삽입 및 삭제를 금지하지 않습니다. 따라서 데이터베이스의 데이터 무결성 제어는 전적으로 클라이언트 애플리케이션에 맡겨집니다. 그러나 서로 다른 프로그래머가 개발한 여러 애플리케이션이 하나의 데이터베이스로 작업할 수 있으며, 이는 데이터 해석의 차이와 오류를 초래할 수 있습니다. 결과적으로 운송장 헤더에 대한 올바른 참조가 있는 상품 레코드만 INVENTORY 테이블에 삽입될 수 있도록 명시적 제약 조건을 설정하는 것이 필수적입니다. 이것이 바로 외래 키 제약 조건으로, 다른 테이블에 있는 값만 제약 조건에 포함된 필드에 삽입할 수 있게 합니다.

이러한 제약 조건은 외래 키를 사용하여 생성할 수 있습니다. 주어진 예에서 FK_TITLE 필드에 대한 외래 키 제약 조건을 설정하고 TITLE의 ID_TITLE 기본 키와 연결해야 합니다. 이미 존재하는 테이블에 외래 키를 추가하려면 다음 명령을 사용할 수 있습니다:

ALTER TABLE INVENTORY ADD CONSTRAINT fktitle1 FOREIGN KEY(FK_TITLE) REFERENCES TITLE(ID_TITLE)

외래 키를 추가할 때 “object is in use” 오류가 자주 발생합니다. 외래 키를 생성하려면 데이터베이스를 단독 모드로 열어야 하며, 동시에 다른 사용자가 없어야 합니다. 또한 수정 중인 테이블을 참조하지 않아야 합니다 - 이로 인해 “object is in use"가 발생할 수 있습니다.

여기서 INVENTORY는 외래 키 제약 조건이 설정되는 테이블의 이름이고, fktitle1은 외래 키의 이름이며, FK_TITLE은 외래 키를 구성하는 필드이고, TITLE은 외래 키에 대한 값(참조 기준)을 제공하는 테이블의 이름이며, ID_TITLE은 외래 키에 대한 참조 기준 역할을 하는 TITLE 테이블의 기본 키 또는 고유 키 필드입니다. 외래 키 제약 조건의 전체 구문(여러 필드를 기반으로 제약 조건을 생성할 수 있는 가능성 포함)은 아래에 나와 있습니다:

= [CONSTRAINT constraint] FOREIGN KEY ( col [, col …]) REFERENCES other_table [( other_col [, other_col …])] [ON DELETE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}] [ON UPDATE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]

보시다시피 정의에는 많은 옵션 집합이 포함되어 있습니다. 먼저 실제 데이터베이스에서 가장 자주 사용되는 외래 키의 기본 정의를 살펴본 다음 가능한 옵션을 분석하겠습니다.

외래 키 제약 조건의 선언적 형태는 제약 조건을 구성할 필드 집합(col [, col …])과 필드 [(other_col [, other_col …])]에 외래 키에 대한 가능한 값 목록을 포함하는 other_table을 지정할 때 가장 자주 사용됩니다.

테이블 생성 시 이러한 정의의 예는 다음과 같습니다:

CREATE TABLE Inventory2( … FK_TABLE INTEGER NOT NULL CONSTRAINT fkinv REFERENCES TITLE(ID_TITLE) …);

이 정의에서는 FOREIGN KEY 키워드가 생략되었으며 단일 필드 FK_TITLE이 외래 키로 사용됨을 의미합니다. 테이블과 동시에 외래 키를 생성하는 더 완전한 형태는 다음 예에 나와 있습니다:

CREATE TABLE Inventory2( … FK_TABLE INTEGER NOT NULL, CONSTRAINT fkinv FOREIGN KEY (FK_TABLE) REFERENCES TITLE(ID_TITLE) …);

외래 키 필드에서 NULL 사용

외래 키가 생성되는 기준이 되는 필드에는 NULL 필드를 적용할 수 있습니다. 이 가능성은 상호 참조를 허용하기 위해 추가되었습니다. 예를 들어, 두 테이블이 외래 키를 사용하여 서로를 참조하는 경우가 있습니다. 이러한 외래 키에서 빈 참조(즉, NULL)를 허용하지 않으면 연결된 테이블에 레코드를 추가하는 것이 불가능합니다: 첫 번째 테이블에 레코드를 추가하려면 두 번째 테이블에 레코드가 있어야 하고, 그 반대의 경우도 마찬가지입니다.

NULL을 빈 참조로 사용하면 서로 교차 참조하는 두 테이블의 상호 참조를 생성할 수 있으며, 관계형 테이블에 계층 구조를 저장할 수도 있습니다 - 이때 루트 노드는 “빈” 레코드(즉, 단순히 NULL 포함)를 참조합니다.

외래 키를 사용한 참조 무결성 지원의 확장 기능

일반적으로 외래 키 제약 조건의 선언적 변형만으로 충분한 경우가 많습니다. 서버는 외래 키가 있는 테이블에 잘못된 값을 삽입하는 것이 불가능하도록 감시하거나, 삽입을 시도할 경우 오류를 발생시킵니다. 그러나 InterBase는 외래 키를 변경하거나 삭제할 때 일련의 자동 작업을 실행할 수 있게 해줍니다. 이를 위해 다음과 같은 외래 키 옵션 집합이 사용됩니다:

[ON DELETE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}] [ON UPDATE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]

이러한 옵션을 사용하면 외래 키 값을 업데이트하거나 삭제할 때 다양한 작업을 정의할 수 있습니다.

예를 들어, 마스터 테이블에서 기본 키를 삭제할 때 하위 테이블에서 동일한 외래 키를 가진 모든 레코드가 삭제되도록 설정할 수 있습니다. 이 경우 외래 키를 다음과 같이 정의해야 합니다:

ALTER TABLE INVENTORY ADD CONSTRAINT fkautodel FOREIGN KEY (FK_TITLE) REFERENCES TITLE(ID_TITLE) ON DELETE CASCADE

실제로 이러한 작업을 구현하기 위해 특정 작업을 실행하는 시스템 트리거가 있습니다. 표 1.2에는 다양한 옵션의 작업에 대한 설명이 나와 있습니다(NO ACTION|CASCADE|SET DEFAULT|SET NULL 옵션은 하나의 ON XXX 절에서 함께 사용할 수 없다는 점에 유의하세요).

표 1.2
이벤트 작업
NO ACTION CASCADE SET DEFAULT SET NULL
ON DELETE 외래 키 삭제 시 아무 작업도 하지 않음 - 기본값으로 사용됨 삭제 시 하위 테이블에서 관련된 모든 레코드 삭제 변경 시
외래 키 필드를 기본값으로 설정		 변경 시
외래 키 필드를 NULL로 설정
ON UPDATE 변경 시 아무 작업도 하지 않음 - 기본값으로 사용됨 레코드 변경 시 하위 테이블의 관련된 모든 레코드 변경 삭제 시
외래 키 필드를 기본값으로 설정		 삭제 시
외래 키 필드를 NULL로 설정

아무것도 지정하지 않거나 NO ACTION을 지정하면 기본 키 변경 시 외래 키 변경을 직접 처리해야 하며, 기본 키 삭제 시에는 미리 하위 테이블의 레코드를 삭제해야 합니다. CASCADE 옵션을 사용할 때는 매우 주의해야 합니다. 부주의하게 사용하면 많은 수의 관련 레코드가 삭제될 수 있습니다.

CHECK 제약 조건

데이터베이스에서 가장 유용한 제약 조건 중 하나는 CHECK 제약 조건입니다. 그 기능은 매우 간단합니다. 테이블에 삽입되는 값을 특정 조건으로 검사하고, 이 조건의 충족 여부에 따라 데이터를 삽입하거나 거부하는 것입니다. 구문은 매우 간단합니다:

= [CONSTRAINT constraint] CHECK ( )}

여기서 constraint는 제약 조건의 이름이고, 는 삽입/업데이트되는 값이 매개변수로 사용될 수 있는 검색 조건입니다. 검색 조건이 충족되면 이 값의 삽입/업데이트가 허용되고, 충족되지 않으면 오류가 발생합니다. CHECK의 가장 간단한 예는 다음과 같습니다:

create table checktst( ID integer CHECK(ID>0));

이 CHECK는 ID 필드에 삽입/업데이트되는 값이 0보다 큰지 확인하고, 결과에 따라 새 값을 삽입/업데이트하거나 오류를 알려줍니다(“InterBase 저장 프로시저 언어의 확장 기능” 장(1부) 참조).

더 복잡한 CHECK 변형도 있습니다. 검색 조건의 전체 구문은 다음과 같습니다:

= {

{ | ()}

| [NOT] BETWEEN AND

| [NOT] LIKE [ESCAPE ]

| [NOT] IN ( [ , …] | )

| IS [NOT] NULL

| {[NOT] {= | < | >} | >= | <=}

{ALL | SOME | ANY} ()

| EXISTS ( )

| SINGULAR ( )

| [NOT] CONTAINING

| [NOT] STARTING [WITH]

| ()

| NOT

| OR

| AND }

따라서 CHECK는 삽입/업데이트되는 값을 검사할 수 있는 다양한 옵션을 제공합니다. CHECK를 사용할 때 다음 제약 사항을 기억해야 합니다:

  • CHECK의 데이터는 현재 레코드에서만 가져옵니다. CHECK의 표현식에 동일한 테이블의 다른 레코드 데이터를 사용해서는 안 됩니다. 다른 사용자가 해당 데이터를 변경할 수 있기 때문입니다.
  • 필드에는 CHECK 제약 조건이 하나만 있을 수 있습니다.
  • CHECK 도메인 제약 조건이 있는 도메인이 필드 정의에 사용되는 경우, 테이블의 특정 필드 수준에서 이를 재정의할 수 없습니다. CHECK는 시스템 트리거로 구현되므로, 레코드 삽입 및 업데이트 프로세스를 크게 느리게 할 수 있는 매우 긴 조건을 사용할 때는 더욱 주의해야 합니다.

제약 조건 삭제

다양한 이유로 제약 조건을 삭제하는 경우가 매우 많습니다. 제약 조건을 삭제하려면 다음 형식의 ALTER TABLE 문을 사용해야 합니다: ALTER TABLE tablename DROP CONSTRAINT constraintname

constraintname은 삭제할 제약 조건의 이름입니다. 제약 조건 생성 시 특정 이름을 지정했다면 해당 이름을 사용해야 하지만, 지정하지 않았다면 InterBase 관리 도구를 열고 관련된 모든 제약 조건을 검색하여 InterBase가 해당 제약 조건에 대해 생성한 시스템 이름을 찾아야 합니다.

제약 조건을 삭제할 수 있는 사람은 테이블 소유자 또는 SYSDBA 시스템 관리자뿐이라는 점에 유의해야 합니다.