達人に学ぶDB設計を読んだ
背景
年末に読んだ。
感想
論理設計と物理設計
物理設計はなかなか馴染みがないので主に論理設計で知識が増えた。
論理設計はドメインをRDBにどういう形で落とし込むか決めることだ。設計にはエンティティの抽出、エンティティの定義、正規化、ER図の作成という流れを踏む。
一方、物理設計はテーブル定義、インデックス定義、ハードウェアのサイジング、ストレージの冗長構成決定、ファイルの物理配置決定、という流れを踏む。サイジングはあまり考えたことがなかったため下記の文章は気づきがあった。
データ量というのは、システムの運用開始から、基本的には増えていきます。
たしかに論理設計でテーブルの関係性だけを見ていると当たり前の話だけどわかってなかったな、と思った。
バックアップ
障害によってデータが失われた時に、それを復旧できるようにしておく必要がある。バックアップには主にフルバックアップ、差分バックアップ、増分バックアップの3種類がある。
フルバックアップは名前の通りデータを全てバックアップしておくこと。しかしバックアップに要する時間やリソース負荷が高く、整合性を保つためにサービス停止が必要など、運用上のコストが大きいという欠点がある。
差分バックアップは、フルバックアップした日以降はフルバックアップのデータとの差分をバックアップすることでフルバックアップのコストを軽くする手法。欠点としてはリカバリ時に差分をひとつひとつ適用させていく必要があるため、オペレーションが手間になるということだ。
増分バックアップは差分バックアップに似ており、フルバックアップした日以降はその日の変更分のみをバックアップする。
リカバリ
定時で行うバックアップだけだと障害発生直前の状態に戻すことができない。そのため、バックアップファイルだけでなく、トランザクションログを使って巻き戻すことが必要になる。
正規化
正規形とは、一言で言うと、データベースで保持するデータの冗長性を排除し、一貫性と効率性を保持するためのデータ形式です。
正規形についてどのようなものなのか改めて理解するきっかけとなった。定義はネットに沢山転がっているので省略。ここでは関数従属について理解が少し大変だったので整理したことを残しておく。
関数従属性
関数従属性は入力により出力が決定するような性質を指す。これはつまり主キーによってレコードが決定するということである。
発展して部分関数従属性というものがある。主キーが複数のカラムで構成されている時、主キーの一部のカラムで決定するカラムが存在するとする。その場合、そのテーブルは部分関数従属性を満たしていると言う。一方、部分的な関係性がなく主キーを構成する全てのカラムによりレコードが決定する場合は完全関数従属と呼ぶ。
最後に推移的関数従属だ。まず、主キーによって決定したカラムがある。そのカラムが別のカラムのキーとなっているとする。この時、主キーとそのキー、そのキーによって得られるカラムが推移的な関係となっている。名前の通りカラムが推移的な従属関係にある声質を推移的関数従属と呼ぶ。
関数従属性は漢字が並んでいてやや読み飛ばしたくなるが、内容はいたってシンプルだ。従属性が中途半端なテーブルに対して直感的に違和感を感じることはあるが、このように言語化され名前を知っていると解釈ができるし腑に落とせるので良かった。
サロゲートキー
アンチパターンやグレーパターンでは「まぁ、そうだな」と思うような悪手がたくさん載っていたが、サロゲートキーがそこに含まれていたのは意外だった。サロゲートキーは論理的なキーであり本来は不要なため、自然キーによる解決をする方が望ましいとのこと。理由は論理モデルをわかりにくくしてしまうため、何の役割を果たしているのか、ER図を見てもわからないから。
これは正直よくわかっていない。サロゲートキーはもはやサロゲートキー自体に意味が生まれていて、そういうコンテクストは共有されているような気がする。ORMのライブラリでもサロゲートキーが前提となっているようなものも多い。むしろ自然キーによる解決をされたテーブルの方が見かけないような気もしている。が、どうなんだろうか。理論的には全て自然キーで決定できるようにエンティティを抽出すべき、という話なのかも知れないが、現実はもっと複雑だと思う。このあたりは、書籍の性質上、主キーは自然キーであって然るべきと言っておく必要もあるのだろうか。
まとめ
正規化をちゃんと整理できたのは良かったなぁと思った。パフォーマンス関連は詳細まで話がなかったため別の書籍も参照した方が良いと思った。パフォーマンスだけで書籍が出ているくらい深遠なので、むしろ簡潔にしたのだと思う。
アンチパターンもひと通り読むことができたので、なんとなく感じていた違和感の名前を知れたのは良かった。
