データ ウェアハウス

コンピューティングにおいて、データ ウェアハウス( DWまたはDWH ) は、エンタープライズ データ ウェアハウス( EDW )とも呼ばれ、レポート作成やデータ分析に使用されるシステムであり、ビジネス インテリジェンスのコア コンポーネントです。^[1]データ ウェアハウスは、さまざまなソースから統合されたデータの中央リポジトリです。レポートの作成、クエリ、データからの洞察の取得が容易になるように、整理された現在のデータと履歴データを保存します。^[2]データベースとは異なり、アナリストやマネージャーが組織の意思決定に役立てることを目的としています。^[3]

ウェアハウスに保存されるデータは、運用システム(マーケティングや販売など)からアップロードされます。データは運用データ ストアを通過する場合があり、レポート作成のためにデータ ウェアハウスで使用される前に、 データの品質を確保するための追加操作のためのデータ クレンジングが必要になることがあります。

データ ウェアハウス システムを構築するための 2 つの主なアプローチは、抽出、変換、ロード(ETL) と抽出、ロード、変換(ELT) です。

データ ウェアハウスおよびデータ マートの環境には、次のものが含まれます。

• ^{データのソースシステム（多くの場合、リレーショナルデータベース[3]}などの企業の運用データベース）
• ソースシステムからデータを抽出し、変換し、データマートまたはウェアハウスにロードするためのデータ統合技術とプロセス^[3 ]
• データをウェアハウスまたはマートに保存するためのアーキテクチャ。
• さまざまなユーザー向けのツールとアプリケーション。
• メタデータ、データ品質、ガバナンスプロセス。メタデータには、データソース（データベース名、テーブル名、列名）、更新スケジュール、データ使用状況の測定が含まれます。^[3]

運用データベースは、データベースの正規化とエンティティ リレーションシップ モデルの使用により、データの整合性の維持とビジネス トランザクションの記録速度が最適化されています。運用システムの設計者は通常、Codd の 12 のデータベース正規化ルールに従って、データの整合性を確保します。完全に正規化されたデータベース設計 (つまり、Codd ルールをすべて満たす設計) では、ビジネス トランザクションの情報が数十から数百のテーブルに格納されることがよくあります。リレーショナル データベースは、これらのテーブル間の関係を効率的に管理します。各トランザクションによって影響を受けるテーブル内のデータは少量だけなので、データベースの挿入/更新パフォーマンスは非常に高速です。パフォーマンスを向上させるために、古いデータは定期的に消去されます。

データ ウェアハウスは分析アクセス パターンに最適化されており、通常、運用データベースで一般的なすべてのフィールドではなく、特定のフィールドを選択します。アクセスにおけるこれらの違いにより、運用データベース (大まかに言えば OLTP) は行指向のデータベース管理システム (DBMS) の使用からメリットを得ますが、分析データベース (大まかに言えば OLAP) は列指向の DBMSの使用からメリットを得ます。運用システムはビジネスのスナップショットを維持し、ウェアハウスは運用システムからウェアハウスにデータを定期的に移行する ETL プロセスを通じて履歴データを維持します。

オンライン分析処理(OLAP) は、トランザクション率が低く、集計を伴うクエリが複雑であるという特徴があります。応答時間は、OLAP システムの効果的なパフォーマンス測定です。OLAP アプリケーションは、データ マイニングに広く使用されています。OLAP データベースは、集計された履歴データを多次元スキーマ (通常はスター スキーマ) に格納します。OLAP システムのデータ待機時間は通常数時間ですが、データ マートの待機時間は 1 日近くになります。OLAP アプローチは、複数のソースと視点から多次元データを分析するために使用されます。OLAP の 3 つの基本操作は、ロールアップ (統合)、ドリルダウン、およびスライス アンド ダイシングです。

オンライントランザクション処理（OLTP）は、多数の短いオンライントランザクション（INSERT、UPDATE、DELETE）を特徴とします。OLTPシステムは、高速クエリ処理とマルチアクセス環境でのデータ整合性の維持を重視しています。OLTPシステムの場合、パフォーマンスは1秒あたりのトランザクション数です。OLTPデータベースには、詳細で最新のデータが含まれています。トランザクションデータベースを格納するために使用されるスキーマは、エンティティモデル（通常は3NF）です。^[4]このシステムでは、正規化がデータモデリング技術の標準となっています。

