データの整合性とビジネス ルールの設定
データの整合性を設定すると、データベース内のデータの質が保証されます。テーブルのプランを作成する際には、列の有効な値を識別することと、その列のデータの整合性の設定方法を決定することの 2 つのステップが重要です。データの整合性は次の 4 種類に分類され、いくつかの方法で設定可能です。
整合性のタイプ
設定オプション
|
実体
PRIMARY KEY 制約
UNIQUE 制約
IDENTITY プロパティ
ドメイン
ドメイン DEFAULT 定義
FOREIGN KEY 制約
CHECK 制約
NULL 値の許容
参照
ドメイン DEFAULT 定義
FOREIGN KEY 制約
CHECK 制約
NULL 値の許容
ユーザー定義
CREATE TABLE でのすべての列制約およびテーブル制約
ストアド プロシージャ
トリガ
実体の整合性
実体の整合性は、行を特定のテーブルの一意な実体として定義します。実体の整合性は、テーブルの識別子列または主キーの整合性を、インデックス、UNIQUE 制約、PRIMARY KEY 制約または IDENTITY プロパティによって設定します。
■ 制約に名前を付ける
制約には常に明示的に名前を付けることをお勧めします。名前を付けずにおくと、Oracle と SQL Server は異なる名前付け規則を使って制約に既定の名前を付けます。名前付け規則の違いによって、移行処理が不必要に煩雑になる場合があります。制約は名前で削除する必要があるため、制約を削除または無効にするときに違いが出てきます。制約に明示的に名前を付けるための構文は、Oracle と SQL Server とで同一です。
CONSTRAINT constraint_name
■ 主キーと一意な列
SQL-92 標準では、主キーのすべての値は一意でなければならず、主キーが NULL 値であってはなりません。Oracle と SQL Server ではいずれも、PRIMARY KEY 制約または UNIQUE 制約が定義されている場合に常に一意なインデックスを自動的に作成することによって、一意性を保証しています。さらに、主キーの列は NOT NULL として自動的に定義されます。主キーは 1 つのテーブルに 1 つしか認められません。
デフォルトの状態では、SQL Server のクラスタ化インデックスは主キー用に作成されますが、非クラスタ化インデックスを要求することもできます。Oracle では、制約を削除または無効にすることでインデックスを削除できますが、SQL Server では制約を削除しない限りインデックスを削除することはできません。
どちらの RDBMS でも、UNIQUE 制約を使用して代替キーを定義できます。複数の UNIQUE 制約を任意のテーブルに対して定義できます。UNIQUE 制約の列には、NULL 値が許容されます。SQL Server では、特に指定しない限り、デフォルトの状態では非クラスタ化インデックスが作成されます。
アプリケーションの移行時、完全に一意なキー（単一または複数の列インデックス）の場合、SQL Server では、NULL 値を持つことができるのは 1 行だけですが、Oracle では、NULL 値を持つ行が何行あってもかまわないことに注意してください。
Oracle
SQL Server
|
CREATE TABLE DEPT_ADMIN.DEPT
CREATE TABLE
(DEPT VARCHAR2(4) NOT NULL,
USER_DB.DEPT_ADMIN.DEPT
DNAME VARCHAR2(30) NOT NULL,
(DEPT VARCHAR(4) NOT NULL,
CONSTRAINT DEPT_DEPT_PK
DNAME VARCHAR(30) NOT NULL,
PRIMARY KEY (DEPT)
CONSTRAINT DEPT_DEPT_PK
USING INDEX TABLESPACE
PRIMARY KEY CLUSTERED (DEPT),
USER_DATA
CONSTRAINT DEPT_DNAME_UNIQUE
PCTFREE 0 STORAGE (
UNIQUE NONCLUSTERED (DNAME)
INITIAL 10K NEXT 10K
)
MINEXTENTS 1 MAXEXTENTS
UNLIMITED),
CONSTRAINT DEPT_DNAME_UNIQUE
UNIQUE (DNAME)
USING INDEX TABLESPACE USER_DATA
PCTFREE 0 STORAGE (
INITIAL 10K NEXT 10K
MINEXTENTS 1 MAXEXTENTS
UNLIMITED)
)
■ 制約の追加と削除
制約を無効にすることで、データベースのパフォーマンスが向上し、データ レプリケーション プロセスが効率的になります。たとえば、リモート サイトでテーブル データをリビルドまたはレプリケートする場合、制約のチェックを繰り返す必要はありません。データ整合性は、データがテーブルに入力された時点でチェックされるからです。Oracle アプリケーションで（PRIMARY KEY と UNIQUE 以外の）制約を有効または無効にしている場合は、ALTER TABLE ステートメントで CHECK オプションと WITH NOCHECK オプションを使用することによって、SQL Server で同じプロセスを簡単に達成できます。
この処理を次の図で示します。
SQL Server では、ALL キーワードと NOCHECK 句を使用して、すべてのテーブルの制約を無効にできます。
Oracle アプリケーションで CASCADE オプションを使用して PRIMARY KEY 制約または UNIQUE 制約を無効または削除している場合は、プログラム コードの一部を書き直さなければならないことがあります。CASCADE オプションでは、親および関連する子の両方の整合性制約を無効にしたり、削除したりするからです。
構文の例を次に示します。
DROP CONSTRAINT DEPT_DEPT_PK CASCADE
SQL Server のアプリケーションでは、子の制約を先に削除してから親の制約を削除するように修正する必要があります。たとえば、DEPT テーブルの PRIMARY KEY 制約を削除するには、STUDENT.MAJOR 列と CLASS.DEPT 列の外部キーを削除する必要があります。構文の例を次に示します。
ALTER TABLE STUDENT
DROP CONSTRAINT STUDENT_MAJOR_FK
ALTER TABLE CLASS
DROP CONSTRAINT CLASS_DEPT_FK
ALTER TABLE DEPT
DROP CONSTRAINT DEPT_DEPT_PK
制約の追加と削除に使用する ALTER TABLE 構文は、Oracle と SQL Server とでほぼ同じです。
■ 連続した数値の生成
Oracle のアプリケーションで SEQUENCES を使用している場合には、Microsoft SQL Server の IDENTITY プロパティを利用するように簡単に変更することができます。
カテゴリ
SQL Server の IDENTITY
|
構文
CREATE TABLE new_employees
(Empid int IDENTITY(1,1),
Employee_Name varchar(60),
CONSTRAINT Emp_PK PRIMARY KEY(Empid)
)
If increment interval is 5:
CREATE TABLE new_employees
(Empid int IDENTITY(1,5),
Employee_Name varchar(60),
CONSTRAINT Emp_PK PRIMARY KEY(Empid)
)
テーブル 1 つあたりの ID 列数
1
NULL 値の許容
許容せず
既定の制約値の使用
使用不可
一意性の設定
あり
INSERT ステートメント、SELECT INTO ステートメント、または一括コピーが終了すると、現在の最大 ID 番号を照会します。
@@IDENTITY（関数）
ID 列の作成時に指定された seed の値を返します。
IDENT_SEED('table_name')
ID 列の作成時に指定されたインクリメント値を返します。
IDENT_INCR('table_name')
SELECT 構文
SELECT ステートメント、INSERT ステートメント、UPDATE ステートメント、DELETE ステートメントに IDENTITY プロパティを含む列を参照する場合に、列名の代わりにキーワード IDENTITYCOL を使用できます。
IDENTITY プロパティは、テーブル内の各行を一意に識別する一連番号を自動的に作成できますが、識別子列はテーブルごとに作成されるため、他のテーブルでは識別子列に同じ値が生成されてもかまいません。IDENTITY プロパティは、識別子列が定義されたテーブル内で一意でありさえすればよいからです。データベース全体あるいはネットワーク接続された世界中のあらゆるコンピュータ上の各データベースで一意な識別子列を生成しなければならない場合は、ROWGUIDCOL プロパティと uniqueidentifier データ型、NEWID 関数を使用してください。SQL Server は、グローバル一意識別子列を使用してマージ レプリケーションを行い、複数のテーブルに渡って行が一意に識別されるようにしてください。
識別子列の作成と修正の詳細については、SQL Server の［Books Online］を参照してください。
ドメイン整合性
ドメイン整合性は、エントリがその列のエントリとして妥当であることを保証します。ドメイン整合性は、（データ型によって）値の型を、（CHECK 制約によって）値の形式を、（REFERENCE 制約と CHECK 制約によって）値の範囲を制限することによって保つことができます。
■ DEFAULT 制約と CHECK 制約
既定値は Oracle では列のプロパティとして扱われますが、SQL Server では制約として扱われます。SQL Server の DEFAULT 制約には、定数値、引数を取らない組み込み関数（ニラディック関数）または NULL を含むことができます。
Oracle の DEFAULT 列のプロパティを簡単に移行するには、SQL Server の列レベルで DEFAULT 制約を定義し、制約名を適用しないようにしてください。SQL Server は、DEFAULT 制約ごとに一意な名前を生成します。
CHECK 制約を定義するための構文は、Oracle でも SQL Server でも同じです。検索条件は論理式として評価される必要があり、サブクエリを含むことはできません。列レベルの CHECK 制約は、制約された列だけを参照でき、テーブル レベルの CHECK 制約は、制約されたテーブルの列だけを参照できます。1 つのテーブルに対して複数の CHECK 制約を定義できます。SQL Server の構文では、1 つの CREATE TABLE ステートメントで列 レベルの制約を 1 つしか定義することができませんが、列のそれぞれの制約は複数の条件を持つことができます。
修正後の CREATE TABLE ステートメントをテストするには、SQL Sever で構文のみを解析する方法が一番です。エラーがあればすべて結果ペインに表示されます。制約構文の詳細については、SQL Server の［Books Online］を参照してください。
Oracle
SQL Server
|
CREATE TABLE STUDENT
CREATE TABLE USER_DB.STUDENT
_ADMIN.STUDENT(
_ADMIN.STUDENT(
SSN CHAR(9) NOT NULL,
SSN CHAR(9) NOT NULL,
FNAME VARCHAR2(12) NULL,
FNAME VARCHAR(12) NULL,
LNAME VARCHAR2(20) NOT NULL,
LNAME VARCHAR(20) NOT NULL,
GENDER CHAR(1) NOT NULL
GENDER CHAR(1) NOT NULL
CONSTRAINT
CONSTRAINT STUDENT_GENDER_CK
STUDENT_GENDER_CK
CHECK (GENDER IN ('M','F')),
CHECK (GENDER IN ('M','F')),
MAJOR VARCHAR(4)
MAJOR VARCHAR2(4)
DEFAULT 'Undc' NOT NULL,
DEFAULT 'Undc' NOT NULL,
BIRTH_DATE DATETIME NULL,
BIRTH_DATE DATE NULL,
TUITION_PAID NUMERIC(12,2) NULL,
TUITION_PAID NUMBER(12,2) NULL,
TUITION_TOTAL NUMERIC(12,2) NULL,
TUITION_TOTAL NUMBER(12,2) NULL,
START_DATE DATETIME NULL,
START_DATE DATE NULL,
GRAD_DATE DATETIME NULL,
GRAD_DATE DATE NULL,
LOAN_AMOUNT NUMERIC(12,2) NULL,
LOAN_AMOUNT NUMBER(12,2) NULL,
DEGREE_PROGRAM CHAR(1)
DEGREE_PROGRAM CHAR(1)
DEFAULT 'U' NOT NULL
DEFAULT 'U' NOT NULL
CONSTRAINT STUDENT_DEGREE_CK
CONSTRAINT
CHECK
STUDENT_DEGREE_CK CHECK
(DEGREE_PROGRAM IN ('U', 'M',
(DEGREE_PROGRAM IN ('U', 'M', 'P',
'P','D')),
'D')),
...
...
ユーザー定義の規則と既定値について、下位互換性を維持する目的で SQL Server の規則と既定値に関する構文を残してありますが、新規のアプリケーション開発では CHECK 制約と DEFAULT 制約を使用することをお勧めします。詳細については、SQL Server の［Books Online］を参照してください。
■ NULL と NOT NULL
SQL Server でも Oracle でも、列の制約を作成して NULL 値を許容するか否かを設定します。CREATE TABLE ステートメントまたは ALTER TABLE ステートメントで指定しない限り、Oracle の表の列はデフォルトで NULL になります。SQL Server では、列の定義で使用したデータ型が NULL 値を許すかどうかは、データベースやセッションの設定に優先することがあります。
（Oracle であるか SQL Server であるかとは無関係に）すべての SQL スクリプトで列ごとに NULL と NOT NULL を両方とも明示的に定義することをお勧めします。具体的な方法については、テーブル作成のサンプル スクリプト Oratable.sql と Sstable.sql を参照してください。明示的に指定しなければ、列で NULL 値を許すかどうかは、次のルールに従います。
NULL の設定
説明
|
列がユーザー定義のデータ型で定義されている
SQL Server は、データ型の作成時に指定された NULL 値を許容するかどうかの設定を使用します。データ型に NULL 値を許すかどうかのデフォルトの設定を調べるには、sp_help システム ストアド プロシージャを使用します。
列がシステム提供のデータ型で定義されている
システム提供のデータ型にオプションが 1 つしかない場合は、これが優先されます。bit 型は NOT NULL としてだけ定義できます。
セッションの設定が ON（SET で設定）の場合は、次のようになります。
ANSI_NULL_DFLT_ON が ON の場合は、NULL が割り当てられます。
ANSI_NULL_DFLT_OFF が ON の場合は、NOT NULL が割り当てられます。
データベースの設定が構成（sp_dboption システム ストアド プロシージャで変更）されている場合は、次のようになります。
ANSI null デフォルトが true の場合は NULL が割り当てられます。
ANSI null デフォルトが false の場合は NOT NULL が割り当てられます。
NULL/NOT NULL 未定義
明示的に定義されない場合（ANSI_NULL_DFLT オプションのいずれも設定されない）は、セッションは変更されず、データベースはデフォルト（ANSI null デフォルトが false）に設定され、SQL Server はこれに NOT NULL を割り当てます。
参照整合性
参照整合性の制約の定義に使用される構文を次に示します。
制約
Oracle
SQL Server
|
PRIMARY KEY
[CONSTRAINT
[CONSTRAINT
constraint_name]
constraint_name]
PRIMARY KEY (col_name [,
PRIMARY KEY [CLUSTERED |
col_name2 [..., col_name16]])
NONCLUSTERED] (col_name [,
[USING INDEX
col_name2 [..., col_name16]])
storage_parameters]
[ON segment_name]
[NOT FOR REPLICATION]
UNIQUE
[CONSTRAINT
[CONSTRAINT
constraint_name]
constraint_name]
UNIQUE (col_name [,
UNIQUE [CLUSTERED |
col_name2 [..., col_name16]])
NONCLUSTERED](col_name [,
[USING INDEX
col_name2 [..., col_name16]])
storage_parameters]
[ON segment_name]
[NOT FOR REPLICATION]
FOREIGN KEY
[CONSTRAINT
[CONSTRAINT
constraint_name]
constraint_name]
[FOREIGN KEY (col_name [,
[FOREIGN KEY (col_name [,
col_name2 [...,
col_name2 [...,
col_name16]])]
col_name16]])]
REFERENCES
REFERENCES [owner.]ref_table
[owner.]ref_table [
[(ref_col [, ref_col2 [...,
(ref_col [, ref_col2 [...,
ref_col16]])]
ref_col16]])]
[NOT FOR REPLICATION]
[ON DELETE CASCADE]
DEFAULT
列のプロパティには制約がない
[CONSTRAINT
DEFAULT (constant_expression)
constraint_name]
DEFAULT {constant_expression
| niladic-function | NULL}
[FOR col_name]
[NOT FOR REPLICATION]
CHECK
[CONSTRAINT constraint_name]
CHECK (expression)
[CONSTRAINT constraint_name]
CHECK [NOT FOR
REPLICATION] (expression)
NOT FOR REPLICATION 句は、レプリケーション時に、列レベルの制約、FOREIGN KEY 制約、CHECK 制約が設定されるのを防止するために使用されます。
■ 外部キー
外部キーを定義する規則は、各 RDBMS で似ています。外部キーの句で指定した列の数とデータ型は、REFERENCES 句と一致する必要があります。この列に入力された NULL でない値は、REFERENCES 句で定義してあるテーブルと列の中に存在する必要があります。参照されるテーブルの列は、PRIMARY KEY 制約または UNIQUE の制約を持っている必要があります。
SQL Server の制約は、同じデータベース内のテーブルしか参照できません。複数のデータベースにまたがる参照整合性を得るには、テーブル ベースのトリガを使用してください。
Oracle と SQL Server は両方とも自己参照テーブルをサポートします。これは、同一のテーブルの 1 つ以上の列に対して参照（外部キー）を置くことができるテーブルです。たとえば、CLASS テーブルの 列 prereq は、CLASS テーブルの 列 ccode を参照し、コースの前提として有効なコース コードを入力することができます。
Oracle ではカスケード削除とカスケード更新を CASCADE DELETE 句で定義できますが、SQL Server ではテーブル トリガで同じ機能が得られます。詳細については、この章の「SQL 言語サポート」を参照してください。
ユーザー定義の整合性
ユーザー定義の整合性は、他の整合性のカテゴリに当てはまらない特定のビジネス ルールを定義することを可能にします。
■ ストアド プロシージャ
ユーザーが指定するパラメータを受け取り、またそれを返す SQL Server のストアド プロシージャを作成するには、CREATE PROCEDURE ステートメントを使用します。ストアド プロシージャは現在のデータベース内でのみ作成できますが、一時ストアド プロシージャだけは例外です。ストアド プロシージャを作成するための Oracle と SQL Server での構文を次の表に示します。
Oracle
SQL Server
|
CREATE OR REPLACE PROCEDURE
CREATE PROC[EDURE] procedure_name
[user.]procedure
[;number]
[(argument [IN | OUT] datatype
[
[, argument [IN | OUT] datatype]
{@parameter data_type} [VARYING]
{IS | AS} block
[= default] [OUTPUT]
]
[,...n]
[WITH
{ RECOMPILE | ENCRYPTION |
RECOMPILE, ENCRYPTION} ]
[FOR REPLICATION]
AS
sql_statement [...n]
SQL Server では、ローカル一時プロシージャの場合は procedure_name の前にシャープ記号（#）を 1 つ付加（#procedure_name）し、グローバル一時プロシージの場合は procedure_name の前にシャープ記号を 2 つ付加（##procedure_name）して、tempdb データベース内で作成します。
ローカル一時プロシージャは、それを作成したユーザーだけが使用できます。ローカル一時プロシージャの実行権限を他のユーザーに与えることはできません。ローカル一時プロシージャは、ユーザー セッションの終了時に自動的に削除されます。
グローバル一時プロシージャの場合は、SQL Server のすべてのユーザーが利用できます。グローバル一時プロシージャを作成すると、ユーザー全員がそれにアクセスでき、権限を明示的に取り消すことはできません。グローバル一時プロシージャは、そのプロシージャを使用する最後のユーザー セッションの終了時に削除されます。
SQL Server のストアド プロシージャは、32 レベルまでネストすることができます。ネストレベルは、呼び出されたプロシージャが実行を開始すると 1 つ増え、呼び出されたプロシージャが実行を終了すると 1 つ減ります。
次の例は、Transact-SQL ストアド プロシージャを使用してどのように Oracle PL/SQL パッケージ関数を置き換えるかを示したものです。SQL Server では、カーソルを使用せずに結果のセットを SELECT ステートメントから直接返すことができるため、Transact-SQL を使う方がはるかに簡単です。
Oracle
SQL Server
|
CREATE OR REPLACE PACKAGE
CREATE PROCEDURE
STUDENT_ADMIN.P1 AS ROWCOUNT
STUDENT_ADMIN.SHOW_
NUMBER :=0;
RELUCTANT_STUDENTS
CURSOR C1 RETURN
AS SELECT FNAME+'' +LNAME+',
STUDENT%ROWTYPE;
social security number'+ SSN+'
FUNCTION
is not enrolled in any classes!'
SHOW_RELUCTANT_STUDENTS
FROM STUDENT_ADMIN.STUDENT S
(WORKVAR OUT VARCHAR2) RETURN
WHERE NOT EXISTS
NUMBER;
(SELECT 'X' FROM
END P1;
STUDENT_ADMIN.GRADE G
/
WHERE G.SSN=S.SSN)
ORDER BY SSN
CREATE OR REPLACE PACKAGE BODY
RETURN@@ROWCOUNT
STUDENT_ADMIN.P1 AS CURSOR C1
GO
RETURN STUDENT%ROWTYPE IS
SELECT * FROM
STUDENT_ADMIN.STUDENT
WHERE NOT EXISTS
(SELECT 'X' FROM
STUDENT_ADMIN.GRADE
WHERE
GRADE.SSN=STUDENT.SSN) ORDER
BY SSN;
FUNCTION SHOW_RELUCTANT_STUDENTS
(WORKVAR OUT VARCHAR2) RETURN
NUMBER IS
WORKREC STUDENT%ROWTYPE;
BEGIN
IF NOT C1%ISOPEN THEN OPEN C1;
ROWCOUNT :=0;
ENDIF;
FETCH C1 INTO WORKREC;
IF (C1%NOTFOUND) THEN
CLOSE C1;
ROWCOUNT :=0;
ELSE
WORKVAR := WORKREC.FNAME||'
'||WORKREC.LNAME||
', social security number
'||WORKREC.SSN||' is not enrolled
in any classes!';
ROWCOUNT := ROWCOUNT + 1;
ENDIF;
RETURN(ROWCOUNT);
EXCEPTION
WHEN OTHERS THEN
IF C1%ISOPEN THEN CLOSE C1;
ROWCOUNT :=0;
ENDIF;
RAISE_APPLICATION_ERROR
(-20001,SQLERRM);
END SHOW_RELUCTANT_STUDENTS;
END P1;
/
SQL Server には、Oracle のパッケージや関数のような構成はありません。また、ストアド プロシージャを作成するための CREATE OR REPLACE オプションもありません。
■ ストアド プロシージャの実行の遅延
SQL Server には、ステートメント ブロック、ストアド プロシージャまたはトランザクションを起動する、時刻、時間またはイベントを指定する WAITFOR ステートメントがあります。これは、Oracle の dbms_lock.sleep と等しい Transact-SQL です。
WAITFOR {DELAY 'time' | TIME 'time'}
DELAY
最長 24 時間までの指定時間が経過するまで SQL Server に待機を指示します。
'time'
待機する時間の長さです。time は、datetime データに適合するいずれかの形式で指定することも、ローカル変数として指定することもできます。日付を指定することはできません。したがって、datetime 値の 日付の部分は無視されます。
TIME
指定時刻になるまで SQL Server に待機を指示します。
BEGIN
WAITFOR TIME '22:20'
EXECUTE update_all_stats
END
■ ストアド プロシージャのパラメータの指定
ストアド プロシージャ内のパラメータを指定するには、次の構文を使用します。
Oracle
SQL Server
|
Varname datatype DEFAULT <value>;
{@parameter data_type}[VARYING] [= default][OUTPUT］
|
■ トリガ
Oracle と SQL Server のどちらにもトリガはありますが、機能には若干の違いがあります。
説明
Oracle
SQL Server
|
テーブル 1 つあたりのトリガ数
無制限
無制限
INSERT、UPDATE、DELETE の前に実行されるトリガ
あり
なし
INSERT、UPDATE、DELETE の後に実行されるトリガ
あり
あり
ステートメント レベルのトリガ
あり
あり
行レベルのトリガ
あり
なし
実行前の制約チェック
トリガが無効にならない限り、チェックあり。
チェックあり。これはデータ変換サービスのオプションでもある。
UPDATE トリガまたは DELETE トリガで古い値または前の値を参照する
:old
DELETED.column
INSERT トリガで新しい値を参照する
:new
INSERTED.column
トリガを無効にする
ALTER TRIGGER
データ変換サービスのオプション
DELETED と INSERTED は、トリガ ステートメントに対して SQL Server が作成する論理（概念的）テーブルです。この論理テーブルは、トリガを定義し、行の値がユーザー操作によって変更された場合の元の値と新しい値を保持するテーブルと構造的には似ています。これらのテーブルは、行レベルの変更を Transact-SQL でトラッキングします。その機能は Oracle の行レベルのトリガと同様です。INSERT ステートメント、UPDATE ステートメントまたは DELETE ステートメントを SQL Server で実行すると、トリガ テーブルに行が追加されると同時に、INSERTED テーブルと DELETED テーブルにも行が追加されます。
INSERTED テーブルおよび DELETED テーブルは、トリガ テーブルと同じもので、列名やデータ型も同じになります。たとえば、GRADE テーブルにトリガを設定すると、INSERTED テーブルと DELETED テーブルは次のような構造になります。
GRADE
INSERTED
DELETED
|
SSN CHAR(9)
SSN CHAR(9)
SSN CHAR(9)
CCODE VARCHAR(4)
CCODE VARCHAR(4)
CCODE VARCHAR(4)
GRADE VARCHAR(2)
GRADE VARCHAR(2)
GRADE VARCHAR(2)
INSERTED テーブルと DELETED テーブルをトリガによって検査し、どのタイプのトリガを行うべきか判断することができます。INSERTED テーブルには INSERT ステートメントと UPDATE ステートメントを使用します。DELETED テーブルには DELETE ステートメントと UPDATE ステートメントを使用します。
UPDATE ステートメントは、INSERTED テーブルと DELETED テーブルの両方を使用します。UPDATE を実行すると常に古い行が削除され、新たな行が追加されるからです。この結果、UPDATE を実行すると、INSERTED テーブルの行は常に DELETED テーブルの行と同じものになります。
次の例では、INSERTED テーブルと DELETED テーブルを使用して PL/SQL の行レベルのトリガを置き換えます。完全外部結合では、両方のテーブルのすべての行が結果に含まれます。
Oracle
SQL Server
|
CREATE TRIGGER
CREATE TRIGGER
STUDENT_ADMIN.TRACK_GRADES
STUDENT_ADMIN.TRACK_GRADES
AFTER
ON STUDENT_ADMIN.GRADE
INSERT OR UPDATE OR DELETE
FOR INSERT, UPDATE, DELETE
ON STUDENT_ADMIN.GRADE
AS
FOR EACH ROW
INSERT INTO GRADE_HISTORY(
BEGIN
TABLE_USER, ACTION_DATE,
INSERT INTO GRADE_HISTORY(
OLD_SSN, OLD_CCODE, OLD_GRADE
TABLE_USER, ACTION_DATE,
NEW_SSN, NEW_CCODE, NEW_GRADE)
OLD_SSN, OLD_CCODE,
SELECT USER, GETDATE(),
OLD_GRADE, NEW_SSN,
OLD.SSN, OLD.CCODE,
NEW_CCODE, NEW_GRADE)
OLD.GRADE,
VALUES (USER, SYSDATE,
NEW.SSN,
:OLD.SSN, :OLD.CCODE,
NEW.CCODE,
:OLD.GRADE,
NEW.GRADE
:NEW.SSN,
FROM INSERTED NEW FULL OUTER JOIN
:NEW.CCODE,
DELETED OLD ON NEW.SSN = OLD.SSN
:NEW.GRADE),
END;
トリガは現在のデータベースでしか作成することができませんが、他のデータベース内のオブジェクトを参照することはできます。トリガを修飾する所有者名を指定するときは、テーブル名を同じ方法で修飾します。
トリガは 32 段階のレベルまでネストすることができます。あるトリガが別のトリガを持つテーブルを変更した場合、2 番目のトリガがアクティブになり、次に 3 番目のトリガを呼び出すという具合に、順にアクティブになります。このトリガのチェインで無限ループが発生すると、ネスト レベルの上限を超えたことになり、トリガはキャンセルされます。また、テーブルの 1 つの列に対して更新トリガを実行することで他の列が更新される場合は、この更新トリガは一度しかアクティブになりません。
SQL Server の宣言参照整合性（DRI）ではデータベース間の参照整合性は得られません。データベース間の参照整合性が必要な場合はトリガを使用してください。
次の挙げるステートメントは、Transact-SQL のトリガでは使用できません。
CREATE ステートメント（DATABASE、TABLE、INDEX、PROCEDURE、DEFAULT、RULE、TRIGGER、SCHEMA、VIEW）
DROP ステートメント（TRIGGER、INDEX、TABLE、PROCEDURE、DATABASE、VIEW、DEFAULT、RULE）
ALTER ステートメント（DATABASE、TABLE、VIEW、PROCEDURE、TRIGGER）
TRUNCATE TABLE
GRANT、REVOKE、DENY
UPDATE STATISTICS
RECONFIGURE
UPDATE STATISTICS
RESTORE DATABASE、RESTORE LOG
LOAD LOG、DATABASE
DISK ステートメント
SELECT INTO（テーブルが作成されてしまうため）
トリガの詳細については、SQL Server の［Books Online］を参照してください。