はじめに
自分自身以前の記事で「スッキリわかるSQL入門」を読むまでSQLとDB設計の関係性をいまいち理解できていませんでした、というよりSQLを覚えればそれだけでデータ周りは大丈夫なのかと思っていました。
SQLとDB設計は、SQLを覚えることが将棋のルールや各駒の動きを覚えることだとするとDB設計は居飛車などの将棋の定跡のようなもので、実際に実践するにあたってはむしろこちらの知識の方が重要なんじゃないかと感じました。（両方大事だし、将棋知らないのになぜか将棋で例えてしまいました）
そんなこんなで今回、DB設計（データベース）の学習にあたって「達人に学ぶDB設計徹底指南書」を読んだので学んだ内容や良かった点、感想などをまとめたいと思います。
良かった点
SQLに関してはいろんなもので触りだけ学ぶことができたりするのに対して、DB設計を学べる教材などは比較的数が少なく貴重な感じがしますが、その中で本書籍はとてもわかりやすく書いてある印象を受けました。
特にSQLの部分については必要最低限な記述にとどめていて、あくまでデータベースの設計という部分に特化して解説がされている点が良かった。
書籍の中で一貫して著者の考えが書かれていて、もちろんそれに従うのが唯一の正解というわけではないと思いますが、自分のような初学者からするとさまざまな手法の解説だけがされていくより、自らを達人と称する著者が将来的な展望や基本的な設計方針などを断定してくれるのは思考を固める上でとても学びやすかったです。
書籍の図解が必要最低限にとどまっている部分が良かった。これはあくまで個人的に意見なのですが、図解が多い書籍はとっつきやすい反面、情報量が少なくなってしまうのでパラパラめくっていると結局読みたい部分まで見落としたりすることがあるのですが、本書籍は１ページたりとも飛ばしても理解できるような部分がない（言い換えると無駄な要素が少ない）のでしっかり全ページに目を通しました。
学んだこと
データのあとにプログラム（DOA）
本書を読むまではDBはあくまでプログラムの中で必要になる１要素のようなイメージを持っていましたが、それ自体がある種の間違いでプログラムはデータの流れを作るためにあるようなもの、データ中心アプローチであるというくらいデータ設計というのは重要なのだと感じました。
各種の設計とパフォーマンスのトレードオフの関係
DB設計はある種どのような要件に対しても正解に近いようなアプローチがあり、正規化やインデックス作成、その他の工夫を正しく行なっていきそこに近づけるようなイメージがあったのですが、例えばバックアップの設計に関しても、より細かい頻度で行えば行うほどパフォーマンスは落ちていったり、正規化に関してもパフォーマンスを考えると行わない方が良くなる場合などもあり、そういった部分を天秤にかけながら要件ごとに対してのベストを探っていくような作業なのだと知りました。
アナログなデータ→DB設計に落とし込む
例として家計簿などのアナログで作られていたものをRDBの設計に置き換える場合のやり方が書かれていて、実際に実務でやったことがない身からすると学びになりました。またこのやり方を知ったことで自分の身近なものをRDBの形式でDB設計するならどうすればいいのか？などと考えてみたりできるようになりました。
ER図
ER図がいまいち理解できていなかったのですが、本書を読んだあとはIE表記法に関してはある程度書いたり、見て関係性を理解できるようになったと思います。
難しかった点
本書はDB設計というデータベースに関しての内容がメインになっていて、特定の要件定義があり、それをSQLを用いてハンズオン形式でDB設計していく ような内容ではないため、いざこの書籍で学んだ知識をもとに実際のアプリケーションで使うデータベースを設計する場合、SQLの知識と今回学んだDB設計の知識を自分なりに融合させていかないと難しいと思いました。
後半の部分では、すでにDB設計をしていて今より良い手法をもとめている方 のようなレベル感の読者を対象にしていて、自分のようなまだDB設計をやったことすらない人間からすると現実味のない事象の対策を聞いているような感じでした。それでも内容自体は非常にわかりやすくて理解することはできました。
感想
プログラミングの学習を始めてから10冊弱はすでに技術書を読んできたのですが、本書は内容が簡単なわけではないのにスラスラ読むことができ、なぜか今まで読んだ技術書の中で一番好きでした。 まだDB設計自体をそこまでやったことがないので、自作のアプリケーションを作る際などにまた読み返していきたいと思いました。
