分析用データモデリングの基礎 ~リレーショナルデータモデルとディメンショナルデータモデルの違い~
はじめに
データの価値を最大限に引き出すためには、「分析しやすくする」必要があります。
この目的を達成するためのアプローチには、「メタデータ管理」「マスタデータ管理」「データモデリング」などがあります。
この記事では、特に「データモデリング」に焦点を当てます。
動機
基幹システム開発のエンジニアからデータエンジニアにキャリアを変えた当初、ディメンショナルデータモデルについては「ファクト」「ディメンション」「スタースキーマ」「スノーフレークスキーマ」など主要な言葉の概要についてはわかっているつもりでした。しかし、実際に分析用のデータモデリングを行う際には、リレーショナルからディメンショナルへの考え方の転換に苦労しました。
そこで、改めてディメンショナルデータモデリングに関する理解を深めるために「リレーショナルデータモデルとディメンショナルデータの考え方の違い」や「ディメンショナルデータモデリングの進め方」についてまとめることにしました。
（あわよくば、社内研修資料などの元ネタにできればいいかなとも思ってます。）
対象読者
- 業務系システムのリレーショナルなデータ構造に慣れている人
- 分析用のデータ設計を行いたいが、リレーショナルからディメンショナルへの考え方の転換が難しいと感じている方
この記事でやること/やらないこと
やること
- リレーショナルデータモデリングとディメンショナルデータモデリングの違いの説明
- ディメンショナルデータモデリングの大まかな進め方
- 【別の記事で書く予定】ケーススタディ：レンタルDVDショップの例
やらないこと
- データパイプライン（ETL,ELT）やSQLについて
- ディメンショナルデータモデリングの応用的なテクニック
- その他データマネジメントに関わる内容
リレーショナルデータモデルとディメンショナルデータモデルの違い
| 特徴 | リレーショナルデータモデリング | ディメンショナルデータモデリング |
|---|---|---|
| 主な目的 | ・業務データの整理と管理 | ・データの分析と意思決定の支援 |
| 主な用途 | ・業務用システム ・ECサイト など |
・データウェアハウス ・分析用システム ・BIツール など |
| データ構造 | ・データを正規化し、重複を避ける ※正規化：1つの事柄を1つの場所で管理すること |
・中心に「ファクトテーブル」と周囲に「ディメンションテーブル」を配置する ・正規化を重視しない ※ファクト：集計対象となる数値や業務プロセス ※ディメンション：分析のための文脈を提供（日付、場所、顧客など） |
| クエリの複雑さ | ・テーブル間の関連が多いため複雑 | ・ファクトとディメンションの結合キーが明確なため容易 |
| 変更への対応 | ・スキーマの変更可能だが大規模変更は困難 | ・ビジネスの変化に柔軟に対応可能 |
まず、両者の目的には明確な違いがあります。
リレーショナルデータモデリングは「記録・管理」に特化しており、ディメンショナルデータモデリングは「分析」に特化しています。
この目的の違いが、データ構造に影響を与えています。
リレーショナルデータモデルは、システム的なデータの管理のしやすさを重視して正規化されたデータモデルです。
これは主に業務系のシステム内で利用されており、業務ユーザーから直接データにアクセスされることや分析に使われることを重要視しません。
そのため、分析しようとするとそのシステムに関する知見や複雑なクエリを書くスキルが必要となります。
それに対して、ディメンショナルデータモデルは大量のデータを分析するために最適化されたデータモデルです。
データ間の関連がシンプルであるため、比較的簡単なクエリであらゆる観点での分析が可能になります。
基本的なディメンショナルデータモデリングのプロセス（キンボールの4ステップ）
ディメンショナルデータモデリングで最も有名なアーキテクトであるRalph Kimball博士は、モデリングの設計プロセスを下記の4つとして提唱しています。[1]
- Select the business process. => 業務プロセスを特定する
- Declare the grain. => 粒度を宣言する
- Identify the dimensions. => ディメンションを定義する
- Identify the facts. => ファクトを定義する
業務プロセスの特定
業務プロセスとは「注文の受付」「出庫処理」「荷受処理」「月報作成」など、会社や組織の中で行われている普段の「業務」のことです。
そして、ディメンショナルモデリングとは、ある業務プロセスに的を絞った分析に最適化されるようにデータを構造化することです。
そのため、モデリングの第1ステップとしては、まずは対象としたい業務プロセスを特定することが重要です。
粒度の特定
粒度の特定とは、ファクトテーブルの1行がどのような粒度で発生するのかを明確にするということです。
つまり、「集計・分析したい対象の最小粒度とは何か？」という問いの答えを考えることになります。
ここで特定した粒度を基にディメンションテーブルが構築されるのですが、その粒度よりも細かい分析をすることは難しくなるため、「粒度の特定」はディメンショナルモデリングの最重要のステップと言えます。
まずは、5W1H（誰が、何を、どこで、いつ、なぜ、どのように）の観点で整理するのが進めやすいと言われています。
ディメンションの特定
上記で特定した粒度のそれぞれを説明する属性を特定します。
例えば、特定した粒度の中に「顧客」というものがあった場合を考えてみましょう。
顧客を説明する属性としては「氏名」「生年月日」「性別」「居住地」「会員区分」「入会日」「退会日」「職業」などが考えられます。
これらの属性は分析時に「集計軸」「絞込条件」として使われることになるため、属性が多いほど、多くの切り口での分析が可能になります。
そのため、できるだけ多くの属性を洗い出せると良いです。
ディメンションの属性には時間が経過すると変化するものもあります。
上記の例で言えば、「顧客の引っ越しによって"居住地"が東京から大阪に変わる」などです。
このような現象は「Slowly Changed Dimension(略称：SCD 和訳：緩やかに変化するディメンション)」と呼ばれ、どのように管理するかの設計手法は複数あります。
ここでは深く触れませんが、タイプ1〜タイプ3が一般的だと考えます。
- タイプ1：行を追加せず、新しい値で古い値を上書きする。
- タイプ2：新しい値を持つ行を追加する。古い値の行とは「有効期間」や「バージョン」で識別する。
- タイプ3：行を追加せず、新しい値・古い値を持つ列をそれぞれ設ける。
SCDについては、下記のようなサイトが参考になります。
ファクトの特定
対象とする業務プロセスの粒度で発生する測定値（基本的に数値）を特定します。
ファクトテーブルの1行は上記で特定した業務プロセスの粒度になるため、ここで特定した測定値はファクトテーブルの1行で持つことになります。
対象の業務プロセスの粒度とは異なる測定値はファクトに含めるべきではありません。
ファクトはディメンションから提供される各属性によって集計されて使われますが、その際に重複して集計されてしまうためです。
今後の話
「リレーショナルデータモデルとディメンショナルデータモデルの違い」と「ディメンショナルデータモデルの大まかな進め方」を知ったところで、腹落ちはできないと思うので、ケーススタディをまとめたいなと思ってます。
具体的には、MySQLのSakillaデータベース(レンタルDVDショップのリレーショナルデータ)を使った売上分析などを題材にしたいなと。
Discussion