「達人に学ぶDB設計徹底指南書」を読みました

「達人に学ぶDB設計徹底指南書」を読みました。

達人に学ぶDB設計 徹底指南書

なぜ読んだのか

基本情報を取ったときに読んだ本で、初心に返りたかった。

対象読者

• DBエンジニア
• DB設計を初級者で終わりたくない人

この本で学べること

• リレーショナルデータベースの論理設計と物理設計について

本の概要

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

• 「データベース」と「DBMS」は異なる。「データベース」はデータの集合を指す論理的概念であるのに対し、「データベース」を管理するためのシステムを「DBMS」という。

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

• 概念スキーマを定義する設計を論理設計と呼ぶ。論理とは、「物理層の制約にとらわれない」という意味。ER図などを書いて設計する。
• 物理設計は、論理設計の結果を受けてデータを格納する頼め物理的な領域や格納方法を決める工程。容量、冗長構成、ファイルの物理配置（データベースのファイルをどのディスクに保存するか）などを検討する。
• バックアップ設計とリストア設計についても触れていた。

第3章 論理設計と正規化　〜なぜテーブルは分割する必要があるのか？〜

• テーブルとは、共通点を持ったレコードの集合である。
• 正規化は、データの更新の不都合/不整合を排除するために行う。

• 第一正規形は「一つのセルの中には一つの値しか含まない」
• 第二正規形は「部分関数従属を解消する」ことで得られる。

- 部分関数従属とは、主キーの一部の列に対して従属する関係のこと。
- 結合すると、第一正規形のテーブルに戻すことができる。

• 第三正規形は「推移的関数従属を解消する」ことで得られる。

-推移的関数従属とは、 {社員ID}→{部署コード}→{部署名}のように、テーブル内部に存在する段階的な従属関係のこと。

• テーブルの正規化は簡単だが、「なぜ正規化しなければならないのか」「正規化のメリット」を説明できる人は少ない。

第4章 ER図　〜複数のテーブルの関係を表現する〜

• ER図の書き方について

第5章 論理設計とパフォーマンス　〜正規化の欠点と非正規化

• 正規化とSQLのパフォーマンスはトレードオフの関係にある。
• 正規化すると、データを集計するときに結合が必要になり、パフォーマンスが落ちる。対処法として、テーブルを非正規形の形に戻したり、冗長なカラム（商品数やいいねの数など）を作る方法がある。
• どちらも正解はない。ケースバイケースで実装する。

第6章 データベースとパフォーマンス

• DBMSはSQLを受け取ったあとたくさんの経路の中から最短経路を選択し、SQL手続きに変換する。経路はDBMSがお任せで決めてくれる。
• B-treeインデックスはバランスの良いインデックス。計算量はO(log n)となり、データが増えても検索や更新にかかる時間はほとんど増えない。

第7章 論理設計のバッドノウハウ

• 配列型は利用しない。あとから結合されたものを分割するのは難しい。
• テーブルにポリモルフィズムはいらない。
• レコード単位で分割する「水平分割」をするとどんどんテーブルが増えてしまうので×
• 列単位でテーブルを分割する「垂直分割」は、定期的にデータの同期が必要になるデメリットがある。

第8章 論理設計のグレーノウハウ

• 主キーがないテーブルに主キーを作る方法
• 行持ち、列持ちテーブル
• データクレンジングについて

第9章 一歩進んだ論理設計　〜SQLで木構造を扱う〜

• SQLは木構造を扱うのが苦手。方法としては以下のようなモデルがある。

- 隣接リストモデル
- 入れ子集合モデル
- 入れ子区間モデル
- 経路列挙モデル

感想

今までもDB設計は業務でやったことがあり、本書を読んでいて、「普通に」考えたらそうなるでしょ、「普通に」考えたらそんな設計にはならないのでは？と思う箇所がたくさんありました。しかしながら、この「普通」について、なぜ必要なのか、なぜいけないのかちゃんと考えたことはありませんでした。DB設計の基本を丁寧に説明されている本だと思いました！
三年くらい前に一度目を通した本でしたが、あたらめて読んでみると新しい発見がありました。読んで良かったです。

達人に学ぶDB設計 徹底指南書

ここまでお読みいただきありがとうございました！