データ基盤

データウェアハウスは、何をそろえて数字を一つに近づけるか

2026/10/4 （更新: 2026/10/4） シリーズ「データ基盤はなぜ作り直されてきたか」 第2回 / 全3回

🤖 AIが執筆しています

業務システムごとに抜き出すと、同じ問いに別々の数字が返る

データウェアハウスの考え方を示した最も早い論文の一つとしてよく挙げられるのが、IBM の Devlin と Murphy が 1988 年に発表した論文である¹。二人は当時の企業の状態を、特定の情報が必要になるたびに、業務システムからデータを取り出す独立した手順が作られ、その手順どうしがしばしば食い違っていた、と書いている。データがあっても問い合わせに向かない形なら、情報システム部門は依頼のたびに取り出しの手順を作らなければならず、依頼が積み重なって大きな遅れが生じた。二人の提案は、会社のデータを一つに統合した倉庫を関係データベースの上に作ることだった。二人は、この倉庫を業務システムと分ける理由の最初に、思いつきの問い合わせや分析で本番の業務システムの性能を乱さないことを挙げている。

Chaudhuri と Dayal は 1997 年の解説論文で、性能のほかにも業務システムのデータがそのままでは分析に使えない理由を挙げた²。推移を見るための過去のデータが業務用のデータベースには無く、さらにデータの出どころごとに品質が違い、表し方・コード・書式が食い違うので、それらをそろえる必要がある。同じ論文は、Inmon の定義を引いて、データウェアハウスを「主題別に整理され、統合され、時間とともに変化を記録し、書き換えられない」データの集まりで、主に組織の意思決定に使うものと説明している。

食い違いの具体的な形は、Rahm と Do が 2000 年の論文で整理している³。同じものを別の名前で呼ぶ（顧客を Customer と Client で呼ぶ）、同じ値を別のコードで書く（性別を “0”/“1” と “F”/“M” で書く）、同じ量を別の単位で持つ（ドルとユーロ）。さらに、同じ人が二つの番号を持つこともあれば、別々の人が同じ番号を持つこともある。二人は、データクレンジング（食い違いや誤りを見つけて直す作業）がデータウェアハウスの最大の問題の一つとみなされている、と書いている。

取り出してそろえる ETL が、データウェアハウスを作る手間の大きな部分を占める

業務システムのデータを取り出し、そろえ、データウェアハウスに入れる一連の処理を ETL（抽出・変換・ロード）と呼ぶ。Vassiliadis は 2009 年の解説論文で、ETL の仕事を、出どころからの取り出し、作業用の領域への転送、共通の形への変換と新しい値の計算、問題のある行の切り分けと修正、データウェアハウスへのロードの五つに分けている⁴。

ETL がどれだけ手間を食うかについて、Kimball は 2004 年の記事で、構築の時間と労力の 70% を占めるとしばしば見積もられる、と書いた⁵。この数字に出典や測り方は示されていない。Kimball Group の現在のページは、割合を挙げずに「不釣り合いに大きな部分」とだけ書いている⁶。

業界団体の TPC がデータウェアハウスの性能を比べるために定めた TPC-DS の仕様は、そろえる作業を前提として組み込んでいる⁷。仕様は、販売の三つの経路（店舗・カタログ・通販）のシステムが、異なる時期に異なる要件で別々の集団によって設計され、顧客や住所の情報を重複して持つ、と想定している。そのうえでデータウェアハウスの側を、7 つのファクトテーブル（売上 1 件のような出来事を 1 行ずつ記録する表）と 17 のディメンションテーブル（日付・商品・顧客のように出来事を見る切り口の表）で組む。

過去の状態の残し方にも、決まった手法がある。Kimball の流派は、ディメンションテーブルの値が変わるときの扱いを SCD（Slowly Changing Dimension、緩やかに変化するディメンション）と呼び、型に分けている⁸。型 1 は古い値を新しい値で上書きし、履歴を失う⁹。型 2 は変更後の値を新しい行として加え、各行に有効期間の開始と終了の日付を持たせる。TPC-DS の仕様は、ディメンションを、変わらないもの（日付）、出来事が起きた時点の値に結び付けて「歴史上の真実」を保つもの（商品）、上書きして前の値を失うもの（顧客）の三つに分けている⁷。

Inmon と Kimball は、どこでそろえるかで分かれた

データウェアハウスの設計には、二つの代表的な流派がある。どちらも、部門ごとに業務システムから別々に抜き出す形が数字の食い違いを生むという点では一致している。Kimball の流派の Ross は 2004 年の記事で、同じ業務システムからの調整されない複数の抜き出しは、名前の付け方や業務の規則が少しずつ違う版を生み、混乱とやり直しと突き合わせを招くと書いた¹⁰。二つの流派が分かれたのは、どこでそろえるかである。

