一言で説明すると？
概念設計
システムが扱うべきデータの種類と、それらのデータがどのように関連しているかを明確にする。
論理設計
データの整合性を保つための制約やルールを定義する。
物理設計
実際のDBMSが理解できる形にする。
概念設計、論理設計、物理設計の違い。
| 設計ステップ | 目的 | 内容 | 出力 |
|---|---|---|---|
| 概念設計 | データベースの基本的な構造を定義します。どのようなデータを保持するべきか、そのデータの種類や関係性を考えること。 | エンティティ（テーブル）を定義し、それぞれのエンティティが持つ属性（フィールド）を決定。エンティティ間の関係性（リレーションシップ）を定義。 | ER図（エンティティ-リレーションシップ図）、概念データモデル |
| 論理設計 | 概念設計で定義されたデータベースの構造をより詳細に設計。データの整合性を保つための制約やその他のルールを設定。 | 正規化の一環として、データの冗長性を減らすためにテーブル間の依存関係を調整。ER図の作成でデータベースの構造を視覚的に表現。 | 論理データモデル、テーブルスキーマ、キー定義、正規化されたスキーマ |
| 物理設計 | 論理設計で定義されたデータベースの構造を実際のDBMSが理解できる形式に変換。パフォーマンスと効率を最適化するための設定。 | テーブル定義を行い、DBMS上にテーブルを構築。インデックスの設計を行い、特定のクエリを高速化。 | 物理データモデル、インデックス設計、ストレージ仕様 |
主な違いのまとめ
| 観点 | 概念設計 | 論理設計 | 物理設計 |
|---|---|---|---|
| 抽象度 | 高 | 中 | 低 |
| 目的 | 基本的なデータ構造と関係性の定義 | データ構造の詳細化とデータ整合性の確保 | 実際のDBMSへの実装とパフォーマンス最適化 |
| 内容 | エンティティ、属性、リレーションシップの定義 | テーブル設計、キー定義、正規化 | テーブル構築、インデックス設計、ストレージ仕様 |
| 出力 | ER図、概念データモデル | 論理データモデル、テーブルスキーマ、キー定義 | 物理データモデル、インデックス設計、ストレージ仕様 |
これらの設計ステップを順に進めることで、効率的で信頼性の高いデータベースを設計・実装できる。