3 データ・ウェアハウスの物理設計
この章では、データ・ウェアハウス環境の物理設計について説明します。内容は次のとおりです。
3.1 論理設計から物理設計への変換
論理設計とは、データ・ウェアハウスを作成する前に、設計を紙に書いたり、Oracle Designerなどのツールで設計したりすることです。物理設計とは、SQL文でデータベースを作成することです。
物理設計では、論理設計時に収集したデータを、物理データベース構造の記述に変換します。物理設計上の決定事項には、主に問合せのパフォーマンスやデータベースのメンテナンスが影響します。たとえば、問合せ要件に適したパーティション化を行うと、実行前に検索対象を絞り込むパーティション・プルーニングをOracle Databaseで活用できます。
関連項目:
-
パーティション化の詳細は、Oracle Database VLDBおよびパーティショニング・ガイドを参照してください。
-
設計事項の概念情報の詳細は、Oracle Database概要を参照してください。
3.2 物理設計について
論理設計の段階で、エンティティ、属性およびリレーションシップで構成されるデータ・ウェアハウスのモデルが定義されています。エンティティは、リレーションシップを使用して相互にリンクされます。属性は、エンティティの説明に使用します。一意識別子(UID)により、エンティティの1つのインスタンスとその他のインスタンスが区別されます。
図3-1に論理設計と物理設計の違いを示します。
物理設計では、必要となるスキーマを実際のデータベース構造に変換します。ここで、次のマッピングを行う必要があります。
-
エンティティから表へ
-
リレーションシップから外部キー制約へ
-
属性から列へ
-
1次一意識別子から主キー制約へ
-
一意識別子から一意キー制約へ
3.2.1 物理設計の構造
論理設計を物理設計に変換するには、表領域、表、(表または索引構成表の)パーティション、索引(パーティション索引を含む)、ビュー、整合性制約、マテリアライズド・ビューおよびディメンションといった構造の一部または全部を作成する必要があります。
3.2.1.1 データ・ウェアハウスの表領域について
表領域は、使用中のオペレーティング・システム内の物理構造である1つ以上のデータファイルで構成されます。データファイルは、1つの表領域にのみ対応付けられています。設計の観点からは、表領域は物理設計構造のコンテナです。
表領域は、相違点によって分離する必要があります。たとえば、表と索引、小規模な表と大規模な表は分離する必要があります。また、表領域は、可能であれば論理的なビジネス・ユニットを表す必要があります。表領域は、バックアップやリカバリ、またはトランスポータブル表領域メカニズムのための最も大きな単位であるため、論理的なビジネス設計は可用性とメンテナンス操作に影響します。
3.2.1.2 データ・ウェアハウスにおけるパーティション化について
Oracle Partitioningは、データ・ウェアハウジングの非常に重要な機能であり、管理性、パフォーマンスおよび可用性を改善します。この項では、パーティション化の重要な概念およびそのメリットについて、データ・ウェアハウスにとっての特別な意味に触れながら説明します。
パーティション化により、表、索引および索引構成表をより細かい単位に細分化できるようになります。データベース・オブジェクトの単位をパーティションと呼びます。各パーティションには独自の名前があり、独自の記憶特性を持つことができます。データベース管理者の視点からすると、パーティション・オブジェクトには、まとめて管理することも個別に管理することも可能な複数の単位があります。このため、管理者は、パーティション・オブジェクトをかなり柔軟に管理できます。ただし、ユーザーにとっては、パーティション表は非パーティション表と同じであるため、SQLおよびDMLコマンドを使用してパーティション表にアクセスする際に変更は必要ありません。
表、索引および索引構成表などのデータベース・オブジェクトは、パーティション化キーを使用してパーティション化されます。パーティション化キーは、指定された行がどのパーティションに存在するかを決定する、一連の列です。たとえば、売上表は月次のパーティション化方法を使用して売上日でパーティション化されています。この表は単一かつ通常の表としてどのアプリケーションにも表示されます。ただし、DBAは、場合によっては異なる記憶域の層を使用し、古いデータに対して表の圧縮を適用して各月次パーティションを個別に管理および格納したり、古いデータの領域全体を読取り専用表領域に保管できます。
3.2.1.2.1 データ・ウェアハウスで使用される基本的なパーティション化戦略
Oracle Partitioningには、様々な個別のパーティションに実際にデータを配置する方法を制御する、次の3つの基本的なデータ分散方法が用意されています。
-
範囲
データはパーティション化キーの値のレンジに基づいて分散されます(日付列がパーティション化キーの場合、January-2012パーティションには、パーティション化キーの値が01-JAN-2012と31-JAN-2012の間の行が含まれます)。データ分散は切れ目のない連続体であり、前のレンジの上限により、レンジの下限が自動的に定義されます。
-
リスト
データ分散は、パーティション化キーの値のリストによって定義されます(地方列がパーティション化キーの場合、
North_AmericaパーティションにはCanada、USAおよびMexicoが含まれます)。特別なDEFAULTパーティションを定義すると、リストで明示的に定義されていないパーティション・キーのすべての値を捕捉できます。 -
ハッシュ
ハッシュ・アルゴリズムは、特定行のパーティションを決定するため、パーティション化キーに対して適用されます。他の2つのデータ分散方法と異なり、ハッシュはデータとパーティション間のいかなる論理マッピングも提供しません。
これらの基本的な方法の他に、次の複数の方法が提供されています。
-
時間隔パーティション化
管理性を向上させるレンジ・パーティション化の拡張機能です。パーティションが等しい範囲の間隔で定義されます。最初のパーティションを除いたすべてのパーティションは、一致するデータの到着時に要求に応じて自動的に作成されます。
-
参照別のパーティション化
子表のパーティション化は、主キーと外部キーの関係を通し、親表から継承されます。パーティションのメンテナンスが簡略化され、パーティション・ワイズ結合が使用可能になります。
-
仮想列ベースのパーティション化
前述のパーティション技術のいずれか1つにより定義され、パーティション化キーは仮想列に基づきます。仮想列はディスクには格納されず、メタデータとしてのみ存在します。この方法により、ビジネス要件により柔軟かつ幅広く対応できます。
前述のデータ分散方法を使用して、単一またはコンポジット・パーティション表として表をパーティション化できます。
-
単一(1レベル)パーティション化
1つ以上の列をパーティション化キーとして使用し、データ分散方法のいずれかを指定することで表を定義します。たとえば、数値列をパーティション化キーとする表があるとします。2つのパーティション
less_than_five_hundredおよびless_than_thousandがあり、less_than_thousandパーティションには、500 <= Partitioning key <1000の条件が当てはまる行が含まれるとします。レンジ、リストおよびハッシュの各パーティション表を指定できます。
-
コンポジット・パーティション化
-
コンポジット・パーティション表の定義には、2つのデータ分散方法の組合せが使用されます。まず、データ配分方法1で表をパーティション化し、その後2つ目のデータ配分方法を使用して、各パーティションをさらに小さなサブパーティションに再分割します。特定のパーティションのサブパーティションをすべて組み合せて、データの論理サブセットを表します。たとえば、レンジ-ハッシュ・コンポジット・パーティション表は、最初にレンジ・パーティション化されます。その後、各レンジ・パーティションがハッシュ・パーティション化技術を使用して、さらにサブパーティション化されます。
関連項目:
-
ハイブリッド列圧縮の詳細は、『Oracle Database概要』を参照してください。
3.2.1.3 データ・ウェアハウスにおける索引のパーティション化
索引のパーティション化方法の選択に関係なく、基礎となる表のパーティション化方法により索引が結合されるか、結合解除されます。適切な索引パーティション化方法は、ビジネス要件に基づいて選択され、各種アプリケーションのサポートに最適なパーティション化を実現します。Oracle Database 12cでは3タイプのパーティション索引を区別します。
-
ローカル索引
ローカル索引は、パーティション表の索引であり、基礎となるパーティション表に結合され、表のパーティション化方法を継承します。そのため、ローカル索引の各パーティションは、基礎となる表の唯一のパーティションに対応します。結合により、パーティションのメンテナンスの最適化が可能です。たとえば、表のパーティションが削除された場合、Oracle Databaseではそれに対応する索引のパーティションを削除するだけで対応できます。費用のかかる索引のメンテナンスは必要ありません。データ・ウェアハウジング環境では、ローカル索引が最も一般的です。
-
グローバル・パーティション索引
グローバル・パーティション索引は、パーティション表または非パーティション表の索引であり、表とは異なるパーティション化キーまたはパーティション化方法でパーティション化されます。グローバル・パーティション索引では、レンジまたはハッシュの各パーティション化を使用してのパーティション化および基礎となる表との結合解除が可能です。たとえば、表を月別にレンジ・パーティション化し、12のパーティションを持たせることが可能ですが、その表の索引を別のパーティション化キーを使用してハッシュ・パーティション化し、異なる数のパーティションを持たせることが可能です。グローバル・パーティション索引は、データ・ウェアハウジング環境よりはOLTP環境で一般的です。
-
グローバル非パーティション索引
グローバル非パーティション索引は、基本的に非パーティション表の索引と同じものです。索引の構造はパーティション化されておらず、基礎となる表と結合されていません。データ・ウェアハウジング環境での、グローバル非パーティション索引の最も一般的な使用方法は、主キーの制約の施行です。
3.2.1.4 管理性のためのパーティション化について
管理性を向上させるための一般的なパーティション化の使用方法は、データ・ウェアハウスでローリング・ウィンドウ・ロード・プロセスをサポートすることです。DBAが新規データを日単位で表にロードするとします。各パーティションに1日分のデータが保存されるように、その表をレンジ・パーティション化できます。ロード・プロセスは単純に新しいパーティションを追加するだけです。DBAがその他のパーティションを変更する必要がないため、単一のパーティションの追加は、表全体を変更するよりはるかに効率的です。パーティション化を使用する別のメリットは、データを削除する場合にあります。この場合、パーティション全体の削除が可能で、各行を個別に削除する場合に比べて非常に効率的かつ高速です。
3.2.1.5 パフォーマンスのためのパーティション化について
調査または操作対象のデータ量を制限することで、パーティション化によりパフォーマンスに関連する多くの利点がもたらされます。次の2つの機能は特に注目に値します。
-
パーティション・プルーニング: パーティション・プルーニングは非常に簡単で、パーティション化を使用してパフォーマンスを向上するための最も実質的な方法でもあります。パーティション・プルーニングにより、問合せのパフォーマンスが大幅に向上します。たとえば、アプリケーションに注文の履歴レコードを含む
ORDERS表があり、この表が日ごとにパーティション化されているとします。1週間の注文をリクエストする問合せでは、ORDERS表の7つのパーティションにのみアクセスします。表に2年分の履歴データがある場合、この問合せでは730のパーティションではなく7つのパーティションにアクセスします。この問合せは、単純にパーティション・プルーニングの効果で、100倍高速に実行される可能性があります。パーティション・プルーニングは、Oracle製品のその他すべてのパフォーマンス機能と連携します。パーティション・プルーニングは、索引や結合の技術またはパラレル・アクセスの手法と組み合せて使用されます。 -
パーティション・ワイズ結合: パーティション化では、パーティション・ワイズ結合と呼ばれる技術が使用され、複数表の結合のパフォーマンスも向上します。パーティション・ワイズ結合は、2つの表を結合する際、少なくとも表の1つが結合キーでパーティション化される場合に適用できます。パーティション・ワイズ結合では、大きな結合が結合された表と同一のデータセットの小さな結合に分割されます。ここでいう同一とは、まったく同一である一連のパーティション化キー値を結合の両側で扱うということです。こうすることにより、これら同一のデータセットの結合のみが結果を生成し、他のデータセットを考慮する必要がないことが保証されます。すでに(物理的に)等しくパーティション化されている結合の表のファクトを使用するか、あるいは実行時に1つの表を透過的に再分割する(再パーティション化する)ことにより、他の表のパーティションに一致する等パーティション化データセットが作成され、全体的な結合が少ない時間で完了します。これにより、シリアル実行およびパラレル実行の両方でパフォーマンスが大幅に向上します。
3.2.1.6 可用性のためのパーティション化について
パーティション化データベース・オブジェクトにより、パーティションの独立性が実現されます。パーティションの独立性のこの特性は、高可用性計画の重要な要素の一部です。たとえば、パーティション表の1つのパーティションが使用できなくなっても、その表のその他すべてのパーティションはオンラインで使用可能なままです。アプリケーションは、そのパーティション表に対して問合せやトランザクションを実行し続けることができ、使用できないパーティションにアクセスする必要がなければ、それらのデータベース操作は正常に実行されます。データベース管理者は、各パーティションが別々の表領域に格納されるよう指定できます。これにより、表内の他のパーティションとは無関係に、個別のパーティションまたは一連のパーティションでのバックアップおよびリカバリ操作が可能になります(パーティションと表領域のマッピングによる)。したがって、万一障害の場合でも、アクティブ・データを構成するパーティションのみでデータベースのリカバリが可能です。その後、都合のよいときに他のパーティションにある非アクティブのデータをリカバリでき、システムの停止時間を削減できます。管理性、パフォーマンスおよび可用性の各メリットを考慮すると、あらゆるデータ・ウェアハウスで採用する必要があります。
3.2.2 データ・ウェアハウスでのビューについて
ビューは、1つ以上の表または他のビューに含まれるデータが、整形された形で表されているものです。ビューは、問合せの出力を取得し、表として処理します。データベースの領域は必要としません。
関連項目:
3.2.3 データ・ウェアハウスでの整合性制約について
整合性制約は、データベースに関連したビジネス・ルールを規定し、表中の無効な情報を防止するために使用されます。データ・ウェアハウスにおける整合性制約は、OLTP環境における制約とは異なります。OLTP環境では、主として無効なデータがレコードに挿入されるのを防止しますが、データ・ウェアハウス環境では、正確さがすでに保証されているため、これは大きな問題ではありません。データ・ウェアハウス環境では、制約はクエリー・リライトにのみ使用されます。NOT NULL制約は、データ・ウェアハウスでは特に一般的です。ある特定の状況では、制約はデータベースの領域を必要とします。このような制約は、基礎となる一意索引の形式になっています。
関連項目:
3.2.4 データ・ウェアハウスでの索引およびパーティション化索引について
索引は、表またはクラスタに関連付けられたオプションの構造体です。データ・ウェアハウス環境では、従来のBツリー索引に加えて、ビットマップ索引がきわめて一般的です。ビットマップ索引は、セット指向の操作に最適化された索引構造です。また、スター型変換など、最適化された一部のデータ・アクセス方法にも必要になります。
索引は、パーティション化できるという点では表と同じですが、パーティション化方法は表の構造に依存しません。索引をパーティション化すると、リフレッシュ時にデータ・ウェアハウスを管理しやすくなり、問合せのパフォーマンスが改善されます。
3.2.5 データ・ウェアハウスでのマテリアライズド・ビューについて
マテリアライズド・ビューには、実行に時間のかかるSQL文の計算が不要になるように、事前の問合せ結果が格納されています。物理設計の観点からすると、マテリアライズド・ビューは表やパーティション表に似ており、透過的に使用されパフォーマンスが向上するという点で、索引のような動作をします。
関連項目:
3.2.6 データ・ウェアハウスでのディメンションについて
ディメンションは、データを分類する1つの構造であり、1つ以上の階層から構成されています。ディメンション属性を使用して、ディメンション値を記述できます。通常、ディメンションは説明的なテキスト値です。ファクトと結合した複数の独立したディメンションにより、ビジネス上の問題に対応できます。最も一般的なディメンションは、顧客(customers)、製品(products)および時間(times)です。
ディメンション・スキーマ・オブジェクトは、列または列セット間の階層関係を定義します。階層関係とは、階層内のあるレベルのデータが次のレベルのどのデータに結びつくかという依存関係を指します。ディメンション・オブジェクトは論理関係のコンテナであり、データベースに領域を必要としません。典型的なディメンションには、市、州(または県)、地域および国などがあります。
ディメンション・データは、通常、詳細な最下位レベルで収集されてから、分析に有効な上位レベルの合計に集計されます。このようなディメンション表内でのロールアップまたは集計を階層と呼びます。
この項では、次の項目について説明します。
3.2.6.1 ディメンション階層について
階層は、データを構成する順序付けられたレベルを使用する論理構造です。階層は、データ集計の定義に使用できます。たとえば、時間ディメンションであれば、月レベルから四半期レベル、さらに年レベルへとデータを集計する階層を定義できます。階層は、ナビゲーショナル・ドリル・パスの定義およびファミリ構造の作成にも使用できます。
階層内では、各レベルがその上下のレベルと論理的に接続されます。下位レベルのデータ値は、上位レベルのデータ値に集計されます。ディメンションは複数の階層で構成できます。たとえば、製品ディメンションには、2つの階層(製品カテゴリおよび製品仕入先)がある場合があります。
また、ディメンション階層は、要約レベルから詳細レベルまでカテゴリ化されます。階層は、問合せツールによって使用されます。これにより、データをドリルダウンし、詳細度の異なるレベルを参照できるようになります。これは、データ・ウェアハウスの主なメリットの1つです。
階層を設計する場合は、ビジネス構造におけるリレーションシップを考慮する必要があります。たとえば、多階層の部門を持つ販売組織では、構造が複雑になりがちです。
階層では、ディメンション値はファミリ構造で表現されます。あるレベルの値に対して、1つ上のレベルの値はその親になり、1つ下のレベルの値はその子になります。これらのファミリ関係によって、アナリストはデータに迅速にアクセスできます。
関連項目:
