<HOME  <お願い事項   <Access2002 TOP   <Access97 TOP   <サイト内検索
 MS-Access2000超入門部屋--見積書を作る
   1 > 2 > 3 > 4 > 5 > 6 > 7 > 8 > 9 > 10 > 11 > 12 > 13 > 14 > 15 > 16 



今日は、「見積書作成データベース」を作ってみようと思います。
長丁場ですけれど、がんばって挑戦してみてください。

と、一口に申しましても、こういうのは、会社とか、業務内容とか、取り扱っている製品とかによって、見積書の作り方自体も変わってくると思います。
なので、ここでは、ほんとにほんとに単純なシンプルなやつを作ります。皆さんのお仕事の「見積書」とは程遠いと思いますけれど、基本的な考え方はきっとお役に立つのではないかなと思うので、もし、これから「見積書」みたいなものを作らなければならないお立場の方は、シンプルなヤツを作って流れを確認してみてください。作りこんでくとややっこしいですからね。まずは超単純な構造の見積データベースで概要を掴んどくと、複雑な構造の見積を作んなくちゃならなくなったとしても、きっときっと楽ちんだと思いますよ。

まず・・・何か業務をデータベース化しようとするとき、いきなり「 Access の操作」のことを考えてはいけませんよ。これはみなさんオッケーですよね。まずは「設計」です。といっても何もフローチャートを書くとか仕様書を作るとかそういうことじゃないんです。ようは・・・見積書発行業務の「現状分析」ってやつですね。

とりあえず手書きで1枚、「見積書」を作るところを想像してみてください。

1)お客様から電話がかかってきて、商品の見積もりを出してくれと言われます。そしたら?
2)見積用紙に、そのお客様の名前や住所などを書いて、自分の名前を書いて、商品名と、単価と、個数と、金額を書く。
3)いくらくらい値引きできるか、今から発注したとしたら納期はいつ頃になるか、などを調べて書く。
4)内容がよければお客様にファックスかなんかで送る。

見積作成の流れはこんなところでしょうか。

もちろん、会社によっては、3)と4)の間に何かしら手続きが必要とか、2)の部分でもっと書き添えなければならない項目がたくさんあるとか、いろいろあると思います。重大なことを見逃してしまわないよう、とにかく見積依頼が発生してから出すまでの間にやらなくちゃならないことを全部書き出して、順番とか、段取りとかの確認をしましょう。

で、この場合の「見積書1 枚」が、このデータベースでの「仕事の単位」になります。何事も、見積書1枚に対して、ことが起こるということです。

ここまで考えがまとまればしめたもんです。

最終的に「見積書」を出すことが目的ですから、「見積書」を出すためにどういう処理をしなくてはならないのか、ということを最優先にして考えていくのがコツです。リレーションシップとかテーブルの正規化とかいう言葉も、結局はその目的を果たすためにあるのですから、リレーションシップをするために見積書を出すようなことにならないよう、目的を見失っちゃわないでくださいね。


さて・・・。そしたら、まず、中心となるテーブルがふたつ。

1件の見積書の中で、見積もる商品が1つならいいんですけど、2つだったり3つだったり 10 個だったり、「見積もってくれ」って言われる商品の種類や数がまちまち、って場合は、見積のテーブルにぶら下がるように、商品明細のデータを入力するテーブルを作って、ふたつのテーブルをセットで使っていこうと思います。目指すは「サブフォーム / サブレポート」ってやつです。

そして、見積を出す社員の名前や部署がすぐ引き出せるよう、「社員マスタ」を設け、見積る商品の単価とかをすぐ引き出せるよう「商品マスタ」を作り、見積を依頼してきたお客さんの住所とかを参照できるよう「顧客マスタ」を作ります。

とにかく、見積書1 枚にどんなことを書くのか、その情報はどこにあるのか、を、ひとつひとつ明確にして、まとめて、テーブルにしていきます。いきなりテーブルの設計をしようと思ってもなかなかうまいこといきませんよ。最終的に出したい「見積書」から、処理を逆流させていって、テーブルのデザインを掴んでいくのがコツです。

今回は、「複数の人があっちこっちから見つもりの入力をする」みたいなことを想定して、「テーブル」と「その他のオブジェクト」を分けて作っていこうと思います。なんでか?ってとこは、他のコーナーでもお話してますので、ぜひとも参考にしてってください。

