More Related Content
Similar to イミュータブルデータモデル(入門編) (20)
More from Yoshitaka Kawashima (20)
イミュータブルデータモデル(入門編)
- 6. Step1 エンティティの抽出
発送担当者が受注リストをもとに、商品の在庫を確認し、在庫が あれば商品を発送する。
① 要求仕様の「動詞」を抜き出しエンティティとする。 ② ①に関わる「名詞」を抜き出しエンティティとする。 ③ エンティティ間の関連に線を引く ④ 属性や候補キーも分かる範囲で書いておきます。
間違い!
この段階で実装をプロパティファイルにするとか、Enum にするとか決め打ちでエンティティとして表さないのはや めましょう。
まず、はじめにエンティティを抽出します。
- 9. Step2 エンティティの分類
会員ID
姓
名
郵便番号
住所
電話番号
注文番号
注文会員ID
注文日時
注文
会員
リソース
イベント
洗いだしたリソースとイベントに分類します。 基準は属性に”日時” をもつかどうかです。 または、Step1の①の動詞から抜き出したエンティティは“イベ ント”に、②の名詞から抜き出したエンティティは“リソース”に なるはずです。
- 11. Step3 イベントエンティティは1つの日時属性 しかもたないようにする
受付番号
注文会員ID
注文日時
注文確認者
注文確認日
請求書出力フラグ
入金予定日
入金日時
入金者氏名
登録日時
更新日時
キャンセル日時
キャンセル取消日時
発注
注文番号
注文会員ID 注文日時
注文
発送指示ID
発送指示者
発送指示日
注文番号
発送指示
One fact in one place.
…
- 15. Step4 リソースに隠された イベントを抽出する
会員ID
姓
名
郵便番号
住所
電話番号
会員
リソースエンティティに更新日時を持たせたくなるのは、リソースにまつ わるイベントが洗い出せていないことが原因と考えます。
•何かトラブル起こった時に原因をトレースす るため会員が自分自身で会員情報変更ページ から変更する。
•規約に違反した会員であったため、お客様セ ンターのオペレータが強制退会を行う。
•会員からの誤った退会をしてしまったが、取 り消してほしいとの問合せを受けて、お客様 センターのオペレータが会員の復会を行う。
更新日時
- 16. 会員ID
姓
名
郵便番号
住所
電話番号
会員
会員変更ID
会員ID 姓 名 郵便番号 住所 電話番号 変更日時 変更イベントID 変更理由
会員変更
大抵の会員を管理するシステムではこういうモデルになるのでは ないでしょうか?
- 18. リソースは、イベントによって引き起こされる属性の変化の
一時点でのスナップショットである。
会員ID: 001
姓: Kawashima
名: Yoshitaka
郵便番号: 111-XXXX
住所: 東京都台東区
電話番号: 090-xxx-xxx
会員ID: 001
姓: Kawashima
名: Yoshitaka
郵便番号: 111-XXXX
住所: 東京都台東区
電話番号: 070-xxx-xxx
会員ID: 001
姓: Kawashima
名: Yoshitaka
郵便番号: 167-XXXX
住所: 東京都杉並区
電話番号: 070-xxx-xxx
電話番号変更
住所変更
業務的に計画された更新がない、または更新のイベントをトレースする必 要がない、場合に限り、このスナップショットだけを変更イベントをもた ないリソースエンティティとして定義される、と考える。
- 19. Step5 非依存リレーションシップを 交差エンティティにする
リレーションが非依存である場合、外部キーにNULLを許し、後でアップ デートすることが可能になってしまいます。 こうした要求の裏には、別のイベントが隠れていることがあります。
プログラマID
姓 名 プロジェクトID (FK)
プログラマ
プロジェクトID
プロジェクト名
プロジェクト
プログラマは、担当するプロジェク トがなくても、存在しうる。
「アサイン」というリレーション シップが間にあるのでは?
- 20. R-R間の交差エンティティ
社員ID
姓 名 部門ID (FK)
社員
部門ID
部門名
部門
新人が部門に配属されたら部門IDに
値を入れる。
社員ID
姓
名
社員
部門ID
部門名
部門
部門ID 社員ID
配属日
配属
配属イベントが潜んでいる。
- 21. E-E間の交差エンティティ
請求ID
請求日時
請求書宛先
請求金額
受注ID
受注日時 請求ID
受注
請求
請求ID
請求日時
請求書宛先
請求金額
受注ID
受注日時
受注
請求
複数の受注をまとめて請求する。
受注ID
請求ID
受注-請求
対応する請求のデータができたら請求IDに 値を入れる。
(時系列の逆転したリレーション)
E-E間の場合は、イベントが潜むのではなく、対応表が必要に なる。時系列の逆転が起こらないように設計する。
- 22. 交差エンティティは多対多の場合だけのものではない
B
A
ER図で、このような形だけみて、「エンティティAとエンティティBは、 多対多じゃないんだけどっ!」というカーディナリティだけでリレー ションシップを決めてしまう人がいます。
重要なのは、非依存リレーションシップということは、互いに独立に 存在しえて、何らかのイベントによって、それらに関係性が作られる という、このイベントが何か洗い出せているか? という点です。
これをやらずに、カーディナリティだけでリレーションシップを考え ると、業務上必要だったイベントエンティティを見落としてしまうこ とに繋がりかねません。