<HOME　　<お願い事項 　　<Access2002 TOP　　　<Access97 TOP　　　<サイト内検索
MS-Access2000超入門部屋--基本操作をさらに考える

では、ぼちぼちデータベースを使って、いろいろ見ていきましょう。

まず、このテーブルを思い出してください。社員の一覧ですね。各社員の名前と、所属と、売上と、くさやが好きか嫌いか、が、わかるようになってます。

で、新しい社員が入ってきたら、このテーブルにデータが1件追加できるようなフォームを作りましたよね。
あと、誰が一番稼ぎがいいのかとか、所属ごとに稼ぎの一覧が出るようにしたりとか、いろいろこのテーブルを基にして練習を繰り返してまいりました。

で、ふと思ったんですが・・・。

いつ、だれが、いくら稼いだのか、という情報を持ちたい、という場合・・・。

どうしたらいいんでしょう。

んでもって、あとで、「今月の売上一覧」って感じのレポートとか出したいなぁって思ってたりして。

今、上のテーブルの中の「売上」って、いったいどういう金額なんでしょうね。このテーブルじゃわからんですよねぇ。。。いつからの稼ぎなのか、今月の稼ぎなのか・・・。
んじゃ、「リッチー・ブラックモアさんが今日、1200円稼いできたとしたら？？？今現在の売上643830円に1200円を足した645030円という金額を、入力しなおすって感じになるんですかね。あらかじめ電卓かなんかで計算しといて。

データシートビューで入力することになるかもしれないし、作っておいた入力フォームで該当する社員を次レコード次レコード次レコードで探したりして表示して、電卓で計算した結果の645030を入力しなおす。。。
ここに1200円って入力したってダメなことはお分かりですよね。
まあ・・・今は電卓もお安い値段で手に入るし、誰でも1台は持ってる時代かもしれないし、これでも間違いじゃないけど・・・。
でも、今のままじゃ、「いつ1200円売り上げたのか」という履歴は残んないですよね。
これはどうしましょうか。

じゃあ、社員テーブルに「売上日」っていうフィールド持たせたらどうでしょう。やってみましょうか。
フォームを閉じて、今度は社員テーブルのテーブルデザイン画面を出しましょう。

一番下でよいので、「売上日」という日付時刻型のフィールドを持たせましょう。
日付時刻型というのは、いわゆる日付と時刻を入力するためのフィールドで（あたりまえか）、基本的には数値のような扱い方を受けます。日付時刻型でないと、日付として認識されず、月ごとの集計とか、年間の集計とか取るとき難しいことになってしまいます。どんなフィールドでも、日付として扱うべきフィールドは全部この型にしときましょう。せっかくこういう配慮があるんだし。

で、まあ、なんかフォームの方にも「売上日」のテキストボックスを一個追加して、売上金額が上がるたびにその日の日付を入力しておけば・・・。
あ、今ちょっと事情があってOSを入れ替えてまして、システム日付が和暦になってますので「12/06/15」になってんですけど、気になさらずに・・・。
みなさんこういうのはご存知ですよね？
システム日付とは、Accessがコントロールしてるんじゃなくて、「コントロールパネル」→「地域」→「日付」の中で設定された値に基づいて、そのパソコン全体に影響が出るもんです。ここが「和暦」になってれば、「平成」で制御されます。が、これがまたいろいろ面倒なことを引き起こすことに・・・。
できればトータルして、「西暦・4桁表示」に統一して使っていかれるのが良いと思いますけどモ。

テーブルのフィールドプロパティでも、フォーム内のテキストボックスのフィールドプロパティにも「書式」というプロパティがあります。「表示形式」をいろいろと取り決めることができるので、日付型のフィールドの場合は、OSの日付の形式が変わっても特別左右されないよう、「表示形式」を指定するくせ、付けとくといいですね。
指定しないまでも、表示形式ってどういうことなのか、その辺理解しておくだけでもいずれきっと役に立つと思います。

で、話を戻しまして・・・。
このテーブルの中での「売上日」って、どういうことでしょう？

・・・って、変な日本語ですね。スイマセン。えー、この「売上日」って、もしかして、「最後に売り上げた日」ってことになるんじゃないでしょうか？？？？

