日本語PDF
  1. データ・ウェアハウス・ガイド
  2. データ・ウェアハウス: 基本
  3. データ・ウェアハウスの論理設計

2 データ・ウェアハウスの論理設計

この章では、データ・ウェアハウス環境の論理設計の作成方法について説明します。内容は次のとおりです。

2.1 データ・ウェアハウスの論理設計と物理設計の比較

組織でのエンタープライズ･データ・ウェアハウス構築がすでに決定されているとします。そして、ビジネス要件の定義、ビジネスの目的の適用範囲の打合せ、および概念的な設計も完了しているとします。そこで、その要件をシステムに移行できるように変換する必要があります。そのためには、データ・ウェアハウスの論理設計と物理設計を行います。定義する内容は、次のとおりです。

  • 具体的なデータ内容

  • データ・グループ内およびデータ・グループ間の関係

  • データ・ウェアハウスをサポートするシステム環境

  • 必要なデータ変換

  • データのリフレッシュ頻度

論理設計は、物理設計に比べて概念的で抽象的です。論理設計では、オブジェクト間の論理的な関係を検討します。物理設計では、オブジェクトの格納と取出しの他、転送処理およびバックアップ/リカバリの観点から、最も効果的な方法を検討します。

設計では、エンド・ユーザーのニーズを優先させる必要があります。エンド・ユーザーは、通常、個々のトランザクションではなく、分析を行って集計されたデータを見ます。ただし、実際にデータを見るまで、何が必要であるかがエンド・ユーザーにはわからない場合があります。適切に計画された設計であれば、ユーザーのニーズの変化や発展に応じて、拡張および変更を行うことができます。

まず、論理設計から始めると、情報についての要件に集中でき、実装の詳細は後で検討できます。

2.2 論理設計の作成

論理設計とは、概念的で抽象的な設計です。ここでは、物理的な実装の詳細は説明しません。必要な情報の種類の定義方法のみを扱います。

組織の論理的な情報要件のモデリングに使用できるテクニックの1つが、E-Rモデリングです。E-Rモデリングでは、重要事項(エンティティ)、重要事項のプロパティ(属性)および相互の関連(リレーションシップ)を特定します。

物理設計プロセスでは、データを、エンティティおよび属性と呼ばれる、一連の論理的な関係に配置します。エンティティは、情報の大きいまとまりを表します。エンティティは、リレーショナル・データベースの表にマップされます。属性はエンティティのコンポーネントで、エンティティの一意性を定義します。属性は、リレーショナル・データベースの列にマップされます。

データの一貫性を確実にするには、一意識別子を使用する必要があります。一意識別子は、同じ項目が異なる場所に表示される場合に、両者を区別できるように表に追加する識別子です。これは通常、物理設計における主キーです。

E-Rモデリングは、完全に論理的なものであり、OLTPとデータ･ウェアハウス･システムの両方に適用されます。データ･ウェアハウス環境で一般的に使用されている、様々な物理スキーマ･モデリング技法、つまり、エンタープライズ･データ･ウェアハウス環境での正規化(3NF)スキーマ、データ･マートでのスターまたはスノーフレーク･スキーマ、またはこれら古典的モデリング技法の両方のコンポーネントを使用した、ハイブリッド･スキーマにも適用可能です。

関連項目:

2.2.1 スキーマとは

スキーマとは、表、ビュー、索引およびシノニムを含むデータベース・オブジェクトのコレクションです。データ・ウェアハウス用に設計されたスキーマ・モデルには、様々な方法でスキーマ・オブジェクトを配置できます。ほとんどのデータ・ウェアハウスでは、ディメンショナル・モデルが使用されます。

データ・ウェアハウス・スキーマの設計には、ソース・データのモデルとユーザー要件を使用できます。会社のエンタープライズ・データ・モデルからソース・データを取得し、これを基にデータ・ウェアハウス用の論理データ・モデルをリバース・エンジニアすることが可能な場合があります。論理データ・ウェアハウス・モデルの物理的な実装には、コンピュータのサイズ、ユーザー数、記憶域の容量、ネットワークの種類、ソフトウェアなどのシステム・パラメータに応じて、多少の変更が必要な場合があります。スキーマの設計の重要な部分は、第3正規形、スターまたはスノーフレーク・スキーマを使用するかどうかということですが、これらについては、後で詳しく説明します。

2.3 第3正規形のスキーマについて