予測分析は、複雑な数学モデルを使用してデータ内の隠れたパターンを見つけて定量化し、将来の結果を予測することです。対照的に、OLAP は履歴データの分析に重点を置き、反応的です。予測システムは、顧客関係管理(CRM) にも使用されます。

データマートは、単一の主題または機能領域に焦点を合わせたシンプルなデータウェアハウスです。したがって、販売、財務、マーケティングなどの限られた数のソースからデータを抽出します。データマートは、多くの場合、組織内の単一の部門によって構築および管理されます。ソースは、内部運用システム、中央データウェアハウス、または外部データである可能性があります。^[5]ウェアハウスと同様に、保存されたデータは通常、正規化されていません。

データ マートの種類には、依存型、独立型、ハイブリッド型データ マートがあります。^{[説明が必要]}

典型的な抽出、変換、ロード(ETL) ベースのデータ ウェアハウスは、ステージング レイヤー、データ統合 レイヤー、およびアクセス レイヤーを使用して主要な機能を収容します。ステージング レイヤーまたはステージング データベースには、さまざまなソース データ システムから抽出された生データが格納されます。統合レイヤーは、ステージング レイヤーからのデータを変換してさまざまなデータ セットを統合し、多くの場合、この変換されたデータを運用データストア(ODS) データベースに格納します。統合されたデータは、次に、データ ウェアハウス データベースと呼ばれる別のデータベースに移動され、そこでデータは階層グループ (ディメンションと呼ばれることが多い) とファクトおよび集計ファクトに整理されます。ファクトとディメンションの組み合わせは、スター スキーマと呼ばれることもあります。アクセス レイヤーは、ユーザーがデータを取得するのに役立ちます。^[6]

データの主なソースは、クレンジング、変換、カタログ化され、データマイニング、オンライン分析処理、市場調査、意思決定サポートのために、管理者やその他のビジネス専門家が使用できるようにします。^[7]ただし、データを取得および分析する手段、データを抽出、変換、ロードする手段、およびデータディクショナリを管理する手段も、データウェアハウスシステムの重要なコンポーネントと見なされています。データウェアハウスに関する多くの参照では、このより広いコンテキストが使用されています。したがって、データウェアハウスの拡張された定義には、ビジネスインテリジェンスツール、データを抽出、変換、リポジトリにロードするツール、メタデータを管理および取得するツールが含まれます。

ELTベースのデータ ウェアハウスでは、データ変換用の個別のETLツールが不要になります。代わりに、データ ウェアハウス自体の中にステージング領域が保持されます。このアプローチでは、データは異種のソース システムから抽出され、変換が行われる前にデータ ウェアハウスに直接ロードされます。その後、必要な変換はすべてデータ ウェアハウス自体の中で処理されます。最後に、操作されたデータは同じデータ ウェアハウス内のターゲット テーブルにロードされます。

データ ウェアハウスは、ソース トランザクション システムからの情報のコピーを保持します。このアーキテクチャの複雑さにより、次のことが可能になります。

• 複数のソースからのデータを単一のデータベースとデータ モデルに統合します。単一のデータベースにデータがさらに集約されるため、単一のクエリ エンジンを使用して運用データ ストアにデータを表示できます。
• トランザクション処理データベースで長時間実行される分析クエリによって発生する、トランザクション処理システムにおける分離レベルのロック競合の問題を軽減します。
• ソーストランザクションシステムがデータ履歴を保持していなくても、データ履歴を保持します。
• 複数のソース システムからのデータを統合し、企業全体の一元的なビューを実現します。この利点は常に価値がありますが、特に組織が合併によって拡大した場合には価値が高まります。
• 一貫したコードと説明を提供し、不良データにフラグを付けたり修正したりすることで、データの品質を向上させます。
• 組織の情報を一貫して提示します。
• データ ソースに関係なく、すべての対象データに対して単一の共通データ モデルを提供します。
• ビジネス ユーザーにとって意味のあるようにデータを再構築します。
• 運用システムに影響を与えることなく、複雑な分析クエリでも優れたクエリ パフォーマンスが得られるようにデータを再構築します。
• 運用ビジネス アプリケーション、特に顧客関係管理(CRM) システムに価値を追加します。
• 意思決定支援クエリの作成を容易にします。
• 繰り返しデータを整理し、明確化します。

