web + dbpress 「実践データモデリング」 を読んだら、いろいろ腑に落ちた
とても良かった。設計に対していつも徒手空拳というやつで自信がなかった。みんな何を基準にテーブル設計の良し悪しを決めているのだろう、どうしてテーブルを分けるという判断をしたのだろうか、といつももやもやしていた。それに対するひとつの明確な答えが得られたので、少しは設計について明るくなった気になれた。ただ難しいので、うまく整理できないまま、アウトプット。
良いデータモデルとは、筆者によれば、成果物としてのモデルはもちろんのこと、顧客（自分たち自身も含めて）の要求の穴などを発見することができることを指す。なるほどそうなのか。確かにいざ実装しようとする段になって、この場合どうするのか？と対話することが多々あるが、あれを前もって洗い出すことができれば開発がしやすい。エンティティを特定するには、単一性、同一性、カテゴリという観点で洗い出すよい、という抽象的な理論を、図書館の予約の具体例を用いて、図書には、「蔵書」というエンティティを発見するくだりはとてもわかりやすかった。こうやって洗い出すのか、と体でわかった気がする。エンティティをひとつに絞り込むのは見かけほど簡単ではない、そういう心構えでいる必要がある。
複雑なものをシンプルに、という姿勢を貫くことが大事のよう。何がシステムを複雑にするのか。筆者は「更新」だという。これはひとつの衝撃だった。そうなのか！と。たしかに、あるデータに、複数の人間が、複数のタイミングでデータ更新ができるような状態だと、処理の条件分岐が増えることがある。そっちの更新の経路は考慮してないよ！みたいなことがある。コードが複雑になる。更新に注意を払うことを覚えた。
システムが扱う情報はリソースとイベントに分類できる。たとえばリソースは社員で、イベントは出世や退職のこと。社員は入社イベントで生成され、出生イベントで変更され、退職イベントで消滅する。なるほど、わかりやすい。で、イベントは更新しない、というのがイミュータブルデータという筆者の考えたデータモデリングの方法のよう。その手法はステップに分けられている。エンティティの抽出して、まずはリソースとイベントを分類する。日時属性を持つものがイベントに分類される。なるほど、そこに着目すればいいのか。それから、イベントは日時属性が一つになるように精査する。複数あれば別のイベントのエンティティとして設計する。再度リソースにイベントが隠れてないか精査する。最後にエンティティのリレーションを考える。というようなステップ。やはりイベントを探す、ということが大事らしい。更新につながるからだ。
また、単一のコンポーネント（エンティティのことかな）に含まれる複雑さ（複数の概念や責務）を分解することは、古くからの設計原則の高凝集や単一責任原則につながる、という指摘は、特集での学びが蓄積された経験の延長線にあることに気づけてとても良かった。巨人の肩にいるのだという安心感がある。
はじめてデータモデリング、というものに触れた。DB設計での悩みがいくぶん減った感覚がある。もっと設計というものに敏感になりたい。複雑なものをいかにシンプルにするか、という姿勢は、何もデータモデリングだけではなく、広く日常生活や別の業務でも役立ちそうだ。理解不足の点があるかもしれないので、何度も立ち返って読みたい。
（了）
