不定期連載型特別テーマ
/第１話 背景/第２話 食費をどう扱うか/ 第３話 お買い物はすべてひとつのテーブルに/第４話 交通費、外食費 及び引き落とし/第5話 基本テーブル「お買い物」の作成/第6話 ルックアップテーブルの作成/第7話 入力フォームの新規作成/第8話 「入力お買い物」フォームのデザイン：カレンダーコントロール/ 第9話 「入力お買い物」フォームのデザイン：2連コンボのコンセプト/第10話 日付抽出モジュールの作成/
/ 第11話 「入力お買い物」フォームのデザイン：品名のコンボボックス にQueryDefオブジェクトを /第12話 「入力お買い物」フォームのデザイン：コンボボックスどうしの関連づけ/第13話 お出かけの入力フォーム / 第14話 引き落としの入力フォーム/第15話 日付抽出の準備をする：「お買い物」/第16話 日付抽出の準備をする：「お出かけ」/ 第１７話 いよいよ日付抽出。まず日付を指定するフォーム/ 第18話 日付抽出のSQL文/ 第19話 「入力引き落とし」フォームで、一時的に今月の一覧を見る/
/第20話 お買い物データを分類 /第21話 「引き落とし」を分類2でわける/第22話 データを集計/第23話 ちとやっかいなのが光熱費/第24話 演算フィールドの落とし穴/第25話 泥縄式，日付の表示/第26話 集計したデータをため込む/第27話 食費の細かい分類は？/第28話 戦いすんで/
約１年間、Microsoft Excelで家計簿をつけてきた。構成は、ごく月並みなものである。
月日 品目 分類（食・住・書籍・コンピュータ・光熱・電話・その他・・・） 価格 という表に、買い物をするたびレシートの内容を入力し、引き落としの領収書などとも併せて月別に合計を計算するというものだった。しかし、なんかめんどくさいな、という感じがいつもつきまとった。そこで、いったいなにがめんどくさいのかをよく考えてみると、以下のような点が挙げられた。
1.食品等、定期的に同じものを買っているのに、品名を いちいち入力し直さなければならない。
2.入力項目が多くなると、スクロール操作が大変になってくる。
3.エクセルの抽出操作はいちいちやるとめんどくさいが、それはこれをマクロ化して利用するめんどくささとかなり拮抗する。
4. 同様、計算を行ったり、計算で出たデータを他のセルに持っていって・・・などという操作も。
さらに、もっとこのようなことをしたいという考えもあった。
5.最近どーも食費がかさむような気がするが、どの項目がかさんでいるのか、主食、お肉、野菜、お菓子などもっと細かい分類集計も併用したい。
6.月別の集計を比較したり、推移を見るなど、もっと分析したい。
以上のような観点から、家計簿データベース管理のシステムを抜本的に改革したい・・・と思い始めたわたしは、1999年末、
「家計簿をAccessで作ろう」
と思い立ったのである。
2000年5月23日
最初に、これから作らんとするAccess家計簿において、レシートから入力するものは全て、フィールドを以下のように設定した。
月日 品目 分類１（小分類） 分類２（大分類） 価格 個数
価格*個数の合計額は、のちにクエリーで処理する。
月日の入力は、カレンダーコントロールにより行う。
項目は、いつも買うもののリストをルックアップし、コンボボックスから選択できるようにする（リスト外入力も可）
・・・という感じである。
食費の扱い方についてどう取り組むかを、一番最初に考える必要があった。我が家ははっきり言って、支出のほとんどは食費とコンピューターだからである。あ、あと書籍もあるな・・・が、いずれにしろ後者は毎日の食費ほど細かく多岐にわたるものではない。
食費について、その小分類名と、各小分類毎の頻出（ルックアップ）項目を 以下のように決めた。
小分類 （頻出項目）
主食 （お米、食パン、うどん、ジャム、 マーガリン、コンビニパン、コンビニおにぎり、コンビニランチ）
おみそしる（味噌、わかめ、おとーふ、あぶらげ、生揚げ、松茸お吸い物）
おにく（鶏肉、豚肉、牛肉、挽肉、魚、卵、かまぼこ、ちくわ・・・・）
やさい（たまねぎ、にんじん・・・）
・・・・
という感じである。ジャムやマーガリン及びわかめやおとーふをそれぞれ、主食及びおみそしるのカテゴリに入れているところがちょっと工夫した点である。
2000年9月21日
食費の他は、現在のところ小分類と大分類にわける必要はないと思われるが、 後分類する必要が出てくることを鑑みて、一応両者に同じ値を入れておく。それらは住居費、書籍、コンピュータ、趣味、その他である（やっぱりすごい単純な家計・・・）。
この、分類1と分類2の関係をテーブルにしておく。「分類2」という名前で保存する。
とにかくレシートから入力するものは、すべて「お買い物」というひとつのテーブルにまとめた。この入力フォームを作るのに、今回はちょっと工夫した。それについては後述。
2000年9月21日
他の支出には、交通費と外食費、及び銀行からの引き落としを設定した。
このうち交通費と外食費は、「お出かけ」というテーブルにまとめられる。なぜならこれはほぼ例外なく、土日におでかけしてお昼を外で食べるという行動により発生する支出だからである。 さらにその行き先は電気街のある2,3の場所に、また外食はマクドナルドのダブルチーズバーガーセットかケンタッキーのオリジナルチキンセットにほぼ限定されている。 ゆえに入力フォームではリストから行き先と店名を選択すれば交通費と外食費が自動入力されるようなクエリーを作成する（マジにわかりやすすぎる、うちの家計・・・）
引き落としは、やはりそのいくつかが、同じカテゴリにまとめられる。「電気」「ガス」「水道」は「光熱費」、「NTT」「JPHONE」「OCN」は「通信費」というふうに。・・・すると、「光熱費」「通信費」を分類2（大分類）に、「電気」「NTT」などを「分類1」に相当するクラスに置くとすっきりする。また、これらの引き落とし先（元？）はいつものことなので、やはり入力の際にはコンボボックスから選択すべし。だが、基本的な構造が「お買い物」とは違うので、テーブルや入力フォームは別にするべし。
このようにして、基本的な入力法のコンセプトができあがった。
2000年9月21日
とうことで、いよいよ、実際に作っていくことにした。
まず何がなくともAccessを立ち上げ、新規データベースを登録する。余計なことだがデータベース名はnoniworld.mdbにした。これはのに子という主婦の世界なんて世界なんて結局１個のデータベースファイルですべて語り尽くされてしまうのよォ〜という自嘲をこめた命名である。
最初に、「お買い物」というテーブルを新規作成し、デザインモードでフィールド名、データタイプを決めた。(参考図面1)
月日（日付/時刻型）、品目（テキスト型）分類1（テキスト型）、分類2（テキスト型）、価格（通貨型）、個数（数値型）
「価格」は、書式を「通貨」に設定。規定値は、なしにした。規定値を0にしておくと、いちいち入力の際この0を消して入力しなければならないことによる。一方、「個数」の規定値は1にした。
2000年9月21日
次に、「お買い物」入力フォームに使う頻出品目用のテーブルを作った。 「頻出品目」と「分類1」の関係を表すテーブルである。名前を「品目一覧」とした。（参考図面2）
2000年9月21日
入力フォームの新規作成にあたっては、「デザインビュー」でまっさらのフォームを立ち上 げるか、「フォームウィザード」を起動するか、「オートフォーム」で一気に自動作成するかを選択させられる。やはり「フォームウィザード」を使うのが一番便利のようだ。いきなりまっさらのフォームを眼前に突きつけられるその茫漠感というか寂寥感は、これからめんどくさくてめんどくさくてしょうがねえ作業をしていこうという者には精神衛生上よろしくない気がしたし、「オートフォーム」ではできたフォームにわたしにことわりもなく、ダサダサな雲かなんかの壁紙が貼り付けられ、初めて何の知識もなしにAccess97でこれをやったときこのダサ紙をひっぺがす方法がわからなくて非常に苦労した思い出がある。
まず「お買い物」の入力フォームを作るので、「基になるテーブル/クエリーの選択」を「お買い物」にする。次に進むと、フォームに含めるフィールドを選択させられるので、これは全部選択する。次に表示形式として「単票形式」を選ぶ。その次がスタイル、つまり壁紙の種類だが、Access97でわたしをかなり不快な気分にさせた「雲」の壁紙はやはり他でも不評だったのか、Access2000では削除されている。「世界地図」というのがわりといい感じなのでこれにした。もっとも「標準（MSの大好きな言葉のようだ）」を選べば、あとで色などを変えられる。もっぱら趣味の問題だ。最後にフォームの名前を「入力お買い物」にして、作成は完了だ。そしてあとはデザインに奮闘することになる。
2000年9月21日
まず、「月日 」を、カレンダーから入力できるようにする。これは、ツールボックスの「コントロール」から「カレンダーコントロール」をフォーム上に貼り付ける。このカレンダーを右クリックし、「プロパティ」で「名前」を「お買い物カレンダー」にする。これはこのデータベース上で他にもカレンダーコントロールを使うので区別したかったからだ。 次にプロパティウィンドウを閉じもう一度右クリックし、「イベントのビルド」 を選択する。ていうかとにかく「コード」の表示をさせるのだ。そして、以下の二つのサブプロシージャを作る。
Private Sub Form_Load()
Me.お買い物カレンダー.Today
End Sub
及び、
Private Sub お買い物カレンダー_Click()
Me.月日 = Me.お買い物カレンダー.Value
End Sub
どこの本にも書いてあることでは、ある。
2000年9月21日
2000年9月21日
それから、「分類１」 のコンボボックスを作る。フォームウィザードでは「分類1」のコントロールは「テキストボックス」になっている。右クリックで「コントロールの種類の変更」から「コンボボックス」を選ぶ。するとこいつのプロパティ ウィンドウに「値集合ソース」という設定が現れ、入力欄をつつくと選択肢が現れてくれるのでその中からテーブル「分類2」 を指定する。閉じようとすると自動的にクエリビルダが立ち上がるから、「分類2」テーブルの二つのフィールドのうち「分類1」のほうをリストとして使うことをさらに指定できる。
2000年9月21日
「品名」のコンボボックスの値集合ソースには、「品目一覧」から任意の「分類1」の値で抽出したクエリを充てる。
というのが、 この入力フォームで一番苦労した点だった。 つまり、抽出条件が変数になるのだ。「分類1」のコンボボックスから任意の値を選ぶとそれが変数に格納され、「品目一覧」の抽出条件になる。「変数を抽出条件に用いるクエリ」の作り方には、Accessヘルプが非常に役に立った。ただしイルカに教えてもらったわけではない。2000のイルカ野郎は、97の平面イルカ野郎よりもっとバカになったかもしれない。「変数を抽出条件に用いるクエリの作り方は？」などと聞いても「ケケケケ、ケケケケ（質問の意味がわかりません」などと平気でぬかしてくる。こいつには「クエリ」と聞いてやるのが関の山だ。そうするといろんなオプションを出してくるので、そこからヘルプサーフィンをしていくのだ。 で、目的のものが見つかりさえすれば、それはすごく使える。
変数を抽出条件に用いるクエリを作るには、dbfオブジェクトの、CreateQueryDefというメソッドによって作成されるQueryDefオブジェクトをを使う。これは普通の環境ではダメで、コードウィンドウを開き、メニューの「ツール」「参照設定」から「Microsoft
DAO Object Library」を選択しておいてやらなければならない。
ここでは、もうこのステートメントを完成させるための浪花節はやめて、一気に結果を書く。まず、モジュールを新規作成して、ここに
Function 品目で分類しよう( Cls1)
と書く。そうしてくだんのクエリ作成のステートメントを書いていく。このやり方は、基本的には
Dim dbs As Database, qdf As QueryDef, strSQL As String
Set dbs = CurrentDb
strSQL = "・・・・”
Set qdf = dbs.CreateQueryDef("分類毎品目", strSQL)
が、すべてである。今のデータベースに、これから作っていくSQL文を使ったクエリを"分類毎品目"という名前で作成し、これをqdfという名前のオブジェクトとして表すとゆーのだ。
今回はクエリ作成だけが目的なので、ここでできたqdfというオブジェクトそのものをどうこうすることはしなかった。
さて、このSQL文を作るのだ。これはまずグラフィカルにクエリを作ってから、SQLビューで見るのが王道である。それには、具体的に分類1を「おにく」で抽出するクエリを作り、ちゃんと機能していることを確かめてからSQLをのぞく。
SELECT 品目一覧.品目 FROM 品目一覧 WHERE 品目一覧.分類1="おにく";
だから"おにく"の部分をCls1という変数にしてやればいい。 ただし、注意すべき点は、SQL文での""は、VB上での文字列を囲むクォーテーションマークと区別を付けなければならない。ということだ。つまりアスキーコードを使うのだ。
SELECT 品目一覧.品目 FROM 品目一覧 WHERE 品目一覧.分類1 = "Cls1";
という文字列を、strSQLという変数に格納するには、ゆえに
strSQL = "SELECT 品目一覧.品目 FROM 品目一覧 WHERE 品目一覧.分類1" & "=" & Chr$(34) & Cls1 & Chr$(34) & ";"
というわけ。
最後にEnd Functionと書くが、たぶんこのへんはVBAがよきにはからってくれる。
ところで，モジュールの名前とFunctionの名前が重複すると，Access97では文句をつけられた。2000ではどうかわからないが念のためちがくしてある。
2000年9月21日
第12話 「入力お買い物」フォームのデザイン：コンボボックスどうしの関連づけ
ここまで作ったら、フォーム「入力お買い物」のコードウィンドウにうつり、以下のプロシージャを書く。
Private Sub 分類1_Change()
Dim Cls1 As String
Cls1 = ""
Cls1 = Forms!入力お買い物!分類1.Value
Call 品目で分類しよう(Cls1)
End Sub
コンボボックスから「分類1」を選ぶと、その選んだ値がCls1に入り、「品目で分類しよう」Functionに引き渡される。Cls1はその都度変えられるので、念のため最初に初期化するようにした。
こうしておいて、「品目」のほうには、
Private Sub 品目_Click()
Forms!入力お買い物!品目.RowSource = "分類毎品目"
End Sub
これはコードで書く「値集合ソース」の指定である。プロパティウィンドウで"分類毎品目"を指定しても、なーぜーかうまくいかない。プロパティウィンドウの設定は気持ち悪いのでまっさらにしておいた。
あと、ちょっとめんどくさいのは、このFunctionで1度作ったクエリは、どうも上書きできないようだ。2回目にトライすると「オブジェクト”分類毎品目"はすでに存在します」とエラーメッセージが出る。一時的なクエリの作り方とかなんかワザはあるらしいのだが、それよかクエリを作るたびに前のクエリを消した方が簡単と考えた。qdfというオブジェクトも頻繁に変えられるので初期化したほうがいいかなというのもあり、
Set qdf = Nothing
DoCmd.Close acQuery, "分類毎品目"
DoCmd.DeleteObject acQuery, "分類毎品目"
などのおそうじステートメントを作り、クエリ作成ファンクションの一番最初に置くことにした。
これで、どうやら目的が達成された！守るべきルールは、まず「分類1」を選んでから、「品目」のコンボを開けることだ。これを守らないと混乱するようだが、そのときは一度フォームを閉じればまた復活する。クエリを消して作って実行して、というのは結構時間かかる処理かと思ったが、ストレスを感じるほどでは全然ない。すげえ便利だ！！！
2000年9月21日
「お買い物」テーブルの入力環境さえ整えれば、あとは大したことない。「お出かけ」の入力のためには、「月日」「場所」「おひる」からなるテーブル「お出かけ」を作り、別に「交通費」と「外食費」というテーブルを作る。前者はいつも行くお出かけ場所と、そこへの交通費。後者はおひるの種類と、お値段を示すテーブルである。第4話に示した通り、これらはもう決まっている。別の場所で別のものを食った場合は出費は「その他」に入れてしまえ！・・・とこのくらいの度胸がなきゃ・・・って何なんだ・・・。とにかく、「お出かけ」入力フォームの「場所」はテーブル「交通費」の「場所」、同じく「おひる」はテーブル「外食費」の「おひる」を値集合ソースとする、つまりコンボボックスを開いて選べるようにする。日付はカレンダーコントロール（「お出かけカレンダー」と命名）から入力などのデザインを作った。
2000年9月22日
引き落としの入力のためには、まず「引き落とし」テーブルを作る。これは「月日」「項目」「請求額」 からなるものだ。別に、「引き落とし分類」をいうテーブルを作り、「項目」「分類2」のフィールドを用意する。「項目」には「電気」「ガス」「NTT」・・・、「分類2」にはそれぞれの項目が該当する「光熱費」「通信費」・・・を入れていく。「家賃」は「家賃」である。それだけで高いもん。
「入力引き落とし」フォームはテーブル「引き落とし」をもとに作成し、「月日」はカレンダーコントロールから入れるが、月一回なので全部もう必ずついたち付けで入れるようにする。カレンダーコントロールがもったいないという感じもするが、まあいい。「項目」はコンボボックスにして、値集合ソースをテーブル「引き落とし分類」のフィールド「項目」にする。
ただし、引き落とし項目の入力に際しては、ちとこれだけでは不便だ。というのは、とにかくレシートの内容を片っ端から入れていく「お買い物」と違って、「引き落とし」は「今月の引き落としは、全部請求書来たかな？」というのを確かめたいからだ。そこで、フォームにコマンドボタンを割り付け、これを押すと今月の引き落とし一覧がみれるようにしたい。
コマンドボタンの扱いはウィザードに従って行けば簡単だが、ここでは、これから作る「今月分の引き落としを抽出して並べる」Functionモジュールの実行を割り付けたいので、今はボタンだけにしておく。そしてボタンには「今月の一覧を見る」
とラベルを付けておく。 続きは第19話。
2000年9月22日
これで、日々の支出の入力はとにかくできるようになった。そこでいよいよ月の集計を求めるシステムを作っていくのだが、その前に、上の3つのテーブルを集計用に整えるクエリを作らなければならない。
まず、「お買い物」テーブルには「価格」と「個数」しか入力していない。日付抽出をかます前に、出費つまり「価格*個数」も計算する必要がある。加えて、「分類1」しか入ってないので、それに該当する「分類2」もフィールドに加えたい。
クエリを新規作成する。テーブルとしては「お買い物」と「分類2」を二つ読み込む。そして、まず、テーブル「お買い物」の「分類1
」にカーソルを充てる。するとなんかヘンなカーソル記号になるので、そいつをドラッグして、テーブル「分類2」のフィールド「分類1」に落とす。これで、二つのテーブルにリレーションが発生する。
そうして、テーブル「お買い物」の「月日」「品目」「分類1」、テーブル「分類2」の「分類2」を選択し、あと最後にひとつ
出費: [価格]*[個数]
というフィールドを作る。ここで、この演算フィールドの「テーブル」の欄にはなにも指定しないように注意する。（参考図面5)
。
実行の結果は、「お買い物」のテーブル全部に、分類2が加わり、あとそれぞれの合計金額（２つ以上買った場合違う）が並べて表示されるだけのごく単純なものだ。
2000年9月22日
次は、お出かけ。入力してるのは「月日」「場所」「おひる」だけなので、これに、相当する「交通費」と「外食費」 を併せて表示させたい。もっとも、ここですでに「交通費」「外食費」関係を分けてもいいんだけど・・・
クエリを新規作成し、「お出かけ」「交通費」「外食費」の各テーブルを表示。
次に「お出かけ」のフィールド「場所」から「交通費」のフィールド「場所」へ、第15話でやったようにドラッグドロップで関連をつける。同様、「おでかけ」の「おひる」から「外食費」の「おひる」へ。
で、「お出かけ」の「月日」、「場所」、交通費の「交通費」・・・と選択していけば、その日のお出かけにかかった交通費と外食費が一緒に見れる結果となる。クエリの名前を「お出かけ支出」にした。（参考図面6）
2000年9月22日
さていよいよ日付っていうか月で抽出する。「今月分の集計ゴー」というフォームを作ることにした（参考図面7）。
元になるテーブルは必要ないが，フォーム作成はテーブルないとできないみたいなので空のテーブルを作ってdummyとかいう名前にする。これを元にフォームを作るが，ウィザードなしで作ることにする。
デザインビューで，ツールボックスからテキストボックスを二つ持ってきて，そこに年と月を入力することにする。前者にstrYear, 後者にstrMonthとオブジェクト名をつける。ボックスstrYearは，規定値を2000にしておく。来年には2001に変える。
フォーム上にコマンドボタンを配置し，このボタンについてコードウィンドウで，以下のように，年と月の値を変数に入れるように指定する。
Private Sub GoButton_Click()
ThisYear = Me.strYear.Value
ThisMonth = Me.strMonth.Value
LastMonth = ThisMonth - 1
If LastMonth = 0 Then
LastMonth = 12
End If
If文は，上のステートメントでは1月の集計の時おかしくなってしまうのに気がついてあわてて付け足したものである。だが，まだEnd Subにはいかない。これがある。
Call 今月分のお買い物(ThisYear, ThisMonth, LastMonth)
Call 今月分のお出かけ(ThisYear, ThisMonth, LastMonth)
Call 今月分の引き落とし2(ThisYear, ThisMonth)
End Sub
指定した年と月に従って，日付で抽出するクエリーを作るFunctionを呼んでくるのだ。これらのFunctionは第11話でやったとおりだが，SQL文が違う。それについては次。
2000年9月22日
いろいろな定義文のところは，第11話と同じである。SQL文は，
Function 今月分のお買い物(ThisYear, ThisMonth, LastMonth)では
strSQL = "SELECT お買い物完成.月日, お買い物完成.品目,お買い物完成.分類１, お買い物完成.分類2, お買い物完成.出費 FROM お買い物完成 WHERE (お買い物完成.月日) " & "Between #0" & LastMonth & "/25/" & ThisYear & "# And #" & ThisMonth & "/24/" & ThisYear & "#;"
むちゃくちゃ長いー。改行コード入れたいんだけどVBAの改行記号ってなんなのかわかーんなーい。このくそ長いSQL文はつまりグラフィカルにクエリを作ってテキトーな値を入れて実行し，成功したのを確かめてからSQLビューでぱくってくる。そして，
Set qdf = dbs.CreateQueryDef("今月分のお買い物", strSQL)
と「今月分のお買い物」というクエリを作るわけ。
全く同様に「今月分のお出かけ」クエリも作る。「今月分の引き落とし」は，その月のついたちだけを持ってくればいいので，SQL文は
strSQL = "SELECT 引き落とし.年と月, 引き落とし.分類1, 引き落とし.出費 FROM 引き落とし WHERE (引き落とし.年と月)=#" & ThisMonth & "/01/" & ThisYear & "#;"
となる。
これで、年と月を指定してGo!ボタンを押すと、好きな月の１ヶ月分だけのレコードが得られることになった。
2000年9月22日
第14話で、一時的に今月の一覧を見るために、第18話で作った「今月分の引き落とし」Functionをちょっと変えて「今月分の引き落とし2」Functionを作る。
Function 今月分の引き落とし2(ThisMonth2)
strSQL = "SELECT 引き落とし.年と月, 引き落とし.分類1, 引き落とし.出費 FROM 引き落とし WHERE (引き落とし.年と月)"
& "= #" & ThisMonth2 & "# ;"
Set qdf = dbs.CreateQueryDef("引き落とし一覧", strSQL)
作るクエリも、一応別のものにしよう。で、実際開いて見たいので
DoCmd.OpenQuery ("引き落とし一覧")
も、付け足す。
さて、こっちの引数は一つでいい。第18話の場合は年と月を別々に設定するが、こっちはフォームに入力した月日をそのまま用いればよい。なぜって「引き落とし」だけを見る場合は、その年と月のついたちだけを指定すればよいから。ゆえに「入力引き落とし」フォームで「今月の一覧を見る」ボタンをクリックしたときに何が起こればよいか。
Private Sub 今月の一覧を見るClick()
ThisMonth2 = Me.月日
Call 今月分の引き落とし(ThisMonth2)
End Sub
これで、引き落としのデータを入力しながら、今月はまだどこからの請求書が来てないとか、検討できるようになた。
2000年9月22日
では、お給料日も近くなってきたので、まずとにかく今月の集計を出せるようにしなければ。「お買い物」データを、大分類つまり「食費」「住居費（生活雑貨という名のほうが適当だったがもう遅い）「コンピュータ」「趣味」「書籍」
「その他」・・・あと，「灯油」だけは，分類2は「光熱費」にあたり，あとから引き落とし項目の光熱費関係と集計することに注意する。
これは、馬鹿正直にクエリを新規作成し，クエリ「今月分のお買い物」を表示させ，すべてのフィールドを選択して，「分類2」の抽出条件を「食費」にするだけである。(参考図面8）
「趣味」以下ほかの分類2についても同様。これらには「分類2食費」などの名前をつけておく。
あと，食費をあとで細かく検討するために（今月はお菓子を食い過ぎたとかビールを飲みすぎたとか），これらを分類1で分けるクエリも作っておく。まあ，抽出条件を片っ端から変えて，サルのように作っていけばよい。(参考図面9）
2000年9月25日
どうやら、日付抽出の前にやるべきだった操作をこのへんで泥縄式にやったらしい。つまり、「分類2」を付け加えることである。新規クエリにクエリ「今月分の引き落とし」とテーブル「引き落とし分類」を読み込み、「今月分の引き落とし」の「項目」から「引き落とし分類」の「項目」に関連を与える。そして、「今月分の引き落とし」の「月日」、「項目」 、「引き落とし分類」の「分類2」、「今月分の引き落とし」の「請求額」を順に選択していくだけだ（参考図面10）。クエリ名は 「引き落としを分類2でわける」・・・だんだんいい加減になってきたらしい・・・
こうして初めて第20話と同様「分類2光熱費(灯油を除く）」「分類2通信費」などのクエリができる。あと家賃は家賃しかないが「一応分類家賃」でひとつだけ抽出しておく。
2000年9月25日
つぎは 怒濤の集計である。 まず，「食費」。クエリを新規作成，クエリ「分類2食費」 を呼び込み，フィールド「出費」を選択する。そして，デフォルトでは隠れている「集計」欄を引っぱり出す。これはツールバーのSum記号のボタンをクリックするか，今いじっている入力欄を右クリックして「集計」と書いてあるやつをクリックすればでてくる。入力欄では「集計」のアクションを選ぶようになっているので「合計」を選ぶ（参考図面11）。
クエリを実行してちゃんと集計が現れることを確認。
注意すべきは，この集計クエリ，一度閉じてまた開くとデザインが変わっている。さっき「出費」を選んだところが，「出費の合計:出費」という間抜けなフィールド名になっているのだ。
わたしの入力法では，スーパーでレシートをもらう「食費」及び「住居費」は，個々の商品は税抜きで記載されているので，この二つの集計値には消費税をかけなければならない。他はほとんど１つか２つの買い物でレシートをもらっているので
，あまり消費税を気にしないか，そのへんを適当に個々の商品に振り分けて適当に入力している（いい加減だ・・・）。
ゆえに，ただ足しあわせただけのクエリは「集計食費（税抜き）」という名前にして，これを元にしてさらにクエリを作る。ここではもとになるフィールドは選択しない。そのかわり新しいフィールドとして
食費: Int([出費の合計]*1.05)+1
という演算フィールドを作る（参考図面12）。これは，小数点以下切り上げってことにした。決して甘く見積もられることがないという。ストイックだ。ていうかめんどくせえ。
これで初めて「集計食費」というクエリが完成する。住居費も同じ。
他のお買い物データは，ただそのまま集計すればよい・・・が，ここで問題がひとつ。 参考図面11に示したように，どの項目でもすべてクエリの結果のフィールド名は「出費の合計」になってしまう。食費，住居費の場合はもうひとつ消費税計算クエリをかますときにフィールド名を指定したが，他の場合はそれをしないので，いったいなんの出費の合計なのかあとで見分けがつかなくなって困る。
こうする。集計クエリを作ったら，いったんそれを実行して成功を確かめ，閉じる。そして開く。そうしてフィールド名を変えちゃうのだ。
「出費の合計:出費」を，「書籍:出費」 に，無理矢理書き換えちゃう。だったら最初からウィザードとかで「新しいフィールド名を定義してください」とか聞いて来いよ・・・と思うのはわたしだけか！
他の項目も同様に集計し，「出費の合計」とでてくるフィールド名をわかりやすい名前に直しておく。「家賃」はレコードが1個しかないが，やっぱり集計ってことにしておこう。ただ，ちとやっかいなのが光熱費・・・
2000年9月25日
光熱費は「分類2光熱費(灯油を除く）」から作るクエリ「集計光熱費(灯油を除く）」と，「分類2光熱費（灯油）」から作る「集計光熱費（灯油）」を，さらに足し合わせなければならない。クエリを新規作成して，
「集計光熱費(灯油を除く）」と「集計光熱費(灯油）」を表示させ，両者のフィールド「光熱費合計」「灯油合計」をそれぞれ選択する。まず，これで保存。「光熱費統合」という名前のクエリにする。
次に，この「光熱費統合」からクエリを新規作成。
光熱費:[光熱費合計]+[灯油合計]
という演算フィールドを作る。これでよーおーやーく，その月の光熱費の合計がでるのだ。(参考図面13）
フィールドの選択と，それぞれのフィールドの集計を一緒にできないかとお考えの向きもあろうが・・・どうも，できなさそうだ。つまり，別々のテーブルまたはクエリのフィールド同士を足しあわせる演算フィールドは作れないっていうかヘンになる，みたいなのである。その詳細は，いよいよ最終合計を求めようというときに，とんでもないデザスターとなって現れたので，そこで詳しく説明しようと思います。
2000年9月25日
ていうか，クエリの演算フィールドは使いにくい！入力欄は何度もいうがせめーし（「ズーム」を指定しないと全体が見られない），「式ビルダ」は使えそうで記号がたりないし，結局ぽちぽち全角と半角を切り替え切り替え入力していくしかない・・・全部英字だったら少しは楽なんでしょうが・・・
その演算フィールドですが，なにがデザスターだったか？・・・現在，各項目ごとの集計が出そろった状態だ。「集計食費」「集計住居費」・・・「集計交通費」「集計外食費」・・・「集計通信費」「最終集計光熱費」
最後に，これらを全部表示し，かつ合計も表示させようではないか！
というわけで，最初やったのです。新規にクエリを作成し，これらの11だかあるクエリを全部表示し，それらの各フィールドである「食費」「住居費」・・・「交通費」「外食費」・・・「通信費」「光熱費」を選択する。
そして，最後に新しいフィールド
総計: [食費]+[住居費]+...[交通費]+[外食費]+...[通信費]+[光熱費]
と，苦労して入力する。この入力に，王道はないぞ！っていうか王道作れよアクセス！
このようにクエリを作り(参考図面14）実行すると・・・・
悪くすると，そのまま死ぬ。運が良ければ，もーのーすーごーく時間がかかったのち，天文学的な金額を叩き出してくれる。光熱費350,000円とか。風呂屋でも経営してるってか！(職業差別の意図はありません）・・・
正解は，光熱費の小計を出したとおりです。まず，11やそこらのクエリを全部ひとつのクエリに集める選択クエリをつくるのです。そうしておいて，「ひとつのクエリの中のフィールド同士の加算」として，上のなが〜い演算式をかます。いくら形式が同じでも，異なるテーブルやクエリのフィールドどうしの演算は，かのグラフィカルなインターフェイスからは，作れないようなんです。なーんでなんでしょーねー？・・・
2000年9月25日
そうそう。大変なことを忘れていた（でもない）。これでは，何年何月の集計かがわからない！・・・てきとーに，日付を持ってこなければ。そうか，「今月分の引き落とし」はみんな月のついたちの日付だった。中でも，「家賃」はデータが1個，軽いクエリだ。そこで，「日付だけ借ります」というクエリを作った。「今月分の引き落とし」から家賃だけを抽出した「一応分類家賃」というクエリがある。こいつを元にして。「年と月」を選択し。「集計」を表示させて「グループ化」を指定する(参考図面15）。これで完成。さっきの，11やそこらのクエリを全部ひとつに集める選択クエリ「最終総計表示（どんどん名前が仰々しくなっていく）」の筆頭に，このクエリの集計値をねじ込んでやる！演算には全く影響ないので，問題なし。
とにかくこれで，とうとう月の集計が完成した！その名もクエリ「最終究極合計」！結果は，前のバージョンを用いた結果より総計が3円違ってた。これは消費税の換算のとき，前のバージョンでは切り捨てたが今度のバージョンではストイックに切り上げにしたからと思われる。あとはフォームを作って，見やすくすればいい。お疲れさまでした・・・
2000年9月25日
しかし、ここまでで最終的に得られる値は、今入力した日付で抽出した分だけである。もう一度抽出フォームを開いて日付を変えれば、せっかくやって今の結果は上書きされてしまう。こんなときに便利なのが，「追加クエリ」である。
これは，クエリの結果を，指定したテーブルにレコードとして追加していけるクエリなのだ。作り方はあまりにも簡単で指示に従っていけばいいだけ。デザインビューで見てもらえば，全ては明らかでしょう。（参考図面16）
ただし，このクエリを作る前に，こいつをため込むテーブルをあらかじめ作っておくことが必要だ。テーブルデータの形式や書式は「最終究極合計」に合わせてデザインするが，フィールド名自体や順番は異なっても，どのフィールドをため込み先のテーブルのどのフィールドに送り込むかを指定できる。
クエリのデザインビューにはどのテーブルにため込むかの指定は一見してわからないが，追加クエリを作るときのウィザードできいてくる。
ひとつ注意すべきは，この追加クエリを用もないのに開かないことである。現在の状態の「最終究極合計」クエリの結果が不必要にため込まれてしまうからだ。まあ，うっかりクリックしちゃっても，イルカがちゃんとでてきて「あんた，ホントに追加したいの？」と確認はしてくれる。こういうときは，こいつも役に立つようだ。
2000年9月25日
食費を「おにく」だの「やさい」だの細かく分類した結果の処理については，これまでと全く同様だ。それぞれについて集計を出し，ひとつのクエリにまとめる。こちらは，消費税の換算はしなかった。食費の絶対集計値はでてるんだし，こっちはあくまで各分類の集計値の比較論でいい。 集計結果は，同様追加クエリでため込む。これからグラフなどを作らなければならない・・・
2000年9月25日
これで一応，家計簿入力と月の集計システムができあがった。これから先，もっと見やすく入力しやすく，また集計値を分析するなどというシステムを開発していかなければならない。しかしなー。思い立って，Access97で作り始めたのが99年の11月で，少し改良したのが2000年1月。このVer.2にかかった時間が1ヶ月くらいだった。それで今度Access2000に乗り換えるにあたりずいぶん改良したが，これは1週間でまとまった。ヒマな主婦じゃないとこんなに時間と労力はかけられないだろうな・・・
だが，こうやって一度苦労すると，完成したあとが超ラクだ!実は，本日は集計日だったんだけど，このウェブを作る前に5分で集計を終えた。 毎日のレシート整理も，10分とかからない。この前テレビで「どうしても3日坊主になってしまう家計簿，でもレシートをスクラップブックに貼るだけでもずいぶん家計が把握できるものです」なんてやってたけど，この集計システムがあれば・・・これで3日坊主になるようなら，人間やめたほうがいいな！ていうか，これ作るのに結局1年弱かかってるんだって！
しかし，別の結論も得られている。毎日家計簿をつけ，毎月集計をしても，出費が減るとは限らないぞ。それに，こいつを完成するまでに購入したハードやソフトの費用を考えると・・・いや，いいす。
2000年9月25日