» 【148号】 リポジトリ構造の設計条件

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【148号】 リポジトリ構造の設計条件

■メタデータ
「メタデータ」のメタは超越といった意味のようですが、日本語に言い換えて
も抽象的で、いまひとつ分かりにくい。

かつてのアメリカの標準化団体IRDSは、ユーザが見る
 [1]-(椿正明、男、73、フェロー、・・)
 [15]-(黒澤基博、男、48、社長、・・)
などをレベル1のデータと言い、これを抽象化して得られる
 [データ総研社員#]-(氏名、性別、年齢、役職、・・)
を、レベル2のデータ「メタデータ」と言っています。
ほかに
 [品#]-(品名、メーカ#、単価、重量、・・)
 [受注#]-(顧客#、品#、数量、納期、・・)
などもレベル2のメタデータとなります。レベル2のデータはレベル1のデー
タの枠組みを決めており、アプリケーションプログラムは、このレベル2のデー
タに基づいてレベル1のデータを処理することになります。
レベル2のデータはレベル1のデータの抽象化によって得られるので、レベル
1データの適切なサンプルIOの選択と個人差なく抽象化を進める方法が重要
になります。

■メタメタデータ
メタデータをさらに抽象化した、IRDSのレベル3のデータをメタメタデー
タといいますが、それは
 [属性#]-(属性名、所属エンティティタイプ#、所属定義域#、・・)
 [エンティティタイプ#]-(エンティティタイプ名、所属概念DBタイプ
#、・・)
などで、レベル2のデータの枠組みを決めるものです。システム設計・開発・
運用にかかわる人やシステムは、このレベル3のデータに基づいてレベル2の
データを処理します。
レベル3のデータは、レベル2のデータの抽象化によって得られるので、レベ
ル2データのIOサンプル?すなわちデータモデル図や業務フロー図など?の
選択が重要となります。
このレベル2のメタデータは、かつては紙、WORD、EXCELなどに記録
されていましたが、今やDB形式に記録されるようになり、そのDBはリポジ
トリと呼ばれるようになって来ました。

■リポジトリ構造の問題
リポジトリはシステム設計・開発・運用という、特種ですがひとつのアプリケー
ションにかかわるDBですから、その構造/レベル3データは、システム関係
者がメタデータを共有するためのハブ通信場として致命的に重要です。標準化
団体、リポジトリベンダーをはじめ多くの提案はあるのですが、そのあるべき
構造について、いまだに決定版がありません。その理由は次のようなものかと
思われます。
・設計素材が明示されておらず、設計者のKH/思い込みで設計される
・実装独立と実装従属が混在し、ITの多様化の影響をうける
・当面のリポジトリ製品の実装を目的とするため、対象とするメタデータの範囲
 が狭い。このためこれを、たとえば孤島ではなく全社へ、あるいはデータだけ
 でなくこれと整合の取れたプロセスを含めてなどと、拡張するとき手戻りが
 発生する
一方、「リポジトリを制するものがシステムを制する」など、重要性は認識さ
れつつあり、今話題のSOAのためのESBにおいても、ラッピングのための
リポジトリなど、常に話題が登場します。しかしまだベンダーごとの場当たり
的解決であり、今後もITの変化による紆余曲折の無駄な作業の発生が予想さ
れます。

■リポジトリ構造の設計条件
リポジトリ構造の設計条件として、筆者は次の条件を提案したいと考えます。
 (1)システム設計・開発・運用において扱うドキュメントを素材として、
 データモデリングを行い、リポジトリ構造を確定する。
 (2)リポジトリを、BM(Business Model)リポジトリ、SW(Software)
 リポジトリ、PF(Platform)リポジトリに分割して設計する(注1)。
 (3)フェデレーション・アーキテクチャ、すなわち全社システムはローレベル
 (個別アプリケーション)とこれを連携するハイレベル(アプリケーション横断)
 から構成され、アプリ間で共用されるべきリソースおよびイベントデータは後者に
 ストアされるべきとする。
(注1)
イメージを説明するために、これらのリポジトリの主なコンポーネント(エン
ティティタイプ)を挙げると、次のようになります。
BMリポジトリ:概念DBタイプ、エンティティタイプ、属性、業務ドメイン、
システム、業務プロセス、IO、論理組織、ユーザなど
SWリポジトリ:物理DB、物理ファイル、物理データ項目、データセット、
プログラム、モジュール、物理IOなど
PFリポジトリ:ユーザインターフェース、プロセッサー、ストレージ、回線、
など
(1)は、「リポジトリ構造とシステム設計・開発・運用は独立でない」、
あるいは「システム設計・開発・運用を規定しないでリポジトリ構造は決まら
ない」という主張です。方法論、したがってそこにどのようなドキュメント
(注2)が作られ、どのようなメタデータが扱われるかが決まってはじめて、
リポジトリ構造が決まってくるという考えです(注3)。
(2)は、ビジネスの変化による影響と、ITの変化による影響を分離して、
保守を容易にしようということです。ビジネスモデルを確定し、これをIT空
間にマッピングしたものがシステムとなるはず。したがって、初めはビジネス・
デザイナーがビジネスの設計を行って、人とIO(構成するデータを含める)
と実行順序を規定し、これをビジネスモデルとしてBMリポジトリに記述する。
次にソフトウエア・デザイナーが、これを要件定義として取り出し、PFリポ
ジトリの制約に基づいて、ソフトウエアの設計に入ろうということです。
(3)は、リポジトリのスコープは少なくとも全社をカバーすべきで、個別
アプリを全社に拡張するとき破綻するリポジトリでは困る、というものです。
孤島システムの発生を未然に防ごう、また今ある孤島を仮想化してつなぎつつ、
徐々に解消していこうということです。個々のアプリケーションはひとつの文
化圏を作っており、変更もその中で解決できるものが多いので、これを活かす
のが得策だと考えます。
(注2)われわれはPLAN?DB基本4ドキュメント、すなわちIPFチャー
ト、IO定義書、DB構造図、データ定義書によって、ビジネスモデルが規定
できる、したがってBMリポジトリの構造が決まる、と考えています。ただし
SWリポジトリやPFリポジトリの確定は今後の課題と考えます。
(注3)「リポジトリの構造がどうあるべきかと言う議論はナンセンスである。
売れるリポジトリ、ユーザが採用するどうかで決まる問題である」という考え
方もありますが、ここではその考え方はとりません。「営業、人事、経理など
のいわゆる業務システムの設計・開発・保守に関しては、どれがベストである
かは議論しなければなりませんが、標準的な方法論があり、作るべきドキュメ
ントを決めることができる。そこで扱うデータはすべてリポジトリに存在すべ
きであり、扱わないデータはリポジトリに含める必要がない」と考えます。
「ビジネスマターではなくサイエンスマターとして考えるべき時期に来ている」
と考えるからです。
なお、メタデータやメタメタデータに関しては、DRI通信89号、94号、
95号に記述がありますので、興味のある方はご参照ください。