<HOME  <お願い事項   <Access2002 TOP   <Access97 TOP   <サイト内検索
  MS-Access2000超入門部屋--いろいろなクエリ
 [はじめに] [AND条件] [OR条件] [または] [パラメータ] [〜以上] [〜の間] [あいまい] [YesNo] [条件組合わせ] [複数テーブル] 
 [並べ替え] [トップ値] [集計] [「週」で集計] [クロス集計]



■何組の、どの職業の人がいくら売ったのか(クロス集計)

「所属ごとに、職業別の売上集計」っていうのを作ってみようと思います。縦横両方向に伸びる、少々変わった形のクエリです。
縦方向に「職業」、横方向に「所属」を取り、売上金額の合計を出します。だいたいどんな感じに仕上がりそうか、イメージ浮かべてみてくださいね。

まず、こんな感じのクエリを作ります。「売上」の金額と、「所属」「職業」のフィールドを、ひとつにまとめるわけですね。

で、なんか名前を付けて保存しておきます。
このクエリを基にして、「クロス集計クエリ」というのを、新規作成していきます。



まず、さっき保存したクエリを選びます。テーブルの一覧とクエリの一覧と、表示を切り替えるようになってますので要注意です。

次に、縦方向に使用するフィールドを指定します。4列まで選べるんですけど・・・今回は「職業」だけ選びます。

次に、横方向の項目を選びます。今回は「所属」を選ぶとしますね。

で、どのフィールドの中の値を、どういう感じで集計するのか、という設定をする画面になります。
「売上」を「合計」しましょうか。


「カウント」というやつを除いて、まあだいたいここで指定するのは数値型のフィールドですね。
合計したり、平均値取ったり、そんなことをやります。

左下に「集計値を表示する」ってのがありますね。ここチェックついてると、「職業ごとの合計」を、1列使って表示してくれます。
「さくら」「ゆり」「すみれ」の3列だけでよければ、このチェックははずすんですが・・・。今日はこのままやってみましょうか。

じゃーん。出ました??

かなり不思議なクエリなんですけど・・・。縦方向に職業、横方向に所属名が並んでますね。
こういうの、クロス集計クエリっていいます。

ふつうの集計クエリと違って、2方向に値を取るんですね。
なので、基になるクエリまたはテーブルの構造も、縦方向・横方向に取るフィールドがなくちゃイケマセン。
とりあえず今日は、どんなクエリなのかざっと見ていただいて、皆さんの業務でこんな感じのクエリ、どっかで活躍しないもんかな・・・と、身近なモノと結びつけて考えてみてくださいね。



ひとつ・・・ご注意なんですけど、これ、ほんとにとっても特殊なクエリなんです。
どこが特殊かというと・・・「さくら組」「すみれ組」「ゆり組」って、クエリの中でまるで「フィールド名」のように扱われてますけど、基のテーブルにはこんなフィールド名、ないですよね。つまり、このクエリを開いたとき(実行したとき・・・かな)に、初めて作成されるフィールドなわけです。

クエリのデータシートビューで確認するだけならなんの問題もありません。
でも、このクエリを基に、フォームとかレポートをこしらえるとなると・・・。

フォームもレポートも、各テキストボックス等々の「コントロールソース」というところに、フィールド名を指定してますよね。で、名前で結びつきあいます。

だから・・・。
来月になってもし、「さくら組」の人がだーれも売り上げなかったとしたら・・・。
このクエリ開いたとき、「さくら組」の列はなくなっちゃってるんです。

クエリですからね。もとのテーブルにレコードが存在しないのなら、出ません。

そうなると、レポートの中の「さくら組」のテキストボックスは、中に表示する値を見失うわけです。

逆に、新しく「バラ組」なんて所属ができたとしても・・・。
このレポートには自動的には反映されてきません。

縦方向の、職業の部分は特別問題ないですよ。増えようが減ろうが変わろうが。
なので、ひとつのポイントとして、「項目の種類が増えそうなフィールドを縦方向に持ってきて、横方向には、種類の変動が絶対ありえないフィールドを持ってくる」ってことがあげられますね。これが狂うと、レポートやフォームに支障をきたしてしまいます。

Accessは「名前」で関連しあいますからね。。。
これを無視しては、クロス集計クエリを使ったレポートやフォームを作ることはできませんです。

なるべくなら、クエリそのものを開いて(データシートビュー)ご覧になるのがいいんじゃないかなぁと思いますよ。




いかがでしょう。いろいろご紹介してきましたけど・・・。
最後にひとつだけ、クエリを使っての作業の注意点です。

さっきのクロス集計クエリなんですけど・・・。

一番下の方見ていただいて、「新規追加のボタン」、クリックできない状態になってますよね。
それと、いつも一番下に空欄行がひとつ空いていたと思うんですけど、これも見当たらない・・・。

ふつうの集計クエリも同じですね。見ると、やっぱり新規追加のボタンがクリックできない・・・。

集計じゃないふつうのクエリや、トップ値などの場合は、どうやらクリックができるみたいですけど・・・。



クエリというのは、こうやってデータシートビューの形で出せますけど、実体はないんですね。実データは持たない。ここから何か新しいデータを追加したり、数値を書き換えたりした場合、基にしているテーブルに繁栄されることになります。その辺はみなさんオッケーですよね。

クロス集計クエリや集計クエリの中のどっかの値を書き換えたい・・・という場合、結局は基にしているテーブルのどっかを書き換えることになりますよね。
じゃ、どのレコードのどの部分を書き換えることになるんでしょう。

集計してますからねぇ。。。
この、クロス集計クエリで言うところの、武道家のさくら組の10900600円って、いったい、誰の、いつの、伝票何番の売上のことなんでしょう。
基にしているテーブルって、所属名は社員テーブルから、売上の金額は売上明細テーブルから取ってきてますから・・・。

つまり、この「追加ボタン」がクリックできない状態のクエリというのは、「更新・追加のできないクエリ」ということになるんです。
べつに意地悪してるわけじゃないんですよ。今の状態じゃ、大基のテーブルの、どのレコードのどの値を書き換えるべきか、Accessには判断できない、っていう意味なんです。そんなわけで、集計クエリは、どんな作りかたしても、基本的に「更新・追加」はできませんのです。



集計クエリ系じゃなくても、複数のテーブルを結合させているクエリで、結合のしかたがおかしかったり矛盾してたりすると、交信できない状態のクエリになります。
テーブルには、ちゃんと1レコード1レコードを識別できる「主キー」にあたるフィールドがないとね、Accessが用心して慎重になってしまうんですよ。
やっぱり、テーブルの設計って大事です。

「データベースの機能としてどうか」ということじゃなくて、業務の流れの中で、そういうデータのたまり方はおかしくないか???みたいな感じで、テーブル作りにはじっくり時間をかけてくださいね。