第3正規形の設計では、データの冗長性を最小化し、データの挿入、更新および削除において非一貫性を回避することが求められます。3NFの設計は、オンライン・トランザクション処理(OLTP)システムで長く使用されてきました。OLTPシステムでは、データの挿入、更新および削除時のパフォーマンスおよび精度を最大限にする必要があります。トランザクションは、可能なかぎり早急に処理する必要があります。そうでなければ、業務でイベントのフローを処理できなくなり、売上の喪失または損害を被る可能性があります。そのため3NFの設計により、挿入、更新および削除を減速させる可能性のある、冗長なデータ操作を回避し、表のロックを最小限にします。3NFの設計は、特定のアプリケーションのニーズによるデータの抽出にも有効です。環境に新しいタイプのデータが追加された場合、データ・モデルを比較的容易に拡張し、既存アプリケーションへの影響を最小限に抑えることができます。同様に、データ・ウェアハウスで実行する、まったく新しいタイプの分析がある場合、適切に設計された3NFスキーマであればデータ構造を再設計することなく処理することが可能です。3NFの設計には非常に柔軟性がありますが、代償も伴います。3NFのデータベースは非常に多くの表を使用するため、多数の結合を使用した複雑な問合せが必要です。3NFで構築された、フル・スケールのエンタープライズ・モデルでは、一般的に1,000を超える表がスキーマに記載されています。データ・ウェアハウスでは多くの場合、多数の表の多数の行へのアクセスを必要としますが、含まれる問合せの種類の数に比例して、この設計が理解を妨げるようになり、パフォーマンスが低下します。問合せの作成者が人間であれ、ビジネス・インテリジェンス・ツールおよびアプリケーションであれ、使用可能な表が非常に多数の場合は、データの特定の部分に必要な表を選択および結合することは、複雑な作業になります。問合せジェネレータによって表が即座に選択される場合でも、3NFスキーマは多くの場合、単一の問合せで多数の表を必要とします。問合せに存在する表が多くなるほど、潜在的なデータ・アクセス・パスが増えることになり、データベース問合せオプティマイザの負荷が増大します。最終的には、問合せパフォーマンスが低下します。

3NFシステムにおける問合せパフォーマンス低下の問題は、レポートおよび分析の作成に使用される、コアの問合せに必ずしも限定されたものではありません。内容を理解するためユーザーがデータのサブセットを参照しているような、より単純なタスクでも発生する可能性があります。同様に、3NFスキーマの複雑さは、問合せおよびレポートの制約に使用される、データの選択リストの作成に影響する可能性があります。これらは比較的軽微な問題に見えますが、このようなプロセスでの応答時間が速いことは、ユーザーの満足度に大きく影響します。

図2-1に、3NFスキーマのごく一部を示します。冗長性の高いデータの格納を避けるため、注文情報が注文と注文品目に分割されていることに注意してください。表間の関係上のカラスの足跡マークは、エンティティ間の1対多の関係を示しています。このように、1つの注文には複数の注文品目があり、1人の顧客には多くの注文があり、さらには1つの製品が多くの注文品目の中にあります。この図では非常に簡単な例を示していますが、データの冗長性を最小化することが、スキーマに多くの表ができることにつながることがわかります。

図2-1 第3正規形スキーマの断片

図2-1の説明が続きます
「図2-1 第3正規形スキーマの断片」の説明

関連項目:

3NFスキーマの設計の概念

2.3.1 正規化について

正規化とは、各ファクトを1箇所のみに保持し、データの冗長性や挿入、更新および削除の非一貫性を回避するという、高いレベルの目的を持ったデータ設計プロセスです。正規化には複数のレベルがありますが、この項ではそれらの内の最初の3つを説明します。第3正規形(3NF)という用語がいかに基本的なものであるかを考えれば、3NFがどのように実現されるかを見なければ意味がありません。

売上を追跡する場合を考えてみます。追跡の中心になるエンティティは受注ですが、各受注には品名、価格、数量など、各購買品目についての詳細(明細項目と呼ぶ)が含まれます。受注には顧客の氏名や住所なども含まれます。様々な明細項目のある受注もあれば、1つしかない場合もあります。

第1正規形(1NF)では、データ・グループの繰り返しや重複行は存在しません。行と列の各交差部分(フィールド)には、1つの値のみが格納されており、同一のファクトを格納する列のグループは存在しません。重複行を避けるため、主キーが存在します。第1正規形における受注では、表の1つのフィールドには各受注の複数の明細項目は表示されません。また、明細項目を示す複数の列は存在しません。

次の第2正規形(2NF)は、設計は第1正規形のものですが、各非キー列は完全な主キーに依存しています。そこで、明細項目を受注明細項目表に抜き出し、各行が1つの注文の1明細項目を表すようにします。明細項目表を見ると、売上項目の品名は明細項目表の主キーに依存していないことがわかります。つまり、売上項目は独自のエンティティです。したがって、売上項目を品名を示している独自の表に移動します。各項目に対する請求額は、注文により異なる(たとえば、値引によって)ため、明細項目表に残します。この受注表の例では、顧客の氏名および住所は受注表の主キーに依存していません。つまり、顧客は独自のエンティティです。したがって、顧客の氏名および住所列は独自の顧客情報表に移動します。

