読書メモ。2025年67冊目。
『達人に学ぶDB設計徹底指南書 第2版』を読んでの感想となります。（2025/11/3記載）
本の概要
本書は、プロのDBエンジニアである著者が、DB設計の基礎と実践ノウハウをやさしく手ほどきする『達人に学ぶDB設計徹底指南書』の改訂書籍です。
第2版では、初期構成を活かしつつ内容を最新化するだけでなく、クラウドにも対応できるようにしました。
【本書のポイント】
●論理設計の基本から、正規化、パフォーマンスなど、押さえておくべき基礎知識やポイントを幅広く体系的に解説！豊富なサンプル、章ごとの練習問題もあるので、実際の開発現場でも通用する知識を徹底的に身につけることができます。
●やってはいけないアンチパターン、注意すべきグレーノウハウも丁寧に解説。「ただ何となくやってはいけないと分かっている」「なぜかはちゃんと分かってないけど、注意するようにしている」で終わらせず、きちんと「なぜ」を理解して、実務で自信を持って使えるだけの知識が身につきます。・DBエンジニアを目指す人
・DB設計の基礎と実践をしっかり学びたい人
・脱初級を目指すDBエンジニアやアプリケーション開発者
など、DB設計・開発に携わるすべての方におすすめの一冊です。
引用：
動機
- 新規プロダクト開発に伴い0=>1のDB設計を行っている。
- DB設計を学習してから長い時間が経ち、なんとなくの経験則で設計をしてしまっていた。
- 長くエンハンスが求められるプロダクトにおいてDB設計の些細なミスが長期間のノイズになることが分かり、1から再学習したいと思っている。
本書からの学び
DB設計を改めて学び、多くの気づきがありました。
自分が経験則で設計を行っていたことに気付けました。
受託企業でのエンジニア経験が長く、DB設計の経験はあるものの、
システムがリリースされた後に、長期運用されるまでを経験することは少ないです。
そのため、自分の経験則に従うと開発のしやすさに傾きやすく、プロダクトの長期成長といった側面での意識が薄かったことに気付きます。
今、そうしたプロダクト開発に携わり、本書で言われる知識がとても重要になることを実感しています。
自分が知っている設計方法もその背景や意図を知ることで、より適切に取り扱えるイメージを持ちました。
『達人に学ぶsql徹底指南書 第2版』も読みたいです。
忘れたくないメモ
本書で特に印象に残ったポイントをふりかえります。
論理設計
概念スキーマを定義する設計を、論理設計と呼びます。システムの世界では「論理」という言葉がよく登場しますが、それは通常の日本語の意味である「整合的で筋道が通っている」という意味ではなく、「物理層の制約にとらわれない」という意味で使います。
論理設計という言葉をなんとなく「システムの制約に捉われない自然言語で表現できる範囲の設計」程度に捉えていたけど、改めて論理設計がなんであるかを理解できました。
正規化のポイント
正規化によって分割されたテーブルは、いつでも非正規化テーブルに復元することができます。これは正規化が情報を完全に保存する無損失分解だからです。そしてこのことが示すのは、高次の正規形は、低次の正規形を含んでいる、ということです。
正規化について繰り返しの情報を無くすぐらいの考えしかなかったため、
それが可逆的である必要があることは新しい学びとなりました。
サロゲートキーは避ける
一般的な原則としては、極力代理キーの使用は避けて、自然キーによる解決を図るべきです。その主な理由は、代理キーがそもそも論理的には不要なキーのため、論理モデルをわかりにくくしてしまうからです。業務的には不要なキーであるため、代理キーが何の役割を果たしているのかは、ER図を一読してもわかりません。つまり、代理キーは本来「使わなくてもなんとかなる」道具なのです。
昔、何かの書籍で「サロゲートキーを利用すると、将来テーブルに求められる変更に柔軟に応えることができる」と読んだ記憶があります。
それ以来、盲目的にサロゲートキーに対して、なんとなく利用した方が良いものと捉えていました。
ただ、そうしたタイミングがあったとして、それはそれで正規化すべきではないかと思います。
YAGNIの原則と同様に将来発生するかも知れないことに対する仕組みは、発生するかもわからないそのタイミング迄実装上のノイズになる。
正規化をするということ
正規化の結果得られる結論は、整合的なシステムを構築しようとすれば必然的に得られるものです。その意味で、正規形の理論はまったく意外性のあるものではありません。むしろ正規形の理論に対する批判者の言うとおり、ごく当たり前のことです。
しかし、正規化のメリットは、まさにその当然さにあるのだ、というのがディトの反論です。常識を定式化することで誰もが利用可能なツールにすることができ、道を外れた設計を防ぐことができるようになります。
ずっと第一正規形からはじまる正規化の内容を覚えることができずにいました。
理解はできるけど、実践になると繰り返しを排除することが意識に上がり、第一正規形から始まる手段について意識することができていませんでした。
そのため、自分が果たして正しいテーブル設計ができているのかとずっと悩んでいました。
この一文を読んで今までのその悩みをぬぐうことができました。ありがたい。
クエリにロジックをどこまで持たせるか
クエリのわかりやすさというのは意外に開発要件を決める要素として馬鹿にならなくて、あまり複雑なことを SQLにやらせたくないとか業務ロジックはすべてアプリケーション側に寄せたいと考えるアプリケーション開発者も一定数いるのです。SQLが複雑だとのちのちメンテナンスできる人間がいなくなってしまうなどの理由もあったりして、なるべく SQLをシンプルに保ちたいという要望が出ることもあります。
こうした考え方があることもチーム開発を進める上で学びました。
どこまで意識してどこまで意識しないといった開発方針が重要なのかも知れないと改めて思いました。
