» 【第51号】因数分解の発想

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第51号】因数分解の発想

DRI通信51号「因数分解の発想」2000.12.1
いよいよ、科学が進歩し、人口が爆発し、大量殺人が行われた20世紀も最後
の月となりました。ITは21世紀の大きな柱と言われます。これに関わるわ
れわれの責任は小さくありません。正しく活用すべく努力していきたいものです。
先月は要件定義の品質保証について述べました。東洋情報の堀越さんから、
「要件定義基本4ドキュメントに加え、『論理組織の体系図』およびシステ
ムの『目的ねらい』を記述したドキュメントを追加したい」とのご意見をいた
だきました。
さて今月は情報システムの分析・設計過程で用いられている因数分解の発想に
ついて考察してみます。
因数分解とは、Ra+Rb=R(a+b)のように変換することですが、一般
には当初共通部分Rが見えていません。A=Ra、B=Rbのように、Rを切
り出せることを見抜かなければなりません。情報システム設計・構築において、
この発想はいわゆるデータベースの正規化をはじめ随所に出てまいります。若
干未整理のまま以下事例を並べます。整理の仕方や追加事例に関するご提案は
大歓迎です。


事例1
金融システムにおいては、CRMのために契約と顧客を分離関係づけしようと
いう掛け声が掛けられています。すなわち今まで[部店C.CIF#]によっ
て管理されていたのは総合口座番号などの契約であって、本当の顧客ではあり
ませんでした。部店別ですから、同じ顧客でも、関わる部店が違えば違う顧客
になってしまいます。
生保では、同じ被保険者に何回も過大な保険金がかけられ不正が仕掛けられて
いても、直ぐには分かりません。対策としては、データベースでは当たり前の
正規化−混合物を要素ごとに分離精製する−という対策が主張されるでしょう。
金融システムと似ている不動産管理システムでも、住戸と顧客と賃貸契約が、
おおむね1対1対1になるような場合、これらの分離が曖昧になり勝ちのよ
うです。
事例2
1:請求、2:精算入金、3:精算返金、4:通常入金、といった類の混合コ
ードを良く見ます。また1:顧客、2:業者、3:顧客かつ業者、といったコ
ードを設計している会社も少なくありません。分類の観点が混合しているため、
サブタイプとコード値の対応が単純でなくなり、一般に処理やメンテナンスが
複雑化します。
事例3
われわれは、これまでに500件近いデータモデリングコンサルテーションを
やらせて頂きましたが、ほとんどの企業において、リソース系DBとイベント
系DBが分離されていませんでした。すなわち社内組織、社外組織(顧客や業
者)、製商品、などに関わるリソースデータが、営業、生産、物流などの個別
DBの中にそれぞれ用意されており、別々の担当者によって多重にメンテされ
ていました。したがって内容は少しずつ違って、不整合発生の原因を作ってい
ます。
われわれがコンサルテーションで指摘するのは、「リソースは業務横断的に全社
で共用すべき資源であり、個々のアプリケーションから切り離して、一元的に
管理しましょう」ということです。更新のタイミング、ユーザ層が、個別業務
と異なるので、管理体制も別にした方が旨く行くのです。
事例4
データモデリングの結果に対して、物理設計と称して、ユーザID、パスワー
ド、更新責任者、更新日などに関するデータ項目の追加を行う場合があります。
そしてこれが多くの場合、個別アプリケーション毎に、属人的に行われます。
これは本来、セキュリティ基準などに基づいて業務横断的に設計されるべきも
ののはずです。ここに用いられるデータ項目は、エンドユーザのための画面で
はなく、システム管理者のための画面に現れ、したがって個別業務の中で設計
すべきものでなく、データベースの運用保守に関わるDBA等の管轄になるも
のと考えられます。
事例5
メタデータを扱うリポジトリを、私は業務モデル用、ソフトウエア用、プラッ
トフォーム用の3層に分けるべきと主張しています。業務モデルはユーザ要件
を表現するもので、企業ないし企業グループに1個あるべきもの、ソフトウエ
ア用は、DB2&COBOL、オラクル&JAVA、SQL&VBなどソフト
環境ごとにn個ありうるもの、プラットフォーム用はハード資源管理や自動運
用などのため、プラットフォームごとにm個ありうるものと考えます。
ノベルのNDSやマイクロソフトのActive Directory はプラットフォーム用の
もの、最近統一化の方向にあると言われるOIM(Open Information Model)
やCWM(Common Warehouse Metamodel)は本来業務モデル用であるべきも
のかと思われます(詳細は未調査、ソフトウエア用の部分が混入している可能\n性もある、またMMS(Microsoft Metadirectory Service)2.2との関係な
どご存知の方教えて下さい)。
事例6
よくCASEツールなどに、開発プロジェクトの進捗管理に関わるエンティ
ティが含まれている場合があります。これは建物やプラントのプロジェクト管
理と同様のエンティティかと思われます。ソフト用・ハード用と別々にすべき
とも考えられません。同じ種類のアプリケーションとして因数分解すべきもの
と考えたい。
事例7
35号でも触れましたが、データベースを概念レベルと物理レベルに分け、ま
たこれらをタイプ(形式/種類)とオカレンス(個体)に分けて考えるのも、
同じ部分と違う部分切り出す因数分解的発想と言えます。
実は、事例3,4,5,6、はいずれもデータベースタイプとして、
リソース
システム管理
業務モデルリポジトリ
ソフトウエアリポジトリ
プラットフォームリポジトリ
プロジェクト管理
に関わるものを分離・独立させようというものです。
事例8
受注ファイルの中の顧客#、受注品#はいずれも参照KEYで、参照整合性
検査ロジックは同じにできるはずです。顧客口座の預金残高と倉庫の商品残
高は、同じロジックで更新できる在庫データとして扱えます。これらはデー
タ項目を参照KEY、在庫データのように抽象化することによって、すなわち
因数分解によって共通の性質を抽出することによって、可能になるものです。
事例9
各社で、ハードを取り揃え、システムを開発して運用するのをやめて、ASP
に移行すべきだとか、各社で同じ法人ファイルや地図情報を共用してはどうか
(これを私はDSP:Data Service Providerと呼びたい)などやはり因数分解
の発想かと思われます。
これらは目先の問題をローカルに解こうと言うのでなく、視野を広げて問題
の本質をつかもうとするところから生まれる発想ではないかと思われます。
開発の無駄が無くなるメリットもありますが、むしろ独立部品化が進みメン
テナンスが局所化されるメリットの方が重要かと思われます。