(57)【要約】【課題】  オブジェクトモデルからディメンジョンモデルを自動的に生成すること。【解決手段】  オブジェクトモデル中の関係が使用され、ディメンジョンモデル中の外部キー関係が推論される。タグ付きフォーマットデータスキーマが開示される。スキーマにより、オブジェクトリレーショナルモデルを指定し、メタデータで装飾し、それによってディメンジョンモデルをそれから推論することが可能となる。一実施形態によれば、スキーマで指定される情報に基づいて、処理エンジンがディメンジョンモデルを自律的に生成することができる。【選択図】  図５
2004280823.tif 000002
【特許請求の範囲】
【請求項１】
入力として、
オブジェクトモデル内のエンティティ間の関係を記述するオブジェクトモデル記述情報と、
前記オブジェクトモデル内の情報を焦点として識別する焦点識別子と、
前記オブジェクトモデル内のエンティティと永続データ記憶との間のマッピングを示すマッピング情報と
を受け取るように構成されたディメンジョンモデル生成構成要素を備え、
前記入力に基づいてディメンジョンモデルを自動的に生成するように構成されることを特徴とするコンピュータ実装ディメンジョンモデル生成システム。
【請求項２】
前記ディメンジョンモデル生成構成要素は、
前記マッピング情報に基づいてデータセットスキーマを生成するマップシステムと、
前記マップシステムに結合され、前記データセットスキーマに基づいて前記ディメンジョンモデルを構築するモデル構築システムと
を含むことを特徴とする請求項１に記載のディメンジョンモデル生成システム。
【請求項３】
前記マップシステムは、
ユーザ提供のマッピング情報に基づいてマップオブジェクトを生成するマップオブジェクトジェネレータと、
前記マップオブジェクトを走査し、前記マップオブジェクトの走査に基づいて前記データセットスキーマを作成するマップウォーカと
を有することを特徴とする請求項２に記載のディメンジョンモデル生成システム。
【請求項４】
前記マップオブジェクトジェネレータは、前記マッピング情報に基づいて、列を有するリレーショナルデータベーステーブルを取り出すように構成されることを特徴とする請求項３に記載のディメンジョンモデル生成システム。
【請求項５】
前記マップオブジェクトジェネレータは、取り出したテーブルおよび列に関するテーブルオブジェクトおよび列オブジェクトを生成するように構成されることを特徴とする請求項４に記載のディメンジョンモデル生成システム。
【請求項６】
前記マップウォーカは、前記オブジェクトモデル記述情報で記述される関係に基づいて作成された外部キー関係を前記テーブルオブジェクトおよび列オブジェクトに適用するように構成されることを特徴とする請求項５に記載のディメンジョンモデル生成システム。
【請求項７】
前記マップウォーカは、前記焦点識別子に基づいて焦点とマークされたエンティティを識別するように構成されることを特徴とする請求項６に記載のディメンジョンモデル生成システム。
【請求項８】
前記マップウォーカは、前記識別したエンティティに対応するテーブルオブジェクトに関する前記外部キー関係を走査することによって、名前付きクエリを生成するように構成されることを特徴とする請求項７に記載のディメンジョンモデル生成システム。
【請求項９】
前記マップウォーカは、前記名前付きクエリを使用して前記データセットスキーマ中の論理ビューを構築するように構成されることを特徴とする請求項８に記載のディメンジョンモデル生成システム。
【請求項１０】
前記モデル構築システムは、
前記データセットスキーマから前記ディメンジョンモデルを生成するモデルジェネレータを有することを特徴とする請求項８に記載のディメンジョンモデル生成システム。
【請求項１１】
前記モデル構築システムは、
起動時に指定されたディメンジョンモデルを具体化するインターフェースをサポートするモデルマテリアライザを有することを特徴とする請求項８に記載のディメンジョンモデル生成システム。
【請求項１２】
前記マップオブジェクトジェネレータは、
前記マッピング情報を受け取り、前記ユーザ提供のマッピング情報の直列化表現を生成するように構成されたマッパ構成要素と、
前記マッパ構成要素に結合され、前記マッピング情報の直列化表現に基づいて前記マップオブジェクトを生成するように構成されたマップローダと
を有することを特徴とする請求項３に記載のディメンジョンモデル生成システム。
【請求項１３】
前記マップウォーカは、前記オブジェクトモデル記述情報によって記述される前記エンティティのマッピングが行われる前記永続データ記憶内にテーブルおよび列を表す前記データセットスキーマを生成するように構成されることを特徴とする請求項３に記載のディメンジョンモデル生成システム。
【請求項１４】
永続データ記憶にマッピングが行われるオブジェクトモデルからディメンジョンモデルを生成する方法であって、
前記オブジェクトモデル中のオブジェクト間の関係を示すオブジェクト記述情報、前記オブジェクトモデル中の焦点を示す焦点情報、および前記オブジェクトモデル中のオブジェクトと前記永続データ記憶との間のマッピングを示すマッピング情報を含む入力に基づいて、前記ディメンジョンモデルを自動的に生成するステップを備えたことを特徴とする方法。
【請求項１５】
オブジェクトリレーショナルデータモデルの標準化データ表現であって、前記オブジェクトリレーショナルデータモデルに対応するディメンジョンデータモデルの自動導出をサポートするように構成されることを特徴とする標準化データ表現。
【請求項１６】
前記標準化データ表現により、前記オブジェクトリレーショナルデータモデルを指定し、メタデータで装飾して、前記ディメンジョンモデルの前記導出をサポートすることを可能とすることを特徴とする請求項１５に記載の標準化データ表現。
【請求項１７】
前記標準化データ表現は、前記ディメンジョンモデルを自律的に導出するように適合された処理エンジンによって処理されるように構成されることを特徴とする請求項１５に記載の前記標準化データ表現。
【請求項１８】
前記標準化データ表現は、前記オブジェクトリレーショナルデータモデルで反映されるオブジェクトおよびオブジェクト関係の記述を含むことを特徴とする請求項１５に記載の標準化データ表現。
【請求項１９】
前記標準化データ表現は、前記オブジェクトリレーショナルデータモデルに関連する永続データ記憶マッピングの記述を含むことを特徴とする請求項１５に記載の標準化データ表現。
【請求項２０】
前記標準化データ表現は、前記オブジェクトリレーショナルデータモデル内のオブジェクトおよびオブジェクト関係の記述と、
前記オブジェクトリレーショナルデータモデルに関連する永続データ記憶マッピングの記述と
を含むことを特徴とする請求項１５に記載の標準化データ表現。
【請求項２１】
前記標準化データ表現は、前記オブジェクトリレーショナルデータモデル中のデータに関連して示される分析点を表す少なくとも１つの焦点の記述をさらに含むことを特徴とする請求項１５ないし２０のいずれかに記載の標準化データ表現。
【請求項２２】
前記標準化表現は、前記オブジェクトリレーショナルデータモデルからのクラス、前記オブジェクトリレーショナルデータモデルからのクラスに関連するデータメンバ、リレーショナルデータベースからのデータの取り出し方を指定するオブジェクトリレーショナルマッピングの集合、前記オブジェクトリレーショナルデータモデルからのクラスを一意に識別するフィールド、前記オブジェクトリレーショナルデータモデル中のクラス間の関係を識別する関連付け関係インジケータ、前記オブジェクトリレーショナルデータモデル中のクラス間の関係を識別する組立関係インジケータ、および前記ディメンジョンモデルの生成のために使用される注目の数値を識別する尺度からなるデータ要素のグループから選択された少なくとも１つのデータ要素の記述を含むことを特徴とする請求項１５に記載の標準化データ表現。
【請求項２３】
前記標準化データ表現は、オブジェクトリレーショナルデータモデルを表すタグ付きフォーマットデータスキーマであることを特徴とする請求項１５に記載の表現。
【請求項２４】
前記標準化データ表現は、オブジェクトリレーショナルデータモデルを表すＸＭＬデータスキーマであることを特徴とする請求項１５に記載の表現。
【請求項２５】
前記スキーマは、前記ディメンジョンモデルを自律的に導出するように適合された処理エンジンによって処理されるように構成されることを特徴とする請求項２３または２４に記載の表現。
【請求項２６】
前記スキーマは、前記オブジェクトリレーショナルデータモデルで反映されるオブジェクトおよびオブジェクト関係の記述を含むことを特徴とする請求項２３または２４に記載の表現。
【請求項２７】
前記スキーマは、前記オブジェクトリレーショナルデータモデルに関連する永続データ記憶マッピングの記述を含むことを特徴とする請求項２３または２４に記載の表現。
【請求項２８】
前記スキーマは、前記オブジェクトリレーショナルデータモデル中のデータに関連して示される分析点を表す少なくとも１つの焦点の記述を含むことを特徴とする請求項２３または２４に記載の表現。
【請求項２９】
前記オブジェクトリレーショナルデータモデルで反映されるオブジェクトおよびオブジェクト関係の記述と、
前記オブジェクトリレーショナルデータモデルに関連する永続データ記憶マッピングの記述と
を含むことを特徴とする請求項２３または２４に記載の表現。
【請求項３０】
前記スキーマは、前記オブジェクトリレーショナルデータモデル中のデータに関連して示される分析点を表す少なくとも１つの焦点の記述をさらに含むことを特徴とする請求項２９に記載の表現。
【請求項３１】
前記スキーマは、前記オブジェクトリレーショナルデータモデルからのクラス、前記オブジェクトリレーショナルデータモデルからのクラスに関連するデータメンバ、リレーショナルデータベースからのデータの取り出し方を指定するオブジェクトリレーショナルマッピングの集合、前記オブジェクトリレーショナルデータモデルからのクラスを一意に識別するフィールド、前記オブジェクトリレーショナルデータモデル中のクラス間の関係を識別する関連付け関係インジケータ、前記オブジェクトリレーショナルデータモデル中のクラス間の関係を識別する組立関係インジケータ、および前記ディメンジョンモデルの生成のために使用される注目の数値を識別する尺度からなるデータ要素のグループから選択された少なくとも１つのデータ要素の記述を含むことを特徴とする請求項２３または２４に記載の表現。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オブジェクトモデルによってモデル化されたシステム内のデータにアクセスするための報告要件を満たすことに関する。より詳細には、本発明は、オブジェクトモデルからディメンジョンモデルを推論することによってビジネスデータの報告を容易にするシステムに関する。
【背景技術】
【０００２】
商取引に関係するソフトウェアアプリケーションを設計するとき、アプリケーション開発者は従来、モデル主導のアーキテクチャを使用し、領域固有の知識に焦点をあわせる。モデル主導のアーキテクチャには、顧客、注文、および製品に対応するビジネスエンティティなど、商取引に関係するビジネスオブジェクト（またはビジネスエンティティ）が含まれることがたびたびある。こうしたエンティティは、オブジェクト指向のパラダイムに従ってオブジェクトとしてモデル化される。
【０００３】
各オブジェクトは、ビジネスエンティティのデータおよび振舞いをカプセル化する。例えば、Ｃｕｓｔｏｍｅｒオブジェクトは、名前、住所、顧客に関するその他の個人情報などのデータを含む。Ｃｕｓｔｏｍｅｒオブジェクトはまた、例えば新しいＣｕｓｔｏｍｅｒを作成し、既存のＣｕｓｔｏｍｅｒのデータを修正し、Ｃｕｓｔｏｍｅｒをデータベースに保存するプログラミングコードも含む。
【０００４】
オブジェクトモデルにより、モデル化するビジネスエンティティ間の関係を記述することも可能となる。例えば、いくつかのＯｒｄｅｒオブジェクトを、そうした注文を行う顧客を表すＣｕｓｔｏｍｅｒオブジェクトと関連付けることができる。これは、関連付け関係（ａｓｓｏｃｉａｔｉｏｎ  ｒｅｌａｔｉｏｎｓｈｉｐ）と呼ばれている。組立などのその他の種類の関係も記述することができる。例えばＯｒｄｅｒを、ＯｒｄｅｒＬｉｎｅｓの集合から「組立てる」ことができる。こうしたＯｒｄｅｒＬｉｎｅｓは、それが属するＯｒｄｅｒと独立には存在しない。このようにして、アプリケーション開発者は、アプリケーション開発者のアプリケーションに関連するビジネスロジックを１組のモデルに変換する。しばしばオンライントランザクション処理（ＯＬＴＰ）を使用して、このビジネスロジックを実装するアプリケーションが構築される。
【０００５】
オブジェクトモデル中のオブジェクトは通常、そのデータをリレーショナルデータベースに格納する。従来の報告要件を満たすために、リレーショナルデータベースを介して、抽出、変換、およびロード（ＥＴＬ）の各プロセスを使用してデータが取り出される。データは、こうしたプロセスを使用して、データマートと呼ばれるステージングエリア内に取り出される。
【０００６】
現在、データマートを扱うユーザと、ＯＬＴＰアプリケーション開発を実施するユーザとの間には知識のギャップが存在している。データマートを扱うユーザは通常、どのようにオブジェクトモデルを構築するかということについての知識を持っていない。したがって、データをＥＴＬプロセスを介して取り出すと、オブジェクトモデル内に構築されたビジネスロジック（関係、クラスなど）が失われる。
【０００７】
したがって従来から、ユーザの報告要件を満足させるのを容易にするために、ディメンジョンモデルと呼ばれる別のモデルが、データマート内のデータから構築される。ディメンジョンモデルは、尺度を有するＦａｃｔテーブルと、ディメンジョンとして参照される関連テーブルとを含む。ディメンジョンモデルを構築すると、オブジェクトモデル内に構築されたビジネスロジックが失われた場合であっても、ユーザは、ディメンジョンモデルに対するクエリを特定して、幾分論理的にデータを得ることができる。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかし、このタイプのシステムは、ビジネスロジック（またはビジネスロジックの少なくとも一部）を再構築してディメンジョンモデルを得る際に多大な時間を必要とする。これにより、こうしたシステムを使用する会社は、一方がビジネスロジックを開発してそれをオブジェクトモデルとして実装し、他方が会社の必要とする報告構造をサポートする２つのグループのプログラマを維持しなければならなくなる可能性がある。もちろん、この人員の重複はコストがかかり、かつ非効率である。
【課題を解決するための手段】
【０００９】
本発明は、オブジェクトモデルからディメンジョンモデルを自動的に生成する。ディメンジョンモデル中の外部キー関係を案出する（ｐｒｏｊｅｃｔ）のに、オブジェクトモデル中の関係が使用される。
【００１０】
一実施形態では、ユーザは、報告の分析の焦点を指定する。ユーザはまた、オブジェクトモデルと、オブジェクトモデルによって表されるエンティティから、リレーショナルデータベースなどの永続データ記憶システムへのマッピングも指定する。
【００１１】
別の実施形態では、第２のオブジェクトモデルが、ディメンジョンモデルから自動的に生成される。これにより、ユーザは、オブジェクト指向の表現だけを使用して所望のレポートを生成することが可能となる。オブジェクト指向の表現は、ディメンジョンモデルに対して実行されるディメンジョンモデルクエリ表現に変換される。
【００１２】
別の実施形態はデータスキーマに関する。特定の実施形態は、オブジェクトリレーショナルモデルを指定し、メタデータで装飾し、それによってディメンジョンモデルをそれから推論することを可能にするタグ付きフォーマットデータスキーマに関する。一実施形態によれば、スキーマで指定された情報に基づいて、処理エンジンがディメンジョンモデルを自律的に生成することができる。
【発明を実施するための最良の形態】
【００１３】
本発明の様々な態様は、オブジェクトリレーショナルモデルを指定し、およびメタデータで装飾して、それからディメンジョンモデルを推定することを可能にするデータスキーマに関する。しかし、本発明をより詳細に説明する前に、本発明を使用することのできる例示的な環境の一実施形態を説明する。
【００１４】
図１に、本発明を実施することのできる適切なコンピューティングシステム環境１００の一例を示す。コンピューティングシステム環境１００は、適切なコンピューティング環境の一例に過ぎず、本発明の使用法または機能の範囲に関して何らかの制限を示唆するものではない。例示的な動作環境１００に図示する構成要素（ｃｏｍｐｏｎｅｎｔ）のうちのいずれか１つ、あるいはそれらの組合せに関係する何らかの依存関係または要件をコンピューティング環境１００が有すると解釈すべきでもない。
【００１５】
本発明は、他の多数の汎用／専用コンピューティングシステム環境／構成を用いて動作可能である。本発明と共に使用するのに適した周知のコンピューティングシステム、環境、および／または構成の例には、限定はしないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルド／ラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル消費者向け電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、ならびに上記のシステムまたは装置のいずれかを含む分散コンピューティング環境などが含まれる。
【００１６】
本発明は、コンピュータが実行中の、プログラムモジュールなどのコンピュータ実行可能命令の一般的状況で説明することができる。一般に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データタイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明はまた、通信ネットワークを介してリンクされるリモート処理装置によってタスクが実行される分散コンピューティング環境でも実施することができる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含む、ローカルコンピュータ記憶媒体とリモートコンピュータ記憶媒体のどちらにも位置することができる。
【００１７】
図１を参照すると、本発明を実装する例示のシステムは、コンピュータ１１０の形態の汎用コンピューティング装置を含む。コンピュータ１１０の構成要素には、限定はしないが、処理装置１２０と、システムメモリ１３０と、システムメモリを含む様々なシステム構成要素を処理装置１２０に結合するシステムバス１２１とを含めることができる。システムバス１２１は、様々なバスアーキテクチャのうちのいずれかを用いる、メモリバスまたはメモリコントローラと、周辺機器バスと、ローカルバスとを含むいくつかのタイプのバス構造のうちのいずれでもよい。例えば、限定はしないが、このようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ  ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとも呼ばれるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが含まれる。
【００１８】
コンピュータ１１０は、一般に様々なコンピュータ読取可能な媒体を含む。コンピュータ読取可能な媒体は、コンピュータ１１０がアクセス可能である入手可能などんな媒体でもよく、それには揮発性媒体と不揮発性媒体、取外し可能媒体と固定媒体のどちらも含まれる。例えば、限定はしないが、コンピュータ読取可能な媒体は、コンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体には、コンピュータ読取可能命令、データ構造、プログラムモジュール、または他のデータなどの情報を格納するための何らかの方法または技術で実装される、揮発性媒体と不揮発性媒体、取外し可能媒体と固定媒体のどちらも含まれる。コンピュータ記憶媒体には、限定はしないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、または他の磁気記憶装置、あるいは、所望の情報を格納するのに使用することができ、コンピュータ１１０でアクセスすることができる他のどんな媒体も含まれる。通信媒体は一般に、コンピュータ読取可能命令、データ構造、プログラムモジュール、または他のデータを、搬送波または他の移送機構などの被変調データ信号で実装するが、その通信媒体にはどんな情報送達媒体も含まれる。「被変調データ信号」という用語は、信号内で情報を符号化するように、その特性の１つまたは複数が設定された、または変化した信号を意味する。例えば、限定はしないが、通信媒体には、有線ネットワークまたは直接配線接続などの有線媒体、ならびに音響媒体、ＲＦ媒体、赤外線媒体、他の無線媒体などの無線媒体が含まれる。上記のいずれの組合せも、コンピュータ読取可能な媒体の範囲内に含まれるべきである。
【００１９】
システムメモリ１３０は、読取り専用メモリ（ＲＯＭ）１３１やランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性メモリおよび／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。起動中などにコンピュータ１１０内の要素間で情報を転送する助けになる基本ルーチンを含む基本入出力システム（ＢＩＯＳ）１３３が、一般にＲＯＭ１３１内に格納される。ＲＡＭ１３２は一般に、処理装置１２０が即座にアクセス可能であり、および／または処理装置１２０が現在操作しているデータおよび／またはプログラムモジュールを含む。例えば、限定はしないが、図１にオペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。
【００２０】
コンピュータ１１０はまた、他の取外し可能／固定の、揮発性／不揮発性コンピュータ記憶媒体も含むことができる。単なる一例であるが、図１に、固定不揮発性磁気媒体を読み書きするハードディスクドライブ１４１と、取外し可能不揮発性磁気ディスク１５２を読み書きする磁気ディスクドライブ１５１と、ＣＤ−ＲＯＭまたは他の光媒体などの取外し可能不揮発性光ディスク１５６を読み書きする光ディスクドライブ１５５とを示す。例示的動作環境で使用することのできる他の取外し可能／固定の揮発性／不揮発性コンピュータ記憶媒体には、限定はしないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、固体ＲＡＭ、固体ＲＯＭなどが含まれる。ハードディスクドライブ１４１は一般に、インターフェース１４０などの固定メモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は一般に、インターフェース１５０などの取外し可能メモリインターフェースによってシステムバス１２１に接続される。
【００２１】
上記で議論し、図１に図示するドライブとその関連するコンピュータ記憶媒体は、コンピュータ１１０に対してコンピュータ読取可能命令、データ構造、プログラムモジュール、および他のデータの記憶を実現する。例えば図１では、ハードディスクドライブ１４１がオペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するものとして図示している。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じであっても、異なっていてもよいことに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７には、少なくともこれらが異なるコピーであることを示すために異なる符号を付けてある。
【００２２】
ユーザは、キーボード１６２と、マイクロフォン１６３と、マウス、トラックボール、またはタッチパッドなどのポインティングデバイス１６１などの入力装置を介して、コマンドおよび情報をコンピュータ１１０に入力することができる。他の入力装置（図示せず）には、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどを含めることができる。これらの入力装置や他の入力装置はしばしば、システムバスに結合されるユーザ入力インターフェース１６０を介して処理装置１２０に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースおよびバス構造によって接続することもできる。モニタ１９１または他のタイプのディスプレイ装置もまた、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタに加えて、コンピュータはまた、スピーカ１９７やプリンタ１９６などの他の周辺出力装置も含むことができ、それらは、出力周辺インターフェース１９５を介して接続することができる。
【００２３】
コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、ハンドヘルド装置、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の共通ネットワークノードでよく、一般にコンピュータ１１０に関して上記で述べた要素のうちの多数またはすべてを含む。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３を含むが、他のネットワークも含むことができる。このようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットで一般的なものである。
【００２４】
ＬＡＮネットワーキング環境で使用する際、コンピュータ１１０は、ネットワークインターフェース／アダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用する際、コンピュータ１１０は一般に、インターネットなどのＷＡＮ１７３を介して通信を確立するためのモデム１７２または他の手段を含む。モデム１７２は内蔵でも外付けでもよく、ユーザ入力インターフェース１６０、または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク環境では、コンピュータ１１０に関して示したプログラムモジュールまたはその一部を、リモートメモリ記憶装置内に格納することができる。例えば、限定はしないが、図１に、リモートアプリケーションプログラム１８５がリモートコンピュータ１８０上に常駐するものとして示す。図示するネットワーク接続は例示的なものであって、コンピュータ間の通信リンクを確立する他の手段も使用できることを理解されたい。
【００２５】
図２は、従来の技術によるデータ処理を示すブロック図である。図２は、アプリケーション開発者が、オブジェクトモデル２００を開発することにより、アプリケーションで使用されるビジネスロジックが実装されることを示す。図２に示すように、オブジェクトモデル２００は、Ｃｕｓｔｏｍｅｒエンティティ２０２、Ｏｒｄｅｒエンティティ２０４、およびＯｒｄｅｒＬｉｎｅエンティティ２０６を含む複数の相異なるビジネスエンティティを含む。オブジェクトモデル２００は、一般に統一モデリング言語（ＵＭＬ）と呼ばれる表記法（ｎｏｔａｔｉｏｎ）を使用する。この表記法は、Ｏｒｄｅｒ２０４とＯｒｄｅｒＬｉｎｅ２０６との間の組立関係を示す。したがって、この表記法は、Ｏｒｄｅｒエンティティ２０４が１つまたは複数のＯｒｄｅｒＬｉｎｅエンティティ２０６から組み立てられることを示す。オブジェクトモデル２００はまた、Ｏｒｄｅｒ２０４がＣｕｓｔｏｍｅｒ２００との関連付け（ａｓｓｏｃｉａｔｉｏｎ）を有することも示す。
【００２６】
従来のシステムでは、所望の報告構造をサポートするために、まず、データが、抽出、変換、およびロード（ＥＴＬ）の各プロセスを用いて永続データ記憶（リレーショナルデータベースなど）２０１から取り出され、データを取り出す前にデータ用のステージングエリアとして振る舞うデータマート２０８に配置されていた。
【００２７】
次いで、ユーザ用の報告構造をサポートする開発者が、モデル２１０などのディメンジョンモデルを生成した。ディメンジョンモデルは通常、その中に尺度が注記されたＦａｃｔテーブル２１１を含む。Ｆａｃｔテーブル２１１はまた、図２のＤ１〜Ｄ５に示す複数のディメンジョンも有する。ディメンジョンモデル２１０は通常、ユーザが報告および分析を望むデータ中の特定の特徴に基づいて作成された。したがって、オブジェクトモデル２００中に実装されたビジネスロジックの一部は、ディメンジョンモデル２１０内に再作成されたのである。
【００２８】
しかし、オブジェクトモデルを介してビジネスロジックを実装するアプリケーション開発者は、通常、ディメンジョンモデルを開発する開発者とは別であり、有する基礎知識も異なる。したがって従来の方法によると、報告に使用することのできるディメンジョンモデル２１０を得るために、オブジェクトモデル２００を介して実行されるビジネスロジックの少なくとも一部を再構築すると、多大の時間と労力が費やされることになった。
【００２９】
また、一部の従来技術の技法によると、ディメンジョンモデル２１０からレポートを生成することでさえ、レポートジェネレータがマルチディメンジョン表現（ＭＤＸ）に通じている必要があるという問題がある。ＭＤＸの構文は複雑であって、ＭＤＸ自身、オブジェクトモデル２００を作成し、対話するのに必要なオブジェクト指向表現とは異なることから、学習するのが困難なことがあるのである。したがって、ディメンジョンモデル２１０を構築した後でも、レポートの生成には、オブジェクト指向プログラミングで使用する知識とは異なる特別の知識を有する人員が必要であった。
【００３０】
本発明をより詳細に説明する前に、外部キー関係の概念を説明する。図３は、外部キー関係の概念を示す略図である。図３は、Ｆａｃｔテーブル２２０が「時間」および「顧客」に関連する他のテーブルをディメンジョンとして含むことを示す。したがって、Ｆａｃｔテーブル２２０は、ＴｉｍｅＩＤフィールド２２２およびＣｕｓｔｏｍｅｒＩＤフィールド２２４を含む。
【００３１】
時間テーブル２２６は、フィールド２２８内にＴｉｍｅＩＤと呼ばれる主キーを含む。主キーは、時間テーブル２２６内のレコードを一意に識別する。時間テーブル２２６はまた、日、週、月などの時間に関するいくつかの追加のフィールドも含む。
【００３２】
Ｃｕｓｔｏｍｅｒテーブル２３０も、ＣｕｓｔｏｍｅｒＩＤ２３２と呼ばれる主キーを含む主キーフィールドを含む。顧客テーブルの主キーは、顧客テーブル内のレコードを一意に識別する。もちろん、顧客テーブルは、顧客名などの顧客に関連する追加の項目も含む。
【００３３】
したがって、テーブル内の主キーは、そのテーブル内のレコードに関する固有識別子である。しかし、Ｆａｃｔテーブル２２０内のＴｉｍｅＩＤフィールド２２２およびＣｕｓｔｏｍｅｒＩＤフィールド２２４は、他のテーブル（この場合、それぞれ２２６および２３０）を参照する識別子である。したがって、Ｆａｃｔテーブル２２０内のフィールド２２２および２２４に含まれるキーは外部キーである。外部キー関係により、問題が複雑になることがある。例えば、テーブルの主キーが別のテーブル内の外部キーである場合、外部キー関係を処理せずにテーブルを削除することはできない。このような処理を行わず削除しなければ、そのようなシステムに通常課される完全性の制約が破られることとなる。
【００３４】
図４Ａは、本発明の一実施形態の概略ブロック図である。図４Ａは、焦点の指定２５２、オブジェクト記述２５４、および１組の永続データ記憶マッピング２５６を入力として取るモデルサービスシステム２５０を示す。次いでシステム２５０は、入力に基づいてディメンジョンモデル２５８を生成する。図１９および２０を参照して以下で説明するが、本発明の一態様は、入力２５２、２５４、および／または２５６の標準化記述を可能にするデータスキーマに関する。モデルサービスシステム２５０は、例示的には、編成スキーマフォーマット内に集められた情報に基づいてディメンジョンモデル２５８を生成するように構成される。
【００３５】
図４Ａにはまた、ディメンジョンモデル２５８に基づいて、本明細書でビジネスインテリジェンスエンティティ（またはＢＩエンティティ）２６２と呼ぶ１組のオブジェクト（またはエンティティ）を生成するエンティティジェネレータ２６０も示す。
【００３６】
焦点２５２は、ユーザによって分析の焦点とマークされるオブジェクトモデル中のあるデータを表す。焦点２５２は、例示的には、ＸＭＬ指定ファイル中で指定することができる。ＸＭＬ指定ファイルの一例を本明細書の付録Ａに示す。
【００３７】
オブジェクト記述２５４は、１組のオブジェクトに対応する１組のメタデータ内のオブジェクト指向関係を記述する入力である。これは、例えばＵＭＬクラスダイアグラムの形を取ることができる。複数のビジネスエンティティ（Ｃｕｓｔｏｍｅｒ、Ｏｒｄｅｒ、およびＯｒｄｅｒＬｉｎｅ）に関するＵＭＬクラスダイアグラムの一例を図４Ｂに示す。
【００３８】
永続データ記憶マッピング２５６は、オブジェクトモデルによって参照されるデータを、永続データ記憶、例示的な一実施形態では図２に示すリレーショナルデータベース２０１へのマッピングを行う。これらは、例示的には、ユーザによってマップファイルの形で作成される。マップファイルの一例を付録Ｂに示す。付録Ｂに示すマップファイルは、Ｃｕｓｔｏｍｅｒエンティティからリレーショナルデータベーステーブルへのマッピングを行う。
【００３９】
モデルサービスシステム２５０は、入力２５２、２５４、および２５６を受け取り、その入力に基づいてディメンジョンモデル２５８を自動的に生成する。本発明の一実施形態によれば、ディメンジョンモデル２５８は、ユーザが供給する入力から推論されるのであって、ビジネスロジックを再作成してモデル２５８を得る際に第２の組の開発者が関わる必要はない。一実施形態では、以下でより詳細に説明するが、モデルサービスシステム２５０は、オブジェクトモデル記述２５４で指定されるオブジェクトモデル内の関連付けおよび組立（ｃｏｍｐｏｓｉｔｉｏｎ）を使用して、ディメンジョンモデル２５８内の外部キー関係を推論する。システム２５０はまた、ユーザがファイル２５２で定義する分析の焦点と、永続データ記憶マッピング２５６とを使用して、ディメンジョンモデル２５８を作成し、モデル２５８を介してデータにアクセスする。したがって、本発明の一態様は、単にディメンジョンモデル２５８の自動生成である。本発明の別の態様によれば、図１９〜２１を参照して説明するが、システム２５０に供給されるデータが、標準化タグ付きフォーマットのデータスキーマ（例えばＸＭＬデータスキーマ）などの標準化データスキーマに従って編成される。
【００４０】
しかし、ディメンジョンモデル２５８を自動的に生成するシステムであっても改良することができる。例えば、ディメンジョンモデル２５８を介して情報を得るには、依然としてＭＤＸまたは何らかの種類のディメンジョンモデルクエリ言語をユーザが知っている必要がある。したがって、本発明の別の実施形態によれば、エンティティジェネレータ２６０が提供される。エンティティジェネレータ２６０は、ディメンジョンモデル２５８中のキューブおよびディメンジョンから、オブジェクトの形のビジネスインテリジェンスエンティティ２６２を作成する。このことも以下でより詳細に説明する。
【００４１】
図４Ｃに、図４Ａに示すシステムをより詳細に示す。図４Ｃに示す例では、オブジェクトモデルがオブジェクト記述２５４によって表され、マッピング２５６が、オブジェクトモデル表現２５４と、リレーショナルデータベース２０１を表すリレーショナルデータベース表現２６４との間に示されている。やはり、図１９〜２１を参照して説明する本発明の一態様によれば、標準化データスキーマに従って情報がモデルサービス２５０に供給される。
【００４２】
図４Ｃでは、ディメンジョンモデル２５８もより詳細に示される。ディメンジョンモデル２５８は、Ｆａｃｔテーブル２６６と、複数のディメンジョン２６８および２７０（ＣｕｓｔｏｍｅｒディメンジョンおよびＯｒｄｅｒディメンジョン）とを含む。各ディメンジョンは、１つまたは複数のテーブルで形成される。Ｆａｃｔテーブル２６６が外部キー参照としてＯｒｄｅｒｌｉｎｅＩＤおよびＣｕｓｔｏｍｅｒＩＤを含むことにも留意されたい。
【００４３】
図４Ｃに、１組のＢＩエンティティ２６２の一実施形態もまた示す。図４Ｃに示す例には、ＢＩエンティティ２６２は、ＢＩＯｒｄｅｒＦａｃｔエンティティ２７０、ＢＩＯｒｄｅｒエンティティ２７２、およびＢＩＣｕｓｔｏｍｅｒエンティティ２７４が含まれる。エンティティ２７２および２７４がエンティティ２７０に関係付けられる。
【００４４】
各エンティティと、オブジェクトモデル記述２５４内のそれらの関係を見ることにより、ディメンジョンモデルがディメンジョンモデル表現２５８内に示すようなスノーフレークスキーマを必要とすることがわかる。したがって、２つのディメンジョンＯｒｄｅｒおよびＣｕｓｔｏｍｅｒが作成されると推論することができる。Ｏｒｄｅｒディメンジョンは、ＯｒｄｅｒおよびＯｒｄｅｒＬｉｎｅという２つのレベルを有する。Ｆａｃｔテーブル２６６中の尺度（または数値）は、ＵｎｉｔＰｒｉｃｅおよびＱｕａｎｔｉｔｙを含み、ＯｒｄｅｒＬｉｎｅエンティティに由来する。
【００４５】
図５は、モデルサービスシステム２５０のより詳細なブロック図である。図６Ａは、図５に示すシステム２５０の動作をより良く示すフローチャートである。図５および６Ａを、相互に参照して説明する。図５は、モデルサービスシステム２５０がモデルサービス構成要素３００、マップシステム３０２、およびディメンジョンモデル構築システム３０４を含むことを示す。マップシステム３０２は、エンティティ関係（ＥＲ）マッパ３０６、マップローダ３０８、およびマップウォーカ３１０を含む。ディメンジョンモデル構築システム３０４は、モデルジェネレータ３１２、モデルマテリアライザ３１４、およびモデルプロセッサ３１６を含む。図５にはまた、エンティティジェネレータ２６０およびＢＩエンティティ２６２も示す。
【００４６】
モデルサービス構成要素３００は、焦点指定２５２、オブジェクト記述２５４、およびＥＲマッピング２５６を受諾するメインユーザインターフェースを提供する。図１９〜２１を参照して説明するが、本発明の一態様によれば、情報（例えば情報項目２５２、２５４、および２５６）は、編成データスキーマに従ってモデルサービス３００に提供される。このスキーマは、例示的には、ディメンジョンモデルを構築する自動プロセスを容易にするように構成される。
【００４７】
モデルサービス構成要素３００はまた、マップシステム３０２、ディメンジョンモデル構築システム３０４、およびエンティティジェネレータ２６０に関連する機能を起動することができる。したがって、変換プロセスの第１ステップとして、モデルサービスシステム２５０は、構成要素３００によって実装されるトップレベルインターフェースを介して、焦点指定２５２、オブジェクト記述２５４、および永続データ記憶マッピング２５６を受け取る。このことを図６Ａのブロック３２０で示す。
【００４８】
この例では、図４Ｂに示すものよりも詳細なオブジェクト記述が可能となる。したがって、この説明では、モデルサービスシステム２５０は、オブジェクト記述として図６Ｂに示すＵＭＬクラスダイアグラムを受け取ると仮定する。幾分複雑ではあるが、より詳細なビットを含むことを除けば、このＵＭＬクラスダイアグラムは図４Ｂに示すものと類似する。
【００４９】
モデルサービス構成要素３００は、これらの入力をマップシステム３０２に提供し、マップシステム３０２中のある機能を起動する。ＥＲマッパを使用して、ユーザは、直列化ＥＲマップ２５６を生成して、どのようにオブジェクトモデルをリレーショナルデータベースへのマッピングを行うかを記述する。次いで、こうした直列化マップ３２２がマップローダ３０８によってロードされる。マップローダ３０８は、こうしたマップを非直列化し、それをエンティティマップ（ＥＭ）オブジェクト３２４に変換する。ＥＭオブジェクト３２４の厳密な形式は重要ではない。ＥＭオブジェクト３２４は単に、ＥＭオブジェクト３２４の構造がマップウォーカ３１０によって認識されるように事前定義される直列化マップ３２２から生成されるオブジェクトである。マップ３２２のロード、およびＥＭオブジェクト３２４の作成を、図６Ａのブロック３２３に示す。
【００５０】
マップウォーカ３１０はＥＭオブジェクト３２４をナビゲーションし、リレーショナルデータベース内に、エンティティのマッピングが行われるテーブルおよび列を表し、かつそれらの間の関係を表すデータセットスキーマを生成する。ＥＭオブジェクトのナビゲーションを行ってデータセットスキーマ３２６を作成する様子を図６Ａのブロック３２５に示す。マップウォーカ３４０によって生成されたデータセットスキーマ３２６は、ディメンジョンモデル内にディメンジョンモデルキューブを構築する基礎を形成する。マップウォーカ３１０はまた、ディメンジョンモデルが必要とする任意の追加の情報をデータセットスキーマ３２６内に満たすことができる。加えて、マップウォーカ３１０は、ディメンジョンモデル中のＦａｃｔテーブルを定義するのに使用されるリレーショナルデータベース中のテーブルに対するクエリ３２８を生成する。次いで、スキーマ３２６をディメンジョンモデル構築システム３０４に提供する。具体的には、モデルジェネレータ３１２が、スキーマ３２６に基づいてディメンジョンモデルキューブを構築する。データセットスキーマ３２６からディメンジョンモデルキューブを構築することを、図６Ａのブロック３３０に示し、図７を参照して以下でさらに詳細に説明する。
【００５１】
モデルマテリアライザ３１４は、モデルジェネレータ３１２で生成されたディメンジョンモデルを具体化するインターフェースを提供する。ディメンジョンモデルの具体化を、図６Ａのブロック３３２で示す。モデルプロセッサ３１６は、モデルマテリアライザ３１４で具体化されたモデルを処理するインターフェースを提供する。この点で、ＭＤＸまたはマルチディメンジョンモデルにクエリを発するのに使用するその他の任意の言語を使用して、ディメンジョンモデルにクエリできることに留意されたい。しかし、本発明の別の実施形態によれば、エンティティジェネレータ２６０がシステム２５０によって起動され、作成されたディメンジョンモデルからＢＩエンティティ２６２が生成される。ディメンジョンモデルオブジェクトからＢＩエンティティを作成することを図６Ａのブロック３３４に示し、図１１Ａ〜１１Ｂを参照して以下でより詳細に説明する。
【００５２】
図７は、図５に示すマップウォーカ３１０およびディメンジョンモデル構築システム３０４を使用してオブジェクトモデルからディメンジョンモデルを作成することをより良く示すフローチャートである。記述されるオブジェクトモデル中の各エンティティに関連するＥＲマッピングから、こうしたエンティティに関係するリレーショナルデータベーステーブルを取り出す。このことは図７のブロック４００において示される。取り出した各テーブルについて、テーブルオブジェクトを作成する。テーブルオブジェクトは、そのテーブルに関連する列のすべてを含むフィールドを有する。これは図７のブロック４０２に示される。
【００５３】
作成したテーブルオブジェクトと列オブジェクトとの間の外部キー関係は、処理するオブジェクトモデル記述（ＵＭＬクラスダイアグラムなど）で記述されるオブジェクト間の関連付けおよび組立に基づいて案出される。次いでマップウォーカ３１０が、分析のための焦点とマークされた対応するエンティティを求めて、作成した各テーブルオブジェクトからの外部キー関係を走査する。焦点もまた、ユーザが入力した焦点指定ファイルで指定されることを想起されたい。名前付きクエリを生成するために、分析のための焦点とマークされた対応するエンティティを含むテーブルオブジェクトに向かって、外部キー関係を多数から１への方向に走査する。名前付きクエリは、適切な永続データ記憶クエリステートメント（構造化照会言語（ＳＱＬ）ステートメントなど）を使用して識別したテーブルを組み合わせることによって合成することができる。したがって、名前付きクエリは、ユーザの指定した焦点に基づいて、各テーブルオブジェクトに関連する他のディメンジョンに達するように設計される。
【００５４】
次いで、名前付きクエリを使用して、ディメンジョンモデルに関する論理ビューオブジェクトを作成する。これをブロック４０８に示す。次いで、各論理テーブルオブジェクトについて、他のテーブルオブジェクトがディメンジョンとしてリンクされたディメンジョンモデルキューブを構築する。これをブロック４１０で示す。図８に、ディメンジョンモデル中のマルチディメンジョンオブジェクトの一般化形式に対する１つの例示的なクラスダイアグラムを示す。図９に、具体化された１つの例示的なディメンジョンモデルを示す。この図は、Ｆａｃｔテーブルと、それに関連する様々なディメンジョンとの間の外部キー関係を示す。
【００５５】
説明する機能を実装するためにどのようにモデルサービスシステム２５０がその様々な構成要素を呼び出すかを示す擬似コードの別の実施形態を付録Ｃに示す。
【００５６】
ここで、その一例を図９に示すディメンジョンモデルは、オブジェクトモデル中の構造（組立および関連付け）から外部キー関係を推論することによって自動的に生成されることに留意されたい。ユーザは、その目的で設計されたツールを使用して、自動的に生成されたディメンジョンモデルにクエリを発することができる。上記で説明したように、ＭＤＸは、ディメンジョンデータベースのクエリを発するように設計された言語である。
【００５７】
図９で示すディメンジョンモデルのクエリを発するための例示的なクエリを図１０に示す。図１０は、ＭＤＸクエリ表現を含むクエリフィールド４３０を有するスクリーンショットを示す。図１０はまた、クエリが返した結果を含む結果フィールド４３２も含む。
【００５８】
上記でやはり示したように、ＭＤＸおよび他のディメンジョンモデルクエリ言語は、かなり複雑な構文を有することがあり、または学習するのが困難であることがある。したがって、本発明の別の実施形態は、自動的に作成されたディメンジョンモデルを、本明細書でＢＩエンティティ２６２と呼ぶ別の１組のオブジェクトに変換し、その結果ユーザは、ディメンジョンモデルクエリ言語で必要な複雑な構文表現ではなく、オブジェクト指向表現を使用してそれにクエリを発することができる。クライアントの報告要件を満たすためには、ディメンジョンモデルがオブジェクトモデル中の２つの異なるエンティティからの属性をそのディメンジョンとして有する可能性があるので、元のオブジェクトモデルのクエリを発するだけでは不十分である。したがって、ディメンジョンモデルにアクセスするのを容易にするために、本発明の一実施形態によれば、ＢＩエンティティ２６２が作成される。
【００５９】
ＢＩエンティティ２６２は、基礎となるディメンジョンモデル２５８の従来型オブジェクト指向ビューを提供する。したがってユーザは、効率的なクエリの基準を作成することができ、実際のディメンジョンモデルのクエリがユーザにとって透過的に実施されるような形でディメンジョンデータを使用することができる。ＢＩエンティティ２６２は、キューブ、ディメンジョン、階層、ネイティブクエリ言語などのディメンジョンモデルの詳細を隠し、ユーザが使用しなければならないのはオブジェクトおよび属性だけである。
【００６０】
図１１Ａに、エンティティジェネレータ２６０と、ＢＩサービス構成要素５０２、ＢＩ基準（ｃｒｉｔｅｒｉａ）構成要素５０４、およびＢＩメタデータ発見（ｄｉｓｃｏｖｅｒｙ）構成要素５０６をそれ自体含むデータアクセスシステム５００とを示す。図１１Ｂは、どのようにエンティティジェネレータ２６０がＢＩエンティティを生成するかをより良く示すフローチャートである。
【００６１】
ＢＩエンティティ２６２を生成するために、エンティティジェネレータ２６０が基礎となるディメンジョンモデル２５８にアクセスしたことを想起されたい。エンティティジェネレータ２６０はまず、ディメンジョンモデル２５８からＦａｃｔテーブルを取り出す。これは図１１Ｂのブロック５１０で示される。次いでエンティティジェネレータ２６０は、取り出したＦａｃｔテーブルに関する主ＢＩエンティティを生成する。Ｆａｃｔテーブル中の数値（または尺度）が、新しく作成したＢＩエンティティのプロパティとなる。取り出したＦａｃｔテーブルに関する主ＢＩエンティティの生成することを図１１Ｂのブロック５１２で示す。
【００６２】
次いでエンティティジェネレータ２６０は、Ｆａｃｔテーブルの各ディメンジョンについて主ではないＢＩエンティティを生成する。ディメンジョンモデルの元の構造、階層、およびレベルを維持するのに、入れ子になったクラスが使用できることに留意されたい。主ではないＢＩエンティティの生成することを図１１Ｂのブロック５１４で示す。ブロック５１６に示すように、エンティティジェネレータ２６０は、ディメンジョンモデル２５８中のＦａｃｔテーブルごとにこれらの操作を実施する。
【００６３】
図１２に、作成したディメンジョンモデルにアクセスするコードを生成するためにモデルサービスによって実装される１つの例示的なインターフェースを示す。このインターフェースにより、モデルサービスがディメンジョンモデルの構造に関する情報をコードジェネレータに搬送することが可能となる。ディメンジョンモデルは、尺度を有するキューブと、階層および属性を有するいくつかのディメンジョンとからなる。図１２は、ディメンジョンモデルの３つの構成要素間の関係を示す。エンティティジェネレータ２６０を起動するインターフェースを図１３に示す。付録Ｄに、システム２５０の様々な構成要素と、エンティティジェネレータ２６０とによってサポートされるインターフェースを示す。
【００６４】
図１４は、データアクセスシステム５００を使用して、ＢＩエンティティ２６２によって表されるデータにどのようにアクセスするかをより良く示すフローチャートである。まず、ユーザ入力クエリ５２０をデータアクセスシステム５００に与える。ユーザ入力クエリの受領を、図１４のブロック５２２で示す。ＢＩ基準構成要素５０４は、例示のようにインターフェースを提供し、これを介してユーザはユーザ入力クエリ５２０を入力することができる。ＢＩ基準インターフェースを図１５に示し、ＢＩ構成要素５０４に関する例示的なクラスダイアグラムを図１６で示す。
【００６５】
ＢＩサービス構成要素５０２は、ディメンジョンモデル２５８に対して実行することのできるＭＤＸ表現などのディメンジョンモデルクエリ表現に、ＢＩ基準５０４を介して入力されたユーザ入力クエリ５２０を変換する。ＢＩサービス構成要素５０２に関する１つの例示的なクラスダイアグラムを図１７に示す。ユーザ入力クエリ５２０をディメンジョンモデルに変換し、ディメンジョンモデルに対してディメンジョンモデルクエリを実行することを図１４のブロック５２４および５２６に示す。もちろん、ＭＤＸは一例として使用するに過ぎず、ＢＩ基準構成要素５０４によって様々なディメンジョンモデルクエリ表現をサポートすることができる。以下は、ＢＩサービス構成要素５０２およびＢＩ基準構成要素５０４によってサポートされるＭＤＸ表現の１つの例示的なリストであるが、他の表現、異なる表現、または追加の表現もサポートできることを強調しておく。
【００６６】
サポートされるＭＤＸセット関数
Ｃｒｏｓｓ  ｊｏｉｎ、ｃｈｉｌｄｒｅｎ、ｄｅｓｃｅｎｄａｎｔｓ、ａｎｃｅｓｔｏｒｓ、ａｌｌ  ｍｅｍｂｅｒｓ、ｍｅｍｂｅｒｓなど
【００６７】
サポートされるＭＤＸメンバ関数
ＣｕｒｒｅｎｔＭｅｍｂｅｒ、ＤｅｆａｕｌｔＭｅｍｂｅｒ、ＦｉｒｓｔＣｈｉｌｄ、ＬａｓｔＣｈｉｌｄ、Ｌｅａｄ、Ｌａｇなど
【００６８】
サポートされるＭＤＸ数値関数
Ａｖｅｒａｇｅ、Ａｇｇｒｅｇａｔｅ、ｃｏｕｎｔ、ｓｕｍ、ｍａｘ、ｍｉｎ、ｍｅｄｉａｎ、ＩＩＦなど
【００６９】
表１に、サポートされる例示的な１組のＭＤＸ演算子を列挙する。
【００７０】
【表１】
2004280823.tif 000003
【００７１】
以下に、Ｃシャーププログラミング言語でユーザ入力クエリ５２０を形成する１つの例示的な基準定義を示す。
【００７２】
【表２】
2004280823.tif 000004
【００７３】
【表３】
2004280823.tif 000005
【００７４】
ディメンジョンモデルクエリを実行した後、図１４のブロック５２８で示すように、ＢＩサービス構成要素５０２が結果セットを返す。
【００７５】
最後に、ＢＩメタデータ発見構成要素５０６も提供される。全システム的ＢＩエンティティ検索を実施し、１つまたは複数のＢＩエンティティに関して取り出した詳細なメタデータを返すために、ＢＩメタデータ発見構成要素５０６が例示的に提供される。もちろん、これはユーザにとって有用である。
【００７６】
どのようにデータにアクセスするかについての一例は役立つであろう。例えば、ディメンジョンモデル２５８中のＳａｌｅｓキューブが、２つの尺度ＳａｌｅｓＵｎｉｔｓおよびＳａｌｅｓＤｏｌｌａｒｓと、１つのディメンジョン「製品」を有し、このディメンジョンが１つの階層「猫」だけを有し、この階層が１つのレベル「カテゴリ」を有すると仮定する。生成されるＢＩクラスコードは、例示的には以下のようになる。
【００７７】
【表４】
2004280823.tif 000006
【００７８】
【表５】
2004280823.tif 000007
【００７９】
【表６】
2004280823.tif 000008
【００８０】
【表７】
2004280823.tif 000009
【００８１】
【表８】
2004280823.tif 000010
【００８２】
ＢＩ基準構成要素５０４を介して入力されるユーザ入力クエリの一例は以下の通りである。
【００８３】
【表９】
2004280823.tif 000011
【００８４】
ユーザ入力クエリに基づいて返される例示的な結果を図１８に示す。
【００８５】
以上により、本発明が従来のシステムに勝るいくつかの利点を提供することが理解される。本発明の一態様においては、オブジェクトモデルからディメンジョンモデルが自動的に生成される。自動生成は、オブジェクトモデル内で指定される関係およびユーザが設計した焦点からディメンジョンモデルを推論し、リレーショナルデータベースへのマッピングを行うことによって実行される。一実施形態によれば、ディメンジョンモデルの推論の基となる情報が、編成データスキーマ、例示的にはタグ付きフォーマットデータスキーマ（例えばＸＭＬデータスキーマ）に従ってジェネレータ（例えばモデルサービスジェネレータ）に供給される。
【００８６】
本発明の別の実施形態では、ディメンジョンモデルの詳細を抽象化するようにオブジェクトが提供される。したがって、ユーザは、何らかのディメンジョンモデルクエリ言語の特定の知識を必要とすることなく、オブジェクト指向表現だけを使用してディメンジョンモデルにアクセスすることができる。
【００８７】
もちろん、本発明の別の実施形態では、ユーザ指定オブジェクトモデルからディメンジョンモデルを自動的に作成し、ディメンジョンモデルを抽象化するエンティティも自動的に作成するように両者のシステムは一緒に使用される。したがって、ユーザが行わなければならないことは、焦点、オブジェクトモデルの記述、およびその永続データ記憶マッピングを与えることだけであり、本発明のこの実施形態においては、ディメンジョンモデルを手動で作成し、次いでディメンジョンモデルに対してディメンジョンモデル特有のクエリを生成するという手間のかかる作業を行うことなく、オブジェクト指向表現だけを使用して所望の報告構造に従ってデータにユーザがアクセスするために必要な構成要素が自動的に生成される。
【００８８】
図４Ａを参照して、モデルサービスシステム２５０は、入力として焦点２５２の指定、オブジェクト記述２５４、および１組の永続データ記憶マッピング２５６を取ると説明した。次いでシステム２５０は、その入力に基づいてディメンジョンモデル２５８を生成する。本発明の一態様によれば、ディメンジョンモデルの自律的生成をサポートするように、限定はしないがタグ付きフォーマットデータスキーマなどの標準化モデル定義スキーマが提供され、システム２５０の入力がフォーマットされる。
【００８９】
一実施形態によれば、標準化モデル定義スキーマは、オブジェクトリレーショナルモデルを指定し、余分なメタデータで装飾し、これによってディメンジョンモデルを推論することを可能にするＸＭＬスキーマである。一実施形態によれば、スキーマは、以下のデータ要素のいずれかまたはすべての記述をサポートする。
【００９０】
１．オブジェクト指向パラダイムでのクラス（スキーマ中のエンティティと例示される）およびそのデータメンバ（スキーマ中のフィールドと例示される）
２．どのようにクラスのデータメンバを、リレーショナルデータベース中のテーブルの列値から取り出したデータで満たすかを指定するオブジェクトリレーショナルマッピング
３．クラスのインスタンスを一意に識別する（クラスからの）キーフィールド
４．クラスのインスタンスを一意に識別し、キーフィールドよりも理解しやすい、クラス中の名前フィールド
５．データメンバのリンケージによってどのように表されるかを含む、クラス間の関連付けおよび組立の関係
６．ディメンジョンモデルの生成のために使用される注目の数値を表す尺度
例示的には、与えられる標準化スキーマ内で編成される情報に基づいて処理エンジン（例えばモデルサービスシステム２５０）が、ディメンジョンモデルを開発する（例えば、自律的に生成する）ように構成される。スキーマは、予測可能データフォーマットを処理エンジンに提供する。
【００９１】
一実施形態によれば、記述の目的で設計されたモデル定義スキーマの概観は、ＸＳＤを使用して以下のように表現される。
【００９２】
【表１０】
2004280823.tif 000012
【００９３】
【表１１】
2004280823.tif 000013
【００９４】
上記で定義されたスキーマ実施形態に関して、ルートＸＭＬタグは＜Ｅｎｔｉｔｉｅｓ＞タグである。このルートタグは、スキーマのタグの大部分と同様に、「ｎａｍｅ」と呼ばれる属性を有する。＜Ｅｎｔｉｔｉｅｓ＞タグのｎａｍｅ属性は、定義されるモデルに関する名前を与える。
【００９５】
＜Ｅｎｔｉｔｉｅｓ＞タグの下では、１つまたは複数の＜Ｅｎｔｉｔｙ＞要素が定義される。先に述べたように、エンティティは、例示するようにプログラミングのオブジェクト指向パラダイムでのクラスと同等である。エンティティは、名前、（継承階層内の）そのベースへの参照、および（組立階層内の）その親への参照を有する。＜Ｅｎｔｉｔｙ＞要素は、５つの潜在的子要素（テーブル、フィールド、関連付け、組立、および階層）を含む。
【００９６】
＜Ｔａｂｌｅ＞要素は、含まれる＜Ｅｎｔｉｔｙ＞のマッピングが行われる主データベーステーブルフィールドを指定する。これは、例示的には、物理データベーステーブル、またはＳＱＬステートメントの結果によって定義される論理テーブルでよい。
【００９７】
＜Ｆｉｅｌｄｓ＞要素は、エンティティを構成する複数の＜Ｆｉｅｌｄ＞要素を宣言するのに使用される。各＜Ｆｉｅｌｄ＞要素は、例示されるように、どのようにフィールドをデータベーステーブル列へのマッピングを行うかに関する情報を含む。
【００９８】
＜Ａｓｓｏｃｉａｔｉｏｎｓ＞要素および＜Ｃｏｍｐｏｓｉｔｉｏｎｓ＞要素は、それぞれ複数の＜Ａｓｓｏｃｉａｔｉｏｎ＞要素および＜Ｃｏｍｐｏｓｉｔｉｏｎ＞要素を宣言する。各＜Ａｓｓｏｃｉａｔｉｏｎ＞要素は、例示されるように、そのエンティティの１組のフィールドをどのように別のエンティティ中の１組のフィールドに多数から１への関係として関係付けるかを宣言する。各＜Ｃｏｍｐｏｓｉｔｉｏｎ＞要素は、１対多の関係ではあるが同様の目的を果たす。
【００９９】
＜Ｈｉｅｒａｒｃｈｉｅｓ＞下の＜Ｈｉｅｒａｒｃｈｙ＞要素は、レベルとして編成されたフィールドのサブセット（例えば、Ｃｏｕｎｔｒｙ、Ｓｔａｔｅ、Ｃｏｕｎｔｙ、およびＺｉｐ  Ｃｏｄｅ）間の意味的階層関係を宣言する。
【０１００】
こうしたタグ全体とその記述の一般的機能を念頭に置いて、上記およびその他のタグについての例示される詳細ならびに関係する属性に関する実施形態をこれから説明する。
【０１０１】
Ｅｎｔｉｔｉｅｓ
（説明）
＜Ｅｎｔｉｔｉｅｓ＞要素は、スキーマのルート要素（例えば、ＸＭＬ文書のルート要素）である。＜Ｅｎｔｉｔｉｅｓ＞要素は、定義されるモデルを表す。
【０１０２】
属性
ｎａｍｅ：ｎａｍｅはモデルを一意に識別する。ｎａｍｅは、ディメンジョンモデルで生成されるキューブの名前に対する基礎として使用される。
【０１０３】
ｎａｍｅｓｐａｃｅ：これは、推論したディメンジョンモデルからのデータアクセスを容易にするように生成されたコードに対して使用される任意選択の名前空間である。
【０１０４】
子要素
Ｅｎｔｉｔｙ：＜Ｅｎｔｉｔｉｅｓ＞要素は複数の＜Ｅｎｔｉｔｙ＞要素からなり、各＜Ｅｎｔｉｔｙ＞要素は、モデルに対して定義されるエンティティを指定する。
【０１０５】
Ｅｎｔｉｔｙ
（説明）
＜Ｅｎｔｉｔｙ＞要素は、モデルのエンティティを指定する。＜Ｅｎｔｉｔｙ＞要素は、オブジェクト指向プログラミングパラダイムにおけるクラスの概念を表す。
【０１０６】
属性
ｎａｍｅ：ｎａｍｅは、モデル内の１組のエンティティ中のエンティティを一意に識別する。ｎａｍｅは、ディメンジョンモデル内のエンティティに対して生成されるディメンジョンの名前に対する基礎として使用される。
【０１０７】
ｂａｓｅ：このタグは、継承階層内のこのエンティティに関するベースエンティティの名前を与える。
【０１０８】
ｐａｒｅｎｔ：このタグは、組立階層内のこのエンティティの親エンティティの名前を与える。親エンティティは、このエンティティに対して組立関係を有することになる。
【０１０９】
子要素
Ｔａｂｌｅ：＜Ｆｉｅｌｄｓ＞要素の下で宣言されたエンティティのフィールドがそこから値を取り出すことになる主データベーステーブルである。要素の使用を制御する規則に関しては、＜Ｔａｂｌｅ＞要素に関するセクションを参照されたい。
【０１１０】
Ｆｉｅｌｄｓ：これは、エンティティに対して定義された＜Ｆｉｅｌｄ＞要素のリストである。エンティティはまた、そのベースエンティティから追加のフィールドを継承する。継承したフィールドの定義およびデータベースマッピングを制御する規則に関しては、＜Ｆｉｅｌｄ＞要素に関するセクションを参照されたい。
【０１１１】
Ａｓｓｏｃｉａｔｉｏｎ：これは、エンティティに対して定義された＜Ａｓｓｏｃｉａｔｉｏｎ＞要素の任意選択のリストである。エンティティはまた、そのベースエンティティから追加の関連付けを継承することもできる。詳しくは＜Ａｓｓｏｃｉａｔｉｏｎ＞要素に関するセクションを参照されたい。
【０１１２】
Ｃｏｍｐｏｓｉｔｉｏｎｓ：これは、エンティティに対して定義された＜Ｃｏｍｐｏｓｉｔｉｏｎ＞要素の任意選択のリストである。エンティティはまた、そのベースエンティティから追加の組立を継承することもできる。詳しくは＜Ｃｏｍｐｏｓｉｔｉｏｎ＞要素に関するセクションを参照されたい。
【０１１３】
Ｈｉｅｒａｒｃｈｉｅｓ：これは、エンティティに対して定義された＜Ｈｉｅｒａｒｃｈｙ＞要素の任意選択のリストである。階層は、エンティティからのフィールドによって定義される。詳しくは＜Ｈｉｅｒａｒｃｈｙ＞要素に関するセクションを参照されたい。
【０１１４】
Ｔａｂｌｅ
（説明）
これは、＜Ｆｉｅｌｄｓ＞要素の下で宣言されたエンティティのフィールドがそこから値を取り出すことになる論理データベーステーブルである。テーブルは、実データベーステーブル、または与えたＳＱＬクエリから返るデータからなる仮想テーブルでよい。
【０１１５】
エンティティが、そのベースエンティティから、このエンティティの＜Ｆｉｅｌｄｓ＞要素下ではなく、ベースエンティティ＜Ｆｉｅｌｄｓ＞要素下で宣言される追加のフィールドを継承できることに留意されたい。その場合、そうしたフィールドは、テーブル名が空文字列でない場合、ベースエンティティの＜Ｔａｂｌｅ＞要素から値を取り出すことになる。そうでない場合、そうしたフィールドは、このエンティティの＜Ｔａｂｌｅ＞要素から値を取り出すことになる。
【０１１６】
このエンティティとそのベースエンティティの両方の＜Ｆｉｅｌｄｓ＞要素下で同一のフィールドが宣言される場合、このエンティティ下の定義が、例示的にはベースエンティティ下の定義を上書きすることになる。さらに、これにより、２つのエンティティ下で定義されたテーブル間の暗黙的リンクがフィールドに作成される。リンクを用いた２つのテーブルに対するデータベース結合操作が使用され、そのベースから継承されたものを含む、導出されたエンティティ内のフィールドの全セットについての値が取り出される。
【０１１７】
属性
ｎａｍｅ：これは、＜Ｆｉｅｌｄｓ＞要素下で宣言されたエンティティのフィールドがそこから値を取り出している論理データベーステーブルの名前である。エンティティが抽象である場合、そのフィールドが、その導出されたエンティティによってマッピングされているだけであり、テーブルの名前が空文字列である可能性があることを意味する。
【０１１８】
ｓｑｌ：これは、物理データベーステーブルが命名されていない場合、エンティティに関するデータを定義するＳＱＬクエリである。
【０１１９】
子要素
なし
Ｆｉｅｌｄ
（説明）
これは、エンティティに関するフィールドを宣言し、さらに任意選択で、エンティティに関して宣言したテーブル下のデータベース列にフィールドをマッピングする。
【０１２０】
属性
ｎａｍｅ：これはフィールドの名前である。フィールドがベースエンティティ下で宣言したフィールドのうち１つと同一の名前を有する場合、このエンティティ下の定義は、例示的には、データベーステーブルマッピングにより、ベースエンティティでの定義を上書きする。「ｃｏｌｕｍｎ」属性を参照されたい。
【０１２１】
ｔｙｐｅ：これは、フィールドのデータタイプである。可能なデータタイプの組は少なくとも、モデルを設計する対象のソフトウェアプラットフォームに依存する。限定はしないが、１つの例示的プラットフォームは、ワシントン州レドモンドのＭｉｃｒｏｓｏｆｔ（登録商標）  Ｃｏｒｐｏｒａｔｉｏｎが提供するＭｉｃｒｏｓｏｆｔ  ．ＮＥＴプラットフォームである。
【０１２２】
ｃｏｌｕｍｎ：これは、フィールドのマッピングが行われるテーブル中の列の名前である。同一のフィールドがベースエンティティでも宣言されている場合、この列マッピングが、例示的されるように、ベースエンティティでの列マッピングより優先される。しかし、この２つの列は、２つのエンティティ下の２つのテーブルに対するリンクも提供する。リンクは、結合クエリを構築して、導出したエンティティに関するフィールド値の全セット（ベースエンティティから継承したものを含む）を得るのに使用される。このエンティティに関するテーブル要素がその名前として空文字列を有する場合、列属性は、例示のように、その導出したエンティティのすべてにおいてこのフィールドのマッピングのためにデフォルト列名を与える。上記で説明したように、マッピングは上書きすることができる。
【０１２３】
ｓｑｌｔｙｐｅ：これは列についてのＳＱＬデータタイプを指定する。例えば、ｃｈａｒ（２０）ｉｎｔ、ｍｏｎｅｙなどである。
【０１２４】
ｋｅｙｃｏｌ：これは、フィールドがエンティティの主キーの一部であるか否かを示すのに使用される任意選択のブール値である。このように宣言されたキー列は、ディメンジョンモデルで構築されるディメンジョンのキー列となる。ｋｅｙｃｏｌプロパティは、任意の導出されたエンティティによってフィールドと共に継承される。
【０１２５】
ｎａｍｅｃｏｌ：これは、フィールドがエンティティの名前列であるか否かを示すのに使用される任意選択のブール値である。名前列は、ディメンジョンモデルに対するクエリの結果のセットの軸（ａｘｅｓ）で使用される。ｎａｍｅｃｏｌが宣言されない場合、キー列のうち１つが名前列として使用される。
【０１２６】
ｍｅａｓｕｒｅ：これは、ディメンジョンモデルにおいてキューブを構築する際にフィールドが焦点として使用されるか否かを示すのに使用される任意選択のブール値である。デフォルト値は「ｆａｌｓｅ」である。そのように宣言されたフィールドは、数値型であるべきである。
【０１２７】
ｔｉｍｅｄｉｍ：これは、同一のエンティティで宣言される尺度に関する時間ディメンジョンを構築するのにフィールドが使用されるか否かを示すのに使用される任意選択のブール値である。デフォルト値は「ｆａｌｓｅ」である。このように宣言されたフィールドは、ｄａｔｅｔｉｍｅ型とすべきである。
【０１２８】
子要素
なし
Ａｓｓｏｃｉａｔｉｏｎ
（説明）
関連付け（ａｓｓｏｃｉａｔｉｏｎ）は、含まれるエンティティを、多数から１への関係で別のエンティティとリンクする。関連付けは、含まれるエンティティ中のフィールドを他のエンティティ中のフィールドとそれぞれリンクするＦｉｅｌｄＲｅｆＰａｉｒの集合とによって定義される。
【０１２９】
属性
ｎａｍｅ：これは、関連付けを一意に識別する名前である。
【０１３０】
ｏｔｈｅｒｅｎｔｉｔｙ：これは、含まれるエンティティが関係付けられる（ｒｅｌａｔｅｄ）他のエンティティへの名前参照である。このエンティティは、同一のモデルで宣言されるべきである。
【０１３１】
ｈｉｅｒａｒｃｈｉｃａｌ：これは、このエンティティが他のエンティティと階層的に、意味的に関係付けられるか否かを示すのに使用される任意選択のブール値である。デフォルト値は「Ｆａｌｓｅ」である。例えば、「Ｃｏｕｎｔｙ」エンティティは、そのようにして「Ｓｔａｔｅ」エンティティに関係付けられる。これは、ディメンジョンモデル内に階層を構築する基礎を形成する。
【０１３２】
子要素
ＦｉｅｌｄＲｅｆＰａｉｒｓ：これは、このエンティティのフィールドを、関係付けるエンティティのフィールドとそれぞれ関係付けるＦｉｅｌｄＲｅｆＰａｉｒの集合である。詳しくは、ＦｉｅｌｄＲｅｆＰａｉｒのセクションを参照されたい。
【０１３３】
ＦｉｅｌｄＲｅｆＰａｉｒ
（説明）
これは、関連付け関係または組立関係の定義で有用な１対のフィールドへの参照である。フィールドのうち１つは、定義をホストするエンティティに属し、他のフィールドは、関係下で定義された他のエンティティに属する。この参照は実際には、関係するエンティティのベースエンティティの下で定義されたフィールドでよいことに留意されたい。
【０１３４】
属性
ｔｈｉｓｆｉｅｌｄ：これは、このエンティティ（またはそのベースエンティティのいずれか）中のフィールドへの名前参照である。
【０１３５】
ｏｔｈｅｒｆｉｅｌｄ：これは、含まれる関連付け関係または組立関係の他のエンティティ（またはそのベースエンティティのいずれか）中のフィールドへの名前参照である。
【０１３６】
子要素
なし
Ｃｏｍｐｏｓｉｔｉｏｎ
（説明）
組立（ｃｏｍｐｏｓｉｔｉｏｎ）は、エンティティを別のエンティティと１対多関係でリンクする。組立は、含まれるエンティティ中のフィールドを他のエンティティ中のフィールドとそれぞれリンクするＦｉｅｌｄＲｅｆＰａｉｒの集合によって定義される。
【０１３７】
属性
ｎａｍｅ：これは、組立を一意に識別する名前である。
【０１３８】
ｏｔｈｅｒｅｎｔｉｔｙ：これは、含まれるエンティティが関連付けられる他のエンティティへの名前参照である。このエンティティは、同一のモデルで宣言されるべきである。
【０１３９】
子要素
なし
Ｈｉｅｒａｒｃｈｙ
（説明）
階層は、このエンティティで定義されるフィールドのサブセット間の意味的階層関係を定義する。
【０１４０】
属性
ｎａｍｅ：これは、エンティティのコンテキスト内の階層を一意に識別する名前である。これは、エンティティに対して構築されたディメンジョン下で構築された階層を命名する基礎として使用される。
【０１４１】
子要素
Ｌｅｖｅｌｓ：これは、含まれるエンティティ中のフィールドをそれぞれ参照する＜Ｌｅｖｅｌ＞要素のリストである。詳しくは、＜Ｌｅｖｅｌ＞要素に関するセクションを参照されたい。
【０１４２】
Ｌｅｖｅｌ
（説明）
これは、含まれるエンティティ中のフィールドを参照する階層内のレベルである。
【０１４３】
属性
ｎｕｍｂｅｒ：これは、その含まれる階層中の要素のレベル番号である。低いレベル番号フィールドは、粒度（ｇｒａｎｕｌａｒｉｔｈｙ）が低い。例えば、Ｓｔａｔｅフィールドは、Ｃｏｕｎｔｙフィールドと同じ低いレベル番号を有する。
【０１４４】
ｆｉｅｌｄｒｅｆ：これは、レベルを定義する含まれるエンティティのフィールドへの名前参照である。
【０１４５】
子要素
なし
上述の標準化データスキーマ実施形態に関して、上述のスキーマタグ、ならびにその関連する属性および子要素の性質をさらに説明するため、例示のオブジェクトリレーショナルデータモデルをこれから与える。この例示のモデルは、いくつかの別個のエンティティ、すなわちＳａｌｅｓＤｏｃ、Ｃｕｓｔｏｍｅｒ、Ｏｒｄｅｒ、ＯｒｄｅｒＬｉｎｅ、Ｐｒｏｄｕｃｔ、Ｓｕｐｐｌｉｅｒ、およびＣａｔｅｇｏｒｙから構成される。このモデルは、基本的継承シナリオ、階層および階層関連付けの使用、ならびに時間ディメンジョンの宣言を含む。ＳａｌｅｓＤｏｃエンティティは、Ｏｒｄｅｒエンティティに対する抽象ベースエンティティであり、Ｏｒｄｅｒエンティティは、ＯｒｄｅｒＬｉｎｅとの組立関係を有し、Ｃｕｓｔｏｍｅｒとの関連付け関係を有する。Ｃａｔｅｇｏｒｙエンティティは、Ｐｒｏｄｕｃｔエンティティとの階層関連付け関係を有する。Ｏｒｄｅｒ．ＯｒｄｅｒＤａｔｅのフィールドは、「ｔｉｍｅｄｉｍ」属性でタグ付けされており、その結果時間ディメンジョンとして使用される。さらに、ＣｕｓｔｏｍｅｒエンティティおよびＳｕｐｐｌｉｅｒエンティティ中のフィールドの集合が、階層の一部であると宣言される。Ｏｒｄｅｒエンティティ下のＦｒｅｉｇｈｔフィールドおよびＯｒｄｅｒＬｉｎｅエンティティ下のＯｒｄｅｒＱｕａｎｔｉｔｙフィールドが、尺度としてマークされる。
【０１４６】
図１９に、記載の例示のオブジェクトリレーショナルデータモデルを表すＵＭＬダイアグラムを示す。
【０１４７】
上述の標準化データスキーマ実施形態に整合する形で編成されて、例示のオブジェクトリレーショナルデータモデルは以下のように特徴付けられ、フォーマットされる。
【０１４８】
【表１２】
2004280823.tif 000014
【０１４９】
【表１３】
2004280823.tif 000015
【０１５０】
【表１４】
2004280823.tif 000016
【０１５１】
記載のタグ付きフォーマットデータスキーマ内に編成されたこのデータにより、その基礎となるオブジェクトリレーショナルモデルを指定し、メタデータで装飾し、それによってディメンジョンモデルをそれから推定することが可能となる。一実施形態によれば、データスキーマをサポートするように構成された処理エンジンは、対応するディメンジョンモデルを自律的に生成する。
【０１５２】
図２０に、例示的オブジェクトリレーショナルデータモデルに対応し、記載の標準化データ表現内に編成されたデータに基づいて例示的に推論されたディメンジョンモデルを示す。
【０１５３】
本明細書で説明したように、モデルサービスエンジンは、対応するディメンジョンモデルを生成するために、モデル定義スキーマの形の情報を処理する。本発明の一態様によれば、記載のモデル定義スキーマ実施形態は少なくとも、モデルサービスエンジンが様々なソースモデルおよびターゲットモデルをサポートすることが可能となるよう十分拡張可能であるという点で有益であることを強調しておく。
【０１５４】
図２１は、記載のモデル定義スキーマの一実施形態に整合するフォーマットでデータ入力を提供するという拡張可能な特性を実証するアーキテクチャを示すブロック図である。
【０１５５】
オブジェクトリレーショナルモデルを指定する標準としてモデル定義スキーマ（ＭＤＳ）を採用することにより、ディメンジョンモデルを生成する問題を２つの別々の作業に分割することが可能となる。まず、図２１に示すように、一実施形態によれば、「ドライバ」（例えばドライバ１、ドライバ２、ドライバｎなど）と識別される構成要素が、一定のタイプのオブジェクトリレーショナルモデルをＭＤＳフォーマットに予備変換するように実装される。次に、「変換エンジン」と識別される別の構成要素が、ＭＤＳ情報からディメンジョンモデルを生成するように実装される。このアーキテクチャを使用して、同一のＭＤＳの周りに様々なドライバおよび変換エンジンを構築し、必要ならば混合および整合することにより、様々なソースモデルおよびターゲットモデルもサポートすることができる。
【０１５６】
ＭＤＳシステムの拡張可能性が、図２１で、それぞれソースモデル１、２、およびＭに基づくモデル１、２、およびＮの生成によって例示されている。この一般化は、モデル変換の複雑さをＮ（（ソース）×Ｍ（ターゲット）からＮ＋Ｍに低減できることを暗示している。ＭＤＳシステムの記載の拡張可能性が与えられたとすれば、任意のパーティ（例えばサードパーティベンダ）が、それ自身のドライバおよび変換エンジンを実装して、ＭＤＳを介して１つのモデルを他のモデルに変換することができる。したがって、例示的には、所与のオブジェクトモデルをＯｒａｃｌｅ  ＯＬＡＰ実装に変換し、またはＳｉｅｂｅｌをＳＱＬ分析サービススキーマに変換することを計画することができる。
【０１５７】
特定の実施形態を参照しながら本発明を説明したが、本発明の精神および範囲から逸脱することなく、形態および詳細に変更を加えることを当業者は理解されよう。
【０１５８】
（付録Ａ）ＸＭＬ焦点指定ファイルの一例である。
【０１５９】
【表１５】
2004280823.tif 000017
【０１６０】
（付録Ｂ）マッピングファイルの一例である。
【０１６１】
【表１６】
2004280823.tif 000018
【０１６２】
【表１７】
2004280823.tif 000019
【０１６３】
【表１８】
2004280823.tif 000020
【０１６４】
（付録Ｃ）モデルサービスシステムの動作を示す擬似コードの一例である。
【０１６５】
【表１９】
2004280823.tif 000021
【０１６６】
【表２０】
2004280823.tif 000022
【０１６７】
【表２１】
2004280823.tif 000023
【０１６８】
（付録Ｄ）モデルサービスシステムの構成要素と、ビジネスインテリジェンスエンティティジェネレータとによってサポートされるインターフェースを示すコードである。
【０１６９】
【表２２】
2004280823.tif 000024
【０１７０】
【表２３】
2004280823.tif 000025
【図面の簡単な説明】
【０１７１】
【図１】本発明を使用することのできる環境の１つの例示の実施形態である。
【図２】ビジネスロジックおよび報告構造を実装する従来技術のシステムを示す図である。
【図３】外部キー関係を示すディメンジョンモデルの一例である。
【図４Ａ】本発明の一実施形態のブロック図である。
【図４Ｂ】本発明の一実施形態によるＵＭＬクラスダイアグラムの形のオブジェクトモデル記述の一例である。
【図４Ｃ】図４Ａに示すシステムのより詳細なブロック図である。
【図５】本発明の一実施形態によるモデルサービス構成要素のより詳細なブロック図である。
【図６Ａ】図５に示すモデルサービス構成要素の動作をより良く示すフローチャートである。
【図６Ｂ】ＵＭＬクラスダイアグラムの形のオブジェクトモデル記述のより複雑な例である。
【図７】本発明の一実施形態によるディメンジョンモデルの作成を示すフローチャートである。
【図８】マルチディメンジョンモデルの一般化形に対するクラスダイアグラムの一実施形態である。
【図９】本発明の一実施形態によるディメンジョンモデルの特定の例である。
【図１０】ディメンジョンモデルに対する例示的クエリ、および対応する結果セットの一実施形態を示す図である。
【図１１Ａ】本発明の一実施形態に従ってビジネスエンティティを作成し、レポートを生成するシステムのブロック図である。
【図１１Ｂ】本発明の一実施形態によるビジネスインテリジェンスエンティティの作成を示すフローチャートである。
【図１２】作成したディメンジョンモデルにアクセスするコードを生成するためにモデルサービスによって実装される１つの例示的インターフェースを示す図である。
【図１３】ビジネスインテリジェンスエンティティジェネレータの機能を起動する例示される１つのインターフェースを示す図である。
【図１４】本発明の一実施形態に従って、どのようにビジネスエンティティからデータを取り出すかを示すフローチャートである。
【図１５】ＢＩ基準構成要素に対するインターフェースの１つの例示の実施形態を示す図である。
【図１６】ＢＩ基準構成要素に対するクラスダイアグラムの一実施形態を示す図である。
【図１７】ＢＩサービス構成要素の例示のクラスダイアグラムである。
【図１８】１つの例示の結果セットを示す図である。
【図１９】特定のオブジェクトリレーショナルデータモデルを示すＵＭＬダイアグラムを示す図である。
【図２０】図１９のＵＭＬダイアグラムに基づいて生成される特定のディメンジョンモデルを示す図である。
【図２１】アーキテクチャシステムを示すブロック図である。
【符号の説明】
【０１７２】
１００  コンピューティングシステム環境
１１０  コンピュータ
１２０  処理装置
１２１  システムバス
１３０  システムメモリ
１３１  読取り専用メモリ（ＲＯＭ）
１３２  ランダムアクセスメモリ（ＲＡＭ）
１３３  基本入出力システム（ＢＩＯＳ）
１３４  オペレーティングシステム
１３５  アプリケーションプログラム
１３６  他のプログラムモジュール
１３７  プログラムデータ
１４０  インターフェース
１４１  ハードディスクドライブ
１４４  オペレーティングシステム
１４５  アプリケーションプログラム
１４６  他のプログラムモジュール
１４７  プログラムデータ
１５０  インターフェース
１５１  磁気ディスクドライブ
１５２  取外し可能不揮発性磁気ディスク
１５５  光ディスクドライブ
１５６  取外し可能不揮発性光ディスク
１６０  ユーザ入力インターフェース
１７０  ネットワークインターフェース／アダプタ
１７１  ローカルエリアネットワーク（ＬＡＮ）
１７２  モデム
１７３  広域ネットワーク（ＷＡＮ）
１８０  リモートコンピュータ
１８５  リモートアプリケーションプログラム
１９０  ビデオインターフェース
１９１  モニタ
１９５  出力周辺インターフェース
１９６  プリンタ
１９７  スピーカ
２０１  リレーショナルデータベース
２０２  Ｃｕｓｔｏｍｅｒエンティティ
２０４  Ｏｒｄｅｒエンティティ
２０６  ＯｒｄｅｒＬｉｎｅエンティティ
２０８  データマート
２１０  モデル
２２０  Ｆａｃｔテーブル
２２２  ＴｉｍｅＩＤフィールド
２２４  ＣｕｓｔｏｍｅｒＩＤフィールド
２２６  Ｔｉｍｅテーブル
２２８  フィールド
２３０  Ｃｕｓｔｏｍｅｒテーブル
２３２  ＣｕｓｔｏｍｅｒＩＤ
２５０  モデルサービスシステム
２５２  焦点
２５４  オブジェクト記述
２５６  永続データ記憶マッピング
２５８  ディメンジョンモデル
２６０  エンティティジェネレータ
２６２  ビジネスインテリジェンスエンティティ
２６４  リレーショナルデータベース表現
２７０  ＢＩＯｒｄｅｒＦａｃｔエンティティ
２７２  ＢＩＯｒｄｅｒエンティティ
２７４  ＢＩＣｕｓｔｏｍｅｒエンティティ
３００  モデルサービス構成要素
３０２  マップシステム
３０４  ディメンジョンモデル構築システム
３０６  エンティティ関係（ＥＲ）マッパ
３０８  マップローダ
３１０  マップウォーカ
３１２  モデルジェネレータ
３１４  モデルマテリアライザ
３１６  モデルプロセッサ
３２２  直列化マップ
３２４  エンティティマップ（ＥＭ）オブジェクト
３２６  データセットスキーマ
３２８  クエリ
５００  データアクセスシステム
５０２  ＢＩサービス構成要素
５０４  ＢＩ基準構成要素
５０６  ＢＩメタデータ発見構成要素
５２０  ユーザ入力クエリ
【図１】
2004280823.tif 000026
【図２】
2004280823.tif 000027
【図３】
2004280823.tif 000028
【図４Ａ】
2004280823.tif 000029
【図４Ｂ】
2004280823.tif 000030
【図４Ｃ】
2004280823.tif 000031
【図５】
2004280823.tif 000032
【図６Ａ】
2004280823.tif 000033
【図６Ｂ】
2004280823.tif 000034
【図７】
2004280823.tif 000035
【図８】
2004280823.tif 000036
【図９】
2004280823.tif 000037
【図１０】
2004280823.tif 000038
【図１１Ａ】
2004280823.tif 000039
【図１１Ｂ】
2004280823.tif 000040
【図１２】
2004280823.tif 000041
【図１３】
2004280823.tif 000042
【図１４】
2004280823.tif 000043
【図１５】
2004280823.tif 000044
【図１６】
2004280823.tif 000045
【図１７】
2004280823.tif 000046
【図１８】
2004280823.tif 000047
【図１９】
2004280823.tif 000048
【図２０】
2004280823.tif 000049
【図２１】
2004280823.tif 000050
【外国語明細書】
2004280823000001.pdf