これを読めばあなたもプロフェッショナル!DWH入門

仕事柄、情報分析目的のRDBMSを触ることが多いのですが、こういった情報分析用途に用いるDBをDWH*1と言います。


以前、勉強会の懇親会でユーザーの立場でこういったシステムの構築に関わっているが、経験がなく、どのように構築していいかわからない。
またこの手の知識をどう勉強していいかわからない。と仰っていた方がいました。


別に大して難しい話でもないのですが、独自の単語が多い上、意外と資料がなくて困る分野だなとは思います。
そういうわけで、もしこの手の分野が難しいと感じている方は損をされています。


ぶっちゃけ、DWHは簡単な概念を少し覚えるだけで、もうプロフェッショナルになれます。
ベンダーやSIerともベシャリまくれることができます。


というわけで、自分なりにDWH関連の初歩の知識である上記の簡単な概念をまとめてみることにしました。


押さえておきたい単語は以下の6つ。
情報系システムDWHスタースキーマディメンションファクト)、スタークエリーです。


この記事では情報系システム、DWHの単語の説明で、情報システムにおけるDWHの位置づけを紹介します。
スタースキーマ、スタークエリーの説明で、実際にDWHの典型的な例から情報を問い合せてみましょう。
この記事を読んで、今日からあなたもDWHプロフェッショナル!!

1.情報系システム
情報系システムというのは主に企業の情報システムの中でも、分析用途に使うためのシステムのことを指します。
これには情報を見るためのBIツール*2Excelやアプリケーション、それに後述するDWH等、幅広い概念を含みます。
一般に対義語としてよく使われるのは業務系システムという言葉がよく使われます。

2.DWH
情報系システムを構成する要素の中でもDBに相当する部分をDWHといいます。


ところで、DBとDBMSの違いはご存知でしょうか。学生時代のデータベースの講義ノートを引っ張り出すと、


DB(データベース):複数の応用目的での共有を意図して組織的かつ永続的に定義されたデータ群
DBMS(データベース管理システム):データベースを管理するためのソフトウェア


DWHはあくまで、DBなのでデータのことを指しているので、OracleとかDB2MySQLのようなDBMSとは別物です。
まー、そんなに細かい言葉の定義にこだわらなくていいですし、結構現場でも曖昧な表現をしていますが。


DWH用途でRDBMSを使うときに、問題になる処理はほとんど、大規模データのSELECT、INSERT文です。
OLTP用途*3が小規模データのSELECT文、UPDATEやDELETE等、幅広い使い方をされるのとは対比的です。


この限定された用途のために、RDBMSをDWH用途に使うときは索引やパラメータ、DB設計等で工夫しなければなりません。
このへんはプロのDBAに任せちゃってください。


というわけで、用語の定義はこれくらいにして実際にDWHを構築するのか、そしてそこからどのように情報を取得するのかを説明します。

3.スタースキーマ(ファクトとディメンション)

DWHのDB設計の方針は至ってシンプル、スタースキーマと呼ばれる構造になっています。
例外はありますが、ほぼすべてこの構造です。


以下の図を見てください。□で囲んでいるのはテーブルで→が外部参照です。



赤いテーブル中心になって、青いテーブルが星型にくっついています。これがスタースキーマの所以です。
赤いテーブルをファクトテーブルと呼び、青いテーブルをディメンションテーブルと呼びます。


2つの違いは以下のとおりです。

ディメンション:商品マスタなら、商品名や商品群など、分析の切り口となるマスタデータを含むテーブル。サイズは2,3行〜2,3万行程度
ファクト:ディメンションの属性で切り分けた売上金額や仕入れ数等、分析したい情報を含むテーブル。サイズは数万行〜数億行。

ファクトはディメンションの中で最も粒度の細かい情報を保持しており、それを使ってファクト表と結合されます。
例えば、商品仕入ファクトテーブルは、仕入先コードと商品コードと仕入日付を一意キーとして持っており、
これらを使ってそれぞれ仕入先マスタ、商品マスタ、カレンダーマスタと結合します。


テーブルの定義は以下の図のような感じです。



