ろでますと申します。
以下のようなパターンが設定できません。
これはそもそもできないのでしょうか？
「M1」親テーブル（であってるかな？）のフィールド1・2・3には
PK
1 1 A
1 2 B
1 3 C
1 4 D
という数字とデータが入っており、この1・2つのフィールドを主キーにして複合キーを作っています。
この場合、このPKを用いて、
「M2」子テーブルでは
FK
山田さん 1 1
加藤さん 1 3
佐藤さん 1 1
になっています。
ではまた別の親テーブル「M3」テーブルがあるとします。
PK
2 1 E
2 2 F
2 3 G
とあった場合、M1－M2データベース間のリレーショナルを切った後、さらにM1－M3テーブルとリレーショナルを組もうとすると整合性エラーではじかれてしまします。
私は「M1」テーブルと「M3」では完全に主キーがユニークなはずなのになぜだろうと首をかしげています。
「M2」テーブルを以下の様に設定したい意味です。
FK
山田さん 1 1
加藤さん 1 3
佐藤さん 1 1
田中さん 2 1
伊藤さん 2 3
にしたいと思っています。
こうすれば、クエリで
山田さん＝A
加藤さん＝C
田中さん＝E
と取得できると思っていました。
ちなみに整合性チェックを入れなければ動操作して、クエリでもデータを取得できるのですが、きちんとした動作ではないですよね・・・。
質問の設定だと、それぞれのテーブルが
M1(一) →(多)M2
M1(一) →(多)M3
のような一対多関係になります。
一つのクエリで上記の結合をしてしまうと、M2とM3が多対多の関係になるので、ユニークに決まらない場合で出てくるので整合性エラーになります。
例えば、下記のような場合、
M1
1 1 A
1 2 B
1 3 C
M3
1 1 X
2 1 E
2 2 F
M2 の FK が 1 1 のとき、A か X か決まりませんよね。
M1 と M3 を分けずに一つににまとめれば、このような重複は許可されないので整合性の保証されたデータになり、エラーはでなくなります。
PK
1 1 A
1 2 B
1 3 C
1 4 D
2 1 E
2 2 F
2 3 G
M1 と M3 を分けたまま、２つのテーブル間で上記のようなユニーク属性を制定するのはできません。
やるとしたら、上記のように一つに纏めておいて、必要に応じて、選択クエリで分割することになると思います。
整合性が保障されないので、整合性に反したデータの入力が可能になってしまいますので、入力、更新するたびに自前で整合性をチェックする(VBAなどで)ことになります。
わざわざそのような面倒かつ不確実なこともぜすとも上記のように必要に応じて選択クエリに分ける設計にすれば問題奈と思います。
ご回答どうもありがとうございます！
確かにおっしゃる通りの方法でうまくいきました。
すいませんが、この後実は色々難所があり、それもお伺いしてもよろしいでしょうか。
このテーブル構成で、
FK
山田さん 1 1
加藤さん 1 3
佐藤さん 1 1
田中さん 2 1
伊藤さん 2 3
となっているときに、FKの左側が1の方に質問があったとします。（山田さん・加藤さん・佐藤さん）
その問いが別のテーブルにあり、10個（01～10）の回答から複数選択しなさいという物いです。
同様にFKの左側が2の方に質問があったとします（田中さん・伊藤さん）
その問いが別のテーブルにあり、15個（01～15）の回答から複数選択しなさいという物いです。
この場合、どういったテーブルを作って、何処のテーブルと結合していいかが全く考え付きません。
よろしければご教授願えませんでしょうか・・・。
いろいろ考えられますが、
一つの解決策としては下記のようなテーブル構成にするのが自由度か高いかな、と思います。
M_Category （カテゴリーマスター）
K1, K2 複合PK
M_Person （人物マスター）
※F1、F2 は M_Category の外部キー
T_Question （質問テーブル）
※K1 は M_Category の外部キー
T_Choice （選択肢）
CID, QID 複合PK
QID は T_Question の外部キー
T_Person_Choice （人物がどの選択肢を選択したか）
テーブル名とかは出された情報から推測で適当につけてますので、参考程度に。
これはあくまで一例ですので、別の方法もあるかと思います。
こんばんわ、ろでますです。
すいません、私の知識不足で、上から読み解いていくうちにわからないことが出てきたので、教えていただけませんか。
＞※F1、F2 は M_Category の外部キー
これはK1、K2の誤記ですか？（揚げ足を取るとかそんなんではなく、純粋に）
あと、
M_Category （カテゴリーマスター）
でK1・K2は2つで複合キーになっていると思うのですが、その後ろの
T_Question （質問テーブル）
の説明書きに
＞※K1 は M_Category の外部キー
とあります。
なぜ、複合主キー内のK1のみを主キーとしてT_Question （質問テーブル）のK1を外部キーとして扱うことができるのかがわかり間ませんでした。（おっしゃりたい意味は大体理解できます）
ためしに、M_Category （カテゴリーマスター）テーブルのK1キーとT_Question （質問テーブル）のK1キーをリレーショナルすると、「未定義となりました」
すいません、ここがわからなかったのでこれ以上先に進めていません＞＜
よろしければご教授願います。
あっ、誤記です。すみません。回答の方も修正しておきます。
そうですね。これは外部キーにはなりませんね。
脳内だけで構成を考えていたのでこのへんはちょっとおかしいですね。
これはリンクせずに、入力フォームを作成するときの抽出条件に使うという感じの設計になるのかな。
各人物の回答用の入力フォームは、メイン/サブフォーム形式のものになるので、
メインで回答者を選択するコンボボックスの値集合リストの抽出条件に使うといいかも。
これもあくまで脳内シミュレーションでの構成ですので、実際につくると修正が必要になるかも知れません。
こんばんわ、ろでますです。
ご返信ありがとうございます。
となると、VBAに足を突っ込まないといかないかもということですか。
エクセルのはそこそこ使ったことあるんですが・・・
Accsessとなってくると、初めてになります。
SQL構文覚えないと＞＜
VBAが必須かどうかは要件によりますが、入力フォームやレポートでの見やすい出力を考えたら、クエリ(SQL)だけでは解決できないと思います。
メイン/サブフォーム形式、レポートのグループ化機能などを使う必要が出てくると思います。