以前の記事でリレーショナルデータベースを構築する上では、「リレーション」の理解が必要不可欠であることをお伝えしてきました。
リレーションが設定されているテーブル間で、片方のテーブルからレコードが削除された場合に、もう一方のレコードとの整合性にどのようなことが起こるでしょうか。
今回は、リレーショナルデータベースにおける「参照整合性」について例を交えて紹介をします。
サンプルテーブル
参照整合性の説明をする上で、表1に示すサンプルテーブルを用意しました。
表1 「T_購入」テーブル(上)と「T_担当者」テーブル(下)
担当者ID | 購入品 | 数量 | 購入日 |
11AA | えんぴつ | 10 | 2022/7/10 |
11AA | ノート | 2 | 2022/7/10 |
11AA | 消しゴム | 5 | 2022/7/15 |
12AB | えんぴつ | 20 | 2022/7/1 |
13AC | ノート | 5 | 2022/7/14 |
担当者ID | 担当者 | 部署コード | 部署 |
11AA | 鈴木 | Z0 | 営業 |
12AB | 山下 | Z1 | 製造 |
13AC | 佐藤 | Z9 | 経理 |
表1で示す2つのテーブルは、「担当者ID」フィールドをキーとして「一対多」のリレーションを設定することができます。
「T_購入」テーブルでは、「担当者ID」フィールドの値に「11AA」が繰り返し登録されていることからも分かるとおり、「T_担当者」対「T_購入」=「一対多」のリレーションシップとなります。
ここまでは、前回の記事でご説明したとおりです。それでは、次から参照整合性とはどのようなものなのかを見ていきましょう。
片方のテーブルからレコードが削除されたら
第2正規形として存在する2つのテーブルは、効率良くデータを保存することができますが、例えば、「T_担当者」テーブルの内、担当者ID「11AA」のレコードが削除されてしまったら、「T_購入」テーブルではどのようなことが起こるでしょうか。
この場合、「T_購入」テーブルでは、担当者ID「11AA」の人が購入実績に併せて4件のレコードを登録していますが、「T_担当者」テーブルで「11AA」のレコードが削除されると「T_購入」テーブルで不整合レコードが発生することになります。
なぜならば、「T_購入」テーブルから「T_担当者」テーブルを参照したときに、「11AA」の人のレコードが存在しないことになるからです(図1参照)。
このように、リレーショナルデータベースでは情報を主題ごとの多数のテーブルに分割して、保存するデータの重複をできるだけ少なくする「正規化」処理によって保守性を高めることができる一方、各テーブルで不用意なレコード削除が行われた結果、参照不整合が発生するおそれがあります。
Accessで参照整合性の設定をする目的
参照整合性を設定する目的は、参照の同期を保ち、上で示したようにレコードの孤立した状態が発生しないようにすることです。このため、リレーショナルデータベースを構築する上では、「リレーション」設定を行い、参照整合性を維持することが大切になります。
Accessでは、参照整合性を設定することでフィールドの連鎖更新やレコードの連鎖削除を設定することができるようになり、データの完全性を担保するための一助になります。
まとめ
今回はデータの完全性を担保するために「参照整合性」をどのような考えの下に設定をするかを紹介しました。
次回は、Accessで具体的にリレーションと参照整合性を設定する方法を紹介します。
データベース設計について学習されたい方は専門書などもを参考にされると良いかと思います。
スポンサーリンク
コメント