データモデルKata

社員-部門

非依存のリソース同士のリレーションシップなので、間に交差エンティティを置きます。

https://gyazo.com/45e8baed637e08e90d06188dc485b191

社員は退職しても別のイベントデータと関連付けされているので、消せないことが多いでしょう。ただ氏名等個人情報に関わるものは持たないようにしなくてはならないので、サブタイプで区別します。

商品-注文

リソース、イベント間の典型例です。

https://gyazo.com/95284f7c8134cb7fb3e94b744f037c02

イベントと関連づいたリソースは業務上消せなくなります。商品は属性が変わりやすい(特に価格)ので世代管理が必要です。

商品の論理的な一意性は、「商品コード」が持ちます。

「現在購入可能な商品」は、未来の適用開始日を入力可能なので、日が変わるときに自動で反映出来なくてはなりません。したがって、基準日がきりかわるタイミングでMVIEWリフレッシュなどで反映させていく必要があります。

「現在購入可能な商品」を利用するシステムの典型はコンシューマ向けのECサイトで、そもそもRDBじゃなくて検索エンジンをデータソースにすることが多いので、その場合商品とのリレーションは論理的なものになります。

ワークフロー

予算執行承認など企業内でありがちなワークフローの典型的モデルです。

https://gyazo.com/d1985d1204bfd8051d3b4da676ea90a8

ログイン

ユーザログイン自体を実装することは、少なくなってきているが、もし実装することがあれば、最終ログインのようなイベントのデータはユーザエンティティには持たせてはいけない。

https://gyazo.com/897881432eb5f6db66d17d42c1ec4f0e

属性の可視性(WIP)

人材マッチングサービスなどにおいて、選考が進むにつれ、その人物の属性の開示範囲が変わるということがある。これは論理モデルとして明確にサブモデルを書き出しておく。