10gリリース2（10.2）
B19215-02
 目次 |
 索引 |
| Oracle Database 概要 10gリリース2（10.2） B19215-02 |
|
この章では、ビジネス・インテリジェンスの基本概念について説明します。
この章の内容は、次のとおりです。
データ・ウェアハウスは、トランザクション処理ではなく問合せおよび分析用に設計されたリレーショナル・データベースです。通常は、トランザクション・データから導出された履歴データが格納されますが、他のソースからのデータも格納できます。データ・ウェアハウスにより、分析のワークロードがトランザクションのワークロードから分離され、組織は複数のソースからのデータを連結できます。
データ・ウェアハウス環境には、リレーショナル・データベースの他に、ETLソリューション、オンライン分析処理（OLAP）エンジン、クライアント分析ツール、データを収集してビジネス・ユーザーに配信するプロセスを管理する他のアプリケーションがあります。
データ・ウェアハウスを紹介する一般的な方法として、William Inmonが規定したデータ・ウェアハウスの特性について触れておきます。
データ・ウェアハウスは、データの分析に役立つように設計されています。たとえば、会社の売上データの詳細を知るために、売上専用のウェアハウスを構築できます。このウェアハウスを使用すると、「昨年度のこの品目の最大顧客は?」などの質問に答えることができます。このようにデータ・ウェアハウスは主題（この場合は売上）別に定義できるため、データ・ウェアハウスはサブジェクト指向となっています。
統合は、サブジェクト指向に密接に関連しています。データ・ウェアハウスには、様々なソースからのデータを一貫性のある形式で格納する必要があります。また、名前の競合や単位間の不一致などの問題を解決する必要があります。このような問題が解決されて初めて、統合が完了したことになります。
恒常的とは、一度ウェアハウスに格納されたデータは変更されないことを意味します。ウエアハウスの目的が、発生した事柄を分析できることであるため、これは論理的です。
アナリストは、ビジネスの傾向を把握するために大量のデータを必要とします。これは、パフォーマンス要件があるために履歴データをアーカイブに移動する必要のあるオンライン・トランザクション処理（OLTP）システムとはきわめて対照的です。データ・ウェアハウスは時間経過による変化に焦点を当てており、これこそは時系列が意味するものです。
一般に、1つ以上のオンライン・トランザクション処理（OLTP）データベースからデータ・ウェアハウスに、月次、週次または日次でデータが送信されます。データは、通常ステージング・ファイル内で処理されてから、データ・ウェアハウスに追加されます。データ・ウェアハウスのサイズは、数十GBから数TBになるのが普通です。また、データの大多数は少数の非常に大きなファクト表に格納されます。
データ・ウェアハウスとOLTPシステムでは、要件が大きく異なります。ここでは、典型的なデータ・ウェアハウスとOLTPシステムの相違点の例を示します。
データ・ウェアハウスは非定型問合せに適応するように設計されています。データ・ウェアハウスのワークロードは事前に不明な場合があります。このため、データ・ウェアハウスは様々な問合せ操作を適切に実行できるように最適化する必要があります。
OLTPシステムでサポートされるのは、事前定義済の操作のみです。これらの操作のみをサポートするように、アプリケーションの特別なチューニングや設計が必要になる場合があります。
データ・ウェアハウスは、バルク・データ修正テクニックを使用して（夜間または週次で実行される）ETLプロセスにより定期的に更新されます。データ・ウェアハウスをエンド・ユーザーが直接更新することはありません。
OLTPシステムでは、エンド・ユーザーはデータベースに対して個々のデータ修正文を定期的に発行します。OLTPデータベースは常に最新であり、各ビジネス・トランザクションの現在の状態が反映されます。
通常、データ・ウェアハウスでは、全体または一部が非正規化されたスキーマ（スター・スキーマなど）を使用して、問合せパフォーマンスが最適化されます。
OLTPシステムでは、通常は完全に正規化されたスキーマを使用して更新/挿入/削除のパフォーマンスが最適化され、データ整合性が保証されます。
典型的なデータ・ウェアハウスの問合せでは、数千または数百万行がスキャンされます。たとえば、「すべての顧客について先月の総売上を検索する」などです。
典型的なOLTP操作は、少数のレコードにのみアクセスします。たとえば、「この顧客の現行の注文を検索する」などです。
通常、データ・ウェアハウスには、数か月または数年分のデータが格納されます。これは、履歴分析をサポートするためです。
OLTPシステムには、通常は数週または数か月分のデータしか格納されません。OLTPシステムでは、現行のトランザクションの要件を適切に満たすために必要な履歴データのみが格納されます。
データ・ウェアハウスとそのアーキテクチャは、組織の状況に応じて異なります。次の3つのアーキテクチャが一般的です。
図16-1に、データ・ウェアハウスの単純なアーキテクチャを示します。エンド・ユーザーは、データ・ウェアハウスを介して、複数のソース・システムから導出されたデータに直接アクセスします。
図16-1では、従来型OLTPシステムのメタデータと生データの他に、サマリー・データがあります。サマリーでは、時間のかかる処理が事前に行われるため、データ・ウェアハウスではきわめて重要です。たとえば、典型的なデータ・ウェアハウスの問合せでは、8月の売上などが検索されます。
Oracleでは、サマリーはマテリアライズド・ビューと呼ばれます。
図16-1では、業務系データをウェアハウスに入れる前に、クリーン・アップおよび処理する必要があります。この操作はプログラムによって実行できますが、ほとんどのデータ・ウェアハウスではかわりにステージング領域が使用されています。ステージング領域により、サマリーの作成とウェアハウス管理全般が簡素化されます。図16-2に、この典型的なアーキテクチャを示します。
図16-2のアーキテクチャはごく一般的ですが、ウェアハウスのアーキテクチャを組織内の様々なグループ向けにカスタマイズできます。
そのためには、特定のビジネス・ライン向けに設計されたシステムであるデータ・マートを追加します。図16-3に、購買、売上および在庫が分離されている例を示します。この例では、財務アナリストは購買と売上の履歴データを分析できます。
ビジネス分析を容易にするという目的を果たせるように、データ・ウェアハウスを定期的にロードする必要があります。そのためには、1つ以上のオペレーティング・システムからデータを抽出し、ウェアハウスにコピーする作業が必要です。ソース・システムからデータを抽出してデータ・ウェアハウスに取り込む処理は、一般にETLと呼ばれ、抽出、変換、ロードを表します。ETLでは転送フェーズが省略され、プロセスの他のフェーズがそれぞれ個別であることを意味するため、ETLという頭字語ではあまりに単純すぎるでしょう。つまり、ETLはデータのロードを含むプロセス全体を指します。ETLが詳細に定義された3つのステップではなく広範囲なプロセスを指すことを理解しておく必要があります。
ETLの方法論とタスクは以前からよく知られており、必ずしもデータ・ウェアハウス環境に固有のものではありません。様々な独自アプリケーションおよびデータベース・システムが、企業のITのバックボーンとなっています。データの統合を試み、少なくとも2つのアプリケーションに同じ内容を提供して、アプリケーション間やシステム間で共有する必要があります。このようなデータ共有は、ETLに似たメカニズムでほとんど対処されています。
データ・ウェアハウス環境は同じ課題に直面しているのに加えて、データを多数のシステム間で交換するのみでなく、統合、再配置および連結する必要があり、それによりビジネス・インテリジェンスに新たに統一された情報ベースを提供するという問題を抱えています。また、データ・ウェアハウス環境ではデータ量が非常に大きくなる傾向があります。
ETLプロセスでどのような処理が発生するかを考えてみます。抽出時には必要なデータが識別され、データベース・システムやアプリケーションなど多数の異なるソースから抽出されます。通常、必要なデータの特定のサブセットを識別することはできません。したがって、必要以上のデータを抽出することになるため、該当データの識別は後に行われます。ソース・システムの機能（オペレーティング・システムのリソースなど）によっては、この抽出プロセスである程度の変換が発生することがあります。抽出されるデータのサイズは、ソース・システムとビジネス状況に応じて数百KB〜数GBです。2つの（論理的に）同一の抽出間に要する時間についても、同じことが言えます。つまり、期間は数日、数時間、数分、ほぼリアルタイムなど様々です。たとえば、Webサーバーのログ・ファイルは、きわめて短時間のうちに簡単に数百MBに達することがあります。
抽出したデータは、さらに処理するためにターゲット・システムまたは中間システムに物理的に転送する必要があります。選択した転送方法によっては、このプロセスでなんらかの変換処理を実行することもできます。たとえば、ゲートウェイを介してリモート・ターゲットに直接アクセスするSQL文では、SELECT文の一部として2つの列を連結できます。
ロード中にエラーが発生すると、そのエラーがログに記録され、操作を続行できます。
トランスポータブル表領域は、2つのOracleデータベース間で大量のデータを移動する場合に最も高速な方法です。異なるコンピュータ・アーキテクチャやオペレーティング・システム間で表領域を転送することもできます。
従来、最もスケーラブルなデータ転送メカニズムでは、生データを含むフラット・ファイルを移動していました。この種のメカニズムでは、データをソース・データベースからアンロードするかファイルにエクスポートし、転送後にターゲット・データベースにロードまたはインポートする必要がありました。トランスポータブル表領域は、このアンロードしてから再ロードするステップを完全にバイパスします。
トランスポータブル表領域を使用すると、Oracleデータファイル（表データ、索引および他のほぼすべてのOracleデータベース・オブジェクトを含む）を、データベース間で直接転送できます。さらに、トランスポータブル表領域は、データ転送に加えてメタデータの転送用に、インポートおよびエクスポートに似たメカニズムを提供します。
データ・ウェアハウスのトランスポータブル表領域が最も一般的に利用されるのは、ステージング・データベースからデータ・ウェアハウスへとデータを移動する場合、またはデータ・ウェアハウスからデータ・マートにデータを移動する場合です。
テーブル・ファンクションは、PL/SQL、CまたはJavaで実装された変換のパイプライン実行とパラレル実行をサポートします。前述の使用例では、中間のステージング表を使用する必要がありません。中間のステージング表を使用すると、各種の変換ステップを経るデータ・フローが中断されます。
テーブル・ファンクションは、出力としてテーブル・ファンクションを生成する関数として定義されます。また、入力として行セットを使用することもできます。テーブル・ファンクションによりデータベース機能が拡張され、次の操作が可能になります。
テーブル・ファンクションは、システム固有のPL/SQLインタフェースを使用してPL/SQLで定義するか、Oracle Data Cartridge Interface（ODCI）を使用してJavaまたはCで定義できます。
外部表により、外部データを仮想表として使用できます。仮想表は、最初に外部データをデータベースにロードしなくても、パラレルで直接問い合せたり結合できます。これにより、SQL、PL/SQLおよびJavaを使用して外部データにアクセスできます。
外部表を使用すると、ロード・フェーズと変換フェーズをパイプライン処理できます。データ・ストリームを中断することなく、変換プロセスをロード・プロセスとマージできます。データベース内のデータに対してさらに比較や変換などの処理を実行するために、データベース内でステージングする必要がなくなります。たとえば、従来型ロードの変換機能を、外部表からのSELECTとともにダイレクト・パスINSERT AS SELECT文に使用できます。図16-4に、パイプライン処理の代表例を示します。
外部表と通常の表の重要な違いは、外部で構成された表が読取り専用であることです。つまり、外部表にはDML操作（UPDATE/INSERT/DELETE）を実行できず、索引を作成できません。
外部表はSQL*Loaderを補完するもので、外部ソース全体を既存のデータベース・オブジェクトと結合して複雑な方法で変換する環境や、外部データ・ボリュームが大きく1度しか使用されない環境で特に役立ちます。これに対してSQL*Loaderは、ステージング表で追加の索引付けが必要となるデータをロードする場合に、より適切な選択肢となります。これは、データが独立した複雑な変換に使用される操作や、以降の処理でデータの一部のみが使用される操作の場合も同様です。
ヒープ構成表を圧縮することでディスク領域を節約できます。表の圧縮を考慮する必要のある典型的なタイプのヒープ構成表は、パーティション表です。
ディスク使用量とメモリー使用量（特にバッファ・キャッシュ）を減少させるために、表とパーティション表をデータベースに圧縮形式で格納できます。通常は、これにより読取り専用操作のパフォーマンスが向上します。また、問合せの実行も高速化されます。ただし、CPUオーバーヘッドの面で少しコストがかかります。
表の圧縮は、多数の外部キーを持つ表など、冗長度の高いデータに使用する必要があります。更新や他のDMLアクティビティが多い表は圧縮しないでください。圧縮された表またはパーティションは更新可能ですが、この種の表の更新時にオーバーヘッドが発生し、更新アクティビティが高いときには領域が多少浪費されて圧縮の妨げとなる場合があります。
チェンジ・データ・キャプチャにより、Oracleリレーショナル表に対して追加、更新または削除されたデータが効率的に識別および取得され、変更データがアプリケーションで使用可能になります。
通常、データ・ウェアハウスでは、分析のためにリレーショナル・データを1つ以上のデータベースからデータ・ウェアハウスに抽出して転送する必要があります。チェンジ・データ・キャプチャにより、表全体ではなく変更があったデータのみがすばやく識別され、処理されて、変更データが後で使用できるようになります。
チェンジ・データ・キャプチャは、リレーショナル・データベースの外部でデータを段階的に処理するための中間フラット・ファイルに依存しません。ユーザー表に対するINSERT、UPDATEおよびDELETE操作からの変更データを取得します。変更データはチェンジ・テーブルと呼ばれるデータベース・オブジェクトに格納され、制御された方法でアプリケーションで使用可能になります。
データ・ウェアハウスでパフォーマンス改善のために採用されているテクニックの1つは、サマリーを作成することです。サマリーは特殊な集計ビューで、問合せを実行する前に高コストの結合および集計操作を計算して結果をデータベースの表に格納することで、問合せの実行時間を短縮します。たとえば、地域別、製品別の売上合計を含む表を作成できます。
このマニュアルとデータ・ウェアハウス関連書で言及しているサマリーまたは集計は、Oracleではマテリアライズド・ビューというスキーマ・オブジェクトを使用して作成されます。マテリアライズド・ビューは、問合せパフォーマンスの改善や複製データの提供など、様々な役割を果たします。
従来、サマリーを使用している組織は、手動によるサマリー作成、作成するサマリーの識別、サマリーの索引付けと更新、さらに使用サマリーに関するユーザーへのアドバイスなどの作業に、大量の時間と労力を費やしています。サマリー管理によりデータベース管理者のワークロードが軽減され、ユーザーは定義済のサマリーを知る必要がなくなります。データベース管理者は1つ以上のマテリアライズド・ビューを作成しますが、これがサマリーに相当します。エンド・ユーザーは、詳細データ・レベルで表やビューを問い合せます。
Oracleデータベース・サーバーのクエリー・リライト・メカニズムにより、サマリー表に使用するSQL問合せが自動的にリライトされます。このメカニズムにより、問合せから結果を戻すための応答時間が短縮されます。データ・ウェアハウス内のマテリアライズド・ビューは、エンド・ユーザーやデータベース・アプリケーションに対して透過的です。
通常、マテリアライズド・ビューにはクエリー・リライト・メカニズムを介してアクセスしますが、エンド・ユーザーやデータベース・アプリケーションはサマリーに直接アクセスする問合せを構成できます。ただし、サマリーに対する変更はそれを参照する問合せに影響するため、ユーザーにこの操作を許可するかどうかは重大な考慮事項となります。
スキーマ内で多数のマテリアライズド・ビューから選択しやすいように、マテリアライズド・ビューの分析およびアドバイザ・ファンクションおよびプロシージャのコレクションがDBMS_ADVISORパッケージに用意されています。これらのファンクションは総称してSQLアクセス・アドバイザと呼ばれ、どのPL/SQLプログラムからでもコールできます。SQLアクセス・アドバイザは、仮説によるワークロードまたはユーザー定義ワークロード、あるいはSQLキャッシュから取得したワークロードに基づいて、マテリアライズド・ビューを推奨します。SQLアクセス・アドバイザは、Oracle Enterprise Managerから実行するか、DBMS_ADVISORパッケージを起動して実行できます。
ビットマップ索引は、データ・ウェアハウス環境で広範囲に使用されています。通常、この環境では大量のデータと非定型問合せを扱いますが、同時DMLトランザクションのレベルは高くありません。この種のアプリケーションに対するビットマップ索引の利点は次のとおりです。
従来のBツリー索引を使用して大きな表に完全な索引を作成すると、領域という面で膨大なコストがかかります。索引は表中のデータの何倍にも膨れ上がることがあるからです。それに対して、ビットマップ索引は通常、表中で索引を付けるデータのサイズより小さくてすみます。
索引では、特定のキー値が含まれる行にポインタが提供されます。通常の索引では、キー値と、そのキー値を持つ行のROWIDの対応リストを格納します。ビットマップ索引では、ROWIDのリストが各キー値のビットマップで置換されます。
ビットマップの各ビットは存在するROWIDに対応します。ビットが設定されている場合は、対応するROWIDを持つ行にはキー値が含まれることになります。マッピング機能がビット位置を実際のROWIDに変換するため、ビットマップ索引は通常の索引と同じ機能を果たします。異なるキー値の数が多くない場合、ビットマップ索引は領域を節約できます。
ビットマップ索引は、WHERE句に複数の条件を含む問合せに最も効率的です。一部の条件は満たしているがすべては満たしていない行については、表自体にアクセスする前に除外します。これによって、応答時間が短縮されます。多くの場合は劇的に改善されます。可能な値が小さいため、性別列はビットマップ索引の優れた候補となります。
パラレル問合せおよびパラレルDMLは、従来の索引のみでなく、ビットマップ索引に対しても機能します。また、索引のパラレル作成と連結索引もサポートしています。
OracleでSQL文をパラレル実行する場合は、複数のプロセスが同時に作業を実行して、単一のSQL文を実行します。1つの文を実行するのに必要な作業を複数のプロセスに分けることにより、1つのプロセスで文を実行する場合に比べて、Oracleはさらに高速で実行できます。これらをパラレル実行またはパラレル処理と呼びます。
パラレル実行では、意思決定支援システム（DSS）およびデータ・ウェアハウスに対応付けられた大規模なデータベースにおいて、集中データ処理の応答時間が大幅に削減されます。対称型マルチプロセッサ（SMP）、クラスタ化されたシステムおよび大規模クラスタ・システムにおいては、パラレル実行を活用して最大のパフォーマンスを引き出せます。1つのOracleシステムに上で多数のCPUに文の処理を分散させることができるためです。特定のタイプのオンライン・トランザクション処理（OLTP）およびハイブリッド・システムに、パラレル実行を実装することもできます。
パラレル化とは、すべての問合せ作業を1つのプロセスで行わずに、多数のプロセスで同時に行えるように1つの作業を分割する考え方です。たとえば、1つのプロセスで12か月分をすべて処理するかわりに、12のプロセスが1年のそれぞれの月を分担して処理するなどがこの例です。これにより、パフォーマンスの大幅な改善が期待できます。
パラレル実行によって、システムはハードウェア・リソースの使用が最適化され、パフォーマンスが一段と向上します。システムのCPUとディスク・コントローラの負荷がすでに大きい場合は、パフォーマンスを改善するため、パラレル実行を使用する前にシステムの負荷を軽減するか、またはハードウェア・リソースを増やす必要があります。
パラレル実行に適さない作業もあります。たとえば、OLTP操作の多くは比較的高速であり数秒以内で完了されるので、全体の実行時間に対し、パラレル実行利用のオーバーヘッドが大きくなる傾向にあります。
パラレル実行を使用しない場合は、SQL文の順次実行に必要な処理のすべてを1つのサーバー・プロセスが実行します。たとえば、全表スキャン（SELECT * FROM empなど）を実行するには、図16-5に示すように、1つのプロセスで操作全体を実行します。
図16-6では、表empのスキャンを実行するパラレル実行サーバーを説明しています。この表はグラニュルと呼ばれるロード単位に動的に分割され（動的パーティション化）、各グラニュルは単一のパラレル実行サーバーにより読み取られます。グラニュルはコーディネータにより生成されます。各グラニュルの大きさは、表empの物理ブロックの範囲にあります。実行サーバーへのグラニュルのマッピングは静的に行われるのではなく、実行時間で決定されます。実行サーバーがグラニュルに対応する表empの行の読込みを完了したときにグラニュルが残っている場合は、コーディネータから別のグラニュルを取得します。この操作は、すべてのグラニュルが使用されるまで続けられます。つまり、表emp全体が読み込まれるまで続けられます。パラレル実行サーバーは結果をパラレル実行コーディネータに送り返し、それぞれの結果が組み立てられて、最終的な全表スキャンになります。
SQL問合せの問合せ計画では、まずパラレル実行コーディネータがSQL問合せ内の各演算子をパラレル・ピースに分割し、それらを問合せで指定した順序に従って実行します。次に、演算子を実行するパラレル実行サーバーによって作成された部分的な実行結果を統合します。1つの操作に割り当てられたパラレル実行サーバーの数が、その操作の並列度（DOP）となります。同じSQL文中の複数の操作の並列度は、すべて同じです。
Oracleには、データベースで分析操作を実行するための多数のSQL操作が導入されています。たとえば、ランキング、移動平均、累計、対比レポート、期間対比などです。これらの計算の一部は従来でもSQLを使用して実行できましたが、この構文はパフォーマンスを大幅に改善します。
この項の内容は、次のとおりです。
集計は、データ・ウェアハウスの基盤となる部分です。ウェアハウスでの集計効率を改善するために、Oracleには問合せとレポートを容易かつ高速にするGROUP BY句の拡張機能が用意されています。これらの拡張機能を使用すると、次の操作ができます。
これらの拡張機能を使用すると、必要なデータ・グループをGROUP BY句で正確に指定できます。これにより、CUBE操作を実行しなくても複数のディメンション間で効率的な分析が可能になります。キューブ全体を計算すると大きな処理負荷が発生するため、キューブをグルーピング・セットで置き換えるとパフォーマンスを大幅に改善できます。CUBE、ROLLUPおよびグルーピング・セットは、異なる方法でグループ化された行のUNION ALLに等価の結果セットを1つ生成します。
パフォーマンスを強化するために、これらの拡張機能をパラレル化できます。つまり、複数のプロセスがこれらの文をすべて同時に実行できます。これらの機能により集計計算の効率が向上し、データベースのパフォーマンスとスケーラビリティが強化されます。
意思決定支援システムで重要な概念の1つが多次元分析、つまり必要なディメンションのすべての組合せから企業を検査することです。ディメンションという用語は、質問の指定に使用されるカテゴリという意味で使用します。最も一般的に指定されるディメンションは時間、地理、製品、部門および物流チャネルですが、潜在的なディメンションは企業のアクティビティと同様に制限はありません。ディメンション値の特定の集合に関連したイベントやエンティティを、通常はファクトと呼びます。ファクトは、営業単位や各国通貨、収益、顧客数、生産高など、追跡する価値のあるデータです。
ここでは、多次元要求の例を使用して説明します。
これらの要求には、いずれも複数のディメンションが含まれています。多次元による多くの質問では、通常は時間、地理または予算にまたがって集計されたデータと、データ・セットの比較が必要になります。
Oracleは、分析SQL関数ファミリを使用した拡張SQL分析処理機能を備えています。これらの分析関数を使用して次の計算を実行できます。
ランキング関数には、累積分布、パーセント・ランクおよびNタイルがあります。変動ウィンドウの計算を使用すると、合計や平均などの移動集計と累積集計を求めることができます。LAG/LEAD分析を使用すると、行間を直接参照できるため、期間ごとの変化を計算できます。FIRST/LAST分析を使用すると、順序付けしたグループ内の最初と最後の値を求めることができます。
その他の機能としてCASE式があります。CASE式は、様々な場合に役立つif-thenロジックを提供します。
パフォーマンスを強化するために、分析関数をパラレル化できます。つまり、複数のプロセスがこれらの文をすべて同時に実行できます。これらの機能により計算が容易かつ効率的になり、データベースのパフォーマンスとスケーラビリティが強化され、簡素化が促進されます。
OracleのMODEL句は、SQL計算に新たなレベルの機能と柔軟性をもたらします。MODEL句を使用すると、問合せ結果から多次元配列を作成し、この配列に計算式を適用して新規の値を計算できます。計算式には、基本的な演算や再帰型を使用した連立方程式を使用できます。一部のアプリケーションでは、MODEL句でPCベースのスプレッドシートを置き換えることができます。SQLでのモデルには、スケーラビリティ、管理性、コラボレーションおよびセキュリティにおけるOracleの長所が生かされています。中核となる問合せエンジンは、処理できるデータ数に制限がありません。データベース内でモデルを定義して実行すると、大きいデータセットを個別のモデル化環境の間で転送する必要がありません。モデルはワークグループ間で簡単に共有できるため、すべてのアプリケーションで計算の一貫性が確実に保たれます。モデルを共有できるのみでなく、アクセスもOracleのセキュリティ機能で厳密に制御できます。MODEL句は、その豊富な機能によりあらゆるタイプのアプリケーションを強化できます。
Oracle OLAPは、従来はマルチディメンション・データベース以外に見られなかった問合せパフォーマンスと計算機能を、Oracleのリレーショナル・プラットフォームに提供します。また、インターネット対応の分析アプリケーションの開発に適したJava OLAP APIも用意されています。OLAPおよびRDBMSテクノロジの他の組合せとは異なり、Oracle OLAPは、ブリッジを使用してリレーショナル・データ・ストアからマルチディメンション・データ・ストアにデータを移動するマルチディメンション・データベースではありません。真のOLAP対応リレーショナル・データベースです。そのため、Oracleは、Oracleデータベースのスケーラビリティ、アクセス可能性、セキュリティ、管理性および高可用性とともに、マルチディメンション・データベースの利点も備えています。Java OLAP APIは、インターネット・ベースの分析アプリケーション専用に設計されており、生産的なデータ・アクセスを提供します。
OLAPシステムの直接のベースとしてOracleデータベース・サーバーを使用する方法には、次の利点があります。
分析アプリケーションの3つのディメンション、つまりユーザー数、データのサイズおよび分析の複雑さは、大幅に拡大しています。分析アプリケーションのユーザーは増加する一方であり、いずれもより洗練された分析と市場の絞込みを実行するために、より多くのデータへのアクセスを必要としています。たとえば、電話会社は、顧客回転率の分析に使用するアプリケーションの一部として、すべての電話番号などの詳細を顧客ディメンションに組み込む必要があります。そのためには、数百万行のディメンション表ときわめて大量のファクト・データのサポートを必要とします。Oracleは、パラレル実行とパーティション化を使用してラージ・データセットを処理できるのみでなく、先進的なハードウェアとクラスタ処理のサポートも提供しています。
パーティション化により、表と索引の正確なサブセットを管理できるため、管理作業はこれらのデータ構造の一部にしか影響しません。表と索引をパーティション化することで、データ管理の処理時間が短縮され、データを使用できない時間が最短に抑えられます。トランスポータブル表領域も、高可用性をサポートしています。トランスポータブル表領域を使用すると、表や索引などのラージ・データセットをほとんど処理することなく他のデータベースに追加できます。これにより、きわめて迅速にデータをロードして更新できます。
Oracleでは、リソースの使用率を正確に制御できます。たとえば、データベース・リソース・マネージャには、データ・ウェアハウスのリソースを様々なエンド・ユーザーの集合間で割り当てるメカニズムが用意されています。
もう1つのリソース管理機能が進捗モニターで、エンド・ユーザーと管理者に長時間実行操作のステータスを示します。Oracleでは、これらの操作の完了率を示す統計がメンテナンスされます。Oracle Enterprise Managerを使用すると、これらの操作の完了率を示す棒グラフを表示できます。さらに、他のツールやデータベース管理者が、システム・ビューを使用してOracleデータ・サーバーから進捗情報を直接取得することも可能です。
Oracleは、TB規模で単純かつ安全な操作を可能にする、バックアップ、リストアおよびリカバリ・タスク用のサーバー管理インフラストラクチャを提供します。その要点は次のとおりです。
Oracleのセキュリティ機能は、アメリカ政府によるデータベース信頼性の最上位認定レベルに達しています。Oracleのファイングレイン・アクセス・コントロールにより、OLAPユーザーに対するセル・レベルのセキュリティが使用可能になります。ファイングレイン・アクセス・コントロールは問合せ処理に対する最小負荷で動作し、セキュリティの効率的な集中管理を可能にします。
Oracle Data Mining（ODM）は、Oracle Databaseの埋込みデータ・マイニング・コンポーネントです。データがデータベースを出ることはなく、データ、データ準備、モデル構築およびモデルのスコアリングの結果は、すべてデータベースに残ります。これにより、Oracleはアプリケーション開発者に、データ・マイニングをデータベース・アプリケーションとシームレスに統合するためのインフラストラクチャを提供します。データ・マイニングが使用される典型的なアプリケーションには、コール・センター、ATM、ERMおよびビジネス・プランニング・アプリケーションなどがあります。
特化したツールにデータを抽出して結果をデータベースにインポートする必要がないため、作業時間を大幅に節約できます。また、データとデータ・モデルを同じ場所（Oracleデータベース）に格納することで、モデルをコードとしてエクスポートする必要がなくなります。
モデルの構築、テストおよびスコアリングなどのデータ・マイニング機能は、Java APIを介して提供されます。
Oracle Data Miningは、次のアルゴリズムをサポートしています。
ODMには、複数の機能とパフォーマンス強化も組み込まれています。
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|