Usage-Driven Database Design Chapter4
- 5. 論理データモデルの作成の流れ 情報収 集 情報分析 モデル 作成 論理モデルの作成の流れ 1. 情報を集める 2. 集めた情報を分析 3. モデルの作成 4. １に戻る 論理モデルって？ 情報をER図等で人の理解 できる形でまとめたもの
- 10. ミーティングと確認作業 一人のインタビュー者につき複数の ミーティングも… なぜ？ • 多くの新しい情報がある • 得た情報を整理して 次質問することないようにする モデルを見せる • モデル全体の確認 • 正しい箇所 • 拡張できそうな点
- 11. 論理データモデルの作成の流れ 情報収 集 情報分析 モデル 作成 論理モデルの作成の流れ 1. 情報を集める 2. 集めた情報を分析 3. モデルの作成 4. １に戻る 論理モデルって？ 情報をER図等で人の理解 できる形でまとめたもの
- 12. 収集データの分析 集めたエンティティ、リレーション、属性の詳細を作る • 論理データモデルはダイアグラムだけでなく 理解できる説明も必要 • 無理に完ぺきを狙わなくてもいい下書きとして書く • 形式化することで足りない要素を見つけていく
- 13. 一例（詳しくはappendixBを確認） Entity type: Proper Attribute: メモリ：16GB Unique ID Entity Name:legionT510i SuperType：PC RelationShips:購入 Number : many Constraints:制約 ドメインやリレーションの詳細も 決めていく どんな変数？
- 14. 論理データモデルの作成の流れ 情報収 集 情報分析 モデル 作成 論理モデルの作成の流れ 1. 情報を集める 2. 集めた情報を分析 3. モデルの作成 4. １に戻る 論理モデルって？ 情報をER図等で人の理解 できる形でまとめたもの
- 16. 質問からモデルへの構築
- 17. どうやってエンティティ作るの 質問をして可視化する genogramみたいに発言を図示していく Employees can reports to either a supervisor or the Human Resource Department Employees Supervisor 一般名詞をエンティティとして 取り出す
- 18. どうやってエンティティ作るの 質問をして可視化する genogramみたいに発言を図示していく Employees can reports to either a supervisor or the Human Resource Department Employees Supervisor Department 人事部は固有名詞なので部門でくくり 属性として部門名：人事部を設定
- 19. どうやってエンティティ作るの 質問をして可視化する genogramみたいに発言を図示していく Employees can reports to either a supervisor or the Human Resource Department Employees Supervisor Department 雇用者は上司や部門に報告するので リレーションはreport to Reports to
- 20. どうやってエンティティ作るの 質問をして可視化する genogramみたいに発言を図示していく Employees can reports to either a supervisor or the Human Resource Department Employees Supervisor Department どちらかと書いてあるので Exclusionで表現 Reports to
- 21. どうやってエンティティ作るの 質問をして可視化する genogramみたいに発言を図示していく Employees can reports to either a supervisor or the Human Resource Department Employees Supervisor Department canは強制ではないので オプションをつける Reports to
- 22. どうやってエンティティ作るの 質問をして可視化する genogramみたいに発言を図示していく Employees can reports to either a supervisor or the Human Resource Department Employees Supervisor Department 複数形かどうかで 多重度を設定する Reports to
- 23. エンティティ対応の一部 現実の単語 対応するE-R図 名詞 ex.車 Proper エンティティ 固有名詞 ex.人事部 インスタンス 他動詞 ex ~に報告する リレーションシップ 自動詞 属性 動名詞 Associative エンティティ 形容詞 ex.美しい Properエンティティの属性 副詞 Associativeエンティティの属性 多く、一つなど数を示す単語 多重度 must,canなど必須かどうかを示す単語 モダリティ AとB（And） など Conjunction または、どちらか など Exclusion
- 24. 単語とER図対応の一例 車 色：黒い 形容詞 顧客 属性を持ったエンティティ＝インスタンス 車 名詞 買う 買う：動詞 リレーションシップ 副詞がある->買うをAssociativeにする 副詞を属性に 黒い車 固有名詞
- 25. 得られた情報は何か整理しよう 二つの方法が有効 迅速なインタビューのフィードバック • 聞いたことを確認する • 質問者に積極的な会話機会を与える Formal Walk Throghs インタビューで得た情報を分析し、結果や追加情報をわかりやすくする 初期のインタビュー後になんどか行う
- 26. インタビューのフィードバック インタビューの行動割合 答える 提案する 質問者のたいていは 技術的に精通した人ではない 控えめな発言になりやすい 聞いたことの理解を誤認しないよう 対象範囲を特定する 例 every account is owned by a customer アカウントとは一つを指すのか 企業のような共同で扱う場合の考えなど
- 27. Formal work throghs 何をするのか 1. 質問者にダイアグラムやエンティティ等を 少しづつ、確認していく 2. モデルをインタビューで得た形態に戻す (リバースエンジニアリング) Employees can reports to either a supervisor or the Human Resource Department 戻す
- 28. モデルの分析効率化
- 29. モデルを効率よく扱う 企業で扱うような規模の大きいERモデルは • 多くのエンティティ • 多くのリレーションシップ 分割して見やすく、分析しやすくしよう！ • Subject Areas • Entity Fragements • Neighborhood Diagrams
- 30. Subject Areas 特定の領域に関連するモデルにわける カテゴリ化 例. 顧客（顧客、アドレス、購入履歴） 目的 • カテゴリ化したモデルをそれぞれ分析 分担がしやすい • 顧客に関連した情報を見せやすい
- 31. Entity Fragments 目的に応じて必要な リレーションシップやエンティティを扱うこと 例. 顧客のアカウントの更新 必要な要素 顧客のアカウントやクレジットなど Subject Areasとの違い データの種類で分けるか、仕事内容で分けるか
- 34. モデリングの ベストプラクティス
- 36. 成功させるためには？ IT業界のプロジェクトと同じように取り組む 必要な各要素に特化した人物を連れてくる • 優れたITスキルを持つ人 • 調査対象に関して優れたスキルを持つ人 • コストの調整等プロジェクトに関心を持つ人 • 組織内で十分に優れた地位を持つ人 ルールや原則を決める プロジェクト途中で無益な言い争いをなくす
- 38. 計画 事前にプロジェクトの計画 必要要素 • 予算 • スケジュール • 資源（チームメンバーを含む） 問題 マネージャーのモデリングに対する造形と設計コストの理解 を強く求められること
- 42. コントロールのコツ • 何をやっているのかを知る • 何をやっているのか、なぜやるのかを伝える • 計画にそって進めよう ルールに従う • ほかの参加者にも計画の順守を徹底させる ルールを共有する
- 46. ふせぐために • 新しい情報を集めても恩恵が少ないとき • 情報の重要さを示す理由がこじつけレベルのとき • 十分な情報が集まったと感じた時
- 50. 成果物 以下の成果物を物理データモデラーが扱う • ER図 • LDMのオブジェクト定義 • リレーション、エンティティ、属性など • ノート • コメント • アドバイス • 困難な点や質問等のコミュニケーション要素