Submit Search
Upload
Usage-Driven Database Design Chapter4
•
Download as PPTX, PDF
•
0 likes
•
39 views
O
OsakiKota
Follow
Usage Driven Database Design 4章をまとめたもの 物理データモデル(SQLやRDBの実装テク)の前にやるべきデータベース設計を学ぶ
Read less
Read more
Engineering
Report
Share
Report
Share
1 of 51
Download now
Recommended
深層学習よもやま話
深層学習よもやま話
Hiroshi Maruyama
データベース09 - データベース設計
データベース09 - データベース設計
Kenta Oku
Database Modeling (2018)
Database Modeling (2018)
Kihyun Kim
DDDで本質の探究 .pptx
DDDで本質の探究 .pptx
ssuser502958
【社内勉強会資料】自社サービスエンジニアの為の「UX設計と情報設計」
【社内勉強会資料】自社サービスエンジニアの為の「UX設計と情報設計」
paiza
初めてのデータ分析基盤構築をまかされた、その時何を考えておくと良いのか
初めてのデータ分析基盤構築をまかされた、その時何を考えておくと良いのか
Techon Organization
[db tech showcase Tokyo 2018] #dbts2018 #D1L 『"何が必要?どう実現?"~異種DB間データリアルタイム連携』
[db tech showcase Tokyo 2018] #dbts2018 #D1L 『"何が必要?どう実現?"~異種DB間データリアルタイム連携』
Insight Technology, Inc.
モデリングの神髄
モデリングの神髄
bpstudy
Recommended
深層学習よもやま話
深層学習よもやま話
Hiroshi Maruyama
データベース09 - データベース設計
データベース09 - データベース設計
Kenta Oku
Database Modeling (2018)
Database Modeling (2018)
Kihyun Kim
DDDで本質の探究 .pptx
DDDで本質の探究 .pptx
ssuser502958
【社内勉強会資料】自社サービスエンジニアの為の「UX設計と情報設計」
【社内勉強会資料】自社サービスエンジニアの為の「UX設計と情報設計」
paiza
初めてのデータ分析基盤構築をまかされた、その時何を考えておくと良いのか
初めてのデータ分析基盤構築をまかされた、その時何を考えておくと良いのか
Techon Organization
[db tech showcase Tokyo 2018] #dbts2018 #D1L 『"何が必要?どう実現?"~異種DB間データリアルタイム連携』
[db tech showcase Tokyo 2018] #dbts2018 #D1L 『"何が必要?どう実現?"~異種DB間データリアルタイム連携』
Insight Technology, Inc.
モデリングの神髄
モデリングの神髄
bpstudy
Object oriented
Object oriented
Toru Takefusa
非技術者でもわかる(?)コンピュータビジョン紹介資料
非技術者でもわかる(?)コンピュータビジョン紹介資料
Takuya Minagawa
データサイエンティストに聞く!今更聞けない機械学習の基礎から応用まで V e-1
データサイエンティストに聞く!今更聞けない機械学習の基礎から応用まで V e-1
Shunsuke Nakamura
AutoML & InterpretML (2019/11/27 Deep Learning Lab 講演資料)
AutoML & InterpretML (2019/11/27 Deep Learning Lab 講演資料)
Keita Onabuta
チームトポロジーから学び、 データプラットフォーム組織を考え直した話.pptx
チームトポロジーから学び、 データプラットフォーム組織を考え直した話.pptx
Rakuten Commerce Tech (Rakuten Group, Inc.)
機械学習応用システムのアーキテクチャ・デザイパターン(2020-07 ドラフトバージョン))
機械学習応用システムのアーキテクチャ・デザイパターン(2020-07 ドラフトバージョン))
HironoriTAKEUCHI1
Janog31 bof-pattern-sasaki-01
Janog31 bof-pattern-sasaki-01
Ken SASAKI
ドメインロジックの実装方法とドメイン駆動設計
ドメインロジックの実装方法とドメイン駆動設計
Tadayoshi Sato
自己紹介にかえて-変化する企業ITと“ワクワク感” 桑原里恵
自己紹介にかえて-変化する企業ITと“ワクワク感” 桑原里恵
Sapporo Sparkle k.k.
情報検索のためのユーザモデル
情報検索のためのユーザモデル
kt.mako
Data scientist casual talk in 白金台
Data scientist casual talk in 白金台
Hiroko Onari
これって、ドメイン駆動設計?
これって、ドメイン駆動設計?
Michitaka Yumoto
MySQLで学ぶ機械学習ことはじめ.pdf
MySQLで学ぶ機械学習ことはじめ.pdf
Machiko Ikoma
東北大学AIE - 機械学習中級編とAzure紹介
東北大学AIE - 機械学習中級編とAzure紹介
Daiyu Hatakeyama
現場で役立つシステム設計の原則
現場で役立つシステム設計の原則
増田 亨
カタログDTPのデータを活用しよう!
カタログDTPのデータを活用しよう!
Masataka Kawahara
IA Workshop, Introduction to Information Architecture (2002)
IA Workshop, Introduction to Information Architecture (2002)
Nobuya Sato
企業等に蓄積されたデータを分析するための処理機能の提案
企業等に蓄積されたデータを分析するための処理機能の提案
Toshiyuki Shimono
カスタマーサクセスのためのデータ整備人の活動記録
カスタマーサクセスのためのデータ整備人の活動記録
syou6162
Rindoku2020
Rindoku2020
Takedaatsushi
More Related Content
Similar to Usage-Driven Database Design Chapter4
Object oriented
Object oriented
Toru Takefusa
非技術者でもわかる(?)コンピュータビジョン紹介資料
非技術者でもわかる(?)コンピュータビジョン紹介資料
Takuya Minagawa
データサイエンティストに聞く!今更聞けない機械学習の基礎から応用まで V e-1
データサイエンティストに聞く!今更聞けない機械学習の基礎から応用まで V e-1
Shunsuke Nakamura
AutoML & InterpretML (2019/11/27 Deep Learning Lab 講演資料)
AutoML & InterpretML (2019/11/27 Deep Learning Lab 講演資料)
Keita Onabuta
チームトポロジーから学び、 データプラットフォーム組織を考え直した話.pptx
チームトポロジーから学び、 データプラットフォーム組織を考え直した話.pptx
Rakuten Commerce Tech (Rakuten Group, Inc.)
機械学習応用システムのアーキテクチャ・デザイパターン(2020-07 ドラフトバージョン))
機械学習応用システムのアーキテクチャ・デザイパターン(2020-07 ドラフトバージョン))
HironoriTAKEUCHI1
Janog31 bof-pattern-sasaki-01
Janog31 bof-pattern-sasaki-01
Ken SASAKI
ドメインロジックの実装方法とドメイン駆動設計
ドメインロジックの実装方法とドメイン駆動設計
Tadayoshi Sato
自己紹介にかえて-変化する企業ITと“ワクワク感” 桑原里恵
自己紹介にかえて-変化する企業ITと“ワクワク感” 桑原里恵
Sapporo Sparkle k.k.
情報検索のためのユーザモデル
情報検索のためのユーザモデル
kt.mako
Data scientist casual talk in 白金台
Data scientist casual talk in 白金台
Hiroko Onari
これって、ドメイン駆動設計?
これって、ドメイン駆動設計?
Michitaka Yumoto
MySQLで学ぶ機械学習ことはじめ.pdf
MySQLで学ぶ機械学習ことはじめ.pdf
Machiko Ikoma
東北大学AIE - 機械学習中級編とAzure紹介
東北大学AIE - 機械学習中級編とAzure紹介
Daiyu Hatakeyama
現場で役立つシステム設計の原則
現場で役立つシステム設計の原則
増田 亨
カタログDTPのデータを活用しよう!
カタログDTPのデータを活用しよう!
Masataka Kawahara
IA Workshop, Introduction to Information Architecture (2002)
IA Workshop, Introduction to Information Architecture (2002)
Nobuya Sato
企業等に蓄積されたデータを分析するための処理機能の提案
企業等に蓄積されたデータを分析するための処理機能の提案
Toshiyuki Shimono
カスタマーサクセスのためのデータ整備人の活動記録
カスタマーサクセスのためのデータ整備人の活動記録
syou6162
Rindoku2020
Rindoku2020
Takedaatsushi
Similar to Usage-Driven Database Design Chapter4
(20)
Object oriented
Object oriented
非技術者でもわかる(?)コンピュータビジョン紹介資料
非技術者でもわかる(?)コンピュータビジョン紹介資料
データサイエンティストに聞く!今更聞けない機械学習の基礎から応用まで V e-1
データサイエンティストに聞く!今更聞けない機械学習の基礎から応用まで V e-1
AutoML & InterpretML (2019/11/27 Deep Learning Lab 講演資料)
AutoML & InterpretML (2019/11/27 Deep Learning Lab 講演資料)
チームトポロジーから学び、 データプラットフォーム組織を考え直した話.pptx
チームトポロジーから学び、 データプラットフォーム組織を考え直した話.pptx
機械学習応用システムのアーキテクチャ・デザイパターン(2020-07 ドラフトバージョン))
機械学習応用システムのアーキテクチャ・デザイパターン(2020-07 ドラフトバージョン))
Janog31 bof-pattern-sasaki-01
Janog31 bof-pattern-sasaki-01
ドメインロジックの実装方法とドメイン駆動設計
ドメインロジックの実装方法とドメイン駆動設計
自己紹介にかえて-変化する企業ITと“ワクワク感” 桑原里恵
自己紹介にかえて-変化する企業ITと“ワクワク感” 桑原里恵
情報検索のためのユーザモデル
情報検索のためのユーザモデル
Data scientist casual talk in 白金台
Data scientist casual talk in 白金台
これって、ドメイン駆動設計?
これって、ドメイン駆動設計?
MySQLで学ぶ機械学習ことはじめ.pdf
MySQLで学ぶ機械学習ことはじめ.pdf
東北大学AIE - 機械学習中級編とAzure紹介
東北大学AIE - 機械学習中級編とAzure紹介
現場で役立つシステム設計の原則
現場で役立つシステム設計の原則
カタログDTPのデータを活用しよう!
カタログDTPのデータを活用しよう!
IA Workshop, Introduction to Information Architecture (2002)
IA Workshop, Introduction to Information Architecture (2002)
企業等に蓄積されたデータを分析するための処理機能の提案
企業等に蓄積されたデータを分析するための処理機能の提案
カスタマーサクセスのためのデータ整備人の活動記録
カスタマーサクセスのためのデータ整備人の活動記録
Rindoku2020
Rindoku2020
Usage-Driven Database Design Chapter4
1.
Usage-Driven Database Design Chapter 4
2.
一、二章では データモデリングには • 人間の理解できる形で表現する論理データモデリング • PCで実際に運用する物理データモデリング がある 論理データモデリングからやると 長い期間、修正の少ない データベース設計ができる
3.
三章では 人が理解できるデータモデルとは エンティティ(人、車などのもの)どうしが どんなリレーションシップ(購入)か どんな属性(色や購入日)かを 図示したもの リレーションや属性は様々な条件があり それに沿って構築する
4.
何を覚えればいいの? 論理データモデリングってなにすんだよ? 質問、可視化 これを繰り返して納得のいくまで必要な情報関係を整理する 作ったモデルがでかすぎて分析できないんだけど? モデルを分割しよう 分け方はカテゴリと機能別、近辺のを取り上げる三つがある データモデリングのプロジェクトがうまくいかない プロジェクトマネジメントを参考に進める
5.
論理データモデルの作成の流れ 情報収 集 情報分析 モデル 作成 論理モデルの作成の流れ 1. 情報を集める 2.
集めた情報を分析 3. モデルの作成 4. 1に戻る 論理モデルって? 情報をER図等で人の理解 できる形でまとめたもの
6.
インタビューする人と専門家を選ぼう 問題:専門家を騙るめんどくさいやつ 何も知らない高齢者 変化にキャッチアップ できない専門家 インタビューをさせて くれないマネージャー
7.
事前情報でインタビューの準備をしよう 事前情報で仮のエンティティやリレーションを設定 アンケートやレポート、スクリーンショットなどの 情報を使ってER図を作るとインタビューしやすい なんでインタビュー前に作るの? インタビューで質問することを作っておくこと ER図で可視化しインタビューを進めやすくする
8.
初めてのインタビュー インタビューの目的を言おう 誇張や嘘を言うのはやめよう 質問をしよう 何をしている? 何が好き?嫌い? など 目標 10個のエンティティ を作ろう 事前にエンティティ作っておくと 関係あるか聞けるんで楽に見つけられる
9.
リレーションをみつけよう • 専門用語はなるべく避ける この時点でModalityやCardinality等は気にしない 例. CustomerはAccountエンティティとどう関連している? 社員と部署の関連はどうだろう?
10.
ミーティングと確認作業 一人のインタビュー者につき複数の ミーティングも… なぜ? • 多くの新しい情報がある • 得た情報を整理して 次質問することないようにする モデルを見せる •
モデル全体の確認 • 正しい箇所 • 拡張できそうな点
11.
論理データモデルの作成の流れ 情報収 集 情報分析 モデル 作成 論理モデルの作成の流れ 1. 情報を集める 2.
集めた情報を分析 3. モデルの作成 4. 1に戻る 論理モデルって? 情報を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. 1に戻る 論理モデルって? 情報をER図等で人の理解 できる形でまとめたもの
15.
モデルの作成 過去の二つのプロセスで集めた情報をもとに モデルを作成、修正、拡張 何回繰り返すの? 仕事や事業で必要な情報を収集できたといえるまで
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との違い データの種類で分けるか、仕事内容で分けるか
32.
Neighborhood Diagrams エンティティとその周辺のリレーションに分割する 近くにあるものは関連性が高い 100個のエンティティ で作られたモデル 100個のダイアグラム Cutomer Account Material
33.
ブリッジとスタブ エンティティの対応が 見づらい ブリッジ スタブ
34.
モデリングの ベストプラクティス
35.
なんで失敗するのか データモデリングが抽象的な仕事 問題や解決策を 概念化できる人がいない 技術や道具が活かせない モデリングの設計は 様々 答えはたくさんある
36.
成功させるためには? IT業界のプロジェクトと同じように取り組む 必要な各要素に特化した人物を連れてくる • 優れたITスキルを持つ人 • 調査対象に関して優れたスキルを持つ人 •
コストの調整等プロジェクトに関心を持つ人 • 組織内で十分に優れた地位を持つ人 ルールや原則を決める プロジェクト途中で無益な言い争いをなくす
37.
ルールを決める理由 ルール:データモデリングにおける構文や意味を示す データモデリングをプロジェクトにかかわる人すべてが 共有し使いこなせるようにするため 対象:プログラマー、システムデザイナー、DBデザイナー 例. エンティティやドメインの定義 理論的に構築することを意識づける 抽象的:派生データを組み込んではいけない
38.
計画 事前にプロジェクトの計画 必要要素 • 予算 • スケジュール •
資源(チームメンバーを含む) 問題 マネージャーのモデリングに対する造形と設計コストの理解 を強く求められること
39.
チーム プロジェクトを任せられるデータモデラーを集めよう どんなデータモデラー? • その領域で経験を積んでいる人 中途 • 実務経験はないが学ぶ意欲が見られる人間 新卒
40.
ユーザー ユーザーや調査対象の専門家からの 情報をうまく引き出せる環境を作る 社会は思ったより融通が利かない 例 ロシアのとある企業の倒産 新しく、安く、高性能な機材を持っていた 理由:利用許可が下りない
41.
ユーザーコントロール ユーザーの意見および管理スタッフの意見 によりすぎた結果 専門家とそりが合わない 例. セキュリティ会社でのモデリング Portfolioやpositionは派生属性 だからモデルに組み込むのは 両方ともモデルに組み込め わかりにくいだろ
42.
コントロールのコツ • 何をやっているのかを知る • 何をやっているのか、なぜやるのかを伝える •
計画にそって進めよう ルールに従う • ほかの参加者にも計画の順守を徹底させる ルールを共有する
43.
プロジェクトスタッフのコントロール 素人 専門家 自信 ここ 技術スタッフの暴走 下手に知識がある分 データモデリングをできない人が 主義主張が激しい ダニングクルーガー効果 素人ながらの質問~がやばいのはこれ
44.
ツールやテクニックだけに依存するな データ分析やモデリングには 便利なツールがいっぱい 使ってもいいが十分に理解しておくこと 講義の目的と同じ ツールを使いこなすバカは ただ作業が速いだけの馬鹿だ Approach Modeling Tools
45.
むだな分析に時間をかけすぎないこと 完璧にこだわりすぎてデータモデルの分析に時間をかけすぎて プロジェクトを失敗する 理由 • 信頼性を失うことを恐れる • どのくらい、どのように使われるかを想定していない
46.
ふせぐために • 新しい情報を集めても恩恵が少ないとき • 情報の重要さを示す理由がこじつけレベルのとき •
十分な情報が集まったと感じた時
47.
データモデルの停止 データモデルの確立のプロセスから コントロールのプロセスへと変更 メンテナンスモードに入ったことを知らせる データモデルの変更、相談を共有するため すべての変更のリクエストはいきなり通さず 変更管理プロセスに通す どの変更が通ったか、相談段階かを可視化する
48.
変更リクエストの扱い 変更リクエスト 早急な変更の適用が求められる バグなどで属性の追加が必要になったとき 現段階の終わりまで必要な時 アップデート版として 出したいときモデリングの修正順序を 優先付けをする
49.
成果物 物理データモデラーに渡すもの/論理データモデリングのゴール
50.
成果物 以下の成果物を物理データモデラーが扱う • ER図 • LDMのオブジェクト定義 •
リレーション、エンティティ、属性など • ノート • コメント • アドバイス • 困難な点や質問等のコミュニケーション要素
51.
ER図と定義集のスクリーンショット
Download now