» 【第89号】メタデータ扱いの進化

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

DRI通信89号「メタデータ扱いの進化」  2004.2.2
本格的な冬を迎えていますが、いかがお過ごしですか。
さる1月20日、50名の出席者を迎えDOA+コンソーシアム分科会をスタートしました。初回で「各種DOA方法論の特徴・相互関係を理解するためにどのように議論を進めるべきか」がテーマでしたが、私の資料がややPLAN−DBの中身の見えすぎるものだったためか、議論を呼びました。しかし今後出てきそうな議論の片鱗が見えたので、対策を講ずると言う意味ではかえってよかったのかも知れません。参加の皆様から期待と貢献を伺いましたが、非常に熱心で今後の展開が楽しみです。
また、1月27日は35名の参加により、K2W勉強会(第15回)を行いました。ブレイズコンサルティングの鈴木秀美さまから「戦略経営とIT戦略の整合の重要性−エンタープライズ・アーキテクチャ」のプレゼンを頂いた後、「EAへの取り組み」として小島薫さま(BIT)、羽生田栄一さま(豆蔵)、萩原正義さま(MS)、真野正さま(CAC)、黒澤基博(DRI)によるパネル討論を行いました。足掛け4年続けかなりフランクな話ができるようになりましたが、DOA+に注力することもあって、これをもって第1期は終了とすることにいたしました。ご協力の皆様大変ありがとうございました。
■ メタデータ
「メタデータとは、データのデータである」などと説明されています。これは定義として不十分ですが、たとえば社員レコード
[1] −(椿正明、男、68、会長)
[2] −(竹下茂、男、62、専務)

 [社員番号]−(社員氏名、性別、年齢、役職)
として捉えるときの、社員番号、社員氏名、性別などである、と言えばおおむね理解していただけるでしょう。


一種の抽象化ですが、「データ総研の男性社員」といった、エンティティ分類における抽象化とは別の、実務をデータに写像した後の抽象化です。社員が100人いても1000人いてもこれを捉えることのできる枠組み/「パターン」/「フレームワーク」であり、「データモデル」の内容でもあります。その意味では、プログラムも同様の「パターン」/「フレームワーク」であり、「処理モデル」です。
したがって、このような場合、「モデル=メタデータで記述されるフレームワーク」ということができます。
■ メタメタデータ
社員について
[社員番号]−(社員氏名、性別、年齢、役職)
のように、そのメタデータを捉えましたが、顧客については
 [顧客番号]−(顧客名、法人個人区分、電話番号、所在地)
また受注については
 [受注番号]−(顧客番号、品番、数量、金額、納期、届先、担当社員番号)
などと捉えることができます。
これらのメタデータを捉えるフレームワークとして、
 [属性番号]−(属性名、所属エンティティ、属性区分、属性値区分、桁数)
 ただし、属性区分:KEY、RKEY、加工データなどの別
     属性値区分:コード、テキスト、数量などの別
などを規定することができます。これはメタデータについてのメタデータということで、メタメタデータと言うことがあります。メタメタデータは、メタデータの構造を明示するものということができます。OO(オブジェクト指向)でもモデル化を重視していますから、そのメタモデルの明示が待たれます。
さてここで、われわれのメタデータ扱いの進化について考察してみます。
■ ディレクトリ
COBOLのCOPYLIBと言う考え方もありますが、やはりDBMSのディレクトリを第1世代のメタデータと言うことができるでしょう。これによってプログラムはWHEREでなくWHATを意識してDBにアクセスすることができるようになりました。
■DD/D
しかし、ディレクトリはまだ当該DBに関わるSEやDBAのツールであり、各DB横断にデータを管理すべきDAには不満の残るものでした。そこでメタデータを一括管理できる第2世代のメタデータツールDD/D(Data Dictionary / Directory)が登場しました。
■ソフトウエアリポジトリ
DD/Dは、レコード形式や属性などディレクトリ生成に関わるデータ系のものからスタートしたわけですが、すぐにこれと関係するプログラムやJCLなどプロセス系のものにも拡張されていきました。第3世代のメタデータツールで、その代表がDATAMANAGERだったと言えるでしょう。
■ 3層リポジトリ
第3世代のリポジトリは、データ系と同時にプロセス系の部品を扱いましたが、実装従属のソフトウエア部品を管理するものでした。規模が小さく、ハード・ソフト環境が比較的均質な場合はこれでよかったわけですが、メインフレーム・C/S・Web、各種レガシー・ERP・新規、自社・サプライヤー・顧客などがからみ、規模が拡大し、異なったハード・ソフト環境での同じ意味のデータの流通が要請されてくると、これでは間に合わなくなってまいりました。実装独立レベル、ソフトレベル、ハードレベルと3つに分離した第4世代のリポジトリが必要になってきたわけです。
すなわち同じデータか否かやその整合性は、実装独立にセマンティックスを考えて検討しなければなりませんし、具体的なデータの授受には個別の実装環境に合わせた変換が必要になってくるからです。
たとえば、A社でもB社でも「取引先」と呼んでいるが、A社は顧客中心、B社はサプライヤー中心、またA社の場合は支店や営業所など小さい粒度のものまでが含まれ、B社では法人レベルで粒度が大きい、などということがよくあります。逆にC社の「相手先」がA社の「取引先」と近いなど、言葉が違っても同じ意味ということがあります。したがって用語/属性名称については、セマンティックスを合わせるためのきちんとした実装独立レベルの定義が必要になります。そして受発注などのイベントで使われる顧客、届先などが、これらのどれを参照しているかをはっきりさせなければなりません。
残念ながら、しかしこのようなツールの商品化はまだのようです。ひとつにはこれを使いこなせるユーザが育っていない。またこのため、ベンダーが消極的になっていて、これを作れるだけの研究をしていない。特に実装独立のメタデータと実装従属のメタデータをスムーズに繋ぐ−できればプログラムレスを実現する−技術が完成していないことが大きい。ベンダーはERPや中国・インドなどによる合理化を進めていますが、これは当面の間に合せで、変化の激しい、大規模・ヘテロなシステムの抱える問題への真の解決策にはならないのではないかと心配になります。
■多重リポジトリ
第4世代が解決できていないので、第5世代を論ずるのは時期尚早ともいえますが、メタデータの全世界一元化が不可能な限り、ここで述べる外部変換機能を持つ多重リポジトリが、第5世代リポジトリとしての必然の課題かと思われます。
リソースデータ(コード)は情報システムで用いる用語を決めていますので、これを共用するシステムごとにひとつの文化圏ができます。この大きさは1企業と重なる場合が多いでしょうが、大会社では1事業に、また逆に企業群や業界に拡大される場合もあるでしょう。この文化圏の中ではシームレスなデータの流通が可能となりますが、これを横断するときはメタデータの形式と値の変換が必要になります。n個の文化圏がからむときは、これを統一する文化圏を設定し、各文化圏はこれとの変換を考えなければなりません。このような複数文化圏を繋ぐ柔軟な多重リポジトリのアーキテクチャを想定しておくことは第4世代のメタデータツールを考える場合にも有効かと思われます。
以上メタデータ扱いの進化を述べましたが、先回のSAMMにならって、これをMRMM(Metadata Repository Maturity Model)と言うのはどうでしょう。