「データマネジメント知識体系ガイド」社内勉強会 - データモデリングで解決する問題を意識する
こんにちは、電通デジタル開発部エンジニアのリチャードです。この記事は、Dentsu Digital Advent Calendar 2021の2日目の記事です。
現在弊社の開発部内では、データマネジメント知識体系ガイド(以下DMBOK本)という本に注目していて、同書籍に関する社内勉強会を不定期で開催しています。
データ基盤などの開発経験が豊富なエンジニアからは、DMBOK本に対して以下のような好意的な意見があがっています。
- 「手探りで取り組んでいた課題が体系化されているので理解しやすい」
- 「自分たちのデータマネジメントの取り組みで、何が足りないのかわかる」
- 「概念を整理した図表が見やすく、コミュニケーションの助けになりそう」
一方でDMBOK本はデータマネジメントに関する知識を網羅的に扱っているので、672ページ、17章と、その分量に圧倒されそうになる書籍です。経験豊富なエンジニアなら知識の整理に役立つ内容ですが、そうではないエンジニアにとっては、次々と出てくる新たな知識や専門用語に壁を感じてしまうかもしれません。
≪目次≫
第1章 データマネジメント
第2章 データ取扱倫理
第3章 データガバナンス
第4章 データアーキテクチャ
第5章 データモデリングとデザイン
第6章 データストレージとオペレーション
第7章 データセキュリティ
第8章 データ統合と相互運用性
第9章 ドキュメントとコンテンツ管理
第10章 参照データとマスターデータ
第11章 データウェアハウジングとビジネスインテリジェンス
第12章 メタデータ管理
第13章 データ品質
第14章 ビッグデータとデータサイエンス
第15章 データマネジメント成熟度アセスメント
第16章 データマネジメント組織と役割期待
第17章 データマネジメントと組織の変革
そこで弊社のDMBOK勉強会では参加のハードルを下げるため、第1章から順に全てを読み込むのではなく、各回順不同に取り上げた章に関して、発表者を募集する形で運営しています。その中で私は「第5章データモデリングとデザイン」について担当し、DMBOK本の内容に入る前段階の心構えとして「そもそもモデリングとは何か？」という内容について、私見を交えて紹介しました。
私が勉強会で紹介した内容は、経験の少ないエンジニアでも、DMBOK本やデータモデリングに関して親しみを感じてもらえる内容だと考えているので、こちらの記事で紹介します。
モデリングとは何か？
「データモデリング」と言われても、具体的に何を指すのかイメージがわかない方もいるかと思います。DMBOK本における定義は以下の通りですが、一読で理解しやすい文章とは言えません。
対する答えとして、ドメイン駆動設計(DDD)コミュニティで有名な松岡幸一郎さんのブログにわかりやすい定義が載っているので引用します。
問題解決のために、物事の特定の側面を抽象化したもの
この定義に従うと、モデルを考える際には、解決したい問題とは何か？を考えるのが重要であると言えます。
具体的な例としてピザの切り分け問題を考えましょう。ピザは実際には真円ではないですが、真円とみなすことでピザの種類に関わりなく複数人で平等な切り分けができます。
この「真円とみなす」というモデルがなかったら、ピザの切り分けは場当たり的になってしまい、問題を解決できなくなります。
また同じピザでも目的、つまり解決したい問題によって適したモデルは変わります。CG(コンピュータグラフィクス)でピザを描画するなら、ワイヤフレームのようなモデルを使うことが多いでしょう。
データモデルが解決する問題を意識する
以上の話を踏まえ、データモデリングにおいて解決したい問題とはなんなのか？それぞれのデータモデルがどんな問題を解決するのに適しているか？を考えると、データモデリングに対する見通しが良くなります。
データモデルの表現方法には多くの種類があり、それぞれの表現方法が得意とする問題の領域は異なります。
ここではデータモデルの解決する問題を考えるため、リレーショナルモデルを例にお話しします。
多くの人にとって、アプリケーション開発の現場で最も頻繁に利用するのがリレーショナルモデルでしょう。リレーショナルモデルは数学の集合論に基づいており、正規化を中心とした理論によって「データ更新の異常」という問題を防ぐのに大きな力を発揮します。
しかし、現実のアプリケーション開発では「パフォーマンスを重視するから正規化しない」「クエリのJOINが複雑になるから正規化しない」といった理由で、あえて正規化を行わない場面もあります。これらの理由は正当でしょうか？そして定量的にどこまでパフォーマンス低下やクエリの複雑度が上がれば、正規化を崩して良いのでしょう？
反対に正規化をしっかり取り入れる場合も、正規化には第1から第5正規形まであるので、現場によっては「第3正規形に従うものとする」といった指針でデータ設計をしているところもあります。では第3正規形までというのは本当に妥当な指針でしょうか？だとすればなぜそう言えるのでしょうか？
アプリケーション開発の現場で感じる不便さに引っ張られて正規化を崩す、あるいは深く理解しないまま正規化に関する指針やベスト・プラクティスに従っていると、間違ったデータ設計のしわ寄せで将来開発がしづらくなります。
そうならないために、データモデルを学び、モデルが得意とする問題領域を理解することが重要です。リレーショナルモデルならば、それがデータ構造をどう表現し、どういった種類の問題を「データ更新の異常」と捉えているのか、といったことです。
データモデルを学ぶとは、問題解決のための「道具」について詳しくなることだと言えます。データに関する問題を解決するためには、問題自体について詳しく知るだけでなく、道具であるモデルについても詳しくなる必要があります。
アプリケーション開発の現場で起きる問題自体は千差万別でも、それを解決するモデルは抽象化され、複数の問題に対して使い回しが効くものです。場当たり的ではなく、自信を持って将来にしわ寄せの来ないデータ設計をするために、1度自分がよく使うデータモデルについてしっかり学ぶことは役に立ちます。
まとめ
本記事の内容はデータモデリングを学ぶにあたっての心構えの話だったので、これを読んですぐにデータモデリングが上達するわけではありません。
しかし、ここで紹介した内容がデータモデリングやDMBOK本を読み解く上で、頭の中を整理する助けになれば嬉しく思います。