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

---

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

　

●　RDB と データ正規形

---

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

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

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

　

●　DOA （Data-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 」という言いかたをします。