» 【第34号】レイヤードアプローチ

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

DRI通信34号「レイヤードアプローチ」  1999.7.1
予定していたコンサル案件が、蜃気楼のように消えたり、延びたりして、今期
も前途多難ですが、皆様のビジネスはいかがですか。
第3回七夕会は、案内後3日でほぼ満杯になり、お断りする方も出て大変申し
訳ありませんでした。費用の関係で場所が限られるためと、ご勘弁願います。
前回は3種の「データのからみ」を述べましたが、「大体同意できるが」と
いったレスポンスをいただきました。この3種は、Coddの言うData
Integrityの
延長線上のものと考えられますので、私はこれを
 ・EI:Entity Integrity
 ・RI:Referential Integrity
 ・DI:Derivation Integrity
のように呼びたいと思いますがいかがでしょうか。


■通信やプラント設計では
さて今回は情報システム開発の「レイヤードアプローチ」について考えて見た
いと思います。通信ではかつて7レイヤーなどが華々しく議論されましたが、
その技術が結局ARPANETを経て今日のインターネットを実現したものと思わ
れます。それは、設計変数をその観点に基づいて各レイヤーに割り付け、順次
設計をすすめる、また標準化もそのレイヤーに基づいて順次行うアプローチと
言えるでしょう。
私はかつて化学工学技術者として、プラント設計に携わっていましたが、そこ
には次のようなレイヤーが確立されていました。
(1)物質収支計算
(2)熱収支計算
(3)性能設計
(4)機構設計
(5)強度設計
原則として(1)、(2)はプラント全体を対象にし、(3)、(4)、(5)
は個別装置/機械を対象に行われます。また一般に(1)−(3)を化工屋が、
(4)、(5)を機械屋が担当いたします。
(1)、(2)は所定の製品を製造する、すなわちユーザ要件をベースに設計
するわけですが、これを先行することによって、各装置/機械の入力・出力の
組成や温度・圧力が固定されます。したがって(3)以降の各装置/機械の設
計は独立して並行的に設計することができます。
すなわち初めにユーザ要件をベースに全体システムを設計し、「各要素のイン
ターフェースを確定」し、次に各要素の設計を行う。これによって大きく複雑
な問題を分割し単純化して扱うことができます。これはどのようなシステムに
も適用できる普遍的原理――今やORの古典となったBellmanの
DP:Dynamic Programming(1957)の原理――です。私はプラント設計を通じて、
DPを持ち出すまでもなく、自然に、空気のように、この原理をあたりまえ
のことと考えていました。
■情報システムでは
そのためプラント設計さらに建設へのコンピュータ適用の仕事を始めたとき、
非常な矛盾・問題を感じました。(1)−(5)の設計、つづく調達、工事設
計、工事管理に至る−−今ではバリューチェーンなどと呼ばれる−−各コンピ
ュータシステムがばらばらに作られ、データが機械的には連携できなかったか
らです。まるでジャンクヤードから装置/機械を拾ってきて繋いでプラントを
作るようなやりかたに見えたのです。全体システムの設計を先行させ、まずイ
ンターフェースを確定しなければ、どこかで必ず行き詰まる、と考えました。
■データとプロセスを分ける
これはプラント建設の基幹業務についてですが、これを人事・経理などを含め
た企業全体に広げても同じことと考えました。インターフェースはデータから
構成されますから、初めにそのデータを確定させる方式、すなわち企業全体に
おいてもDOAが正解と考えました。データのためにプロセスがある、データ
を作らないプロセスは検討する意味がない。データとプロセスの関係は目的と
手段の関係、ということでレイヤーを分けることになります。
■概念と物理で分ける
折しもDBMSが商品化されてまいりました。階層型、ネットワーク型、箱型
の議論があり、これを調停するERモデルなど実装独立の意味論モデルが登場
しました。私も同じ時期にTHモデルを発表しましたが、これはデータ設計の
中に実装独立(概念)と実装従属(物理)の2つのレイヤーを設けるものでした。
各々の観点は
 ・実装独立(概念):ユーザの情報要求への対応
 ・実装従属(物理):コンピュータなどによる最適実現方式