データ ウェアハウスの概念は、IBM の研究者 Barry Devlin と Paul Murphy が「ビジネス データ ウェアハウス」を開発した 1980 年代後半^[8]にまで遡ります。本質的に、データ ウェアハウスの概念は、運用システムから意思決定支援環境へのデータの流れのアーキテクチャ モデルを提供することを目的としていました。この概念は、この流れに関連するさまざまな問題、主にそれに関連する高コストに対処しようとしました。データ ウェアハウス アーキテクチャがない場合は、複数の意思決定支援環境をサポートするために膨大な量の冗長性が必要でした。大企業では、複数の意思決定支援環境が独立して動作するのが一般的でした。各環境は異なるユーザーにサービスを提供していましたが、多くの場合、同じ保存データが必要でした。さまざまなソース (通常は長期にわたる既存の運用システム (通常、レガシー システムと呼ばれる)) からデータを収集、クリーニング、統合するプロセスは、通常、各環境で部分的に複製されていました。さらに、新しい意思決定支援要件が出現するたびに、運用システムが頻繁に再検討されました。多くの場合、新しい要件では、ユーザーがすぐにアクセスできるように調整された 「データ マート」から新しいデータを収集、クリーニング、統合する必要がありました。

さらに、James M. Kerr による The IRM Imperative (Wiley & Sons、1991) の出版により、組織のデータ リソースを管理してドル価値に換算し、その価値を資産として貸借対照表に報告するというアイデアが普及しました。この本で Kerr は、トランザクション駆動型システムから得たデータをサブジェクト領域データベースに取り込んで、要約データをさらに活用して経営幹部の意思決定に役立てることができるストレージ領域を作成する方法について説明しました。この概念は、あらゆる企業内でデータ ウェアハウスを実用的な方法で開発および管理する方法をさらに考えるきっかけとなりました。

データ ウェアハウスの初期における主な開発:

• 1960年代 -ゼネラルミルズとダートマス大学は共同研究プロジェクトで「ディメンション」と「ファクト」という用語を開発しました。^[9]
• 1970年代 - ACNielsenとIRIが小売販売向けのディメンションデータマートを提供。^[9]
• 1970年代 -ビル・インモンがデータウェアハウスという用語の定義と議論を始める。^{[10] [11] [12]}
• 1975 年 - Sperry Univac は、世界初の4GLを含むデータベース管理およびレポート システムであるMAPPER (MAintain, Prepare, and Produce Executive Reports)を発表しました。これは、情報センター (現代のデータ ウェアハウス テクノロジーの先駆け) を構築するために設計された最初のプラットフォームです。
• 1983年 -テラデータは意思決定支援用に特別に設計されたDBC/1012データベースコンピュータを発表しました。^[13]
• 1984年 - David LiddleとDon Massaroによって設立されたMetaphor Computer Systemsが、ビジネスユーザーがデータベース管理および分析システムを作成するためのハードウェア/ソフトウェア パッケージとGUIをリリースしました。
• 1988年 - バリー・デブリンとポール・マーフィーが「ビジネスと情報システムのアーキテクチャ」という論文を発表し、「ビジネスデータウェアハウス」という用語を導入した。^[14]
• 1990 年 - Ralph Kimballによって設立された Red Brick Systems が、データ ウェアハウス専用のデータベース管理システムである Red Brick Warehouse を発表しました。
• 1991 年 - James M. Kerr が IRM Imperative を執筆し、データ リソースを貸借対照表上の資産として報告できることを示唆し、データ ウェアハウスの構築に対する商業的関心が高まりました。
• 1991年 - Bill Inmonによって設立された Prism Solutions が、データ ウェアハウス開発用ソフトウェアである Prism Warehouse Manager を発表しました。
• 1992年 -ビル・インモンが『データウェアハウスの構築』を出版。^[15]
• 1995 年 - データ ウェアハウスを推進する営利団体である Data Warehousing Institute が設立されました。
• 1996年 -ラルフ・キンボールが『データウェアハウスツールキット』を出版。^[16]
• 1998年 - パトリック・ラガーが主な推進者の一人となり、フォーカルモデリングがアンサンブル（ハイブリッド）データウェアハウスモデリングアプローチとして実装されました。^{[17] [18]}
• 2000 年 - Dan Linstedt が、ソースデータ モデルの追跡、監査、変更に対する回復力を重視し、複数の運用システムから入力されるデータの長期履歴ストレージを提供するために 1990 年に Inmon と Kimball の代替として考案されたデータ ボールト モデリングをパブリック ドメインでリリースしました。
• 2008 年 - Bill Inmonが Derek Strauss および Genia Neushloss とともに「DW 2.0: 次世代のデータ ウェアハウスのアーキテクチャ」を出版し、データ ウェアハウスに対するトップダウン アプローチを説明し、「データ ウェアハウス 2.0」という用語を生み出しました。
• 2008年 -アンカーモデリングは国際概念モデリング会議で発表された論文で形式化され、最優秀論文賞を受賞した^[19]
• 2012 年 - Bill Inmon が「テキストの曖昧さ解消」として知られる技術を開発し、公開しました。テキストの曖昧さ解消は、生のテキストにコンテキストを適用し、生のテキストとコンテキストを標準データベース形式に再フォーマットします。生のテキストがテキストの曖昧さ解消を通過すると、標準のビジネス インテリジェンス技術によって簡単かつ効率的にアクセスおよび分析できます。テキストの曖昧さ解消は、テキスト ETL の実行によって実現されます。テキストの曖昧さ解消は、ドキュメント、Hadoop、電子メールなど、生のテキストが見つかる場所であればどこでも役立ちます。
• 2013年 - データボールト2.0がリリースされ、^{[20] [21]}モデリング方法に若干の変更が加えられ、アジャイルやCMMIの原則を含む他の方法論、アーキテクチャ、実装のベストプラクティスとの統合も行われました。

