Upgrade to Pro — share decks privately, control downloads, hide ads and more …

データマネジメント知識体系ガイドとともに学ぶデータモデリング

 データマネジメント知識体系ガイドとともに学ぶデータモデリング

14bfbc98a7d5ed3574be08f6b176ce70?s=128

リチャード 伊真岡

December 10, 2021
Tweet

More Decks by リチャード 伊真岡

Other Decks in Technology

Transcript

  1. Tech x Marketing データマネジメント知識体系ガイドと ともに学ぶデータモデリング richard

  2. Tech x Marketing データマネジメント知識体系ガイドと ともに学ぶデータモデリング richard Tech x Marketing データマネジメント知識体系ガイドと

    ともに学ぶデータモデリング richard
  3. Tech x Marketing データマネジメント知識体系ガイドと ともに学ぶデータモデリング richard Tech x Marketing データマネジメント知識体系ガイドと

    ともに学ぶデータモデリング richard
  4. 672ページ 第1章 データマネジメント 第2章 データ取扱倫理 第3章 データガバナンス 第4章 データアーキテクチャ 第5章

    データモデリングとデザイン 第6章 データストレージとオペレーション 第7章 データセキュリティ 第8章 データ統合と相互運用性 第9章 ドキュメントとコンテンツ管理 第10章 参照データとマスターデータ 第11章 データウェアハウジングとビジネスイン テリジェンス 第12章 メタデータ管理 第13章 データ品質 第14章 ビッグデータとデータサイエンス 第15章 データマネジメント成熟度アセスメント 第16章 データマネジメント組織と役割期待 第17章 データマネジメントと組織の変革
  5. 13,200円 第1章 データマネジメント 第2章 データ取扱倫理 第3章 データガバナンス 第4章 データアーキテクチャ 第5章

    データモデリングとデザイン 第6章 データストレージとオペレーション 第7章 データセキュリティ 第8章 データ統合と相互運用性 第9章 ドキュメントとコンテンツ管理 第10章 参照データとマスターデータ 第11章 データウェアハウジングとビジネスイン テリジェンス 第12章 メタデータ管理 第13章 データ品質 第14章 ビッグデータとデータサイエンス 第15章 データマネジメント成熟度アセスメント 第16章 データマネジメント組織と役割期待 第17章 データマネジメントと組織の変革
  6. 定義: データモデリングとは、データ要件を洗い出し、分 析し、取扱スコープを決めるプロセスであり、データ要件 を記述し伝えるために、明確に定義されたデータモデルと 呼ばれる様式が用いられる。概念、論理、物理モデルが含 まれる

  7. 定義: データモデリングとは、データ要件を洗い出し、分 析し、取扱スコープを決めるプロセスであり、データ要件 を記述し伝えるために、明確に定義されたデータモデルと 呼ばれる様式が用いられる。概念、論理、物理モデルが含 まれる なるほど……!汗

  8. 今日の目的: モデリングに親しみを感じてもらう そのための参考情報・文献を紹介

  9. しばらくDMBOK本を 飛び出した話が続きます

  10. > 問題解決のために、物事の特定の 側面を抽象化したもの モデルとは?

  11. モデルとは? 例:ピザの切り分け問題 ピザは真円ではない しかし真円とみなすと切り分け方法を 導ける

  12. 適当にカット 同じ重さになる まで再分配 モデルがなかったら??

  13. 適当にカット 同じ重さになる まで再分配 モデルがなかったら?? モデルがないと きれいに問題解決できない!

  14. CGをつくるならワイヤフレーム 目的によって適したモデルは変わる https://chewypixels.com/projects/dOqVg1

  15. モデルと数学

  16. 数学的なモデル例: 放物線 初速𝒗 角度𝛳 飛距離ℓ 最高到達点 h 投射高さy 0 重力加速度g

  17. ボール表面の摩擦 ボールのわずかな歪み ボールの回転 風速 よいモデルは不必要な情報を考慮しない

  18. 数学的なモデルの利点 その分野における数学者たちの数十~数百年の積み重ねを利用できる モデルの持つ様々な性質を導ける 例) • 行列なら固有値分解 • 微分積分 • 統計なら大数の法則や中心極限定理

  19. データモデルの中のひとつである リレーショナルモデルは 数学に基づいています 後で話します

  20. なぜソフトウェア開発でモデルを使う? • 開発対象の問題に意識を集中するため • 実装の詳細に引きずられない議論を可能にするため • モデルを共通言語とし開発チーム内の認識を統一できる ◦ ただしチーム内でモデルに関する共通知識を育てる必要性

  21. ソフトウェア開発におけるモデルの表現方法 数式、図解、文章、ソースコード…解決したい問題に集中できる表現 モデリング 設計 ソフトウェア開発的には 重要: モデルから将来のバグや問題を見抜く

  22. では、データモデルの表現方法は? データモデリング・スキーム 1.3.4 p165 ここからDMBOK本の内容に戻ります

  23. モデルの表現方法 1.3.4 p.165 スキーム 表記法の例 リレーショナル IE(Information Engineering)、IDEF1X、Barker、Chen ディメンショナル ディメンショナル

    オブジェクト指向 UML ファクトベース ORM(Object Role Modeling)、ORM2、FCO-IM タイムベース データボールト、アンカーモデリング NoSQL ドキュメント、カラム、グラフ、キーバリュー
  24. モデルの表現方法 1.3.4 p.165 スキーム 表記法の例 リレーショナル IE(Information Engineering)、IDEF1X、Barker、Chen ディメンショナル ディメンショナル

    オブジェクト指向 UML ファクトベース ORM(Object Role Modeling)、ORM2、FCO-IM タイムベース データボールト、アンカーモデリング NoSQL ドキュメント、カラム、グラフ、キーバリュー
  25. ER図いろいろ UMLモデリング入門 児玉公信より

  26. ER図 IE記法 学生 コース インストラクタ 四角がエンティティ

  27. ER図 IE記法 学生 コース インストラクタ 線がリレーションシップ 履修する 教える

  28. ER図 IE記法 学生 コース インストラクタ リレーションシップの多重度 履修する 教える

  29. ER図 = エンティティ」リレーション図… エンティティってなに?

  30. 一般的に使われるエンティティカテゴリー 表7(p.157) カテゴリー 例 誰が(Who) 従業員、患者、選手、容疑者、顧客、ベンダー、… 何を(What) 製品、サービス、原材料、完成品、… いつ(When) 時間、日付、月、四半期、年、予定、会計年度、…

    どこ(Where) 郵送先住所、配送地点、ウェブサイトアドレス、… 何故(Why) 注文、返品、苦情、出勤、… どのように(HOW) 請求書、契約、合意書、… 集計(Measurement) 売上、項目数、支払額、…
  31. 実務に即したモデリングの参考になる書籍

  32. 個人的なお気に入り

  33. 注) 2017年のツイートなので今もt_wadaさんがこちらを参考にし ているかは不明です

  34. 2006 2008 2012 2016 2005 2020 2003 2009 2013 2019

  35. リレーショナルモデルを勉強するモチベーションの1つ 費用対効果! ただし、人間費用対効果だけでは動かないので、気が向かなければ無理しない

  36. 正規化 1.3.6 (p.179)

  37. リレーショナルモデルは集合論 p.49 リレーショナルデータモデルは集合論に基 づき数学的に定義された徹底的にフォーマルな モデル

  38. リレーショナルモデルは集合論 正規化の効果: 更新時異常の防止 タップル挿入時・削除時・修正時異常 20ページ読むのに1週間くらいかかりました…

  39. OLTPでは正規化は重要 Online Transaction Processing - 例: アプリケーションとバックエンドDB アプリケーションサーバ データベース 更新時異常を防ぎたい

  40. OLAPでは正規化を意図的に崩すこともある Online Analytical Processing - 例: データウェアハウス データベース

  41. OLAPでは正規化を意図的に崩すこともある Online Analytical Processing - 例: データウェアハウス データベース 自分の携わるシステムが OLTPかOLAPどちらの性格が強いか

    見極める
  42. なぜソフトウェア開発でモデルを使う? • 開発対象(ドメイン)の問題に意識を集中するため • 実装の詳細に引きずられない議論を可能にするため • モデルを共通言語とし開発チーム内の認識を統一できる ◦ ただしチーム内でモデルに関する共通知識を育てる必要性

  43. 開発チーム内で共通知識を育てる これだけだと幅が狭い 自分の仕事

  44. 開発チーム内で共通知識を育てる 自分の仕事 経験則を補う1冊で他のエンジニアに差がつく

  45. 開発チーム内で共通知識を育てる チームで学ぶ

  46. 開発チーム内で共通知識を育てる 経験則 理論 全員がここまで 学ぶ必要はない

  47. 開発チーム内で共通知識を育てる 経験則 正規化 集合論

  48. 開発チーム内で共通知識を育てる コンピュータ・サイエンス ソフトウェア・エンジニアリング

  49. 概念・論理・物理モデル 1.3.5 (p.173)

  50. 学校 学生 応募書類 概念モデル エンティティのみ 在籍させる 提出する

  51. 学校名 学校コード 学生番号 学校コード(FK) ファーストネーム ラストネーム 学生誕生日 応募書類番号 学生番号(FK) 応募書類提出日

    論理モデル 属性を持つ 学校 学生 応募書類 在籍記録を持つ 提出する
  52. 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
  53. 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 適切な抽象度で議論する
  54. モデルの表現方法 1.3.4 p.165 スキーム 表記法の例 リレーショナル IE(Information Engineering)、IDEF1X、Barker、Chen ディメンショナル ディメンショナル

    オブジェクト指向 UML ファクトベース ORM(Object Role Modeling)、ORM2、FCO-IM タイムベース データボールト、アンカーモデリング NoSQL ドキュメント、カラム、グラフ、キーバリュー
  55. ディメンショナル - OLAP Cube 最初からクエリのためにデータをスライス クエリ

  56. ディメンショナル リレーショナルモデルで実現するとスタースキーマ、スノーフレークスキーマ

  57. ディメンショナルとOLAP YouTube What is OLAP? https://youtu.be/2ryG3Jy6eIY

  58. モデルの表現方法 1.3.4 p.165 スキーム 表記法の例 リレーショナル IE(Information Engineering)、IDEF1X、Barker、Chen ディメンショナル ディメンショナル

    オブジェクト指向 UML ファクトベース ORM(Object Role Modeling)、ORM2、FCO-IM タイムベース データボールト、アンカーモデリング NoSQL ドキュメント、カラム、グラフ、キーバリュー
  59. オブジェクト指向 DMBOK本5章ではUMLのクラス図のみ紹介 これだけではオブジェクト指向モデリ ングには物足りないのでは? 学生 Stdtno:integer strdt:date Prgm:txt ExpctGradedt:date ActlGraddt:date

    クラス名 属性 メソッド 1 *
  60. オブジェクト指向 UMLのクラス図で表現できないこと コンストラクタの引数で依存関係を表現とか クラス図では表現できない、型による制約を はじめとしたテクニックこそが、モダンなオ ブジェクト指向モデリングでは重要な気がす る class C {

    //aとbはCのインスタンスより先に生成 construct(a:A, b:B){ … } }
  61. モデルの表現方法 1.3.4 p.165 スキーム 表記法の例 リレーショナル IE(Information Engineering)、IDEF1X、Barker、Chen ディメンショナル ディメンショナル

    オブジェクト指向 UML ファクトベース ORM(Object Role Modeling)、ORM2、FCO-IM タイムベース データボールト、アンカーモデリング NoSQL ドキュメント、カラム、グラフ、キーバリュー この2つは私の知識が足りないのでスキップ
  62. モデルの表現方法 1.3.4 p.165 スキーム 表記法の例 リレーショナル IE(Information Engineering)、IDEF1X、Barker、Chen ディメンショナル ディメンショナル

    オブジェクト指向 UML ファクトベース ORM(Object Role Modeling)、ORM2、FCO-IM タイムベース データボールト、アンカーモデリング NoSQL ドキュメント、カラム、グラフ、キーバリュー
  63. Quoraの興味深いエントリ やや煽りがつよいが、歴史を踏まえてNoSQLのハ イプ・サイクルを紹介 > MongoDBの様なNoSQLに勢いがあるのは何故ですか?SQLと比 べてどんな利点や欠点がありますか? https://bit.ly/3DmAOvv

  64. Quoraの興味深いエントリ Q: MongoDBの様なNoSQLに勢いがあるのは何故です か?SQLと比べてどんな利点や欠点がありますか? A: この質問はちょっと古いですね。NoSQLに勢い があったのは2009-2015年にかけての頃です。 2018年現在は、PostgreSQL 10やMySQL 8などRDBMS

    (以下、わかりやすくSQLと呼びます)でJSONをネ イティブに扱える(インデックスを貼ったりツ リーの一部を操作したり)のがスタンダードに なったので、むしろこれらSQLのほうに勢いがあり ます
  65. Quoraの興味深いエントリ …(中略) ただの水平分散というのはベストケースでO(n)の 性能しか出ず、 …(中略) アルゴリズム的には「ナイーブ」とか「ブルート フォース(力任せ)」と揶揄される悪手です。

  66. Quoraの興味深いエントリ …(中略) この対数化を実現しているのが、実はSQLのイン デックスで使われているB-treeというアルゴリズ ムで、このインデックスがあるがゆえに、テーブ ルの行数が10倍、1万倍、1億倍になっても性能は1 億分の1ではなく8分の1ぐらいのおだやかな性能劣 化で収まるのです。こういう圧倒的なパワーこそ がサイエンスと呼ぶにふさわしいものです。 …(中略)

    そんなわけで、NoSQLを語るときに「性能」を持ち 出す人は、はっきり言って素人だと思います。
  67. 今はSQLもNoSQLも両方使う時代 SQL: • SQL製品の進化 NoSQLハイプ・サイクル 性能上がらない 運用大変… NoSQL知見がたまる NoSQL: •

    SQLライクなインターフェース ◦ 例: KSQL、GAQL、… • MapReduce操作の多くを表面上は SQLで置き換え • SQLの裏にあるDB設計・実装は多彩 • マネージドNoSQL製品で運用負担減 両方使うので、今が一番勉強は大変… イマココ
  68. アクティビティ 2 (p.181)

  69. アクティビティ 2.1 データモデリング計画 2.2 データモデルの構築 2.2.1 フォワードエンジニアリング ここまでの話と参考文献を抑えておけば、理解できる 実行できるかどうかは別の話

  70. 2.2.2 リバースエンジニアリング (p.186)

  71. 2.2.2 リバースエンジニアリング (p.186) DBからモデルを起こせるからといって それだけでよいわけではない

  72. 2.2.2 リバースエンジニアリング (p.186) モデリング 設計 ソフトウェア開発的には デザイン 適切な抽象度と適切なツール リバースエンジニアリングに任せっぱなしではいけない 議論と試行錯誤で設計を洗練させる

    = フォワードエンジニアリング
  73. まとめ

  74. まとめ • モデル = 問題解決のための抽象化 • 場面に応じた適切な抽象度 ◦ 概念、論理、物理 •

    数学的なモデルなら性質を導出しやすい ◦ 例: リレーショナルモデルの正規化 • 数学的でないモデルは経験則を利用 ◦ 自分の経験 + 先人の経験、パターン・アンチパターン • 開発チームが共通言語としてのモデルに習熟する必要
  75. これからの勉強を少しでも楽しくする案内になれば幸いです!