DB 論理設計と物理設計
前提知識
- 外部スキーマ:ユーザから見たデータベース。ユーザから見てデータベースがどのような機能とインターフェースを持っているのか定義するスキーマ。
- 概念スキーマ:開発者から見たデータベース。データベースに保持するデータの要素および、データ同士の関係を記述するスキーマ。
- 内部スキーマ:DBMSから見たデータベース。論理データモデルを具体的にどのようにDBMS内に格納するか定義するスキーマ。テーブルやインデックスの物理設計を含む。
概念スキーマと論理設計
論理設計:概念スキーマを定義する設計
DB設計は基本的に論理設計→物理設計の順で行っていく。物理設計とはDBのCPUやストレージなど定義する設計のこと。論理設計と物理設計は互いに依存しない。
料理で例えるなら、器(物理設計)を用意して献立(論理設計)を決めるのではなく、献立に合わせて器を決める。みたいな感じ。
論理設計のステップ
エンティティの抽出 → エンティティの定義 → 正規化 → ER図の作成
- エンティティの抽出:システムに必要なデータ(エンティティ)が何かを洗い出す。
- エンティティの定義:各エンティティの属性(列)を定義する。ここでキーの定義についても行う。
- 正規化:データをシステムで利用しやすいように各エンティティの最適化を行う。
- ER図作成:正規化するとエンティティが細かく分割されるので、それぞれのエンティティの関係性や保持するデータを可視化する作業。
内部スキーマと物理設計
物理設計のステップ
テーブル定義 → インデックス定義 → ハードウェアのサイジング → ストレージの冗長構成決定 → ファイルの物理配置決定
- テーブル定義とインデックス定義:論理設計をもとにDBMSで扱うテーブル、インデックスを定義する
- ハードウェアのサイジング:以下の2つのサイジングを行う
- ストレージのサイジング:キャパシティの見積もりをする
- CPU、 メモリのサイジング:パフォーマンスの見積もりをする
- 性能要件
- 処理時間:特定の処理が「何秒以内に終了すること」を定義。つまりどれだけ速く処理をこなせるか
- スループット:単位時間あたりにどれだけの処理をこなせるかを定義。つまりどれだけたくさんの処理をこなせるか
- 性能要件
- ストレージの冗長構成:データベースに使用するHDDの冗長化。データベースに格納するデータは紛失してはならないデータなので、冗長に持つのが望ましいとされる。また冗長構成にすることで、データを分散することもできるので性能向上に繋がる。 具体的にはRAID(Redundant Array of Inexpensive Disks)のレベルを選定する。 ※RAID: HDDを1つのドライブのように認識させたり表示させたりする技術のこと
- ファイルの物理配置:以下のファイル郡をどのRAIDに配置するか。これらのファイルをすべて異なるHDDで管理したら多額の費用がかかるので、I/Oが頻繁に発生するファイルは別のHDDで管理してそれ以外のファイルは同じHDDで管理するなどして、性能面を考慮しながらファイルの物理配置を設計する必要がある。
- データファイル
- データベースに格納するデータを保持するためのファイル
- インデックスファイル
- テーブルに作成されたインデックスを格納するためのファイル
- システムファイル
- DBMSの内部管理用に使用されるデータを格納するファイル
- 一時ファイル
- サブクエリやソートデータなどを格納するためのファイル
- ログファイル
- テーブルのデータ更新をした際に更新するログファイル
- データファイル