実践的データモデリング入門

実践的データモデリング入門 (DB magazine selection)

データモデルは、データのある時点でのスナップショットです。データモデルでは、同一のキーで一意に定まる項目を1つのエンティティにまとめています（関数従属という正規化の原則です）。
エンティティあるいは、個別の属性がいつ（どんなイベントで）発生し、いつ更新され、消滅するのかを見ると、果たしてこのエンティティの分け方でよいのだろうかといった疑問も湧いてきます。このような疑問は、データモデルだけを眺めていただけではなかなか出てきません。システム構築の場数を踏み、対象業務（購買管理・販売管理など）についても知識を有するモデラーは、この作業をある程度頭の中でやっているわけです。
しかし、ここであまりにもプロセス側のことを考慮してしまうと、せっかく作った正規型モデルが崩れ、モデリングの価値が半減してしまうため注意が必要です。この部分は、昔から業務プロセス設計担当者とデータモデラーで衝突するところとして有名です。

これは、CRUD分析についての解説の一節からの引用。「データモデルが先か、データフローが先か」というコラムにおいて、著者は「サイクリックに両方のモデル間を行ったり来たりしながら進めていくのが正解」と指摘している。
AP（データフロー）とDB（データモデル）との対立の構図としてしまうのではなくて、恐らくはサイクリックな検討の先にある中庸の満足解に向けて、如何にして関係者間での合意を得るかというファシリテーションの問題であり、そこでのブレない評価軸を得るためにも、対立構造の成り立ちを理解しておくことが必要と感じた。

サブタイプ構造の物理変換

1. 論理モデルのままで1対1で移行
2. 子エンティティにそれぞれ共通属性を付加する
3. 1つのエンティティに統合する

本書にある「論理モデルから物理モデルへの変換」の節についても、同様にファシリテーション上の難しさを感じた。
「論理的にはサブタイプとして表現できる構造を、どのようなテーブル構造に落とし込むか」という問題に対する解決として、本書で上記3つの選択肢が列記されている（各々の特徴が述べられているが、どの選択肢を採用すべきかの指針は明示されていない）。
これは、RDBを採用する以上はどれかを選ばなくてはならない一方で、どの選択肢がベストであるかは、データを利用する処理ごとに順位が相異なることがあるため、全体としてどれを採用するかの合意は難しい問題だと思った。