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

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

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

リチャード 伊真岡

December 10, 2021
Tweet

More Decks by リチャード 伊真岡

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  15. モデルと数学

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  25. ER図いろいろ
    UMLモデリング入門 児玉公信より

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  30. 一般的に使われるエンティティカテゴリー
    表7(p.157)
    カテゴリー 例
    誰が(Who) 従業員、患者、選手、容疑者、顧客、ベンダー、…
    何を(What) 製品、サービス、原材料、完成品、…
    いつ(When) 時間、日付、月、四半期、年、予定、会計年度、…
    どこ(Where) 郵送先住所、配送地点、ウェブサイトアドレス、…
    何故(Why) 注文、返品、苦情、出勤、…
    どのように(HOW) 請求書、契約、合意書、…
    集計(Measurement) 売上、項目数、支払額、…

    View Slide

  31. 実務に即したモデリングの参考になる書籍

    View Slide

  32. 個人的なお気に入り

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  36. 正規化
    1.3.6 (p.179)

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  51. 学校名
    学校コード
    学生番号
    学校コード(FK)
    ファーストネーム
    ラストネーム
    学生誕生日
    応募書類番号
    学生番号(FK)
    応募書類提出日
    論理モデル
    属性を持つ
    学校
    学生 応募書類
    在籍記録を持つ
    提出する

    View Slide

  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

    View Slide

  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
    適切な抽象度で議論する

    View Slide

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

    View Slide

  55. ディメンショナル - OLAP Cube
    最初からクエリのためにデータをスライス
    クエリ

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  59. オブジェクト指向
    DMBOK本5章ではUMLのクラス図のみ紹介
    これだけではオブジェクト指向モデリ
    ングには物足りないのでは?
    学生
    Stdtno:integer
    strdt:date
    Prgm:txt
    ExpctGradedt:date
    ActlGraddt:date
    クラス名
    属性
    メソッド
    1 *

    View Slide

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

    class C {
    //aとbはCのインスタンスより先に生成
    construct(a:A, b:B){

    }
    }

    View Slide

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

    View Slide

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

    View Slide

  63. Quoraの興味深いエントリ
    やや煽りがつよいが、歴史を踏まえてNoSQLのハ
    イプ・サイクルを紹介
    > MongoDBの様なNoSQLに勢いがあるのは何故ですか?SQLと比
    べてどんな利点や欠点がありますか?
    https://bit.ly/3DmAOvv

    View Slide

  64. Quoraの興味深いエントリ
    Q: MongoDBの様なNoSQLに勢いがあるのは何故です
    か?SQLと比べてどんな利点や欠点がありますか?
    A: この質問はちょっと古いですね。NoSQLに勢い
    があったのは2009-2015年にかけての頃です。
    2018年現在は、PostgreSQL 10やMySQL 8などRDBMS
    (以下、わかりやすくSQLと呼びます)でJSONをネ
    イティブに扱える(インデックスを貼ったりツ
    リーの一部を操作したり)のがスタンダードに
    なったので、むしろこれらSQLのほうに勢いがあり
    ます

    View Slide

  65. Quoraの興味深いエントリ
    …(中略)
    ただの水平分散というのはベストケースでO(n)の
    性能しか出ず、
    …(中略)
    アルゴリズム的には「ナイーブ」とか「ブルート
    フォース(力任せ)」と揶揄される悪手です。

    View Slide

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

    View Slide

  67. 今はSQLもNoSQLも両方使う時代
    SQL:
    ● SQL製品の進化
    NoSQLハイプ・サイクル
    性能上がらない
    運用大変…
    NoSQL知見がたまる
    NoSQL:
    ● SQLライクなインターフェース
    ○ 例: KSQL、GAQL、…
    ● MapReduce操作の多くを表面上は
    SQLで置き換え
    ● SQLの裏にあるDB設計・実装は多彩
    ● マネージドNoSQL製品で運用負担減
    両方使うので、今が一番勉強は大変…
    イマココ

    View Slide

  68. アクティビティ
    2 (p.181)

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  73. まとめ

    View Slide

  74. まとめ
    ● モデル = 問題解決のための抽象化
    ● 場面に応じた適切な抽象度
    ○ 概念、論理、物理
    ● 数学的なモデルなら性質を導出しやすい
    ○ 例: リレーショナルモデルの正規化
    ● 数学的でないモデルは経験則を利用
    ○ 自分の経験 + 先人の経験、パターン・アンチパターン
    ● 開発チームが共通言語としてのモデルに習熟する必要

    View Slide

  75. これからの勉強を少しでも楽しくする案内になれば幸いです!

    View Slide