ファクトとは、管理されているシステム内の値または測定値です。

生の事実は、報告エンティティによって報告される事実です。たとえば、携帯電話システムで、基地局(BTS) がトラフィック チャネル割り当ての要求を 1,000 件受信し、820 件を割り当て、残りを拒否した場合、管理システムに次の 3 つの事実を報告できます。

• tch_req_total = 1000
• tch_req_success = 820
• tch_req_fail = 180

生の事実は、さまざまな次元でより高いレベルに集約され、サービスやビジネスに関連性の高い情報を抽出します。これらは集約された事実または要約と呼ばれます。

たとえば、ある都市に 3 つの BTS がある場合、上記の事実はネットワーク ディメンションの都市レベルに集約できます。例:

• tch_req_success_city = tch_req_success_bts1 + tch_req_success_bts2 + tch_req_success_bts3
• avg_tch_req_success_city = (tch_req_success_bts1 + tch_req_success_bts2 + tch_req_success_bts3) / 3

ウェアハウスにデータを格納するための最も重要な2つのアプローチは、次元型と正規化型です。次元型アプローチでは、ラルフ・キンボールが提案したスタースキーマを使用します。正規化アプローチは、第3正規形（3NF）とも呼ばれ、ビル・インモンが提案したエンティティリレーショナル正規化モデルです。^[22]

ディメンション アプローチでは、トランザクション データは、通常は数値トランザクション データである「ファクト」と、ファクトにコンテキストを与える参照情報である「ディメンション」に分割されます。たとえば、販売トランザクションは、注文された製品の数や製品の合計支払額などのファクトと、注文日、顧客名、製品番号、注文の発送先と請求先の場所、注文の受け取りを担当する営業担当者などのディメンションに分割できます。

このディメンションアプローチにより、データが理解しやすくなり、データ検索が高速化されます。^[16]ディメンション構造は、測定/事実とコンテキスト/ディメンションに分割されているため、ビジネスユーザーにとって理解しやすいものです。事実は組織のビジネスプロセスと運用システムに関連し、ディメンションはそれらに関するコンテキストです (Kimball、Ralph 2008)。もう 1 つの利点は、ディメンションモデルではリレーショナルデータベースが毎回必要にならないことです。したがって、このタイプのモデリング手法は、データウェアハウスでのエンドユーザークエリに非常に役立ちます。

事実と次元のモデルはデータキューブとして理解することもできます。^[23]ここで、次元は多次元キューブ内のカテゴリ座標であり、事実は座標に対応する値です。

次元アプローチの主な欠点は次のとおりです。

1. 異なる運用システムからのデータをデータウェアハウスにロードし、事実とディメンションの整合性を維持するのは複雑です。
2. 組織がビジネスのやり方を変えた場合、倉庫の構造を変更するのは困難です。

正規化アプローチでは、ウェアハウス内のデータは、ある程度、データベース正規化ルールに従って保存されます。正規化されたリレーショナル データベース テーブルは、サブジェクト領域(顧客、製品、財務など) ごとにグループ化されます。大企業で使用すると、結合の網によってリンクされた数十のテーブルが作成されます (Kimball、Ralph 2008)。

