ACCESSでの別のテーブルのデータの参照方法

質問

ACCESS初心者です。
教えてください。

「支払」テーブル、「担当表」テーブルがあります。
「支払」テーブルには、
ID（主キー）、サービス名、金額、支払日
「担当表」テーブルには、
ID（主キー）、サービス名、担当者
という項目があります。
この二つのテーブルは「サービス名」で連結してます。

今「支払」テーブルの入力フォームを作っていて、サービス名をプルダウンで選択出来るようにしたのですが、出来れば選択したら自動的に該当する担当者の名前を表示したいと思っています。
担当者名を表示するためのテキストボックスを作成し、プロパティでいろいろいじってみましたがどうもうまく行きません。

すごく基本的な質問で恐縮ですが、どうか助けてください。
宜しくお願いいたします。

回答No.4

you-m · ベストアンサー

せっかく日付のデータがあるのに、わざわざ月別の集計が必要だからといって月だけのフィールドを追加するのも、あんまりスマートなやり方ではありません。

データベースの目的の一つは、同じ種類の情報を二重管理しない事もあります。
日付から、月だけを抽出するのが自然な方法でしょう。

ですが、SQL云々を悩むよりも、まずウィザードをぐりぐりいじって見てください。比較的単純な月ごとの合計値を出すクエリは10秒で出来ますよ。

クロス集計のクエリ自体は、非常に簡単にできますし、見てみればイメージもわきやすいでしょう。

それでデータが壊れるわけではないし、クエリなんて作っては消しての繰り返しで問題ないです。
もちろん、テーブルを消してしまってはまずいですけど（笑）
いろいろ試しているうちに、逆にこういうまとめ方もできるのかといった発見もあるかもしれませんよ。

お礼

いつも丁寧なご回答ありがとうございます。

おっしゃる通り、ウィザードで簡単に集計できましたし、イメージも沸きました。
あとクエリのSQLも見てみましたが「これがSQLか！」って感じでした（以前シスアドの勉強をしていた時に出てまして、その時は全くピンと来なかったんですが…（苦笑））。
まだまだ先は長そうですが、これで何とかなりそうです。

初めてACCESSに触れ、データベース構築方法のとっかかりもなく、途方にくれていたところを助けていただいて感謝しております。

お忙しいところ、初心者にお付き合いいただいて有難うございました。
またつまづいてしまったら、お助けくださいませ。
有難うございました。

回答No.3

you-m

月次の集計自体は、クエリを使えば、都度支払台帳から出せるので、テーブルを作るよりも、いいと思います。

案件別のものであれば、抽出条件として日付とサービスIDに条件を付加すれば、その部分だけ取り出す事は可能です。
SQLで、WHEREを使う部分ですね。

集計が欲しい場合は、クロス集計のクエリを作成します。
SQL的には、GROUP BY句やPIVOTを使うような内容になります。
ある値の月次の集計等が、簡単に出せますし、やはり抽出条件を指定する事で、サービスと月の指定もできます。

いずれも、ウィザードで比較的簡単にたたき台が作れますし、作った後で細かくSQLを修正する事もできます。
ウィザードは、あんまり融通が利きませんので（笑）

ただ、担当者については月中で交代とか、サービス毎に1人という状態が、必ず成り立つのでなければ、入れない方がいいでしょう。

ここでテーブルを分けてしまうと、リレーショナルデータベースの一番便利なところを使わずにいる事になりますよ。

お礼

何度もご丁寧にご回答ありがとうございます！

まだ「SQL」がどのようなものであるかはちょっとわかりませんが（EXCELは使えるのでPIVOT等は何となく想像がつきますが）、とりあえずテーブルを分けてしまうことが大きな間違いであることは、よくわかりました。

とすると、確認ですが、テーブルを分けずに月毎の集計を出すには、「何月の」サービスなのかという項目が追加で必要になりますよね？

例えば、今まで支払台帳を
ID、サービスID、担当者ID、請求額、支払日
としていましたが、
ID、サービスID、サービス提供月、担当者ID、請求額、支払日
として、基本テーブルを組み直せばいい、ということです？
そこでSQL（これから勉強します）を使って、サービス提供月を抽出条件に、サービス名を縦軸、担当者名、請求額、支払日を横軸に置きなおして表示をすると、サービス提供月毎の支払状況を一覧で確認できるクエリが完成！ってことですよね。

何度も初心者質問ですみません。。。

回答No.2

you-m

基本的にデータベースのマスタと呼ばれるようなテーブルは、ID等のデータを一意に指定出来るようなコードを持って表現するのが、望ましいです。

