データモデル分割ルール 2024

データモデルを作る時の分割のルール
RDBだったり色々なのがほぼ同じパターンに収まる

前提

モデルを作る時には同時に業務フローを把握すること
業務フローの把握の手順は「RDRA 2.0」がお勧め
RDRAは「手順」になってるので再現性が高いため

データモデルに名前を付けておく

業務フローを把握すると並行して扱うデータモデルが出てくる
業務上で使う名前を付けておく
この段階だと業務で使う名前のみ利用する

データモデルをある程度正規化しつつ、状態を最大１つになるように分割する

この段階では完全な第三正規化は不要なので
データモデルが複数の状態を持ってないことを大前提にモデルを分割する
モデルを分割していくと業務フローの業務自体が分かれたりすることがあるのでそこも分けていく

なんでモデル分割するために業務フローを分けるのか？

その業務自体が複数の役割を持ってることが多いため
複数の役割をもつ業務よりも単一の業務に分割してく方が良い

データモデルを分類する

システムの中ではデータの更新頻度が低いもの

一般的にマスタデータと呼ばれることがあるものがこの分類

マスタデータの履歴

他のデータから参照される時に、「ある時点のデータ」を常に参照する必要がある場合は、マスタデータには履歴が必要
履歴の保持方法は別のテーブルへのバックアップが推奨方法
マスタデータには常に履歴が必要とは考えないこと

更新頻度が高いデータ

一般的にトランザクションデータと呼ばれる
トランザクションデータの扱い方として更新主体でデータを扱う方法が多い
この方法だとある時点の時間で集約したいとかの処理が複雑になりやすい（そして履歴が必要になる）

トランザクションデータ

登録した情報をなるべくそのままの形で保存する
簡単な状態遷移を持つこともある

集約データ

複数種類・複数の数のトランザクションデータを集めて集約したデータのこと
たとえば、トランザクションデータがポイントの付与・利用だとすると集約データは個人のポイント数みたいになる
トランザクションデータを再計算すれば常に最新の状態が取得出来るのがポイント
トランザクションデータを更新・削除しても再計算すれば常にその時点の状況が判断できる
さらに集約データを特定時点のもので再現したい場合もトランザクションデータの状況さえ合わせれば可能
デメリットとしては集約データはSQLを使う事が多いのでそれなりに複雑になりやすい

集計

各種データを特定の軸で集計した物
月間売上高とかそういうの
一般的にSQLで集計する
集計処理がそれほど高負荷にならない場合はSQLでそのまま返す形

履歴

変更がほぼなくひたすら保持し続ける事に意味があるデータ
たとえばECサイトの買い物履歴とか
トランザクションデータとかマスターデータから必要ない情報を削った別のデータとして用意するのがお勧め

パラメータ

アプリケーションが動作するときに必要になる色んなパラメータ
可能なら環境変数などで渡した方が良い

アクションとアクション履歴

システムが後から何かする為のデータ
非同期でメールを送るとかWebhookを呼び出すとかそういうときに利用
一定期間で削除する前提で作る

データモデルの分類に合わせてモデルを分類していく

業務的なデータの目的に合わせて分類する
さらに必要なデータモデルを追加したりしていく

正規化して必要な項目を追加する

ここまでで軽い正規化までは出来てるはずなので
第三正規化しつつ、必要な項目を追加する