<HOME  <お願い事項  <Access2000 TOP   <Access97 TOP   <サイト内検索
 MS-Access2002チョ〜入門部屋>MS-Accessを使いこなすために・・
  (←別ウィンドウでサブメニュー)



2.テーブル設計の基本...続き

ではもう少し練習を・・・。
各社員の身長と体重は以下のように↓なってます。かなりマジデータです。

これを随時知ることができるようにするためには・・・・。
「社員マスター」に身長と体重の項目を増やして↓並べてやればよさそうですね。

でももし、季節ごとに体重が変わるとか、ひとりの社員が複数の身長と体重の値を持たなくちゃならない場合は、社員テーブルではなくて別にひとつテーブルを作るとよいでしょう。

で、「ひとりの社員の季節ごとの身長と体重」が、このテーブルのデータの単位です。
こうしておけば、このテーブルも、「社員番号」で「社員テーブル」とつながりを持つことができるはずなんです。

こういうテーブルはかなり高度ですね。ここまでたどり着くの、大変だと思いますよ。
なにより、その業務のことを熟知してないと、どういう表にすればいいのかどうかわからないですもんね。



各社員の体重に合わせて、お芋を支給しています。
体重の2割分、支給することにしているんですが、芋の量はテーブルに持たずに、クエリで計算するようにしたほうがいいでしょう。全員同じ支給率なら、たとえば「体重×0.2」で、芋の量が出るはずです。



もし、ひとりひとり支給率が異なる場合、あるいはしょっちゅう変わる場合は、社員テーブルに支給率を持たせて、体重×芋支給率という計算式をクエリでやってやればよいと思います。

では、毎日支給率が変わる場合はどうしたらいいんでしょう。ちょっと考えてみてください。
そしたら、「労働テーブル」に「今日の支給率」みたいなフィールドを持たせて計算させてはどうでしょうかね。
あるいは、「芋支給率テーブル」みたいなのを設けてやるのもいいかもしれません。
こんなふうに、「どういう結果を得たいのか」によって「テーブルの構造」も変わってくるのです。だから、テーブルだけ作ろうとしても、ダメなんですよ。どういう画面がほしいのか、どういう印刷物がほしいのか・・・そういったところから少しずつつめていかないと、形にならないんです。

でも、テーブルをしっかり作っておくと、フォームとかレポートとか作るの、楽になります。
考え方を養うのはすごく難しいかもしれませんが、少しずつ、いろんな例題とかみながら、慣れてってくださいね。



で、毎日みんながんばって働いてるんですけどね・・・・。ときどき、物を壊して帰ってくるんですよ。
この間なんか、ゴモラが大阪城を壊しちゃって。

けっこうあるんですよこういうこと。みんな体が大きいからねぇ。
なので、何をどれくらい壊してきちゃったのか、記録を残していくことにしました。

だれが、いつ、何を、どんなふうに、いくらくらい・・・・と、こんな感じかな。



まあ・・・ゴジラが1日に3箇所も壊してきたよ。あっちこっち謝りに行かなくちゃ・・・。

と、こういう具合に考えると、この表には「だれがいつどこを壊したのか」が単位になりますよね。
1日1箇所とは限らないし、毎日壊してくるわけじゃない。
誰かがなんかやらかしたら初めて1件データが発生するというタイプの表になると思います。

日誌みたいにあとで眺めることができればいいだけなら↑これでもいいんですが、もし、被害総額を集計してだれが一番壊したか統計をとりたい、なんていう場合は、被害総額は数値でなければなりませんよね。足し算するんだから・・・。
「3桁ずつ区切って表示する」とか「円をつける」とかいうのは、書式っていう機能でまかないましょう。表の中には実数だけを持つようにします。これも、コンピュータにデータを任せるときの鉄則ですよ。

もし、同じ大阪城でも、その中で管轄が分かれているとか、被害額を分けて記録しておきたい場合などは、上の表で1レコードだったデータをさらに分けて考えます。
こうすると、「だれがいつどこのどの部分をどう壊したか」が、データの単位になるわけです。



