参照整合性等の制約については通常の場合、主キーと外部キーの間で設定しますが、重複を許さないインデックスを適用した列とその外部キー(と言っていいかわかりませんが)の間でも設定可能です。しかし、重複を許さないインデックスの場合は主キーと違って値をNullとすることができます。このときの連鎖更新と連鎖削除のちょっと不思議な動作についてです。
よほど意図的にやらないと遭遇しない事象ですので、マニアの方以外は気にされませんように_ _)
社員テーブルの社員番号は通常主キーとしますが、ここでは重複を許さないインデックスとします。
また、値要求オプションについては「いいえ」とします。
テーブルの例です。
値要求が「いいえ」ですので社員番号がNullの社員も許容されています。
もう一つのテーブルである契約テーブルです。こちらにも担当者となる社員番号を記録する「担当社員番号」という列があります。1人の社員が複数の契約を担当できるようになっていますので、親子関係に例えれば社員テーブルが親で契約テーブルが子となります。
なお、こちらにも担当社員番号がNullとなっている契約が2つあります。
リレーションシップの画面です。
これらの2つのテーブルの間で参照整合性等の設定を行います。キーとなるのは当然ですが社員テーブルの社員番号と契約テーブルの担当社員番号です。
さて、社員テーブルの、社員番号がNullである2人についてサブデータシートを開いても何も表示されません。
先ほど見た契約テーブルにおいて、担当社員番号がNullの契約が2つありましたが、これを見る限り「社員番号がNullの社員」と「担当社員番号がNullの契約」は、特に関連付けられていないようです。
しかしここからが問題です。
社員番号がNullである者のうち1人(加藤 愛菜)に新たに社員番号106を付与してみました。
そして、その後にサブデータシートを開くと、2つの契約が表示されます;-o-)
2つ上の画像を見る限り「社員番号がNullの社員」と「担当社員番号がNullの契約」は結び付けられていないようでしたが、連鎖更新のはたらきによって、Nullであった2つの契約の担当社員番号がともに106となり、2つの契約は社員「加藤 愛菜」が担当する契約とみなされる状態になったのです。
付与した社員番号をNullに戻すとやはり連鎖更新のはたらきにより最初の状態に戻ります。そこで、社員番号がNullであるもう1人の者(奥山 啓太)に新たに社員番号を付与すると、やはり同じようになります。つまり、2つの契約は社員「奥山 啓太」が担当する契約とみなされる状態となります。
では、社員番号がNullである行を削除するとどうなるでしょうか。
連鎖削除のはたらきにより、契約テーブルのうち担当社員番号がNullである行を同時に削除しようとするメッセージが出ます。「1件のレコードが削除されます」と表示されていますが、実際は2件とも削除されます;-o-)
当然ですが社員番号がNullであるもう1つの行を削除しようとしても同じようになります。