このアプローチの主な利点は、データベースに情報を簡単に追加できることです。欠点としては、テーブル数が多いため、データ ソースとデータ ウェアハウスのデータ構造を正確に理解していないと、さまざまなソースのデータを結合して意味のある情報にしたり、情報にアクセスしたりすることが難しいことが挙げられます。

正規化モデルとディメンション モデルはどちらも、結合されたリレーショナル テーブルを含んでいるため、エンティティ リレーションシップ図で表現できます。両者の違いは、正規化の度合いです。これらのアプローチは相互に排他的ではなく、他のアプローチもあります。ディメンション アプローチでは、ある程度データを正規化できます (Kimball、Ralph 2008)。

ロバート・ヒラードは、Information-Driven Business ^[24]で、ビジネス問題の情報ニーズに基づいて2つのアプローチを比較しています。彼は、正規化モデルは、次元の同等のものよりもはるかに多くの情報を保持できるが（両方のモデルで同じフィールドが使用されている場合でも）、使いやすさが犠牲になっていると結論付けています。この手法では、情報量を情報エントロピーで測定し、使いやすさをスモールワールドデータ変換尺度で測定します。^[25]

ボトムアップアプローチでは、まずデータマートを作成し、特定のビジネスプロセスにレポート機能と分析機能を提供します。これらのデータマートを統合して、包括的なデータウェアハウスを作成できます。データウェアハウスバスアーキテクチャは、主に「バス」の実装であり、適合ディメンションと適合ファクトのコレクションです。適合ディメンションとファクトは、2つ以上のデータマートのファクト間で（特定の方法で）共有されるディメンションです。^[26]

トップダウンアプローチは、標準化されたエンタープライズデータモデルを使用して設計されます。「アトミック」データ、つまり最も詳細なレベルのデータは、データウェアハウスに保存されます。特定のビジネスプロセスまたは特定の部門に必要なデータを含むディメンションデータマートは、データウェアハウスから作成されます。^[27]

データ ウェアハウスは、多くの場合、ハブ アンド スポーク アーキテクチャに似ています。ウェアハウスにデータを提供するレガシー システムには、顧客関係管理やエンタープライズ リソース プランニングが含まれることが多く、大量のデータが生成されます。これらのさまざまなデータ モデルを統合し、抽出、変換、ロードプロセスを容易にするために、データ ウェアハウスでは、運用データ ストアが使用されることが多く、そこからの情報が実際のデータ ウェアハウスに解析されます。データの冗長性を減らすために、大規模なシステムでは、データが正規化された方法で保存されることがよくあります。その後、特定のレポートのデータ マートをデータ ウェアハウス上に構築できます。

ハイブリッド (アンサンブルとも呼ばれる) データ ウェアハウス データベースは、データの冗長性を排除するために第 3 正規形で保持されます。ただし、通常のリレーショナル データベースは、ディメンション モデリングが普及しているビジネス インテリジェンス レポートには適していません。小規模なデータ マートは、統合されたウェアハウスからデータを購入し、必要なファクト テーブルとディメンションにフィルター処理された特定のデータを使用できます。データ ウェアハウスは、データ マートが読み取ることができる単一の情報ソースを提供し、幅広いビジネス情報を提供します。ハイブリッド アーキテクチャにより、データ ウェアハウスを、運用情報 (静的ではない) を格納できるマスター データ管理リポジトリに置き換えることができます。

データボールト モデリングコンポーネントは、ハブ アンド スポーク アーキテクチャに従います。このモデリング スタイルは、第 3 正規形とスター スキーマの両方のベスト プラクティスから構成されるハイブリッド設計です。データ ボールト モデルは、真の第 3 正規形ではなく、そのルールの一部に違反していますが、ボトムアップ設計のトップダウン アーキテクチャです。データ ボールト モデルは、厳密にデータ ウェアハウスとして設計されています。エンド ユーザーがアクセスできるようには設計されていません。エンド ユーザーがアクセスできるように構築する場合は、ビジネス目的でデータ マートまたはスター スキーマ ベースのリリース領域を使用する必要があります。

データ ウェアハウス内のデータを定義する基本機能には、主題指向、データ統合、時間変化、不揮発性データ、およびデータ粒度が含まれます。

運用システムとは異なり、データ ウェアハウスのデータは企業の主題を中心に展開されます。主題指向はデータベースの正規化ではありません。主題指向は意思決定に非常に役立ちます。必要なオブジェクトを収集することを主題指向と呼びます。

