▼ [ DOA ] Data-Oriented Analysis << もどる HOME すすむ >>


● ソフトウェア・エンジニアリング と 構造化手法

1970年代の ソフトウェア・エンジニアリング は以下の点を特徴としていました。

 - アプリケーション 単位に システム を構築する。
 - システム 構築の工程を フェーズ 化する(分析工程・設計工程・製造工程・保守工程)。
 - それぞれの工程で構造化手法を使う。

 



● データ重複 と 無駄プログラム

アプリケーション 単位に構造化手法を使ったので、データ が重複してしまいました。或る調査では、データ・ストーレッジ に収められている データ の 70%が重複しているそうです。重複している データ を同期的に更新するために インタフェース・プログラム が蔓延しました。プログラム の ソース・コード の 90%が無駄であるという報告も公表されました。

 



● RDB と データ正規形

1980年代、RDB が普及するにつれて、データ の正規形が論点になりました。
データ 正規形は、データ の重複を排除して、以下の 2点を実現する構造です。

 - 「minimal cover (必要最小限の)」 データ 量
 - 「stable (安定した)」 データ 構造

つまり、環境が変化しても、データ 構造が(ほとんど)影響されない状態にすることが狙いでした。データ の正規形は 「環境の変化(ビジネス の分析)」そのものを対象とはしていなかった。

 



● DOAData-Oriented Approach

RDB が普及するにつれて、プログラム の アルゴリズム と データ を切り離して、データ の独自性を立脚点にして データベース を構築することが主張されました。

データ の独自性に対して数々の解釈が出てきましたが、データ の独自性という共通項を立脚点にしているので、それらの流派の考えかたを総括して DOA と言います。1980年代に導入された DOA は、「Data- Oriented Approach 」の略称でした。DOA では、実世界(事業)を対象にした概念設計の やりかた(意味論)が、主に討論されました。

 



● 概念設計(意味論)と データベース設計論(数理モデル)の断層

概念設計と データベース設計論では、使われている手法が違うので 「断層」 が起こっています。つまり、概念設計段階において分析された事業実態を システム・エンジニア が「翻訳」して データベース設計論に移植しなければならない。言い換えれば、「共有の」財産である データ が一人の システム・エンジニア の価値観に左右されるということです。

 



● 事業実態の分析 = データ構造(正規形)

事業実態の解析を、そのまま、データ 構造として使い、データ の正規形を実現しなければならない。それを実現するのが 「DOA」です。

 



● 事実の記述

戦略とは「環境適用能力」のことです。事業の「事実」を分析して、環境変化に対照しながら、事業の「強みと弱み」を分析しなければならない。事業のなかで実際に使われている「情報」を分析して「事実を記述する」技術が「DOA」です。

 



● アルゴリズム の I/O

DOA」 は、単に データ の正規形を生成するのではなくて、戦略を対象とします。意味論(事業分析)と数理モデル(データ構造)の「溝」を埋めて、「事業分析 = データ構造」とする技術です。そして、アルゴリズム を、できるかぎり、I/O 化して プログラム の生産性を向上する技術です。したがって、1980年代に導入された DOA から、いっそう進化しています。「DOA」を1980年代の DOA と区別して、「Data-Oriented Analysis 」という言いかたをします。

 

 DOA [ Data-Oriented Analysis ] は、

 事業の強みと弱点を分析して、
 データベース の正規形を生成しながら高 レスポンス を実現して、
 アルゴリズム を、できうるかぎり、I/O 化して、
 システム 作りの高生産性を少ない投資で実現して、

 経営と IT を直結する技術です。

  << もどる HOME すすむ >>



/font>