のように異なり、これらの分離は客観的に可能であり、かつ変化の要因が、前
者はビジネス環境の変化、後者はITの変化であって、そのメリットも大きい。
そこでデータベース設計の工程が
 ・概念データベース設計(データモデリング)
 ・物理データベース設計
に分かれることになります。
■リソースとイベントを分ける
概念データベースには、購買、生産、受注、出荷、請求など業務分野ごとの変
化の多いデータ(イベントデータ)が含まれますが、同時に、部署、社員、顧
客、商品、勘定科目など共用性の高い安定したデータ(リソースデータ)が含
まれています。リソースデータはイベントデータの中で参照されますので、こ
れもレイヤーとして分離し、できればリソースデータを事前に用意すると概念
データベース設計がスムーズに展開できます。
■データベースのタイプとオカレンスを分ける
DBMSが初めに登場したときは、メインフレームの時代であり、データベー
スも物理的に1企業に1個存在するかのような認識が多かったようです。その
後分散システムの時代となり、しかもUNIX、NTなどプラットフォームも
多様化してきて、データベースが分野ごとに、また地域や工場、プロジェクト
ごとに作られるようになってまいりました。
そこで対象範囲を、主としてデータを共用するユーザの集団ごとにどう設定す
るかが設計ファクターとして登場してきたわけです。この対象範囲−−我々は
これをデータベースオカレンスと呼んでいる−−はユーザの意識するもの、
すなわちユーザに見えなければならないものであり、かつ物理データベース設
計に先立つものであるため、やはり概念データベース設計の中のひとつのレイ
ヤーとして分離する必要があります。これを物理データベースで代用し、ビ
ジネスユーザにITを意識させていたのが今までのやり方です。
■情報システム設計での5レイヤー
こうして情報システム設計におけるレイヤーは次のような5レイヤーに分離さ
れることになります。
(1)データ設計 概念データベース設計 リソース系設計
(2)イベント系設計
(3)データベースオカレンス設計
(4)物理データベース設計
(5)プロセス設計
このようなレイヤードアプローチによって、設計や保守が大幅に単純化されま
すが、実際にはDOAを標榜するプロジェクトにおいてさえ、きわめて不完全
にしか実施されていません。「要は動くソフトを早く作れば良い」として(1)
−(4)をだんごにして行ってしまうことが少なくありません。小ぶりの個別
アプリケーションはこれでやれても、ちょっと大きさの限界を超えると、大き
なトラブルの原因になっているように思われます。
その理由としては、次のようなものが挙げられます。
 ・技法を知らない、理解していない
 ・小ぶりの個別アプリケーションがターゲット
 ・ツールの設計がそうなっていない
 ・データ資源再利用の文化ができていない
■ツールの設計コンセプトに問題
ツールのうち、私は特に「DBMS」について触れておきたいと思います。R
DBMSにおいては、正規化したファイルが定義できますし、ビューの機能が
提供されていますが、それはユーザがそのように使うことが出来るだけです。
RDBMSとして実現しているのは物理モデルであって概念モデルではありま
せん。冗長項目はそのまま見えますし、概念モデルが不変でもスタースキーマ
にすればDDL定義は変更しなければなりません。
このためユーザは概念モデル上で処理ロジック考えることをあきらめ、物理モ
デル上でしか考えなくなります。ITを意識する分ビジネスユーザにとって
負担が増えますし、当初作った概念モデルをつい陳腐化させメンテナンス合
理化のチャンスを捨てることになります。極端に言うならば「RDBMSや
SQLが概念と物理のレイヤー分離を妨げてきた」とも言えます。
データ資源再利用の文化は想像以上に未熟のようです。これは特にオープン系
の開発環境においてはなはだしいとのことです。リソースデータの共用/再利
用はデータ流通のため、きわめて重要かつ有効ですが、多くは業務のイベント
の中に埋没して再利用しようと思うと却って工数が掛かるような状態となって
いるようです。
これはマネジメントの問題ですが、同時にDBMSや開発ツールの影響も大き
いように思われます。もしRDBMSが概念モデルと物理モデル、またリソー
スデータとイベントデータを区別し、レイヤードアプローチを支援するもので
あったら、今日の情報システムはよほど違ったものになっていたのではと残念
でなりません。
情報システム開発のありかたについてかなり大胆な仮説を述べました。皆様か
らのコメントなど期待します。