管理の手引き


制約の強制について計画する

制約 とは、 データベース・マネージャーが実施する規則の 1 つのことです。 このセクションでは、4 つのタイプの制約処理について説明します。

"固有制約"
表のキー値を必ず固有にします。 基本キーを構成する列に対するすべての変更については、固有かどうかが検査されます。

"参照保全"
挿入、更新、削除の操作時に参照制約を施行します。 この場合、データベースは、すべての外部キーのすべての値が有効になります。

"表検査制約"
変更されたデータが、 表の作成または変更時に指定された条件に違反していないかどうかを検査します。

"トリガー"
指定された表に対する更新、削除、 または挿入の操作によって呼び出されたときに実行される 1 組のアクションを定義します。

固有制約

固有制約 とは、1 つのキーの値が、 表内で必ず固有になるという規則のことです。 固有制約内のキーを構成する各列は、NOT NULL として定義されていなければなりません。 固有制約は、PRIMARY KEY 文節または UNIQUE 文節を使用して、 CREATE TABLE または ALTER TABLE ステートメントで定義されます。

1 つの表は任意の数の固有制約を持つことができますが、 1 つの表に対する基本キーとして定義できるのは 1 つの固有制約だけです。 また、1 つの表は、同じ列のセット上では、複数の固有制約を持つことはできません。

固有制約が定義されると、データベース・マネージャーは、 (必要ならば) 固有索引を作成し、 それをシステム必須の 1 次索引または固有索引のいずれかとして指定します。 この制約は、固有索引を通して施行されます。 固有制約が 1 つの列でいったん確立されると、 複数行の更新中における固有性の検査は、更新の終わりまで延期させられます。

固有制約は、参照制約の中の親キーとしても使用することができます。

参照保全

データベース・マネージャーは、 参照制約 を介して参照制約を保守します。 この関係においては、 表の中の特定の属性や列の値が別の表や列にも存在していることが必要となります。 たとえば、ある参照制約では、 従業員表の全従業員が部署表の中に含まれているいずれかの部署に所属している必要があります。 従業員が、存在しない部署に所属していてはなりません。

データベースの中に参照制約を作成すると、参照保全が必ず維持されるようになり、 照会をより能率良く処理するために、 最適化プログラムがこれらの特殊な関係の情報を活用できるようになります。 参照保全を計画する時は、 データベースの表と表の間の関係をすべて識別することが必要です。 基本キーと参照制約を定義すれば、関係を識別できるようになります。

次の関連表を考慮してください。

表 20. DEPARTMENT 表
DEPTNO (基本キー) DEPTNAME MGRNO
A00 Spiffy Computer Service Div. 000010
B01 Planning 000020
C01 Information Center 000030
D11 Manufacturing Systems 000060

表 21. EMPLOYEE 表
EMPNO(基本キー) FIRSTNAME LASTNAME WORKDEPT (外部キー) PHONENO
000010 Christine Haas A00 3978
000030 Sally Kwan C01 4738
000060 Irving Stern D11 6423
000120 Sean O'Connell A00 2167
000140 Heather Nicholls C01 1793
000170 Masatoshi Yoshimura D11 2890

次に示す概念の多くは、参照保全を理解するのに役立つものであり、 これらの表と関連して説明されています。

固有キー とは、 値が他のどの行とも重複していない 1 つの列または 1 組の列のことです。 1 つの固有キーを表の基本キーとして定義できます。 固有キーは、外部キーによって参照された場合、 親キー とも呼ばれます。

基本キー とは、 表の定義の一部である固有キーのことです。 それぞれの表は、1 つの基本キーのみを持つことができます。 前述の表では、DEPTNO と EMPNO が、 それぞれ DEPARTMENT 表と EMPLOYEE 表の基本キーです。

外部キー とは、 同じ表または別の表の固有キーまたは基本キーを参照する、 表内の 1 つの列または 1 組の列のことです。 外部キーは、表と表の間の参照保全を実施するために、 固有キーまたは基本キーとの関係を確立するために使用されます。 EMPLOYEE 表の WORKDEPT 列は、 DEPARTMENT 表の DEPTNO という基本キーを参照しているため、外部キーになっています。

複合キー とは、複数の列を持つキーのことです。 基本キーと外部キーの両方が複合キーになることができます。 たとえば、部署が部番号と課番号の組み合わせによって一意的に識別される場合、 DEPARTMENT 表のキーを作成するには 2 つの列が必要になります。

