<HOME  <お願い事項  <Access2000 TOP   <Access97 TOP   <サイト内検索
 MS-Access2002 なりきりデータベース設計
  1 2 3 4 5



漕げよマイケル 3

もう一度この図をじっくり観察してみてください。

今までは、マイケルの側に立ってお話をしてまいりましたが、今度はMS-Access・・・というか、リレーショナルデータベースと呼ばれるものの本質を考えつつ、お話をいたします。

リレーショナルデータベースというのは、情報を小分けし、それぞれを関連付け(リレーション)ることで、合理的で無駄のないデータ管理ができるように工夫されたデータベースのことです。正確には、そういう仕組みというか、考え方というか、技術全般のことを、リレーショナルデータベースといいます。
今はもう、そういうデータベースソフトのことを直接、リレーショナルデータベースと呼んでいて、Oracleとか、SQLServerといった製品名がそのまま、リレーショナルデータベースの代名詞になっています。もう、これからは、こういう製品名を前面に出して覚えてしまったほうがいいのかもしれないですね。

ポイントは「合理的で無駄のないデータ管理」というところにあります。
皆さんにとって、ではありません。コンピュータにとって、合理的で無駄のないデータ管理をする、というところです。
コンピュータにとって、というところがまた、ミソなんですけどね。
さっきもちらっとお話しましたが、皆さんの会社の大切なデータだろうがなんだろうが、コンピュータにとっては単なる文字や数字の羅列に過ぎません。いや、文字や数字であるという認識も、どこまでしているやら・・・。
なので、皆さんにとって合理的な管理ができているか否かは、実は皆さん次第、ということになります。
世の中、厳しいです・・・。

上の図のような作りにすると、たとえば今後、「各商品の説明」とか「賞味期間」とか、「お客さんの種類ごとに好みを入力しておく」とか、「顧客の種類」や「商品一覧」に加えたい情報が増えたとしても、「売上一覧」の中の項目は増やさなくても済みますよね。
「売上一覧」に商品番号だけを記録して、商品のこまごました情報は全部「商品一覧」の方にまとめておくというのが、リレーショナルデータベースの基本です。
こういうのを「テーブルの正規化」といいます。

  「将来項目を増やしたりしてデータベースが成長しても、必要最低限の手直しだけで済む」
  「売上一覧にも商品一覧にも両方に同じような項目ができたりして、無駄なスペースを取らないようにする」

こういうことが、コンピュータ側から見た「合理的で無駄のないデータ管理」の基本方針になるわけです。
リレーショナルデータベースの正しい考え方です。

でも・・・これは、あくまでもコンピュータ側から見た「正しさ」です。
データベースという「学問」と考えるならば、きっちり正規化して、無駄な項目がバラバラできちゃったりしないように考えていかないといけません。でも、人間の行動って、きっちりパターン化できるもんでも、ないですよね。
皆さんの会社の中のお仕事って、どれもこれもきっちり「正規化」できるほど単純ではないと思います。
例外もいっぱいあり、お客さんからの無理難題に答えて奔走することもあり。当然、データベースも、そうした例外に対応しておかないと。
いや、はっきりいって、すべてが例外であり、会社が違えばデータベースの内容だってがらりと変わるはず。
机上の論理だけではどうにもならないこともたくさんあるはずですよね。
データベース関係の資格試験を受けようとしているなら、「正規化」ということはシッカリ学んでおかないとならないですが、実際にデータベース作るときはなかなかそうも言ってられないケース、出てまいります。



マイケル、毎日がんばってますよ。
でも・・・だんだんと季節が変わってきて、ここのところ品薄になりがちです。
やむなく、若干の値上げを敢行することにいたしました。
新しい値段を、こんなふうに設定してみました。。。

価格改定は3月2日からです。
商品一覧の価格を書き換えると、3月2日から新しい価格でちゃんと計算されますが、3月1日以前は、クヌギは100円だったんですよね。
ん?商品一覧の価格を直接書き換えちゃって、問題起こらないかしら???マイケル?

昔の売上を振り返って見たい場合とか、2月とか1月の売上の集計を見る場合とかも、みんな新しい価格で売上金額の集計をしてしまいます。
「商品一覧」の価格を書き換えればいいだけなので、「最低限の修正でデータ管理ができる」というリレーショナルデータベースの基本方針は貫いています。でも、マイケルの立場にたって考えると、新価格に書き換えてしまっては困ることもありそうです。
過去の売上は振り返らない、というならいいんですが、やっぱ、2月の売上と3月の売上の比較をしたりしますから・・・。
それに、いつから値上げしたのか全然跡形も残さないってのは、営業上どうなんでしょう

だからアンタってダメなのよ。マイケル。


これはみんな、マイケルの都合です。
マイケルは、リレーショナルデータベースの本質を理解した上で、自分のお店の仕事の流れに沿った形に工夫していかなければならないのです。これが非常に難しい。誰も助けてくれません。本人が、がんばるしかないことです。


もう、リレーショナルデータベースの本質をまげて、(コンピュータ側から見て)非合理的なデータ管理をせざるを得ないことは明白なので、どうするかはマイケルの工夫次第なんですが、考え方は大きく分けて2パターンあるかなぁと思います。


  1)価格の変更履歴みたいなのを、どっかに残しておき、売上の日付と照らし合わせて、そのときの価格を表示できるようにする。
  2)「売上一覧」に、そのときの価格を書き込んでおく。


1)は、テーブルのデザインとかあんまり変更しなくてもよいので、手直し自体は楽なんですが、実際に売上の集計とか出すときめちゃくちゃ難しいです。うーん、実際、できるんでしょうか???
2)は、テーブルのデザインとかをいろいろこまごま変えないとならないので手間はかかりますが、実際に売上の集計とか出すときは楽です。
ただ、価格をいつ変更したか、という履歴は、どっかに残しておいたほうがいいような気もするんで(お客さんから問い合わせがあったときとかのために)、1)と2)の併用、って感じで考えたほうがいいのかもしれないですね。

あるいは、商品の価格を「価格変更履歴」の方だけに書いておくようにして、「価格変更履歴の中の、更新日時が一番新しいもの」を拾い出すように工夫しておくとか。。。
そうすれば、「価格変更履歴」そのものを「商品一覧」の代わりに使うこともできちゃいそうです。

「商品一覧」は、価格以外の商品情報を載せる(栄養価とか平均的な重さとか色とか主にどの辺で採れる、とか)ためのもの、というふうにしておいて、価格だけ「価格変動履歴」の方に書き込んでいくようにする、とか。
ケースバイケースでいろいろと考えられそうですね。

と、こんな感じで、どういうふうに項目を配置しておくのが一番効率がいいか(コンピュータにとっても、私たちにとっても)を、落書きしつつ考えていきましょう。