同業者の人などからたまに、次のような質問を受けます。
「うちの
顧客管理をするのに、最初年賀状ソフトなどを使って管理していたんだけどね。ただ、事務所通信の発行とか、いろいろやりたいことが出てきて、うちのスタッフの子にACCESS(データベースソフト)を買って、顧客管理のデータベースを作らせるようにしたんだよ。」「最初のうちは、色々やってたみたいなんだけど最近は、苦戦しているようで、、、ちょっと見てくれないかなあ?ぼくが見るところ結構出来はよさそうなんだけどね!!!」
「じゃあ、ちょっと拝見しましょうと、その作られた自社製顧客管理データベースを見ると」
立ち上がったメニューを見てみると、
デザインセンスよく出来ていて、「私の作るメニューより上出来じゃないか」というのが少なくありません。
ところが、内部の構造を見てみると、かなり適当に作られていて「こりゃ、いろいろやろうとすると苦戦するだろうな」と思わせるようなつくりになっています。
例えば、データの枠組み(
テーブル)が次のようになっていたりします。
(顧客テーブル)顧客番号、顧客名、代表者名、住所、電話番号
まあ、住所と電話番号などを検索参照する程度ならコレでもいいのですが、事務所通信発行の管理をするためこんな風に付け加えています。
(顧客テーブル)顧客番号、顧客名、代表者名、住所、電話番号、1月、2月・・・・12月
「どうやってつかってるの?」と聞くと
「1月分の事務所通信を送ったら1月のところに発送済みと書いておくんです。2月分の発送に時期になったら1月発送済み分の宛名ラベルを発行して用意しておきます」
「何に困っているの?」
「所長がこれをつかって、事務所通信の
請求書の発行などもできないか?ていってるんです。ただ、請求書の発行となったら、宛名ラベルだけじゃなく、いろいろ計算集計しないといけないし、値段も月ごとに変更があるし、全然判らなくて」
データーベースを使うときには、一つのテーブルで何もかもやろうとするとこのような状態に陥りがちです。
こうした
システムを作るときには、まず、どのようなことをやろうとしていて、どの様な実態(エンティティ)が存在するか?それらがどのような関係にあるか?をまず分析しなければいけません。その上で、実態に応じたテーブルと関係(リレーション)を作っておかないといけません(関係モデルの構築)。
上のケースのような場合
まず、実態としては(顧客)(事務所通信)(
注文)の3つが存在すると考えられます。
そしてその関係は
一人の顧客にとって、1月分の注文、2月分の注文など複数が考えられます。
よって(顧客)1−多(注文)の関係になります。
また、事務所通信にとってもAさんの注文、Bさんの注文など複数考えられます
よって(事務所通信)1−多(注文)の関係になります。
まとめると(顧客)1−多(注文)多−1(事務所通信)
となるとテーブルの作り方は、次のようなものになります。。
(顧客テーブル)顧客番号、顧客名、代表者名、住所、電話番号
(事務所通信テーブル)発行年月日、タイトル、金額
(注文テーブル)発行年月日、顧客番号、発送処理
(以下請求管理のための仕組みなどは省略)
かなり単純化していますが、こうしておかないと、このシステムに対する複雑な事後の要求が出るたびに、苦しい状況になってしまいます。
※
アクセスなど低価格データベースソフトが日本で販売された当初は、プロでもこんなつくりの巨大ワンテーブルのデーターベースをつくってニッチモサッチモいかなくなった事例をいくつか見ています。(たぶん、システムを発注した会社が最初に全体像を提示せず、事後になって色々変更を出してしまったか、開発会社の事前情報整理やデータベース関連の基本技術が足りなかったか、アクセス自体のバグや当時のPCの非力さを強引に回避したツケのいずれかでしょう。)
posted by SE会計士の日記 at 08:26|
Comment(0)
|
TrackBack(0)
|
情報・システム
|

|