「達人に学ぶ DB設計指南書」を読みました その1

はじめに

「達人に学ぶ DB設計指南書」は、翔泳社より出版されている書籍です。

https://www.shoeisha.co.jp/book/detail/9784798124704

今回は、こちらの書籍のまとめや感想などをお伝えします。

内容まとめ

今回はその1ということで、1章と2章の内容をまとめていきます。

第1章 データベースを制する者はシステムを制す

• データとは、ある形式（フォーマット）に揃えられた事実のこと
• 情報とは、データと文脈を合成したもの
• RDBとは、データベースのモデルの一つ
  • 2次元の表形式でデータを管理する
• RDB以外にも、オブジェクト指向データベースやXMLデータベース、キーバリューストアなどがある
• RDBには、MySQLやPostgreSQLなどの種類がある
• どのRDBを採用しても、設計方法は同一である
• RDBを管理するためのシステムをRDBMSと呼ぶ
• システム設計には、以下のステップがある
  • 要件定義
  • 設計
  • 開発(実装)
  • テスト
• 本書では、設計の工程にフォーカスする
• データ設計がシステムの品質を最も大きく左右する
  • なぜなら、ソフトウェアはいわば「データの流通機構」だからだ
• DOA：データ中心アプローチ
• POA：プロセス中心アプローチ
  • 現代ではDOAが主流
• 3層スキーマ
  • ① 外部スキーマ
    • ユーザーから見たデータベース
  • ② 概念スキーマ
    • 開発者から見たデータベース
  • ③ 内部スキーマ
    • DBMSから見たデータベース

第2章 論理設計と物理設計

• 概念スキーマを定義する設計を論理設計と呼ぶ
• 論理 = 物理的な制約にとらわれない、という意味
• 論理設計
  • 論理設計は、以下の順で行う
    • 1. エンティティの抽出
    • 2. エンティティの定義
    • 3. 正規化
    • 4. ER図の作成
  • エンティティの抽出
    • エンティティ = 実体
    • そのシステムで、どのようなデータを扱いたいか、を考察する工程
  • エンティティの定義
    • 各エンティティがどのようなデータを保持するかを決める工程
    • エンティティはデータを「属性」で保持する
    • 属性 = 列
    • ある特定の値を決定するための列を「キー」と呼ぶ
  • 正規化
    • normalization
    • エンティティ（テーブル）について、システムでの利用がスムーズに行えるよう整理すること
    • データの更新が整合的に行えるように、エンティティのフォーマットを整理する
  • ER図の作成
    • Entity-Relationship Diagram
    • 正規化をするとエンティティが増える
    • 増えたエンティティ同士の関係を表現する図を作成する工程
• 物理設計
  • 物理設計は、論理設計の結果を受け、データを格納するための物理的な領域や格納方法を決める工程
  • 物理設計は以下のステップで行う
    • 1. テーブル定義
    • 2. インデックス定義
    • 3. ハードウェアのサイジング
    • 4. ストレージの冗長構成決定
    • 5. ファイルの物理配置決定
  • テーブル定義
    • 概念スキーマを「テーブル」の単位に変換する工程
    • 成果物は「物理モデル」と呼ばれる
  • インデックス
    • インデックスについて決める工程
  • ハードウェアのサイジング
    • ストレージ容量を決める工程
  • ストレージの冗長構成
    • 冗長化のための技術が「RAID」
    • Redundant Array of Independent Disks
    • RAID0、RAID1などの種類がある
    • 可能であればRAID10を採用すること
  • ファイルの物理配置決定
    • データベースには以下のファイルが存在する
      • データファイル
        • SQLが参照・更新を行うファイル
        • アプリケーションからは「テーブル」として見えている
      • インデックスファイル
        • テーブルに対するインデックスが格納される
      • システムファイル
        • DBMSの内部管理に使われる
        • 基本的に、アプリケーションやユーザーがアクセスすることはない
      • 一時ファイル
        • 例えばSQLのサブクエリを展開したデータや、ソートデータなど
        • 処理が終了すれば削除される
      • ログファイル
        • SQLは、データをすぐに更新するわけではなく、一度ログファイルに格納される
        • バッチでデータを更新している
• バックアップ設計
  • バックアップには、以下の3種類がある
    • フルバックアップ（完全バックアップ）
      • 全てのデータをバックアップする
      • 利点はシンプルで分かりやすいこと
      • 欠点はバックアップの時間が長い、リソースへの負荷が高い、サービス停止が必要になること
    • 差分バックアップ
      • 差分のみバックアップする
        • 利点はデータ量が少なく済む
        • 欠点はリカバリ手順が増えること
        • 毎回、フルバックアップとの差分を取っていく
    • 増分バックアップ
      • 基本的には差分バックアップと同じ
      • 毎回、前回のバックアップとの差分を取っていく
  • どのバックアップ方式を採用するかは、トレードオフを加味して判断する必要がある

以上です。

3章以降については、次回の記事でお伝えします。