データを入力して蓄積するだけが業務システムの役割ではありません。蓄積されたデータを様々な局面で利用できてこそ「よいシステム」と言えます。よいシステム作りのために、今回紹介する集計機能をマスターしましょう。
- データは溜まってからが重要 -
日々の仕事ではデータがどんどん蓄積され、テーブル内のレコードという形でデータベースに記録されていきます。そうやって蓄積された情報は、１日・１箇月・１年などの区切りで整理され、テーブルにはまた新たなレコードが記録され……と、このサイクルが繰り返されます。
では、蓄積されたレコード群はどうなるのでしょう？ ただ「過去のデータ」として保存されるだけでしょうか？ もちろんそんなことはありません。業務遂行の結果生まれたたくさんの情報は、例えば会計処理や税務処理の基礎データとして他の業務で使われたり、新商品の開発や販売促進などの検討資料に用いられたり、むしろ蓄積された後からの活用が重要になってきます。
冒頭に書いたように、データベースアプリを作っているとつい入力周りに意識が集中し、入力を終えた後の処理をおろそかにしてしまいがちです。実際、大がかりな業務処理では、普段はデータの入力に携わっていない営業や倉庫の担当者、あるいは経営の意志決定を行う経営陣が本当に必要としている情報を得られず、開発セクションに苦情が集中することもよくあります。
- データ活用を活かした設計を -
受注伝票の処理、発送や在庫の増減、経理や財務との連携はうまくいっているのに、営業担当者が前月の顧客との取引を調べたり、役員が年間の地域別・年代別売上の推移を調べたりしようとすると、途端に操作が不便になったり、ときにはその要求にまったく応えられなかったり……。
これは、システムの設計者（または依頼者）が「蓄積されたデータの二次的な利用こそが最も重要である」ということを知らないか、意識していないということです。組織が大きくなり、システムの設計者や設計者に依頼する担当者が、自分に与えられた仕事さえこなしていればいい──といったお役所的な発想をした場合、こういった問題を引き起こすケースが目立ってきます。
筆者はかつて、ユーザーが「こんなデータを取り出せるようにして欲しい」と要求すると、システム担当者が「それにはデータベースの構造ごと変更しなければならないから無理だ」と断る、といった状況に遭遇したことがあります。
どの部署ではどのような情報を欲しがっているのか──といった需要を十分検討しないまま、システムを設計すること自体が大きな問題です。データ構造がプログラム自体に埋め込まれてしまう汎用機＋COBOLの時代には、よくこういった問題が発生しました。しかし、これは過去の問題ではありません。今でも、あちこちで尾を曳いています。
- 集計処理の充実したシステムを -
データベースは、単に情報を蓄積するだけではありません。蓄積された情報が新たな業務や研究・分析に利用され、情報の循環あるいは拡大再生産を行うために役立ちます。そのために備わっている機能が「データの集計」です。
設計者は、データを蓄えることだけではなく、蓄えたデータをどのように使うかまで十分に検討しなければなりません。そして、ユーザーの望む情報を手早く引き出せるよう、集計処理の充実したシステムを作ることが大切です。
集計には色々あります。前回少し触れたCOUNTは、レコード数を数える機能でした。その他、特定フィールドの値を合計したり平均したり、最大値や最小値を取り出したりすることで、単なる業務遂行の記録だったテーブルが大きな情報源となってきます。
なお、当然のことですが、合計・平均・最大値／最小値など、集計の機能は基本的に数値型のフィールドを扱います。
 |
|
|
