<HOME　　<お願い事項　　 <Access2002 TOP　　　<Access97 TOP　　　<サイト内検索
MS-Access2000超入門部屋--祝日祭日土日を識別させるために
1　2　3

Format関数で曜日を出すことは可能です。
でも、祝祭日は、できません。そんな関数はありませんです。
っていうか、祝祭日って、日本だけの祝祭日のことですよね。それに、最近になってハッピーマンデーとかいって、毎年変動するじゃありませんか。
こんなの、コンピュータには対応できませんよ。

そしたら、自分たちで仕組み作るしかないでしょ。

今回のように、「曜日や祝祭日などによって、時給が異なる」みたいな感じの考え方の場合は、別にひとつテーブルを作成した方がよいかもしれないですね。
こんな感じの、1年365日分・・・じゃなくてもいいんですけど、「1月1日は祝日、1月2日は会社が休日、1月4日は出勤日」とか、それぞれ自由に設定できるようなテーブルをひとつ設けてみましょう。

フィールド名はなんでもいいんですけど、わたしは［分類］という名前の、数値型のフィールドにしてみました。
ここに　0　と入ってる日は出勤日、　1　と入ってる日は土日または会社の休日、2　と入ってる日は一般的な祝日・・・・というように、一桁の数字を入れていきます。こいつは手作業ですね。って、これはあたりまえですね。先にお話したように、ハッピーマンデーなんてもんを毎年自動的に判断してくれる関数なんか、ありませんし。それに、こういうテーブルをひとつ設けておけば、祝祭日以外のことにもいろいろ活用できるんじゃないかと思います。

で、実際、0のときは時給がいくらなのか、1っていうのはどういう意味合いの日なのか、ということを、別のテーブルに入れておきます。

準備が整ったら、これらのテーブルをもとにクエリを作ります。
さっき作ったクエリがまだ残ってるのであれば、それつかっていただいてもいいですよ。ツールバーの「テーブルの表示」ボタンをクリックすれば、後からテーブルを追加することができると思いますので、まずは［稼働日テーブル］の方を追加してみましょうか。

ふたつのテーブルは、［作業日］［稼働日］で結ばれます。
［テーブルA］の方の［作業日］が、休日なのか祝日なのか出勤日なのか知るために、［稼働日テーブル］を作ったんですから、［テーブルA］の［作業日］は、［稼働日テーブル］の［稼働日］に当たるわけです。
こういうのが、リレーションシップ、っていうんですよ。リレーションシップは設定とか機能のことではありません。業務の内容やデータの内容から見て、複数の情報のかたまり同士がどうやって結びつくべきなのか、を、わたしたちが考えることを、リレーションシップというのです。考え方のことです。これを理解しないと、意味のないフィールド同士で適当に結びつけたクエリとかになっちゃいますよ。

さて・・・このクエリ、データシートビューで開いてみたんですが・・・。

まあ、曜日と見比べてみても、とりあえず正しく祝祭日等々見てくれているみたいですが、なんか変じゃありません？
わたしのは、新規入力行がないし、新規入力のためのボタンもクリックできない状態になってます。
そう、いわゆる「更新できないクエリ」ですね。更新クエリと更新できないクエリはぜんぜん意味違いますよ。まさかそんな取り違えはなさってないですよね？？？

このページをご覧いただいてる方は、どうして更新できないクエリになっちゃってるのか、多分理解なさってると思います。
大丈夫ですよね？

テーブル同士の結びつきを、単に机上の学問として捉えようとすると、とても危険です。
データベースはあくまでもわたしたちの身の回りの情報を管理するための仕組みであって、学問ではありません。

この管理テーブルの役割をもう一度考えてみてください。
これは、1月1日が祝日かどうか、1月2日は出勤日なのか・・・ということを記しておくためのテーブルです。
［テーブルA］は、このテーブルを参照して、［テーブルA］に入力されている各レコードの［作業日］が、祝日なのか休日なのかを判断します。

そうすると、ひとつの［稼働日］にひとつの［分類］があるわけですよね。
このテーブルの中に、2001/01/01という日は、1回だけ出てくればよいのです。

もし、うっかりこんなふうに1月1日のレコードを2件入力しちゃってたとしたら、どうなるでしょう？

カエルさんが、1月1日に休日出勤してきました。がんばりやさんです。
テーブルには、こんな感じで1件分、1月1日に4時間働いたことがわかるようなデータが入りました。

このテーブルをもとに、1月1日は、祝日扱いだったかしら？ということで、［稼働日テーブル］と結びつけた先ほどのクエリを開いてみると・・・。

カエルさんの1月1日の4時間の労働が2件、でてきます。
・・・なんでだか、わかりますよね？
［稼働日テーブル］に、1月1日のレコードが2件入ってるからです。

カエルさん、お給金2倍です。バンザーイ。
ああーーーーでもこんなことが起っては、誰にいくらお給料を払っていいのか、正しい結果が出ません。意味ない。