こんなふうに、「どういう目的でデータをためていくのか」をまず見極めて、「目的ごとにテーブルを作り」「その表の中に入ってくるデータの最小単位」を見つけることが、テーブル作りの第一歩になります。

で、こんな感じで↓
この二つの表を「社員番号」でくっつけて見れば、「だれがいつどこを壊して被害額はいくらでそいつの身長と体重がいくつくらいで時給はいくらで・・・」という情報を見ることができるわけです。でも普段は、二つの表は別々に存在しています。ガメラの慎重や体重が変わったとしても、「被害状況テーブル」の方は何もいじらなくてもいいわけですよね。

できるだけ、ダブらないように分けて表を作ることが、しいては「あとあとデータの追加とか修正が楽」になるはずなんです。ちゃんと作れば後々楽になるのが、リレーショナルデータベースの基本です。
でも、時と場合によっては、ある程度ダブらせないと必要な情報が取れなくなったり間違った結果が出てきちゃう場合もあります。なかなかこういうのは「セオリーどおり」というわけにはいかないんですよ。
こういうのを見極めてテーブルを作ってくのはほんとに難しいです。

ポイントは「どういう結果を得たいのか」をじっくり考えて、頭の中でシュミレーションすることです。
ある程度訓練が必要なところでもありますんで、会社の中のいろんな書類とかを見て、「こういうのを印刷するためには、どういう形でデータを持っておく必要があるのかな」とか、考える練習をしてみるといいと思います。
でもこのとき、繰り返し、毎日、1ヶ月ずっと、いつ、だれが、どういうときに印刷するものなのかってことも含めて考えないとなりません。
1枚だけ1回だけ印刷するだけならワープロで作ったほうが楽ですもんね。

もし、こうした「テーブル設計のノウハウ」みたいなのを習得したいっとお思いでしたら、SQLというデータベース言語について書かれている入門書を一冊お買いになることをお奨めします。ほんとは、データベース概論みたいな書籍がいいのでしょうが、多分市販されてるものって少ないんじゃないかと思うんです。あってもすっごい値段が高かったりして・・・気軽にはじめるためには、SQLってどんなもんなのか書いてある本をお読みになるといいと思いますよ。



今の時代、データベースといったら、OracleとかSQL ServerとかDB2とか、データベースの製品そのものの名前が真っ先に出てきますよね。これらはどれも、それぞれの会社が作って売ってる「イチ製品」に過ぎないんですけれど、こういうものがデータベースそのものになっちゃってます。
なので、基礎知識や考え方を学ぶための書籍って、逆にすごく少なくなってきてると思うんです。
データベース関係の書籍のコーナーを見ると、「Oracle入門」とか「SQLServerを使ったどうのこうの」とか、そういうタイトルの本がほとんどだと思います。まず製品があって、その製品を使ってデータベース環境を構築していくには、どうだこうだと、そういう切り口で学ぶほうが手っ取り早いのかもしれないですね。
だから逆に、「これから新しくデータベースを導入しようと思うんだけれど、製品比較を・・・」とか思っても、製品に特化した資料とか書籍ばっかりになってるんでなかなか比較が難しいかもしれないです。

SQLというのは、リレーショナルデータベースとやり取りをするための(リレーショナルデータベースの考え方のもとに設計され構築されたテーブルとやり取りするための)データベース言語です。
SQLという言語を使ってきちっととりたいデータが取れるようなテーブルこそ理想形なので、SQLに詳しい人はテーブル設計のノウハウもたくさん持ってらっしゃいます。専門的な知識を持って、どんな業務でも簡単にテーブル設計ができるようになるためには、SQLを学んでいくのが一番かなと思いますよ。

でも、とりあえず簡単なデータベースの構築ができればいい、あんまりあれもこれもと欲張らないのでありがちな交通費の精算システムが作れればいい、ということなら・・・・・MS-Accessを使って試行錯誤しながら理解を深めていくのでもいいんじゃないかなって思うんです。