親キー とは、参照制約の基本キーまたは固有キーのことです。 基本キー制約 は、 親キー列のセットが指定されていないときの参照制約のデフォルト親キーです。

親表 とは、 同じ表または別の表の少なくとも 1 つの外部キーに関連づけられた親キーが含まれる表のことです。 1 つの表が、任意の数の関係において親となることが可能です。 たとえば、DEPTNO が基本キーの DEPARTMENT 表は、 WORKDEPT という外部キーを含む EMPLOYEE 表の親表です。

親行 とは、 その親キーの値が従属表の中の少なくとも 1 つの外部キーと一致する、 親表の 1 つの行のことです。 親表の行がすべて親行であるとは限りません。 DEPARTMENT 表の第 4 行 (D11) は、EMPLOYEE 表の第 3 行と第 6 行の親行です。 DEPARTMENT 表の第 2 行 (B01) は、他のどの行に対しても親行になっていません。

従属表 とは、外部キーを含んだ表のことです。 従属表が親表でもある場合もあります。 表は、任意の数の関係において従属表となることが可能です。 EMPLOYEE 表には WORKDEPT という外部キーが含まれており、 基本キー DEPTNO のある DEPARTMENT 表に対する従属となっています。

従属行 とは、 親キーの値と一致する非ヌルの外部キー値を持つ従属表の 1 つの行のことです。 外部キーの値は、従属行から親行への参照を表します。 外部キーがヌル値のこともあるため、従属表の行がすべて従属行であるとは限りません。

表が子孫 であるとは、 それが従属表であるか、または従属表の子孫であるということです。 子孫表には、ある表の親キーまで逆トレースできる外部キーが含まれています。

参照循環 とは、表をその表自体に接続する経路のことです。 表がその表自体に直接接続されている場合、それは自己参照 表です。 EMPLOYEE 表の中に各従業員のマネージャーの EMPNO の含まれる MGRID という別の列がある場合、 EMPLOYEE 表は自己参照表となります。 その MGRID は、EMPLOYEE 表の外部キーとなります。

自己参照表は、同一の関係において親表でもあり従属表でもあります。 自己参照行とは、その行自体の親行でもあり従属行でもある行のことです。 この状態で存在する制約は、自己参照制約と呼ばれます。 たとえば、 自己参照表の 1 つの行の中の外部キーの値がその行の中の固有キーの値と一致する場合、 その行は自己参照になります。

参照制約 とは、指定された外部キーの非ヌル値が、 指定表の固有キーの値としても現れる場合にのみ有効であることを表明することです。 参照制約の目的は、データベースの関係を維持し、 データ入力規則に従うようにすることです。

SQL 操作に及ぼす影響

参照制約を施行すると、 表が親表であるか従属表であるかに依存する一部の SQL 操作に特別な影響が及びます。 ここでは、参照保全の保守が SQL の INSERT、 DELETE、UPDATE、および DROP の操作に及ぼす影響について説明します。

DB2 は、 自動的にはシステムでの参照制約を適用しません。 そのため、システム間で参照制約を施行したい場合は、 アプリケーションの中に必要な論理が含まれていなければなりません。

この部分では、次の点について説明します。

INSERT 規則

親表への行の挿入は、従属表に対するアクションを何も行うことなく、 いつでも実行できます。 ただし、外部キーがヌル値である場合を除き、親キー値を持つ親表の中に、 挿入される行の外部キーの値と等しい行がないかぎり、 行を従属表に挿入することはできません。 複合外部キーの値は、値のいずれかの要素がヌル値であれば、ヌル値になります。

これは、外部キーが指定された場合は暗黙の規則になります。

参照制約を持っている表に行を挿入することを試みる場合、 親キーに何らかの非ヌルの外部キー値が存在しないと、INSERT 操作は許されません。 複数の行を挿入しようとした時に 1 つの行に関して INSERT 操作が失敗した場合、 行はどれも挿入されません。

DELETE 規則

親表から行を削除する場合、DB2 は、従属表の中に、 外部キーの値と一致する従属行があるかどうかを調べます。 従属行が見つかると、いくつかのアクションが実行されることがあります。 どんなアクションを実行させるかは、 従属表の作成時に削除 規則を指定することによって指定できます。

基本キー削除時の従属表 (外部キーを含む表) の削除規則は、次のとおりです。

RESTRICT
従属行が見つかると、親表の行の削除は禁止されます。 親行と従属行の両方を削除する必要がある場合は、従属行の方をまず削除してください。 最初に親行を削除しようとしても、参照制約に違反するため実行されません。