どうしてこんなことになっちゃうのか？？？
結論から言うと［稼働日テーブル］の［稼働日］フィールドを主キーにしてないから、こんなことになっちゃうんですけど、ここで、「主キー」という言葉で覚えようとすると、多分なかなか理解が深まらないのではないかと思います。
［稼働日テーブル］に1月1日は2回いらない。なぜ要らないのか？？？このテーブルの目的を理解しなくては語れないですよね。

［稼働日テーブル］は、［テーブルA］にレコードを入力するときに、あるいは表示するときに「参照」するテーブルです。
［作業日］が祝日かどうかを参照するテーブルです。
ここでテーブル同士のつながりをすぐに考えてはいけません。皆さんが、電話でどこかのお店に品物の値段を問い合わせてる様子を思い描いてください。

　皆さん：「カタログに載ってるA001っていう製品の値段を知りたいんですけど」
　店　員：「はい、A001ですと、500円と580円となっております。」
　皆さん：「500円と580円？どっちなんですか？」
　店　員：「ですから、500円と580円です」
　皆さん：「500円なんですか？」
　店　員：「はい。それと、580円です」
　皆さん：「んじゃ、A001をひとつ買ったとしたら、いくら支払えばいいんですか？」
　店　員：「ですから、500円と、580円です」
　皆さん：「500円＋580円ってことですか？1080円？」
　店　員：「いいえ、違います。何度も申しますように500円と580円です。1080円ではありません」
　皆さん：「だーかーらー、いくらなんだって聞いてるんですよ」
　店　員：「何度も申しますが、500円と580円です！」
　皆さん：「それじゃいくら払ったらいいかわからないよ。A001はいくらなの？」
　店　員：「ですから、500円と580円です」
　
と、いう問答が繰り返されエンドレス・・・。と、上のクエリが更新できない状態なのは、［稼働日テーブル］に1月1日のレコードが2件あって、どっちを参照していいかわからないので困ります、という状態・・・ですね。

どうしてこんなことになってしまうんだと思います？
店員さんが見ている料金表に、A001の料金がふたつ載ってるからじゃないでしょうか。
つまり、「商品テーブル」みたいな、商品の一覧表っぽいテーブルに、A001という商品が2重登録されてるってわけです。多分そんなトコじゃないでしょうか。

じゃあ、こういうことが起らないようにするためには、どうしたらいいんでしょう。
料金表に新しい商品の値段を書き込むときに、既に登録済みかどうか確認して、ダブって書き込まないようにしておけばいいんですよね。
人間なら、肉眼で確認できます。
でも、Accessのテーブルは、どうでしょう？
みなさんは、Accessのテーブルに対して、「ダブって入力したりしないからね」って、どうやって約束します？
いくら言い聞かせたって、わかりゃしないですよ。相手はコンピュータですからね。

その証が、「主キー」なのです。
［稼働日テーブル］は、「何日がどういう日なのか」をずらっと一覧にしたものです。なので、同じ［稼働日］が2回出てくるのはおかしい。同じ［稼働日］のレコードが2レコード以上あると、上のような大バカ会話みたいな状態になってしまうのです。
ここで問題なのは、「今現在ダブっているか」ということではありません。「ダブって入力されてしまう可能性のある構造のテーブルかどうか」ということが問題なのです。ダブらずきっちり入力できたからといってオッケーというわけではなく、将来的にも絶対ダブらないってことを、何かの形で証明しなくてはならないのです。
なので、［稼働日］を主キーにします。

Accessに限らず、リレーショナルデータベースというものは、テーブルをうまく分けて、効率よく結びつけて情報の管理をします。表計算ソフトのイメージで、一枚の大きな表がどーんとあるようなデータの管理方法もありますが、リレーショナルデータベースというものは、なるべく無駄のないように情報を管理していくための手法のひとつなのです。わたしたちの日常に氾濫する情報・・・これらを、効率よく管理して、必要なときにさっと引き出せるようにするにはどうやって整頓していったらいいか・・・戸棚の中に書類をしまうとき、引き出しに細かいものをしまうとき、倉庫にしまうとき・・・取り出すときのことも考えて効率よく収納するやりかたっていろいろあると思います。リレーショナルデータベースは、こうした「効率の良いしまい方、取り出し方」から生まれた技術なのです。
決して、「テーブルには主キーをつけなければいけない」のではありません。それぞれちゃんと意味があります。
この意味を無視して、オートナンバー型かなんかで適当に作った主キーで（これってちょっと問題ありますよね）理解しようとすると、多分、「なんで主キーなんているんだろう・・・」って思うだけだったり、入力できないフォームになっちゃったりしてしまうはずです。

Accessの操作方法を覚えるのも大切だし、きちんとデータベースの概念を学ぶことも大切ですけれど、データベースの基本は、わたしたちの身の回りの「整理整頓術」と深いつながりがあります。机上の理論だけにとどめず、理解を深めていってくださいね。