次の第3正規形の目的は、非キー属性に依存しないことを確認することです。つまり、行のサブジェクト(主キー)に直接関連付けられていない列を取得して、それらを独自の表に配置することが目的になります。したがって、顧客の名前や顧客の市などの顧客に関する詳細を別個の表に配置してから、customer外部キーをorders表に追加する必要があります。

2NF表と3NF表の相違の別の例として、トーナメント、年、勝者および勝者の誕生日の列を含む、テニス・トーナメントの勝者の表が挙げられます。この場合、勝者の誕生日は、不整合を起こしやすくなります。なぜなら、同じ人が、異なるレコード内で異なる誕生日で表示される可能性があるためです。この潜在的な問題を回避する方法は、表を、トーナメントの勝者用のものと、選手の誕生日用のものに分けることです。

2.3.2 3NFスキーマの設計の概念

次の項では、3NFスキーマの手法を使用したデータ･ウェアハウス環境向けのモデリングの際の、基本概念のいくつかについて説明します。ここでは3NFモデリング(またはさらに高いレベルの正規化)の論理的根拠についての説明ではなく、データ･ウェアハウスに関連する主要コンポーネントに注目することを意図しています。

データ・ウェアハウスに関連する主要な3NFスキーマ設計の概念の一部を次に示します。

2.3.2.1 主キーの識別

主キーとは、表の中の特定のレコードを一意に識別する属性です。主キーは、単一または複数の列により識別することができます。通常は、可能なかぎり少ない列(理想的には1つか2つ)によって一意の識別を実現することと、更新の可能性の最も低い列または一括で変更されることのない列のいずれかの使用が望ましいとされています。もしデータ･モデルが、その属性を使用した単純な一意の識別につながらない場合は、1つのレコードを一意に識別するために必要な属性が多すぎるか、データが変更されやすいためなので、サロゲート･キーの使用を強くお薦めします。

問合せは多くの表の結合を持つ傾向があり、結合による行の重複を避けるために、レコードを一意に識別するために必要なすべての列が結合条件として必要であるため、3NFスキーマは特に、完全かつ単純な一意の識別に依存します。

2.3.2.2 外部キーの関係および参照整合性制約

データ･ウェアハウス環境における3NFスキーマは、そのOLTPソース･システムのデータ・モデルに通常、類似していますが、そこではデータ･エンティティ間の論理的整合性は、親子関係としても知られる主キーと外部キーの関係によって表現および規定されています。外部キーは、リレーショナル･システムでの1対多の関係を解決し、論理的整合性を保証します。たとえば、注文ヘッダーのない注文明細項目や、存在しない部門で働く従業員を持つことはできません。

そうした参照がOLTPシステムでは常に強制されていますが、データ･ウェアハウス・システムでは通常、これらを強制されない条件である宣言として実装し、ETLプロセスに依存してデータの整合性を保証します。可能な場合は、外部キーと参照整合性制約を強制されない条件として常に定義するようにします。これにより、問合せの最適化およびカーディナリティの見積りを向上させることができます。

2.3.2.3 非正規化

完全な非正規化モデリングでは、論理的なエンティティ(顧客、製品、注文など)が多くの物理表に分解される傾向があり、既知の単純な情報の取得でさえ、多くの表の結合が必要になります。ただし、これは問合せ処理の観点からは問題ではなく、データベース(情報が結合され、常に同時に使用されるため)だけでなく、アプリケーション開発者(コードを記述する)にも不必要な負荷がいくぶん掛かるというだけです。3NFのデータ･ウェアハウス･モデルの非正規化は、論理的な形式ではビューで、物理的な形式では表の非正規化が多少行われるという、ある程度のレベルにとどまることも珍しくありません。

物理的な非正規化には、サブジェクト･ニュートラルな形状を保持するよう注意が必要であり、そのため3NFスキーマの物理的実装には柔軟性があります。

2.4 スター・スキーマについて

スター･スキーマは、埋込み論理データ･マートまたは埋込み物理データ･マートを使用したデータ･ウェアハウス･システムでは、一般的に使用されています。スター・スキーマは、データ・モデルを定義する、ディメンショナル・モデリング法の別名です。ほとんどのディメンショナル・モデリングについての説明は、この分野の先駆的コンサルタントかつライターであるRalph Kimball氏の文献から引用した用語を使用しています。ディメンショナル・モデリングでは複数のスター・スキーマが作成され、その各々が売上追跡や出荷などのビジネス・プロセスに基づいています。各スター・スキーマは1つのデータ・マートと見なすことができ、わずか20個程度のデータ・マートがあれば、1企業のビジネス・インテリジェンスのニーズに対応できます。3NF設計と比較すると、ディメンショナル・モデリングで使用される表の数は微々たるものです。多くのスター・スキーマで保持される表は、1ダース足らずです。スター・スキーマは適合済ディメンションと適合済ファクトを介して一体化されます。したがって、ユーザーは最小限の労力で複数のスター・スキーマからデータを取得できます。

