データウェアハウスの設計原理

非正規形のデータ構造では更新時異状が発生する。更新時異状があると実装できない機能が(ふつうは)出てくるので、OLTPシステムでは正規化が必要になる。
一方データウェアハウスには日中のデータ更新がないので、OLTPの設計原理に従う必要がない。では何を指針として設計すればよいか。

古典的なデータウェアハウスの設計原理にディメンジョナル・モデルがある。
ディメンジョナル・モデルに従ったDBは、いわゆるスタースキーマ

• 多数の外部キーと小数の数値データからなるファクトテーブルと
• それを取り巻く次元テーブル

この2段でおしまい、という形になる。
このモデルでは、リレーションシップは全てファクトと次元の間に張るのであって、

売上ファクト = { 年月日, 事業部コード(FK), ブランドコード(FK), 製品コード(FK), 数量 }

事業部次元   = { 事業部コード, 事業部名 }
ブランド次元 = { ブランドコード, ブランド名 }
製品次元     = { 製品コード, 製品名 }

↓このように次元テーブル間に張ることはない。

売上ファクト = { 製品コード(FK), 数量 }

製品次元     = { ブランドコード(FK), 製品コード, 製品名 }
ブランド次元 = { 事業部コード(FK), ブランドコード, ブランド名 }
事業部次元   = { 事業部コード, 事業部名 }

ラルフ・キンボールの古典

データウェアハウス・ツールキット

によれば、後者の「スノーフレーク・スキーマ」は、ユーザからのクエリに対する応答速度が低下するので、データウェアハウスの設計としてはよろしくない。

P-112
次元がいかに巨大でもスノーフレーク化してはいけない。
次元をスノーフレーク化させるときには、劣悪なブラウズ速度を覚悟しなければならない。

ところが、この話があてはまるのは古典的な構成のデータウェアハウスシステムに対してであって、
今のDWHではアドホックなクエリのパフォーマンスなんて気にする必要はないのだ。

DWHを構築するほどの会社はBusinessObjectsとかCognosとかのBIツールも買っていて、エンドユーザからのクエリには、これらのツールで対応している。
BIツールは内部に専用のデータファイルを抱えていて、「DWHに接続してSQLを発行する」ということをしない。
この構成では、DWHの役目は「夜間バッチでBIツールのデータファイルを作ること」だけになる。
アドホックなクエリに高速に応答する必要がないから、DWHをディメンジョナル・モデルにする必要はない。

だから、今その辺で動いているDWHには、設計原理やデータモデルなんてものはない。完全フリーダムの世界になっている。