Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
データマネジメント知識体系ガイドとともに学ぶデータモデリング
Search
リチャード 伊真岡
December 10, 2021
Technology
0
290
データマネジメント知識体系ガイドとともに学ぶデータモデリング
リチャード 伊真岡
December 10, 2021
Tweet
Share
More Decks by リチャード 伊真岡
See All by リチャード 伊真岡
Adobe After EffectsによるExplainer Video作成
richardimaokajp
0
110
Java 5.0時代の非同期処理技術から学び直すScala/Java非同期処理
richardimaokajp
9
6.5k
非同期処理の歴史から見たコンピューティングの進化
richardimaokajp
12
6.6k
出張Akkaワークショップ
richardimaokajp
0
2k
Scala ZIOをバッチ処理に使ってみた
richardimaokajp
1
860
Akkaによるスレッドの使い方
richardimaokajp
4
1.3k
Other Decks in Technology
See All in Technology
複雑なState管理からの脱却
sansantech
PRO
1
140
ドメイン名の終活について - JPAAWG 7th -
mikit
33
20k
Terraform CI/CD パイプラインにおける AWS CodeCommit の代替手段
hiyanger
1
240
スクラムチームを立ち上げる〜チーム開発で得られたもの・得られなかったもの〜
ohnoeight
2
350
DMARC 対応の話 - MIXI CTO オフィスアワー #04
bbqallstars
1
160
OCI 運用監視サービス 概要
oracle4engineer
PRO
0
4.8k
テストコード品質を高めるためにMutation Testingライブラリ・Strykerを実戦導入してみた話
ysknsid25
7
2.6k
マルチモーダル / AI Agent / LLMOps 3つの技術トレンドで理解するLLMの今後の展望
hirosatogamo
37
12k
CysharpのOSS群から見るModern C#の現在地
neuecc
1
3.1k
開発生産性を上げながらビジネスも30倍成長させてきたチームの姿
kamina_zzz
2
1.7k
SSMRunbook作成の勘所_20241120
koichiotomo
2
120
【Startup CTO of the Year 2024 / Audience Award】アセンド取締役CTO 丹羽健
niwatakeru
0
920
Featured
See All Featured
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
665
120k
Being A Developer After 40
akosma
86
590k
The Cost Of JavaScript in 2023
addyosmani
45
6.7k
Into the Great Unknown - MozCon
thekraken
32
1.5k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.9k
The Art of Programming - Codeland 2020
erikaheidi
52
13k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Designing Experiences People Love
moore
138
23k
Measuring & Analyzing Core Web Vitals
bluesmoon
4
120
Git: the NoSQL Database
bkeepers
PRO
427
64k
Transcript
Tech x Marketing データマネジメント知識体系ガイドと ともに学ぶデータモデリング richard
Tech x Marketing データマネジメント知識体系ガイドと ともに学ぶデータモデリング richard Tech x Marketing データマネジメント知識体系ガイドと
ともに学ぶデータモデリング richard
Tech x Marketing データマネジメント知識体系ガイドと ともに学ぶデータモデリング richard Tech x Marketing データマネジメント知識体系ガイドと
ともに学ぶデータモデリング richard
672ページ 第1章 データマネジメント 第2章 データ取扱倫理 第3章 データガバナンス 第4章 データアーキテクチャ 第5章
データモデリングとデザイン 第6章 データストレージとオペレーション 第7章 データセキュリティ 第8章 データ統合と相互運用性 第9章 ドキュメントとコンテンツ管理 第10章 参照データとマスターデータ 第11章 データウェアハウジングとビジネスイン テリジェンス 第12章 メタデータ管理 第13章 データ品質 第14章 ビッグデータとデータサイエンス 第15章 データマネジメント成熟度アセスメント 第16章 データマネジメント組織と役割期待 第17章 データマネジメントと組織の変革
13,200円 第1章 データマネジメント 第2章 データ取扱倫理 第3章 データガバナンス 第4章 データアーキテクチャ 第5章
データモデリングとデザイン 第6章 データストレージとオペレーション 第7章 データセキュリティ 第8章 データ統合と相互運用性 第9章 ドキュメントとコンテンツ管理 第10章 参照データとマスターデータ 第11章 データウェアハウジングとビジネスイン テリジェンス 第12章 メタデータ管理 第13章 データ品質 第14章 ビッグデータとデータサイエンス 第15章 データマネジメント成熟度アセスメント 第16章 データマネジメント組織と役割期待 第17章 データマネジメントと組織の変革
定義: データモデリングとは、データ要件を洗い出し、分 析し、取扱スコープを決めるプロセスであり、データ要件 を記述し伝えるために、明確に定義されたデータモデルと 呼ばれる様式が用いられる。概念、論理、物理モデルが含 まれる
定義: データモデリングとは、データ要件を洗い出し、分 析し、取扱スコープを決めるプロセスであり、データ要件 を記述し伝えるために、明確に定義されたデータモデルと 呼ばれる様式が用いられる。概念、論理、物理モデルが含 まれる なるほど……!汗
今日の目的: モデリングに親しみを感じてもらう そのための参考情報・文献を紹介
しばらくDMBOK本を 飛び出した話が続きます
> 問題解決のために、物事の特定の 側面を抽象化したもの モデルとは?
モデルとは? 例:ピザの切り分け問題 ピザは真円ではない しかし真円とみなすと切り分け方法を 導ける
適当にカット 同じ重さになる まで再分配 モデルがなかったら??
適当にカット 同じ重さになる まで再分配 モデルがなかったら?? モデルがないと きれいに問題解決できない!
CGをつくるならワイヤフレーム 目的によって適したモデルは変わる https://chewypixels.com/projects/dOqVg1
モデルと数学
数学的なモデル例: 放物線 初速𝒗 角度𝛳 飛距離ℓ 最高到達点 h 投射高さy 0 重力加速度g
ボール表面の摩擦 ボールのわずかな歪み ボールの回転 風速 よいモデルは不必要な情報を考慮しない
数学的なモデルの利点 その分野における数学者たちの数十~数百年の積み重ねを利用できる モデルの持つ様々な性質を導ける 例) • 行列なら固有値分解 • 微分積分 • 統計なら大数の法則や中心極限定理
データモデルの中のひとつである リレーショナルモデルは 数学に基づいています 後で話します
なぜソフトウェア開発でモデルを使う? • 開発対象の問題に意識を集中するため • 実装の詳細に引きずられない議論を可能にするため • モデルを共通言語とし開発チーム内の認識を統一できる ◦ ただしチーム内でモデルに関する共通知識を育てる必要性
ソフトウェア開発におけるモデルの表現方法 数式、図解、文章、ソースコード…解決したい問題に集中できる表現 モデリング 設計 ソフトウェア開発的には 重要: モデルから将来のバグや問題を見抜く
では、データモデルの表現方法は? データモデリング・スキーム 1.3.4 p165 ここからDMBOK本の内容に戻ります
モデルの表現方法 1.3.4 p.165 スキーム 表記法の例 リレーショナル IE(Information Engineering)、IDEF1X、Barker、Chen ディメンショナル ディメンショナル
オブジェクト指向 UML ファクトベース ORM(Object Role Modeling)、ORM2、FCO-IM タイムベース データボールト、アンカーモデリング NoSQL ドキュメント、カラム、グラフ、キーバリュー
モデルの表現方法 1.3.4 p.165 スキーム 表記法の例 リレーショナル IE(Information Engineering)、IDEF1X、Barker、Chen ディメンショナル ディメンショナル
オブジェクト指向 UML ファクトベース ORM(Object Role Modeling)、ORM2、FCO-IM タイムベース データボールト、アンカーモデリング NoSQL ドキュメント、カラム、グラフ、キーバリュー
ER図いろいろ UMLモデリング入門 児玉公信より
ER図 IE記法 学生 コース インストラクタ 四角がエンティティ
ER図 IE記法 学生 コース インストラクタ 線がリレーションシップ 履修する 教える
ER図 IE記法 学生 コース インストラクタ リレーションシップの多重度 履修する 教える
ER図 = エンティティ」リレーション図… エンティティってなに?
一般的に使われるエンティティカテゴリー 表7(p.157) カテゴリー 例 誰が(Who) 従業員、患者、選手、容疑者、顧客、ベンダー、… 何を(What) 製品、サービス、原材料、完成品、… いつ(When) 時間、日付、月、四半期、年、予定、会計年度、…
どこ(Where) 郵送先住所、配送地点、ウェブサイトアドレス、… 何故(Why) 注文、返品、苦情、出勤、… どのように(HOW) 請求書、契約、合意書、… 集計(Measurement) 売上、項目数、支払額、…
実務に即したモデリングの参考になる書籍
個人的なお気に入り
注) 2017年のツイートなので今もt_wadaさんがこちらを参考にし ているかは不明です
2006 2008 2012 2016 2005 2020 2003 2009 2013 2019
リレーショナルモデルを勉強するモチベーションの1つ 費用対効果! ただし、人間費用対効果だけでは動かないので、気が向かなければ無理しない
正規化 1.3.6 (p.179)
リレーショナルモデルは集合論 p.49 リレーショナルデータモデルは集合論に基 づき数学的に定義された徹底的にフォーマルな モデル
リレーショナルモデルは集合論 正規化の効果: 更新時異常の防止 タップル挿入時・削除時・修正時異常 20ページ読むのに1週間くらいかかりました…
OLTPでは正規化は重要 Online Transaction Processing - 例: アプリケーションとバックエンドDB アプリケーションサーバ データベース 更新時異常を防ぎたい
OLAPでは正規化を意図的に崩すこともある Online Analytical Processing - 例: データウェアハウス データベース
OLAPでは正規化を意図的に崩すこともある Online Analytical Processing - 例: データウェアハウス データベース 自分の携わるシステムが OLTPかOLAPどちらの性格が強いか
見極める
なぜソフトウェア開発でモデルを使う? • 開発対象(ドメイン)の問題に意識を集中するため • 実装の詳細に引きずられない議論を可能にするため • モデルを共通言語とし開発チーム内の認識を統一できる ◦ ただしチーム内でモデルに関する共通知識を育てる必要性
開発チーム内で共通知識を育てる これだけだと幅が狭い 自分の仕事
開発チーム内で共通知識を育てる 自分の仕事 経験則を補う1冊で他のエンジニアに差がつく
開発チーム内で共通知識を育てる チームで学ぶ
開発チーム内で共通知識を育てる 経験則 理論 全員がここまで 学ぶ必要はない
開発チーム内で共通知識を育てる 経験則 正規化 集合論
開発チーム内で共通知識を育てる コンピュータ・サイエンス ソフトウェア・エンジニアリング
概念・論理・物理モデル 1.3.5 (p.173)
学校 学生 応募書類 概念モデル エンティティのみ 在籍させる 提出する
学校名 学校コード 学生番号 学校コード(FK) ファーストネーム ラストネーム 学生誕生日 応募書類番号 学生番号(FK) 応募書類提出日
論理モデル 属性を持つ 学校 学生 応募書類 在籍記録を持つ 提出する
STUDENT_NUM STUDENT_FIRST_NAM STUDENT_LAST_NAM STUDENT_BIRTH_DT SCHOOL_CD SCHOOL_NAM APPLICATION_NUM STUDENT_NUM(FK) APPLICATION_SUBMITION_DT 物理モデル
テーブルスキーマと非常に近い STUDENT APPLICATION Submit
STUDENT_NUM STUDENT_FIRST_NAM STUDENT_LAST_NAM STUDENT_BIRTH_DT SCHOOL_CD SCHOOL_NAM APPLICATION_NUM STUDENT_NUM(FK) APPLICATION_SUBMITION_DT 物理モデル
ほぼテーブルスキーマと同一 STUDENT APPLICATION Submit 適切な抽象度で議論する
モデルの表現方法 1.3.4 p.165 スキーム 表記法の例 リレーショナル IE(Information Engineering)、IDEF1X、Barker、Chen ディメンショナル ディメンショナル
オブジェクト指向 UML ファクトベース ORM(Object Role Modeling)、ORM2、FCO-IM タイムベース データボールト、アンカーモデリング NoSQL ドキュメント、カラム、グラフ、キーバリュー
ディメンショナル - OLAP Cube 最初からクエリのためにデータをスライス クエリ
ディメンショナル リレーショナルモデルで実現するとスタースキーマ、スノーフレークスキーマ
ディメンショナルとOLAP YouTube What is OLAP? https://youtu.be/2ryG3Jy6eIY
モデルの表現方法 1.3.4 p.165 スキーム 表記法の例 リレーショナル IE(Information Engineering)、IDEF1X、Barker、Chen ディメンショナル ディメンショナル
オブジェクト指向 UML ファクトベース ORM(Object Role Modeling)、ORM2、FCO-IM タイムベース データボールト、アンカーモデリング NoSQL ドキュメント、カラム、グラフ、キーバリュー
オブジェクト指向 DMBOK本5章ではUMLのクラス図のみ紹介 これだけではオブジェクト指向モデリ ングには物足りないのでは? 学生 Stdtno:integer strdt:date Prgm:txt ExpctGradedt:date ActlGraddt:date
クラス名 属性 メソッド 1 *
オブジェクト指向 UMLのクラス図で表現できないこと コンストラクタの引数で依存関係を表現とか クラス図では表現できない、型による制約を はじめとしたテクニックこそが、モダンなオ ブジェクト指向モデリングでは重要な気がす る class C {
//aとbはCのインスタンスより先に生成 construct(a:A, b:B){ … } }
モデルの表現方法 1.3.4 p.165 スキーム 表記法の例 リレーショナル IE(Information Engineering)、IDEF1X、Barker、Chen ディメンショナル ディメンショナル
オブジェクト指向 UML ファクトベース ORM(Object Role Modeling)、ORM2、FCO-IM タイムベース データボールト、アンカーモデリング NoSQL ドキュメント、カラム、グラフ、キーバリュー この2つは私の知識が足りないのでスキップ
モデルの表現方法 1.3.4 p.165 スキーム 表記法の例 リレーショナル IE(Information Engineering)、IDEF1X、Barker、Chen ディメンショナル ディメンショナル
オブジェクト指向 UML ファクトベース ORM(Object Role Modeling)、ORM2、FCO-IM タイムベース データボールト、アンカーモデリング NoSQL ドキュメント、カラム、グラフ、キーバリュー
Quoraの興味深いエントリ やや煽りがつよいが、歴史を踏まえてNoSQLのハ イプ・サイクルを紹介 > MongoDBの様なNoSQLに勢いがあるのは何故ですか?SQLと比 べてどんな利点や欠点がありますか? https://bit.ly/3DmAOvv
Quoraの興味深いエントリ Q: MongoDBの様なNoSQLに勢いがあるのは何故です か?SQLと比べてどんな利点や欠点がありますか? A: この質問はちょっと古いですね。NoSQLに勢い があったのは2009-2015年にかけての頃です。 2018年現在は、PostgreSQL 10やMySQL 8などRDBMS
(以下、わかりやすくSQLと呼びます)でJSONをネ イティブに扱える(インデックスを貼ったりツ リーの一部を操作したり)のがスタンダードに なったので、むしろこれらSQLのほうに勢いがあり ます
Quoraの興味深いエントリ …(中略) ただの水平分散というのはベストケースでO(n)の 性能しか出ず、 …(中略) アルゴリズム的には「ナイーブ」とか「ブルート フォース(力任せ)」と揶揄される悪手です。
Quoraの興味深いエントリ …(中略) この対数化を実現しているのが、実はSQLのイン デックスで使われているB-treeというアルゴリズ ムで、このインデックスがあるがゆえに、テーブ ルの行数が10倍、1万倍、1億倍になっても性能は1 億分の1ではなく8分の1ぐらいのおだやかな性能劣 化で収まるのです。こういう圧倒的なパワーこそ がサイエンスと呼ぶにふさわしいものです。 …(中略)
そんなわけで、NoSQLを語るときに「性能」を持ち 出す人は、はっきり言って素人だと思います。
今はSQLもNoSQLも両方使う時代 SQL: • SQL製品の進化 NoSQLハイプ・サイクル 性能上がらない 運用大変… NoSQL知見がたまる NoSQL: •
SQLライクなインターフェース ◦ 例: KSQL、GAQL、… • MapReduce操作の多くを表面上は SQLで置き換え • SQLの裏にあるDB設計・実装は多彩 • マネージドNoSQL製品で運用負担減 両方使うので、今が一番勉強は大変… イマココ
アクティビティ 2 (p.181)
アクティビティ 2.1 データモデリング計画 2.2 データモデルの構築 2.2.1 フォワードエンジニアリング ここまでの話と参考文献を抑えておけば、理解できる 実行できるかどうかは別の話
2.2.2 リバースエンジニアリング (p.186)
2.2.2 リバースエンジニアリング (p.186) DBからモデルを起こせるからといって それだけでよいわけではない
2.2.2 リバースエンジニアリング (p.186) モデリング 設計 ソフトウェア開発的には デザイン 適切な抽象度と適切なツール リバースエンジニアリングに任せっぱなしではいけない 議論と試行錯誤で設計を洗練させる
= フォワードエンジニアリング
まとめ
まとめ • モデル = 問題解決のための抽象化 • 場面に応じた適切な抽象度 ◦ 概念、論理、物理 •
数学的なモデルなら性質を導出しやすい ◦ 例: リレーショナルモデルの正規化 • 数学的でないモデルは経験則を利用 ◦ 自分の経験 + 先人の経験、パターン・アンチパターン • 開発チームが共通言語としてのモデルに習熟する必要
これからの勉強を少しでも楽しくする案内になれば幸いです!