スター・スキーマの目的は、構造の簡素化とデータ取得のパフォーマンス向上です。近年ではほとんどの問合せがレポート・ツールやアプリケーションによって生成されるため、ツールやアプリケーションでの問合せの生成を簡便で信頼性の高いものにすることが不可欠です。実際、多くのビジネス・インテリジェンス・ツールおよびアプリケーションは、スター・スキーマの表現が使用可能なことを見込んで設計されています。

スター・スキーマの説明では、3NFに比べて物理データベースの説明の要約は多くありません。これはディメンショナル・モデリングが実際にビジネス・インテリジェンス・ユーザーのニーズに対して重点を置いているためです。

ディメンショナル・モデリングの形式と、データの冗長性および更新、挿入、削除の非一貫性の危険を最小化する3NFの方法の違いに注意してください。スター・スキーマでは、ユーザーの理解しやすさとデータ取得のよりよいパフォーマンスを意図して、ディメンション表でのデータの冗長性(非正規化)を許容します。スター・スキーマへの一般的な批判は、3NF設計と比較して分析の柔軟性が限定されるというものです。しかし、適切に設計されたディメンショナル・モデルは、新しいタイプの分析が可能になるよう拡張でき、スター・スキーマは最大規模の企業で長年正常に動作しています。

前述のとおり、データ・ウェアハウスの最新の手法は、スター・スキーマと3NFを対抗させるものではありません。むしろ、3NFの基盤レイヤー(3NFのエンタープライズ･データ･ウェアハウス)は基盤データとして、スター・スキーマはアクセスの中核部分およびパフォーマンス最適化レイヤーとしてそれぞれ機能し、2つの技術がともに使用されています。

関連項目:

2.4.1 スター・スキーマのファクトおよびディメンションについて

スター・スキーマでは、データをファクトとディメンションに分割します。ファクトは売上など、なんらかのイベントの実測値であり、通常は数字です。ディメンションは日付、場所、製品などのファクトの識別に使用するカテゴリです。

スター・スキーマという名前は、スキーマのダイアグラムでは通常、中心のファクト表に付いた線が、ディメンション表に結合しているため、図の印象が星に似ていることに由来します。図2-2は、ファクト表である売上と、ディメンション表である製品、時間、顧客およびチャネルの簡単な例です。

図2-2 スター・スキーマ

図2-2の説明が続きます
「図2-2 スター・スキーマ」の説明

関連項目:

2.4.1.1 データ・ウェアハウスのファクト表について

ファクト表は実測値を保持しています。ファクト表は、多数の行を保持しますが、列は通常多くありません。大企業のファクト表では数十億行を保持することがあります。多くのスター・スキーマでは、ファクト表は全記憶領域の90%を優に超えます。ファクト表には、スキーマのディメンション表の主キーで構成される複合キーがあります。

ファクト表には、ディテール・レベルのファクトまたは集計ファクトのいずれかが含まれます。集計ファクトを含むファクト表は、一般にサマリー表と呼ばれます。通常、ファクト表には同じ集計レベルのファクトが含まれています。ほとんどのファクトは加算的ですが、準加算的なものや非加算的なものもあります。加算ファクトは、単純な加算で集計できます。その最も一般的な例が売上です。非加算ファクトは加算できません。その一例が平均です。準加算ファクトは、ディメンションの一部については集計できますが、他の部分については集計できません。その一例が物理的倉庫に格納された在庫レベルです。倉庫敷地のディメンション全体での加算は可能ですが、時間全体での集計はできません。

ファクト表のデータに行を追加するという観点で、主な方法は次の3つです。

  • トランザクションベース

    トランザクションの最も細かなレベルの詳細の行を示します。特定の組合せのディメンションの値についてトランザクションが発生した場合のみ、行が入力されます。これは最も一般的なタイプのファクト表です。

  • 定期的スナップショット

    日単位または週単位などの、定期的な時間間隔が終わった時点でデータを示します。前の期間にスナップショットの行が存在する場合は、最後の期間で関連するアクティビティが発生しなくても、そのスナップショットの行が新しい期間に入力されます。このタイプのファクト表は、各トランザクション行からスナップショットの値を計算することが困難な、複雑なビジネス・プロセスで有効です。

  • 累積スナップショット

    短期間のプロセスが発生するたびに1行が示されます。行には、短期間のプロセスの主なマイルストンを追跡した、複数の日付が格納されています。他の2つのタイプのファクト表と異なり、累積スナップショットの行は、追跡されたプロセスが前進すると複数回更新されます。

2.4.1.2 データ・ウェアハウスのディメンション表について

