(57)【特許請求の範囲】
【請求項１】
コンテンツ管理システムにおいて複数のオブジェクトをレポーティングするためにコンピュータで実装される方法であって：
複数のオブジェクトを記憶デバイスに格納するステップと；
第１のオブジェクト、第２のオブジェクト及び前記第１のオブジェクトと前記第２のオブジェクトとの間の関係を定義するレポートタイプの定義を受け取るステップと；
前記レポートタイプの定義についてマルチオブジェクト・クエリ言語ステートメントを生成するステップと；
前記マルチオブジェクト・クエリ言語ステートメントを、第１のクエリと第２のクエリに分解するステップであって、前記第１のクエリが前記第１のオブジェクトに対応し、前記第２のクエリが前記第２のオブジェクトに対応する、ステップと；
前記第１のクエリ及び前記第２のクエリについて索引付きアクセスのクエリ定義を生成するステップと；
前記索引付きアクセスのクエリ定義内の前記第１のクエリに対応する前記第１のオブジェクトのＩＤと、前記索引付きアクセスのクエリ定義内の前記第２のクエリに対応する前記第２のオブジェクトのＩＤを、Ｌｕｃｅｎｅベースの検索エンジンから抽出するステップと；
前記第１のオブジェクトの抽出されたＩＤと、前記第２のオブジェクトの抽出されたＩＤを結合するステップと；
を含む、方法。
【請求項２】
結合結果について、インデックスを生成するステップ
を更に含む、請求項１に記載の方法。
【請求項３】
前記インデックスは、固定の２進表現である、
請求項２に記載の方法。
【請求項４】
前記インデックスについて、対応するデータファイルを生成するステップ
を更に含む、請求項３に記載の方法。
【請求項５】
前記インデックスに従って、前記Ｌｕｃｅｎｅベースの検索エンジンにおいてオブジェクトに対するインデックスアクセスを実行するステップ
を更に含む、請求項２に記載の方法。
【請求項６】
Ｓｏｌｒクエリを実行して、応答を返すステップ
を更に含む、請求項５に記載の方法。
【請求項７】
前記インデックスアクセスは、サイズベースである、
請求項５に記載の方法。
【請求項８】
インデックスアクセスの応答を事後処理して、表示するためのレポートを生成するステップ
を更に含み、前記レポートは、前記第１のオブジェクト及び前記第２のオブジェクトを備える、
請求項１に記載の方法。
【請求項９】
前記第１のオブジェクトで前記レポート内のデータをグループ化することを可能にするステップ
を更に含む、請求項８に記載の方法。
【請求項１０】
前記レポート内でデータを集計することを可能にするステップ
を更に含む、請求項８に記載の方法。
【請求項１１】
前記第１のオブジェクトの抽出されたＩＤと、前記第２のオブジェクトの抽出されたＩＤをＭｙＳＱＬへ存続させるステップ
を更に含む、請求項１に記載の方法。
【請求項１２】
インデックスアクセスの方式は、仮想記憶アクセス方式（ＶＳＡＭ）である、
請求項１に記載の方法。
【請求項１３】
前記の分解は、ＡＮＴＬＲベースの解析を介する、
請求項１に記載の方法。
【請求項１４】
ハッシュ関数を使用して前記の結合を実装する、
請求項１に記載の方法。
【請求項１５】
前記の結合は、内部結合及び外部結合を含む、
請求項１４に記載の方法。
【請求項１６】
前記の結合は、前記第１のオブジェクトと前記第２のオブジェクトとの間の外部キーの関係に基づく、
請求項１に記載の方法。
【請求項１７】
前記索引付きアクセスのクエリ定義に関与する前記第１のオブジェクト及び前記第２のオブジェクトのコストを計算するステップ
を更に含む、請求項１に記載の方法。
【請求項１８】
前記索引付きアクセスのクエリ定義が、前記第１のオブジェクトの更なるフィルタリングを必要とすることを決定するステップ
を更に含む、請求項１７に記載の方法。
【請求項１９】
結果のサイズを限定するよう前記第１のクエリを書き直すステップ
を更に含む、請求項１７に記載の方法。
【請求項２０】
コンテンツ管理システムであって、
複数のオブジェクトを格納する記憶デバイスと；
第１のオブジェクト、第２のオブジェクト及び前記第１のオブジェクトと前記第２のオブジェクトとの間の関係を定義するレポートタイプの定義を受け取り、該レポートタイプの定義についてのマルチオブジェクト・クエリ言語ステートメントを生成する、レポート実行エンジンと；
前記マルチオブジェクト・クエリ言語ステートメントを、前記第１のオブジェクトと前記第２のオブジェクトにそれぞれ対応する第１のクエリと第２のクエリに分解し、前記第１のクエリ及び前記第２のクエリについての索引付きアクセスのクエリ定義を生成し、Ｌｕｃｅｎｅベースの検索エンジンにおいて、インデックスに従ってオブジェクトについてのインデックスアクセスを実行する、クエリ言語実行エンジンと；
前記索引付きアクセスのクエリ定義内の前記第１のクエリに対応する前記第１のオブジェクトのＩＤと、前記索引付きアクセスのクエリ定義内の前記第２のクエリに対応する前記第２のオブジェクトのＩＤを、前記Ｌｕｃｅｎｅベースの検索エンジンから抽出し、前記第１のオブジェクトの抽出されたＩＤと、前記第２のオブジェクトの抽出されたＩＤを結合して前記インデックスを生成する、索引付きアクセス実行エンジンと；
を備える、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、一般にコンテンツ管理に関し、より具体的には、企業のコンテンツ管理におけるオブジェクトのレポーティングに関する。
【背景技術】
【０００２】
ユーザは、何時でも何処でもどのデバイスからでも管理されるユビキタスなアクセスのために、コンテンツ管理システムにますます依存する。しかしながら、一部の先行技術のコンテンツ管理システムは、そのシステム自体のレポーティングツールを有しておらず、システムのユーザは、第三者レポーティングツールを使用する必要がある。この第三者レポーティングツールは、ユーザが、完全に別個のデータストアを構築し、コンテンツ管理システムからデータをとり、これらのデータを第三者レポーティングツールへ移して変換することを要する。一部の先行技術のコンテンツ管理システムは、そのシステム自体のレポーティングツールを有するが、完全にドキュメント又はワークフローに対するものであり、通常はドキュメントごとのデータの行であるので、かなり柔軟性がない。図１は、先行技術のコンテンツ管理システムレポーティングツールによって提供される例示のレポートページを図示している。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
したがって、顧客が複雑なオブジェクトを使用して、リアルタイムデータを柔軟なフォーマットで定義又はレポーティングすることができるように、コンテンツ管理システムにおけるデータの相関を可能にすることが望ましい。
【課題を解決するための手段】
【０００４】
開示される主題は、コンテンツ管理システムにおいて、複数のオブジェクトをレポーティングするためのコンピュータで実装される方法に関する。この方法は：複数のオブジェクトを記憶デバイスに格納するステップと；第１のオブジェクト、第２のオブジェクト及び第１のオブジェクトと第２のオブジェクトとの間の関係を定義する、レポートタイプの定義を受け取るステップと；レポートタイプの定義についてのマルチオブジェクト・クエリ言語ステートメントを生成するステップと；マルチオブジェクト・クエリ言語ステートメントを、第１のクエリと第２のクエリに分解するステップであって、第１のクエリが第１のオブジェクトに対応し、第２のクエリが第２のオブジェクトに対応する、ステップと；第１のクエリ及び前記第２のクエリについての索引付きアクセスのクエリ定義（indexed  access  query  definition）を生成するステップと；索引付きアクセスのクエリ定義における第１のクエリに対応する第１のオブジェクトのＩＤと、索引付きアクセスのクエリ定義における第２のクエリに対応する第２のオブジェクトのＩＤを、Ｌｕｃｅｎｅ（ルシーン）ベースの検索エンジンから抽出するステップと；第１のオブジェクトの抽出されたＩＤと、第２のオブジェクトの抽出されたＩＤを結合（join）するステップと；を含む。
【図面の簡単な説明】
【０００５】
【図１】先行技術のコンテンツ管理システムにおいて、レポーティングツールにより提供される例示のレポートページを示す図である。
【図２】本発明が実装され得る企業コンテンツ管理アーキテクチャについての例示の高レベルブロック図である。
【図３】コンピューティングデバイスの例示のブロック図である。
【図４】ユーザコンピューティングデバイスの例示の高レベルブロック図である。
【図５】本発明の一実施形態による、図２に示される企業コンテンツ管理アーキテクチャ内のレポート実行エンジンについての例示の高レベルブロック図である。
【図６】本発明の一実施形態による、図２に示される企業コンテンツ管理アーキテクチャ内のクエリ言語実行エンジンについての例示の高レベルブロック図である。
【図７】本発明の一実施形態による、図２に示される企業コンテンツ管理アーキテクチャ内のコスト最適化エンジンについての例示の高レベルブロック図である。
【図８】本発明の一実施形態による、図２に示される企業コンテンツ管理アーキテクチャ内の索引付きアクセスの実行エンジンについての例示の高レベルブロック図である。
【図９Ａ】本発明の一実施形態による、図２に示される企業コンテンツ管理アーキテクチャ内で複数のオブジェクトをレポーティングするための方法の例示のフローチャートである。
【図９Ｂ】本発明の一実施形態による、図２に示される企業コンテンツ管理アーキテクチャ内で複数のオブジェクトをレポーティングするための方法の例示のフローチャートである。
【図１０】本発明の一実施形態による、マルチオブジェクトのレポーティングを開始する例示のグラフィカルユーザインタフェース（ＧＵＩ）を示す図である。
【図１１】本発明の一実施形態による、レポートのユーザ定義を受け取る例示のＧＵＩを示す図である。
【図１２】本発明の一実施形態による、コスト最適化のための方法の例示のフローチャートである。
【図１３】コンテンツ管理システムにおけるドキュメントを表示する例示のＧＵＩを示す図である。
【図１４】結合後の結果のインデックスファイルの例を示す図である。
【図１５】本発明の一実施形態による、生成されたマルチオブジェクトレポートの例を表示するＧＵＩを示す図である。
【発明を実施するための形態】
【０００６】
ここに記載される詳細な説明は、本技術の様々な構成の説明として意図されており、本技術が実施され得る構成のみを表すようには意図されていない。添付の図面はここに組み込まれ、詳細な説明の一部を構成する。詳細な説明は、本技術の全体的な理解を提供する目的で具体的な詳細を含んでいる。しかしながら、本技術は、ここで説明される具体的な詳細に限定されず、これらの具体的な詳細なしに実施されてもよい。一部の例において、周知の構造及びコンポーネントは、本技術の概念を曖昧にすることを避けるために、ブロック図の形式で示されている。
【０００７】
本技術は、コンテンツ管理システムにおいて複数のオブジェクトをレポーティングするための技術を対象とする。オブジェクトは、動的に変更可能なアイテム、例えばテーブルとすることができる。オブジェクトは、柔軟なフォーマットで格納され、検索エンジンにおいてインデックスを付けられることができる。検索エンジンは、例えばＬｕｃｅｎｅ（ルシーン）ベースの検索エンジンであってよく、Ｌｕｃｅｎｅベースの検索エンジンは、ドキュメントがテキストのフィールドを含むという考えに基づいている。この柔軟性は、ＬｕｃｅｎｅのＡＰＩがファイルフォーマットと独立であることを許容する。ＰＤＦ、ＨＴＭＬ、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｏｒｄ及びＯｐｅｎＤｏｃｕｍｅｎｔのドキュメントからのテキスト並びに多くの他のものからのテキストは、これらのテキストの情報を抽出することができる限りにおいて、全てインデックスを付けることができる。オブジェクトは、コンテンツ管理システムのサービスプロバイダ又は顧客によって、管理されるコンテンツ又はその一部分、例えば製品（プロダクト）（product）、ドキュメント又は国（country）に従って定義され得る。
【０００８】
コンテンツ管理システムにおいて、ドキュメントは、幾つかのプロパティ、例えば認められる場合には、製品、国、ファイル名、ファイルサイズ、ファイルタイプを有することができる。これらのプロパティのうちの１つ以上を、複数のプロパティ、例えばニックネーム、略称及び製品のタイプに更に関連付けることができる。ユーザがコンテンツ管理システム内でドキュメントを作成するとき、このユーザに、これらのプロパティを与えるかどうかを尋ねることができる。これらのプロパティを用いて、ユーザはデータを集計して、特定のプロパティ（例えば製品タイプ）を有する全てのドキュメントを見つけることができ、（例えば製品タイプによる又は国による）カウント、平均及び合計のような集計機能が提供され得る。ユーザは、データをグループ化することもでき、例えば最初に製品タイプによってデータをグループ化し、次いで国によってグループ化する、レポートを要求することもできる。したがって、オブジェクトがポインタしか有していないとしても、これは非常に複雑なオブジェクトである可能性がある。コンテンツ管理システムは、例えばその製品タイプがコレステロールの薬というドキュメントのみを表示するレポートを提供することにより、オブジェクトについてレポーティングし、フィルタをかけることが可能である必要がある。
【０００９】
変更があるといつもでも、全てのものが非正規化され、ユーザが検索基準に再び索引付けをしなければならない単一の大きな容量のオブジェクトを保持する代わりに、本発明のコンテンツ管理システムは、オブジェクトを構造化された別個の状態に保ち、データを分離し、そしてクエリに応答して、要求に応じて結合を実行することができる。データを小さなピースに区分しておくことは、コンテンツ管理システムを更に効率的かつ柔軟で、より維持しやすいものにすることを可能にする。
【００１０】
検索エンジンは、記憶デバイス内に格納されたオブジェクトをとることができ、結合エンジンは、検索エンジンから返されたオブジェクトを結合して、これらを複合オブジェクトに変えることができる。その情報は次いで、ドライバオブジェクト又はメインオブジェクトと、そのドライバオブジェクトに対する各オブジェクトの関連付けとを有するフォーマットで表示され得る。複数のオブジェクトが存在するとき、ある結合と別の結合との間の関係は非常に難しいことがある。例えばコンテンツ管理システム内のドキュメントは１５個の製品を有するが、１つのみが国であり、異なるオブジェクトであり得る。したがって、これらの個々のオブジェクトは、明らかに異なるが、関連付けられる。ユーザは、ドライバオブジェクトのソートには実際には影響を与えることなく、これらのオブジェクトの各々においてソートを行うことができる。
【００１１】
一実装において、検索エンジン、例えばＬｕｃｅｎｅベースの検索エンジンは、オブジェクトのための高速データストアとして使用され得る。レポートのユーザ定義が結合を必要とするとき、索引付きアクセス方式に基づくデータベース及び標準的なハッシュ結合を使用して、Ｌｕｃｅｎｅベースの検索エンジン用の結合を書くことができ、別個のＬｕｃｅｎｅのインデックスをとって、これらを結合して結合されたオブジェクトを作成することができる。索引付きアクセス方式は、例えば索引付き順次アクセス方式（ＩＳＡＭ：indexed  sequential  access  method）又は仮想記憶アクセス方式（ＶＳＡＭ：virtual  storage  access  method）とすることができる。
【００１２】
図２は、本発明が実装され得る企業コンテンツ管理アーキテクチャ２００の例示の高レベルブロック図を図示している。企業は会社や組織であってよい。示されるように、アーキテクチャ２００は、ネットワーク２５０を介して相互に結合される、コンテンツ管理システム２１０及び複数のユーザコンピューティングデバイス２２０ａ、２２０ｂ．．．２２０ｎを含み得る。コンテンツ管理システム２１０は、コンテンツ記憶デバイス２１１及びコンテンツ管理サーバ２１２を含み得る。ネットワーク２５０は、１つ以上のタイプの通信ネットワーク、例えばローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、イントラネットワーク、インターネットワーク（例えばインターネット）、電気通信ネットワーク及びピアツーピアネットワーク（例えばアドホック・ピアツーピアネットワーク）を含むことがあり、これらは有線又は無線とすることができる。
【００１３】
ユーザコンピューティングデバイス２２０ａ〜２２０ｎは、ユーザによってネットワーク２５０を介してコンテンツ管理システム２１０にアクセスするのに使用される任意のマシン又はシステムであってよく、ラップトップコンピュータ、デスクトップコンピュータ、モバイルフォン、スマートフォン、タブレットコンピュータ、ネットワーク及びパーソナルデジタルアシスタント（ＰＤＡ）を含め、任意の市販のコンピューティングデバイスであってよい。クライアントアプリケーション２２１は、ユーザコンピューティングデバイス、例えば２２０ａから実行することができ、ネットワーク２５０を介してコンテンツ管理システム２１０内のコンテンツにアクセスすることができる。ユーザコンピューティングデバイス２２０ａ〜２２０ｎは、図４により詳細に図示される。
【００１４】
コンテンツ記憶デバイス２１１は、ユーザコンピューティングデバイス２２０ａ〜２２０ｎ内のクライアントアプリケーション（例えば２２１）がアクセスし得るコンテンツを格納することができ、任意の市販の記憶デバイスであってよい。一実装において、コンテンツ記憶デバイス２１１は、電子トライアルマスターファイル（ｅＴＭＦ）を格納する。このファイルは、薬が通過することになる処理、並びに治験の立ち上げ、実行及び記録のあらゆる段階で臨床上の書類に対する供与スポンサー（giving  sponsor）及び開発業務受託機関（ＣＲＯ：contract  research  organizations）のリアルタイムアクセスを記録するのに使用されるマスターファイルである。このドキュメントにおいて、例えば薬剤を検査する場所を示す「サイト」と呼ばれるオブジェクトが存在することがある。ドキュメントは、「研究（study）」にも関連付けられてよく、この研究は、例えば研究のタイプのように幾つかの異なるプロパティを有することがある。
【００１５】
一実装において、コンテンツ記憶デバイス２１１は、品質のコントロール、セキュリティ及びコンプライアンスを改善する際に、製薬会社、バイオテクノロジー及び医薬製品の会社を助けるために、製品の作り方や標準的な操作手順（ＳＯＰ：standard  operating  procedure）、変更制御及び様々なＦＤＡの指示による電子ドキュメントといった、顧客のセキュアな機密コンテンツを格納することがある。顧客は、コアバージョンのコントロール、ドキュメントステータス及び完全なオーディット・トレールとともに、効果的なＳＯＰ及び関連する品質のドキュメントタイプを作成、確認、承認、発行及び生成することができ、承認を迅速化し、厳しい規制の遵守を保証する。典型的なオブジェクトは、例えばワークフロー、流通（分布）（distribution）及び施設（facility）を含み得る。
【００１６】
一実装において、コンテンツ記憶デバイス２１１は、標準的な応答ドキュメント（response  document）と医療上の手紙（medical  letter）及びＦＡＱを含む、医療上の通信を格納することができる。典型的なオブジェクトは、例えばドキュメント、ワークフロー、流通、製品及び国を含み得る。
【００１７】
一実装において、コンテンツ記憶デバイス２１１は、ライフサイエンス産業における宣伝用の資料（promotional  materials）を格納してもよい。典型的なオブジェクトは、例えばドキュメント、ワークフロー、流通、製品及び国を含み得る。
【００１８】
コンテンツ記憶デバイス２１１が他の産業のコンテンツを含んでもよいことを理解されたい。
【００１９】
コンテンツ管理サーバ２１２は、典型的に、例えばネットワーク２５０のようなリモート又はローカルのネットワークを介してアクセス可能なリモートコンピュータシステムである。コンテンツ管理サーバ２１２は、任意の市販のコンピューティングデバイスとすることができる。クライアントアプリケーション（例えば２１１）のプロセスが、１つ以上のコンピューティングデバイス２２０ａ〜２２０ｎ上でアクティブであってよく、対応するサーバプロセスは、コンテンツ管理サーバ２１２上でアクティブであり得る。クライアントアプリケーションプロセス及び対応するサーバプロセスは、ネットワーク２５０を介して相互に通信することができ、したがって分散機能を提供し、複数のクライアントアプリケーションがコンテンツ管理システム２１０の情報収集能力を利用することを可能にする。一実装において、コンテンツ管理サーバ２１２は、レポート実行エンジン２１３、クエリ言語実行エンジン２１４、コスト最適化エンジン２１５及び索引付きアクセス実行エンジン２１６を含むことができる。
【００２０】
レポート実行エンジン２１３は、レポートのユーザ定義を受け取り、次いでレポート定義を解析することができる。レポート実行エンジン２１３は、要求されたレポートが複数のオブジェクトを含むかどうかを判断し、複数のオブジェクトを含む場合、マルチオブジェクト・クエリ言語ステートメントを生成することができる。要求されたレポートが単一のオブジェクトしか含まないとき、レポート実行エンジン２１３は、単一オブジェクト・クエリ言語ステートメント生成することができる。レポート実行エンジン２１３は次いで、クエリの実行のために、クエリ言語ステートメントをクエリ言語実行エンジン２１４に送ることができる。レポート実行エンジン２１３は、クエリ言語実行エンジン２１４からクエリ実行結果を受け取り、この結果を事後処理して、ユーザフレンドリーなレポートを提示することができる。
【００２１】
クエリ言語実行エンジン２１４は、マルチオブジェクト・クエリ言語ステートメントをレポート実行エンジン２１３から受け取り、受け取ったマルチオブジェクト・クエリ言語ステートメントを解析して、関連するオブジェクトごとに個々のクエリへと分解（dissect）する。Ｌｕｃｅｎｅベースの検索エンジン自体は、索引付けをする検索ライブラリであり、クロール及びＨＴＭＬ解析機能を含まないので、解析は、ＡＮＴＬＲ（Another  Tool  for  Language  Recognition）に基づくものであってよく、一実装ではＪＡＶＡ（登録商標）オブジェクト内で行われてよい。クエリ言語実行エンジン２１４は、マルチオブジェクト・クエリ言語ステートメントが有効であるかどうかを判断し、有効な場合、実行計画を作成することができる。クエリ言語実行エンジン２１４は、オブジェクト間の関係を定義する個々のステートメントに基づいて、クエリ定義を生成することができる。一実装において、クエリ定義は、ＶＳＡＭクエリ定義であってよい。クエリ言語実行エンジン２１４は次いで、結果として得られるインデックスを索引付きアクセス実行エンジン２１６から受け取り、クエリを実行して、事後処理のために結果をレポート実行エンジン２１３に返すことができる。クエリ言語実行エンジン２１４はまた、単一オブジェクト・クエリ実行ステートメントをレポート実行エンジン２１３から受け取り、クエリを実行して、事後処理のために結果をレポート実行エンジン２１３に返すこともできる。一実装において、クエリの実行は、Ｓｏｌｒ（ソーラー）検索プラットフォームにおいて行われる。
【００２２】
コスト最適化エンジン２１５は、コストベースの最適化により、クエリを最適化することができる。コスト最適化エンジン２１５は、クエリ言語実行エンジン２１４からクエリ定義を受け取り、クエリ内で関与する各オブジェクトのコストを計算する。コスト最適化エンジン２１５は、追加のフィルタリングが必要かどうかを判断することができる。追加のフィルタリングが必要な場合、コスト最適化エンジン２１５は、ベースオブジェクトを実行して、子オブジェクトに対してクエリを最適化することができる。
【００２３】
索引付きアクセス実行エンジン２１６において、クエリ定義内のオブジェクトの各々について、一意のＩＤをＬｕｃｅｎｅ／Ｓｏｌｒから抽出することができ、各オブジェクトのメモリテーブル内においてＭｙＳＱＬに対してデータを存続（persist）させることができる。結合が外部キーの関係に基づいてオブジェクト間で実行され、予測される結果セットをフィルタダウンすることができる。結合の結果を、インデックスである固定の２進表現（fixed  binary  representation）に対してエクスポートすることができる。インデックスは、サイズベースのインデックスアクセス（index  access）を実行することができるクエリ言語実行エンジン２１４に返される。一実装において、データベース内で結合するためにハッシュ関数が使用され、このハッシュ関数をＬｕｃｅｎｅベースの検索エンジンと組み合わせて、柔軟なデータスキーマを維持することができる。
【００２４】
レポート実行エンジン２１３、クエリ言語実行エンジン２１４、コスト最適化エンジン２１５及び索引付きアクセス実行エンジン２１６は１つのサーバ内に示されているが、これらは複数のサーバ内で実装されてもよいことを理解されたい。
【００２５】
一実装において、コンテンツ管理システム２１０は、ハードウェア及びソフトウェアの様々な要素が１以上の顧客によって共有され得る、マルチテナントシステムとすることができる。例えばサーバは、複数の顧客からの要求を同時に処理することができ、コンテンツ記憶デバイス２１１は、複数の顧客についてのコンテンツを格納することができる。マルチテナントシステムでは、ユーザは典型的に、特定の顧客に関連付けられる。一例において、ユーザは、コンテンツ管理システム１０のテナント又は顧客である幾つかの製薬会社のうちの１つの従業員である可能性がある。
【００２６】
一実施形態において、コンテンツ管理システム２１０は、クラウドコンピューティングプラットフォーム上で動作することができる。ユーザは、仮想マシンイメージを使用することにより、あるいはクラウドデータベースプロバイダによって保持されるサーバへの購入アクセスにより、独立にクラウド上のコンテンツにアクセスすることができる。
【００２７】
一実施形態において、コンテンツ管理システム２１０は、ソフトウェア・アズ・ア・サービス（ＳａａＳ）として提供され、ユーザが、シンクライアントによりコンテンツ管理システム２１０へアクセスすることを可能にすることができる。
【００２８】
図３は、コンピューティングデバイス３００の例示のブロック図を示しており、コンピューティングデバイス３００は、図２のユーザコンピューティングデバイス２２０ａ〜２２０ｎ、レポート実行エンジン２１３、クエリ言語実行エンジン２１４、コスト最適化エンジン２１５及び／又は索引付きアクセス実行エンジン２１６として使用することができる。コンピューティングデバイス３００は、適切なコンピューティング環境の一例にすぎず、使用又は機能の範囲に関して如何なる限定を示唆するようにも意図されていない。コンピューティングデバイス３００は、処理ユニット３０１、システムメモリ３０２、入力デバイス３０３、出力デバイス３０４、ネットワークインタフェース３０５及びこれらのコンポーネントを相互に結合するシステムバス３０６を含み得る。
【００２９】
処理ユニット３０１は、例えばシステムメモリ３０２のような、コンピュータ読取可能媒体内に記憶されるコンピュータ命令を実行するように構成され得る。処理ユニット３０１は中央処理ユニット（ＣＰＵ）であってよい。
【００３０】
システムメモリ３０２は典型的に、様々なコンピュータ読取可能媒体を含み、このような媒体は、処理ユニット３０１によってアクセス可能な任意の利用可能な媒体であってよい。例えばシステムメモリ３０２は、読取専用メモリ（ＲＯＭ）及び／又はランダムアクセスメモリ（ＲＡＭ）といった揮発性及び／又は不揮発性メモリの形のコンピュータ記憶媒体を含むことができる。限定ではなく例として、システムメモリ３０２は、例えばオペレーティングシステム、プログラムモジュール、様々なアプリケーションプログラム及びプログラムデータといった、命令及びデータを格納することができる。
【００３１】
ユーザは、入力デバイス３０３を通してコマンド及び情報をコンピューティングデバイス３００に入力することができる。入力デバイス３０３は、例えばキーボード、タッチスクリーン入力デバイス、タッチパッド、マウス、マイクロフォン及び／又はペンとすることができる。
【００３２】
コンピューティングデバイス３００は、その出力を、出力デバイス３０４を介して提供することができ、出力デバイス３０４は、例えばモニタ若しくは他のタイプのディスプレイデバイス、スピーカ又はプリンタとすることができる。
【００３３】
コンピューティングデバイス３００は、ネットワークインタフェース３０５を介して、１つ以上の他のコンピューティングデバイスへの論理接続を使用して、ネットワーク環境又は分散環境内で動作することができ、そのような他のコンピューティングデバイスは、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、スマートフォン又は任意の他のメディア消費若しくは伝送デバイスであってよく、上述の要素のいずれか又は全てを含んでよい。論理接続は、ネットワーク（例えばネットワーク２５０）及び／又はバスを含み得る。ネットワークインタフェース３０５は、コンピューティングデバイス３００が、ネットワーク、例えばネットワーク２５０においてデータを送受信することを可能にするよう構成され得る。ネットワークインタフェース３０５は、１つ以上のネットワークインタフェースカード（ＮＩＣ）を含んでよい。
【００３４】
図４は、本発明が実装され得るユーザコンピューティングデバイス（例えば２２０ａ）の例示の高レベルブロック図を示す。ユーザコンピューティングデバイス２２０ａは、上述のコンピューティングデバイス３００によって実装されてよく、システムバス２２０６を介して相互に結合される処理ユニット２２０１、システムメモリ２２０２、入力デバイス２２０３、出力デバイス２２０４及びネットワークインタフェース２２０５を有することができる。システムメモリ２２０２は、クライアントアプリケーション２２１を格納することができる。
【００３５】
図５は、本発明の一実施形態に係るレポート実行エンジン２１３の例示の高レベルブロック図を示す。レポート実行エンジン２１３は、コンピューティングデバイス３００によって実装されてよく、システムバス２１３６を介して相互に結合される処理ユニット２１３１、システムメモリ２１３２、入力デバイス２１３３、出力デバイス２１３４及びネットワークインタフェース２１３５を有することができる。システムメモリ２１３２は、レポートタイプの定義を解析するためのレポートタイプ定義パーサ２１３７と、単一オブジェクト・クエリ言語ステートメントを生成するための単一オブジェクト・クエリ言語ステートメント・ジェネレータ２１３８Ｓと、マルチオブジェクト・クエリ言語ステートメントを生成するためのマルチオブジェクト・クエリ言語ステートメント・ジェネレータ２１３８Ｍと、クエリ言語実行エンジン２１４からの応答を処理して、ユーザに表示すべきレポートを生成するための事後処理ユニット２１３９とを格納することができる。
【００３６】
図６は、本発明の一実施形態に係るクエリ言語実行エンジン２１４の例示の高レベルブロック図を示す。クエリ言語実行エンジン２１４は、コンピューティングデバイス３００によって実装されてよく、システムバス２１４６を介して相互に結合される処理ユニット２１４１、システムメモリ２１４２、入力デバイス２１４３、出力デバイス２１４４及びネットワークインタフェース２１４５を有することができる。システムメモリ２１４２は、レポート実行エンジン２１３からのマルチオブジェクト・クエリ言語ステートメントを解析するためＡＮＴＬＲベースのパーサ２１４７と、索引付きアクセスのクエリ定義を生成するための索引付きアクセス・クエリ定義ジェネレータ２１４８と、レポート実行エンジン２１３からの単一オブジェクト・クエリ言語ステートメントを受け取るか、かつ／又はマルチオブジェクト・クエリ言語ステートメントのために索引付きアクセス実行エンジン１６によって生成されたインデックスを受け取り、インデックスアクセスを実行するための検索エンジン２１４９を格納することができる。
【００３７】
図７は、本発明の一実施形態に係るコスト最適化エンジン２１５の例示の高レベルブロック図を示す。コスト最適化エンジン２１５は、コンピューティングデバイス３００によって実装されてよく、システムバス２１５６を介して相互に結合される処理ユニット２１５１、システムメモリ２１５２、入力デバイス２１５３、出力デバイス２１５４及びネットワークインタフェース２１５５を有することができる。システムメモリ２１５２は、クエリ言語実行エンジン２１４からの索引付きアクセスのクエリ定義内に含まれる各オブジェクトのコストを計算するための計算機２１５７と、ベースオブジェクトを実行するためのベースオブジェクト実行エンジン２１５８と、子オブジェクトのクエリを最適化するようクエリを書き直すためのクエリ・リライター２１５９を格納することができる。
【００３８】
図８は、本発明の一実施形態に係る索引付きアクセス実行エンジン２１６の例示の高レベルブロック図を示す。索引付きアクセス実行エンジン２１６は、コンピューティングデバイス３００によって実装されてよく、システムバス２１６６を介して相互に結合される処理ユニット２１６１、システムメモリ２１６２、入力デバイス２１６３、出力デバイス２１６４及びネットワークインタフェース２１６５を有することができる。システムメモリ２１６２は、索引付きアクセスのクエリ定義内の各オブジェクトについて、Ｓｏｌｒ検索エンジンから一意のＩＤを抽出するためのエクストラクタ２１６７と、ＭｙＳＱＬに対してデータを存続させるためのデータ存続ユニット２１６８と、オブジェクト間の結合を実行するための結合エンジン２１６９を格納することができる。
【００３９】
図９Ａ〜図９Ｂは、本発明の一実施形態に従って、（図２に示されるような）企業コンテンツ管理システム２００内で複数のオブジェクトをレポーティングするための方法の例示フローチャートを示す。要求を行うユーザは、どのオブジェクトが関与し、かつこれらのオブジェクトがどのように関連するかを定義する、レポートタイプの定義を入力することができる。レポート実行エンジン２１３は、レポートタイプの定義をクエリ言語に変換するよう、クエリ言語ステートメントを生成する。クエリ言語実行エンジン２１４は、クエリ言語ステートメントを、個別の単一のピースに分解することができ、コスト最適化エンジン２１５は、オブジェクトを結合することがコスト効率が良いかどうかを判断し、索引付きアクセス実行エンジン２１６は、レポートタイプの定義に基づいてリンクを作成することにより、物理的には接続されないオブジェクトを結合することができる。その後、インデックスアクセス及びレポーティングが実行され得る。
【００４０】
処理は９０１において開始する。
【００４１】
９０２において、ユーザはクライアントアプリケーション２２１にログインして、コンテンツ管理システム２１０にアクセスするよう認証され得る。
【００４２】
９０３において、図１０に示されるようなＧＵＩ  １０００を表示することができる。ＧＵＩ  １０００は、コンテンツ管理システム２００と対話するためのユーザコマンドを受け取るメニューバー１００１を有することができる。一実装において、メニューバー１００１は、例えばＨＯＭＥ用の１００２、ＬＩＢＲＡＲＹ用の１００３、ＲＥＰＯＲＴＳ用の１００４及びＤＡＳＨＢＯＡＲＤＳ用の１００５といった、幾つかのボタン又はクリック可能なエリアを含むことができる。ユーザがレポートを実行したい場合、ユーザは、ＲＥＰＯＲＴＳボタンをクリックすることができる。
【００４３】
応答として、９０４において、図１１に示されるようなＧＵＩ  １１００を表示し、レポートのユーザ定義を受け取ることができる。一実装において、ＧＵＩ  １１００は、検索ウィンドウ１１０１、レポートタイプウィンドウ１１０２、フィルタウィンドウ１１０３及びグループウィンドウ１１０４を含め、ユーザ入力を受け取るための様々なウィンドウを有することができる。検索ウィンドウ１１０１は、ユーザからの検索語を受け取ることができる。レポートタイプウィンドウ１１０２は、レポートタイプについてのユーザ入力、例えば「ドキュメントを伴う製品（product  with  document）」又は「製品及び国を伴うドキュメント（document  with  product  and  country）」を受け取ることができる。フィルタウィンドウ１１０３は、ユーザが、レポート定義において１つ以上のフィルタを選択すること、例えば製品名「ＶＰＸＲ」をフィルタとして使用して、表示されるべきオブジェクトを、ＶＰＸＲに関連するオブジェクトのみに狭めることを可能にすることができる。グループウィンドウ１１０４は、ユーザが、レポート内の行をグループ化する方法、例えば製品によって又はドキュメントによってグループ化することを選択することを可能にすることができる。例えば総称や略称によって行をグループ化するよう、ドキュメントの更なるプロパティを追加してもよい。ユーザがレポートタイプ及びフィルタを選択して、「実行」ボタン１１０５をクリックすると、レポーティング処理が始まる。
【００４４】
９１１において、ＧＵＩ  １１００で受け取ったレポートタイプの定義を、レポート実行エンジン２１３、より具体的にはレポートタイプ定義パーサ２１３７において解析することができる。図１１に示されるＧＵＩ  １１００上で受け取った「ドキュメントを伴う製品」というレポートタイプの定義について、データベース内の解析されるレポートタイプの定義は：
Primary  object  is  product
public_key  is  product_with_document__c
report  type  definition  is,
<downRelationships>
<downRelationship  key="Product.document"  
keyRef="reportTypeRef1403542951011"  joinType="inner"  />
</downRelationships>
</reportType>
とすることができる。
【００４５】
９１２において、要求されたレポートが複数のオブジェクトを含むかどうかが判断される。
【００４６】
要求されたレポートが１つのオブジェクトのみを含むとき、例えば製品又は国を含むとき、９１３において、要求されたレポートを表す単一オブジェクト・クエリ言語ステートメントを、レポート実行エンジンによって、より具体的には単一オブジェクト・クエリ言語ステートメント・ジェネレータ２１３８Ｓによって生成することができる。処理は、次いで９２３に進み、クエリ言語実行エンジン２１４においてクエリを実行することができる。
【００４７】
要求されたレポートが複数のオブジェクトを含む場合、９１４において、マルチオブジェクト・クエリ言語ステートメントを、レポート実行エンジン２１３、より具体的にはマルチオブジェクト・クエリ言語ステートメント・ジェネレータ２１３８Ｍにおいて生成することができる。
【００４８】
一実装において、product__v及びcountry__vは、それぞれオブジェクトタイプcountry__v及びcountry__vのオブジェクト参照（ObjectReference）ドキュメントフィールドである。これらのドキュメントフィールドによって参照されるオブジェクトのオブジェクトレコードデータを選択するために、次のマルチオブジェクト・クエリ言語ステートメントを９１４で生成することができる：
SELECT  id,
(SELECT  external_id__v  FROM  document_product__vr),
(SELECT  name__v  FROM  document_country__vr)
FROM  documents
WHERE  name__v  =‘Test’                                      例（１）
【００４９】
マルチオブジェクト・クエリ言語ステートメントの例（１）では、オブジェクトフィールドは、フィールドで定義される関係パス表記（relationship  path  notation）を通してアクセスされる。document_product__vrとdocument_country__vrの関係は、それぞれドキュメントと製品の間及びドキュメントと国の間のＪＯＩＮ（結合）関係である。
【００５０】
９１４で生成されるマルチオブジェクト・クエリ言語ステートメントの別の例は：
SELECT  id,
(SELECT  external_id__v  FROMdocument_product__vr  WHERE  name__v＝
‘CLCP01’  LIMIT  100),
(SELECT  name__v  FROM  document_country__vr)
FROM  documents  FIND  "search  term"
WHERE  name__v  =‘Test’                                    例（２）
とすることができる。
【００５１】
９１４で生成されるマルチオブジェクト・クエリ言語ステートメントの更なる例は：
SELECT  id,  name__v,
(SELECT  id,  name__v,  major_version_number__v,
minor_version_number__v
FROM  document_product__vr)
FROM  product__v
WHERE  id  IN  (SELECT  product__v  FROM  document_product__vr)
例（３）
とすることができる。
【００５２】
マルチオブジェクト・クエリ言語ステートメントの例（３）は、図１１に示されるＧＵＩ  １１００で受け取られる、「ドキュメントを伴う製品」クエリに対応する。このクエリは、ドキュメント内で使用される製品を返すことになり、メインオブジェクトは製品である。
【００５３】
９１３及び９１４で生成されるクエリ言語ステートメントは、クエリ言語実行エンジン２１４に送ることができる。単一オブジェクト・クエリ言語ステートメントについては、９２３において、クエリ言語実行エンジン２１４が、クエリ、例えばＳｏｌｒクエリを実行して、レポート実行エンジン２１３に応答を返すことができる。処理は、事後処理のために９１６に進む。
【００５４】
９１４で生成されるマルチオブジェクト・クエリ言語ステートメントについては、９２１において、ステートメントが解析され、クエリ言語実行エンジン２１４において関与するオブジェクトごとに、個々のクエリへと分解され得る。一実装において、個々のクエリは、ＡＮＴＬＲベースの解析によって生成され、ＪＡＶＡ（登録商標）オブジェクトで実行され得る。ＡＮＴＬＲベースのパーサ２１４７がマルチオブジェクト・クエリ言語を解析して、これが有効であるかどうかを判断し、有効である場合にはクエリ計画を作成することができる。例えば上記のマルチオブジェクト・クエリ言語ステートメントの例（３）では、２つの個々のクエリ、すなわち製品から選択することと、ドキュメントから選択することが存在し得る。クエリ計画の例は：
Main  Query:  PRIMARY|358fac27-2248-4bb3-9df0-635a4b6b1d1d|SELECT
id  FROM  product__v  LIMIT  1000  OFFSET  0
Sub  Query:  CHILD|488e0503-f579-45d3-8009-5adc5a1a345e|SELECT
product__v,  id  FROM  documents  LIMIT  250  OFFSET  0
Join:  358fac27-2248-4bb3-9df0-635a4b6b1d1d|488e0503-f579-45d3-
8009-5adc5a1a345e|id|product__v|leftOuterJoin
Sub  Query:  CHILD|21e79b35-542b-420e-a012-d0b042d3334a|SELECT
product__v,  id  FROM  documents  LIMIT  250  OFFSET  0
Join:  358fac27-2248-4bb3-9df0-635a4b6b1d1d|21e79b35-542b-420e-
a012-d0b042d3334a|id|product__v|innerJoin
とすることができる。
【００５５】
９２２において、索引付きアクセスのクエリ定義を、クエリ言語実行エンジン２１４、より具体的には索引付きアクセス・クエリ定義ジェネレータ２１４８において、オブジェクト間の関係を定義する個々のステートメントに基づいて生成することができる。一実装では、索引付きアクセスのクエリ定義は、ＶＳＡＭクエリ定義とすることができる。上記に示されるマルチオブジェクト・クエリ言語ステートメントの例（２）に関して、索引付きアクセスのクエリ定義は：３つの異なるオブジェクト（すなわち、ドキュメント、製品及び国）が存在すること、子が存在すること、ドキュメントを、プライマリである製品及び子である国から選択する必要があること、とすることができる。
【００５６】
９３１において、コスト最適化エンジン２１５は、索引付きアクセスのクエリ定義を、クエリ言語実行エンジン２１４から受け取り、索引付きアクセスのクエリ定義内で関与する各オブジェクトのコストを計算することができる。マルチオブジェクト・クエリ言語ステートメントの例（３）についてのコスト計算の例は、次の通りである：
Driver,  ID=358fac27-2248-4bb3-9df0-635a4b6b1d1d
Cost=4
Solr=SELECT  id  FROM  product__v  ORDER  BY  id  asc  LIMIT  1000  OFFSET  0
Joins:
(0)  ID=21e79b35-542b-420e-a012-d0b042d3334a
Type=innerJoin  (parent_0),  CHILD        Cost=10
Solr=SELECT  product__v,  id  FROM  documents  LIMIT  250  OFFSET  0
(1)  ID=488e0503-f579-45d3-8009-5adc5a1a345e
Type=leftOuterJoin,  CHILD        Cost=10
Solr=SELECT  product__v,  id  FROM  documents  ORDER  BY  product__v  asc  
LIMIT  250  OFFSET  0
【００５７】
９３２において、追加のフィルタリングが必要であるかどうかをコスト最適化エンジン２１５において判断することができる。マルチオブジェクト・クエリ言語ステートメントの例（１）のように、追加のフィルタリングが必要でない場合、処理は９４１に進み、索引付きアクセス実行、例えばＶＳＡＭ実行を行うことができる。
【００５８】
追加のフィルタリングが必要な場合、コスト最適化エンジン２１５は、９３３において、ベースオブジェクトを実行し、次いで子オブジェクトに対してクエリを最適化することができる。例えばマルチオブジェクト・クエリ言語ステートメントの例（２）は、子オブジェクトをフィルタするようベースオブジェクトを必要とするWHERE節「WHERE  name__v=‘Test’」を含むので、マルチオブジェクト・クエリ言語ステートメントの例（２）では、追加のフィルタリングが必要となる。同様に、マルチオブジェクト・クエリ言語ステートメントの例（３）では、ドキュメント内で使用される製品を選択するように、WHERE節は、子オブジェクト「ドキュメント」によってベースオブジェクト「製品」をフィルタリングすることを必要とする。
【００５９】
最適化は、データに依存し得る。一実装では、９３４において、データの量が閾値を超えるかどうかを判断することができる。閾値を超えない場合、最適化エンジン２１５は、図１２に関連して以下で説明されるように、９３５において、より効率的になるようクエリを書き直すことができ、そして処理は９４１に進み、索引付きアクセス実行、例えばＶＳＡＭ実行を行うことができる。例えばマルチオブジェクト・クエリ言語ステートメントの例（２）は、高度なフィルタオプションである可能性が最も高いので、９３５においてクエリが書き直されることがある。一方、多数のデータのピースが存在する場合、例えばデータの各ピースを、データの他の全てのピースに対して結合する必要があるとき、クエリを書き直すことは、処理をより効率的なものにしないので、処理は、書き直し処理をスキップして直接９４１に進み、結合を実行する。コスト最適化エンジン２１５は、オブジェクトのサイズ及び結果の予想サイズを含め、幾つかの異なるコスト影響を考慮し得る。
【００６０】
図１２は、本発明の一実施形態に係るコスト最適化の方法の例示のフローチャートを示す。示されるように、１２０１において、それぞれ個々のクエリにより返される行の数を決定することができる。一実施形態では、外部結合（outer  join）の前に内部結合（inner  join）をチェックする。内部結合の個々のクエリのいずれかがゼロ行を返す場合は、空の結果セットを返すことができる。１２０２において、個々のクエリを、例えば行の数によって最低から最高まで各々について再順序付けすることができる。１２０３において、個々のクエリは、ベースクエリ又はドライバクエリから導かれる追加のWHERE節を追加することにより最適化され得る。
【００６１】
一実装において、WHERE節を個々のクエリに追加して、コスト最適化について処理すべき行を減らすことができる。ベース又はドライバクエリが製品に基づくとき、後続の個々のクエリも製品を有する必要があり、したがってWHERE節は：
“WHERE  product__v  !=  null”
とすることができる。
【００６２】
一実装において、元のクエリは「ドキュメントを伴う製品」であり、これに対するフィルタ、例えば「return  only  product  =  CC」（製品＝CCのみを返す）を有する。最適化中に、製品のクエリを最初に実行することができる。続いて、下記のWHERE節をドキュメントのクエリに追加して、ドキュメントのクエリからの中間結果を限定することができ、その結果、後続のステップにおいて処理すべきデータはより少なくなる：
“WHERE  product__v  =  ‘CC’”
【００６３】
図９に戻る。９４１において、索引付きアクセス実行が、索引付きアクセス実行エンジン２１６において開始され、索引付きアクセスのクエリ定義内のオブジェクトの各々について、一意のＩＤがＬｕｃｅｎｅ／Ｓｏｌｒから抽出され得る。一実装では、ドキュメントについての一意のＩＤを「ＩＤ」とし、製品についての一意のＩＤを「ドキュメントＩＤ，ＩＤ」とすることができる。一実装において、マルチオブジェクト・クエリ言語ステートメントの例（２）では、ＩＤと、当該ＩＤに関連付けられる製品と、当該ＩＤに関連付けられる国とを選択することができる。製品及び国は、ドキュメントからのものであってよい。次いで製品及び国から、これらのＩＤを選択することができる。
【００６４】
９４２において、ＩＤの各々を、ＭｙＳＱＬに個別のメモリテーブルへと存続させることができる。出力セットのサイズが閾値を超えるときは、メモリテーブルの代わりに、ディスクに格納してもよい。存続の例は、次の通りである：
Execute  Primary  Table  SQL  :  CREATE  TEMPORARY  TABLE  
d358fac2722484bb39df0635a4b6b1d1d  (row_num  BIGINT  UNSIGNED  NOT  NULL
AUTO_INCREMENT,  id  CHAR(20),  PRIMARY  KEY(row_num))
INSERT  INTO  PRIMARY  :  INSERT  INTO  d358fac2722484bb39df0635a4b6b1d1d(id)  
VALUES  (?)
Execute  JOIN  Table  SQL  :  CREATE  TEMPORARY  TABLE  
c488e0503f57945d380095adc5a1a345e  (row_num  BIGINT  UNSIGNED  NOT  NULL  
AUTO_INCREMENT,  fk  CHAR(20),  id  CHAR(20),  PRIMARY  KEY(row_num))
INSERT  INTO  JOIN  TABLE  :  INSERT  INTO  
c488e0503f57945d380095adc5a1a345e(fk,id)  VALUES  (?,?)
Execute  JOIN  Table  SQL  :  CREATE  TEMPORARY  TABLE  
c21e79b35542b420ea012d0b042d3334a  (row_num  BIGINT  UNSIGNED  NOT  NULL  
AUTO_INCREMENT,  fk  CHAR(20),  id  CHAR(20),  PRIMARY  KEY(row_num))
INSERT  INTO  JOIN  TABLE  :  INSERT  INTO  
c21e79b35542b420ea012d0b042d3334a(fk,id)  VALUES  (?,?)
Execute  Primary  Table  SQL  :  CREATE  TEMPORARY  TABLE  
j8fb43757c91f41038b4bac735cabc4f4  (row_num  BIGINT  UNSIGNED  NOT  NULL  
AUTO_INCREMENT,  id  CHAR(20),  PRIMARY  KEY(row_num))
PERFORM  JOIN  :    INSERT  INTO  j8fb43757c91f41038b4bac735cabc4f4(id)  
SELECT  d358fac2722484bb39df0635a4b6b1d1d.id  FROM
d358fac2722484bb39df0635a4b6b1d1d,c488e0503f57945d380095adc5a1a345e    
WHERE  c488e0503f57945d380095adc5a1a345e.fk  =  
d358fac2722484bb39df0635a4b6b1d1d.id  ORDER  BY
d358fac2722484bb39df0635a4b6b1d1d.row_num
CREATE  CHILD  INDEX  TABLE  :  SELECT  DISTINCT  
LPAD(IFNULL(j8fb43757c91f41038b4bac735cabc4f4.id,0),20,'  ')  INTO  
OUTFILE  '/data2/reports/instance_2/358fac27-2248-4bb3-9df0-
635a4b6b1d1d/358fac27-2248-4bb3-9df0-635a4b6b1d1d.idx'  FIELDS  
TERMINATED  BY  ','  LINES  TERMINATED  BY  '\n'  FROM  
j8fb43757c91f41038b4bac735cabc4f4  ORDER  BY  row_num
CREATE  FILE  INDEX:  SELECT  j8fb43757c91f41038b4bac735cabc4f4.id,
LPAD(IFNULL(min(t.min),0),9,'0'),  LPAD(IFNULL(max(t.max),0),9,'0')  INTO  
OUTFILE  '/data2/reports/instance_2/358fac27-2248-4bb3-9df0-
635a4b6b1d1d/358fac27-2248-4bb3-9df0-635a4b6b1d1d.idx'  FIELDS  
TERMINATED  BY  ','  LINES  TERMINATED  BY  '\n'  FROM  
j8fb43757c91f41038b4bac735cabc4f4  LEFT  OUTER  JOIN  (SELECT  fk  AS  col,  
min(row_num)  AS  min,  max(row_num)  AS  max  FROM  
c21e79b35542b420ea012d0b042d3334a  GROUP  BY  col)  AS  t  ON
j8fb43757c91f41038b4bac735cabc4f4.id  =  t.col  GROUP  BY  1  ORDER  BY
j8fb43757c91f41038b4bac735cabc4f4.row_num
【００６５】
この例では、INSERT（挿入）は、ＳｏｌｒからのデータをＭｙＳＱＬテーブルにプルするのに使用され、最後のSELECT...  INTO  OUTFILEの行は、インデックス及びデータファイルが生成される場所である。
【００６６】
９４３において、リンクとして使用される外部キーの関係に基づいて、全てのオブジェクトの間で結合が実行され、予測された結果セットをフィルタダウンする。結合の処理は、マルチオブジェクト・クエリ言語ステートメントの例（３）では「ドキュメントを伴う製品」というレポートタイプの定義の要件に合致する、オブジェクトの組み合わせを見つけることになる。ドキュメントがいずれの製品も使用しない場合、あるいは製品が、該製品に関連付けられるいずれのドキュメントも有さない場合、これらは、結合の結果には含まれない。
【００６７】
一実施形態において、ハッシュ関数を使用して、データベース内で結合を実装することができ、結合には、内部結合及び外部結合が含まれ得る。
【００６８】
９４４において、結合の結果を、ファイルシステム内の固定の２進表現にエクスポートすることができ、この固定の２進表現は基本的にインデックスである。マルチオブジェクト・クエリ言語ステートメントの例（２）に対する結合の後に結果として得られるインデックスファイルの例が、図１３に示されている。示されるように、データは３つのインデックスファイル：すなわち、プライマリの第１のファイルと、製品についての第２のファイルと、国についての第３のファイルとに分割され得る。第１のファイルは、ドキュメントＩＤと、製品についての子の行開始（row  start）と、製品についての子の行終了（row  end）と、国についての子の行開始と、国についての子の行終了とを有することができる。最初の列は、ドキュメントＩＤが１であり、０として開始し、３として終了することを示す。製品についての２つ目のファイルでは、行ＩＤ０〜５に対して、最初の３つの行０、１及び２が、１つ目のファイル内のデータ（１，０，３）のチャンクに関連付けられ、次の２つの行が、１つ目のファイル内の（２，４，５）を表す。読み取りアルゴリズムは、ドキュメント、すなわちドライバの行にジャンプし、製品についての子の行開始を読み取り、次いでバイト計算に基づいて読み取る。国についての３つ目のファイルを同様の方法で読み取ることができる。実際のファイルは、データセットの全ては取得せずにそのＩＤのみを取得するので、かなり小さい。
【００６９】
一実施形態において、コンテンツ管理システム２１０内の製品は、ＣＣ、ＶＰ、ＶＰＸＲ及びＷＤを含むことができる。図１４は、コンテンツ管理システム内のドキュメントを表示する例示のＧＵＩ  １４００を図示している。示されるように、コンテンツ管理システム内には１０個のドキュメントが存在する。ＧＵＩ１４００は、どの製品がどのドキュメントによって使用されるかについても表示することができる。例えばドキュメントＴｅｓｔ４、Ｔｅｓｔ２及びＴｅｓｔ１の各々は、製品ＣＣを使用し、ドキュメントＮｕｍｂｅｒ１０は、製品ＣＣ及びＶＰＸＲを使用し、ドキュメントＴｅｓｔ５は製品ＶＰを使用する。内部結合ロジックを使用して同じであるものを示すことができる、例えば製品ＣＣがＴｅｓｔ１、Ｔｅｓｔ２、Ｔｅｓｔ４及びＮｕｍｂｅｒ１０によって使用されるという事実に関心を有する。マルチオブジェクト・クエリ言語ステートメントの例（３）の索引付きアクセス実行の間、結合後の結果インデックスファイル及びその対応するデータファイルの例を下記に示す。製品ＷＤはいずれのドキュメントにおいても使用されていないので、これはクエリ結果では返されず、結果インデックスファイルにも含まれない。  
結果インデックスファイル
【表１】
0005944039.tif 000002
対応するデータファイル
【表２】
0005944039.tif 000003
【００７０】
結果のデータファイル内の最初の列は、製品キーであり、この製品キーは製品テーブルからのＩＤである。次の２つの列は、これらのキーは有効であるデータファイル内の開始行及び終了行である。結果インデックスファイルの１番目の行は、製品ＣＣを使用するドキュメントである。対応するデータファイルにおいて、これらのドキュメントのＩＤは１、２、４、１０である。結果インデックスファイル内の２番目の行は、対応するデータファイル内の行５〜行５が、製品キーとしてＶＰを有するドキュメントであることを示す。対応するデータファイルにおいて、ドキュメントのＩＤは５である。結果インデックスファイルの３番目の行は、対応するデータファイル内の行６〜行６が、製品ＶＰＸＲを使用するドキュメントであることを示す。対応するデータファイルにおいて、ドキュメントのＩＤは１０である。
【００７１】
図９Ｂに戻る。９４５において、結果として得られるインデックスが、クエリ言語実行エンジン２１４に返され、クエリ言語実行エンジン２１４においてサイズベースのインデックスアクセスを実行することができる。その後、その結果を、レポート実行エンジン２１３に返すことができる。一実装において、ＪＳＯＮ内のクエリ言語実行エンジン２１４からの結果は：
{
"responseStatus":"SUCCESS",
"responseDetails":{
"find":"search  term",
"limit":500,
"offset":500,
"size":500,
"totalFound":2000,
"previous_page":"/api/v9.0/query/00Q12334586932?limit=500&offset=0",
"next_page":"/api/v9.0/query/00Q12334586932?limit=500&offset=1000"
},
"data":[
{
"id":1,
"document_product__vr":{
"responseDetails":{
"limit":250,
"offset":0,
"size":250,
"totalFound":500,
"next_page":"/api/v9.0/query/00Q448829222?limit=250&offset=250"
},
"data":[
{
"external_id__v":"EXTID123"
}
]
},
"document_country__vr":{
"responseDetails":{
"limit":250,
"offset":250,
"size":250,
"totalFound":1000,
previous_page":"/api/v9.0/query/00Q24845839872?limit=250&offset=0",
"next_page":"/api/v9.0/query/00Q24845839872?limit=250&offset=500"
},
"data":[
{
"name__v":"Austria"
},
{
"name__v":"Costa  Rica"
}
]
}
}
]
}
であり得る。
【００７２】
一実装において、クエリ言語実行エンジン２１４からの結果は、ＸＭＬでは、
<?xml  version="1.0"  encoding="utf-16"?>
<ResultSetRestResult>
<responseStatus>SUCCESS</responseStatus>
<responseDetails>
<find>search  term</find>
<limit>500</limit>
<offset>500</offset>
<size>500</size>
<totalFound>2000</totalFound>
<previous_page>/api/v9.0/query/00Q12334586932?limit=500&amp;offset=0</previous_page>
<next_page>/api/v9.0/query/00Q12334586932?limit=500&amp;offset=1000</next_page>
</responseDetails>
<data>
<id>1</id>
<document_product__vr>
<responseDetails>
<limit>250</limit>
<offset>0</offset>
<size>250</size>
<totalFound>500</totalFound>
<next_page>/api/v9.0/query/00Q448829222?limit=250&amp;offset=250</next_page>
</responseDetails>
<data>
<external_id__v>EXTID123</external_id__v>
</data>
</document_product__vr>
<document_country__vr>
<responseDetails>
<limit>250</limit>
<offset>250</offset>
<size>250</size>
<totalFound>1000</totalFound>
<previous_page>/api/v9.0/query/00Q24845839872?limit=250&amp;offs  t=0</previous_page>
<next_page>/api/v9.0/query/00Q24845839872?limit=250&amp;offset=500</next_page>
</responseDetails>
<data>
<name__v>Austria</name__v>
</data>
<data>
<name__v>Costa  Rica</name__v>
</data>
</document_country__vr>
</data>
</ResultSetRestResult>
であり得る。
【００７３】
これらのＩＤにより、クエリ言語実行エンジン２１４は、必要とされる実際のピースは、オブジェクトの外部ＩＤに対するものであると判断し、これらのＩＤに基づいて必要なデータのピースをプルし得る。データの代わりに単にＩＤについて結合し、データを正しい順序にすることで、索引付きアクセス実行エンジン２１６によりその性質「による順序付け」又は指示をサポートし、その後、クエリ言語実行エンジン２１４によりデータにアクセスして提供することによって、コンテンツ管理サーバ２１２は、クエリ処理を大いにスピードアップすることができ、最終的な結果セットをリアルタイムで提供することができる。
【００７４】
９１６において、クエリ言語実行エンジン２１４からの結果は、レポート実行エンジン２１３内の事後処理ユニット２１３９において事後処理を通過し、プレゼンテーションレイヤに置かれ、その結果、よりユーザフレンドリーなレポートにフォーマットされて提示され得る。
【００７５】
図１５は、マルチオブジェクト・クエリ言語ステートメントの例（３）について、９１６で生成されるレポートの例を表示するＧＵＩ  １５００を図示している。ＧＵＩ  １５００上に示されるように、６つの行が返され、この６つの行は、製品ＣＣについての４つのドキュメント（すなわち、Ｔｅｓｔ１、Ｔｅｓｔ２、Ｔｅｓｔ４及びＮｕｍｂｅｒ１０）と、製品ＶＰについての１つのドキュメント（すなわち、Ｔｅｓｔ５）と、製品ＶＰＸＲについての１つのドキュメント（すなわち、Ｎｕｍｂｅｒ１０）を含む。製品ＷＤはいずれのドキュメントにおいても使用されていないので、クエリ結果では返されない。内部結合が、製品ＷＤを結果セットから効果的に除外した。フィルタ１１０３がＣＣに対して設定される場合、３つのドキュメントを伴うＣＣ行のみが表示されることになる。これに対して標準のデータベースクエリを実行することにより結果をソートすることができる。レポート実行エンジン２１３は、これらの結果をとり、自身のデータベース内に置き、そしてこれに作用することができる。
【００７６】
上述の特徴及び適用を、コンピュータ読取可能記憶媒体（コンピュータ読取可能媒体とも呼ばれる）上に記録される命令のセットとして指定される、ソフトウェア処理として実装することができる。これらの命令は、１つ以上の処理ユニット（例えば１つ以上のプロセッサ、プロセッサのコア又は他の処理ユニット）によって実行されると、処理ユニットに、命令内で支持される動作を実行させる。コンピュータ読取可能媒体の例には、これらに限られないが、ＣＤ−ＲＯＭ、フラッシュドライブ、ＲＡＭチップ、ハードドライブ、ＥＰＲＯＭ等が含まれる。コンピュータ読取可能媒体は、無線で通過するか又は有線接続を経由して通過する搬送波や電気信号は含まない。
【００７７】
上述のこれらの機能を、デジタル電気回路で内で、コンピュータウェア、ファームウェア又はハードウェアとして実装することができる。本技術を、１つ以上のコンピュータプログラム製品を使用して実装することができる。プログラム可能なプロセッサ及びコンピュータをモバイルデバイスに含めるか、モバイルデバイスとしてパッケージすることができる。処理及び論理フローを、１つ以上のプログラム可能なプロセッサにより、そして１つ以上のプログラム可能な論理回路により実行することができる。汎用及び専用のコンピューティングデバイス及び記憶デバイスを、通信ネットワークを介して相互接続することができる。
【００７８】
本明細書において、「ソフトウェア」という用語は、プロセッサによる処理のためにメモリ内へ読み出すことができる、読取専用メモリ内に存在するファームウェア又は磁気ストレージ内に格納されるアプリケーションを含むよう意図される。また、一部の実装では、複数のソフトウェア技術を、別個のソフトウェア技術を残しつつ、大きなプログラムの一部の部分として実装することができる。一部の実装では、複数のソフトウェア技術を別個のプログラムとして実装することもできる。最後に、本明細書で説明されるソフトウェア技術を一緒に実装する別個のプログラムのいずれの組み合わせも、本技術の範囲内である。一部の実装において、ソフトウェアプログラムは、１つ以上の電気システムを動作させるようにインストールされると、ソフトウェアプログラムの動作を稼働させて実行する１つ以上の特定のマシン実装を定義する。コンピュータプログラム又はコンピュータコードの例には、例えばコンパイラによって生成されるマシンコード、及びコンピュータ、電気コンポーネント又はマイクロプロセッサによってインタプリタを使用して実行される高レベルコードを含むファイルが含まれる。
【００７９】
コンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト又はコードとしても知られる）を、コンパイル又は翻訳された言語、宣言的又は手続的言語を含め、任意の形式のプログラミング言語で書くことができ、スタンドアロンのプログラムとして、あるいはモジュール、コンポーネント、サブルーチン、オブジェクト又はコンピューティング環境における使用に適した他のユニットとして含まれる任意の形式で展開することができる。コンピュータプログラムは、必ずではないが、ファイルシステム内のファイルに対応し得る。プログラムを、他のプログラム又はデータを保持するファイルの一部分内（例えばマークアップ言語内に格納される１つ以上のスクリプト）、問題となっているプログラムに専用の単一のファイル内、複数の協調ファイル内（例えば１つ以上のモジュール、サブモジュール又はコードの一部を格納するファイル）に格納することができる。コンピュータプログラムを、１つのコンピュータ上で、あるいは１つのサイトに置かれるか、複数のサイトにわたって分散されて通信ネットワークにより相互接続される複数のコンピュータ上で実行されるように展開することができる。
【００８０】
本明細書及び本出願のいずれかの請求項で使用されるとき、「コンピュータ」、「サーバ」、「プロセッサ」及び「メモリ」という用語は全て、電気又は他の技術のデバイスを指す。これらの用語は、人又は人のグループを除外する。本明細書の目的では、ディスプレイ又は表示するという用語は、電子デバイス上で表示することを意味する。本明細書及び本出願のいずれかの請求項で使用されるとき、「（複数の）コンピュータ読取可能媒体」及び「（１つの）コンピュータ読取可能媒体」という用語は、全体的に、コンピュータによって読取可能な形式の情報を格納する、有形の物理的なものに制限される。これらの用語は、任意の無線信号、有線のダウンロード信号及び任意の他の一次的な信号は除外する。
【００８１】
理解されるように、開示される処理のステップのいずれかの具体的な順序又は階層は、例示的なアプローチの例である。設計上の好みに基づいて、処理におけるステップの具体的な順序又は階層を再配置することができ、あるいは図示されたステップの全てが実行されてもよいことが理解されよう。ステップのうちの幾つかが同時に実行されてもよい。例えば特定の環境では、マルチタスク化及び並行処理が有利であり得る。さらに、上記で説明される様々なシステムコンポーネントを分けることは、そのような分離を必ずしも必要であるように理解されるべきではなく、説明されるプログラムコンポーネント及びシステムは一般的に、単一のソフトウェア製品に一緒に統合することができ、複数のソフトウェア製品にパッケージ化することができることを理解されたい。
【００８２】
これらの態様に対する様々な修正が容易に明らかになり、ここで規定される一般的な原理を他の態様に適用してよい。したがって、特許請求の範囲は、本明細書で示される態様に限定されるように意図されておらず、特許請求の範囲の文言と互換性のある完全な範囲に合致することとする。特許請求の範囲においては、単数形の要素への言及は、特に記載されていない限り、「唯一」であることを意味するようには意図されていらず、「１つ又は複数」を意味するよう意図される。そうでないことを特に記載しない限り、「一部の、幾つかの（some）」という用語は、１つ又は複数を指す。
【図１】
0005944039.tif 000004
【図２】
0005944039.tif 000005
【図３】
0005944039.tif 000006
【図４】
0005944039.tif 000007
【図５】
0005944039.tif 000008
【図６】
0005944039.tif 000009
【図７】
0005944039.tif 000010
【図８】
0005944039.tif 000011
【図９Ａ】
0005944039.tif 000012
【図９Ｂ】
0005944039.tif 000013
【図１０】
0005944039.tif 000014
【図１１】
0005944039.tif 000015
【図１２】
0005944039.tif 000016
【図１３】
0005944039.tif 000017
【図１４】
0005944039.tif 000018
【図１５】
0005944039.tif 000019