データ ウェアハウス内のデータは統合されています。データは複数の運用システムから取得されるため、すべての不整合を取り除く必要があります。不整合には、命名規則、変数の測定、エンコード構造、データの物理的属性などが含まれます。

運用システムは日々の業務をサポートするため、現在の価値を反映しますが、データ ウェアハウスのデータは長期間 (最大 10 年) のデータを表し、主に履歴データが格納されます。主にデータ マイニングと予測を目的としています。(たとえば、ユーザーが特定の顧客の購入パターンを検索する場合、ユーザーは現在の購入と過去の購入に関するデータを調べる必要があります。) ^[28]

データウェアハウス内のデータは読み取り専用であり、更新、作成、削除することはできません（規制または法律上の義務がない限り）。^[29]

データ ウェアハウス プロセスでは、データはさまざまな抽象レベルでデータ マートに集約されます。ユーザーは、まず、ある地域全体での製品の総販売数を調べます。次に、その地域の州を調べます。最後に、特定の州にある個々の店舗を調べます。したがって、通常、分析は上位レベルから開始され、詳細の下位レベルにドリルダウンされます。^[28]

データ仮想化では、使用されるデータは元の場所に残り、リアルタイムアクセスが確立されるため、仮想データウェアハウスを作成して複数のソースにわたる分析が可能になります。これにより、さまざまなプラットフォームからのデータを組み合わせる際の互換性の問題などの技術的な問題を解決したり、欠陥のあるデータによって引き起こされるエラーのリスクを軽減したり、最新のデータが使用されることを保証したりできます。さらに、個人情報を含む新しいデータベースの作成を回避することで、プライバシー規制に準拠しやすくなります。ただし、データ仮想化では、データのローカルコピーがないため、必要なすべてのデータソースへの接続が機能している必要があり、これがこのアプローチの主な欠点の1つです。^[30]

組織が指定するデータ ウェアハウスを構築/編成するために使用されるさまざまな方法は多数あります。使用されるハードウェア、作成されるソフトウェア、およびデータ ウェアハウスの正しい機能に特に必要なデータ リソースは、データ ウェアハウス アーキテクチャの主要なコンポーネントです。すべてのデータ ウェアハウスには、組織の要件が修正され、微調整される複数のフェーズがあります。^[31]

これらの用語は、データ ウェアハウスの高度さのレベルを表します。

オフライン運用データウェアハウス

この進化段階にあるデータ ウェアハウスは、運用システムから定期的な時間サイクル (通常は毎日、毎週、または毎月) で更新され、データは統合されたレポート指向のデータベースに保存されます。

オフラインデータウェアハウス

この段階のデータ ウェアハウスは、運用システムのデータから定期的に更新され、データ ウェアハウスのデータはレポート作成を容易にするために設計されたデータ構造に保存されます。

オンタイムデータウェアハウス

オンライン統合データウェアハウスは、ソースデータで実行されるトランザクションごとにウェアハウス内のデータが更新されるリアルタイムのデータウェアハウスステージを表します。

統合データウェアハウス

これらのデータウェアハウスはさまざまなビジネス分野からデータを収集し、ユーザーが他のシステムから必要な情報を検索できるようにします。^[32]

無料辞書の Wiktionary でデータ ウェアハウスを調べてください。

• ビジネス インテリジェンス ソフトウェアの一覧
• データレイク – 自然な/生の形式で保存されたデータのシステムまたはリポジトリ
• データメッシュ – データ管理のための分散アーキテクチャフレームワーク

• ダベンポート、トーマス H.、ハリス、ジーン G.分析による競争: 勝利の新しい科学( 2007) ハーバード ビジネス スクール プレス。ISBN 978-1-4221-0332-6 
• Ganczarski, Joe.データ ウェアハウスの実装: 重要な実装要因の調査(2009) VDM Verlag ISBN 3-639-18589-7 ISBN 978-3-639-18589-8   
• キムボール、ラルフ、ロス、マージー。データ ウェアハウス ツールキット第 3 版 (2013) Wiley、ISBN 978-1-118-53080-1 
• リンステッド、グラツィアーノ、ハルトグレン。データ ボールト モデリングのビジネス第 2 版 (2010) ダン リンステッド、ISBN 978-1-4357-1914-9 
• ウィリアム・インモン著『データウェアハウスの構築』（2005年）ジョン・ワイリー・アンド・サンズ、ISBN 978-81-265-0645-3