ディメンション表はカテゴリ・データを提供し、ファクト・データにコンテキストを与えます。たとえば、売上データのスター・スキーマは、製品、日付、売上場所、宣伝その他のディメンション表を持ちます。ディメンション表の情報は、問合せの制約に使用される値を選択させるもののため、この表は参照表として機能します。多くのディメンション表の値は、頻繁には更新されません。一例として、市を表す地理のディメンションはほとんど変わりません。しかし、ディメンションの値が変更される場合は、早急かつ確実に更新することが不可欠です。当然、データ・ウェアハウスのディメンションの値が頻繁に変更される場合もあります。企業の顧客ディメンションでは、頻繁な更新ストリームおよび削除ストリームに確実に左右されます。

ディメンション表の重要な側面は、提供される階層情報にあります。ディメンションのデータには通常、最下位レベルの詳細の行と、集約されたディメンション値の行があります。このようなディメンション表内でのロールアップまたは集計は階層と呼ばれ、分析に高い価値を付加します。たとえば、特定の製品が示す、特定の製品カテゴリ内の特定の製品の売上高の割合を計算するとします。各問合せに製品カテゴリのすべての要素を指定するよりは、製品集計用の定義済階層を持つ方が、はるかに容易で信頼性が高くなります。階層情報は非常に価値が高いため、一般的に複数の階層がディメンション表に反映されます。

通常、ディメンション表は説明的なテキストであり、その値は問合せで生成されたレポートの行ヘッダー、列ヘッダーおよびページ・ヘッダーとして使用されます。ディメンション表はファクト表に比べ、はるかに少ない行を保持しますが、非常に幅広くなり、数十列になることがあります。場所のディメンション表は、ロールアップ階層のすべてのレベルを示す列を持ち、表に反映された複数の階層を表します。場所のディメンション表には、街の住所、郵便番号、市、州または県および国などの、地理的ロールアップ用の列があります。同じ表に、販売組織用に設定されたロールアップ階層を含め、販売地区、販売地域、販売地方および特徴に対する各列を持たせることができます。

関連項目:

ディメンションの詳細は、ディメンションを参照してください。

2.4.2 スター・スキーマの設計の概念

ここではスター・スキーマで使用される、主要な用語のいくつかに触れます。すべてを説明するわけではなく、検討の価値のある分野の一部について取り上げます。

データの粒度

モデルを設計する際に最も重要なタスクの一つは、データの粒度と呼ぶ、モデルが提供する詳細さのレベルを検討することです。売上スキーマについて検討してみます。各顧客が購入した個々の品目を格納するほど粒度を細かくするべきでしょうか。それとも粒度を粗くし、各店舗で各製品についての日々の売上合計のみを格納すればよいでしょうか。最新のデータ・ウェアハウスでは、分析力を最大限にするため、粒度の非常に細かいデータの提供に特に重点が置かれています。ディメンショナル・モデリングのエキスパートは一般に、各ファクト表が格納する粒度のレベルは1つのみとすることを推奨しています。単一粒度の表でファクト・データを提供することにより、ファクト表のすべての行の適用範囲に曖昧性がなくなるため、より信頼性の高い問合せおよび表のメンテナンスに対応できます。

複数スター・スキーマでの処理

スター・スキーマの設計方法はデータを異なるプロセスに区分化することを意図しているため、問合せが複数スキーマにまたがった場合、スキーマを横断するための信頼性およびパフォーマンスの高い方法が必要です。この機能を表す用語がデータ・ウェアハウス・バス・アーキテクチャです。データ・ウェアハウス・バス・アーキテクチャは、適合済ディメンションおよび適合済ファクトによって実現可能です。

適合済ディメンション

適合済ディメンションとは、ディメンションが様々なスター・スキーマにわたって同一になるよう設計されていることです。適合済ディメンションでは同一の値、列、名前およびデータ・タイプを、複数のスターにわたり一貫して使用します。適合済ディメンションでは、小さい表の行が大きい表の真のサブセットであるかぎり、ディメンション表の各スキーマのコピー間で同一の行数である必要はありません。

適合済ファクト

複数のファクト表内でファクト列がまったく同じ内容の場合、適合済ファクトとみなされます。このようなファクトは異なる表からのものであっても、計算上確実なものとして組み合せて使用できます。適合済ファクトは、適合状態を示すため、同一の列名にする必要があります。適合されていないファクトは、内容が異なることを示すため、常に異なる名前にする必要があります。

サロゲート・キー

サロゲート・キー、すなわち人工キーは、通常連続した整数で、ディメンション表で推奨されています。サロゲート・キーの使用により、操作の変更からデータが隔離されます。また、小型の整数キーでは、大型で複雑な英数字キーに比べ、よりよいパフォーマンスが期待できます。

逆ディメンション

逆ディメンションとは、ファクト表のディメンション列がディメンション表に結合されていないものです。通常は、注文番号やインボイス番号などの項目です。ファクト表の粒度が注文明細項目または単一トランザクションのレベルの場合に見られます。

ジャンク・ディメンション

