楽々ERDレッスン
データモデリングについての初心者向け本
テーブル設計について
Railsでのschema設計と思想が近い感じ(基本テーブルにUIDを設定するとか)がしてRailsプログラマには合いそう
関数型ドメインモデリングを読んでイベントストーミングを使った業務の洗い出しとモデリングのHow-toに結構感銘を受けてたけど大昔から普通に存在する手法だったんだ エンティティ
イベント系
リソース系
関連系
イベント系エンティティからまずは取り掛かる
各部門ごとのIn/Outに関する動詞をチェック
営業部門なら受注する(In)、見積もりを出す(Out)、納品する(Out)など。
リソース系エンティティは
分類が肝。しかし種類が膨大。いきなり分類作業に取り掛かるのはとても大変。
さらに半年くらいで分類体系が変わることもある(販売チャネルが増えたり)
部門間の調整が必要
イベント系エンティティを先にやりこちらは後回しにした方が良い場合が多い
交差テーブル(俗にいう中間テーブル)は気兼ねなく作る。ビジネスの変化は激しいので柔軟性重視。SQLの性能をこの時点で気にしない。
複数領域に跨って現れるリソース系エンティティ(例えば商品とか)は各領域のものを1つに統合する
ここの統合の設計が長生きするシステムになるかどうかを決める
70年代、手作業だった帳票作成作業を電子化する流れが生まれた
売り上げデータをインプットに帳票を出力するのがメイン業務
ビジネス要望で色々な形の帳票が求められた
売り上げデータを月毎にまとめてソートしたものとか従業員ごとに売り上げ多い順に並べた帳票とか
しかし当時はいちいちそのフォーマット変換プログラムを書く必要があった
ビジネス要望で帳票は求められるがプログラマにコーディングしてもらわないといけなくて大変
大量にデータを抽出し変形しまとめられる仕組みが求められていた
そこでリレーショナルモデルがハマった
エンジニアという特権階級からデータを解放した
欲しい情報を得るためにいかに効率よくプログラムを生産するか?という現状から、いかに無駄にプログラムを書かずに済ませられるか?というパラダイムシフト
ERDを書く = ビジネスの写像を行うということ
物理設計≒インデックス設計
データへのアクセスパスの設計
ビジネスフローにおけるIn/Outの設計から最適なパスを決める。主キーとIDとは別。