» 【第106号】データモデルのスコープ

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

■システムの大きさ
多くの企業で、予算を用意し、システム開発プロジェクトが企画されます。
そのときのシステムの規模はどのようにして決められるのでしょうか。30年
の昔、BSP(Business System Planning)という手法がIBMから紹介されま
した。顧客企業のDBをどう設定すべきかをガイドする、IBMのIMS販売戦
略から生まれたものと思われますが、RDBの時代になって聞かなくなりま
した。10年前、ERPの時代になって、n個のアプリケーションがシステム化
の対象となりました。しかし、かならずしも全社がカバーされるわけでもなく、
他システムとの連携のありかたや、Monolithicで柔軟性に欠けるサブシステ
ム独立性の課題にどう対処するかなど、課題は多々残されています。最近
EA(Enterprise Architecture)が話題になっていますが、システムの大きさ
について「こうあるべき」の基準は見当たりません。

結局、予算執行権を持つユーザ代表が、その見ている範囲で、システム化
を企画し、それが大きすぎるような場合は、適宜直感的に分割してシステム
の大きさが決められてきたかに見えます。システム屋はこれを受けて、シス
テム対応にDBを構築し、多くの場合、「システムの大きさ=DBの大きさ」と
なっていったようです。DBは無矛盾を前提としますので、DB設計とはデー
タ標準化でもあり、その大きさはデータの流通する文化圏を規定することに
なります。したがって、文化圏の大きさを、予算執行権を持つユーザ代表が
決めているわけですが、明確な規定は見たことがありません。
われわれは、これをそこで使われる画面・帳票(IO)で規定できるはず、
すなわち
  DB=f(IOs)
として、このIOs(IOの集合)をどう選択すべきかとして考えています。
そしてfとしてPLAN−DB手法を位置づけているわけです。ただし、DBは
実装独立の概念DB、またIOもレイアウトなど実装仕様を取り去った、どの
ようなデータが含まれるかのみから成る、いわば概念IOとします。

■DBの大きさの基準
上述のように、客観的な基準が見当たりませんので、私の基準を述べるこ
とにします。概念DBの大きさは物理DBより大きくなりますから、小さい方の
制約は物理DBによって、「DBトランザクションの処理が1DB内で完結する」
という条件から決まると考えます。これは、DBMSは2フェーズコミットという
機能を持っていますが、「原則として2フェーズコミットは使わないようにDB
の大きさを決めるべき」というものです。「もし銀行の入出金レコードと口座
レコードが別々のDBにストアされていたら、10万円引き出しても残高はし
ばらく同じまま推移する」、「これを防ぐために2フェーズコミット機能を使うの
ではたまらない、だからこれらは同じDBに収めるべき」、と考えるわけです。
すなわち「ユーザに対して約束した整合性−この場合加工データ整合性−
を保証するデータは1個のDBに収容すべき」と言うものです。
大きい方の制約は、データ標準化、文化圏の大きさの観点から、大まかな
ものになるようです。すなわち、大きすぎるとデータ管理者がすべてを理解
できず、管理の品質が保証できなくなります。生産、販売、経理、人事のデ
ータをすべて理解することは大変です。また同じ生産でも半導体生産と重
電製品生産のデータを理解することも難しい。また物理DBもこれらを一括
して作ることはしません。大きすぎると障害が必要以上の多くのユーザに及
びます。全体最適と部分最適のバランスの問題で、人間の管理能力が制
約になります。なにかヨーロッパの統合の話に似てませんか。
逆に、2フェーズコミットは不要だが、本来Aというシステムが最適なのに、
A1、A2と二つに分けてしまったらどうなるのでしょうか。たとえば販売物流
とすべきところ、販売と物流が別々にDB化されたというケースです。おそら
く別々のDBMSの管理下に関連の強いレコードが管理されますので、両者
間に煩雑なやりとりが発生し、保守や機械効率面でのマイナスが発生する
ことかと思われます。しかしこの場合は、経験的に「リソースDB(マスターデ
ータ)が標準化され、独立していれば、致命的な問題はないはず」と考えます。
すなわち業務系DBにおいては、リソースDBが独立し、かつすべての業務
DBがこれを共有するアーキテクチャとなっていれば、DBの大きさの許容
範囲は十分大きいものと考えます。