ジャンク・ディメンションは、ファクト表のフラグおよびコードのテキスト参照値を保持するため使用される、抽象的ディメンション表です。これらのディメンションをジャンクと呼びますが、価値が低いからではなく、利便性のため各種の列を保持していることから、ガラクタの入った引き出し(junk drawer)にたとえられるからです。ジャンク・ディメンション表における各列の個別値(カーディナリティ)は通常、少数です。

埋込み階層

スター・スキーマを使用した従来のディメンショナル・モデリングでは、各表が単一粒度のデータを格納することを推奨していました。ただし、設計者が表に複数の粒度を格納することを選択する場合があり、これらは通常ロールアップ階層を表します。たとえば、単一の売上ファクト表は、トランザクションレベルのデータと、日レベルの製品別ロールアップおよび月レベルの製品別ロールアップの両方で構成されます。この場合、ファクト表は各行に適用する階層レベルを示す、レベル列を持つ必要があり、この表に対する問合せにはレベルの述語が必要になります。

ファクトレス・ファクト表

ファクトレス・ファクト表には、販売価格や販売数量などのメジャーを含みません。そのかわり、ファクトレス・ファクト表の行は、他のファクト表では表されないイベントを示すために使用されます。ファクトレス・ファクト表のもうひとつの使用法は、有効範囲表です。全製品が販売促進用で、宣伝価格で販売された場合などの特定の状況で発生した、考えられるすべてのイベントを保持します。

緩やかに変化するディメンション

データ・ウェアハウスで確実なことの1つは、データの分類方法が変更されることです。製品名やカテゴリ名は変更されるものです。店舗の特徴も変わります。販売地域に含まれるエリアも変わります。これらの変更のタイミングや程度は必ずしも予測できません。こうした緩やかに変化するディメンションには、どのように対処すればよいのでしょうか。スター・スキーマにより、これらに対処する主な方法は、次の3つです。

  • タイプ1

    変更されたディメンションの値を、履歴を残さず単純に上書きします。この場合、時間ベースの分析に問題が発生します。また、ディメンションの古い値に依存する、既存の集計がすべて無効になります。

  • タイプ2

    ディメンションの値が変更されると、新規のディメンション行が変更後の値を示し、新しいサロゲート・キーが作成されます。新しい行が有効になった場合およびその行が期限切れになった場合、ディメンションに日付列を含めるか選択できます。ファクト表を変更する必要はありません。

  • タイプ3

    ディメンションの値が変更された場合、以前の値は同じ行の別の列に格納されます。これにより、列の現在の値と以前の値を使用して結果を比較する場合の問合せの生成が簡単になります。

実際には、緩やかに変化するディメンションの対処としては、タイプ2が最も一般的です。

2.4.3 スノーフレーク・スキーマについて

スノーフレーク・スキーマは、スター・スキーマより複雑なデータ・ウェアハウス・モデルであり、スター・スキーマの一種です。このスキーマの図がスノーフレーク(雪片)に似ているため、スノーフレーク・スキーマと呼ばれます。

スノーフレーク・スキーマでは、ディメンションが正規化され、冗長性が排除されます。つまり、ディメンション・データは1つの大規模な表ではなく複数の表にグルーピングされます。たとえば、スター・スキーマのproductディメンション表は、スノーフレーク・スキーマのproducts表、product_category表およびproduct_manufacturer表に正規化できます。これによって、領域が節約されますが、ディメンション表の数が増加し、より多くの外部キー結合が必要になります。その結果、問合せがより複雑になり、問合せのパフォーマンスが低下します。図2-3に、スノーフレーク・スキーマを示します。

図2-3 スノーフレーク・スキーマ

図2-3の説明が続きます
「図2-3 スノーフレーク・スキーマ」の説明

2.5 インメモリー列ストアを使用した分析の改善

インメモリー列ストア(IM列ストア)は任意のシステム・グローバル領域(SGA)です。ここには、迅速にスキャンできるように最適化された圧縮列形式で、表、表のパーティションおよびその他のデータベース・オブジェクトのコピーが格納されています。

列形式はベクトル処理に適しているため、集計、結合、およびいくつかの種類のデータ取得が、従来のディスク上の形式より高速になります。列形式はメモリーの中にのみ存在するもので、ディスク上の形式やバッファ・キャッシュ形式の代替にはなりません。むしろバッファ・キャッシュを補完するものであり、ディスク形式から独立している、トランザクションと整合的な表の追加コピーです。

従来の分析では、分析の問合せで良好なパフォーマンスを得るために対処する必要がある特定の制限または必要条件を持っています。ユーザーのアクセス・パターンを把握し、そのアクセス・パターンでパフォーマンスが最高になるようにデータ構造をカスタマイズする必要があります。既存の索引、マテリアライズド・ビューおよびOLAPキューブを調整する必要があります。いくつかのデータ・マートとレポーティング・データベースには複合ETLがあるため、特別の調整が必要です。さらに、失効したデータに関する分析の実行と、本番データベース上でのOLTP操作のスローダウンのバランスを最適化する必要があります。

