🤖

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

2023/04/27に公開

idea

タイトルの通り本を読んだので、感想や理解したことを書いていきたいと思います。

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

昔はプロセス中心のアプローチが選択されていたが、現代ではデータ中心のアプローチが選択されるのが主流です。
データーベースの設計は大きく分けて、下記の三つのステップで行っていきます。

外部スキーマ：テーブル、ビュー（画面、データ）
ユーザ、利用者からの見え方を定義するスキーマ
概念スキーマ：テーブル定義（データの要素やデータ同士の関係）
開発者からの見え方を論理的に定義するスキーマ
内部スキーマ：データの物理的配置（テーブルやインデックスの物理的定義）
DBMSからの見え方を物理的に定義するスキーマ

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

データベースの設計は大きく分けて下記の流れで実施する。
概念スキーマ（論理設計）→内部スキーマ（物理設計）

論理設計は下記のステップで実施する。
エンティティの抽出→エンティティの定義→正規化→ER図の作成

ストレージの冗長構成は下記の様なものがある。
効果としてはRAID10が優秀だがコストがかかるため、その効果が本当に必要か？を考えたうえで選択する必要がある。あまり効果のないものにコストを支払っても無駄になってしまう。

RAID0 二つのディスクに分散してデータを格納する：I/O性能の向上
RAID1 二つのディスクに同じデータを格納する：冗長性の向上
RAID5 三つのディスクにデータ、パリティ（データを復元できる情報）を格納する：I/O性能、冗長性の向上
RAID10四つのディスクを利用し、二つのディスクに分散したうえで残りの二つにミラーリングを行って格納する：I/O性能、冗長性の向上

バックアップの方式には３種類あります。
フルバックアップを行うことでリカバリに対するコストは小さくなるが、逆にバックアップにかかるコストは大きくなる。どのバックアップにおいてもトレードオフの関係は発生するので、状況に応じて選択、組み合わせて使用することが大事になってくる。

フルバックアップ：全てのデータをバックアップする
差分バックアップ：前回のフルバックアップ時点との差分をバックアップする
増分バックアップ：前回のバックアップ時点（フルバックアップ以外も含む）からの差分をバックアップする

第三章論理設計と正規化

ボイスーコッド正規化、第四正規化、第五正規化といった高次正規化というものがあることを知りました。ただし、第四正規系、第五正規系については特段意識しなくても関連エンティティの作り方を意識していれば自然とクリアできることがわかったので記憶にとどめておくレベルでよいかと思いました。

第四章ER図

これまで自分自身で作成ルール自体はそれほど難しくなくIE記法では下記の3種類で簡単に表現できることを学びました。

第五章論理設計とパフォーマンス

正規化を行うことで高いのデータの整合性を得られるがパフォーマンスは低下するというトレードオフが発生します。
基本的には正規化を行っていき、非正規化は許容するべきではない。非正規化を行うのは最終手段として利用するべき。

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

インデックスと統計情報でパフォーマンスを改善することについて学習ました。
インデックスについて下記のような特徴があります。

アプリケーションのコードに影響を与えない
データに影響を与えない
性能改善の効果が大きい

このような特徴からインデックスはパフォーマンスが悪かった場合に改善行をうための手段としてとても扱いやすいです。
インデックスは種類があるが、基本的に利用されるインデックスはB-treeインデックスが使用されます。インデックス毎に特徴がありますがB-treeインデックスは全体的なバランスが良いというのが特徴となります。
Btree-インデックスの注意点としては下記の様な場合には効果が発揮されないという点です。

列に対して演算を行っている
列に対して関数を利用している
IS NULLを利用している
否定形を利用している
ORを利用している
後方一致、中間一致のLIKEを利用している
暗黙の型変換を行っている

上記の様に様々な条件によりインデックスが効果を発揮しない状態が発生します。
SQLを書く際には常にパフォーマンスのことを念頭に置きながら考えることが大事だと感じました。

統計情報を元にオプティマイザが最適と思われる経路を選択し、実行します。
統計情報で設計すべきポイントとしては、収集を行うタイミング、対象についてです。
基本的な指針としてはデータが大きく更新されたら速めに統計情報の更新を行うことです。

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

よくない論理設計について学習しました。これまでの現場で見かけたことがあるものもありちょっと親近感がわきました。
全体的に共通して感じたことはメリットあるように感じたとしてても、基本的な思想に反するようなことは極力やるべきではないということです。
他の代替手段はないか？ということをよくよく検討することが重要だと思いました。

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

第七章と近しいと内容となっていますが、バッドノウハウとまでは言えない微妙なラインの設計について解説されていました。
悪いとは言い切れないテクニック等が説明されていましたが、やはり共通する点としては多様することで設計が複雑になっていくので利用する際は本当に必要なのか十分に検討を行うことが大事だと感じました。
基本に忠実にシンプルに設計を行っていくのが良いかと思いました。

第九章一歩進んだ論理設計

SQLでの木構造の扱い方について解説している章でした。
木構造の作り方、たどり方等、様々な考え方がありおもしろかったが知識を使う機会あまりこないのかなと感じました。
リレーショナル型の欠点を克服するために、さまざまなNoSQL型のデータベースをでてきているので今後も情報をキャッチアップしていくことが大事だと思いました。