データベース設計はいつ、何をポイントに行うか：ゼロからのデータモデリング入門（4）（2/3 ページ）

前回までは、データベース設計の歴史的背景からデータベース設計の有効性までを解説しました。今回は、システム開発ライフサイクルと照らし合わせ、それぞれのフェイズで必要となるデータベース設計について、お話をします。

[沖冠吾，株式会社アシスト]

各工程におけるデータベース設計（データモデリング）の役割

　システム化分析、基本設計、詳細設計の各工程において、データベース設計（データモデリング）が果たす役割は、「ビジネス構造のデータによる分析」「ビジネス構造のデータによる可視化」「システムを動かすためのデータ構造化」の3つです。

（1）ビジネス構造のデータによる分析（システム化分析工程）

　システム化要求工程でシステム化される対象範囲が決定するため、次の工程となるシステム化分析工程では、ビジネス活動全体と企業が管理すべきデータを明確にし、システム化対象範囲となるデータ構造を確定させます。具体的には、ビジネスプロセス構造とビジネスプロセス上必要となるエンティティとの関連を表す「CRUD図」を作成し、ビジネスプロセス間のルールを確認しながら企業全体でER図を作成します。これが「概念データモデル」になります。

　・概念データモデル

　概念データモデルは、システム化対象範囲の業務プロセスをモデル化したものです。概念データモデルにより、ビジネス活動全体を俯瞰（ふかん）的に捉え、システム化対象範囲をすぐに判断することができます。

●図2　概念データモデルの作成

（2）ビジネス構造のデータによる可視化（基本設計工程）

　・論理データベース設計

　システム化対象範囲のデータ構造は「概念データモデル」によって明確になっているため、基本設計工程では、ビジネスの視点でより詳細なER図を作成し、データ項目を明確にします。これを「論理データベース設計」といいます。

　論理データベース設計では、既存データベースやExcelファイル、帳票、画面など、関連する情報から項目レベルでデータを捕捉し、整理します。ここで作成したものが「論理データモデル」になります。

　「論理データモデル」は「ビジネス活動をデータモデルで可視化したもの」であるため、システムの観点ではなく、ビジネスの観点で作成する必要があります。

●図3　論理データモデルの作成

（3）システムを動かすためのデータ構造化（詳細設計工程）

　・物理データモデル

　せっかくビジネスの観点でデータを整理しても、実際に動かなければ意味がありません。そのため、詳細設計工程では、できる限り「論理データモデル」を崩さずに最適な処理効率が可能な「物理データモデル」へ変更します。具体的には、システムの処理とエンティティのCRUD図を作成し、ボトルネックを見つけ、論理的なI/O試算を行ったうえで、対処方法の検討を行います。

　ボトルネックとなる部分に対しては、RDBMSの機能による施策の検討、テーブルの配置の検討、およびIndexによる施策の検討などを行い、最終手段としてデータ構造の変更を行います。ここでは、論理データモデルと物理データモデルの相違が「なぜ」起きたか理由が明確になっていることが重要です。

●図4　物理データモデルの作成