» 【第100号】データモデルの統一

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

DRI通信100号「データモデルの統一」 2005.1.4
あけましておめでとうございます。やっと雪の舞う冬が来ました。短めのお正月休み、いかがでしたか。
DRI通信も8年4ヶ月続いて、これで100号を迎えました。「毎月送られてくるDRI通信、楽しみにしてます」、などといわれると、本気にして気合を入れて書いてます。テーマは、いつも5個くらいは溜まっていて、その中のひとつを月中の土日に書きます。調子の良いときは5時間くらいで書けますが、それから数人の方にレビューを依頼します。誤解を招くところや、分かりにくいところを直し、推敲して月末に挨拶をつけ、営業から発行してもらいます。皆様、とくにレビューアの皆様のご協力によって、100号になりました。ありがとうございました。
12月6日には、DOA+コンソーシアムの1周年記念セミナーがありました。120名以上のご参加をいただき、内容的にもご満足いただけたようでした。特に協和発酵の中山嘉之さんの「協和発酵におけるモデリング20年とこれから」はDOA20年で数十億円の価値を生んだとするもの、事実の説得力が印象的でした。
■データモデルは統一しない
さて今月は「データモデルの統一」について述べます。DOA+コンソーシアム1周年記念セミナーでお話したことです。結論は「データモデルは、簡単な条件付ですが、今は統一しない」と言うものです。OOでは3アミーゴがUML表記について統一することになったため、その普及が進みました。これに倣って、DOA+コンソーシアムも「モデルを統一して欲しい」といった期待がありましたが、「その時機でない」と判断しました。


第1の理由は、まだ「データモデルは如何にあるべきか」が議論できていないためです。データモデル第1分科会は5回開きましたが、T字形、TH、Xprime(Xupperのデータモデル)、3要素分析法(渡辺幸三方式)の4件について紹介があり、特徴がおおよそつかめただけの段階です。第2の理由は、「それぞれ特徴があり、ファンがいてビジネスとして成り立っている」、すなわち、ねらっている目的を達成しているということです。
データモデルは、データについてコミュニケーションを行うための一種の図面言語です。言語はトレーニングを通じて身につけなければ使い物になりません。たとえ英語が日本語より優れているとしても、にわかに英語に切り替えることができないように、データモデルも切り替えるのは簡単ではありません。
■データモデルの違いの由来
違いは、目的としている課題のコンテキストや捉え方からきているように思われます。「今与えられた領域のデータベースを設計しよう」とするのか、「レガシーやパッケージの混在する全社、あるいは関連会社を含めたシステム/DBの中にどう位置づけて、その設計や保守を考えよう」とするのかによって、データモデルに対するニーズが違ってきます。前者の場合は、同じIT環境それもRDBだったりすると、論理モデルが目標になります。一方後者ですと、ヘテロなIT環境が前提となり、IT独立の概念モデルを目標とし、実装(論理モデルや物理モデル)との関係は別途考慮すべきものとなります。
多くの場合、前者はSIerの、また後者はユーザ企業のニーズを代表するものかと思われます。傾向として、前者は短期にローカルな問題を解決しようとしますし、後者はシステムライフサイクルなど長期にグローバルな問題を解決しようとします。従って、語弊を覚悟して簡単にいうと、「自動車があるから、オートバイは要らないとは言えない」というような状況のように思われます。
■ハイレベルコミュニケーションの問題
しかし企業内には、現にいろいろなデータモデルをベースに開発された、たくさんのアプリケーションシステムがあり、相互にコミュニケーションが行われています。いまアプリケーション内の問題をロウレベル、アプリケーション間の問題をハイレベルというならば(DRI通信93号参照)、ロウレベルは同じデータモデルなので問題は少ないのでしょうが、ハイレベルでは、異なったデータモデルに基づくデータ−ハイレベルメッセージ/ハイレベルトランザクション−が対象となるため、そこでのコミュニケーション/データ流通が正しく行われることをいかに保証するか、大きな問題が残されます。
正しいコミュニケーションの前提は、意味が通じることです。桁数や値の違いは、変換で解決できます。そこでわれわれは、完璧かどうかの証明はできていませんが、概念レベルのハイレベルメタ構造において、次のような3つの条件、?参照制約、?ドメイン制約、?複合データ制約を設定するものとしました。?は参照KEYについての制約で、たとえば、「受注エンティティにおける受注顧客コードは、どのモデルでも同様に、リソース系の取引先コードと対応すべき」というものです。?は非参照KEYについての制約で、たとえば「受注金額は、どのモデルでも同様に、金額ドメインの形式を持つべき」というものです。?は複合データに対する制約で、たとえば「商品のKEYは、どのモデルでも同様に、[品目コード.荷姿コード]の構造を持つべき」というものです。
したがって、「各アプリケーションシステムが生成するハイレベルメッセージは、この制約に準拠したものとして生成しましょう」と提案することにしました。これはDOA+の中だけの問題ではありません。ひろくOOの方々にも訴えていこうということになりました。堀内一教授(東京国際大学)によると、これはISO/IEC JTCI SC32の「メタモデル相互運用枠組み標準化」の発想と同じであるとのことでした。
■ハイレベルDOA
このような制約は、ハイレベルメッセージを構成する属性の調整/標準化によって満たされることになります。このためハイレベルメッセージを素材にデータモデリング−これはハイレベルDOAと呼ぶことができるでしょう−を行って、共用リソースを識別し、そのメタデータをハイレベルリポジトリに定義することになります。アプリケーション横断でない個別のリソースデータを、ここに定義してもかまいませんが、個別アプリケーションに任せてもかまいません。したがってパッケージなどの場合は、ロウレベルのデータはすべてパッケージに任せることになるでしょう。
■Divide and Conquerの論理
この方針の基本は、データモデルの適用をロウレベルとハイレベルの二つに分けたところにあります。いわば国内問題と国際問題は分け、国内問題は過去のしがらみや独自の文化があるから、それぞれにまかせ、しかし国際間の通商などにはルールを作り守りましょう、という発想に近いかと思われます。アメリカ流で全て押し通すのでなく、ローマ帝国のDivide and Conquerで行こうというわけです。
しかし、「データモデルは統一しない」ということになると、初心の方はどれを選択すべきか、また初心でなくても今後の開発にどれを採用すべきかなどに、不便を感ずることになるかと思われます。そこでこれに応えるために、DOA+コンソーシアムとしては、第1分科会を中心に、「データモデルへの要件や、それぞれのデータモデルの特徴を明らかにするための活動をしよう」と言うことにいたしました。有志の方のご協力を期待します。