NO ACTION
すべての参照制約が適用された後、 それぞれの子に対して、親行の存在を強制します。

CASCADE
親表の行を削除すると、従属表の中の関連する行が自動的に削除されます。 この規則は、親表の行がなければ従属表の行が無意味になってしまう場合に役立ちます。

最初に親行を削除すると、基本キーを参照する従属行が自動的に削除されます。 したがって、従属行を最初に削除する必要はありません。 従属行自体に従属行がある場合にも、こうした関係についての削除規則が当てはまります。 連鎖削除は DB2 によって管理されます。

SET NULL
親表から行を削除すると、従属行の外部キーの値が必ずヌル値に設定されます。 行の他の部分は変更されません。

表の作成時に削除規則を明示的に定義しない場合は、NO ACTION 規則が適用されます。

削除操作に関係する表は、連結削除表と呼ばれます。 連結削除関係には、次の制限が適用されます。

従属表の行の削除は、親表に対するアクションなしにいつでも実行できます。 たとえば、部署 - 従業員の関係で、従業員が退職する場合、部署表には影響を与えずに、 従業員表からその従業員の行を削除することができます。 (従業員 - 部署の逆関係は、 部署のマネージャー ID が従業員表の親キーを参照する外部キーになります。 マネージャーが退職する場合は、部署表に影響します。)

UPDATE 規則

DB2 では、親行の固有キーの更新は禁止されています。 従属表の外部キーを更新する場合で、外部キーがヌル値でない場合は、 その外部キーは、その関係の親表の基本キーのいずれかの値に一致しなければなりません。 参照制約の中に UPDATE 操作で違反しているものがあれば、エラーになり、どの行も更新されません。

親キーの列の値が更新される場合、以下のようになります。

親行の中にある親キーの値を更新するためには、以下のいずれかを行うことによって、 まず従属表内のすべての子行との関係を除去しなければなりません。

行の中のキー値との従属関係がない場合、行は参照関係の親ではなくなり、 更新することができます。

外部キーの一部が更新され、しかも外部キーにヌル値の部分がない場合、 外部キーの新しい値は、親表の中の固有キーの値を示していなければなりません。 特定の固有キーに従属する外部キーがない場合、 つまり、固有キーを含んでいる行が親行ではない 場合、 固有キーの一部は更新できます。 ただし、固有キーの作業を行っており、重複行が許されないので、 この場合は、更新する行として 1 つの行しか選択できません。

表検査制約

設計の中で指定する業務上の規則は、 表検査制約によって施行できます。 表検査制約 は、表の行ごとに適用される探索条件を指定します。 これらの制約は、 表に対して更新または挿入ステートメントを適用したときに自動的に活動化されます。 また、CREATE TABLE または ALTER TABLE ステートメントを介して定義されます。

表検査制約は、妥当性検査のために使用できます。 たとえば、部署番号の値は 10 〜 100 の範囲になければならず、 従業員の職務名は、"Sales"、"Manager"、または "Clerk" だけが可能であり、 入社歴 8 年を超える従業員は $40,500 を超える収入がなければならないなどです。

IMPORT および LOAD コマンドへの表検査制約の影響についての詳細は、 データ移動ユーティリティー 手引きおよび解説書 を参照してください。

トリガー

トリガー とは、指定された表に対して、 削除、挿入、または更新の操作が行われたときにいつでも実行される、 定義済みのアクションのセットのことです。 業務規則をサポートするため、トリガーを定義できます。 トリガーは、要約や監査データを自動更新する時にも使用できます。 トリガーはデータベースに格納されるため、 どのアプリケーション・プログラムでもアクションをコーディングする必要がありません。 トリガーは 1 度だけコーディングして、データベースに保管します。 アプリケーションがそのデータベースを使用すると、トリガーは、 必要に応じて自動的に DB2 から呼び出されます。 これにより、データに関連した業務規則は必ず適用されます。 業務規則を変更した場合は、トリガーのみを変更する必要があります。

トリガー起動される SQL ステートメントからは、 ユーザー定義関数 (UDF) を呼び出すことができます。 これによって、トリガー起動時に、 トリガー起動されるアクションによって非 SQL 操作を実行できます。 たとえば、警報機構として電子メールを送信することができます。 トリガーの詳細については、 トリガーの作成 と、 アプリケーション開発の手引き を参照してください。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]