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