■メタDBの大きさ
ここまでは、業務系DB、すなわちアプリケーション・レベルの(概念)DBを
考えてきましたが、メタDB、すなわちリポジトリではどうでしょう。これをアプ
リケーション・レベルと一括して、と考える人はいませんので、メタDBの中で
考えましょう。この場合つぎのような問題が浮かび上がってまいります。
 ・概念メタ、物理メタ(ソフト)、ハードメタ、の関係
 ・概念メタ全体、データメタ全体、モデル図(図と矢線だけ)メタ、の関係
1990年代半ばまでCASEツールが使われ、リポジトリがそのメタデータを
ストアしていましたが、これは明らかに物理メタ中心で、しかし概念メタも混
在していました。CPU、ディスク、データセット、プリンター、ネットワーク、
ユーザIDなどを記述するハードメタは自動運用などに必要です。IT環境が
変化すると物理メタやハードメタは変化しますから、リポジトリ構造が揺さぶ
られます。ISOなどの標準化団体が、情報共有のため、その活動を概念メ
タにシフトしてきたのは当然かと思われますが、いろいろな案が提出され、
収束には程遠いように見えます。
これらの関係についての議論は未熟のように思われますが、私見を述べま
すと、「1個の概念メタを(メインフレーム、C/S、Webなど)環境対応のn個
の物理メタが参照する、またさらにこれらをハードメタが参照する」すなわち
  概念メタ→物理メタ→ハードメタ
という関係になるのではないかと考えます。したがって、概念メタがメタ構造
の中心課題と思われますが、これを、プロセスを除外し、データモデルだけ
から、あるいは箱と矢線のモデル図だけから、考えていいのでしょうか。これ
を決めるための素材はどうあるべきなのでしょうか。
弊社では、前述のようにDBの素材はIOであるとする原理を、システム開発
保守システムにも適用し、
  メタDB=f(メタIOs)
とします。メタIOsとしては、PLAN−DBの定める概念基本4ドキュメント−
概念DB構造図、データ定義書、IPF(Information Process Flow)チャート、
概念IO仕様−を選択、これを分析して概念メタ構造を決めるものとしていま
す。ただしこの場合、DB、システムなどこの上位のメタ部品を記述する
EXCELドキュメントも補足して考えることにします。こうして得られるメタデータ
モデルを、今、「DRIメタモデル」と呼ぶことにしましょう。
しかし、一般には、データモデルだけからのメタモデルや、さらに箱と矢線
(鳥の足を含む)だけから成るデータモデル図を分析したメタモデルが提案
されています。これらを、それぞれ「データメタモデル」、「パネルメタモデル」
と呼ぶことにします。
これらは一体、相互に整合性が取れるのでしょうか。すなわち、「素材をモデ
ル図から概念メタ全体に増やしていったとき、データモデルの拡張性には問
題が発生しないか」です。これはまだ十分議論されてこなかった課題のよう
にと思われます。

■パネルメタモデルの問題
箱と矢線だけから成るモデル図を分析すると、必然的にエンティティと関連の
メタ部品が識別されます。エンティティとエンティティの間には多重の関連が
あります。たとえば、人と車には、所有者の関連と(主)運転者の関連があり
えます。すなわち
   エンティティ    関連
   [人]        [人.車.所有]
   [車]        [人.車.運転]
