「当社は何もかもアナログな仕事の仕方なので、いったんデータベースを作ってもらって必要なデータを入れておき、その後に業務をどう変えていくか考えようと思います。」というご相談をお客様から受けました。うーん、気持ちはわかります。社内が伝票だらけで、それを使った人間系の仕事ばかりだから、データベース化したい、と言いたくなる気持ちは…。しかし、これは大きな問題が起こりうる考え方で、非常に面倒くさいのです。

例えば、注文のデータをデータベースに入れることを考えます。注文は通常、

　注文日

　得意先（社名や氏名）

　注文された製品の品番や型番と数量

　希望納品日

その他、単価や合計金額、送料、支払い条件などが記載されていることもありますが、基本的には上記４種類のデータです。これをデータベースに入れましょう、ということになると、データベースに入れた後の処理が決まっていないまま入れることになるので、おそらく上記４種類のデータを１行（１レコードと呼びます）に入れることになります。データベースですから当然得意先や製品の品番などもマスター化され、データベースの中にあらかじめ設定しておくことになります。

データベースは簡易的なものであれば「作ればその通りにデータを登録できる」ので、４つのデータぐらいのカンタンな構造であれば特に問題なくさっくり動くようになります。

しかしです。問題はこの後にやってきます。例えば、「データもたまってきたので、そろそろ今までやっていなかったことをやろう。そうだなぁ、まずどんな客先にどんなカテゴリーの商品が売れているか、分析できるようにしてみよう！」となった場合、客先を分類できるカテゴリーコードを附番しようとします。

　A社ーーー商社

　B社ーーーメーカー

　C社ーーー商社

といった様にそれぞれ商社とかメーカーに相当する分類コードを付けるでしょう。そして、分類コードから過去の注文実績を抽出しようとします。分類コードから得意先を抽出し、そこから注文実績を参照する、という、通常の受注登録とは全く逆の順番でデータを分析できるようにしたくなりますね。その時、「動くけどめちゃくちゃ遅い」という事態が発生する可能性が極めて大きいのです。もともとこの様な使い方を想定してあれば、データベースの設計の際にこの順番での検索やデータ抽出ができるように作ることが可能です。しかし、当初そんな要求は出していないので、無理やり区分などのデータを後付けし、そこから逆展開することになるので遅くて仕方ない、場合によってはいつまで経っても処理が終わらないといった不具合が出る可能性があるのです。

もちろん、気が利いたエンジニアが作っていれば、「おそらく将来こんな使われ方をするんだろうなぁ」という想像をし、データベースの基本構造をこっそりと変えておいてくれるかもしれません。しかしそれは単なるラッキーなことで、通常はユーザー側がきちんとやりたいことをあらかじめ伝えておくことが肝要です。

今回の例は速度が出ない、という程度の影響が考えられるケースでしたが、最悪「それは作れない」というケースも存在します。データとデータの関連性を綿密に考えて設計しないとデータベースはまともに動かないのです。

非常にめんどくさい話ですが、データベースを作りたいと思ったときには、変な失敗をしないよう最低でも「いったん何をしたいのか？」を明確化し、それができる構造を設計してもらう必要があるのです。