<HOME <お願い事項 <Access2000 TOP <Access97 TOP <サイト内検索 | ||
MS-Access2002 なりきりデータベース設計 | ||
1 2 |
さてさて、マイケルの店の売上データベース作りも、いよいよ終盤ですさてさて、マイケルの店の売上データベース作りも、いよいよ終盤です。
最後にお話しするのは、売上の入力のところです。
今回は、具体的にはデータベースは作らないので、雰囲気だけ見てってください。
今回のお話は、今まで相当作りこんできた「在庫」とか「売上集計表」とかを根底からくつがえすような内容になります。後からテーブルの構造を変えるってことは、データベース全体に相当な影響を及ぼすことになるわけで、その辺をご覧いただけたら・・・と思います。
設計の解説(漕げよマイケル5)のところで、以下のような図をご覧いただいたと思います。
1回の来店、一人のお客様とのやり取りで発生する情報なんだけど、
お客が買う商品の種類は1種類かもしれないし、2種類かもしれないし、10種類かもしれない。
というふうに、「1件なんだけど、複数件」の入力をこなすためのフォームとして、「サブフォーム」というスタイルのフォームを作ることがありますよね。あるんですよ。これが。
もちろん、必ずサブフォームにする、という意味じゃあありませんですよ。結果的に
・売上の入力(来店したお客さんの情報や、売上日付、売上総計など)
・商品の入力(お客さんが1回の来店で購入した商品の種類と単価、数量など)
をきっちり入力できればいいわけですから、方法はひとつではないはず。
サブフォームの作り方、仕組みについてはヘルプ等で確認してくださいね。
ここではあんまり細かいことはお話しませんです。
売上のテーブルが↓こんな感じになっているとします。
でも、実際には、このエゾリスさんは、他にもいくつか買っていきたい商品があったんですよね。。。
でも、1回のお買い物で1商品しか入力ができないので、クヌギだけ買って帰ってもらいました。
ってマイケルはバカですかー!!!
そんな営業の仕方があるかっ!
このエゾリスさんは0001の商品を1個だけ買っていきましたけど、
実際には全部で4種類くらい買っていきたかったんだよなぁ・・・、
という場合は、
と、こんなふうにテーブルをふたつこしらえて、分けて入力して行くようにすればいいわけです。
ここで、もう一度実際の業務をもう一度振り返ってみましょう。
・商品別の売上数量や売上金額などの集計・分析をしょっちゅうやるのか、
・分析はあまりやらないので、とにかく総売上の金額だけ手っ取り早くわかるようにしたいとか、
・消費税はどうするのか、とか、
・値引きやサービス料などはどういう対応をしてるのか、とか・・・などなど
それによって、ふたつに分けたテーブルのどっちにどういう項目を作るべきか変わってくるずですよね。
どうすればいいのか、どういうテーブル構造にすればいいのか、は・・・皆さんの会社の業務がどうなっているのか・・・それを見極めなくては前に進めません。専門的な言葉を使って設計する必要はありませんから、落書き感覚で図に書き出してみるといいと思いますよ。
・1回の売上の入力で、どういう項目が発生するか
・入力した項目は、後日どうなっていくのか(集計、分析、請求書の発行・・・などなど)
こういうところをじっくり考えて、テーブルの構造を見極めていきましょう。
マイケルは、まず、「売上テーブル」のほかにもうひとつ「売上明細テーブル」というテーブルを作りました。また、「売上テーブル」の方には「売上金額」というフィールドも作りました。
そして、「伝票番号」というフィールドを設けて、1回のお買い上げごとに番号を振るようにしようと考えました。
両方のテーブルに「伝票番号」というフィールドを設けます。
もし、「売上明細テーブル」の表示順(後で印刷するときのことなどを考えて)にこだわるのなら、入力した順番があとでわかるようなフィールドを別に設けておく必要があるかもしれませんね。これはちょっと難しいお話になりそうなのでこのコーナーでは触れませんが、、表向き使用しないフィールド、ということなら、オートナンバー型のフィールドかなんかこっそり作っておくといいと思います。
で、このふたつのテーブルを元にして、サブフォームを作ろう、というわけです。
「サブフォーム」に詳しい方ならご存知と思いますが、もし「サブフォームをフォームウィザード機能」を使って作るのであれば、このふたつのテーブルが伝票番号を元に関連づいているということをMS-Accessに教えておかなければなりません。
ウィザードを使わないのなら、別にこんな手間かけなくてもなんとかなるんですけどね。でも、こういうウィザード機能は仕組みを理解してうまいこと活用していくのがいいんじゃないかなぁと思うんです。
じゃあ、「このふたつのテーブルが伝票番号を元に関連づいているということをMS-Accessに教えておく」ってのは、具体的にどういうことなのかというと、リレーションシップってやつですよね。リレーションシップって何なのかわからない人はヘルプで調べておいてくださいよ。
これ、リレーションシップオブジェクトを必ず作らなきゃならないのかと誤解して覚えてしまうと、わけのわからないことになりかねないので、何で必要なのかきっちり理解しておく必要があると思いますよ。
「よくわかんないけど、本に書いてあったから、リレーションシップって必ずやらないといけないもんなんじゃないの?」という覚え方は、実に、最悪です。。。
いきなり「一対多」という言葉を使って理解できる人はそれに越したことないですが、理解できていないのに言葉だけ先行しても苦しいばかりなので、「1回の売上につき、複数の商品を購入する可能性がある、購入できる関係」というふうに、実際の業務の中の言葉でご自身に説明ができるようにしておくといいですよ。これが結果的に「一対多」になるのであって、別にこの世の中に「一対多」という機能があるわけじゃありませんからね。
で、結果的に、マイケルの店の売上データの場合も、「売上」と「売上明細」は「一対多」になるわけなんですけども、ここでしっかり理解しておかなくちゃいけないのは、闇雲に一対多になるわけじゃなくて、「伝票番号」の数が「一対多」になるわけですよ。これ、ちゃんと理解できてないといけません。つまり、「売上」のデータの中に、同じ伝票番号がふたつ以上あったらおかしいわけです。
皆さんは困らなくても、MS-Accessは「伝票番号00002が2件あったらどうしていいかわからない」のです。
こういうリレーションは、成立しません。
なので必ず、「一対多」の「一」の方の「伝票番号」を主キーにしないとならないわけです。
主キーにすれば「伝票番号はダブらない」という証明になりますからね。
と、いうのが、これからの作業の背景です。ここまでこぎつければ、後は問題ないですよね。
と、いろいろお話してきましたが・・・。
こういう「データベースの基本設計」って、すごく技術がいるんですよ。
データベースの知識もいるし、業務知識(会計とか経理とか流通とか・・・)も幅広く深く詳しくひつようになります。
そういう、設計やコンサルティング専門にやってる技術者さんもたくさんいるくらいですから・・一朝一夕に身につく技術でもないんです。
ほんとに、難しいことなんです・・・。
以上で、「マイケルの店の売上入力のためのデータベース作り」のお話は終わりです。
いかがでしたでしょう。
もちろんVBAも大切かもしれませんけど、データベース設計には、それとはまた次元の違った「難しさ」があると、私は思います。
フランス語勉強したからってブランス文学史上に名を残せるとは限らないですよね。データベースつくりだって同じで、コードの書き方だのプログラミングの手法だの覚えたところで、業務分析ができなかったら、それらの技術を活かせないわけです。
「VBAの勉強をしています」と言う人を見て、少々不気味に感じることもあります。
車を買って、右折や縦列駐車の練習をして、道を覚えようとしないのと、同じような状況なのでは・・・。
データベースの技術が相当あるプロの人でも、結構トンチンカンなこと言う人いますよ。
すなわち「高級な車を買い、免許も取得し、右折や縦列駐車の練習もしました。もう20年、車の運転を続けています。しかし、なぜ移動しなくてはならないのかが理解できません。どうして移動しなくてはならないのでしょうか。わたしが理解できないのは、この車に欠陥があるということですか?」と聞かれたら、皆さんならなんて答えます?
しばらくお話をすれば、納得のいく答えは見つかるかもしれませんが、この人は、一言二言で端的に手短に、ずばりと要点を指摘してほしいと思っています。一言で、なぜ、この人は移動しなくてはならないのか、教えてあげることができそうでしょうか?
ほんとうの「難しさ」は、身近で見えにくいところに潜んでいるもんだ、と、私はそんなふうに思うんです。
MS-Accessが難しいのは、初心者だからでもなく、VBAがわからないからでもなく。
MS-Accessの使い方を学ぶだけでは、本当の目的を達成できないから、ではないでしょうか・・・。
次のページは、ちょっとしたオマケです。
すでに何件か売上データを入力してしまっているので、「売上テーブル」を「売上テーブル」と「売上明細テーブル」に分ける作業などをご覧いただこうかなと思います。もちろん、決まったやり方はないので、一例に過ぎませんし、あまり細かいことは書いておりませんけれど、何かの参考になればなぁと思います。