ダイアグラム（DIAGRAM）でテーブルを関連付け、結合方向と参照整合性制約を保存しておけば、アプリケーションやビューからSQLによってテーブルを関連付けた場合に、その定義が自動的に反映され、ある処理によって宙に浮いてしまったレコードや、関連付けられているのに双方の値が異なるフィールドが存在するような矛盾を、データベースエンジンの側で解決してくれます。
- ダイアグラムとリレーションシップ -
画面8は、EnterpriseManagerで「商品_mr、仕入先_mr、在庫_mr」の３つのテーブルを関連付けたダイアグラムです（このダイアグラムは「DIAGRAM1」という名前でサンプルのデータベースに含まれています）。
テーブルを追加した後、フィールドリストからフィールドをドラッグしてもう一方のフィールドに重ねれば、結合が定義されます。その後、描かれた結合線を右クリックしてコンテキストメニューを表示し「プロパティ」を選択すれば、「リレーションシップ」タブから関連付けと結合に関するプロパティを編集できます。
ここで「INSERTとUPDATEに対するリレーションシップを適用する」にチェックを付けて有効にすれば、参照整合性制約を設定できるようになります。
- 参照整合性制約の設定 -
「商品_mr」と「在庫_mr」のような１対１の結合では、通常は「関連レコードの連鎖削除」をチェックして有効にしておきます。
「商品_mr」と「仕入先_mr」のようにマスターテーブル同士を１対多で結合した場合は、特に何も設定しないのが普通です。もし「仕入先_mr」の「仕入先ID」フィールドの値が変更される可能性があるなら、「関連フィールドの連鎖更新」をチェックして有効にしておきます。
販売（受注）記録のような１対多の関連付けでは、「商品_mr」の「商品ID」や「得意先_mr」の「お客様ID」がいきなり変更される場合に備え、「関連フィールドの連鎖更新」をチェックして有効にしておく場合もあります。
但し、リレーションを保った状態でマスターテーブルのIDフィールドがいきなり変更されるケースというのは、まず滅多にありません。そういった事態を招かないよう、通常の業務を行っている時間帯にはマスターテーブルの保守を行わないという形に、システム自体を設計しておくべきです。従って、「関連フィールドの連鎖更新」はあまり頻繁に設定するものではありません（むしろ、仕様設計段階での検討の方が重要で、仕様を適当に設計して後から参照整合性制約に頼るのは本末転倒です）。
なお、参照整合性制約を有効にすると、当然のことながらデータベース処理のパフォーマンスは低下します。
- 連鎖削除・連鎖更新は必須ではない -
ここまでの説明でお分かりのように、レコードの連鎖削除やフィールドの連鎖更新は、必ず設定しなければならない──というものではありません。
一方のテーブルからレコードを削除したりフィールドの値を変更（更新）したりすることで、もう一方のテーブルにどこからも参照されないレコードが生じたり、テーブルの記録内容自体に矛盾が生じたりする可能性がある場合にだけ、自動的にデータベース全体の整合性を図る目的で利用するものです。
中には、これらを設定すると問題を引き起こす場合もあります。例えば、商品IDをキーに商品マスターを参照している商品の販売（受注）記録のテーブルで、参照先である商品テーブルから商品のレコードを削除したとしましょう。レコードの連鎖削除を設定していると、その商品の販売を記録したレコードがすべて削除されることになります。
このように、特に１対多のリレーションでは、連鎖削除を設定してはいけない関連付けがあります。業務全体を見てテーブル同士の関係を把握し、適切に設定しましょう。矛盾を生じないよう、システム全体の仕様を設計することが最も重要です。
 |
|
|