一度結合してしまえば、ディメンションのより粗い粒度情報をファクトからも取得することができます。
例えば、カレンダーマスターは日付をキーとして持っていますが、月の情報、年の情報を持っているので、
これをマスタより取得して月別、年別の情報を取得できます。
これにより、任意の粒度での分析が可能になります。


スタースキーマでは基本的にファクト同士、マスタ同士が結合したりすることはありません。
また、マスタと結合するマスタみたいなものを導入することはありますが、
これが存在するとスタースキーマではなく、スノーフレークスキーマと呼ばれます。


個人的にはスノーフレークスキーマは可能なかぎり避けるのがベターだと思っています。


4.スタークエリー

DWHでスタースキーマをうまく構成することが出来たとして、そのDWHに投げる問い合わせ、つまり
SELECT文はスタークエリーと呼ばれるものが、最適ですし、ほとんどの例でそれを使用します。


実際にスタークエリーのSQLを使って先のスタースキーマより、情報を取得してみましょう。


1.2011年4月24日という日付にどの商品をどの仕入先から、どれだけ仕入れたかという情報を取得する。

SELECT
 商品マスタ.商品コード, 商品マスタ.商品名,
 仕入先マスタ.仕入先コード, 仕入先マスタ.仕入先名,
 商品仕入.商品仕入数
FROM 
 商品マスタ, 仕入先マスタ, 商品仕入
WHERE
    カレンダーマスタ.日付
    商品マスタ.商品コード = 商品仕入.商品コード
AND 仕入先マスタ.仕入先コード = 商品仕入.仕入先コード
AND カレンダーマスタ.日付 = 商品仕入.仕入日付
AND カレンダーマスタ.日付 = '2011-04-24';
ORDER BY
 商品マスタ.商品コード
 仕入先マスタ.仕入先コード;


商品マスタ、仕入先マスタディメンションを商品仕入ファクトが持っているコード値を使って結合して値を
取得しているのがわかると思います。
ちなみにこの例では、カレンダーマスタと商品仕入を結合する必要性はありません。


では、仕入日付に関してより粒度の粗い月単位の情報で情報を分析する場合はどうするのでしょうか。


2.2010年の月別に'今夜が山田商店'からどの商品をどれだけ仕入れたかという情報を取得する。

SELECT
 カレンダーマスタ.年月
 商品マスタ.商品コード, 商品マスタ.商品名,
 仕入先マスタ.仕入先コード, 仕入先マスタ.仕入先名,
 SUM(商品仕入.商品仕入数)
FROM 
 商品マスタ, 仕入先マスタ, 商品仕入
WHERE 
    商品マスタ.商品コード = 商品仕入.商品コード
AND 仕入先マスタ.仕入先コード = 商品仕入.仕入先コード
AND カレンダーマスタ.日付 = 商品仕入.仕入日付
AND 仕入先マスタ.仕入先コード = '101' --'今夜が山田商店'の仕入れ先コード値
GROUP BY 
 カレンダーマスタ.年月
 商品マスタ.商品コード, 商品マスタ.商品名,
 仕入先マスタ.仕入先コード, 仕入先マスタ.仕入先名
ORDER BY
 カレンダーマスタ.年月
 商品マスタ.商品コード
 仕入先マスタ.仕入先コード;

どうでしょうか、簡単だったと思います。これだけで、DWHから日々の業務で必要なレポートを取得することができます。
スタークエリー万歳!


ここまでの説明を理解すれば、あなたはもう今日から立派なDWHプロフェッショナルです。
もちろん、ETLやパーティショニング、シェアディング等、
大量のデータをRDBMSで処理するために学ぶべきことは他にも色々ありますが、
基本的にDWHの本質は情報の問い合せであり、スタークエリーが発行出来ればOKですし、、
技術的な事は信頼できるベンダーやSEに任せておけば十分だと思います。

*1:基本的にDWHの分野およびこの記事ではDBMSRDBMSを想定しています。

*2:DWHからのレポーティングや情報の可視化とその管理を簡易に行ってくれるツール。OracleIBM、SAP等のベンダーが提供している。

*3:リアルタイムな処理のこと。業務系システムがこの用途になることが多い