| Oracle® Databaseデータ・ウェアハウス・ガイド 12c リリース1 (12.1) B71318-06 |
|
 前 |
 次 |
組織でのエンタープライズ･データ・ウェアハウス構築がすでに決定されているとします。そして、ビジネス要件の定義、ビジネスの目的の適用範囲の打合せ、および概念的な設計も完了しているとします。そこで、その要件をシステムに移行できるように変換する必要があります。そのためには、データ・ウェアハウスの論理設計と物理設計を行います。定義する内容は、次のとおりです。
具体的なデータ内容
データ・グループ内およびデータ・グループ間の関係
データ・ウェアハウスをサポートするシステム環境
必要なデータ変換
データのリフレッシュ頻度
論理設計は、物理設計に比べて概念的で抽象的です。論理設計では、オブジェクト間の論理的な関係を検討します。物理設計では、オブジェクトの格納と取出しの他、転送処理およびバックアップ/リカバリの観点から、最も効果的な方法を検討します。
設計では、エンド・ユーザーのニーズを優先させる必要があります。エンド・ユーザーは、通常、個々のトランザクションではなく、分析を行って集計されたデータを見ます。ただし、実際にデータを見るまで、何が必要であるかがエンド・ユーザーにはわからない場合があります。適切に計画された設計であれば、ユーザーのニーズの変化や発展に応じて、拡張および変更を行うことができます。
まず、論理設計から始めると、情報についての要件に集中でき、実装の詳細は後で検討できます。
論理設計とは、概念的で抽象的な設計です。ここでは、物理的な実装の詳細は説明しません。必要な情報の種類の定義方法のみを扱います。
組織の論理的な情報要件のモデリングに使用できるテクニックの1つが、E-Rモデリングです。E-Rモデリングでは、重要事項(エンティティ)、重要事項のプロパティ(属性)および相互の関連(リレーションシップ)を特定します。
物理設計プロセスでは、データを、エンティティおよび属性と呼ばれる、一連の論理的な関係に配置します。エンティティは、情報の大きいまとまりを表します。エンティティは、リレーショナル・データベースの表にマップされます。属性はエンティティのコンポーネントで、エンティティの一意性を定義します。属性は、リレーショナル・データベースの列にマップされます。
データの一貫性を確実にするには、一意識別子を使用する必要があります。一意識別子は、同じ項目が異なる場所に表示される場合に、両者を区別できるように表に追加する識別子です。これは通常、物理設計における主キーです。
E-Rモデリングは、完全に論理的なものであり、OLTPとデータ･ウェアハウス･システムの両方に適用されます。データ･ウェアハウス環境で一般的に使用されている、様々な物理スキーマ･モデリング技法、つまり、エンタープライズ･データ･ウェアハウス環境での正規化(3NF)スキーマ、データ･マートでのスターまたはスノーフレーク･スキーマ、またはこれら古典的モデリング技法の両方のコンポーネントを使用した、ハイブリッド･スキーマにも適用可能です。
関連項目:
ODIの詳細は、『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』を参照してください。
スキーマとは、表、ビュー、索引およびシノニムを含むデータベース・オブジェクトのコレクションです。データ・ウェアハウス用に設計されたスキーマ・モデルには、様々な方法でスキーマ・オブジェクトを配置できます。ほとんどのデータ・ウェアハウスでは、ディメンショナル・モデルが使用されます。
データ・ウェアハウス・スキーマの設計には、ソース・データのモデルとユーザー要件を使用できます。会社のエンタープライズ・データ・モデルからソース・データを取得し、これを基にデータ・ウェアハウス用の論理データ・モデルをリバース・エンジニアすることが可能な場合があります。論理データ・ウェアハウス・モデルの物理的な実装には、コンピュータのサイズ、ユーザー数、記憶域の容量、ネットワークの種類、ソフトウェアなどのシステム・パラメータに応じて、多少の変更が必要な場合があります。スキーマの設計の重要な部分は、第3正規形、スターまたはスノーフレーク・スキーマを使用するかどうかということですが、これらについては、後で詳しく説明します。
第3正規形の設計では、データの冗長性を最小化し、データの挿入、更新および削除において非一貫性を回避することが求められます。3NFの設計は、オンライン・トランザクション処理(OLTP)システムで長く使用されてきました。OLTPシステムでは、データの挿入、更新および削除時のパフォーマンスおよび精度を最大限にする必要があります。トランザクションは、可能なかぎり早急に処理する必要があります。そうでなければ、業務でイベントのフローを処理できなくなり、売上の喪失または損害を被る可能性があります。そのため3NFの設計により、挿入、更新および削除を減速させる可能性のある、冗長なデータ操作を回避し、表のロックを最小限にします。3NFの設計は、特定のアプリケーションのニーズによるデータの抽出にも有効です。環境に新しいタイプのデータが追加された場合、データ・モデルを比較的容易に拡張し、既存アプリケーションへの影響を最小限に抑えることができます。同様に、データ・ウェアハウスで実行するまったく新しいタイプの分析がある場合、十分な設計の3NFスキーマは、データ構造の再設計を必要とすることなく、それらを処理できます。
3NF設計には優れた柔軟性がありますが、デメリットもあります。3NFデータベースは非常に多くの表を使用するため、多くの結合で複雑な問合せを必要とします。3NFで構築された、フル・スケールのエンタープライズ・モデルでは、一般的に1,000を超える表がスキーマに記載されています。データ・ウェアハウスでは多くの場合、多数の表の多数の行へのアクセスを必要としますが、含まれる問合せの種類の数に比例して、この設計が理解を妨げるようになり、パフォーマンスが低下します。問合せの作成者が人間であれ、ビジネス・インテリジェンス・ツールおよびアプリケーションであれ、使用可能な表が非常に多数の場合は、データの特定の部分に必要な表を選択および結合することは、複雑な作業になります。問合せジェネレータによって表が即座に選択される場合でも、3NFスキーマは多くの場合、単一の問合せで多数の表を必要とします。問合せに存在する表が多くなるほど、潜在的なデータ・アクセス・パスが増えることになり、データベース問合せオプティマイザの負荷が増大します。最終的には、問合せパフォーマンスが低下します。
3NFシステムにおける問合せパフォーマンス低下の問題は、レポートおよび分析の作成に使用される、コアの問合せに必ずしも限定されたものではありません。内容を理解するためユーザーがデータのサブセットを参照しているような、より単純なタスクでも発生する可能性があります。同様に、3NFスキーマの複雑さは、問合せおよびレポートの制約に使用される、データの選択リストの作成に影響する可能性があります。これらは比較的軽微な問題に見えますが、このようなプロセスでの応答時間が速いことは、ユーザーの満足度に大きく影響します。
図2-1に、3NFスキーマのごく一部を示します。冗長性の高いデータの格納を避けるため、注文情報が注文と注文品目に分割されていることに注意してください。表間の関係上のカラスの足跡マークは、エンティティ間の1対多の関係を示しています。このように、1つの注文には複数の注文品目があり、1人の顧客には多くの注文があり、さらには1つの製品が多くの注文品目の中にあります。この図では非常に簡単な例を示していますが、データの冗長性を最小化することが、スキーマに多くの表ができることにつながることがわかります。
関連項目:
正規化とは、各ファクトを1箇所のみに保持し、データの冗長性や挿入、更新および削除の非一貫性を回避するという、高いレベルの目的を持ったデータ設計プロセスです。正規化には複数のレベルがありますが、この項ではそれらの内の最初の3つを説明します。第3正規形(3NF)という用語がいかに基本的なものであるかを考えれば、3NFがどのように実現されるかを見なければ意味がありません。
売上を追跡する場合を考えてみます。追跡の中心になるエンティティは受注ですが、各受注には品名、価格、数量など、各購買品目についての詳細(明細項目と呼ぶ)が含まれます。受注には顧客の氏名や住所なども含まれます。様々な明細項目のある受注もあれば、1つしかない場合もあります。
第1正規形(1NF)では、データ・グループの繰り返しや重複行は存在しません。行と列の各交差部分(フィールド)には、1つの値のみが格納されており、同一のファクトを格納する列のグループは存在しません。重複行を避けるため、主キーが存在します。第1正規形における受注では、表の1つのフィールドには各受注の複数の明細項目は表示されません。また、明細項目を示す複数の列は存在しません。
次の第2正規形(2NF)は、設計は第1正規形のものですが、各非キー列は完全な主キーに依存しています。そこで、明細項目を受注明細項目表に抜き出し、各行が1つの注文の1明細項目を表すようにします。明細項目表を見ると、売上項目の品名は明細項目表の主キーに依存していないことがわかります。つまり、売上項目は独自のエンティティです。したがって、売上項目を品名を示している独自の表に移動します。各項目に対する請求額は、注文により異なる(たとえば、値引によって)ため、明細項目表に残します。この受注表の例では、顧客の氏名および住所は受注表の主キーに依存していません。つまり、顧客は独自のエンティティです。したがって、顧客の氏名および住所列は独自の顧客情報表に移動します。
次の第3正規形の目的は、非キー属性に依存しないことを確認することです。つまり、行のサブジェクト(主キー)に直接関連付けられていない列を取得して、それらを独自の表に配置することが目的になります。したがって、顧客の名前や顧客の市などの顧客に関する詳細を別個の表に配置してから、customer外部キーをorders表に追加する必要があります。
2NF表と3NF表の相違の別の例として、トーナメント、年、勝者および勝者の誕生日の列を含む、テニス・トーナメントの勝者の表が挙げられます。この場合、勝者の誕生日は、不整合を起こしやすくなります。なぜなら、同じ人が、異なるレコード内で異なる誕生日で表示される可能性があるためです。この潜在的な問題を回避する方法は、表を、トーナメントの勝者用のものと、選手の誕生日用のものに分けることです。
次の項では、3NFスキーマの手法を使用したデータ･ウェアハウス環境向けのモデリングの際の、基本概念のいくつかについて説明します。ここでは3NFモデリング(またはさらに高いレベルの正規化)の論理的根拠についての説明ではなく、データ･ウェアハウスに関連する主要コンポーネントに注目することを意図しています。
データ・ウェアハウジングに関連する、3NFスキーマ設計の重要な概念を次にいくつか示します。
主キーとは、表の中の特定のレコードを一意に識別する属性です。主キーは、単一または複数の列により識別することができます。通常は、可能なかぎり少ない列(理想的には1つか2つ)によって一意の識別を実現することと、更新の可能性の最も低い列または一括で変更されることのない列のいずれかの使用が望ましいとされています。もしデータ･モデルが、その属性を使用した単純な一意の識別につながらない場合は、1つのレコードを一意に識別するために必要な属性が多すぎるか、データが変更されやすいためなので、サロゲート･キーの使用を強くお薦めします。
問合せは多くの表の結合を持つ傾向があり、結合による行の重複を避けるために、レコードを一意に識別するために必要なすべての列が結合条件として必要であるため、3NFスキーマは特に、完全かつ単純な一意の識別に依存します。
データ･ウェアハウス環境における3NFスキーマは、そのOLTPソース･システムのデータ・モデルに通常、類似していますが、そこではデータ･エンティティ間の論理的整合性は、親子関係としても知られる主キーと外部キーの関係によって表現および規定されています。外部キーは、リレーショナル･システムでの1対多の関係を解決し、論理的整合性を保証します。たとえば、注文ヘッダーのない注文明細項目や、存在しない部門で働く従業員を持つことはできません。
そうした参照がOLTPシステムでは常に強制されていますが、データ･ウェアハウス・システムでは通常、これらを強制されない条件である宣言として実装し、ETLプロセスに依存してデータの整合性を保証します。可能な場合は、外部キーと参照整合性制約を強制されない条件として常に定義するようにします。これにより、問合せの最適化およびカーディナリティの見積りを向上させることができます。
完全な非正規化モデリングでは、論理的なエンティティ(顧客、製品、注文など)が多くの物理表に分解される傾向があり、既知の単純な情報の取得でさえ、多くの表の結合が必要になります。ただし、これは問合せ処理の観点からは問題ではなく、データベース(情報が結合され、常に同時に使用されるため)だけでなく、アプリケーション開発者(コードを記述する)にも不必要な負荷がいくぶん掛かるというだけです。3NFのデータ･ウェアハウス･モデルの非正規化は、論理的な形式ではビューで、物理的な形式では表の非正規化が多少行われるという、ある程度のレベルにとどまることも珍しくありません。
物理的な非正規化には、サブジェクト･ニュートラルな形状を保持するよう注意が必要であり、そのため3NFスキーマの物理的実装には柔軟性があります。
スター･スキーマは、埋込み論理データ･マートまたは埋込み物理データ･マートを使用したデータ･ウェアハウス･システムでは、一般的に使用されています。スター・スキーマは、データ・モデルを定義する、ディメンショナル・モデリング法の別名です。ほとんどのディメンショナル・モデリングについての説明は、この分野の先駆的コンサルタントかつライターであるRalph Kimball氏の文献から引用した用語を使用しています。ディメンショナル・モデリングでは複数のスター・スキーマが作成され、その各々が売上追跡や出荷などのビジネス・プロセスに基づいています。各スター・スキーマは1つのデータ・マートと見なすことができ、わずか20個程度のデータ・マートがあれば、1企業のビジネス・インテリジェンスのニーズに対応できます。3NF設計と比較すると、ディメンショナル・モデリングで使用される表の数は微々たるものです。多くのスター・スキーマで保持される表は、1ダース足らずです。スター・スキーマは適合済ディメンションと適合済ファクトを介して一体化されます。したがって、ユーザーは最小限の労力で複数のスター・スキーマからデータを取得できます。
スター・スキーマの目的は、構造の簡素化とデータ取得のパフォーマンス向上です。近年ではほとんどの問合せがレポート・ツールやアプリケーションによって生成されるため、ツールやアプリケーションでの問合せの生成を簡便で信頼性の高いものにすることが不可欠です。実際、多くのビジネス・インテリジェンス・ツールおよびアプリケーションは、スター・スキーマの表現が使用可能なことを見込んで設計されています。
スター・スキーマの説明では、3NFに比べて物理データベースの説明の要約は多くありません。これはディメンショナル・モデリングが実際にビジネス・インテリジェンス・ユーザーのニーズに対して重点を置いているためです。
ディメンショナル・モデリングの形式と、データの冗長性および更新、挿入、削除の非一貫性の危険を最小化する3NFの方法の違いに注意してください。スター・スキーマでは、ユーザーの理解しやすさとデータ取得のよりよいパフォーマンスを意図して、ディメンション表でのデータの冗長性(非正規化)を許容します。スター・スキーマへの一般的な批判は、3NF設計と比較して分析の柔軟性が限定されるというものです。しかし、適切に設計されたディメンショナル・モデルは、新しいタイプの分析が可能になるよう拡張でき、スター・スキーマは最大規模の企業で長年正常に動作しています。
前述のとおり、データ・ウェアハウスの最新の手法は、スター・スキーマと3NFを対抗させるものではありません。むしろ、3NFの基盤レイヤー(3NFのエンタープライズ･データ･ウェアハウス)は基盤データとして、スター・スキーマはアクセスの中核部分およびパフォーマンス最適化レイヤーとしてそれぞれ機能し、2つの技術がともに使用されています。
スター・スキーマでは、データをファクトとディメンションに分割します。ファクトは売上など、なんらかのイベントの実測値であり、通常は数字です。ディメンションは日付、場所、製品などのファクトの識別に使用するカテゴリです。
スター・スキーマという名前は、スキーマのダイアグラムでは通常、中心のファクト表に付いた線が、ディメンション表に結合しているため、図の印象が星に似ていることに由来します。図2-2は、ファクト表である売上と、ディメンション表である製品、時間、顧客およびチャネルの簡単な例です。
ファクト表は実測値を保持しています。ファクト表は、多数の行を保持しますが、列は通常多くありません。大企業のファクト表では数十億行を保持することがあります。多くのスター・スキーマでは、ファクト表は全記憶領域の90%を優に超えます。ファクト表はスキーマのディメンション表の主キーからなる複合キーを持ちます。
ファクト表には、ディテール・レベルのファクトまたは集計ファクトのいずれかが含まれます。集計ファクトを含むファクト表は、一般にサマリー表と呼ばれます。通常、ファクト表には同じ集計レベルのファクトが含まれています。ほとんどのファクトは加算的ですが、準加算的なものや非加算的なものもあります。加算ファクトは、単純な加算で集計できます。その最も一般的な例が売上です。非加算ファクトは加算できません。その一例が平均です。準加算ファクトは、ディメンションの一部については集計できますが、他の部分については集計できません。その一例が物理的倉庫に格納された在庫レベルです。倉庫敷地のディメンション全体での加算は可能ですが、時間全体での集計はできません。
ファクト表のデータに行を追加するという観点で、主な方法は次の3つです。
トランザクションベース
トランザクションの最も細かなレベルの詳細の行を示します。特定の組合せのディメンションの値についてトランザクションが発生した場合のみ、行が入力されます。これは最も一般的なタイプのファクト表です。
定期的スナップショット
日単位または週単位などの、定期的な時間間隔が終わった時点でデータを示します。前の期間にスナップショットの行が存在する場合は、最後の期間で関連するアクティビティが発生しなくても、そのスナップショットの行が新しい期間に入力されます。このタイプのファクト表は、各トランザクション行からスナップショットの値を計算することが困難な、複雑なビジネス・プロセスで有効です。
累積スナップショット
短期間のプロセスが発生するたびに1行が示されます。行には、短期間のプロセスの主なマイルストンを追跡した、複数の日付が格納されています。他の2つのタイプのファクト表と異なり、累積スナップショットの行は、追跡されたプロセスが前進すると複数回更新されます。
ディメンション表はカテゴリ・データを提供し、ファクト・データにコンテキストを与えます。たとえば、売上データのスター・スキーマは、製品、日付、売上場所、宣伝その他のディメンション表を持ちます。ディメンション表の情報は、問合せの制約に使用される値を選択させるもののため、この表は参照表として機能します。多くのディメンション表の値は、頻繁には更新されません。一例として、市を表す地理のディメンションはほとんど変わりません。しかし、ディメンションの値が変更される場合は、早急かつ確実に更新することが不可欠です。当然、データ・ウェアハウスのディメンションの値が頻繁に変更される場合もあります。企業の顧客ディメンションでは、頻繁な更新ストリームおよび削除ストリームに確実に左右されます。
ディメンション表の重要な側面は、提供される階層情報にあります。ディメンションのデータには通常、最下位レベルの詳細の行と、集約されたディメンション値の行があります。このようなディメンション表内でのロールアップまたは集計は階層と呼ばれ、分析に高い価値を付加します。たとえば、特定の製品が示す、特定の製品カテゴリ内の特定の製品の売上高の割合を計算するとします。各問合せに製品カテゴリのすべての要素を指定するよりは、製品集計用の定義済階層を持つ方が、はるかに容易で信頼性が高くなります。階層情報は非常に価値が高いため、一般的に複数の階層がディメンション表に反映されます。
通常、ディメンション表は説明的なテキストであり、その値は問合せで生成されたレポートの行ヘッダー、列ヘッダーおよびページ・ヘッダーとして使用されます。ディメンション表はファクト表に比べ、はるかに少ない行を保持しますが、非常に幅広くなり、数十列になることがあります。場所のディメンション表は、ロールアップ階層のすべてのレベルを示す列を持ち、表に反映された複数の階層を表します。場所のディメンション表には、街の住所、郵便番号、市、州または県および国などの、地理的ロールアップ用の列があります。同じ表に、販売組織用に設定されたロールアップ階層を含め、販売地区、販売地域、販売地方および特徴に対する各列を持たせることができます。
関連項目:
ディメンションの詳細は、ディメンションを参照してください。
ここではスター・スキーマで使用される、主要な用語のいくつかに触れます。すべてを説明するわけではなく、検討の価値のある分野の一部について取り上げます。
データの粒度
モデルを設計する際に最も重要なタスクの一つは、データの粒度と呼ぶ、モデルが提供する詳細さのレベルを検討することです。売上スキーマについて検討してみます。各顧客が購入した個々の品目を格納するほど粒度を細かくするべきでしょうか。それとも粒度を粗くし、各店舗で各製品についての日々の売上合計のみを格納すればよいでしょうか。最新のデータ・ウェアハウスでは、分析力を最大限にするため、粒度の非常に細かいデータの提供に特に重点が置かれています。ディメンショナル・モデリングのエキスパートは一般に、各ファクト表が格納する粒度のレベルは1つのみとすることを推奨しています。単一粒度の表でファクト・データを提供することにより、ファクト表のすべての行の適用範囲に曖昧性がなくなるため、より信頼性の高い問合せおよび表のメンテナンスに対応できます。
複数スター・スキーマでの処理
スター・スキーマの設計方法はデータを異なるプロセスに区分化することを意図しているため、問合せが複数スキーマにまたがった場合、スキーマを横断するための信頼性およびパフォーマンスの高い方法が必要です。この機能を表す用語がデータ・ウェアハウス・バス・アーキテクチャです。データ・ウェアハウス・バス・アーキテクチャは、適合済ディメンションおよび適合済ファクトによって実現可能です。
適合済ディメンション
適合済ディメンションとは、ディメンションが様々なスター・スキーマにわたって同一になるよう設計されていることです。適合済ディメンションでは同一の値、列、名前およびデータ・タイプを、複数のスターにわたり一貫して使用します。適合済ディメンションでは、小さい表の行が大きい表の真のサブセットであるかぎり、ディメンション表の各スキーマのコピー間で同一の行数である必要はありません。
適合済ファクト
複数のファクト表内でファクト列がまったく同じ内容の場合、適合済ファクトとみなされます。このようなファクトは異なる表からのものであっても、計算上確実なものとして組み合せて使用できます。適合済ファクトは、適合状態を示すため、同一の列名にする必要があります。適合されていないファクトは、内容が異なることを示すため、常に異なる名前にする必要があります。
サロゲート・キー
サロゲート・キー、すなわち人工キーは、通常連続した整数で、ディメンション表で推奨されています。サロゲート・キーの使用により、操作の変更からデータが隔離されます。また、小型の整数キーでは、大型で複雑な英数字キーに比べ、よりよいパフォーマンスが期待できます。
逆ディメンション
逆ディメンションとは、ファクト表のディメンション列がディメンション表に結合されていないものです。通常は、注文番号やインボイス番号などの項目です。ファクト表の粒度が注文明細項目または単一トランザクションのレベルの場合に見られます。
ジャンク・ディメンション
ジャンク・ディメンションは、ファクト表のフラグおよびコードのテキスト参照値を保持するため使用される、抽象的ディメンション表です。これらのディメンションをジャンクと呼びますが、価値が低いからではなく、利便性のため各種の列を保持していることから、ガラクタの入った引き出し(junk drawer)にたとえられるからです。ジャンク・ディメンション表における各列の個別値(カーディナリティ)は通常、少数です。
埋込み階層
スター・スキーマを使用した従来のディメンショナル・モデリングでは、各表が単一粒度のデータを格納することを推奨していました。ただし、設計者が表に複数の粒度を格納することを選択する場合があり、これらは通常ロールアップ階層を表します。たとえば、単一の売上ファクト表は、トランザクションレベルのデータと、日レベルの製品別ロールアップおよび月レベルの製品別ロールアップの両方で構成されます。この場合、ファクト表は各行に適用する階層レベルを示す、レベル列を持つ必要があり、この表に対する問合せにはレベルの述語が必要になります。
ファクトレス・ファクト表
ファクトレス・ファクト表には、販売価格や販売数量などのメジャーを含みません。そのかわり、ファクトレス・ファクト表の行は、他のファクト表では表されないイベントを示すために使用されます。ファクトレス・ファクト表のもうひとつの使用法は、有効範囲表です。全製品が販売促進用で、宣伝価格で販売された場合などの特定の状況で発生した、考えられるすべてのイベントを保持します。
緩やかに変化するディメンション
データ・ウェアハウスで確実なことの1つは、データの分類方法が変更されることです。製品名やカテゴリ名は変更されるものです。店舗の特徴も変わります。販売地域に含まれるエリアも変わります。これらの変更のタイミングや程度は必ずしも予測できません。こうした緩やかに変化するディメンションには、どのように対処すればよいのでしょうか。スター・スキーマにより、これらに対処する主な方法は、次の3つです。
タイプ1
変更されたディメンションの値を、履歴を残さず単純に上書きします。この場合、時間ベースの分析に問題が発生します。また、ディメンションの古い値に依存する、既存の集計がすべて無効になります。
タイプ2
ディメンションの値が変更されると、新規のディメンション行が変更後の値を示し、新しいサロゲート・キーが作成されます。新しい行が有効になった場合およびその行が期限切れになった場合、ディメンションに日付列を含めるか選択できます。ファクト表を変更する必要はありません。
タイプ3
ディメンションの値が変更された場合、以前の値は同じ行の別の列に格納されます。これにより、列の現在の値と以前の値を使用して結果を比較する場合の問合せの生成が簡単になります。
実際には、緩やかに変化するディメンションの対処としては、タイプ2が最も一般的です。
スノーフレーク・スキーマは、スター・スキーマより複雑なデータ・ウェアハウス・モデルであり、スター・スキーマの一種です。このスキーマの図がスノーフレーク(雪片)に似ているため、スノーフレーク・スキーマと呼ばれます。
スノーフレーク・スキーマでは、ディメンションが正規化され、冗長性が排除されます。つまり、ディメンション・データは1つの大規模な表ではなく複数の表にグルーピングされます。たとえば、スター・スキーマのproductディメンション表は、スノーフレーク・スキーマのproducts表、product_category表およびproduct_manufacturer表に正規化できます。これによって、領域が節約されますが、ディメンション表の数が増加し、より多くの外部キー結合が必要になります。その結果、問合せがより複雑になり、問合せのパフォーマンスが低下します。図2-3に、スノーフレーク・スキーマを示します。
注意:
(この機能は、Oracle Database 12cリリース1(12.1.0.2)以上で使用できます。)
従来の分析では、分析の問合で良好なパフォーマンスを得るために対処する必要がある特定の制限または必要条件を持っています。ユーザーのアクセス・パターンを把握し、そのアクセス・パターンでパフォーマンスが最高になるようにデータ構造をカスタマイズする必要があります。既存の索引、マテリアライズド・ビューおよびOLAPキューブを調整する必要があります。いくつかのデータ・マートとレポーティング・データベースには複合ETLがあるため、特別の調整が必要です。さらに、失効したデータに関する分析の実行と、本番データベース上でのOLTP操作のスローダウンのバランスを最適化する必要があります。
Oracle Databaseの範囲内で Oracle In-Memory Column Store(IM列ストア)を活用すると、非定型の問合せとライブ・データの分析のパフォーマンスが向上します。ライブ・トランザクション・データベースは問合せに瞬時に応答するために使用され、それにより、OLTPトランザクションとデータ・ウェアハウス分析に、同じデータベースをシームレスに使用することが可能になります。
IM列ストアはSGA内のオプション領域で、表、表パーティションおよび個別の列のコピーが、高速スキャンに最適化された圧縮列形式で格納されます。列形式はベクトル処理に適しているため、集計、結合、およびいくつかの種類のデータ取得が、従来のディスク上の形式より高速になります。列形式はメモリーの中にのみ存在するもので、ディスク上の形式やバッファ・キャッシュ形式の代替にはなりません。むしろバッファ・キャッシュを補完するものであり、ディスク形式から独立している、トランザクションと整合的な表の追加コピーです。
関連項目:
IM列ストアの概要は、『Oracle Database概要』を参照してください。
Oracle In-Memory Column Storeの構成
IM列ストアの構成は簡単です。INMEMORY_SIZE初期化パラメータを設定してから、DDLを使用して、IM列ストアに移入する表領域、表、パーティションまたは列を指定します。
関連項目:
IM列ストアの構成の詳細は、『Oracle Database管理者ガイド』を参照してください。
Oracle In-Memory Column Storeの移入
データベースがデータをRAW記憶域からIM列ストアに移入するのを、データベース・インスタンスの起動時と、データが初めてアクセスされたときのいずれにするかを指定できます。
関連項目:
IM列ストアの移入方法の詳細は、『Oracle Database概要』を参照してください。
In-Memory列圧縮
Oracle Databaseは、記憶域の削減よりもむしろアクセス速度に最適化した特別の圧縮形式を使用してデータをIM列ストアに格納します。表、パーティションまたは列それぞれに対して、異なる圧縮オプションを選択できます。
関連項目:
『Oracle Database概要』
『Oracle Database管理者ガイド』
IM列ストアを使用すると、Oracle Databaseがスキャン、結合および集計を、ディスク上の形式のみを使用する場合よりはるかに速く実行できるようになります。ビジネス・アプリケーション、非定型の分析問合せおよびデータ・ウェアハウスのワークロードにおいて利点が最大になります。索引参照を使用して短いトランザクションを実行する純粋なOLTPデータベースでは、利点はそれほど大きくありません。
IM列ストアはOracle Databaseとシームレスに統合します。既存のすべてのデータベース機能(高可用性機能を含む)は、アプリケーションの変更を必要とせず、サポートされます。このため、IM列ストアを設定すると、既存の分析ワークロードと非定型問合せのパフォーマンスはただちに向上します。
Oracle OptimizerはIM列ストアに対応しており、OLTP問合せやDMLが行ストアに送信される際に、Oracle Databaseが分析問合せをIM列ストアにシームレスに送信することが可能です。
データ・ウェアハウジング環境に対してIM列ストアがもたらす利点は次のとおりです。
大量の行のスキャンと、=、<、>およびINなどの演算子を使用するフィルタの適用の高速化。
表中の列サブセットの問合せ(たとえば、100列から5つを選択する場合)の高速化。分析問合せのパフォーマンス高速化を参照してください。
小さなディメンション表上の述語を大規模なファクト表上のフィルタに変換することによる結合パフォーマンスの向上。ベクトル結合の使用による結合のパフォーマンス向上を参照してください。
VECTOR GROUP BY変換とベクトル配列処理の使用による効率的な集計。VECTOR GROUP BY変換の使用による集計の拡張を参照してください。
IM列ストア使用に伴う必要な索引、マテリアライズド・ビューおよびOLAPキューブの減少による、記憶域と処理オーバーヘッドの大幅な低下。
関連項目:
IM列ストアのその他の利点の詳細は、『Oracle Database概要』を参照してください。
分析問合せのパフォーマンス高速化
列形式を使用してデータをメモリーに格納すると、大量データの分析の際のスループットを高速化できます。これは、予期しないアクセス・パターンでの非定型問合せで有効です。列形式は、大部分の数値および短い文字列のデータ型で、固定幅の列を使用します。これにより、問合せに迅速に応答する、非常に高速なベクトル処理が可能になります。データ行全体ではなく、固有のデータ分析タスクが必要な列のみがスキャンされます。
データはリアルタイムに分析できるため、異なる可能性を探って、繰返しを実行できます。IM列ストアを使用すると、問合せ結果を取得するために作成するOLAPキューブが少なくてすみます。
たとえば、今年のカリフォルニア州での売上の数値が必要だとします。このデータは、SALES表に格納されています。この表がIM列ストアに格納されている場合、データベースはState列のみをスキャンして、州がカリフォルニアである発生の数をカウントします。
ベクトル結合の使用による結合のパフォーマンス向上
IM列ストアは、ベクトル結合の利点を活用します。ベクトル結合は、小さなディメンション表上の述語を大規模なファクト表上のフィルタに変換して、結合を高速化します。1つの大きなファクト表で複数ディメンションの結合を実行する場合に有効です。ファクト表のディメンション・キーには、繰返しの値が数多くあります。スキャンのパフォーマンスと繰返し値の最適化により結合の速度は向上します。
VECTOR GROUP BY変換の使用による集計の拡張
分析の重要な側面は、データの集計によって、パターンと傾向を判断することです。データがIM列ストアに格納されていると、集計と複合的なSQL問合せはより高速に実行されます。
VECTOR GROUP BY変換は、効率的なインメモリー配列ベースの集計を可能にします。ファクト表のスキャンの際、集計値はインメモリー配列に蓄積され、効率的なアルゴリズムで集計が実行されます。主キーと外部キーの関係に基づく結合の実行が、スター・スキーマとスノーフレーク・スキーマの両方に対して最適化されます。
関連項目:
既存のデータベースでも、作成予定の新規データベースでも、列形式を使用してIM列ストアにデータを格納することができます。IM列ストアは設定が簡単で、既存のアプリケーションに影響しません。要件により異なりますが、1つ以上の表領域、表、マテリアライズド・ビューまたはパーティションをメモリーに格納するように構成できます。
関連項目:
IM列ストアの構成の詳細は、『Oracle Database管理者ガイド』を参照してください。
IM列ストアにデータを格納する方法:
結合は、データ・ウェアハウジング・ワークロードの不可欠な一部です。結合される表がメモリーに格納されている場合、IM列ストアにより結合のパフォーマンスが向上します。ブルーム・フィルタを使用する単純な結合と、複数の表の間の複合的な結合は、IM列ストアの使用により改善されます。データ・ウェアハウジング環境で最も頻繁に使われる結合は、1つ以上のディメンション表がファクト表に結合される場合です。
次の種類の結合は、結合される表がIM列ストアに格納されている場合、より高速に実行されます。
ブルーム・フィルタを使用できる結合
複数の小規模なディメンション表の、1つのファクト表への結合
PK-FK関係を持っている2つの表の間の結合
ベクトル結合を使用すると、IM列ストアは、結合を含む問合せを、より効率的で高速に実行できます。ベクトル結合を使用すると、Oracle Databaseで、高速スキャンとIM列ストアのベクトル処理能力の両方を活用できます。ベクトル結合は、ディメンション表とファクト表の間の結合を、ファクト表のスキャンの一部として適用可能なフィルタに変換します。この結合変換はブルーム・フィルタを使用して実行され、それによりOracle Databaseでのハッシュ結合のパフォーマンスが向上します。ブルーム・フィルタはIM列ストアとは独立ですが、SIMDベクトル処理を介して、メモリー内に格納されているデータに、非常に効率的に適用できます。
CUSTOMERSディメンション表とSALESファクト表の結合を実行する次の問合せを想定します。
SELECT c.customer_id, s.quantity_sold, s.amount_sold FROM CUSTOMERS c, SALES s WHERE c.customer_id = s.customer_id AND c.country_id = 'FR';
両方の表がIM列ストアに格納されている場合、SIMDベクトル処理を使用して、高速にデータをスキャンし、フィルタを適用します。図2-4 に、ベクトル結合のグラフィック表現を使用した問合せの実装のようすを示します。CUSTOMERS表の述語、c.country_id='FR'は、SALESファクト表上のフィルタに変換されます。フィルタはcountry_id='FR'です。SALES表が列形式を使用してメモリー内に格納されているため、この問合せの結果を決定するためにスキャンする必要がある列は1つのみです。
大きな表の自動キャッシングは、インメモリー・パラレル問合せのパフォーマンスを向上させます。表がメモリー内におさまらない場合、データベースはアクセス・パターンに基づいてキャッシュに格納するバッファを決定します。大きな表がバッファ・キャッシュに完全におさまらない場合も、これにより効率的なキャッシュが可能になります。
表スキャンのデータを格納するためにはバッファ・キャッシュのオプションの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およびパーティショニング・ガイド』を参照してください。
インメモリー集計は、データを集計し、1つ以上の比較的小さな表を大きな表に結合する問合せのパフォーマンスを向上させるために、VECTOR GROUP BY操作を使用します。これはスター・クエリーにおいてしばしば発生する状況です。VECTOR GROUP BYは、SQLオプティマイザによって、コスト見積もりに基づいて選択されます。これは、問合せがインメモリー列表からSELECTし、その表に一意または数値の結合キーが含まれる際により多く発生します(主キー、一意性制約またはスキーマ設計による強制的な一意性かどうかは関係ありません)。
関連項目:
インメモリー集計のしくみの詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。
VECTOR GROUP BY集計は、GROUP BYによってのみ選択されます。GROUP BY ROLLUP、GROUPING SETSまたはCUBEには選択されません。
注意:
(この機能は、Oracle Database 12cリリース1(12.1.0.2)以上で使用できます。)
次のトピックでは、インメモリー集計に関する詳細情報を示します。
VECTOR GROUP BY集計を使用することが、すべての問合せとシナリオで有効なわけではありません。次の項は、この集計の使用が有効である状況に関するガイドラインです。
VECTOR GROUP BY集計が有効な状況
VECTOR GROUP BY集計は、次のシナリオで有効です。
スキーマが、多くの場合、ファクトとディメンションを結合するために使用される列の一意キーまたは数値キーを含んでいる。主キー、一意性制約またはスキーマ設計を使用して一意性を強制することができます。
ファクト表が、ディメンションより10倍以上大きい。
IM列ストアが、ディメンションとファクト表をメモリー内に格納するために使用されている。
VECTOR GROUP BY集計が不利な状況
次のシナリオでは、VECTOR GROUP BY集計を使用しても、実質的なパフォーマンス上の利点がありません。
2つの非常に大きな表の間で結合が実行される。
デフォルトでは、VECTOR GROUP BY変換はファクト表がディメンションより10倍以上大きな場合のみ使用されます。
ディメンションに、20億以上の行が含まれる。
ディメンションに20億以上の行が含まれる場合、VECTOR GROUP BY変換は使用されません。
システムに十分なメモリー・リソースがない。
IM列ストアを使用するシステムの大部分では、VECTOR GROUP BY変換の使用が有効です。
VECTOR GROUP BY集計はOracle Optimizerと統合されており、この変換を使用できるようにするために、新しいSQLパラメータや初期化パラメータは必要ありません。また、追加の索引、外部キーまたはディメンションも不要です。
デフォルトでOracle Databaseは、問合せに対してVECTOR GROUP BY集計を使用するべきかどうかを、この問合せに対して決定されている他の実行計画と比較したコストに基づいて決定します。ただし、問合せブロックのヒントまたは表ヒントを使用して、問合せに対してVECTOR GROUP BY集計を使用するようにデータベースに指示できます。
VECTOR GROUP BY集計は、複数のファクト表から導き出されるファクト・ビューを使用する問合せを処理するために使用できます。
Oracle Databaseは、次の条件が満たされた場合、VECTOR GROUP BY集計を使用してデータ集計を実行します。
問合せまたは副問合せは、ファクト表からのデータを集計し、ファクト表を1つ以上のディメンションに結合します。
これらのファクト表が結合のみを介してディメンションに接続されているという想定では、同じディメンションに結合された複数のファクト表もサポートされます。この場合、VECTOR GROUP BYはファクト表を別々に集計し、グループ化キー上で結果を結合します。
ディメンションとファクト表は、結合列を介してのみ互いに接続されます。
特に、問合せには、複数のディメンションを通じて、またはディメンションとファクト表から、列を参照する述語が他にないようにする必要があります。問合せが2つ以上の表の間の結合を実行し、結果をファクトに結合する場合、VECTOR GROUP BY集計は、複数のディメンションを1つのディメンションとみなします。
VECTOR GROUP BY集計のパフォーマンスが最高になるのは、結合される表がIM列ストアに格納されている場合です。
VECTOR GROUP BY集計は、次の場合をサポートしていません。
複数のディメンションの間、またはディメンションとファクト表の間の半結合と逆結合
複数のディメンション間の等価結合。
DISTINCTを使用して実行される集計
ブルーム・フィルタ
VECTOR GROUP BY集計とブルーム・フィルタは排他的です。
ブルーム・フィルタを使用して問合せが実行される場合、VECTOR GROUP BY集計はこの問合せの処理に適用できません。
