| |
クロス集計クエリを使うことになります。
ただ、私は、クロス集計クエリをそれほど使ったことがなく、
またレポートもそれほど得意ではありません。
なので、私にもよくわからないというのが正直なところです。
私にわかる範囲で述べます。
クロス集計クエリのベースとなるクエリですが、
次のフィールドを持つものである必要があると思います。
月
個人番号
種類 （基本給か社会保険かが格納される）
人別種類 （例えば、「121314社会保険」などというデータ。
個人番号と、基本給か社会保険かということを
単純につなげただけのもの）
金額 （基本給額と社会保険料額が格納される）
例示されたクエリからクロス集計クエリのベースとなるクエリを作るとすると、
次のようなＳＱＬ文になります。
SELECT 該当月
,個人番号
,種類
,CStr(個人番号) & "基本給" AS 人別種類
,基本給 AS 金額
FROM [4月]
UNION ALL
SELECT 該当月
,個人番号
,種類
,CStr(個人番号) & "社会保険" AS 人別種類
,社会保険 AS 金額
FROM [4月]
UNION ALL
SELECT 該当月
,個人番号
,種類
,CStr(個人番号) & "基本給" AS 人別種類
,基本給 AS 金額
FROM [5月]
UNION ALL
SELECT 該当月
,個人番号
,種類
,CStr(個人番号) & "社会保険" AS 人別種類
,社会保険 AS 金額
FROM [5月]
・・・・・・・・
ＳＱＬ文はうんざりするほど長いものとなりますね。
ＳＱＬ文の長さには制限があるので、
ひょっとしたらそれにひっかかってしまうかもしれません。
それから、クエリ名が「4月」というのは、よくないですね。
数字で始まるオブジェクト名は御法度です。
無理にユニオンクエリを作るよりも、
「4月」クエリの元になったテーブルがきちんと作られたものであれば、
そのテーブルからクロス集計クエリを作った方がいいです。
きちんと作られているとは、
月別にテーブルを作るなどということは
データベースではやってはいけないことの代表例ですから、
そのようなテーブルではないということです。
部署と氏名は、
個人番号が決まれば、部署も氏名も決まるという性質のものなので、
クロス集計クエリに含ませる必要はありません。
クロス集計クエリを作った後、
そのクロス集計クエリと、部署や氏名が格納されたテーブルとを結合させた
選択クエリを作ることになると思います。
経費の扱いがよくわかりませんね。
人が決まれば、どの経費に該るのかが決まるという性質なのであれば、
経費は部署や氏名と同様に扱えばいいです。
これに対し、人が決まっても、どの経費に該るのかは決まらない、
例えば、山田さんの場合に、
経費がＡＢＣであることもＤＥＦであることもあるということであれば、
上記の「人別種類」フィールドの値を、
個人番号と基本給か社会保険かと経費とをつなげたものとする
（例えば、「121314社会保険ＧＨＩ」）必要が出てきそうです。
クロス集計クエリは、次のようなものとなります
（ただい、経費の扱いについては前者だとします。）。
個人番号 種類 人別種類 4月 5月 6月
123456 基本給 123456基本給 50000 60000 60000
123456 社会保険 123456社会保険 2000 3000 3000
121314 基本給 121314基本給 50000 60000 60000
121314 社会保険 121314社会保険 2000 3000 3000
789101 基本給 789101基本給 60000 80000 80000
789101 社会保険 789101社会保険 3000 4000 4000
このクロス集計クエリと、部署、氏名、経費などの情報をもったテーブルとを
結合させて選択クエリを作り、
この選択クエリをレコードソースとするレポートを作ります。
レポートでは、適宜グループを設定した上で、レイアウトを工夫することになると思います。
|
|
![[未読]](./data/access/image/read_icon.gif){kind=icon}