正規化は、同じ事実を一か所にだけ持つように表を分ける設計の手法である。Inmon は、全社のデータを正規化した表の形で一つの倉庫に集め、部門向けのデータマート（特定の部門や用途向けに切り出した小さなデータの集まり）は、その倉庫だけを出どころにする形を説いた¹¹。Inmon によれば、この倉庫は、どのデータが正しいかについての「最後の言葉」を持つ場所になる。Inmon は同じ文書で、古い業務システムのデータの統合は複雑で時間がかかり、この形の倉庫を作るのは簡単でも速くもないと認めている。

Kimball は、スタースキーマを中心に置いた。スタースキーマは、ファクトテーブルを中心に置き、その周りにディメンションテーブルを星形につなぐ表の組み方である。Kimball は 1997 年の記事で、業務の処理に向けて設計した表の構造は利用者が理解も記憶もできず、問い合わせられないデータベースになったと批判した¹²。統合の要には、部門をまたいで同じ列名と同じ値の範囲を持つディメンションテーブル、つまり適合ディメンション（conformed dimension）を置く。Kimball の流派は、適合ディメンションを「統合の本質」と呼ぶ¹³。Ross は、正規化した表はデータの関係を表すが、統合に要る共通のキーやラベルをそろえる圧力は生まない、と Inmon の形を批判した¹⁰。

Inmon は Kimball の初期の形を、業務システムから直接作った部門ごとのデータマートの寄せ集めとして描き、適合ディメンションについても、会社の属性の一部しかそろえず、残りは統合されないと批判する¹¹。これに対して Ross は 2004 年の別の記事で、適合ディメンションなしに部門ごとに作ったデータマートは統合が難しく、だから自分たちはその形を勧めないと書いた¹⁴。前者は相手の流派を外から見た説明であり、後者は当事者の自己説明である。ただし Kimball 自身は 1997 年の記事ですでに、全社のデータウェアハウスを業務の過程ごとのスタースキーマで組み、適合ディメンションで結び付けることを求めていた¹²。

Chaudhuri と Dayal は、全社のデータウェアハウスの構築は長く複雑な過程で成功までに何年もかかりうるとし、部門ごとのデータマートは速く作れるが、全体の業務のモデルが無いと後で統合が難しくなると書いた²。調査会社の Gartner は 2005 年の発表で、2007 年までにデータウェアハウスの事業の半分以上が限られた利用にとどまるか失敗するとし、原因をデータの品質への注意不足に求めた¹⁵。これは予測であり、発表は測り方を示していない。

倉庫を作っても、指標の計算の規則が割れると数字は割れる

データウェアハウスを作った後でも、数字が一つになるとは限らない。Kimball の流派も、数値の列を同じ業務規則で計算する適合ファクトを説き、規則が違う数値には別の名前を付けるとしていた¹⁰。Ross は別の記事で、全社で定義と業務規則をそろえるときに組織と文化の障害は避けられず、技術は易しい部分だとも書いていた¹⁴。それでも数字は割れた。Uber の技術ブログは 2021 年に、同じ指標についてチームごとに自分のデータの流れを作り、別々の道具に出すと、数字が食い違いうると書いた¹⁶。その例として、同じ都市・同じ期間の同じ指標が、社内の二つの道具で 653 万と 620 万に分かれた。原因は、一方の道具の問い合わせに、乗客の状態の最新の一覧を反映していない古い絞り込みの条件が残っていたことだった。Uber はこの問題に、一つの指標に一つの計算の規則を対応させ、全社で共有する仕組みで対応した。

Airbnb の発表資料も、データ基盤を作った後に指標の数字が割れた例を挙げている¹⁷。2015 年には、チームごとに違う数字を報告する問題が残り、修正が下流に伝わらず、意思決定をする人の信頼が下がった。Airbnb はその後、指標の定義を一か所で管理する仕組みを作り、資料の時点で 3 万を超える指標をそこで管理していると報告している。同じ資料は、その仕組みの最初の版の課題として、絞り込みの条件だけが違う指標の変種が生まれたことと、あらかじめ計算されていない指標が要る利用者は、過去分の再計算を待つか、一元管理を迂回して自分で書き直すしかなかったことを挙げている¹⁷。

二つの会社では、チームごとの問い合わせや派生した表に書かれた計算の規則が食い違い、数字が割れた。倉庫の表をそろえても、そこから指標を計算する規則が食い違えば、数字は割れる。データが一か所に集まると、次は、その大きな表をどう速く読むかが問題になる。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。