なぜデータ中心アプローチなのか？ → データは安定している
基幹システムの処理は業務手順の変化に合わせて変化することはあっても、業務の本質的な内容、つまり業務に根ざしたデータ自体は経営の内容が変わらない限り変化しない。業務内容そのものを表現するデータは、業務手順（プロセス）が多少変化しても、安定している。
従来技法（構造化分析設計技法：機能分解中心）の問題点
データを共有資源として十分に意識していないため、データ資源操作がプログラムごとに重複してしまい、プログラム相互の依存関係を強くする、あるいは、共有資源としてのデータを分析しないので共有データの整合性、一貫性維持を難しくする。
ただし…
データ構造の複雑なシステムを解析する上では、データモデリングの考え方は有効であるが、機能が複雑なシステムを解析する場合はプロセス中心（機能分解中心）の構造化分析設計技法が有効である。データ中心とプロセス中心は相互補完関係にあり、一方だけでは十分ではない。
| １．データ標準化 | 情報システムの運用や保守を容易にするため、あるいはデータの共用を可能にするためにデータの標準化を行う。 |
|---|---|
| ２．データ設計過程の分離独立 | 共有資源としてのデータの設計と管理は、データ資源管理者の組織が行い、システム開発プロジェクトには任せないようにする。 |
| ３．データモデリング | 複数のシステムを対象にした論理データモデルを作成することによって、個別システムを開発する前に企業全体のデータ体系を見直すことができるようになる。 ↓ データやデータ資源操作が重複しない、整合性がとれた開発が行える。 |
| ４．データに基づく要求定義 | ユーザやビジネスからの要求を従来のように機能（プログラムを作成すること）に置き換えて捉えるのではなく、情報に対する要求として捉える。 ex.)ユーザが直接入手できる分かりやすい成果物（帳票や画面のイメージ）として要求を捉える。 こうした情報要求が既存のDB上の標準データやカプセル化された処理を用いて実現可能かどうかが検証され、必要ならば最低限の開発が行われる。 |
| ５．リポジトリによるシステム開発と保守 | データ中心アプローチではリポジトリを用いたシステム開発を行う。リポジトリにはデータ対応にビジネスルールから導かれる整合性制約を格納しておくことができる。 システム開発に当たってはこうしたリポジトリにデータ対応でもたれている部分以外のもの、つまりアプリケーション固有の部分を業務プログラムとして開発するようにする。 保守においてデータ定義の変更が生じた場合はリポジトリを元に変更箇所を特定し適切な措置（リコンパイルやソース修正）をとる。 |
| ６．カプセル化 | データと処理を一体化して、データに処理を閉じ込めたもの。カプセルはデータと制約条件チェック処理が主な構成要素となる。 |
| ７．制約独立性 | トランザクション制約やデータ整合性制約などの制約条件をプログラムから取り除く。（整合性チェックをDBMSに任せる…とか） ↓ プログラムの作成量が最小限となり、制約条件が集約化されるので保守性が向上する。 |
| ８．リポジトリを中心としたツール体系 | 名称付与ツール、名称監視ツール、CASE（上流、下流工程）、リバースツールなどのリポジトリを中心とするツール体系を利用して開発を行う。 |
データ中心アプローチによる開発手順について、次の作業項目を正しい順に並べたものはどれか。
（１）応用プログラム設計
（２）カプセル化
（３）データモデリング
（４）ドメイン／原子オブジェクト分析
ア （３） （４） （１） （２）
イ （３） （４） （２） （１）
ウ （４） （３） （１） （２）
エ （４） （３） （２） （１）
ユーザ要求などにかかわらず、先にデータを分析・設計し、プロセスの多くをデータに固有の操作または制約としてカプセル化するのがデータ中心アプローチである。
| データモデリング | 上記参照（３）。 |
|---|---|
| ドメイン／原子オブジェクト分析 | オブジェクトを構成する共通な原子データを洗い出し、オブジェクトをそれらの集約物として定義する（上記４）。 |
| カプセル化 | 上記参照（６）。 |
| 応用プログラム設計 | カプセルとして定義されたデータをリポジトリによって共有しながら、ソフトウェアの開発を行う（上記８）。 |
実際、こんな開発したことないなぁ