ここでいう「データ指向」というのは、古くはホストコンピューターの時代から連綿と続いているIBM 内の秘伝のタレ（かな？）のことで、昨今の O/R マッピングの話が出る以前の設計と実装手順のことです。20 年以上前ってことになるかなぁと。
- テーブル構造を作成する
- テーブルへアクセスするCRUDを記述する
- テーブルを連結して一覧する方法を記述する
- 画面を設計する
いきなり、テーブル構造（データ構造）から始めているのが「データ指向」の所以です。オブジェクト指向の場合は、どのデータが「存在するのか」を調べた後に、どのまとまり（クラス）にするのか、という整理の仕方（オブジェクト図からクラス図の設計の流れがそれ）をしますが、データ指向の場合は、まず、まとまったデータがいきなりあって、そこからスタートします。
そして、データ指向で実装をする場合には、後戻りをしませんッ!!! ここは重要です。データ指向をする場合には、最初のデータ構造ありきのところがあるので、逐一 CRUD を作るところから、完全なウォーターフォール方式（あるいは流れ作業方式）で作れ、完全に分業が可能な開発工程ができます。
■テーブル構造を作成する
アプリオリな話になりますが、データ構造をどうやって分析していたのか（いるのか？）は私には不明です。後には DFD を使ってデータ構造を作ったりするのですが（本来は、DFD はデータの前後の関係、データの加工手順を示すものなのですが）、それ以前はどうしていたのでしょうね？
なんとなく、まとまりがあるところから、なんとなく正規化をして、という流れで設計をしているのでしょうね。おそらく。
また、ホストコンピュータの時代からのデータ構造を流用し続けていくので、データ構造を新しく作ることはないと言っても過言ではありません。あらかじめ、データベースにテーブル構造があるところから、移行設計、追加設計をしていくのが普通です。
■テーブルへアクセスする CRUD を記述する
CRUD(Create, Read, Update, Delete)の表を、テーブル毎にすべて作ります。そして、CRUD する関数を全て最初に作ってしまいまいます。今でこそ、自動化なり、リフレクションを使って、なぞと小細工…いえ効率化をすることができるのですが、当時はちまちまとコーディングです。
基本はひとつのテーブルに対して、ひと揃いの CRUD を用意していきます。このあたり、いわゆる登録系の画面（いわゆる年金を登録する画面とかね）と、検索系の画面（いわゆる株価の動向を見る画面とかね）の二種類があって、ここで CRUD 表を作るのは、登録系の画面で使うものです。
検索する場合であっても、主キーのみで検索したり、外部キーで他のテーブルを参照したりするぐらいのリレーションを持っているものです。
これをひたすら設計/実装していきます。
■テーブルを連結して一覧する方法を記述する
いまでこそデータベースと BI はビジネス的に切っても切れない関係にありますが、かつてはデータを分析するのは別の機能でしたし、非常にお金のかかるものでした。なので、分析して帳票に出すというのは、結構手間が掛かりお金もかかったので、あまり機能的には豊富ではなかったのですね。
いまのように GUI でちょいちょいと検索項目を入れて、数分後には帳票ができるというものではありませんでした。プリンターも高かったし。
なので、帳票を出力する場合は、「事前に決めた検索項目」を使って出力するってのが普通だったし、それがデータ指向をするときの欠点にもなっています。
日次、月次のような決まりきった帳票を出すためのインターフェース（関数のロジック）を事前に決めることができるのですが、インタラクティブに GUI で検索項目を変える、というところにまでデータ指向の利点はでてきません。
なので、この部分は、現在データ指向でプログラミングする場合は、
- 事前に分かっている検索結果、帳票しか出さない要件とする。
- それ相応に、要件定義を練り込む
という制限が必要になります。
■画面を設計する
ここに来て、やっとユーザーが利用する画面を設計＆実装していきます。
データベースへのアクセスについては、2 と 3 で作成した関数を必ず通すので、おのずから画面のスタイルは決まっています。
- 更新や閲覧のためのテーブル構造そのままの画面
- リレーション先は、別画面（あるいは子画面）
- リレーションが必要な一覧は、帳票として出力
というパターンになります。
当然、ユーザーがあれこれと画面を渡り歩くことはできず、画面遷移もデータ構造に一致します。
このデータ指向での設計＆実装での最大の利点は、
- 機能数や画面数が事前に見積もりやすい（FP を利用しやすい）
- 機能数が事前に分かるので、開発期間が見積しやすい
- CRUD 表に従うので、標準的なプログラマだけでよい（スーパープログラマはいらない）
というところになります。
欠点としては、
- 開発プロセスとして面白みがない（改善する余地がほとんどないので、効率化もできない）
- 画面にユーザーの要望が入らない。
- 分析系が複雑化すると破綻しやすい（事前の関数の数を見極めにくい）
というところです。
でも、非常に開発プロセスとしては安定しているので、大規模開発には向いています。
ただし、効率化できるところが少ないので、アジャイルプロセスのように「作業の省略」ができません。全てを綿密に作る（無駄も含めて）ことになるので、あとから見ると無駄な関数を大量に作る可能性があります。
時間があれば、後で図解でも up しますか。
