|
||
| <HOME <お願い事項 <Access2000 TOP <Access97 TOP <サイト内検索 | |
|
|
||
| MS-Access2002 なりきりデータベース設計 | ||
| 1 2 3 4 5 | ||
お店は非常に順調です。
最近、一度にたくさん買ってってくれるお客さんが増えてきました。
今のデータの扱い方だと、「売上一覧」に、日々の売上のデータが入ってくることになり、そのほかの情報は言わば「売上一覧」を入力するための補佐的役割を担ってます。
すべてはこの「売上一覧」に、売上のデータをためていくため・・・。
で、この「売上一覧」なんですけど、１行分（１件分）のデータについてちょっと着目してみました。
１件分っていうのは、「お客様が来店して、返っていくまでのやり取りの中で発生したデータ」を１件と考えてます。
もし、お客さんが、数種類の商品をまとめて購入していった場合、データはどうやってためていくべきでしょう。
扱っている商品の種類は４種類なんだから、↓こんなふうにしていったらどうでしょう。
うーん、ちょっと横に長くなっちゃいますが・・・。でも、まあ、必要なことはちゃんと書き込めそうですね。
毎回、こんなふうな↓売上伝票を書いておいて、閉店後にこれをまとめて入力するようにしたら・・っていうイメージなんですけどね。
合計金額も入力して、こんなふうにしておけば、木の実の価格を残しておく必要もないかもしれません。
合計金額は、そのときお客さんから受け取ったお金の額ですからね。
そのときの金額を記録しておけば、別にあとで計算させるとか考えなくてもいいですもんね。
これでも別に、いいと思いますよ。
データベースを作るに当たって、こういうふうにテーブルを作っている人も、結構いると思います。
でも、これだと少々問題が出てまいります。多分。例えば、
・商品の種類が増えたり減ったりする場合の対応が面倒になりそう
・「性別・商品ごとの集計」とか「お客さんの種類・商品ごとの集計」などの分析をしようとすると結構難しい。
などなど。
商品の種類は絶対に増えたり減ったりしないし、特に後で細かい集計をしたり分析をしたりしないのであれば、こういうテーブルが比較的使いやすいのかもしれません。
ただ、こういう一覧でいいのなら、データベース化する意味はあまりないと思います。
表計算ソフトを使って、入力したデータを見渡せるようにして管理してった方がいいんじゃないでしょうか。
データベース化するのなら、日々発生するデータをできるだけ細かい単位で蓄積しておいて、将来、さまざまな角度からデータの集計ができるようにしておくのがいいんじゃないでしょうか。マイケルのお店はどうかわかりませんけど、企業というものは成長するものです（気持ち的には）。成長に合わせて、必要となる情報の種類も増えていきます。
今、知りたい情報だけを入力するんでよければ、それは表計算ソフトのほうが絶対便利。
それから、もうひとつ。
前にお話をしました「リレーショナルデータベースの基本」をもう一度思い出してください。
「合理的で無駄のないデータ管理（コンピュータにとって）」が、基本です。
この一覧を見ると、↑ずいぶんと無駄があるように思いません？？
0個のところは、別に何も入力しなくてもいいところですよね。
まあ、「0個」と表示させてるだけで、実際には何も入力していないという意味で、空欄になってるだけなんですけどね。
要は、空欄の箇所がずいぶんできることになるんですよね。
これって、コンピュータにとってはとても「無駄」なのです。
ディスク容量とかそういうレベルのお話じゃないですよ。構造的に、無駄が多い、という意味です。リレーショナルデータベースの基本に沿ってないということは、それだけ、「MS-Accessでデータの管理がしにくい」ということにつながっていきます。
何度も繰り返しますように、やむをえないときはしょうがないんですよ。マイケルの店はMS-Accessでデータベース作るためにあるんじゃないですからね。時には、リレーショナルデータベースの基本に逆らったデータ管理をしていかなくちゃ成らないときも、あります。
でも、まず、基本に沿った設計をしてみて、何度も何度も図を書いて、実際のお店の様子をシュミレーションしてみて、これではダメだな・・・とわかったら、それなりの工夫を凝らしていく・・・という段取りを必ず踏んでください。
これがまた難しいんですが、コツとしては「情報の最小単位を見極める」というところでしょうか。
マイケルのお店での、お客様とのやり取りを再現してみましょう。
マイケル「いらっしゃいませ」
お客様「こんにちは。今日はいい天気ね」 ←3月4日、11時20分 アカリス、女性。１回の来店で発生するデータ
マイケル「そうですね。今日は何を差し上げましょう」
お客様「そうね、今日は、クヌギを頂戴。25個ね」 ←商品の売上データ1件目
マイケル「かしこまりました。他にご注文はありますか？」
お客様「シイの実もいただこうかな。そうねぇ、こちらは40個いただける？」 ←商品の売上データ2件目
マイケル「かしこまりました。他には何かよろしいですか？」
お客様「他には・・・今日はもういいわ。おいくら？」
マイケル「はい。合計で、7500円になります」 ←１回の来店で発生するデータに情報追加
お客様「ありがとう。また来るわね」
マイケル「ありがとうございました」
今回のお話で、一番重要なポイントは、ココです。
リレーショナルデータベースの設計のコツは、「情報の増え方、減り方」を見極める」ことにあります。
今まで、いろいろと情報を分けたりしてきましたけど、これってみんな、「情報の増え方、減り方」が違うわけなんですよね。
・商品の種類が増えるのと（お客様の来店人数、来店回数）
・売上のデータが１件増えるのと（お客様が注文なさる商品の種類というか、数というか）
このふたつの情報は、増えるタイミングは一緒でしょうか。商品が増えると、売上のデータも増えます？
違いますよね。
商品の種類と、売上のデータは、全然シンクロせず、別々に増減します。
お客さんがふたりになったからといって、そのお客さんがそれぞれ２種類ずつ買っていくわけでもないですよね。
そういう場合は、情報のかたまりを二つに分けて、それぞれ好き勝手に増えたり減ったりできるようにする。。。
これが、「リレーション」という考え方の基礎になります。
それ以外の理由で情報を分けることもありますし、分けないでひとくくりで管理する場合もありますが、基本的には、「データの増え方減り方タイミングで見極めて分けていくもの」とと考えてよいでしょう。
そうすると、ふたつの情報を分けて、↓こんなふうに・・・。
こんなふうに、ですね。これなら、ひとりのお客さんが大量に購入していっても、１種類だけ購入していっても、データの増え方に無駄がなくなるわけです。
ほんとは、合計の金額もとっぱらっちゃって、必要に応じて計算して出せるようにしたいんですけどね・・・。だって、単価と個数がわかれば、金額なんていつでも出せるじゃないですか。そういう情報を持つことは、コンピュータにとっては無駄なんですよ。
リレーショナルデータベースの基本に沿ってません。
でも・・・。リレーショナルデータベースの基本に沿うということは、それなりにリレーショナルデータベースに熟知してないとならないわけで、いきなり極端に基本に沿っても、熟知していないうちは逆に身動き取れなくなっちゃいます。
リレーショナルデータベースに熟知している、というのは、要は、SQLというデータベース言語に非常に詳しい、ということにつながります。SQLの知識があまりないうちは、基本に沿うのもほどほどがいいかも、しれません。特に、こういう↑、「明細を合計して金額を出す」みたいなのは、慣れないと難しいかもしれませんので・・・。
でも、基本に沿ってないということは、それはそれで、いろいろと面倒も発生します。
この辺のバランスや加減が、また難しいんですよね。。。。
さて・・・・上の図をもう一度振り返っていただいて、これ、ただ分けただけじゃ、ふたつの情報はつながらないですね。
そこで、
こんなふうに↑「売上番号」みたいな番号をつけていくことにしました。
番号は、自動的に振ってもいいし、何か決まりを作ってもいい。
あらかじめ、紙の伝票に番号をふっておいて、これを入力するようにしてもいいですよね。
別に、規則正しい番号でなくてもいいんですよ。
売上と明細をつなげる目安になればいいので、数字でなくてもいいし、記号とかでもいいわけです。
ここで重要なことは、このふたつの情報が、どういう関係を持つか、ということです。
売上番号の数をそれぞれ数えてみてください。
「売上一覧」のほうは、売上番号013の数は１個ですが、「売上明細一覧」のほうは、、売上番号013の数が3個です。
でも、他の番号は、１個ですね。
「売上明細一覧」のほう、売上番号の数が3個以上になること、あるんでしょうか。
そういうことをじっくり考えると、このふたつの情報の関係は、「一対多」です。
どんなお客さんがどんな注文をしていっても、左が１、右が多になるかどうか。。。。を、考えます。
え？そんなことわかんないんじゃないかって？
そんなことないでしょう・・・今までのお話の内容をもう一度振り返ってみてください。
「一対多」というのは、物事の流れや動きを整理したうえでの「結果」であって、別に無理やり「一対多」にしたわけじゃなかったはず。
どうして上のような図になったのか、段階を経て考えれば、必然的に左側は「売上番号がダブらない」情報のかたまりになっていることがわかるはず、なんですよ。もう一度じっくり考えてみてください。
で、「売上番号がダブらない」という証のひとつとして、左側の「売上番号」が主キーになる、のです。
主キーは無理やりつけるんじゃありませんですよ。意味もなくつけるもんでもありません。
つけなくちゃいけないというものでもない。
こうして、情報の流れや動きを図にしてみて、複数の情報同士結びつける段階になって、初めて浮き上がってくるもんなんです。
ふいーーー。マイケル、こんな感じになったけど、どうかな。
かなり複雑にはなりましたが、情報のかたまりがいくつか浮かび上がって、それぞれのかたまりがどういう関連を持つか、まとまってきました。
繰り返しになりますが、これは、テーブルの設計をやってるんじゃないんですよ。単に、情報のかたまりを図にしているだけです。
この段階でテーブルの設計とか具体的に考えては、いけませんですよ。あくまでもまだ、ドブさらい中、落書き中、です。
このくらいまで細かく考えることができて、どうやらマイケルのお店の中にあふれている情報をひととおり洗い出せたかなぁ・・・というところまで来たら、テーブルのデザインを考えましょう。
上のような図を書くのも、データベースのひとつの技術です。
本当はもっと、データの関連性とかを、一定のルールにのっとってきちんと書くもんなんですが、これ結構難しいので・・・
わたしは、きっちり業務分析ができていれば、落書きみたいな図でも問題ないと思ってます。
むしろ、ルールにのっとってきちんと図を書くことにばかり気を取られてしまって、現実離れしたデータベース設計になっちゃうことのほうが怖いですもんね・・・。慣れるまでは形にこだわらず、どんどん図にして、どんどん書き込んでみてください。
これで、
・売上数や金額の集計
・売上は曜日などに左右されるのか、どういったお客さんが多いのか・・・など各種分析
・価格改定に柔軟に対応
・現在庫数の把握と、おおよその仕入数の算出
といったことをもろもろとクリアできるような情報の流れができました。
もちろん、これで終わりではありません。ここから、MS-Accessを起動して、テーブル作って、クエリ作って・・・という作業が始まるわけです。
作り始めたら、「あれっ？こんなはずじゃなかったのに？」ということがボロボロ出てくるかもしれませんし、根底から見直さなくちゃならなくなるかもしれませんけどもね・・・。でも、そういう場合でも、今までいろいろと考えてきたことが、きっと役に立つと思いますよ。
一番大切なのは「業務分析」です。
マイケルが今、お店でどういうお仕事をしていて、どういうお客さんが来て、どういう商品があって、いったいどういう集計や分析が必要になるのか・・・。そういうことを、マイケル自身がシッカリ理解して、ちゃんと図にできる。。。データベース作りはそこから始まるのです。
 |
|
 |