アクセスのリレーションシップが多対多の場合について

質問

初めて質問させていただきます。
多対多の対応方法については勉強してやっては見たのですが、うまく機能しないので質問させていただきます。

中間テーブルを作成して現在ABCの３つのテーブルがあります。頓挫しているのでかなり不備がありますが、それも踏まえて助言をお願いします。
　　　フィールド名は
A：aID、氏名、所有物No、数量
B：bID、aID、cID、事由、日時
C：cID、事由タイプ、タイプ１のgrade、料金、タイプ2のgrade、料金、タイプ3のgrade、タイプ3の細分タイプ、料金

Aは名簿、Bは中間用に試作、C料金体系テーブル、といった形を目指しました。
同一人物で複数請求があり、一つのフォーム上でAとBを追加、更新出来るようにしたいです。
また、料金体系のテーブルの事由タイプは３つでそれぞれgrade毎に料金体系があります。
Cのテーブルはそれぞれのタイプはその他のタイプのところは空欄になっています。

このままクエリを作って見ると追加、更新が出来ません。
以上、わかりにくいですが、助言お願いします。

回答No.1

007MUKADE · ベストアンサー

回答が付きませんね・・・・・

書かれた内容から どの様な業務で どの様にしたいのか？ が解らないのです。
特に・・＞C：cID、事由タイプ、タイプ１のgrade、料金、タイプ2のgrade、料金、タイプ3のgrade、タイプ3の細分タイプ、料金
のテーブルの意味が掴めません。

Exell の１行目みたいな フィールドですね。これでは クエリー操作は困るでしょうね。
テーブル構造をもう少し考え直さないと ・・・・・・

補足

返信ありがとうございます。
やはり料金体系のテーブルは細分化した方がいいでしょうか。
一つのテーブルで管理しやすいと思ったのですが。
てーぶるCは事由タイプが３つあり、それぞれ１，２，３として、それぞれに区分があります。
また、事由タイプ３だけは区分が２つあります。
事由タイプ毎に料金テーブルを分けたほうがいいですか？
もう少し、テーブルの構造を考えてみます。

回答No.2

layy

何が多か？、多‐多は１‐多の集まり

テーブル分ける前、１つのテーブルなら追加更新できる状態か？

主キーや副キーはあるのか。

ひたすら入力蓄積するデータ
１度登録したらしばらく変えないデータ
この２つから生まれるデータ
整理出来てますか。

１テーブル化を考えてから正規化し細分化でも良いです。

クエリなら関係も明確に。例えば、会員マスタと取引マスタだったら、１会員が何度も取引するから．．．．とか整理。

質問伝わらないなら、回答もあいまい。

お礼

返信遅れましたが、事故解決。といいますか、一からテーブル構造を組み直しました。

料金体系が少し複雑なので一つ表をテーブルに作って、これを素に料金を参照しやすいように新しくテーブルを作りました。
少し面倒ですが、料金テーブルは頻繁には変更がないのでこれで少し対応できそうです。

ひとまず、この問題は無くなりましたが、今度はまた少し違う問題が出てきたので亦改めて質問させていただきます。

ありがとうございました。