データモデリング エンティティの切り出し
トップダウンによる エンティティの切り出し リソース系エンティティ 企業活動に実際に存在するもの DB構築時に最初からあるかのように扱われる 一般に，「○○マスタ」と呼ばれるテーブルになる イベント系エンティティ 企業活動内の行為（注文，販売，出荷,etc） 注文などから始まり，売り上げまでの一連の活動を考え，その構成要素として同定する サマリー系エンティティ 他のエンティティのインスタンスをまとめたもの
Quiz: リソース系エンティティと イベント系エンティティ 物議をかもしたCSに関して、次のエンティティはリソース系？イベント系？ 開催球場エンティティ リソース系 都市名，収容可能観客数 選手エンティティ リソース系 ポジション，背番号 選手交代エンティティ イベント系 退出選手，新規参加選手 対戦エンティティ イベント系 先攻チーム，後攻チーム
ステップ１：全体ビジネスフローから リソース・エンティティを切り出す （図４-１のような）ビジネス・フロー上のボックス（絵）の部分が候補 ビジネス・フローから抜けているものもあるので注意 名前付け が実は肝心 他と重複がないこと 長すぎないこと 「○○管理」など 意味のない名前 はつけない エンティティ定義を必ずしておく
[補助] なぜ，意味がない？ データベースは情報を管理するためにある． 「売り上げ管理」とするのは，「売り上げ」と書いてあるのと同じ 他には ○○処理 ソフトウェアの世界でデータを処理するのは当たり前！ どう処理するかを書くべき
ビジネス・フローに出ていない リソース・エンティティ 配送センタが配送計画を立てるのに必要 顧客本人の住所 もしくはギフトのときは贈答先の住所 Webサイトで購入予定商品を一時的に入れておくところ
リソース系エンティティの定義 エンティティを抽出した理由が不明となりがちなため
ステップ２： リソース系エンティティの関連付け ステップ２： リソース系エンティティの関連付け 特定のエンティティから関連するエンティティを調べていく 各関連について カーディナリティ を設定 独立か依存か を決定 関連（リレーションシップ）に 動詞 を付加する
1: n n : n
[補助] どうして n 対 n? 書籍卸と出版社 考え方のヒント ひとつの書籍卸は，複数の出版社から本を仕入れる ひとつの出版社は，複数の書籍卸に本を納入する． 考え方のヒント どちらか一方をひとつに固定して，相手が複数あるか考える． 反対側も，ひとつに固定して，相手が複数あるか考える．
ステップ３： イベント系エンティティの抽出 （図4-１のような）ビジネス・フローの中の 業務の流れ を説明した文からイベント系エンティティの候補を抽出 発生順を矢印で表記 やはり， 名前付け が肝心 やはり，イベント系エンティティの定義を必ずおこなう
図４－８
図４－９
ステップ４： イベント間の関連付け 依存関係とカーディナリティを設定 １つの注文に複数の商品があれば，出荷が複数。 注文と出荷は１：多 ステップ４： イベント間の関連付け 依存関係とカーディナリティを設定 １つの注文に複数の商品があれば，出荷が複数。 注文と出荷は１：多 出荷と売り上げは１：１ 売り上げと支払い請求は１：１ 発注に対して配送センタに分割して納入 発注と入荷は１：多
図４－１０
ステップ５：イベントとリソースの関連 リソース系エンティティ間の関連の中に，イベントをおいてみる イベントがどのリソースを参照するかを調べる 注文から 顧客（1対1） 届け先（1対1） ショッピング・カート（1対多） 注文と商品（多対多） １つの注文の中で複数の商品を指定でき，１つの商品はさまざまな人から注文される（複数の注文から参照される）． 「注文商品」（１つの注文の中で指定された商品）というエンティティをつくり，多対多の関係を1対多（1対1）の関連２つに分ける 「出荷」「発注」などの他のイベントについても同様に実施
[補助] どうして， イベントからリソースへ調べるの？ なぜ，イベントからリソースへの参照を調べるのか？ イベントは人間の動作により起こされる． リソースは世の中にある物体や人 動作の中で物体や人が参照される よってイベントからリソースを参照するが，リソースからイベントを参照することには無理がある． リソースからイベントへは調べなくていいの？ 無理があるものは，しないほうがよい
ステップ５：サマリー系エンティティの追加 他のエンティティのインスタンスについて統計処理を施して束ねたエンティティ CRMなどで傾向を探るのに有効 Data Warehouse (データの問屋さんシステム)の研究には欠かせないエンティティ
図４－１３