前回までにテーブルの設計、テーブルの正規化について説明をしてきました。 今回は正規化したテーブルの取り扱い方法について見ていきましょう。
リレーションシップの設定方法
データの整合性を担保するために「リレーションシップの設定」について説明します。まず、前回例に出した表1について再度、示します。
表1 入力データサンプル
管理番号 | 購買担当者 | 発注先名称 | 発注日 | 購買品目 | 購買数量 | 単価 | 小計 |
1 | 鈴木 太郎 | A社 | 2019/10/29 | 鉛筆(黒) | 100 | 50 | 5,000 |
1 | 鈴木 太郎 | A社 | 2019/10/29 | 消しゴム | 80 | 70 | 5,600 |
2 | 佐藤 花子 | A社 | 2019/10/30 | 消しゴム | 100 | 70 | 7,000 |
2 | 佐藤 花子 | A社 | 2019/10/30 | 鉛筆(赤) | 110 | 60 | 6,600 |
2 | 佐藤 花子 | A社 | 2019/10/30 | ボールペン | 100 | 80 | 8,000 |
3 | 鈴木 太郎 | B社 | 2019/10/30 | シャープペン | 50 | 100 | 5,000 |
3 | 鈴木 太郎 | B社 | 2019/10/30 | ノート | 200 | 120 | 24,000 |
4 | 山田 一郎 | A社 | 2019/10/31 | ボールペン | 50 | 80 | 4,000 |
5 | 佐藤 花子 | A社 | 2019/10/31 | 鉛筆(黒) | 200 | 50 | 10,000 |
5 | 佐藤 花子 | A社 | 2019/10/31 | 消しゴム | 100 | 70 | 7,000 |
5 | 佐藤 花子 | A社 | 2019/10/31 | 鉛筆(赤) | 100 | 60 | 6,000 |
5 | 佐藤 花子 | A社 | 2019/10/31 | ボールペン | 90 | 80 | 7,200 |
これらデータを正規化したテーブルに変換すると次のようになります。
T_購買伝票
管理番号 | 購買担当者 | 発注先名称 | 発注日 |
1 | 1 | 1 | 2019/10/29 |
2 | 2 | 1 | 2019/10/30 |
3 | 1 | 2 | 2019/10/30 |
4 | 3 | 1 | 2019/10/31 |
5 | 2 | 1 | 2019/10/31 |
T_購買伝票内訳
購買内訳ID | 管理番号 | 購買品目 | 購買数量 |
1 | 1 | 1 | 100 |
2 | 1 | 2 | 80 |
3 | 2 | 2 | 100 |
4 | 2 | 3 | 110 |
5 | 2 | 4 | 100 |
6 | 3 | 5 | 50 |
7 | 3 | 6 | 200 |
8 | 4 | 4 | 50 |
9 | 5 | 1 | 200 |
10 | 5 | 2 | 100 |
11 | 5 | 3 | 100 |
12 | 5 | 4 | 90 |
T_商品マスタ
商品ID | 品目 | 単価 |
1 | 鉛筆(黒) | ¥50 |
2 | 消しゴム | ¥70 |
3 | 鉛筆(赤) | ¥60 |
4 | ボールペン | ¥80 |
5 | シャープペン | ¥100 |
6 | ノート | ¥120 |
T_取引先マスタ
取引先ID | 取引先名称 |
1 | A社 |
2 | B社 |
T_担当者マスタ
担当者ID | 担当者氏名 |
1 | 鈴木 太郎 |
2 | 佐藤 花子 |
3 | 山田 一郎 |
さて、ここでT_購買伝票テーブルの内、管理番号=1のレコードは間違って登録したために、削除したとします。するとどうでしょうか?
T_購買伝票内訳テーブルには管理番号=1のレコードが残ったままになってしまいます。
このように、データの整合性を維持するためにAccessではリレーションシップの設定をします。
具体的には次の図を見てみましょう。
データベースツールタブをクリックし、リレーションシップアイコンをクリックすると、リレーションシップツール画面が開きます。
テーブルの表示アイコンをクリックし、リレーションシップ設定をするT_購買伝票、T_購買伝票内訳を選択し、「追加」をクリックすると、それぞれのテーブルが表示されます。
この後は、「閉じる」を押しましょう。
T_購買伝票テーブルの「管理番号」フィールドとT_購買伝票内訳テーブルの「管理番号」フィールドをリレーションシップ設定するため、ドラッグアンドドロップをすることで、リレーションシップ画面が開きます。
ここで、参照整合性、フィールド連鎖更新、レコードの連鎖削除チェックボックスにチェックを入れます。
参照整合性: 冒頭で述べたようにリレーション関係のあるテーブル間でレコードの不整合が発生する場合に警告を発し、削除等をできないようにします。
フィールドの連鎖更新: 1対多の関係において、「1」側のテーブル内レコードを更新すると、「多」側のレコードも連鎖して更新する設定です。
レコードの連鎖削除: 参照整合性設定をしているときに、「1」側のテーブル内レコードを削除すると、「多」側のレコードも連鎖して削除する設定です。
以上の操作により、1対無限のリレーションシップ設定ができました。
なお、マスタテーブルは各レコードを一義的に決まる番号(担当者ID等)で管理しており、データの整合性を担保できるようにテーブル設計をしているため、今回はリレーションシップ設定を行わずに、この後の作成を進めます。
まとめ
今回は、リレーションシップや参照整合性等の設定目的、その設定方法について紹介してきました。リレーションシップは必ずしも設定する必要はありませんが、複雑なデータベースを構築する際、また莫大なデータを取り扱う場合には、設定をしておくことで管理側の負担を減らすこともできるようになりますので、その意義は理解していただけると良いかと思います。
次回からは、レコード操作のために用いる「クエリ」を紹介していきます。
以下の書籍は、著者がAccessを勉強する際に参考になった書籍のシリーズです。
是非ご覧になってください。
スポンサーリンク
コメント