がメタ部品として登録されます。
これを、箱と矢線だけでなく属性を含むメタモデルで考えます。たとえばTH
モデルでは
   エンティティ    属性
   [人]        [人#]     −(KEY、・・)
   [車]        [車#]     −(KEY、・・)
              [車所有者#]−(参照KEY、・・)
              [車運転者#]−(参照KEY、・・)
のように分析します。したがって、「DRIメタモデル」にはエンティティと属性
だけがあり、関連といったメタエンティティはありません。箱と矢線でモデリ
ングしても、属性定義は必要ですから、「パネルメタモデル」でも後工程で
属性を矢線から生成することになります。しかしこの場合は、パネルで考え
たときに発生した関連という冗長な(なくてもすむ)エンティティタイプが残り、
これによって、メタモデルに解が2つ発生し、そのユニーク性が損なわれる
のが気になります。これはどう考えるべきなのでしょうか。
人と車における所有、運転の関連について、DBMSは[車所有者#]、[車
運転者#]の2つの参照KEYの値によって、読み取ります。人もこの参照
KEYを認識します。大方のユーザはIO上の参照KEYとその値の、いわゆる
レベルペアによって、関係を理解していると思われます。
一方、矢線は、DBMSは知りません。人、それもデータモデル屋の便宜の
ために、お絵かきツールが提供しているものです。お絵かきツールとしては
オブジェクトとしてストアする必要がありますが、対応するアプリデータはない
ようです。メタデータは本来アプリデータをタイプ化するために設けられるもの
のはずです。その意味では、矢線はエンティティや属性と並ぶ、リポジトリを
構成すべきメタエンティティとしては資格が不十分のように見えます。箱の座
標と同じく、単なるお絵かきツールの作図のための情報ではないでしょうか。
この問題は、「パネルメタはデータモデリングのスコープとして不備である」
ことを暗示します。すなわち「箱と線だけではデータモデルが(中途半端にし
か)表現できない」、「属性の追加が不可欠である」と言うことです。
いま、(1)「AがBを殴った」と(2)「AがBの頭を殴った」を比較します。
(1)は身体の部位を表す用語がないときの表現です。(2)があれば、(1)は冗
長です。最終的に身体の部位まで表現する必要があるとした場合、(1)はワ
ークドキュメントとしての意義はありますが、最終的に(2)が記録されれば、
削除すべきものになると思われます。2つのアプリがあって、片や関連/
Associationを用いるモデル、片や参照KEYを用いるモデルによって開発さ
れたものであった場合、その間のデータのやり取りはどうなるのでしょうか。
実際ほとんどのケース、(関連/Associationを持ち出すことなく)属性と属性
値によって行われているものと思われます。したがって、私には、パネルメ
タは(1)に相当する表現のように思われるのです。
これまで、標準化団体はこの関連/Associationをメタモデル構築の基本部
品としてきたように見えます。しかし情報を扱う場合、属性と属性値のペアは
基本ですから、常にこれに立ち戻って、「関連/Associationは参照KEYで表\n現する」ルールの設定を検討してほしいと思います。これによって、メタモデル
の不必要な代案の発生を抑えることは、標準化の趣旨にも沿ったものになる
かと思います。私には、カーディナリティや整合性の条件なども、矢線ではな
く、参照KEYの性質として規定する方が素直ではないかと考えます。

■まとめ
「データモデルをどのような範囲について、どのような素材から作るべきか」
は非常に大切なことと考えますが、従来はあまり考えてこなかったかに思わ
れます。業務アプリケーションの世界ではリソースDBを確立し共用すること
が解決になりますが、この認識不足から孤島システムがたくさん作られてい
ます。メタモデルの世界では、パネルメタだけでモデリングを行って、関連/
Associationという冗長エンティティタイプを作り、余分な複雑さを招いている
ように思われます。またツールの要請で、「参照KEYを生成するために、矢
線を書く、そのために各アプリケーションのデータモデル図にリソースエン
ティティの箱を書く」結果となり、「リソースは共有資源」の認識を損なわせ、
孤島システム発生を助長しているようにも見えます。
まだ議論する相手の少ない領域なので、独断で書いている部分があります。
しかし重要なテーマと考えます。皆さんからのご意見を期待します。