Oracle Databaseの範囲内で Oracle In-Memory Column Store(IM列ストア)を活用すると、非定型の問合せとライブ・データの分析のパフォーマンスが向上します。ライブ・トランザクション・データベースは問合せに瞬時に応答するために使用され、それにより、OLTPトランザクションとデータ・ウェアハウス分析に、同じデータベースをシームレスに使用することが可能になります。

IM列ストアは、Oracle Databaseとシームレスに統合され、データ・ウェアハウス環境に次の利点をもたらします。

  • 問合せパフォーマンスの向上

    • 予期しないアクセス・パターンの非定型の問合せの処理が速くなります。

      IM列ストアは、大量データの分析の際のスループットを高速化できます。表の列のサブセットを問い合せると、特定のデータ分析タスクに必要な列のみがスキャンされるため、結果がすばやく取得されます。

    • 大量の行のスキャン、および=、<、>およびINなどの演算子を使用するフィルタの適用は、SIMDベクトル処理を使用すると速くなります。

    • 頻繁に評価される式をIM式を使用して格納すると、同じ式を繰り返して計算することが少なくなります。

    • IM仮想列を使用して、指定した仮想列をIM列ストアに移入すると、仮想列を繰り返して評価することが回避されます。

  • ブルーム・フィルタを使用した強化された結合パフォーマンス

    特定の種類の結合は、結合される表がIM列ストアに格納されている場合、より高速に実行されます。IM列ストアは、小さいディメンション表に対する述語を大きいファクト表に対するフィルタに変換することによって結合を高速化するハッシュ結合を使用するブルーム・フィルタを活用しています。

  • VECTOR GROUP BY変換とベクトル配列処理の使用による効率的な集計。

    データを集計して1つ以上の比較的小さい表をより大きい表に結合する問合せ(スター・クエリーでよく行われます)がより速く実行されます。VECTOR GROUP BYは、オプティマイザによって、コスト見積もりに基づいて選択されます。

  • IM列ストア使用に伴う必要な索引、マテリアライズド・ビューおよびOLAPキューブの減少による、記憶域と処理オーバーヘッドの大幅な低下。

関連項目:

IM列ストアの使用の詳細は、Oracle Database In-Memoryガイドを参照してください。

2.5.1 インメモリー式を使用した問合せパフォーマンスの改善について

インメモリー列ストア(IM列ストア)を使用すると、頻繁に評価される式にインメモリー式(IM式)を使用することによって問合せパフォーマンスをさらに向上させることができます。

データ・ウェアハウス環境のほとんどの問合せでは、大きいデータ・セットへの問合せが行われ、複雑な式や計算が含まれているため計算集約的です。IM式を使用すると、頻繁に評価される式を含む問合せのパフォーマンスが向上します。オプティマイザは、繰返し使用される式を自動的に識別して式統計ストア(ESS)に記録します。ESSに取得された式はIM式の候補となります。再使用を促進するには、IM式をマテリアライズしてIM列ストア内のインメモリー式単位(IMEU)に移入します。データベースは、IM式を保守し、それらの式が基にしているソース列への変更と整合性が保たれるようにします。IM式をIM列ストアに移入すると、同じ式が繰り返して計算されることが少なくなります。

たとえば、価格と販売数の積である売上金額はIM式の候補です。IM式を使用しない場合は、すべての問合せおよび問合せによって返されるすべての行で、売上金額の値を再計算する必要があります。IM式を使用する場合は、この頻繁に評価される式をマテリアライズしてIM列ストアに格納できます。これにより、問合せに使用される式を繰返し再計算する必要がなくなります。Oracle Databaseは、IM列ストアに格納されている式の結果を使用するように実行時に問合せをリライトし、問合せのパフォーマンスを向上させます。

初期化パラメータINMEMORY_EXPRESSIONS_USAGEは、IM列ストアに移入する必要があるIM式を制御します。DBMS_INMEMORY_ADMINパッケージのプロシージャは、IM式を識別、移入および使用するタイミングを指定します。

関連トピック

2.5.2 インメモリー仮想列を使用した問合せパフォーマンスの改善について

インメモリー列ストア(IM列ストア)を使用すると、インメモリー仮想列(IM仮想列)を使用して、指定した仮想列をIM列ストアに移入することによって、仮想列を繰り返して評価することを回避できます。

仮想列は、ユーザーが作成した名前付きの式であり、Oracleによって通常の列のように扱われます。たとえば、SALARY表に列monthly_salaryが含まれている場合は、annual_salaryという仮想列をmonthly_salary * 12として定義できます。IM仮想列は、IM列ストアに移入できる仮想列です。表に定義されている仮想列のすべてまたはサブセットをIM列ストアに移入できます。再計算された仮想列をIM列ストアに格納すると、評価を繰り返すことが回避され、問合せパフォーマンスが向上します。仮想列値は、SIMDベクトル処理などのインメモリー・テクニックを使用してスキャンおよびフィルタ処理することもできます。

