DMBOK準拠のBigQueryにおけるOBT設計
「BI描画が遅い」「JOINが難しい」…その悩み、BigQuery×OBTで解決しませんか？DMBOKの基礎を押さえつつ、巨大な一枚テーブル（OBT）を作成する具体的な3層設計フローを解説します。コスト削減とデータ民主化を実現する、モダンなデータモデリングの実践ガイドについても触れます。
なぜ今、OBT（One Big Table）なのか？
OBTとは、その名の通り「一つの巨大なテーブル」のことです。 ファクトテーブル（事実）にあらゆるディメンションテーブル（属性）をあらかじめ結合（JOIN）し、非正規化（Denormalization）した状態で保持するモデルを指します。
BigQueryとOBTの相性は抜群
従来のRDBでは「正規化」による重複排除が正義でしたが、BigQueryにおいてはOBTが以下の理由で推奨されるケースが増えています。
- カラムナ（列指向）ストレージの特性 BigQueryはデータを列単位で保存します。横に長い（カラムが多い）テーブルであっても、クエリで必要なカラムだけを指定すれば、スキャン料金やパフォーマンスに悪影響を与えません。
- JOINコストの削減 分散処理基盤であるBigQueryにとって、巨大なテーブル同士のJOIN（Shuffle操作）は比較的コストの高い処理です。OBTであらかじめ結合しておけば、分析クエリ実行時の計算リソースを大幅に節約でき、レスポンスも高速化します。
- エンドユーザーへの利便性（データ民主化） 「売上」と「顧客マスタ」と「商品マスタ」を都度JOINして…というSQLを書かなくても、OBTなら
SELECT *（あるいはBIツールのドラッグ＆ドロップ）だけで分析が完結します。
DMBOKの視点から見るOBT設計
DMBOKの「データモデリングとデザイン」の章では、概念・論理・物理の3段階のモデリングが提唱されています。OBTを採用する場合でも、この思考プロセスは無視できません。いきなり巨大なテーブルを作るのではなく、以下のように段階を踏みます。
- 論理モデル（スタースキーマ等の整理） まずは正規化された形やスタースキーマとして、ビジネスエンティティ間の関係性（リレーション）を整理します。ここでデータの整合性やビジネスルールを定義します。
- 物理モデル（OBTへの変換） 論理モデルで定義された関係性を、BigQueryの物理テーブルとして実装する際に「非正規化」を選択します。ここでパフォーマンス要件に応じたOBT化を行います。
【実践】レイヤーアーキテクチャによるOBT構築フロー
OBTを作成する際は、dbt（data build tool）などで採用される「3層アーキテクチャ（ELT）」の考え方を取り入れると、DMBOK的な品質管理と物理的なパフォーマンスの両立が容易になります。
以下に、StagingからMart（OBT）に至るまでのデータパイプラインの流れを図解します。
┌─────────────────────────────────────────────────────────────────────────┐
│ STAGING LAYER (stg) │
├─────────────────────────────────────────────────────────────────────────┤
│ ・Rawデータの取り込み（Source） │
│ ・型変換（Casting）、カラム名のリネーム（英名化） │
│ ・PII（個人情報）のハッシュ化やマスキング処理 │
│ ・1対1の単純な変換処理（データの標準化） │
└─────────────────────────────────────────────────────────────────────────┘
│
│
▼
┌─────────────────────────────────────────────────────────────────────────┐
│ INTERMEDIATE LAYER (int) │
├─────────────────────────────────────────────────────────────────────────┤
│ ・ビジネスロジックの適用 │
│ ・論理モデルの形成（ファクトとディメンションの準備） │
│ ・共通利用される中間テーブルの作成 │
│ ・複雑な結合の前処理 │
└─────────────────────────────────────────────────────────────────────────┘
│
│
▼
┌─────────────────────────────────────────────────────────────────────────┐
│ MART LAYER (mart) │
├─────────────────────────────────────────────────────────────────────────┤
│ 【 ここが OBT (One Big Table) 】 │
│ ・Intermediateのファクトとディメンションを全てJOIN │
│ ・分析ユーザーが使いやすいカラム名（日本語ラベル等）への最終調整 │
│ ・BigQueryのパーティション(Partition)とクラスタリング(Cluster)の設定 │
│ ・BIツールから直接参照される最終成果物 │
└─────────────────────────────────────────────────────────────────────────┘各レイヤーの役割と設計ポイント
1. STAGING LAYER (stg)
「データソースをそのまま映す鏡」ではなく、「きれいに整えられた素材」を作る層です。 DMBOKで言う「データ品質」の第一関門です。ここでデータ型やNULLの扱いを統一しておかないと、後のOBT作成時に結合キーがズレる等の問題が発生します。
2. INTERMEDIATE LAYER (int)
ここで「論理モデル」を組み立てます。 OBTを作るからといって、いきなり全てを結合するのではなく、一度「注文単位」「顧客単位」などでデータを意味のある粒度にまとめます。この層があることで、もしOBTの定義が変わっても、ロジックの修正範囲を局所化できます。
3. MART LAYER (mart) – OBTの完成
ここで物理的なパフォーマンス最適化を行います。 BigQueryにおけるOBT設計の肝は「パーティション」と「クラスタリング」です。 例えば、order_dateでパーティションを切り、customer_idやproduct_categoryでクラスタリングを行うことで、数億行のOBTであってもスキャン量を抑え、高速に検索可能な状態を作り上げます。
また、BigQuery特有の機能として「Nested Fields (RECORD/STRUCT型)」の活用も検討してください。1行に対して複数の明細（1対Nの関係）を持たせる場合、無理に行を増やさず、ARRAY型としてネストさせることで、OBTの可読性を保ちつつ情報を集約できます。
まとめ
DMBOKが教える通り、データマネジメントの目的は「データから価値を引き出すこと」です。
「正規化こそが美しい」というRDB時代の固定観念にとらわれず、BigQueryというプラットフォームの特性を最大限に活かすためにOBTを採用する。それは、「分析までのリードタイム短縮」や「クエリパフォーマンスの向上」というビジネス価値に直結します。
これからデータ基盤を構築、あるいはリファクタリングする際は、ぜひこの3層構造を用いたOBTモデルの導入を検討してみてください。
