「データモデル大全」は良い本だ

渡辺さんの本「データモデル大全」を読んだ。
いろんな気づきがあるので、ラフなメモ書き。

【参考】
業務ロジックをデータモデリングはどこまで表現できるか？: プログラマの思索

渡辺式データモデリングの復習: プログラマの思索

第39回IT勉強宴会の感想～花束を作る花屋の業務モデルをT字形ERと三要素分析法で比較する: プログラマの思索

第62回IT勉強宴会のメモ～２人の方法論者によるデータモデリング激レア対談: プログラマの思索

第66回IT勉強宴会の感想～データモデリングに数多くの流派が発生している理由: プログラマの思索

関西IT勉強宴会の感想～コロナワクチン接種管理システムのデータモデリング: プログラマの思索

【1】「データモデル大全」のデータモデリングは多分かなり高度なので一般でないと思うけど、後で、なるほどと気づく。

たとえば、動的参照関係で、複数のテーブルのビューがあれば、外部キーの参照関係が生じるが、普通のER図では表現できない。

たとえば、「データモデル大全」のデータモデリングでは、ツリー構造のモデルが特殊。
ヘッダーと明細のテーブル二つに親子階層を持たせて、親テーブルにLLCという階層最小値を持たせて、ツリー構造を表現する。
再帰構造ではない。
たぶんこのデータモデルであれば、PLSQLのバッチ処理が書きやすいのだろうと想像する。
他方、Redmine ならば、チケットの階層構造は、入れ子構造のデータモデルで実現できてる。
こっちの方がプログラマは書きやすいだろう。

【2】「データモデル大全」のデータモデリングで最も特徴的なのは、2次識別子を使って、参照関係や連関テーブルを表現してる事。
製品の入出荷履歴などの沢山のテーブルは、受払履歴テーブルに集約させるが、その時に、取引管理番号を各テーブルで２次識別子に持たせる。
そうすれば、最初はNull値でも、後からデータ更新できるので、一意制約を持たせられる。

「データモデル大全」全では、他に、逆に、入出荷指示明細テーブルから受払予定、受払履歴、売上履歴などのテーブルへばらすモデルを作り、指示を出したら、売掛金の履歴や在庫の履歴が見れるテーブルを用意してる。
この辺りは本当にすごいなと思う。

【3】惜しむらくは、データモデルしか記載がないので、どんな業務フローになるのか、どんな画面遷移になるのか、が分かりにくい事。
せっかくなので、このデータモデルからRailsで画面を自動生成して、簡単な画面遷移が作れると良かったのに、と思う。
そうすれば、データモデルの威力が分かるはず。

たとえば、データモデルからイメージできるのは、注文ヘッダ・注文明細の親子関係タイプと注文明細・商品情報の参照関係タイプがあれば、それらは一つの帳票を表す。
よって、データモデルから、本質的な帳票がいくつあるのか、を見抜けば、帳票を保守する画面数やバッチ処理本数を算出できる。

たとえば、データモデルから時系列の順序を導くのは、T字型ERの考え方を使って、トランザクション系テーブル同士に参照関係があれば、1：Nの関係があるので、先トランザクションテーブル：後トランザクションテーブル＝1：Nとみなすことで、導ける。
よって、時系列に帳票が作成される順序を考えれば、業務フローが描けるはず。

この辺りのイメージはまたまとめてみる。