初期化パラメータINMEMORY_VIRTUAL_COLUMNSは、IM列ストアが有効にされている表のIM仮想列を作成するかどうかを決定します。

関連トピック

2.5.3 インメモリー列ストアと自動データ最適化について

自動データ最適化(ADO)を使用すると、インメモリー列ストア(IM列ストア)のコンテンツを管理できます。

IM列ストアによって提供されるパフォーマンスの利点は、IM列ストアのコンテンツを効果的に管理することによって最適化できます。IM列ストアに格納されることで最もメリットがあるオブジェクトを保持する必要があります。IM列ストアに保持する必要があるオブジェクト、および削除する必要があるオブジェクトを判別するために、IM列ストアを常に監視する必要があります。

自動データ最適化(ADO)は、IM列ストアのコンテンツの管理を自動化します。IM列ストア内のオブジェクトについてヒート・マップ統計が収集され、最もアクティブではないオブジェクトおよび最もアクティブなオブジェクトを判別するために、それらの統計が使用されます。ADOポリシーを定義すると、IM列ストアからオブジェクトを削除するタイミングを指定できます。

データ・ウェアハウス・アプリケーションでは、通常、オブジェクトがアクセスされる頻度は時間の経過に従って減少します。このため、オブジェクトは最初にデータ・ウェアハウスにロードされたときに最も頻繁にアクセスされ、アクティビティ・レベルは徐々に減少します。データ・ウェアハウスのパフォーマンスは、最もアクセスが少ないオブジェクトをIM列ストアから削除するADOポリシーを定義することによって改善できます。

関連トピック

2.6 大きな表の自動キャッシングによるインメモリー・パラレル問合せのパフォーマンス向上

大きな表の自動キャッシングは、インメモリー・パラレル問合せのパフォーマンスを向上させます。表がメモリー内に収まらない場合、データベースはアクセス・パターンに基づいてキャッシュするバッファを決定します。大きな表がバッファ・キャッシュに完全におさまらない場合も、これにより効率的なキャッシュが可能になります。

表スキャンのデータを格納するためにはバッファ・キャッシュのオプションの1セクションが使用され、それは「大きな表のキャッシュ」と呼ばれます。大きな表のキャッシュはバッファ・キャッシュと統合され、温度ベースでオブジェクト・レベルの置換アルゴリズムを使用して、大きな表のキャッシュ内容を管理します。これは、バッファ・キャッシュが使用する、アクセス・ベースでブロック・レベルのLRUアルゴリズムとは異なります。

ノート:

大きな表の自動キャッシングは、Oracle Database 12cリリース1(12.1.0.2)以上で使用できます。

一般的なデータ・ウェアハウジング・ワークロードでは、複数の表がスキャンされます。これらの表の合計サイズがバッファ・キャッシュの合計サイズより大きい場合、パフォーマンスに影響が生じる場合があります。大きな表の自動キャッシングでは、スキャンされた表は、バッファ・キャッシュでなく大きな表のキャッシュに格納されます。大きな表のキャッシュで使用される温度ベースでオブジェクト・レベルの置換アルゴリズムでは、次のようなデータ・ウェアハウジング・ワークロードのパフォーマンスを向上させることができます。

  • 「ホット」オブジェクトの選択的なキャッシュ格納

    オブジェクトがアクセスされるたびに、Oracle Databaseはそのオブジェクトの温度をインクリメントします。大きな表のキャッシュにあるオブジェクトは、その温度より高い温度を持つ別のオブジェクトとのみ置換できます。

  • スラッシングの回避

    オブジェクトを完全にはキャッシュに格納できない場合、オブジェクトの一部をキャッシュに格納します。

Oracle Real Application Clusters(Oracle RAC)環境では、大きな表の自動キャッシングは、パラレル問合せについてのみサポートされます。単一インスタンス環境では、この機能は、シリアル問合せとパラレル問合せの両方についてサポートされます。

大きな表の自動キャッシングを使用するには、大きな表のキャッシュを有効化する必要があります。連続する問合せに対して大きな表の自動キャッシングを使用するには、DB_BIG_TABLE_CACHE_PERCENT_TARGET初期化パラメータをゼロ以外の値に設定する必要があります。パラレル問合せに対して大きな表の自動キャッシングを使用するには、PARALLEL_DEGREE_POLICYをAUTOまたはADAPTIVEに、そしてDB_BIG_TABLE_CACHE_PERCENT_TARGETをゼロ以外の値に設定する必要があります。

関連項目:

大きな表のキャッシュとその使用方法の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。