datatech-jp で Star Schema The Complete Reference という書籍の輪読会を始めました。
Star Schema The Complete Reference
私は横断組織にいて、サービス事業部の方たちの支援をするのが仕事なのですが、そのためにデータオーナーになったりすることがほとんどありません。最近は支援している事業部数も増えて、一つの事業部のデータをしっかり見ることもなく、データモデリングやデータウェアハウスの構築に関する知見を溜めるにはどうしたらよいか…と考え、手始めに座学から始めようと考えました。
この本はディメンション設計に関して、中立的に、かつ特定のソフトウェア・ハードウェア・データウェアハウス製品に依存することなく説明することを試みた参考書です。 Inmon 氏の Corporate Information Factory と Ralph Kimball 氏のデータウェアハウスアプローチはどちらも丁寧に解説されています。全18章のうち最初の3章は必読ですが、残りの章はどこから読んでもよい構成になっています。
今日は第1章、"Chapter1 Analytic Databases and Dimensional Design" を読み合わせました。導入章なので用語や概念の説明が多かったのですが、スタースキーマではファクトとディメンションはサロゲートキーで繋ぐべき、というのが私には新しい学びでした。これはディメンションに変更がある場合（これを Slowly Changing Dimensions と呼ぶそうです）に履歴管理ができるようになります。詳しくは以下のブログ記事で分かりやすく解説されていますので、よければご覧ください：
サロゲートキーをどうやって構築するのか？
輪読会中に、サロゲートキーは誰がどうやって生成するのかについて議論になりました。
業務システムとは異なり、データ分析では最新のデータだけでなく、関心対象の時刻のときにディメンションがどういう値だったのかという履歴が重要になる場合があります。自然なキー（Customerというディメンションなら、 customer_id などの会員識別子など）ではなく、あえてサロゲートキーを使うことでこの問題に対応することができます。
ではこのサロゲートキーはどうやって構築されるのか？書籍の後半に載っているのかもしれませんが、Ralph Kimball 氏の記事を見つけました（かなり古いですが…）
Surrogate Keys - Kimball Group
It is up to the data extract logic to systematically look up and replace every incoming natural key with a data warehouse surrogate key each time either a dimension record or a fact record is brought into the data warehouse environment.
Fundamentally, every time we see a natural key in the incoming data stream, we must look up the correct value of the surrogate key and replace the natural key with the surrogate key. Because this is a significant step in the daily extract and transform process within the data staging area, we need to tighten down our techniques to make this lookup simple and fast.
具体的な生成方法については書いていませんが、データを抽出してデータウェアハウスに入れるときの処理でサロゲートキーを生成する、とあります。 this is a significant step ともあるので、簡単な処理ではないようです。
まだ適切な方法は見つけられていませんが、調べた情報を載せてみます。ノウハウをお持ちの方がいましたら、ぜひご教示ください。
ディメンションテーブルを先に更新する？
Stack Overflow にスタースキーマにおけるサロゲートキーの扱いについての質問がありました
- ディメンションテーブルでサロゲートキーを生成する
- ファクトテーブルは、まずナチュラルキーでディメンションテーブルとジョインし、対応するサロゲートキーを取得する
適当にやるとぐちゃぐちゃになりそうです。。ディメンションとファクトの更新タイミングについて、ディメンションテーブルが必ず先に更新されるようにし、ファクトテーブルはナチュラルキーと適当な条件（日付など？）を組み合わせればうまくいくようにも思えますが、果たして。。
ETL 処理の中で定義する？
IBM の db2 という製品において、スタースキーマにおいてサロゲートキーを生成する手順が紹介されていました：
IBM の InfoSphere Information Server という製品でも、スタースキーマにおけるサロゲートキーの生成方法が紹介されています：
どちらも詳しくはよく分からないのですが、ETL 処理の中でどのようにサロゲートキーを構築するかを指定することができるようです。
ハッシュ値を使う？
いろんな記事を見ている中で、何度かハッシュ値をサロゲートキーとして利用しているケースを見かけました。（後日もう少し調べてみます）
ディメンションとファクトそれぞれでキー生成出来るので、十分あり得る選択肢でしょうか。ただファクトとディメンションが必ず結合できるかは保証されないため、品質面で問題が出てくるかもしれません。
