MS Access リレーションシップの組み方でより良い方法はどれか

Question

#実現したいこと
管理する建物の雑多な情報を一元管理できるようなデータバンクをAccessで実現したい。
（独学なのでいろいろ間違っているかもしれません）

#お尋ねしたいテーマ
建物名を元に、性質が異なる枝になる情報がいくつもあることを想定しています。

例）テーブル
t01_建物名：建物名のみ登録
t02_室番号 ：建物ごとに存在する部屋番号
t03_建物住所：建物の住所

　これらのテーブルのリレーションシップを組む場合、

　1.従たるテーブル全部が一つの主たるテーブルのユニークコードを引用する場合

　2.主たるテーブルのクエリを作成し、従たるテーブルごとにクエリからユニークコードを引用する場合

　どちらがより良い考え方なのか、よくわからないでいます。

　1.の場合、リレーションシップの画面で主従の関係が明確にわかる一方、t01を開いた際、Accessから子テーブルがどれか決定するよう要求が出ると思います。

2.の場合、リレーションシップの画面で情報が系統ごとに把握できる一方、クエリ内部の状態がつかみにくいということがあるように思います。
（追記）2.の場合、現在クエリの中身は単純ですが、今後引用する情報が増えてくると、クエリを通じていろいろなテーブルをリンクすることを予想しています。

　現在は枝が二つですが、実際に管理したい情報は多岐にわたっています。

　今後展開されるテーブルの予想例）
t04_入居者氏名：室ごとの入居者名を記録
（t01_建物名←t02_室番号←t04_入居者氏名　でリンク）

t05_親メータ検針データ：建物ごとの親メータ、電気・ガス・水道の検針データを記録
（t01_建物名←t05_親データ検針データ　でリンク）

　t06_子メータ検針データ：室ごとの子メーター、電気・ガス・水道の検針データを記録
（t01_建物名←t02_室番号←t06_子メータ検針データ　でリンク）

　：
：

そこであらかじめ方針を決めておいたほうがプログラムが楽だと思います。　

#皆様へ質問

　ある親テーブルの下にいくつもの子テーブルが存在する場合、親テーブルのユニークコードをリンクするためには

上記1.のようにする場合
上記2.のようにする場合

どちらがより良いと思われますか？
上記のメリットデメリットとか、ほかにもやり方があるよとか、そのようなお話も伺えれば大変ありがたいです。

　いろいろ本を読んだりやネットで調べましたが、そこまで論じているものは見つけ出すことができませんでした。

　なにとぞよろしくお願い申し上げます。

Answer 1

リレーションシップ自体の定義には拘り過ぎない方が良いですよ。

リレーションの関係は起点とするものを何にするかによって変わるので、１パターンで定義できるものでは無いです。

何れかにするかなら、正規化の観点からは１です。

個人的には、制約が生じたりするのでリレーションシップの定義は使わない事が多いですね。

Comments

[Attl]

早速のご回答ありがとうございました。
なるほど、あまりこだわらなくてもよいみたいですね。
何せ経験がないので迷ってしまいました。
ありがとうございました。

Answer 2

1.の場合、リレーションシップの画面で主従の関係が明確にわかる一方、t01を開いた際、Accessから子テーブルがどれか決定するよう要求が出ると思います。

提示のテーブルを作成してリレーションシップも提示通りに設定してみましたが、そのような要求は出ませんでした。（追記、レコードセレクタの＋をクリックするとでますね。）

また、必要ならばデザインビューで「サブデータシート名」で子テーブルとして表示するテーブルを選択することはできますので、子テーブル（サブデータシート）の表示が必要ないならここを[なし]に設定しておけばいいでしょう。（追記、[なし]に設定しておくとレコードセレクタの＋が表示されなくなりますね。）

さて、ここから本題です。

リレーションシップ機能の本質

Accessにおけるリレーションシップ機能ですが、主に２つの機能があります。

ひとつは、クエリを作成したり、ウィザードでフォームやレポートを作成するときに、リレーションシップの定義にそって、自動で結合やリンクを設定してくれる機能。設計時に手助けしてくれる便利機能ですね。

もう一つは、参照整合性（それに付随する連鎖更新、連鎖削除）の機能です。この機能について説明すると長くなるので下記のリンク先を読んでおいてください。

