用途から作るか、ソースシステムから作るか：3つのデータモデリングの本質

経営会議で事業別の粗利を見たい、営業部門が商談の中身を分析したい、AIに社内データを読ませて質問に答えさせたい、と、データを見たい場面は次々に生まれます。

こうした要望に応えるための、分析用のデータの設計手法を「データモデリング」と呼び、代表的な手法に、ディメンショナルモデリング、第三正規形、Data Vaultの3つがあります。

3つの作り方は全く違いますが、本質を考えると、違いは「用途から作るか、ソースシステムから作るか」の1点に落ち着くと思っています。

そしてこの1点は、「見たいもの専用にすぐ作るか、先にデータ全体を整えるか」という、現場で毎回迫られる判断にそのまま繋がっています。

そもそも、なぜデータを設計し直すのか

前提として、業務システムの中のデータは、業務を回すための形をしています。

注文が1件入るたびに正確に記録し、キャンセルが出たらその1件だけを正確に書き換える、という使い方に最適化された形です。

一方、分析はデータを「切り口で比較する」行為です。

受注金額を月別に並べる、事業別に比べる、商品別に順位を付ける、と、大量のデータを切り口ごとに集計します。

1件ずつ正確に書き込むのに向いた形と、大量のデータを集計するのに向いた形は、同じデータでも別物です。

そのため、業務システムのデータを分析に使うには分析に向いた形へ設計し直す必要があり、その設計の仕方が、データモデリングの手法として体系化されてきました。

3つの手法は、この設計し直しで「何を第一にするか」という思想がそれぞれ違います。

ディメンショナルモデリング：見たい指標から逆算して作る

「ディメンショナルモデリング」は、「分析する人が速く、分かりやすく集計できる事」を第一にする手法です。

分析の質問は、例えば「先月の、事業別の、受注金額は？」のような形をしています。

この質問は、2つの部品でできています。

• 知りたい数値：受注金額。これを「ファクト」と呼ぶ

• 数値を眺める切り口：先月（日付）と事業。これを「ディメンション」と呼ぶ

質問の中の「〜別の」「〜ごとの」に当たる言葉が切り口で、最後に残る数値がファクト、と考えるとつかみやすいと思います。

ディメンショナルモデリングは、この質問の形をそのままテーブルにします。

• 中心に、数値のテーブルを置く。受注のファクトテーブルなら、1行が受注1件で、受注金額と、日付・事業・商品への繋ぎの番号だけを持つ

• その周りに、切り口のテーブルを置く。日付テーブル（月・四半期・曜日）、事業テーブル（事業名）、商品テーブル（商品名・カテゴリ）

中心に数値、周りに切り口、という星の形になるので「スタースキーマ」と呼びます。

この形にしておくと、「先月の、事業別の、受注金額」は、真ん中の金額を事業の切り口で足し合わせるだけで出ます。

切り口を商品カテゴリに変えても、月を四半期に変えても同じ足し算で答えられるので、BIツールでもAIでも、速く、間違いにくくなります。

作る順番は、見たいものの洗い出しが先、テーブルの設計が後です。

会社全体に広げる時は、「どの業務の、どの数値を、どの切り口で見たいか」を先に一覧表（バスマトリクス）にまとめてから、テーブルを設計していきます。

第三正規形：同じ事実を2箇所に書かない

「第三正規形」は、「データに矛盾を起こさない事」を第一にする整理のルールです。

やり方の要点は「同じ事実を2箇所に書かない」です。

• 顧客の住所は、顧客テーブルの1行だけに置く

• 受注テーブルには顧客番号だけを書き、住所は書かない

• こうしておくと、引っ越しで住所が変わっても直す場所は1箇所で済み、データ全体が矛盾しない

これは元々、業務システムのデータベース設計の標準です。

この整理のまま、分析用のデータを作る方式もあります。

• 販売管理・会計・顧客管理といった業務システムのデータを、第三正規形のまま全社1つの矛盾のないモデルにまとめる

• そこから、用途別のデータマートを切り出す

Data Vault：キーと関係と属性を分けて貯める

「Data Vault」は、「ソースシステムの変化に壊れない事」を第一にする手法です。

データを3種類のテーブルに分けて貯めます。

• Hub：「顧客番号の一覧」「契約番号の一覧」のように、業務上のキーだけを貯める

• Link：「この顧客番号は、この契約番号と結びついている」という、キー同士の関係だけを貯める

