目的
「達人に学ぶ DB 設計 徹底指南書」を読んで学んだことをアウトプットするために記事を投稿する。
今回は第 2 章についての内容をまとめる。
概念スキーマと論理設計
- 論理設計
- 概念スキーマを定義する設計
システム開発におけるデータベース設計の手順
1. 概念スキーマ（論理設計）
2. 内部スキーマ（物理設計）
論理設計のステップ
- エンティティの抽出
- システムのためにどのようなエンティティ（＝データ）が必要になるかを抽出
- エンティティの定義
- どのような列（=属性）を持つかを定義する
- キー（key：ある特定の列の値を決定するための列）という列を定義
- 正規化
- エンティティ（テーブル）について、システムでの利用がスムーズに行なえるよう整理する
- データの更新（登録、変更、削除）が整合的に行なえるように、エンティティのフォーマットを整理する
- ER図の作成
- エンティティ同士の関係を表現する図を作成
内部スキーマと物理設計
- 物理設計
- データを格納するための物理的な領域や格納方法を決める工程
物理設計のステップ
- テーブル定義
- 論理設計で定義された概念スキーマをもとに、それをDBMS内部に格納するための「テーブル」の単位に変換していく作業
- インデックス定義
- インデックスは本の索引のような役割
- ハードウェアのサイジング
- システムで利用するデータサイズを見積り、それに十分な容量の記憶装置（ストレージ）を選定する
- システムが十分な性能を発揮できるだけのスペックのCPUやメモリを持ったサーバーを選定する
- ストレージの冗長構成決定
- システムの耐障害性を高めるための工程
- RAIDと呼ばれる技術を用いる（RAID0、RAID1、RAID5、RAID6、...）
- ファイルの物理配置決定
- データベースのファイルをどのディスク（またはRAIDグループ）に配置するか考える
- 最近のDBMSでは自動化が進んでいるため、ある程度はDBMS側が自動的に配置してくれることもある
バックアップ設計
バックアップの基本分類
- フルバックアップ（完全バックアップ）
- ある時点でそのシステムで保持されているすべてのデータをバックアップする方式
- リカバリ作業が容易だが、バックアップにかかる時間が長い、ハードウェアリソースへの負担が高い、バックアップ時にサービスの停止が必要になるなどの欠点も抱えている
- 差分バックアップ
- ある時点でフルバックアップを行い、その後はバックアップファイルとの差分のみをバックアップする方式
- ログファイル（データの変更履歴）を活用
- フルバックアップと比較すると、バックアップデータ量が減る他、バックアップ時間が短縮されるなどのメリットがある
- バックアップ時に使用するファイルが増える（フルバックアップファイル＋ログファイル）ため、リカバリの手順や作業時間が長くなる
- 増分バックアップ
- ある時点でフルバックアップを行い、その後は変更分のみをバックアップする方式
- バックアップデータ量が3つの方式の中で最も少ない（=バックアップに要する時間が短い）
- リカバリ時に使用するファイル数が多くなる（=最も作業時間が長い）
バックアップ方式を選定するポイント
1. いつ時点の状態に復旧させる必要があるか。そもそも復旧の必要があるか。
2. バックアップに使用できる時間（バックアップウィンドウ）
3. リカバリに使用できる時間（リカバリウィンドウ）
4. 何世代までのデータを残す必要があるか（保管用の媒体サイズに影響）
リカバリ設計
リカバリとリストア
- リカバリ
- バックアップファイルを戻す作業
- リストア
- トランザクションログを適用して変更文を反映する作業
データベースの復旧手順
1. フルバックアップのファイルをデータベースに戻す（=リストア）
2. 差分、または増分バックアップしていたトランザクションログを適用する（=リカバリ）
3. データベースサーバーに残っているトランザクションログを適用する（=ロールフォアード）
感想
- RAID やバックアップ方式を通して、完全な手法（メリットしかない手法）は存在しないということを改めて思い知らされた
- バックアップ方式を選定するポイントが分かりやすくまとめられていたのが良かった