CREATE | ALTER TABLE … CONSTRAINT¶
이 항목에서는 CREATE TABLE, CREATE HYBRID TABLE 또는 ALTER TABLE 문에 CONSTRAINT 절을 지정하여 제약 조건을 만드는 방법에 대해 설명합니다.
인라인 제약 조건은 개별 열 정의의 일부로 지정됩니다.
아웃오브 라인 제약 조건은 독립된 절로 지정됩니다.
테이블을 만들 때 이 절은 테이블에 대한 열 정의의 일부입니다.
테이블을 변경할 때 이 절은 테이블에 대한 명시적인
ADD작업으로 지정됩니다.
자세한 내용은 제약 조건 섹션을 참조하십시오.
하이브리드 테이블 을 만들거나 변경하는 경우 제약 조건을 정의하는 구문은 동일하지만, 규칙과 요구 사항은 다릅니다.
인라인 제약 조건 구문¶
여기서:
아웃오브 라인 제약 조건 구문¶
여기서:
제약 조건 속성¶
다른 데이터베이스와의 호환성을 보장하고 하이브리드 테이블과 함께 사용하기 위해 Snowflake는 제약 조건 속성을 제공합니다. 제약 조건에 대해 지정할 수 있는 속성은 다음과 같이 유형에 따라 다릅니다.
일부 속성은 모든 키(고유, 기본, 외래)에 적용됩니다.
외래 키에만 적용되는 다른 속성도 있습니다.
중요
표준 Snowflake 테이블의 경우 다른 데이터베이스에서 쉽게 마이그레이션할 수 있도록 이러한 속성이 제공됩니다. Snowflake에서는 이들 속성을 적용하거나 유지 관리하지 않습니다. 이는 이러한 속성의 기본값을 변경할 수 있지만, 기본값을 변경하면 Snowflake에서 제약 조건을 만들지 않게 된다는 뜻입니다.
예외로 RELY 속성이 있습니다. 표준 테이블의 데이터가 UNIQUE, PRIMARY KEY 및 FOREIGN KEY 제약 조건을 준수하는 경우 해당 제약 조건의 RELY 속성을 설정할 수 있습니다. 불필요한 조인을 제거하도록 RELY 제약 조건 속성 설정하기 도 참조하십시오.
하이브리드 테이블 을 만들거나 변경하는 경우 규칙과 요구 사항은 다릅니다. 제약 조건의 개요 섹션을 참조하십시오.
지원되는 제약 조건 속성은 대부분 ANSI SQL 표준 속성이지만, 다음 속성은 Snowflake 확장입니다.
ENABLE | DISABLE
VALIDATE | NOVALIDATE
RELY | NORELY
또한 아웃오브 라인 제약 조건 정의 내에서 설명을 정의할 수도 있습니다. 제약 조건에 대한 설명 섹션을 참조하십시오.
모든 제약 조건의 속성¶
모든 제약 조건에 다음 속성이 적용됩니다(속성의 순서는 상호 교환 가능).
{ ENFORCED | NOT ENFORCED }트랜잭션에서 제약 조건을 강제 적용할지 여부를 지정합니다. 표준 테이블의 경우 NOT NULL은 이 속성과 관계없이 Snowflake에서 적용하는 유일한 제약 조건 유형입니다.
하이브리드 테이블의 경우 PRIMARY KEY, FOREIGN KEY, UNIQUE 제약 조건에 NOT ENFORCED 속성을 설정할 수 없습니다. 이 속성을 설정하면 “유효하지 않은 제약 조건 속성” 오류가 발생합니다.
참조 무결성 제약 조건 도 참조하십시오.
기본값: NOT ENFORCED
{ DEFERRABLE | NOT DEFERRABLE }후속 트랜잭션에서 트랜잭션이 끝날 때까지 제약 조건 검사를 연기할 수 있을지 여부를 지정합니다.
기본값: NOT DEFERRABLE
INITIALLY { DEFERRED | IMMEDIATE }DEFERRABLE 제약 조건의 경우 제약 조건 검사가 다음 트랜잭션부터 연기될 수 있는지 여부를 지정합니다.
기본값: INITIALLY DEFERRED
{ ENABLE | DISABLE }제약 조건을 사용할지, 사용하지 않을지 지정합니다. 이러한 속성은 Oracle과의 호환성을 위해 제공됩니다.
기본값: DISABLE
{ VALIDATE | NOVALIDATE }제약 조건을 만들 때 테이블에 있는 기존 데이터의 유효성을 검사할지 여부를 지정합니다.
{ ENFORCED | NOT ENFORCED }또는{ ENABLE | DISABLE }이 지정되어 있을 때만 적용됩니다.PRIMARY KEY 및 FOREIGN KEY 제약 조건의 기본값: NOVALIDATE
CHECK 제약 조건의 기본값: VALIDATE
{ RELY | NORELY }쿼리 재작성 중에 NOVALIDATE 모드의 제약 조건을 고려할지 여부를 지정합니다.
테이블의 데이터가 제약 조건을 준수하는지 확인한 경우 이 속성을 RELY로 변경하여 쿼리 최적화 프로그램에서 이러한 데이터 무결성을 예상해야 함을 나타낼 수 있습니다. 표준 테이블의 경우 RELY 제약 조건을 적용하는 것은 사용자의 책임입니다. 그렇지 않으면 의도하지 않은 동작과 예기치 않은 결과가 발생할 위험이 있습니다.
RELY 속성이 제약 조건에 대해 설정되고 참조 무결성 위반이 발생하는 경우, DML 및 CTAS 문이 잘못된 데이터를 삽입할 수 있습니다.
RELY 속성을 설정하면 쿼리 성능이 향상될 수 있습니다(예: 불필요한 조인을 제거 함으로써).
관련 PRIMARY KEY 및 FOREIGN KEY 제약 조건의 경우 두 제약 조건 모두에 이 속성을 설정합니다. 예를 들면 다음과 같습니다.
기본값: NORELY
속성(FOREIGN KEY 제약 조건에만 해당)¶
다음 제약 조건 속성은 외래 키에만 적용됩니다(속성의 순서는 상호 교환 가능).
MATCH { FULL | PARTIAL | SIMPLE }하나 이상의 열에 있는 NULL 값에 관해 FOREIGN KEY 상수가 충족되는지 여부를 지정합니다.
기본값: MATCH FULL
UPDATE { CASCADE | SET NULL | SET DEFAULT | RESTRICT | NO ACTION }외래 키의 기본 또는 고유 키가 업데이트될 때 수행되는 작업을 지정합니다.
기본값: UPDATE NO ACTION
DELETE { CASCADE | SET NULL | SET DEFAULT | RESTRICT | NO ACTION }외래 키의 기본 또는 고유 키가 삭제될 때 수행되는 작업을 지정합니다.
기본값: DELETE NO ACTION
속성(CHECK 제약 조건에만 해당)¶
다음 제약 조건 속성은 CHECK 제약 조건에만 적용됩니다.
CHECK ( expr )적용할 조건을 정의하는 식입니다.
이 식은 다음 항목 중 하나를 포함할 수 있습니다.
CHECK 제약 조건이 작동하는 테이블에 정의된 테이블 열.
상수 값.
환경이나 실행 컨텍스트에 의존하지 않는 스칼라 함수.
이 식은 다음 항목을 포함할 수 없습니다.
사용자 정의 함수(UDFs).
집계 함수, 윈도우 함수, 테이블 함수 또는 하위 쿼리.
데이터베이스 상태를 변경하는 시스템 정의 함수(예: SYSTEM$CANCEL_ALL_QUERIES 함수).
RANDOM 함수와 같은 비결정적 시스템 정의 함수.
환경 또는 실행 컨텍스트에 의존하는 시스템 정의 함수(예: CURRENT_DATE 함수 또는 CURRENT_ROLE 함수).
자세한 내용은 CHECK 제약 조건 섹션을 참조하십시오.
ENABLE 및 VALIDATE 속성의 기본값이 아닌 값¶
다른 데이터베이스와의 구문 호환성을 위해 Snowflake는 제약 조건 속성에 기본값 이외의 값을 지정하는 것을 지원합니다.
그러나 PRIMARY KEY, UNIQUE, FOREIGN KEY 제약 조건의 경우 새 제약 조건을 생성할 때 ENABLE 또는 VALIDATE(이러한 속성에 대한 기본값 이외 값)를 지정하면 제약 조건이 생성되지 않습니다. 이는 RELY에 적용되지 않습니다. RELY를 지정하면 새 제약 조건이 생성됩니다.
CHECK 제약 조건의 경우 ENABLE은 기본값이며 필수입니다. DISABLE을 지정한 후에는 CHECK 제약 조건이 생성되지 않습니다. NOVALIDATE 및 VALIDATE는 새 테이블에 대해 모두 지원됩니다. VALIDATE는 기존 테이블에서 지원되지 않습니다.
Snowflake는 제약 조건 생성 중에 기본값이 아닌 값을 지정하면 오류를 생성할지 여부를 결정하는 세션 매개 변수 UNSUPPORTED_DDL_ACTION 을 제공합니다.
사용법 노트¶
NOT NULL은 열에 NULL 값이 허용되지 않음을 지정합니다.
표준 Snowflake 테이블의 경우 이것이 적용되는 유일한 제약 조건입니다. 참조 무결성 제약 조건 섹션을 참조하십시오.
열 정의 내에서 인라인 제약 조건으로만 지정할 수 있습니다.
기본값은 열에 NULL 값을 허용하는 것입니다.
다중 열 제약 조건(복합 고유 키 또는 복합 기본 키)은 아웃오브 라인에서만 정의할 수 있습니다.
인라인이나 아웃오브 라인으로 외래 키를 정의할 때, 외래 키 열과 참조된 테이블의 기본 키 열의 서명(이름과 데이터 타입)이 정확히 일치하는 경우 참조된 테이블의 열 이름을 지정할 필요가 없습니다.
외래 키를 생성하는 경우 REFERENCES 절의 열은 기본 키에 대해 나열된 열과 동일한 순서로 나열되어야 합니다. 예:
두 경우 모두 열의 순서는
c_1, c_2입니다. 외래 키의 열 순서가 달랐다면(예:c_2, c_1) 외래 키 생성 시도가 실패했을 것입니다.
액세스 제어 요구 사항¶
PRIMARY KEY 또는 UNIQUE 제약 조건 생성의 경우:
기존 테이블을 변경하여 제약 조건을 추가하는 경우 테이블에 대한 OWNERSHIP 권한이 있는 역할을 사용해야 합니다.
새 테이블을 만들 때 테이블이 생성될 스키마에 대해 CREATE TABLE 권한이 있는 역할을 사용해야 합니다.
FOREIGN KEY 제약 조건 생성의 경우:
외래 키 테이블에 대한 OWNERSHIP 권한이 있는 역할을 사용해야 합니다.
고유 또는 기본 키 테이블에 대한 REFERENCES 권한이 있는 역할을 사용해야 합니다.
GRANT <privileges> … TO ROLE 및 REVOKE <privileges> … FROM ROLE 명령을 사용해 REFERENCES 권한을 역할에 부여하고 부여한 권한을 취소할 수 있습니다.
표준 테이블을 사용한 제약 조건의 예¶
하이브리드 테이블의 제약 조건에 대한 예는 CREATE HYBRID TABLE 섹션을 참조하십시오.
아래 예에서는 테이블을 만드는 동안 간단한 NOT NULL 제약 조건을 만들고 테이블을 변경하는 동안 또 다른 NOT NULL 제약 조건을 만드는 방법을 보여줍니다.
테이블을 만드는 동시에 제약 조건 만들기:
제약 조건이 있는 열을 추가하도록 테이블 변경하기:
다음 예에서는 열의 의도가 고유한 값을 유지하는 것임을 지정하지만, 제약 조건이 실제로 적용되지 않음을 분명히 합니다. 이 예에서는 제약 조건의 이름(이 경우 “uniq_col3”)을 지정하는 방법도 설명합니다.
다음은 PRIMARY KEY 제약 조건이 있는 상위 테이블과 첫 번째 테이블의 PRIMARY KEY 제약 조건과 같은 열을 가리키는 FOREIGN KEY 제약 조건이 있는 다른 테이블을 생성하는 예제입니다.
다음 예제에서는 CREATE TABLE 문에 인라인 CHECK 제약 조건을 지정합니다.
다음 DML 작업에서는 수량이 음수이거나 0이므로 이 CHECK 제약 조건은 실패합니다.
여러 열에 대한 아웃오브 라인 CHECK 제약 조건을 지정합니다.
CHECK 제약 조건은 가격이 최고 가격을 초과하지 않도록 합니다.
다음 예제에서는 CTAS 문에 인라인 CHECK 제약 조건을 지정합니다.
CHECK 제약 조건은 새 high_value_products 테이블에 고가로 간주되는 항목만 포함되도록 합니다.
제약 조건에 대한 설명¶
다른 데이터베이스 오브젝트 및 구문과 마찬가지로, Snowflake는 제약 조건에 대한 설명을 지원합니다.
아웃오브 라인 제약 조건은 제약 조건 정의 내에서 COMMENT 절을 지원합니다.
열 정의 내의 COMMENT 절은 열 자체나 해당 제약 조건에 대한 설명을 다는 데 사용할 수 있습니다.
다음과 같은 제한 사항이 있습니다.
COMMENT 명령을 사용하여 제약 조건에 대한 설명을 설정할 수 없습니다.
DESCRIBE TABLE 명령은 열에 정의된 설명을 표시하지만 제약 조건에 정의된 설명은 표시하지 않습니다. 제약 조건에 대한 설명을 보려면 TABLE_CONSTRAINTS 뷰 또는 REFERENTIAL_CONSTRAINTS 뷰 중에서 선택합니다.
열 및 제약 조건 정의 내의 COMMENT 절은 등호(
=)를 지원하지 않습니다. 다음을 지정하지 마세요.이전 예에 표시된 구문을 사용합니다.