2 つのデータモデリング

2 つのデータモデリング

データモデリングについての個人的な捉え方を書いてみました。
Clock Icon2025.03.13

とーかみです。

積極的なデータ活用やデータドリブンな組織を目指す際、データモデリングが話題にあがることがあります。

データモデリングを行うために何をすべきかを考える前に、「データモデリングとはどんなことか」を理解していただきたいと思っています。

この記事では「2 つのデータモデリング」と題して個人的な捉え方を書き出してみました。

まとめ

  • 2 つのデータモデリングとは「データ "で" モデリングする」と「データ "を" モデリングする」です
  • 「データ "で" モデリングする」は、現実をデータで表すことです
  • 「データ "を" モデリングする」は、データを現実に反映しやすくするためにデータを使いやすい形にすることです

データ活用とデータモデリング

DMBOK において、データモデリングは、データ要件をもとにデータマネジメントで扱う範囲を決めるプロセスと記載されています。

ビジネス、企業、業務、システムで扱っているデータは、それぞれの範囲で必要であるため管理していると思いますが、データ活用・データマネジメントの対象としてそのすべてが必要なわけではないため、範囲・粒度・形式を定義します。

データモデリングとは

データモデリングについて調べると、「概念データモデル」、「論理データモデル」、「物理データモデル」が説明のなかで挙げられることが多いです。

私は、これらを書き出すことがデータモデリングの活動そのものではないと考えています。

私のデータモデリングの捉え方として「データ "で" モデリングすること」と「データ "を" モデリングすること」の 2 つに大別することができるため、これらについて説明します。

モデリングとは

データモデリング以外も含めた「モデリング」とは、どのような意味かを整理します。

モデリングとは以下のような意味です。

  • 模型(モデル)を組み立てる
  • 対象を造形する
  • 目に見えないものを目に見える形にする
  • 模倣する

例えば 3D モデリングでは、もととなる現実のオブジェクトや誰かの頭の中にあるアイデアを CG などを使って 3D データとして造形します。

他にも、対象となる事象を数式で表現することもモデリング(モデル化)に該当します。
システムの構成を構成図として表すこともモデリングに含まれます。

データ "で" モデリングする

「データ "で" モデリングする」は、現実をデータで表すことです。

現実をデータで表すとは、例えば現実の「温度」を「温度計」や「温度センサー」をもとにデータにすることです。

IoT の文脈で、 CPS (Cyber-Physical System) という表現があります。
これは、物理世界の情報をセンサーで収集しデータ化、ネットワークを介したサイバー空間で再現し、(現実世界ではコストがかかるような)分析・解析結果を物理世界へフィードバックすることで効果・価値を高めるものです。

最近では、物理 (Physical) だけではなく、 AI/ML の発展とあわせて思考や論理も再現精度があがってきているため、物理より範囲を広げ、現実世界を仮想世界で表現するものとして「デジタルツイン」という表現が好まれています。

「概念データモデル」、「論理データモデル」、「物理データモデル」は、こちらのデータモデリングに分類されます。

ビジネスの中に業務があり、業務の中にシステムがあり、システムの中にデータがあります。
データドリブンとは、データをもとに意思決定や判断を行い、アクションを起こせる状態です。
これは、ビジネスとデータの親和性が高まり距離が近くなることで往復速度が速くなり、往復頻度が高くなることでできるようになります。
(従来はそれぞれが断絶しておりサイロ化した状態だった)

ビジネスとデータの関連性を定義し、親和性を高めることが「データ "で" モデリングする」ということであり、この活動の具体的なチェックポイントとして「概念データモデル」、「論理データモデル」、「物理データモデル」が存在します。

データ "を" モデリングする

「データ "を" モデリングする」は、データを現実に反映しやすくするためにデータを使いやすい形にすることです。

言い換えると、データに対して SQL でクエリを実行したり、 BI ツールで参照するときに使いやすく効率のよい形にしておくということです。

こちらのデータモデリングに分類されるのが「スタースキーマ」、「スノーフレークスキーマ」のような、DWH やデータ構造のモデリングです。

こちらのデータモデリングで考慮されるのは以下のような観点です。

  • ストレージ効率
  • 参照効率
  • データのわかりやすさ

「ストレージ効率」は、同じ価値のデータを効率よく保存することで参照コスト、性能、データの更新コストを下げるものです。
「参照効率」は、 SQL のクエリでコストとなるテーブル結合の効率や条件のフィルタリングのしやすさです。
「データのわかりやすさ」は、異なるデータを関連付けて参照したい場合にどのように統合すればいいかのわかりやすさです。(データの探しやすさや意味のわかりやすさはデータカタログのような機能で実現します)

スタースキーマを例にすると、スタースキーマは、それぞれの属性の詳細情報をもつディメンションテーブルと、ディメンションテーブル間をつなぐファクトテーブルに階層化することで、ストレージ効率、参照効率、データのわかりやすさ(つなぎやすさ)を向上させる考え方です。

データ活用のためのデータモデリングの進め方

データを登録するシステムの導入から始める場合

ビジネスモデルや、ビジネスや業務の中でどのような情報を扱っているかを整理し、データモデルとしてまとめましょう。

それぞれの業務だけでなく、業務を横断したデータ活用についてもこの段階から検討していくとデータのサイロ化を抑制することができます。

この活動は、 SaaS 、パッケージ、フルスクラッチといった導入するシステムの形態を問わず実施することをおすすめします。
(そのうえで、どの部分をどこまで SaaS やパッケージに当てはめるかによってシステム形態を決めるとよいと思います)

(データモデリングとは直接は関連しないのですが、差分反映対象を把握するための更新タイムスタンプや削除を論理削除として表現できるかはデータ活用としては重要になります)

また、ビジネスの変化や企業の規模(部署の分割など)によってデータモデルやデータモデルに対するシステム分割(データアーキテクチャが関連します)も変化することもあるため、定期的に見直しましょう。

データを集め活用するデータ基盤の導入から始める場合

各システム・サービスからデータを集め、データ基盤の中だけでなんとかするのは限界があります。

こちらの場合でも、ビジネスモデルや、ビジネスや業務の中でどのような情報を扱っているかを整理し、データモデルとしてまとめることは重要です。

そのうえであるべき姿と現状を照らし合わせ、当てはめていきながらデータ基盤の導入やデータ統合を考えていきます。

あるべき姿は、データ基盤としての仕組みだけでなく、利用できるようにするデータに対してもどのようなデータとして管理していくのか、どの段階でどのような形で保存していくのかを考えます。

現状は、すでに各システム・サービスがある場合、論理データモデル・物理データモデルは ER 図やテーブル定義としてある場合が多いと思いますので(なければ作って・更新してください)、それらを束ね全体が見渡せるような概念/論理データモデルを作ります。

あるべき姿と現状をもとに当てはめていくと、不足している部分が見えてくると思いますのでそれらに対して戦略を立て、計画し、実行していきます。

まとめ(再)

  • 2 つのデータモデリングとは「データ "で" モデリングする」と「データ "を" モデリングする」です
  • 「データ "で" モデリングする」は、現実をデータで表すことです
  • 「データ "を" モデリングする」は、データを現実に反映しやすくするためにデータを使いやすい形にすることです
  • 後からデータ基盤を構築したりデータ活用ができる環境を作りたい場合、今あるものをかき集めてなんとかするのではなく、ビジネスレベルから棚卸しし、概念/論理データモデルを整理しながら、今あるものを当てはめ、足りないものをどうするかの戦略を立てます

以上、個人的な考えを書き出したものになりますが、みなさまの参考になれば幸いです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.