• Satellite：顧客の名前や住所、契約の金額といった、キーに付く説明を貯める

狙いは第三正規形での統合と同じく、ソースシステムのデータを1箇所にまとめる事です。

違いはキー・関係・属性を分けて貯めておく点で、例えば販売システムの入れ替えで商品の項目が増えても、説明の属性（Satellite）のテーブルを1つ足すだけで済み、既にあるテーブルを壊さずに受け止められます。

作り方は違うが、本質は「用途から作るか、ソースシステムから作るか」

3つを並べると、作り方の違いの奥に、設計をどちらの端から始めるかという違いが見えてきます。

ディメンショナルモデリングだけが、見たいもの、つまり用途から逆算して設計を始め、第三正規形とData Vaultは、業務システムに既にあるデータから設計を始めます。

切り口も数値も全部を1枚の横長のテーブルにまとめてしまう「ワンビッグテーブル」も、用途から作る側の最も単純な形で、テーブル同士の繋ぎ合わせが要らずExcel感覚で扱えるため現場に好まれ、保存の容量が安くなったクラウドDWHでは合理的な選択になっています。

また、テーブルの設計手法ではありませんが、できあがったテーブルの上に「売上」「解約率」といった指標の定義を載せる近年のセマンティックレイヤーも、定義を先に確定してからデータの取り出し方を導くという意味で、用途から作る側と同じ発想です。

どちらの端から始めるかで、強みと弱みがちょうど裏返しになります。

用途から作る場合：

• 見たいものが決まっているので、関係ないデータには手を付けずに済む

• 出てきたテーブルはそのままダッシュボードに繋がり、最初の用途に最短で届く

• 一方で、設計時に選ばなかった切り口や粒度には応えられない。「月次で事業別に見る」前提のテーブルは、「日次で担当者別に見たい」という要望に作り直しで応える事になる

• 用途が増えるほど似たテーブルが増え、気づけば同じ「売上」を集計しているはずの数字が食い違っていく

ソースシステムから作る場合：

• 特定の見方を想定せず業務の構造をそのまま貯めるので、後からどんな質問が来てもそこから組み立てられる

• データの出どころと変更の履歴が残るので、監査にも耐える

• 一方で、そのままダッシュボードに繋がる形はしておらず、使える形になるまでが長い

• 「データを整備しているのに、成果物がまだ無い」という期間が続き、社内の理解を保てなくなった時点で頓挫する

実務では、両方を前段と後段に並べて使う

ここまで対立する2つの流れとして説明してきましたが、現在の実務では、どちらか1つを選ぶのではなく、データの流れの前段と後段に両方を並べて使います。

dbtを使ったデータ基盤の標準的な構成が、この形です。

• 前段（staging層）はソースシステムから作る。各業務システムから取り込んだデータの名前と型を揃えて整え、この段階ではまだ用途を想定しない

• 後段（mart層）は用途から作る。整えたデータから、見たい指標に合わせたスタースキーマを組み立てる

入口（ソースシステム）と出口（用途）の両方から設計を進め、中間で繋がる構成です。

実際、私がいま進めているクライアント様のデータウェアハウス構築でもこの形を取っており、前段はソースシステムのテーブル構造をほぼ保ったまま整え、後段は「どの指標を、どの切り口で見たいか」から逆算したディメンショナルモデリングで設計しています。

前段を挟んでおくと、見たいものが変わって後段を作り直す時も、整えたデータの再利用で済み、ソースシステムからのやり直しになりません。

どちらから始めるか

両方使うとしても着手の順番は決める必要があり、私の考えは、見たいものがはっきりあるなら、まず用途から1本作る、です。

最初の1本を作る過程では、売上に返品を含めるか、顧客は契約単位か企業単位か、といった定義の議論が発生します。

この議論を経て固まった定義と、整えたデータを、その用途専用にせず、次の用途でも使える共通の層に残していき、ソースシステムから作る資産は最初に一括で作るのではなく、用途をこなすたびに積み上げていきます。

逆に、見たいものが決まっていないうちから全体を整えに行くのは勧めません。

用途を決めずに整えたデータは、いざ使う段になると、粒度や項目がどの用途にも少しずつ足りない事が多いように思います。

そして、似たテーブルの作り直しが2度3度と続いた領域が出てきたら、それが共通の層への投資を始める合図です。

「すぐ作るか、先に整えるか」は、どちらかを選ぶ問いではなく、どの順番で両方やるかの問いだと思っています。