» 【第94号】メタとメタメタ

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

DRI通信94号「メタとメタメタ」       2004.7.1
第1四半期が終わり、梅雨の後半戦になりますが、今年も厳しいですね。
DOA+コンソーシアムでは、6月28日、五反田ゆうぽーとで、はじめての試み、初心者向け講座を開催しました。講師は堀越(データ総研)、真野(CAC)、本村(ケンシステムコンサルティング)。無料ということもあってか、140名ほどの参加をいただきました。プレゼンは今までの技術を棚卸しし整理するもので、初心者というより中級者向けでしたが、参加者層とほぼマッチしていたようで、例外はあるものの好評でした。また6月22日には、アルゴシステム創研の勝藤さまより「Hybrid型開発技法B-DM」の紹介がありました。「上流はDOAで下流はOOで」という意味のHybridということですが、プログラミングのパラダイムを上流に持ち込むのは無理との判断からのようでした。
■ メタとメタメタ
この話題、抽象的で苦手と言う人もあるかと思います。しかし情報システムの設計にかかわる人にとって避けて通れない概念ですし、落ち着いて考えればそんなに難しいものではありません。まずこれから考える対象を次のように、分類コードをつけて、整理しておきます。
          サーバー側(S)      クライアント側(C)
概念データ(DC) 概念DBデータ(D*CS) 概念画面・帳票(D*CC)
物理データ(DP) 物理DBデータ(D*PS) 物理画面・帳票(D*PC)
ここで画面・帳票を概念と物理に分けることに違和感を持たれる方があるかと思われます。われわれはしかし、ビジネスユーザの情報要求の本質は概念画面・帳票として把握でき、操作性などに関わる要件は、むしろシステムユーザ/オペレータのための二次的なもの(大事でないと言う意味ではなくIT環境などによる変化に対応すべきと言う意味)として分離し、物理画面・帳票として捉えます。なお、サーバー側とは原料となるデータをストックするDB側、クライアント側とは製品となる画面・帳票を扱うユーザ側という意味で、特定のIT環境を想定したものではありません。
以上、データだけを4種類に分けましたが、データにはこれを生成するプロセスが4種類それぞれ対応付けられます。以下これらについてメタとメタメタを考察することになります。


■ メタデータ
辞書によると、meta-について、[超越]とか[一段と高い階型の]とあります。
THモデル方式で書いた顧客に関するつぎのデータ(顧客レコードの個体)
[121]−(林進、男、東京)
[135]−(山田彦左衛門、男、神奈川)
のメタデータ(顧客レコードの形式)は
[顧客番号]−(顧客氏名、性別、顧客住所)・・・・・・・・・・D1CS1(注)
のように書けます。すなわち具体的なデータを抽象化して型として書いたものです。プログラムはこの型を前提に作り、林さんのデータも、山田さんのデータも同様に処理することができます。このためレコードを構成するデータ項目の集合および各データ項目の桁数や型をあらかじめ標準化しておきます。
(注)形式を4桁の分類コード+枝番で示します。分類コードはつぎのとおり。
   1桁目、D:データ、P:プロセス
   2  、1:メタ、2:メタメタ
   3  、C:概念、P:物理
   4  、S:サーバー側(DB)、C:クライアント側(画面・帳票)
 なおこれをコンポーネント種別コードと呼びたいのですが、いかがでしょう。
