keyword 6 制約（整合性制約）
データベースのデータは、ビジネスルールに則って正しく格納されている必要があります。例えば、社員表の社員番号は重複していてはならないとか、在庫表の数量の値はマイナスになってはいけないなどです。しかし、データを入力したり更新したりする際に、オペレーションミスや悪意的な作為によってルールに反する状態になってしまう可能性があります。
データを正しくするための方法として、いくつかの方法が考えられます。アプリケーション側に、そのためのロジック（例えば、数量にはマイナスデータはあり得ないなど）としてビジネスルールを組み込んでおくことが思い浮かぶでしょう。ただし、そうすると、すべてのアプリケーションにビジネスルールを組み込む必要があり、1つのアプリケーションでもそれを怠ってしまうと、正しくなくなる可能性が出てきます。また、正しさを保証するビジネスルールに修正が発生したときに、ビジネスルールが組み込まれているすべてのアプリケーションのメンテナンスを行なわなければなりません。
そのため、データベース側でビジネスルールのチェックを行なうものとして用意されているものが「制約（整合性制約）」になります。データベース側でチェックを行なう利点として、ビジネスルールをデータベース1箇所で集中管理することにより、どのようなビジネスルールがあるかを把握しやすく、またメンテナンスが発生した際の手間が最小限（データベース上の1箇所の修正）で済むことが挙げられます。一方、欠点として、制約に違反するデータが発生した際に、そのデータの発生元のアプリケーションではなく、ネットワークを経由してデータベースまで到着した後に、判明したエラーをアプリケーション側に返すことになるので、ネットワークの負荷が大きくなる可能性があります（図11）。
制約（整合性制約）には、主キー、 一意、 NOT NULL、チェック、参照整合性などの種類があり、それぞれ列に対して指定します。簡単に紹介すると、次のようになります。
主キー制約
正規化のところで説明しましたが、表の行を識別する制約となります。必ず値が入っていなければならず、値の重複を許しません。表に対してただ1つのみ設定できます。
一意制約
列の値の重複を許さない制約です。
NOT NULL制約
値が入っていない状態を「NULL値」と言います。このNULL値を防ぐ、つまり必ず該当の列には値が入っている状態を強制する制約です。
チェック制約
例えば、数量列は値が0よりも大きくなければならないように、列の値が特定の範囲に収まっていることを保証する制約です。
参照整合性（外部キー）制約
データベースの説明のところでリレーションシップという言葉を説明しましたが、そのリレーションシップの値の関連付けを強制する制約となります。例えば、社員表の部署コードの値は部署表の部署コードの列の値のいずれかでなければなりません。もし、この状態に反するような値が入っていた場合、その社員はどの部署に所属しているのかが分からなくなります。このような状態にならないように、各種の操作を抑止する働きがあります。社員表の部署コードにこの制約を定義することになります（図12）。
ストアドプロシージャ
データベースにはデータのほか、アプリケーションを格納することもできます。データベースに格納したアプリケーションを「ストアドプロシージャ」と言います。これを利用して、制約として実現できないビジネスルール（例えば、処理は9:00～18:00の間でないと行なえないなど）についてロジック化し、データベースに格納し集中管理することもできます（図13）。
トリガー
データ入力などの各種の操作に応じて、あらかじめ動作内容を設定させておくこともできます。これを「トリガー」と呼びます。例えば、表に対する入力（INSERT）時に表に対するビジネスルールを表にトリガーとして作成しておき、自動的にその操作が正しいかチェックさせることを可能とします。チェックに失敗したらアプリケーションにエラーを返します。
ストアドプロシージャとの違いは、実行時に明示的にその格納されているアプリケーションの名前を指定する必要がなく、データ入力などの各種の操作に応じて、自動的に起動するところにあります（図14）。また、トリガーを使用すると、連携したアプリケーションの自動起動などを行なうこともできます。例えば、受注表に受注データが追加（INSERT）されたら、在庫表の在庫データを減らす（UPDATE）アプリケーションを連携実行させます。これにより、アプリケーションやシステムフローの設計をシンプルにする効果があります（図15）。
Keyword 7～12は、後編（近日公開予定）で紹介します。
