１．業務システムでデータベースを利用する目的
データベースを利用する目的は、業務で発生する顧客情報、商品情報、注文情報などを一元的に管理すること、必要な情報に効率的にアクセスできるようにすることです。このような目的を達成するデータベースを構築するためには、要件定義、データベース設計、構築（実装）、テスト、運用などの作業が必要となります。データベース設計は、論理設計と物理設計に分かれます。
２．論理設計
論理設計では、業務で求められる機能要件に合わせた論理データモデルを作成します。論理データモデルは、エンティティとエンティティ間のリレーションで定義されます。エンティティは、主キーと、それに従属する属性で定義されます。リレーションは、カーディナリティとオプショナリティで表します。カーディナリティは、２つのエンティティ間の「多重度」を「1対1」、「1対多」、「多対多」の対応関係として示します。オプショナリティは、２つのエンティティ間の「依存性」を示します。例えば、商品と注文の２つのエンティティがある場合、注文エンティティは商品エンティティに依存しますが、商品エンティティは他のエンティティに依存しません。
３．物理設計
物理設計では、非機能要件（パフォーマンスや可用性など）をもとに論理データモデルを最適化して物理データモデルを作成します。パフォーマンス要件では、データベースの応答時間やスループットを達成するために、必要に応じて検索用インデックス、パーティショニング、事前集計表などを作成します。また、アプリケーションからデータベースをアクセスするためのビューの設計を行います。このようなビューは、外部スキーマと呼ばれます。ビューを利用しないシステムでは、データベースが変更される度にプログラムの変更が発生する可能性があります。多くのシステム開発現場では、データベースの変更がドキュメント化されていないために、プログラムの変更漏れによって不具合が発生することがあります。
４．機能要件に適した論理データモデル
機能要件と論理データモデルの間にギャップがあると、そのギャップを埋めるために、本来必要のない「無駄なプログラム」を作成することになります。無駄なプログラムは、開発工数やテスト工数の増加、不具合の発生、性能劣化などの問題を誘発してプロジェクトを遅延させたり、本番稼働後に突発的なトラブルを発生させる原因となります。
５．フレームワークの必要性
プロジェクト遅延やトラブル発生を回避するために「フレームワーク（枠組み）」を利用します。ここでのフレームワークの目的は、論理データモデルを標準化して説明性を高めることです。フレームワークは、テンプレート化されたインプット（入力情報）とアウトプット（成果物）、プロセス（手順）、そして、設計支援ツールの３つの要素で構成されます。入力情報や成果物を標準的な形式でテンプレート化して説明性を高めることにより、プロジェクト内での情報共有とスムーズな利用を促進します。さらに、標準的な形式を採用することで、特別な学習を必要とせずに入力情報や成果物を理解できるというメリットがあります。実際のシステム開発現場では、時間と労力を費やして独自の形式による成果物を作成したものの、プロジェクト内で利用されず、お客様にも理解されないという事例もあります。
６．おわりに
次回からフレームワークを使ってデータベースの論理設計を実施する手順を、具体的なサンプルを交えて紹介していきます。
なお、「機能要件に適した論理データベース設計」を支援するサービスを提供させていただいております。是非、一度、ご検討いただければ、幸いです。
