『達人に学ぶDB設計』を読みました!
はじめに
『達人に学ぶDB設計』を読んだので、その感想をまとめていきます!
良かったところ
タイトルの通りDB設計について深く知ることができる
正規化、ER図などなんとなく理解して作成したり行っていたことを、具体的な例を交えて解説してくれていたので、理解が深まりました。
わかりやすい
DB設計の本で難しいだろうな……と構えていたんですが、文章が読みやすく、難しいところは少しありましたが、概ね説明がわかりやすかったです。
学んだこと
正規化
第1正規形から、第5正規形まで解説されています。
正規化については、他の本でも説明がある場合が多いですが、じっくりと解説されていてこういうことだったのかと改めて学ぶことができました。
各正規形の定義を明確にし、その正規化を行うべき理由、行わない場合はどんな問題があるのか、などが解説されています。
各正規形の定義
本では、第3正規形までは原則として行うとしているので、その定義をまとめます。
正規形 | 定義 |
---|---|
第1正規形 | 一つのセルの中には一つの値しか含まない |
第2正規形 | テーブル内で部分関数従属を解消し、完全関数従属のみのテーブルとする |
第3正規形 | 推移的関数従属の解消 |
従属
部分関数従属
主キーの一部の列に対して従属する列がある
完全関数従属
主キーを構成するすべての列に従属性がある
推移的関数従属
テーブル内部に存在する段階的な従属関係
非正規化とパフォーマンス
正規化と検索SQLのパフォーマンスは強いトレードオフの関係にあります。 厳しく正規化をすればパフォーマンスが悪化し、パフォーマンスを良くするために非正規化すればデータの不整合が生じやすくなります。
論理設計のバッドノウハウとグレーノウハウ
論理設計のバッドノウハウ
論理設計でやってはいけないことです。
- 非スカラ値
- 値に配列型を利用すること
- ダブルミーニング
- 列が途中で値の意味が変わること
- 単一参照テーブル
- 一つのテーブルにすべてをまとめる
- テーブル分割
- 不適切なキーを用いる
- ダブルマスタ
- 同じ役割を果たすはずのマスタテーブルが2つ存在する
論理設計のグレーノウハウ
節度ある利用をするのであれば有効に作用するものの、利点と欠点のバランスを身長に考える必要があるノウハウのことです。
- 代理キー
- 主キーが決められない場合などの代替手段
- 列持ちテーブル
- 配列型は使えないけれど、配列を表現したい場合
- アドホック(場当たり的)な集計キー
- 多段ビュー
難しかったこと
第9章
第9章は、一歩進んだ論理設計でSQLで木構造を扱う、という内容でした。
隣接リストモデル、入れ子集合モデルなどが解説されているのですが、いまいちSQLと結びつけるのが難しく……
一通り読んだものの、内容は半分も理解できていないので、繰り返し読み直して理解したいところです。
まとめ
DB設計に関する本ははじめて読んだのですが、実際に設計を行う際に参考になりそうなことばかりでした。
更に読み込んで、設計どんどん活かしていきたいです。