» 【第60号】決めるもの、決まるもの−その2

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第60号】決めるもの、決まるもの−その2

DRI通信60号「決めるもの、決まるもの−その2」2001.9.3
DRI通信もいつのまにか60号となりました。5年続いたことになります。
はじめはそのうちテーマが枯渇するのかなと思っていましたが、むしろバック
ログがたまり気味です。いろいろな人とお話ししていて、話しの通じない原因
が、前提知識の違いや説明の不備にあること気づき、これを説明する必要から
生まれたものが少なくありません。説明の過程で曖昧なものが明快になり、さ
らに新しい発見があることもあります。
初稿は土日に半日か1日当てて書きますが、誤解を招かないよう何人かの方に
モニターをお願いしています。これに基づく修正や自発的推敲が何回か入るた
め、もう半日くらいを使ってしまいます。ときどき「楽しく読んでいます」と
いったメールを頂きますので、こちらも「楽しいボランティア」として書かせ
て頂いています。
アメリカでは熱心なDOAマンがDAMAを通じて活動していて、最近はロン
ドンで国際会議を開くなど、勢いを盛り返しています。日本はIRM研究会が
なくなり劣勢です。零細企業でやれることはかぎられますが、DOAの火を消
さないように、もう少しがんばりたいと思っています。


先月号の「その1」では「エンティティタイプは、決めるものではある。しか
し広域における円滑なコミュニケーションを実現するために、共通認識のでき
る比較的大きな粒度のエンティティタイプを定義し、あとはサブタイプとして
位置づけてはどうか」という提案をいたしました。ROMの方が多いので、確
認はできませんが、大方のご賛同を得たと解釈しております。
さて今月は続きですが、1単位のDBやシステムの大きさは「決めるものか決ま
るものか」を考えます。
数学的には、決めるものは独立変数、決まるものは従属変数ということになり
ます。独立変数はしたがって何らかの最適化によって決めることになりますが、
厳密な数式モデルを作って最適化計算を実行しても、この激動の世界、モデル
構造やパラメータは激変しますので、実用になりません。パラメータの一つで
しょうが、特に期間「2年先までか、10年先までかなど」は、結果を大幅に
変えてしまいます。かと言って「みんながそうしてるから」といった護送船団
的多数決は最後の手段、やはり本質を捉えた経験則やこれに基づいた標準化・
規準が重要かと考えます。
「とりあえず間に合わせで」という前提では、本質を捉えた議論ができません
から、まずは長期的に考える必要があります。従来は開発のタイミングや予算
によってDBやシステムの大きさが決められてきたきらいがあります。すなわ
ちスポンサーの懐が、DBやシステムの単位を決めた。クライアント/サーバ
ーシステムが安易にできる環境が与えられ、ベンダーの言いなりに次々と孤島
システムを作った。「運用や保守、他システムとのデータの流通や整合性は
後でなんとでもなる」と考えられたかのようです。
例外は別として、これらシステムに共通に見られる問題は、各システムがリソ\nースデータ(社内外人・組織、品目などのマスターデータ)を独自に抱え込ん
でいることです。個別に定義し保守する無駄もさることながら、ストアされる
データがそのアプリケーションの視野から見たローカルな標準データであるた
め、他システムとのデータ流通、DWH構築などに支障を来すのが困ります。
これは「リソースDBとイベントを扱うアプリケーションDBは分離すべき」
という「決まり」を無視した「つけ」のように思われます。
リソースDBの第1の特徴は更新頻度が少ないことです。一般にはイベント系
DBが更新されないとき、夜間バッチで更新して済むものが大部分です(もち
ろんリアルタイムでも可能ですが、そうするとリカバリや再実行に制限が発生
します)。
第2の特徴は一般に共用性が高いことです。リソースと言っても、たとえば物
流効率から決められたルール
[品#.届先c]−(出荷倉庫#)
[出荷方法c]:トラック/船/飛行機
などアプリケーション専用のものもありますが、社内外の人・組織、設備、品
目、勘定科目、またこれらの分類や区分など共用性が命と言えるデータ項目が
たくさんあります。これらは全社あるいはコラボレーションすべき企業群全体
に1個あるのが理想です。ERPもレガシーも、必要なら変換テーブルを用い
て、これを共用しなければならないはずです。共用の観点からすれば、リソー
スDBはリポジトリ(メタデータDB)と一括して取り扱うべきものと考えます。
リソースDBを1個切り出したとして、営業、生産、物流、人事、経理などの
イベント系DBはどうなるのでしょうか。私は、これらはまずデータ管理者の
守備範囲によって決めるべきと考えています。恐らく上記の5分野は十分大き
いので、これらを跨ったDB(正しくはDBタイプ=DBの種類)はあり得な
いでしょう。すなわち更新頻度でなくメタデータの更新責任者ごとに、まず分
かれるべきとするわけです。先のアプリケーション専用のリソースはこちらに
組み込んでもよいでしょう。
次に同種のDBが分散設置されるようなとき、(正しくはDBオカレンス=
DBの個体について)DB管理者ごとに、たとえば山田さんの管轄する鹿島工
場DBと鈴木さんの管轄する大阪工場DBを別々に設定します。この場合はア
プリデータの更新場所すなわち更新責任者の地理的特性が決め手になります。
では小さい方の制限はどうなるのでしょうか。私は、これは「DBトランザク
ションが整合性を保証できる大きさが必要である」、そのために更新整合性が
鍵であると考えています。たとえば出荷ファイルと在庫ファイルは同一DB内
に定義しなければなりません。出荷数量に連動して在庫数量を変えなければな
らないからです。
以上DBの大きさは更新頻度、更新責任者、更新整合性など、更新特性によっ
て「決まる」のではないかと考えています。しかし、いままではスポンサーの
懐に合わせてこの「決まり」を無視したDBがいろいろ作られてきたのではな
いでしょうか。
ではこの基準で作られたDBがあったとして、システムの大きさはどうなるの
でしょうか。参照だけのシステムならば、大きさに制限を設ける基準はあまり
ないと考えます。問題は更新のあるケースです。システムと言っても単なる寄
せ集めでなく、1個のDBMS下で動く処理の塊を考えるとき、これが2個以
上のDBを更新して良いでしょうか。私は反対です。リカバリなど運用がいた
ずらに難しくなるからです。逆に更新対象が1個のDBに閉じている限りシス
テムの大きさは自由、すなわち「決めるもの」であると思われます。したがっ
てリソースDBありきとするならば、アプリDBとアプリシステムは、スポン
サーの懐に合わせて少しづつ作っていけば良いと考えます。