エンティティ内の属性のライフサイクルを揃える

真野正 実践的データモデリング入門 (DB magazine selection) によると、CRUD分析とは別にIRUN分析というものがあるそうだ。
CRUD分析では、各アクティビティがCRUDするエンティティの中の、どの属性が読み書きされるのかまではわからない。
そこでエンティティの属性レベルまで降りて、各アクティビティがどの属性を Import/Refer/Update/Nullify するのかを明らかにするのが、IRUN分析。

分析の結果、同じエンティティの中で生成／消滅するタイミングが違う属性のグループを見つけたら、エンティティを分割する。
例えば、注文エンティティの中の｛ 配送先氏名, 住所, 郵便番号, 電話番号 ｝が注文発生時点では未確定で、後続の「配送・支払指定」アクティビティで値が入力されるとしたら、注文エンティティと配送先エンティティに分割する。
こうすると、それぞれのエンティティ中の属性のライフサイクルがきっちり揃う。なのでインスタンスの中にnullが発生しない。

10年前に最初の会社でDB設計を一通り教わった時は、属性のライフサイクルを揃えろなんて言われなかったけど（＝nullだらけのDBを作っても何も言われなかったけど）、最近はどうなのだろう。

データモデリング手法の進化の方向

真野氏のやり方を見て思うのだが、データモデリング手法は着実に基底テーブルが増える方向に進んでいるのだな。
昔は主キーに対して関数従属するデータは全部同じ器に放り込んでいた。社員マスタに所属部門コードが入っていてもOK。
現役社員と退職社員を区別したかったら社員マスタに退職済みフラグを追加。ライフサイクルの違うデータ項目が混在してnullが出ても平気。月次データは横持ち上等。

T字形ER手法は resource 間に対照表を導入し、また null 回避のための形式的サブセットや resource 純化のためのVEを追加した。

ABDではさらに event 間にも対照表が導入され、またアクティビティごとに専用テーブルが追加される。

最後はインメモリDBが普及してjoinのコストがタダ同然になり、基底テーブルはコナゴナに（＝第6正規形に）なる。のかも。