今日はこんな感じで作っていこうと思ってるんですけど・・・いかがでしょう?え?そんなこと聞くなって?えーそんなこと言わないでいっしょに考えていきましょうよー。

ふたつMDB を作って(今回は片方をMaster、もう片方をMitsumoriという名前にします)、テーブルだけのMDBをサーバーのどこぞのフォルダに置き(これは絶対動かさないし削除しないし名前も変えない)、もう片方を個々のパソコンに置いて、後者の方を開いて使います。前者は直接開かず、ただサーバーの中に置いとくだけです。

Master.mdbのテーブル類を、Mitsumori.mdb側から「テーブルのリンク」して使おうと思ってるんですけどね。このとき、4〜5人でワーワー入力する可能性が高いなら、Mitsumori.mdb 側に「とりあえずテーブル」を作って(ワークテーブルとかテンポラリテーブルとかいう言い方する人もいますね)、とりあえずこのテーブルに 1件分の見積を入力して、内容がオッケーだったらMaster.mdbの本番テーブルにレコードを移す、っていう感じにしようかなって思ってます。かなり手間ですけど、しっかり作れば安全に運用していくことができると思いますよ。


余談になりますが・・・Access に限らず、リレーショナル・データベースとかSQLっていう考え方で動いてるデータベースって、とってもとってもパワーが必要なものなんです。わたしたちにしてみれば何気ないデータ入力とか検索でも、とってもとってもエネルギー使ってます。もともとリレーショナル・データベースって、パソコン文化の中で生まれてきたものじゃなく、もっと上位クラスの、汎用機とかから生まれてきた考え方ってこともあるんで、パソコンの場合だとほんとにほんとにほんとにほんとにメモリとかディスクをいっぱいいっぱい食って仕事をします。やっぱし、用心すべきところは用心していった方がいいですよ。 MDBファイルぶっ壊れちゃってから怒っても、取り返しつかないですし・・。

CPU が速くても、ディスクの空き容量が 10MB くらいしかあいてない!とか、スクリーンセイバーとかやたら常駐させてるソフトがいっぱいあったりとかしてるパソコンだと、やっぱし Access の動きは遅いし、メモリ不足とかハングアップしちゃったりとかする可能性もあります。 Access に窮屈させないであげてくださいね。

MDB を二つに分けて作っておけば、Master.mdbだけこまめにバックアップを取っておけば、とりあえず大切な見積のデータを守ることはできますよね。

ただ、これはみなさんご承知だと思いますけど・・・ MS-Accessはあくまでも「パーソナルなリレーショナルデータベース」です。

今、「ネットワーク」とか「LAN」といった環境でお仕事なさるのはごくごく自然なことだと思いますけれど、MS-Accessで作成したMDBファイルは、サーバーに置いて大勢でワーワー使うという使い方にはあまり適していません。上のような作り方をしても、 20人30人でほとんど同時に見積書の入力をする(おなじテーブルに対して入力するとか更新するとか)場合、まったくかち合わなければ問題ないでしょうけれど、おなじレコードに対して複数の人が同時に金額の変更とか顧客の変更とかやらかした場合に生じる障害に対しての配慮は、万全とは言えません。それは Accessがもろいという意味ではなくて、そうした細かい障害設計などよりもまず手軽さを重視しているものだからです。
大人数で、同時に、ひっきりなしに、毎日毎日かなりの件数の見積を入力するような場合は、 OracleやMS-SQLServerなどのデータベースの導入を検討なさるべきでしょう。ただ、勘違いをしてはいけないところが一点・・・「高度な技術を駆使して作ったトラブルの少ないシステム」というものは得てして運用面で手がかかるものです。 Oracle導入した、高スペックのサーバーに導入した、すごく高度な技術を使ってシステム組んだ・・・だからといって手が離せるわけではない。返って運用には手がかかるはず。やっぱりそれなりの覚悟が必要ですよ。
テーブルにデータ入力するのだけがデータベースではありませんからネ。

「じゃあどれくらい大変なんでしょうか」とか「何人くらいまでならAccessでも大丈夫なんですか?」とか、こういうのは一概に言えませんよ。聞かれても・・・誰も答えられないです。こういうの相談に乗ってくれる会社さんってたくさんあると思うんで、一度相談なさった方がよいと思いますよ。


お話がそれちゃいましたね。この辺まで構想が固まったら、細かいところは作りながら考えていきましょうか。

では、いざ。