読者の中には，「DOA（Data Oriented Approach：データ中心アプローチ）なんて過去のもの。今から学ぶならオブジェクト指向では？」と思っている人も多いのではないだろうか。確かに現在では，プログラミング言語も開発プロセスも，「OOA（Object Oriented Approach：オブジェクト指向アプローチ）」が前提になっていることが多い。このため「まずオブジェクト指向を学ぶべき」と考えても無理はない。
しかし筆者は，ITエンジニアがDOAや，その中核を成すER図（Entity Relationship Diagram）によるデータ・モデリングを学ぶ意義は極めて大きいと考える。その第1の理由は，現在のデータベースの主流であるRDBMS（リレーショナル・データベース管理システム）を使うときは，データ・モデリングが必須であることだ。詳しくは後述するが，ER図で作成したデータ・モデルはRDBと親和性が高く，RDBの実装へとつなげやすい。RDBを使って情報システムを効果的に開発するには，データ・モデリングを正しく理解しておく必要がある。第2の理由はDOAにはオブジェクト指向との共通点が多いため，オブジェクト指向の学習にも役立つことだ。そこで本記事では，歴史的背景を踏まえて，DOAの基礎とデータ・モデリング手法を解説する。
プロセスと機能が主体のPOA
DOAの名称にある「～中心アプローチ」とは，システム化の対象業務を図で表現するためのモデリング手法を含む，システム分析・設計・開発の方法論を指す。DOAの具体的な解説に入る前に，方法論の変遷を概観しておこう。
システム分析・設計・開発の方法論は，システム化の対象業務のどの側面に着目するか＊1によって，「POA（Process Oriented Approach：プロセス中心アプローチ）」，DOA，OOAの3つに大きく分類できる（図1）。
|
|
| 図1●情報システム開発の3つのアプローチ 各々に一長一短があるが，現在ではDOAまたはOOAが主流である |
1960年代から70年代にかけては，POAが主流だった。POAは業務プロセスと機能に着目した方法論で，その起源＊2は，1960年代後半にエドガー.W.ダイクストラが提唱した「構造化プログラミング＊3」とされている。
POAでは，業務プロセスと機能をモデリングし，それを忠実にプログラム言語で記述する。代表的なモデリング手法としては，1978年にトム・デマルコが提唱した「DFD（Data Flow Diagram：データフローダイヤグラム）＊4」がある。DFDは，システムの機能を全体から部分へと詳細化しながら厳密にモデリングでき，ユーザーにも理解しやすいため，現在でも広く普及している。
POAに基づく業務プロセスと機能のモデリングは，プログラムのアルゴリズムと親和性が高いため，プログラミングに直結するという利点を持つ。その半面，データがプログラムごとにバラバラに設計されるため，データの重複や不整合が起こりやすい。このため，POAに基づいて開発したシステムでは，プログラムを追加・変更するたびにデータまで設計し直すことになり，大幅な手間とコストがかかる。
それでも60年代から70年代にかけては，POAで十分だった。当時は，業務の効率化が主な目的であり，業務プロセスや機能も比較的シンプルだったからだ。しかし，80年代に入ってシステムが大規模かつ複雑になってくると，プログラムの追加・修正に手間がかかるというPOAの欠点が露呈してきた。情報システムは本来「資産」であるべきところが，経営ニーズに即応できずコストばかりかかるため，「負債」と呼ばれるようになってしまったのである。
安定した「データ」に着目
プログラムの追加・修正に手間がかかるというPOAの限界を克服するために，80年代に登場したのがDOAである（図2）。DOAは，ビジネス環境によって変化しやすい業務プロセスや機能ではなく，変化が少なく安定した「データ」に着目した方法論だ。
|
|
| 図2●システム開発アプローチの歴史 1960～70年代は，業務プロセスやシステムの機能に着目する「POA（プロセス中心アプローチ）」が主流だった。しかし業務システムが複雑になるにつれて，データの重複やシステムの保守性の低下といったPOAの問題点が顕在化。代わって，データに着目してシステムの分析/設計/実装を行う「DOA（データ中心アプローチ）」が登場した |
企業にとってはデータこそが「資産」であり，将来にわたって組織的に管理・活用する必要がある。そこでDOAでは，まずすべてのプログラムが共通に利用するデータの構造を，重複や不整合のない形でモデリングする（データ・モデリング）。1つのデータは原則として1つしか存在させない（複製を作らない）。このDOAの原則を「one fact in one place（1つの事実は1カ所で管理する）」と呼ぶ。機能や状態遷移（実行順序）などは，データ・モデルとは別にモデリングする。
DOAでは，データ構造とプログラムは切り離されている。加えて，一度モデリングしたデータ構造は長期にわたって変化しにくい。このため，システムを変更したり新たな機能を追加するときも，プログラムだけを修正すれば済むことが多い。POAに比べてシステムの保守や拡張が容易な，構造的に安定したシステム構築が可能になるわけだ。なお，DOAという用語は国際的にはほとんど用いられていない和製英語であることに注意して欲しい。米国では「DDA（Data Driven Approach）」と呼ぶことが多い。
DOAの起源はERモデル
DOAの起源は，1975年にピーター・チェンが提唱した「ER（Entity Relationship）モデル」である。ERモデルは，データ項目の集まりである「エンティティ（Entity：実体）」と，エンティティ間の論理的なつながりを定義した「リレーションシップ（Relationship：関連）」を使ってデータ構造を図示したものだ。ERモデルを作成するための表記法がER図である。現在に至るまで，ER図はデータ・モデリングの代表的な手法として利用されている。
89年には，ジェームス・マーチンが，ER図によるデータ・モデリングを中心にした方法論「IE（Information Engineering）」を提唱。DOAが普及する大きな原動力となった。マーチンは「プログラムごとにデータを設計するPOAは，全社最適の視点を失う」と主張し，それを回避するために全社レベルのデータ・モデルの必要性を説いた。これは，現在でもDOAの基本的な考え方となっている。
90年代に入ると，RDBMSが企業情報システムのデータベースとして普及し始めた。ER図でモデリングしたデータ構造はRDBMSに実装しやすかったため，RDBMSの普及と歩調を合わせてDOAは広く普及していった。
データと処理を一体化する
ただし，DOAにも欠点はある。一度モデリングしたデータ構造を変更すると，関連するプログラムを特定するのが極めて難しいことだ。このため，システムの追加・修正の際にデータ構造を変更する必要があると，多大な手間と時間がかかる。これはデータとプログラムが切り離されていることに起因する。
これに対して，90年代に入って普及し始めたOOAは，データとそれに関連する処理および状態を「カプセル化（Encapsulation）」して「オブジェクト」として定義し，データとプログラムを一体のものとして扱う。あるオブジェクト内部のデータ構造が他のオブジェクトに依存しないため，オブジェクト同士を部品のように組み合わせられることが大きなメリットだ。これにより，新たな機能の追加やシステムの修正，さらにプログラムの再利用も容易になる。
しかしOOAは，DOAに比べて歴史が浅いこともあって，モデリング手法がまだ十分確立されていない。このため，モデリング手法に属人性が高く，作業者のスキルによってモデルの品質や開発生産性にばらつきが大きくなりやすい問題がある。
OOAとDOAは，一見すると全く異なる方法論に見える。しかしOOAのオブジェクトの中心となる構成要素はDOAと同じく「データ」であり，しかもDOAもOOAも，時間の経過による変化を考えずにある瞬間のシステムの状態を表した「静的な側面」（DOAの場合はデータ，OOAではオブジェクト）に着目している。この点で，DOAもOOAも本質は同じと筆者は考えている。冒頭で，DOAの理解がOOAの学習に役立つと述べたのはそのためだ。
また，OOAでシステムを開発する場合でも，RDBMSを使うときはデータ・モデリングが必須になる。つまりDOAやデータ・モデリングと，OOAは相反するものではない。DOAとOOAは，今後も協調しながら進展を遂げていくだろう。
（次回へ）
|
