システム開発・刷新のためのデータモデル大全

『システム開発・刷新のためのデータモデル大全』（渡辺幸三*1，日本実業出版社，2020年9月20日）を読了。

論理フィールドの値を DB 上で物理的に保持しておく必要はありません。なぜなら，それらの値は物理的に記録されているデータを組み合わせることで，必要に応じて算出できるからです。このように「物理的な記録の実体を伴わない」という意味で，それらは「論理フィールド（導出フィールドや仮想フィールドとも）」と呼ばれます。（位置 No. 243）

論理フィールドのことを覚えておこう。

「名称」やある種の「コード」は，それらが変化する可能性があるゆえに，マスター系テーブルの主キーとしては向いていない。いったん値が与えられたらレコードが削除されるまで変化しない項目が主キーには向いている。（位置 No. 528）

何が主キーとして向いているか考えよう。

このモデルに新たに導入された「品種」は，「オプショナル属性の組み合わせが同一であるような商品グループ」くらいの意味合いですが，それまでのユーザ企業の誰もが想像したことのない概念である可能性があります。ここらへんはまさにデータモデリングの醍醐味といっていいところで，新たな概念を創出して既存の概念（テーブル）と組み合わせることで，より合理的な情報管理の枠組みが生み出されます。（位置 No. 1827）

実際の物事を抽象化した新しい概念を創出し，合理的な情報管理の枠組みが生み出すことがデータモデルの醍醐味か。

筆者は年間 100 冊以上読むほど本好きなのですが，高校時代に身についたその習慣が，職業生活でどれだけ役立ったかわかりません。まわりを見渡しても有能な IT 技術者は例外なく読書家です。ぜひ学生時代のうちに，遅くても 20 代までに読書を習慣化することをお勧めします。5 年もたてば，その習慣を持たない同僚と明確な差がつくでしょう。（位置 No. 2146）

私も 20 代までに読書を習慣化できた。読書を習慣化できたことは，本当によかったと思う。

出来の良いシステムは「出来の良いアプリ」ではなく「出来の良いデータモデル」を基礎としています。そして，アプリの出来は専門家でないとわかりませんが，本書を一読すればわかるように，データモデルのわかりやすさや巧拙についてはエンドユーザにも判定できます。ところが，データモデルさえ整備されていないシステムが多いのが実情で，そういうものを納品されるとユーザ企業は何十年も無駄に苦しむ羽目になります。（位置 No. 3006）

「出来の良いデータモデル」になっていれば，出来の良いシステムにできる。

だからデータモデルはしっかり考えて，エンドユーザにもわかってもらう。

dbconcept.hatenablog.com