サブジェクト指向

データ・ウェアハウスは、データの分析に役立つように設計されています。たとえば、会社の売上データの詳細が必要な場合は、売上を中心とするデータ・ウェアハウスを作成できます。このデータ・ウェアハウスでは、「昨年、この品目を最も多く購入した顧客は誰だったか」のような質問に答えることができます。このようにデータ・ウェアハウスをサブジェクト（この場合は売上）別に定義できるため、データ・ウェアハウスの使用はサブジェクト指向となります。

統合化

統合化は、サブジェクト指向と密接な関係があります。データ・ウェアハウスでは、異なるソースのデータを、一貫したフォーマットに入れる必要があります。また、ネーミングの競合や単位の不整合などの問題を解決する必要があります。これが達成されれば、データ・ウェアハウスは統合化されたことになります。

恒常的

恒常的とは、一度データ・ウェアハウスに入ったデータは変更できないことを意味します。これは、データ・ウェアハウスの目的が、何が発生したかを分析することにあるためです。

時系列

データ・ウェアハウスでは、時系列という用語が意味する、時間経過に伴う変化に重点が置かれています。ビジネスの動向を見いだすには、アナリストは大量のデータを必要とします。これは、オンライン・トランザクション処理（OLTP）システムとは非常に対照的です。OLTPシステムでは、パフォーマンス要件のために、履歴データをアーカイブに移動させる必要があります。

OLTPとデータ・ウェアハウス環境の比較

図1-1に、OLTPシステムとデータ・ウェアハウスの主な違いを示します。

この2つのシステムにおける大きな違いの1つは、OLTP環境での一般的なデータ正規化タイプは第3正規形（3NF）ですが、データ・ウェアハウスでは、通常そうではないということです。

データ・ウェアハウスおよびOLTPシステムの要件は、大きく異なります。次に、典型的なデータ・ウェアハウスとOLTPシステムのいくつかの違いの例を示します。

• 処理負荷

  データ・ウェアハウスは、非定型の問合せに適応するように設計されています。データ・ウェアハウスの処理負荷は、事前には不明な場合があります。このため、データ・ウェアハウスは、様々な問合せ操作を適切に実行できるように最適化する必要があります。

  OLTPシステムは、事前に定義された操作のみサポートします。アプリケーションは、これらの操作のみサポートするようにチューニングまたは設計されている場合があります。

• データ修正

  データ・ウェアハウスのデータは、大量データ修正の技術を使用して、ETLプロセスによって定期的に（毎晩、毎週など）更新されます。データ・ウェアハウスのエンド・ユーザーは、データ・ウェアハウスを直接更新しません。

  OLTPシステムでは、エンド・ユーザーが機械的に、個々のデータ修正の都度、修正文を発行します。OLTPデータベースは常に最新であり、各ビジネス・トランザクションの現在の状態が反映されます。

• スキーマ設計

  データ・ウェアハウスは、非正規化または部分的に非正規化されたスキーマ（スター・スキーマなど）を使用して、問合せのパフォーマンスを最適化します。

  OLTPシステムは、完全に正規化されたスキーマを使用して、更新/挿入/削除のパフォーマンスを最適化し、データ整合性を保証します。

• 典型的な操作

  典型的なデータ・ウェアハウスの問合せでは、膨大な数の列がスキャンされる場合があります。たとえば、「先月のすべての顧客に対する合計売上の検索」などの場合です。

  典型的なOLTP操作では、少数のレコードのみがアクセスされます。たとえば、「この顧客に対する現在の注文の取出し」などの場合です。

• 履歴データ

  データ・ウェアハウスには、通常、長い年月分のデータが格納されています。これは、履歴の分析をサポートするためです。

  OLTPシステムには、通常、数週間または数か月分のデータのみが格納されています。OLTPシステムには、現行のトランザクション要件を満たすために必要な履歴データのみが格納されます。