■ メタメタデータ
いまつぎの3つのメタデータ(D1CS1)を考えて見ます。
[顧客番号]−(顧客氏名、性別、顧客住所)
[品番]−(品名、単価)
[受注番号]−(顧客番号、受注品番、数量、受注単価、金額、納期、受注日)
これらは似ています。だから抽象化して型にはめることができるはずです。すなわち
[エンティティ番号]−(属性1、属性2、・・、属性n)
の形ですから、親子に分けて、
[エンティティ・タイプ番号]−(エンティティ・タイプ名)・・・D2CS1
[属性番号]−(属性名、所属エンティティ・タイプ番号)・・・・D2CS2
となります。これがメタメタデータ(の骨格)です。われわれは、さらに
・ エンティティ・タイプは、リソースやイベントに分類できる
・ エンティティ・タイプは、リソース、販売、生産などのあるDBタイプに所属する
・ 属性はKEYかどうか、参照KEYかどうか、ある種の加工データかどうか分類できる
・ 属性はどのような定義域をもつか
などを考慮して
[エンティティ・タイプ番号]−(エンティティ・タイプ名、エンティティ・タイプ類型、所属DBタイプ、・・)・・・・・・・・・・・・・・・・・・・・D2CS1
[属性番号]−(属性名、所属エンティティ・タイプ番号、データ機能コード、定義域番号、・・)・・・・・・・・・・・・・・・・・・・・・・・・・・D2CS2
のように、メタメタデータを充実させます。これがリポジトリの構造ということになります。
さきのメタデータは、顧客だの、受注だの「業務アプリケーションのにおい」のぷんぷんするものだったのですが、メタメタデータは抽象化によって全く「業務アプリケーションのにおい」を消し去ったものとなっています。その数もメタデータは、大会社ですと、しっかり整理しても属性レベルで5万点を超えますが、メタメタデータは500以下に抑えることができると思われます。しかもメタメタデータは企業横断に共通化することができます。
■ 画面・帳票のデータ
ここまではサーバー側の概念データベースにおける、メタデータとメタメタデータを考察しましたが、こんどはクライアント側の画面・帳票上のデータについて考察します。
メタデータについては結局、画面・帳票が冗長データ(カッコつきで示す)を含むため
[受注番号]−(顧客番号、(顧客名)、受注品番、(品名)数量、受注単価、金額、納期、受注日)・・・・・・・・・・・・・・・・・・・・・・・・・・・・D1CC1
のようになります。
また、メタメタデータについては、
[画面・帳票番号]−(画面・帳票名、画面・帳票種別、所属業務種別番号、・・)
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・D2CC1
[画面・帳票番号.行番号]−(属性番号、表示要否区分、入力要可否区分・・)
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・D2CC2
のようになります。これもリポジトリの構造になります。
■ 物理のデータ
ここまでは、概念データすなわち実装独立のデータに対して、そのメタおよびメタメタデータを考察しましたが、今度は物理すなわち実装従属のデータについて考察します。
メタデータについては、物理ファイルとしてはデータ項目が並んでいるだけですから、金額はストアしないとすると、
「受注番号、顧客番号、顧客名、受注品番、品名、数量、受注単価、納期、受注日」
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・D1PS1
のように書けます。
画面・帳票については、金額表示があるでしょうから、
「受注番号、顧客番号、顧客名、受注品番、品名、数量、受注単価、金額、納期、受注日」
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・D1PC1
のようになるでしょう。
メタメタデータについては、物理ファイルは、
[物理ファイル番号]−(所属DB番号、レコード件数、・・)・・・D2PS1
[物理ファイル番号.行番号]−(属性番号、スタート位置、桁数、ソートレベル、
ソート方向、インデックス種別、・・)・・・・・・・・・・・・・・D2PS2
また、物理画面・帳票は
[物理画面・帳票番号]−(媒体コード、形式コード、表示位置、・・)
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・D2PC1
[物理画面・帳票番号.行番号]−(属性番号、表示位置、桁数、データタイプ、入力形式、入力支援コード、支援データ、・・)・・・・・・・・・・・・・D2PC2
のように書けるでしょう。
■ 生成プロセス
これまでは、データについてだけ、その概念・物理に関し、メタ、メタメタの形式を書きました。データに関しては必ずこれを生成するプロセス(メタプロセス、メタメタプロセス)が1個はあるはずです。生成するプロセスですから、サーバー側(DB)には入力系、クライアント側(画面・帳票)には出力系のプロセスを対応付けます。
D1CS1の顧客データ、品番データ、受注データについて考えます。この生成プロセスP1CS1は、一般に、「顧客登録」、「品番登録」、「受注登録(または受注入力)」などと呼ばれています。
D1CC1、すなわち上記の画面・帳票上への表示プロセスP1CC1は、「顧客データ表示」、「品番データ表示」、「受注データ表示」となります。
D1PS1は受注データなどの物理メタデータでした。これらの生成プロセスP1PS1は「受注データAdd to ORACLE」のように呼べるでしょう。
D1PC1は受注データなどの画面・帳票メタデータでした。これらの生成プロセスP1PC1は「受注データ表示to XP in HTML」のように呼べるでしょう。
以上メタデータについて述べましたが、メタメタデータもほぼ同様です。対応は1桁目をDに変えるだけですから、プロセスのみについて書きます。
P2CS1:エンティティ・タイプ登録/削除/変更
P2CS2:属性登録/削除/変更
P2CC1:画面・帳票表示/削除/スイッチ/・・
P2CC2:画面・帳票データ表示/入力支援/・・
P2PS1:物理レコード登録/削除/変更 to ORACLE
P2PS2:物理データ登録/削除/変更to ORACLE
P2PC1:物理画面・帳票表示/削除/スイッチ/・・to XP in HTML
P2PC2:物理画面・帳票データ表示/入力支援/・・to XP in HTML
■ メタメタに対するオブジェクト指向の適用
このほか「業務アプリケーションのにおい」のしないメタメタのデータとして、データセットや物理レコード(ページ)、またプロセスとしてJob、Task、Threadなどもあります。オブジェクト指向はGUIなどの、やはり「業務アプリケーションのにおい」のしない領域で大成功したと言われますが、どうもメタメタデータとメタメタプロセスを対応付けて考えるとき、非常に有効のように見えます。
しかしメタデータの世界に適用するのはどうでしょうか。属性は1企業に5千件から5万件あります。属性は企業が違えば、重なるものもありますが、範囲や粒度が違うためもあって、違うものが多々あります。いろいろなビジネス、企業がありますから、全企業の属性を集めたら、しっかり整理しても100万件からあるのではないでしょうか。属性の標準化はDOAの領域かと思われますが、これすらなかなかできていないのに、この組み合わせを含むオブジェクトを標準化し、再利用しようという試みは果たして正解なのでしょうか。
すなわちOOによるデータとプロセスの対応付けに
 a.メタデータ←→メタプロセス
 b.メタデータ→メタメタデータ←→メタメタプロセス
の方法があるかと思われますが、「業務アプリケーションのにおい」のするメタレベルでのaは収拾が難しい。DOAでメタデータ(メタメタデータに関するコンテンツ)を整備し(ただし一部の加工データを除く)、メタメタレベルでプロセスと対応付けるbの方が現実的ではないでしょうか。もちろんこの場合、正しいメタメタデータの設計が前提になります。