ITエンジニアがDOAや,その中核を成すER図(Entity Relationship Diagram)によるデータ・モデリングを学ぶ意義は極めて大きい。そこで本講座では,歴史的背景を踏まえて,DOAの基礎とデータ・モデリング手法を解説する。Part1では,DOAの具体的な解説に入る前に,方法論の変遷を概観する。

 読者の中には,「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の具体的な解説に入る前に,方法論の変遷を概観しておこう。

 システム分析・設計・開発の方法論は,システム化の対象業務のどの側面に着目するかによって,「POA(Process Oriented Approach:プロセス中心アプローチ)」,DOA,OOAの3つに大きく分類できる(図1)。

図1●情報システム開発の3つのアプローチ
図1●情報システム開発の3つのアプローチ
各々に一長一短があるが,現在ではDOAまたはOOAが主流である

 1960年代から70年代にかけては,POAが主流だった。POAは業務プロセスと機能に着目した方法論で,その起源は,1960年代後半にエドガー.W.ダイクストラが提唱した「構造化プログラミング」とされている。

 POAでは,業務プロセスと機能をモデリングし,それを忠実にプログラム言語で記述する。代表的なモデリング手法としては,1978年にトム・デマルコが提唱した「DFD(Data Flow Diagram:データフローダイヤグラム)」がある。DFDは,システムの機能を全体から部分へと詳細化しながら厳密にモデリングでき,ユーザーにも理解しやすいため,現在でも広く普及している。

 POAに基づく業務プロセスと機能のモデリングは,プログラムのアルゴリズムと親和性が高いため,プログラミングに直結するという利点を持つ。その反面,データがプログラムごとにバラバラに設計されるため,データの重複や不整合が起こりやすい。このため,POAに基づいて開発したシステムでは,プログラムを追加・変更するたびにデータまで設計し直すことになり,大幅な手間とコストがかかる。

 それでも60年代から70年代にかけては,POAで十分だった。当時は,業務の効率化が主な目的であり,業務プロセスや機能も比較的シンプルだったからだ。しかし,80年代に入ってシステムが大規模かつ複雑になってくると,プログラムの追加・修正に手間がかかるというPOAの欠点が露呈してきた。情報システムは本来「資産」であるべきところが,経営ニーズに即応できずコストばかりかかるため,「負債」と呼ばれるようになってしまったのである。