ABD (Activity Based Datamodel) についてのメモです。
- 1 Seasar Conference 2006 Spring © The Seasar Foundation and the others all rights reserved. EJB3 時代の ERD レッスン ~ Activity Based Datamodel
- 大元になったSeasar Conference 2006のスライド
- システムより前に業務プロセスがある
- DBはシステムの一部であり、ユーザにとって大切なのはUI
- UIの操作にはシナリオがあり、シナリオに沿って動いた結果がDBに入る
- 予定を立てた結果 → 予定データ
- 計画を立てた結果 → 計画データ
- 製品を販売する場合:
- 受注した結果 → 受注記録
↓ 梱包依頼 - 梱包した結果 → 梱包記録
↓ 出荷依頼 - 出荷した結果 → 出荷記録
- 受注した結果 → 受注記録
- 業務と対になるのがイベント系、それ以外はリソース系
- イベント
- 「○○する」と言える、「○○日」がある
- 受注する、受注日 = OK
- 顧客する、顧客日 = NG
- リソース
- 「○○名」と言える
- 顧客名 = OK
- 受注名 = NG
- 「○○する」「○○名」の両方言えないものは属性
- 数量する、数量名 = NG
- 必要項目は出力(帳票)から決める
- 出力に必要な項目がDBにないと駄目
- 出力に必要な項目を入力画面に作る必要がある
- イベント系とは交差エンティティである
- そもそもコッドのリレーショナル理論では:
- ドメインをテーブルと考えると、リレーションはドメインテーブルの外部キー(FK)を集めたもの
- リソースとリソースを結ぶとき、リソースにFKを入れると多対多だけ特殊になってしまう
- 本来はリソースとリソースを結ぶ「何か」があり、それが抜け落ちていると考える
- 例えばリソース「顧客」とリソース「商品」の間には「販売」という関係がある
- 関係を表す交差エンティティで結ぶ
- 交差エンティティはFKと属性と、それ自身のIDを格納する
- IRE (Inter Relational Entity)
- Activityを表す交差エンティティ
- FactにはFKを入れない
- IREは同じタイミングで使うFactをFKとして参照する
- Seasar Conference 2006 Spring (5) - 世界線航跡蔵
- RailsとABDとCRUDとワークフロー - moroの日記
- 気楽に生こうか: データベース設計手法
- 『楽々ERDレッスン』はABDのテキストとして使える