参照整合性 - Wikipedia

リレーションシップの設定と効果 - もう一度学ぶMS-Access

リレーションシップ、特に参照整合性を設定しておくのは私は必須だと考えています。（詳細は下記のリンク参照。）

リレーションシップを設定した場合の利点 - hatena chips

そのうえで、
2.のクエリと結合するリレーションシップは、参照整合性は設定できません。（グレーになって選択不可になってます。）つまり、リレーションシップの機能のうち、前者の便利機能のみということです。
参照整合性はテーブル間でしか設定できないのです。

参照整合性の機能を活かすなら1.の方法を選択すべきだと考えます。

（追記）2.の場合、現在クエリの中身は単純ですが、今後引用する情報が増えてくると、クエリを通じていろいろなテーブルをリンクすることを予想しています。

クエリを作成するときに、用途に応じて結合を決定すればいい話で、リレーションシップで事前に決めておく必要はないし、一意に定義出るものではないと思います。

私の意見をまとめると、

1.の方法で各テーブル間で結合して、さらに参照整合性にチェックを入れておく。連鎖更新、連鎖削除に関しては必要に応じてチェックをいれる。
リレーションシップにクエリを含める必要性はほとんどない。

Comments

[Attl]

ご回答ありがとうございます。
ご紹介いただいたURL先を読ませていただきました。

>t01を開いた際、Accessから子テーブルがどれか決定するよう要求が出ると思います。
正しくは「＋を押すとリンク子フィールドの指定を要求される」でした。表現があやふやで申し訳ありません。

参照整合性については「クエリの元になるテーブルの書式なり変数型式なりがそのまま引用される動作をするため、テーブル間のリンクで参照整合性にチェックを入れたことと同義」だと思っていました。

引き続き勉強したいと思います。
ありがとうございました。

[hatena19]

「＋を押すとリンク子フィールドの指定を要求される」に関しては回答にもありますが「サブデータシート名」を「なし」にするかテーブル名を設定しておく要求されなくなります。

[Attl]

ご回答ありがとうございます。
その点は存じておりました。
子フィールドを都度選択する方法をよく知らないため、一度指定してしまったら別の子フィールドへ移動できないという思いもありました。

[hatena19]

別の質問をみると、テーブルまたはクエリで直接入力しているようですが、そこから改めるべきかと思います。そうすればリレーションシップの設定を複雑にする必要はなくなります。

[sazi]

参照整合性については、外部からの入力で参照整合性を保てない入力（親が後から）を過去に経験してそれから使ってないですね（チェックは独自に行う）
なので、推奨はしない、あくまで個人の経験ですけど。

[hatena19]

参照整合性のチェックを独自でできるスキルをお持ちで、かつ、外部から入力で保てないというような特別な事情かあるならしないほうがいいと私も思います。
私自身は、参照整合性のメリットは実感してます（独自に参照整合チェックするのはかなりの負担です。）

[sazi]

連鎖更新はありだと思いますけどね。

[hatena19]

連鎖更新は、一対多の一側を更新したときに、多側も連鎖して更新されるという機能ですよね。
一側のキー（マスターのキー）自体を更新することはまずないので、ほとんど設定してませんが、その必要性があるなら設定すべきですね。

[sazi]

連鎖更新よりも連鎖削除の方が有用度は高いと思います。
ナチュラルキーを採用しなければ、連鎖更新が必要な場面は抑えられるので。
また、参照整合については、サブフォームを用いれば自ずとそうなるので、敢えて必要無いと思っています。

[Attl]

>テーブルまたはクエリで直接入力しているよう
今のところその通りです。直接入力させるのは、フォームをビルドすることを後まわしにして、取り急ぎ自分の思う設計で動作するか確認したいため、間にクエリを挟むのは、工程の中間で自分のほしい結果が発生しているか見たいためです。（そういう手順が変だと思われていますかね？？？汗）

皆様の議論を拝見しますと、あまり良い手ではないものの、やっていけないということでもなさそうで、それだけでも設計の方針に幅がとれると知り、安心しました。

スマートなDBを作り上げるまでには、まだまだ自己研鑽が必要だと痛切に思いました。
ありがとうございました。