今回の場合も、担当者とサービスが同じテーブルで無ければ、IDで表現する事に何も問題は無いのです。
先の回答は、データ構造をあまり大きく変更しないように回答したのですが、多分以下のようなデータ構造が本来望ましいのではと思います。

支払台帳
ID、サービスID、担当者ID、請求額、支払日

サービスマスタ
ID、サービス名、基本料金、サービス内容、備考

担当者マスタ
ID、氏名、備考

まあ、細かいフィールドについては、まだまだ足りない部分もあるでしょうが、私ならこのようなデータ構造にすると思います。
どことどこがリレーションするかは分かりますよね？
これなら、過去のデータが矛盾する事無く、担当者やサービス内容についても、独立して管理出来ます。

お礼

たびたびご回答ありがとうございます。

自分で頭をひねったところ、ご回答のようなテーブルを作成するに至りました（「備考」は入れてなかったですけど、これいただきです(笑））。
リレーションはもちろん「支払台帳_サービスID」と「サービスマスタ_ID」、「支払台帳_担当者ID」と「担当者マスタ_ID」ですよね？
これをもとに、
サービス名、サービス内容、氏名（担当者名）、請求額、支払日でクエリを作成し、フォームを作ったところ、思い通りの表を作成することができました。
ありがとうございました。

ちなみに質問の内容が変わり、かつ何度も質問して申しわけありませんが、再度質問させてください。
最終的にこの支払管理を月次締めにしていこうと考えています。
例えば４月が役務提供月のサービスの支払状況一覧、５月が役務提供月のサービスの支払状況一覧、という形です。
私の考えとしては、支払台帳をベースにして、４月支払台帳、５月支払台帳、といったものを用意してやっていこうと思い、テーブルを作成しております。
しかし、考え方として、サービスID毎をベースにしてテーブルをつくる方法もあると思います。
例）
Aサービス
４月、（４月の）料金、（４月の）担当者、（４月分の）支払日
５月、（５月の）料金、（５月の）担当者、（５月分の）支払日
・・・
Bサービス
４月、（４月の）料金、（４月の）担当者、（４月分の）支払日
５月、（５月の）料金、（５月の）担当者、（５月分の）支払日
・・・
提供されるサービスのラインナップは、月ごとに大きな変化はありません。
もしかすると後者の組み方のほうが賢い、ということはありますでしょうか？

やや頭がこんがらがってます。
何卒ご教授ください。
宜しくお願い致します。

回答No.1

you-m

恐らく今は入力フォームに対して支払いテーブルを渡しているのでは無いかと思いますが、これを自分で結合クエリを作成して、そのクエリを渡せば良いかと思います。

ウィザードで作れますので、すでにリレーションの設定がされているのであれば、簡単に作成できます。

作成したクエリは、あたかもテーブルであるかのように扱えますので（もちろん全く同じではありませんけど）このような事ができます。

どのような仕様が欲しいのか、具体的には分からないので断言はさけますが、このような使い方をするならば担当表テーブルにはIDは不要かと思います。

私であれば支払いテーブルにサービス名の変わりにサービスIDというフィールドを作成して、それとリレーションさせます。
なぜなら、サービス名は変わるかもしれないからです。
また、担当者名というフィールドも別途支払テーブルに追加します。
そして、入力フォームから支払の記録を入れる際に、サービスIDから担当者名を引っ張ってきて、担当者名を直接そこにいれます。
これは、同じサービスに対して永遠に担当者が変わらないとは限らないからです。
支払は、一度支払ったらその事実が変わる事は無く、また担当者はその時点の担当者の名前が入っていなければなりません。
途中で担当者が変わって、その後に見てみたら、自分では心当たりの無い案件に、担当者として自分の名前が入っているような事態は、避けた方が良いでしょう。

お礼

ご回答ありがとうございます。

出したい要素が別のテーブルに存在する場合は、結合してクエリを作成し、そのクエリを元に入力フォームを作成する、という理解でよろしいでしょうか？

結合クエリは何となくできましたが、なかなか思う通りの形になりません。
しかし地道に勉強して頑張っていこうと思います。

あと薄々気づいていたのですが、ご指摘の通り、そもそもテーブルの組み方に問題がありました。アドバイス通りに作り直してみようと思います。
尚、「担当者名というフィールドも別途支払テーブルに追加します」とありますが、「担当者ID」より「担当者名」のほうがよろしいのでしょうか？
担当者表というテーブルも別途作成し、基本このテーブルは削除なしというルールで担当者もIDで表現した方がより管理しやすいのかな？なんて思いました。意味ないですかね…？