| Oracle Databaseデータ・ウェアハウス・ガイド 11gリリース1（11.1） E05763-01 |
|
 前へ |
 次へ |
この章では、データ・ウェアハウス環境の物理設計について説明します。内容は次のとおりです。
論理設計とは、データ・ウェアハウスを作成する前に、ペンと紙で描画したり、Oracle Warehouse BuilderまたはOracle Designerで設計することです。物理設計とは、SQL文でデータベースを作成することです。
物理設計では、論理設計時に収集したデータを、物理データベース構造の記述に変換します。物理設計上の決定事項には、主に問合せのパフォーマンスやデータベースのメンテナンスが影響します。たとえば、問合せ要件に適したパーティション化を行うと、実行前に検索対象を絞り込むパーティション・プルーニングをOracle Databaseで活用できます。
|
関連項目:
|
論理設計の段階で、エンティティ、属性およびリレーションシップで構成されるデータ・ウェアハウスのモデルが定義されています。エンティティは、リレーションシップを使用して相互にリンクされます。属性は、エンティティの説明に使用します。一意識別子（UID）により、エンティティの1つのインスタンスとその他のインスタンスが区別されます。
図3-1に論理設計と物理設計の違いを示します。
物理設計では、必要となるスキーマを実際のデータベース構造に変換します。ここで、次のマッピングを行う必要があります。
エンティティから表へ
リレーションシップから外部キー制約へ
属性から列へ
1次一意識別子から主キー制約へ
一意識別子から一意キー制約へ
論理設計を物理設計に変換した後に、次の一部またはすべての構造を作成する必要があります。
これらの構造の中には、ディスク領域を必要とするものがあります。データ・ディクショナリにのみ存在するものもあります。また、パフォーマンス改善のために次の構造を作成できます。
表領域は、使用中のオペレーティング・システム内の物理構造である1つ以上のデータファイルで構成されます。データファイルは、1つの表領域にのみ対応付けられています。設計の観点からは、表領域は物理設計構造のコンテナです。
表領域は、相違点によって分離する必要があります。たとえば、表と索引、小規模な表と大規模な表は分離する必要があります。また、表領域は、可能であれば論理的なビジネス・ユニットを表す必要があります。表領域は、バックアップやリカバリ、またはトランスポータブル表領域メカニズムのための最も大きな単位であるため、論理的なビジネス設計は可用性とメンテナンス操作に影響します。
現在では、巨大なデータファイルを使用でき、非常に大きなデータベースでのパフォーマンスが大幅に改善されています。
表は、基本的なデータ格納単位であり、データ・ウェアハウス内で予測された量の生データのコンテナです。
表を、より小さく管理しやすいサイズに分割したパーティション表にすることにより、大量のデータをサポートする際の主要な問題に対処できます。パーティション化の主な設計基準は管理のしやすさですが、ほとんどの場合、パーティション・プルーニングやインテリジェントなパラレル処理により、パフォーマンスも向上します。たとえば、受注取引日に基づいて月毎にパーティション化できます。4年分のデータがある場合も、単一の高速なDDL文を使用して4年以上経過したデータを月単位で順次削除し、新しいデータをロードできます。このとき影響が及ぶのは表全体の1/48のみです。最終の四半期に関するビジネスの問合せが影響するのはたった3か月分（3パーティション分）、つまり全体の3/48となります。
大規模な表をパーティション化すると、各パーティションの管理がさらに簡単になるため、パフォーマンスが向上します。通常、データ・ウェアハウス内のトランザクションの日付（月ごとなど）に基づいてパーティション化を行います。たとえば、毎月、1か月分のデータを独自のパーティションに割り当てることができます。
ヒープ構成表を圧縮することにより、ディスク領域を節約できます。表の圧縮を考慮する必要がある典型的なヒープ構成表タイプは、パーティション表です。
ディスクの使用とメモリーの使用（具体的にはバッファ・キャッシュ）を削減するために、表およびパーティション表をデータベース内に圧縮形式で格納できます。多くの場合、これにより、読取り専用操作のスケールアップを図れます。表の圧縮により、問合せの実行速度も向上できます。ただし、代償としてCPUオーバーヘッドが増加します。
表の圧縮は、冗長性の高いデータ（多数の外部キーを持つ表など）で使用します。更新やその他のDMLアクティビティが頻繁に発生する表の圧縮は避けてください。圧縮されている表やパーティションは更新可能ですが、このような表の更新にはオーバーヘッドが発生し、頻繁な更新アクティビティで領域が浪費されて圧縮の妨げになる場合があります。
ビューは、1つ以上の表または他のビューに含まれるデータが、整形された形で表されているものです。ビューにより、問合せの出力が表として処理されます。データベースの領域は必要としません。
|
関連項目: 『Oracle Database概要』 |
整合性制約は、データベースに関連したビジネス・ルールを規定し、表中の無効な情報を防止するために使用されます。データ・ウェアハウスにおける整合性制約は、OLTP環境における制約とは異なります。OLTP環境では、主として無効なデータがレコードに挿入されるのを防止しますが、データ・ウェアハウス環境では、正確さがすでに保証されているため、これは大きな問題ではありません。データ・ウェアハウス環境では、制約はクエリー・リライトにのみ使用されます。NOT NULL制約は、データ・ウェアハウスでは特に一般的です。ある特定の状況では、制約はデータベースの領域を必要とします。このような制約は、基礎となる一意索引の形式になっています。
索引は、表またはクラスタに関連付けられたオプションの構造体です。データ・ウェアハウス環境では、従来のBツリー索引に加えて、ビットマップ索引がきわめて一般的です。ビットマップ索引は、セット指向の操作に最適化された索引構造です。また、スター型変換など、最適化された一部のデータ・アクセス方法にも必要になります。
索引は、パーティション化できるという点では表と同じですが、パーティション化方法は表の構造に依存しません。索引をパーティション化すると、リフレッシュ時にデータ・ウェアハウスを管理しやすくなり、問合せのパフォーマンスが改善されます。
マテリアライズド・ビューには、実行に時間のかかるSQL文の計算が不要になるように、事前の問合せ結果が格納されています。物理設計の観点からすると、マテリアライズド・ビューは表やパーティション表に似ており、透過的に使用されパフォーマンスが向上するという点で、索引のような動作をします。
ディメンションは、列または列セット間の階層関係を定義するスキーマ・オブジェクトです。階層関係とは、階層内のあるレベルのデータが次のレベルのどのデータに結びつくかという依存関係を指します。ディメンションは論理関係のコンテナであり、データベースに領域を必要としません。典型的なディメンションには、市、州（または県）、地域および国などがあります。
