SQL Serverでは、外部キー制約（およびCHECK 制約）は、信頼できる場合と信頼できない場合があります。
制約が信頼できる場合、これは制約がシステムによって検証されたことを意味します。信頼されていない場合、制約にはがありません システムによって検証されました。
基本的に、信頼できない制約がある場合、データベースに無効なデータが含まれている可能性もあります。これは、制約に違反するデータが存在する可能性があることを意味します。
これは、リレーションシップ内で参照整合性を維持しなくなったことを意味します。これは、本番環境でリレーショナルデータベースを管理する場合、通常は適切な方法ではありません。
この記事では、既存の制約の「信頼性」を確認してから、もう一度信頼できるように更新します。
例1-既存の制約を確認する
sys.foreign_keysにクエリを実行すると、制約が信頼できるかどうかを確認できます。 システムビュー。
このように：
SELECT name AS 'Constraint', is_disabled, is_not_trusted FROM sys.foreign_keys;
結果：
+-------------------+---------------+------------------+ | Constraint | is_disabled | is_not_trusted | |-------------------+---------------+------------------| | FK_Albums_Artists | 1 | 1 | | FK_Albums_Genres | 0 | 1 | +-------------------+---------------+------------------+
OK、これは私に2つの外部キー制約があり、両方とも信頼できないことを示しています。
制約の1つが無効になっているため、信頼されていないことは理にかなっています（制約が無効になっていると、不正なデータがデータベースに入る可能性があります）。
ただし、他の制約は有効になっているため、信頼できないものであってはなりません。信頼できないということは、データベースに無効なデータが存在する可能性があることを意味します。 があるという意味ではありません 無効なデータ、可能性がある なれ。
基本的に、有効にすることで将来のデータをチェックしますが、既存のデータを保証することはできません。制約が信頼できる場合は、既存のすべてのデータが有効であることを確認できます。
信頼できない制約のみを返す
WHEREを使用することをお勧めします 信頼できない制約のみを返す句。このように：
SELECT name AS 'Constraint', is_disabled, is_not_trusted FROM sys.foreign_keys WHERE is_not_trusted = 1;
結果：
+-------------------+---------------+------------------+ | Constraint | is_disabled | is_not_trusted | |-------------------+---------------+------------------| | FK_Albums_Artists | 1 | 1 | | FK_Albums_Genres | 0 | 1 | +-------------------+---------------+------------------+
したがって、この場合、結果は同じです（現在のすべての制約が信頼されていないため）。
例2–信頼の回復
有効な制約への信頼を復元するには、WITH CHECKを使用しながら再度有効にします。 オプション。
このように：
ALTER TABLE Albums WITH CHECK CHECK CONSTRAINT FK_Albums_Genres;
ここで、sys.foreign_keysをクエリすると 別の結果が得られます：
SELECT name AS 'Constraint', is_disabled, is_not_trusted FROM sys.foreign_keys;
結果：
+-------------------+---------------+------------------+ | Constraint | is_disabled | is_not_trusted | |-------------------+---------------+------------------| | FK_Albums_Artists | 1 | 1 | | FK_Albums_Genres | 0 | 0 | +-------------------+---------------+------------------+
is_not_trustedであるため、制約が信頼されていることがわかります。 フラグは0に設定されています 。
例3–制約はどのようにして信頼できないものになりましたか？
外部キー制約を無効にすると、自動的に信頼できなくなります。同じ制約を再度有効にすると、その信頼を回復する機会があります。これを行わないと、信頼されないままになります。
外部キー制約を有効にする場合、WITH CHECKを指定するオプションがあります またはWITH NOCHECK 。後で指定した場合、制約が有効になると、制約は信頼されないままになります。
WITH NOCHECKに注意することが重要です はデフォルトのオプションであるため、信頼する必要があることを明示的に指定しない場合、制約は信頼できないものとして有効になります。
ただし、外部キー制約を作成する場合は逆になります。最初に制約を作成するとき、デフォルトのオプションはWITH CHECKです。 。したがって、この設定を省略すると、デフォルトで信頼されます（無効なデータがある場合を除き、その場合は有効になりません）。ただし、WITH NOCHECKを明示的に指定することで、この設定を上書きできます。 制約を作成するとき。
有効にした制約が簡単に信頼できないままになる可能性があることを示すために、もう一方のキー（無効にしたキー）を再度有効にしますが、デフォルト設定を使用します：
ALTER TABLE Albums CHECK CONSTRAINT FK_Albums_Artists; SELECT name AS 'Constraint', is_disabled, is_not_trusted FROM sys.foreign_keys;
結果：
+-------------------+---------------+------------------+ | Constraint | is_disabled | is_not_trusted | |-------------------+---------------+------------------| | FK_Albums_Artists | 0 | 1 | | FK_Albums_Genres | 0 | 0 | +-------------------+---------------+------------------+
したがって、怠惰な（または忘れている）ことと、WITH CHECKを明示的に指定しないことによって 、「信頼されていない」ステータスをそのままに保ちながら、制約を有効にすることに成功しました。
これからの重要なポイントは次のとおりです。再度有効にした制約を信頼できるようにする場合は、常にWITH CHECKを使用して有効にする必要があります。 。