『事業分析・データ設計のためのモデル作成技術入門』を読んだ感想
『事業分析・データ設計のためのモデル作成技術入門』を読み終わった。
元々、フロントエンド・小規模のアプリ開発からエンジニアキャリアをスタートして今日に至るので、どうにも「モデリング」の様なレイヤーの話に疎く、衝動買い基礎的な知識を学ぶ為に購入。
結論から言うと、自分から読みたいと思うぐらいに面白い内容で、非常に読んで良かったと感じている。
（デファクトスタンダードなやり方ではないのは承知だが）
数学の理論や手続きに則って「誰がやっても同じモデル図が出来る方法論・技術」がまとまっていた。
以下、簡単な感想をつらつらと。
徹頭徹尾、数学の話だった。
本の中ではいわゆる Entity という言葉が出てこなく、全て集合や元など数学に基づいた考えに基づいてモデル分析をしていく手法がまとめられていた。
大まかには以下の通りの様な話が展開されている。
- 事業上登場する事柄は全てモノ（事態・事物）として扱う
- 事業活動は５種類に分類され、それに対応する5種類の管理業務がある
- 管理業務上、管理したい事柄には必ず識別子が存在する
- その識別子ごとに正規化したモノを作り、Event（日付を基に並べることができるもの）Resource（辞書的な規則に則って並べられるモノ）に分類する
- それぞれのモノの関係を基に文法・論理規則に当てはめて成り立つかどうかを関係論理に基づいて図式化していく（合わせて、実務に合わせた知識・補足がされている）
完全に定義・概念・計算方式が確立されていてモデルの作成にエンジニアの解釈が必要無く、誰がやっても同じモデル図になるとのことだった。
また、曰く出来上がったモデル図はそのまま DB 設計に置き換えても動くとのこと
（INDEX ONLY, ADD ONLY で DB 作成する。著者の経験＋観測範囲ではパフォーマンス問題に出会ったことがないらしい。）
これだけ聞くと魔法の様な話だが、実際にその関係式が充足されるのか否かを判断・判定する必要があるから完全に属人性が排除される訳ではない。実際の業務知識が無いと正しい図は作れない。 それに補助資料も多いので相応のコストもかかる印象だった。
ただ、この本に書いてある知識・考え方は普遍的なものだと思うし、直接この方法で分析・設計を行わずとも役に立つ知識だったなぁと思う。 （迷惑かからない小規模アプリを作ることがあれば、試してみたいなと思う。）
「構文論が先で意味論が後」
上記の数学の話と被るが、書籍の中で繰り返される「構文論が先で意味論が後」という話が凄く印象的だった。
まず「文法・論理規則・関係（関数）として正しいか否か 」が常にあり、「真とされる値が本当に充足されるかどうか。」は後から判断する、という話。
例えば、R(受注, 発注) の関係は支払い請求、R（発注、受注）は先払い、R(受注, 発注) も R（発注、受注）も論理的には成り立つけど事業上存在するかは別な話だよね、という感じ。
本当に知識ゼロと言っていいぐらいの身としては、これぐらい形式だった手法を学べるのはありがたいなぁと思った。
事実：情報は1:N、情報:モデルはN:1
数学の写像の話に基づいた説明をされて「なるほど」となった。
1:N 関係は関数（写像）にできないけど、N:1関係は関数に直せる、という話。
今よりももっと何も知らなかった頃は「Entityって実体だよな、実体を1:1に表す、、、訳ではないけど、どう解釈すれば良いんだ？」という疑問が絶えなかったので、ようやく一番論理的な理解が得られた。
そもそも「Entity は ID を基に同一性を判断できるオブジェクト」って定義でもあると思うので、改めて全然とんちんかんな疑問を抱いていたなぁとも気づいたり。
総じて自分は相性が良かったし、相性が良さそうな人にはオススメ
繰り返しになるが、DB の設計手法として使うかは別として、モデリングや事業分析の為の普遍的な考え方・基礎知識を学べる書籍として本当に良かった。
色々とモデリングに対する誤解が解けたり、正しい知識が得られたと思う。
もう一週ぐらい読み直して、自分に定着させたい。
また、相性が良くない人は全然受け付けないと思うが、相性の良さそうな人は凄くしっくりくると思うので是非オススメしたい。
ところどころ、数学や哲学、ないしはコッド先生の話など歴史の話題が多かったり、今の手法にたどり着くまでの悩みなどもあるが、その辺りの癖を掴むと非常に読みやすいと思うのでご興味ある方はご参考までにどうぞ。
