読書メモ：達人に学ぶ DB 設計

読書メモ：達人に学ぶ DB 設計

November 11, 2023

本書は全９章からなる約 300 ページほどの本で、１〜６章までが DB に関する基本的な事柄の説明、７〜９章が設計に関するノウハウ的な内容になっている。前半部分について具体的には、１章がリレーショナルデータベースに関する説明、２章がデータベース設計にまつわる概要説明と RAID やバックアップに関する説明、３章が正規化、４章が ER 図、５章が非正規化、６章がインデックスやオプティマイザや実行計画に関する説明となっている。書籍名の「初級者で終わりたくないあなたへ」から、この本は中級者向けの事柄を扱ったものと想像していたが、思いの外基本的な内容が多く期待していた内容とギャップがあった。後半の設計に関するノウハウに関してはある程度常識的なものも多い。このような内容を勉強したいのであれば以前に読んだ「SQL アンチパターン」という本が良かった。総じて言うと、データベースエンジニアでなくとも、アプリケーションエンジニアとしてある程度 DB に触れたことがある人であれば、本書はもう必要ないかもしれない。

積読状態にあったものを読了したので、記憶したい内容をメモしておく。

コラム：表形式（タビュラー）モデルではなく関係（リレーショナル）モデルと呼ぶ理由 #

  • 関係には重複するレコードは存在してはならないが、表には存在しても良い。
  • 関係のレコードは上下の関係を持たないが、表の行は上から下へ順序づけられている。
  • 関係の列は左右の順序を持たないが、表の列は左から右へ順序づけられている。

厳密にいうと「表」と「関係」は別物であり、上記の違いがある。このために、リレーショナルデータベース理論の開発者はリレーショナルモデルと名付けたのである。ただし開発者自身、「関係」の概念を説明するときには「表」を例示して説明すると最もイメージしやすいことを認めている。

非正規化のタイミング #

正規化とデータ読み取りのパフォーマンスはトレードオフの関係にある。正規化をすることで冗長性が排除される。冗長性が排除されたデータベースでは不整合なデータが保存される可能性も低減され、さらに更新処理は高速になる（逆にいうと冗長なレコードがある場合、ある項目を更新するためにはその項目を含んだ複数の冗長なレコードを更新する必要がある）。総じて正規化はデータベースを更新処理に対して堅牢、迅速な姿に変える。一方で、正規化されたデータベースから必要な情報を復元するためには結合（join）を多く必要とする。これはデータ読み取りのパフォーマンスを悪化させる紛れも無い原因となる。そのため意図的に正規化を巻き戻す、非正規化という考え方がある。

「非正規化」はあくまでも最後の手段という姿勢で臨むべきである。要するに十分に正規化された設計をあきらめても良いのは、パフォーマンスを向上させるためのその他すべての戦略が要件を満たさない場合だけとするべきだ。

データベース製品には、インデックス、パーティション、シャーディング、マテリアライズドビューなど、パフォーマンスを向上させるための色々な機能がある。非正規化を行う前に、まずはこれらの機能の使用を検討するべきだ。

DBMS がクエリを発行する流れ #

  1. ユーザが SQL を記述し、処理を発行する。
  2. DBMS のパーサ（構文解析器）が SQL を解析し、構文ミスがないかを確認する（SQL に問題があればここでエラーになる）。
  3. オプティマイザがカタログマネージャが管理している「統計情報」を参照したうえで、ユーザの SQL を最適な処理手順に変換する（このとき得られた最適化手順を「実行計画」という）。
  4. 実行計画に基づいて、データベースへアクセスを実行する。

SQL のような言語は（手続き型言語に対して）「宣言型」言語と呼ばれることがあるが、これはユーザが「どのように」ではなく「何を」を指定する言語であるためである。ユーザが指定した宣言は、オプティマイザが手続きに変換しているのである。