無意味？？？もしかして・・・。Σ(@o@；

・・・・。消しましょう。

削除は、テーブルデザイン画面で、削除したいフィールドを選択し、キーボードのDeleteキーか、ツールバーの「フィールドの削除」のボタンで消えます。
削除しますよ！というメッセージが出ますけど、これに「はい」と答えれば、消えます。あ、「はい」って口でいってもダメですよ。ボタンをクリックしてください。

テーブルの設計をするとき、とっても大切なことは、「その処理の中での、情報の最小単位を見極める」ことです。
データベースの理論をきちんと学習するとなると、もっとちゃんとした用語や考え方があるんだと思いますけど、Accessで小さなデータベースを作成していく段階では、この考え方がきちんと身についていればあまり困らないでしょう。

上の「社員テーブル」の中の、情報の最小単位はなんでしょう？？？
「社員」ですよね。フィールドで言うと、「社員番号」でしょうか。
「名前」でもいいんですけど（社員番号と名前は一対ですもんね）、まあ、前にもお話した通り、名前じゃ同姓同名の可能性もありますから、コンピュータではたいてい、「そのテーブルの中の情報の最小単位をコード化」します。
で、これを、主キーとする場合が多いですね。
だって、社員番号とかって、そういう意味でつけてるんじゃないです？名前ですべて識別できるなら、いらないっしょ。
でも、「同姓同名の人がいる可能性があるから」、コード化してるんでしょ。社員番号0012の山田隆夫さんと社員番号0041の山田隆夫さんは、山田隆夫には違いないけど別人でしょう。字も同じで識別できないからって、山田隆夫Aとか山田隆夫Bとか、勝手に名前になんか文字つけます？そりゃご本人は気ぃ悪いっしょ。
むやみやたらにコード化する必要はないですけど、こういうこと少しずつ考えていくのが、データベース作りの基礎になるんです。

でも、「いつ」「だれが」「いくらうりあげたか」という情報を常に持ちたい、という場合、この処理の情報の最小単位はなんでしょう。「社員番号」でしょうか？
どの社員も絶対1回しか売り上げないんだったら、最小単位は「社員」でしょう。
んでも、そんなことないですよね。多分、毎日なんかしら売ってくる人もいるし、一日にたくさん売り上げてくる人もいるでしょう。少なくとも「社員番号」ではない。そうすると、この情報を上の「社員テーブル」に格納することはできないということになるわけです。

ここでは例題に沿ってお話しますけど、皆さんの周りで行われている業務、もしAccessでシステム化するとしたら、どうかな？？ってこと、ちょっとだけ考えてみてくださいね。

で、もちっとつきつめて考えて・・・

「１日にひとりの人間しか売上入力しない」のであれば、「売り上げた日」が情報の最小単位になりますね。

←ちょうどこんな感じです。え？なんで「名前」とか「所属」とかがないのかって？？？
そいつはおいおいお話していきましょう。とりあえず、左のテーブルの内容を見ていただいて、「情報の最小単位を考える」ことに少しずつ慣れていってください。

「1日の終わりに、その日の合計売上を入力する」のなら、「売り上げた日」と「売り上げた人」のふたつの項目の組み合わせが情報の最小単位になりますか。ふたつ以上のフィールドをまとめて、ひとつまとまりと考えることもあるんですよ。この場合はそんな感じでしょうか。

要するに、同じテーブルの中のレコードで、ダブってないフィールドを見つければいいんですよ。
左の状態だと、「売上日」はダブってますよね。んでも、同じ売上日の中で、3人の社員が売上てたとすると、その3人はダブってないですもんね。

そして、「１回の売上、ひとつの得意先への売上をひとつひとつ入力する」のなら・・・「同じ日に同じ人が何件か入力する可能性が出てくる」わけですよね。
同じ日に、同じ社員が、3回売上入力をしたとすると・・・1回目と2回目と3回目の売上を区別するためには、どうしたらいいのでしょう？？？

左のテーブルで言うところの、オレンジ色のしるしをつけたところ。同じ日に、同じ人が2回売り上げてますよね。でもデータの二重登録じゃないんです。売上金額は違う。
「0004さんの6月15日の108円の方の売上のことなんですけどね」って言えば通じるかな・・・。それで通じれば、この3つのフィールドを主軸にして考えればいいと思うんですけど・・・。
なんか、ややっこしくないです？

それに、もし仮に、ぜんぜん違うところに物を売ったのに、たまたまどっちも売上金額が2200だったら・・・・。
その人、2回売り上げてほんとは合計が4400円のはずなのに二重登録と勘違いされてその日の売上が半分・・・何てことも、考えられなくはないですよね。

「売上金額」とか「売上数」みたいな、実際の数値がいくらになるのか全く予測のつかないようなフィールドは、そのテーブルの中心となるフィールドには似つかわしくないですね。

そこで、「伝票番号」とか「売上番号」とか「入力番号」みたいな、このテーブルの中のデータの最小単位となりえるフィールドをこしらえるわけです。上の3つのテーブルのうちの、3番目のやつ、このパターンが出てきたら、毎レコード異なる番号がつくようなフィールドを設けるとよいでしょう。

こういうことが理解できているのとちっともわからん状態では、Ａｃｃｅｓｓの「便利度」ってぐっと違ってくると思うんです。

「どうして主キーが必要なんですか？主キーは作らないといけないの？」っていう質問、結構あるんですけど、皆さんにとっては、主キーなんていらないと思うんです。わたしもいらないです。でもでも、Ａｃｃｅｓｓは、「このテーブルの中のデータの単位って、何かな、社員番号かな、売上日かな。矛盾したレコードが入ってきて処理がごちゃごちゃにならないかな」って、いつもちゃんと考えてるんです。っていうか、コンピュータだから、実際ちゃんと「売上日」とか「社員番号」とか、データの中身がわかってるわけじゃないし。

だから、「なんで主キーが必要なの？」って疑問に思わないことです。
コンピュータの中に入ってくるデータなんだから、無作為でめちゃくちゃって事はないでしょう。そのテーブルの中に入ってくるレコードには、何かしら決まりがあるはずです。

こんなテーブルも、作ろうと思えば作れますけど、こんなテーブルの中のレコードに何の意味があります？？？
そりゃ、作った人にとってみれば何か必要な情報ばかりかもしれないですが、こういうものならワープロの表作成とか、表計算ソフトで作るべきでしょう。データベースってのは縦横に決まった系列のデータが入ってくることを想定したもんです。

だから、ひとつの処理の中で発生するデータが入るテーブルを作れば、おのずとその中で「主キー」に当たるフィールド、そのテーブルの中のデータの最小単位となるフィールドってものがあるはずなんです。ない方がおかしい・・・・。

ただ、これはAccessの操作というより、ものの見方、考え方ですから、どうしても理解できない、わからないということなら、あせる必要はないと思いますよ。
どうしてもわからなければ、主キーなしのテーブルを作って、少しずつ慣れていかれればよいでしょう。ただ、こういう考え方を常に持つことが、より使いやすくて安全なデータベースを作ることにつながっていくので、ほんの少しずつでも理解を深めていかれるとよいなぁと思います。