達人に学ぶDB設計徹底指南書 を読んだ感想

はじめに

達人に学ぶDB設計徹底指南書を読んだのでアウトプット記事を書いていきます。

学んだこと

第一章

• 3層スキーマ
  • 外部スキーマ
    ユーザから見たDB。
  • 概念スキーマ
    開発者から見たDB。論理設計にあたる部分
  • 内部スキーマ
    DBMSから見たDB。物理設計にあたる部分

第二章

• 論理設計→物理設計の順に行う
• 論理設計のステップは以下
  1. エンティティの抽出
  2. エンティティの定義
  3. 正規化
  4. ER図の作成
• 物理設計のステップは以下
  1. テーブル定義
  2. インデックス定義
  3. ハードウェアのサイジング
  4. ストレージの冗長構成の決定
  5. ファイルの物理配置の決定
• バックアップ設計
  バックアップ方式は、「フルバックアップ＋差分バックアップ」または「フルバックアップ＋増分バックアップ」が一般的。
• リカバリ設計
  • バックアップファイルを戻す作業をリストア、そのファイルに対してトランザクションログを適用して変更分を反映する作業をリカバリ

第三章

• テーブルの構成要素
  • キー
    • 主キー
      • レコードを一意に識別するためのもの
    • 外部キー
      • 外部キーがある場合、データの削除は子から順に行う方が良い
  • 制約
    • NOT NULL制約
    • 一意制約
    • CHECK制約

正規化について

• 正規化とはDBのデータの冗長性を排除し、一貫性と効率性をもったデータ形式にすること。正規形は第5レベルまであるが、普通は第3正規形まで理解すればOK
  • ボイスーコッド正規形：非キーからキーへの関数従属をなくした状態にする。分解時に気をつけないと不可逆な操作となることがある
• 第4正規形：多値従属性が複数存在するテーブルを分割する
• 第5正規形：関連と関連エンティティを1対1になるようにテーブルを分割する

正規化まとめ

• 第三正規形までは行う
• 関連エンティティが存在する場合は、関連とエンティティが1対1に対応するよう注意する
• メリット
  • テーブルの持つ意味が明確になって、開発者が理解しやすくなる
  • データの冗長性が排除で、更新時の不整合を防止
• デメリット
  • テーブルの数が増えるため、SQL文で結合を多用することになり、パフォーマンスが悪化

第四章

• ER図の代表的なフォーマットは、「IE表記法」と「IDEFIX」
  • IE表記のほうが簡素で概略把握しやすい
  • IDEFIXはかなり細かく記述できる
• 1対1
  • あまり見かけない
  • 二つのテーブルのレコードが1対1に対応する場合、二つのテーブルの主キーが一致する事になる為、その場合は一つのテーブルにまとめても問題ない
• 1対多
  • 最も良くあるタイプ
  • 基本的に正規化によって生まれる関連はこのカテゴリに属する
• 多対多
  • RDBのお約束として、基本的に多対多の関連は作ってはならない
  • 中間テーブルを作成して対応する

第五章

• 正規化されたテーブルへのSQLは結合を多用することになるので、非常にパフォーマンスが悪くなる
• 非正規化のリスク
  • 非正規化は、検索のパフォーマンスは向上させるが更新のパフォーマンスを低下させる
  • データのリアルタイム性（鮮度）を低下させる
  • 後続の工程で設計変更すると、手戻りが大きい

第六章

• インデックスは、SQLチューニングの手段として非常よく使う
• 最短距離を探してくれる
  • 「ここに行きたい」と入力するカーナビと同じ
  • コストベース
• 統計情報収集は原則、夜間帯に実施する

第七章

• 非スカラ値
  • 第一正規形すら満たしていない
• ダブルミーニング
  • 列の意味が行毎に違っている
  • レコードは変数ではない
• テーブル分割
  • 水平、垂直分割はNG
  • 集約関数で対応
• 不適切なキー
  • 固定長と可変長を混同して使う
• ダブルマスタ
  • 顧客マスタが複数ある
    • システム統廃合によって起こる

第八章

• 主キーが決められない・不十分なケース3つ。解決策は、代理キー
  • 入力データに一意なキーがそもそも存在しない
  • 一意キーはあるが、サイクリックで使いまわされている
  • 一意キーはあるが、途中で指す対象が変化する
• 代理キー（サロゲートキー）で解決
  • なるべくやらない方がいい。ER図でわからなくなる
• 自然キーで解決
  • タイムスタンプ、インターバルを使用
• アドホック(場当たり的）な集計キー
• 多段ビュー
  • ビューは「クエリの缶詰」
  • DBMSはビューのSELECTとテーブルのSELECTをマージして実行する
  • 「ビューの背後にあるテーブルの存在を、常に意識せよ」
  • ビューは原則として1段にとどめる

第九章

• RDBでは木構造のデータを表現するのが苦手
• 入れ子区間モデルは、いずれ近い将来において主流となるモデルだと予想される

良かったこと

入門書には詳しく書いていないアンチパターンについて学べた。プログラミングよりDBの設計の方が大切であると理解できた

難しかったこと

全体的に内容が難しかったです。

小規模な個人開発もしたことがない為、現段階では全体像が掴みにくかったです。

6~9章は曖昧な部分が多いので都度見直して知識を定着させます。