CHECK制約 - Advanced SQL Engine - Teradata Database

Teradata Vantage™ - SQLデータ定義言語 詳細トピック

Product
Advanced SQL Engine
Teradata Database
Release Number
17.05
17.00
Published
2020年6月
Language
日本語
Last Update
2021-03-30
dita:mapPath
ja-JP/jpx1556733107962.ditamap
dita:ditavalPath
ja-JP/jpx1556733107962.ditaval
dita:id
B035-1184
Product Category
Software
Teradata Vantage

CHECK制約は、SQL制約仕様の中で最も汎用性の高いタイプです。CHECK制約をCREATE TABLEまたはALTER TABLEのSQLテキストのどこに指定するかに応じて、その制約が個々の列に適用されるか、テーブル全体に適用されるかが決まります。

Teradata Databaseは、テーブル レベルのパーティションCHECK制約を、パーティション化されたテーブルのパーティション式から導出します。この派生制約のテキストは、16,000文字を超えてはなりません。そうしないと、システムはリクエスト側にエラーを返します。詳細については、パーティション化されたテーブルのルールと使用上の注意を参照してください。

すべてのCHECK制約に対して以下のルールが適用されます。
  • CHECK制約は、列レベルでもテーブル レベルでも定義できます。
  • 1つのテーブルに複数のCHECK制約を定義できます。
  • CHECK制約は、列レベルまたはテーブル レベルで定義できます。
  • CHECK制約の述部に指定できるのは、単純なブール検索条件です。

    Subquery 、集約式、およびCASE式は、CHECK制約の定義に指定する検索条件としては無効です。

  • CHECK制約式からSQL UDFを呼び出すことはできません。
  • 揮発テーブルおよびグローバル一時トレース テーブルに対しては、どのレベルでもCHECK制約を指定できません。
  • テーブル レベル制約、列レベル制約、およびビューに対するWITH CHECK OPTION制約の組み合わせによっては、INSERTおよびUPDATE文のための制約式が大きくなりすぎて、構文解析できないことがあります。
  • Teradata Databaseは、文字型の列のCHECK制約をテストするときに、現行のセッション照合を使用します。

    このため、まったく同じデータを挿入または更新した場合でも、1つのセッション照合では条件を満たすCHECK制約が、別のセッション照合では違反とみなされることがあります。

    この現象の重要性を、例を挙げて説明します。CHECK制約は基本テーブルの文字型の列への挿入および更新の際にチェックされるので、その文字型の列に定義したスパース結合インデックスが、セッション文字照合の違いによって更新されたり、更新されなかったりします。そのため、クエリー計画でそのスパース結合インデックスを使用した場合の結果が、使用するスパース結合がない場合と異なる結果になることがあります。

  • Teradata Databaseは、名前なしの複数のCHECK制約でテキストと大文字/小文字が同一である場合、それを重複と見なし、その制約がCREATE TABLEまたはALTER TABLE文の一部として発行された時点でエラーを返します。

    例えば、次のCREATE TABLE文は有効です。f1は小文字で、F1は大文字だからです。

    CREATE TABLE t1 (f1 INTEGER, CHECK (f1>0), CHECK (F1>0));

    しかし、次のCREATE TABLE文はないです。名前なしの2つのf1制約の大文字/小文字が同一だからです。このリクエストはリクエスト側にエラーを返します。

    CREATE TABLE t1 (f1 INTEGER, CHECK (f1>0), CHECK (f1>0));
  • CHECK制約を列レベルで定義することとテーブル レベルで定義することの基本的な違いは、列レベルの制約ではテーブル内の他の列を参照できないのに対して、テーブル レベルの制約では、その定義からして、テーブル内の他の列を参照するSYSUDTLIBという点です。
  • 以下のリストにあるデータ型を定義された列は、CHECK制約の構成要素になることはできません。
    • BLOB
    • CLOB
    • UDT
    • ARRAY
    • VARRAY
    • PERIOD
    • 地理空間
  • 行レベル セキュリティで保護されたテーブルの行レベル セキュリティ制約列に対して、CHECK制約を定義することはできません。
  • 行レベル セキュリティで保護されたテーブルに1つまたは複数のCHECK制約を定義した場合、その制約を実施すると、そのテーブルに定義されたUDFセキュリティ ポリシーは実行されません。CHECK制約の実施はテーブル全体に適用されます。したがって、CHECK制約は、ユーザーが表示できる行だけでなく、テーブル内のすべての行に適用されます。
以下のルールは、列レベルのCHECK制約にのみ当てはまります。
  • 1つの列に対して列レベルのCHECK制約を複数指定できます。

    1つの列に対して名前なしの異なるCHECK制約を複数定義した場合、Teradata Databaseはそれらの制約を1つの列レベルの制約に組み合わせします。

    ただし、Teradata Databaseは、それぞれの名前なしの列レベルCHECK制約を、名前ありのテーブル レベルCHECK制約の場合と同じように、別個に処理します。

  • 列レベルのCHECK制約では、テーブル内の別の列を参照できません。
以下のルールは、テーブル レベルのCHECK制約にのみ当てはまります。
  • テーブル レベルの制約では、通常、テーブルの少なくとも2つの列を参照します。
  • テーブル レベルのCHECK制約の述部では、他のテーブルの列を参照できません。
  • 1つのテーブルに対して同時に100個までのテーブル レベル制約を定義できます。