技術書読書ログ「Star Schema The Complete Reference」
概要
スタースキーマについて、がっつり書かれた書籍です。現状だと、一番詳しく書かれている書籍らしい。
スタースキーマ: ディメンショナルモデリングで設計する実際のスキーマタイプ
-
論理設計レベル: データの設計手法の種類
- 第3正規形（3NF）モデリング
- Data Vault
- ディメンショナルモデリング: データウェアハウスで分析しやすい形でデータを構造化方法
-
物理設計レベル: ディメンショナルモデリングの具体的なスキーマ構造の種類
- スノーフレークスキーマ
- ギャラクシースキーマ
- スタースキーマ: ファクトテーブルを中心に、複数のディメンションテーブルが放射状に並ぶ構造
- ディメンション設計の基礎から始まり、WH InmonやRalph Kimballのアーキテクチャやスタンドアロンデータマートにどのように適合するかやその歴史や違いについての説明
- 実際の設計手法やセマンテックレイヤーの解説
- ディメンショナルモデリングで設計するプロジェクトの進め方や必要なドキュメント
など、実用的な内容が載っています。
個人的に重要だと思ったところ
データウェアハウスアーキテクチャの比較
- 読む前は、データウェアハウスアーキテクチャの提唱者でBill InmonとRalph Kimballという人がいて、それぞれの日本語訳本（もはや古典）を流し読む程度だった。この書籍で比較して説明していたので、データウェアハウスアーキテクチャの全体像を把握できた
| アーキテクチャ名 | 提唱者 | 説明 | ディメンショナル設計の役割 |
|---|---|---|---|
|
Corporate Information Factory (コーポレート情報ファクトリー) |
Bill Inmon | ・エンタープライズDWHはアトミック（詳細レベル）データの統合リポジトリ ・直接アクセスされない ・部門ごとの利用・分析のためにデータマートへ再編成 |
データマートにのみディメンショナル設計を使用 |
|
Dimensional Data Warehouse (ディメンショナルDWH) |
Ralph Kimball | ・ディメンショナルDWHはアトミックデータの統合リポジトリ ・直接アクセス可能 ・サブジェクトエリア（テーマ別領域）は“データマート”と呼ばれることがあるが分離されたDBである必要はない |
全てのデータがディメンショナルに整理される |
|
Stand-Alone Data Marts (スタンドアロン・データマート) |
提唱者なし | ・エンタープライズ全体の文脈を持たないサブジェクトエリア単位の実装 | ディメンショナル設計が使われることもある |
リポジトリ = データを一元的に集約・保管する場所（データベース）
| アーキテクチャ | 企業レベル | サブジェクトエリア（部門）レベル | ||||
|---|---|---|---|---|---|---|
| 統合リポジトリの有無 | 形式 | 直接アクセス | データマート | 形式 | 直接アクセス | |
| Corporate Information Factory | ✅ | 3NF | ❌ | 物理的 | ディメンショナル（※） | ✅ |
| Dimensional Data Warehouse | ✅ | ディメンショナル | ✅（※） | 論理的（※） | ディメンショナル | ✅ |
| Stand-Alone Data Marts | ❌ | n/a | n/a | 物理的 | ディメンショナル（※） | ✅ |
※: オプション
スター・スキーマの基本要素
- ディメンションテーブル
- 自然キーと代替キー（サロゲートキー）を持ち、履歴管理が可能。
- 列数は多く、分析に有用な属性を豊富に持たせる。
- 数値型のディメンションも存在し、使用方法でファクトと区別される。
- 正規化はせず、第3正規形にはしない。
- ファクトテーブル
- ディメンションへの外部キー＋ファクト値で構成される。
- 加算できない値（比率など）は、加算可能な構成要素に分解し、レポート時に計算。
- 疎な構造（イベント発生時のみ行が存在）= スパース性
- 粒度は明確に定義する。
- 縮退ディメンションはファクトテーブル内にあるディメンション
ファクトの加算性（Additivity）による分類
| 種類 | 定義 | 例 | 集計可能な軸 |
|---|---|---|---|
| 加算可能 | すべての軸（ディメンション）で合計できる | 売上金額、数量、コスト | 日付・商品・店舗などすべて |
| 半加算可能 | 一部の軸では合計可能だが、他ではNG | 在庫残高、口座残高、スナップショット値 | 店舗・商品ではOK、日付ではNG（時点ごとの値） |
| 非加算 | どの軸でも合計できない | 単価、利益率、ROAS、平均値、比率 | 集計は平均・中央値などを使う |
茹でガエルのたとえ話（boiling the frog）
- カエルをぬるま湯に入れて、少しずつ温度を上げていくと、カエルは変化に気づかずにそのまま茹で上がってしまう（という寓話）。これは、「小さな問題の積み重ねが、やがて大きな問題になる」という警鐘を鳴らす話です。
- 異なるプロセス（例：注文と出荷）に関するファクトを1つのファクトテーブルに入れてしまうと、クエリで必ず条件を追加しなければならないようになります（
HAVING句など）。
SELECT product_key, SUM(quantity_shipped) FROM sales_facts
GROUP BY product_key
HAVING SUM(quantity_shipped) > 0
- その追加作業は最初は小さく感じても、あらゆる分析で同じ対応が必要になり、最終的には大きな負担になります。つまり、設計時の手抜きが、将来の分析作業の重荷になるということです。
Schema design time, as my friend used to say, is your chance to “un-boil” the frog.
スキーマ設計は、私の友人がよく言っていたように、カエルを「煮る前に冷ます」チャンス
理解を助けるドキュメント作成
属性階層を文書化
スタースキーマ構築の設計や理解を助けるためのドキュメントの作成方法が記載されていました。
- ディメンションテーブルの文書化。基本的に第２正規化までしかしていないのでディメンショナルテーブル内での項目の粒度や階層構造の把握が難しい場合があるので下記の図を作成しておくを理解が速くなります。
- とはいえ、綺麗に階層を分類できるとは限らないので、全てのケースで使えるわけではなさそう
階層が明示されていれば、集計の粒度は階層の一部を丸で囲むだけで定義できる
ダッシュボードや集計の要件定義に使えそうな図ではある
適合マトリクス
適合マトリクスは実装の青写真として機能しそう
マトリックス図を使用して、ファクト テーブルまたはサブジェクト領域全体のディメンションの適合性を文書化が可能。セマンテックレイヤーを運用する場合。ビジネスユーザーの理解の助けになる可能性がある
感想
序盤で著名なアーキテクチャの比較があったことで、データエンジニアリング全体の構造が把握しやすく、全体像を掴むうえでとても助けになりました。それぞれのアーキテクチャについて、単なる紹介ではなく、メリット・デメリットを踏まえた解説がなされており、非常にバランスの取れた書籍だと感じました。
最近読んだ『アジャイルデータモデリング 組織にデータ分析を広めるためのテーブル設計ガイド』では、より上流工程の観点から語られており、モデリングの目的は理解できる一方で、実際にどうSQLに落とし込むかという点が少しイメージしにくい印象がありました。しかし、本書を通じてアジャイルデータモデリングで目指していることや、その背景への理解が深まりました。
また、意外だったのがセマンティックレイヤーに関する記載の多さです。頭から読み進めていくことで、キンボールの世界観が、近年の技術進化によってよりスマートに実現できるようになってきていることを実感できました。
Discussion