JP6072334B1 - 情報処理システム及び方法、並びにプログラム - Google Patents

Abstract

【課題】極めて高いレスポンス性能を達成すること。【解決手段】サブクエリ抽出部１１０は、サブクエリを抽出する。ＰＬデータ生成部１１２は、ＰＬデータを生成する。ＰＬデータ管理部１２０は、ＰＬデータを管理し、ＰＬデータＤＢに格納する。ユーザインターフェイス制御部１００は、ユーザにより入力されたクエリ条件を受け付ける。クエリ条件送信制御部１０１は、クエリ条件をサーバ２へ送信させる。クエリ条件取得部１２１は送信されてきたクエリ条件を取得する。実行結果抽出部１２３は、サブクエリの実行結果を抽出する。検索結果生成部１２４は、抽出された実行結果から、検索結果を生成する。検索結果送信制御部１２５は、検索結果をプレイヤー端末１へ送信させる。検索結果取得部１０２は送信されてきた検索結果を取得する。検索結果表示制御部１０３は、検索結果を表示させる。【選択図】図４

Description

本発明は、情報処理システム及び方法、並びにプログラムに関する。

従来から、データベースの高速化を行う技術としてはインデックス技術がある（例えば特許文献１参照）。
しかしながら、このインデックス技術は、不特定の検索条件で検索された場合においてクエリの実行を高速化することを目的とした技術である。
例えばゲームに用いられるような、データ検索を起動するきっかけとなる操作の種類が有限であるデータ構造、即ち、クエリが有限となるデータ構造に最適化された技術ではない。
一方、クエリの状態を利用したデータベース検索の高速化の技術としては、データベース用のクエリ結果のキャッシュ技術が挙げられる。
例えば、最近最も使われていない検索結果を最初に捨てるＬｅａｓｔ Ｒｅｃｅｎｔｌｙ Ｕｓｅｄ（ＬＲＵ）、最近最も使われた検索結果を最初に捨てるＭｏｓｔ Ｒｅｃｅｎｔｌｙ Ｕｓｅｄ（ＭＲＵ）、最近最も使われる頻度の少ない検索結果から捨てるＬｅａｓｔ Ｆｒｅｑｕｅｎｔｌｙ Ｕｓｅｄ（ＬＦＵ）等のアルゴリズムがよく知られている（例えば特許文献２参照）。
しかし、これらのアルゴリズムは、クエリ使用頻度に依存してキャッシュを管理するものであり、例えばオンラインゲームのように検索の局所性が全く存在しない用途では有効に機能しない。

特開平１１−２１２９８０号公報 特開２００９−２６６１４７号公報

本発明が解決する問題は、オンラインゲームのパラメタやシナリオ展開等を格納する、固定的なデータセットへの検索・参照処理を高速化することである。

ゲームシステムは、バトルやゲームシナリオの進行に応じて、静的なデータから必要な項目を極めて高頻度に検索する。このような検索処理は、ゲーム実行中、常に行われる操作であり、ゲーム全体のレスポンス性能に大きな影響を及ぼしている。
特にクライアント側に予めデータをインストールすることが難しい、Ｗｅｂブラウザ上で動作するゲームにおいてはＣＳＶの検索が性能上のボトルネックの一つとなっており、静的データの検索の高速化は本質的に重要な問題である。

しかし、長期間運用されるオンラインゲームでは、アイテムやカードの属性等ゲーム内で使用するデータが膨大な数になり、時にはゲーム内の文字や数値だけで１００メガバイトを超えるような静的データが存在することも珍しくはない。
さらに言えば、例えば、英語版をはじめ、多言語・他国市場への展開時には、自然言語のデータは、サポートする言語や進出する市場の数だけ増加することになる。

本発明は、オンラインゲームのパラメタやシナリオ展開等の静的データの検索・参照処理を効率的かつ高速化することによって、スマートフォンという限られた計算能力しか持ちえない端末上や膨大な数のリクエストを受け付け、処理能力が逼迫するサーバ上においても、極めて高いレスポンス性能を達成することを目的とする。

上記目的を達成するため、本発明の一態様の情報処理システムは、
所定のユーザインターフェイスから入力可能であり、かつ、クエリを構成する夫々の条件間において、減少性、冪等性、交換可能性の３つを満たすクエリ条件を用いて、検索対象データに対して検索の処理を実行する情報処理システムにおいて、
検索の処理前に処理を実行する前処理実行手段と、
検索の処理を実行する検索処理手段と、
を備え、
前記前処理実行手段は、
前記検索対象データで使用され得るクエリ条件の集合から、複数種類のサブクエリを抽出するクエリ抽出手段と、
前記クエリ抽出手段により抽出された前記複数種類のサブクエリの夫々を実行するクエリ実行手段と、
前記クエリ抽出手段により抽出された前記複数種類のサブクエリ毎に、前記クエリ実行手段による実行結果と、当該実行結果に対応する種類のサブクエリを識別可能な情報とを対応付けたデータを、対応付データとして生成する対応付け手段と、
前記対応付け手段により生成された、前記複数種類のサブクエリ毎の対応付データを管理する管理手段と、
を含み、
前記検索処理手段は、
前記ユーザインターフェイスから検索用に入力されたクエリ条件を、検索クエリ条件として受け付ける受付手段と、
前記受付手段により受け付けられた前記検索クエリ条件を、１種類以上のサブクエリの集合体に分割する分割手段と、
前記分割手段により分割された前記集合体に属する前記１種類以上のサブクエリの夫々を識別可能な情報に基づいて、当該１種類以上のサブクエリの夫々の実行結果を前記対応付データの中から抽出する実行結果抽出手段と、
前記実行結果抽出手段の抽出結果に基づいて、前記受付手段により受け付けられた前記検索クエリ条件に対する検索結果を生成する検索結果生成手段と、
を備える情報処理システム。

本発明によれば、オンラインゲームのパラメタやシナリオ展開等の静的データの検索・参照処理を効率的かつ高速化することによって、スマートフォンという限られた計算能力しか持ちえない端末上や膨大な数のリクエストを受け付け、処理能力が逼迫するサーバ上においても、極めて高いレスポンス性能を達成することができる。

本発明の一実施形態に係る情報システムの構成を示すブロック図である。 図１の情報処理システムのうち、本発明の一実施形態のプレイヤー端末のハードウェア構成を示すブロック図である。 図１の情報処理システムのうち、本発明の一実施形態のハードウェア構成を示すブロック図である。 図２のプレイヤー端末及び図３のサーバの機能的構成例を示す機能ブロック図である。 図４のプレイヤー端末及び図３のサーバが実行する情報処理のフローチャートである。 図４のサーバが実行する情報処理のフローチャートである。 図４のプレイヤー端末に表示されるユーザインターフェイス用の画面の一例を示す図である。 図４の検索対象データＤＢに格納される検索対象データの一例を示す図である。 図４のＰＬデータＤＢの構造例を示す図である。 図４の演算順番決定部において実行される、検索コストの見積もり処理及び実行順序の最適化処理の一例を示す図である。

以下、本発明の実施形態について、図面を用いて説明する。

図１は、本発明の一実施形態に係る情報処理システムの構成を示している。
図１に示す情報処理システムは、ｗ人（ｗは１以上の任意の整数値）のプレイヤーの夫々により使用されるプレイヤー端末１−１乃至１−ｗと、サーバ２とを含むシステムである。プレイヤー端末１−１乃至１−ｗの夫々と、サーバ２とは、インターネット等の所定のネットワークＮを介して相互に接続されている。

サーバ２は、プレイヤー端末１−１乃至１−ｗの夫々において実行されるゲーム等において用いられる静的データを効率的かつ高速に検索等できる環境を提供する。これにより、当該ゲーム等において極めて高いレスポンス性能が達成される。

なお、以下、プレイヤー端末１−１乃至１−ｗの夫々を個々に区別する必要がない場合、これらをまとめて「プレイヤー端末１」と呼ぶ。

図２は、図１の情報処理システムのうち、本発明の一実施形態に係るプレイヤー端末１のハードウェア構成を示すブロック図である。

プレイヤー端末１は、スマートフォン等で構成される。
プレイヤー端末１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２３と、バス２４と、入出力インターフェース２５と、タッチ操作入力部２６と、表示部２７と、入力部２８と、記憶部２９と、通信部３０と、ドライブ３１と、を備えている。

ＣＰＵ２１は、ＲＯＭ２２に記録されているプログラム、又は、記憶部２９からＲＡＭ２３にロードされたプログラムに従って各種の処理を実行する。
ＲＡＭ２３には、ＣＰＵ２１が各種の処理を実行する上において必要なデータ等も適宜記憶される。

ＣＰＵ２１、ＲＯＭ２２及びＲＡＭ２３は、バス２４を介して相互に接続されている。このバス２４にはまた、入出力インターフェース２５も接続されている。入出力インターフェース２５には、タッチ操作入力部２６、表示部２７、入力部２８、記憶部２９、通信部３０及びドライブ３１が接続されている。

タッチ操作入力部２６は、例えば表示部２７の表示面に積層される静電容量式又は抵抗膜式（感圧式）の位置入力センサにより構成され、タッチ操作がなされた位置の座標を検出する。
ここで、タッチ操作とは、タッチ操作入力部２６に対する物体の接触又は近接の操作をいう。タッチ操作入力部２６に対して接触又は近接する物体は、例えばプレイヤーの指やタッチペン等である。
表示部２７は、液晶等のディスプレイにより構成され、ゲームに関する画像等、各種画像を表示する。
このように、本実施形態では、タッチ操作入力部２６と表示部２７とにより、タッチパネルが構成されている。

入力部２８は、各種ハードウェア釦等で構成され、プレイヤーの指示操作に応じて各種情報を入力する。
記憶部２９は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
通信部３０は、インターネットを含むネットワークＮを介して他の装置（図１の例ではサーバ２や他のプレイヤー端末１）との間で行う通信を制御する。

ドライブ３１は、必要に応じて設けられる。ドライブ３１には、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア４１が適宜装着される。ドライブ３１によってリムーバブルメディア４１から読み出されたプログラムは、必要に応じて記憶部２９にインストールされる。また、リムーバブルメディア４１は、記憶部２９に記憶されている各種データも、記憶部２９と同様に記憶することができる。

図３は、図１の情報処理システムのうち、本発明の一実施形態に係るサーバ２のハードウェア構成を示すブロック図である。

サーバ２は、ＣＰＵ５１と、ＲＯＭ５２と、ＲＡＭ５３と、バス５４と、入出力インターフェース５５と、出力部５６と、入力部５７と、記憶部５８と、通信部５９と、ドライブ６０とを備えている。
サーバ２の構成は、プレイヤー端末１のタッチパネルを除いた構成と基本的に同様であるので、ここではその説明は省略する。

このような図２のプレイヤー端末１及び図３のサーバ２の各種ハードウェアと各種ソフトウェアとの協働により、プレイヤー端末１及びサーバ２において、静的データの検索等について高速処理の実行が可能になる。
即ち、本実施形態の情報処理システムは、高速検索のためのデータベースを生成する「開発時（データ導入時）」のフェイズと、ゲームのプレイ中等に実際に検索が行われる「実行時（ゲームプレイ中等）」のフェイズと、から構成される一連の処理を実行することができる。

より具体的に言えば、本実施形態において、情報処理システムは、「開発時（データ導入時）」のフェイズの一連の処理（以下、「データ導入時処理」と呼ぶ）として、本実施形態では、次のような処理を実行する。
即ち、サーバ２は、事前にゲーム内で実行され得るクエリの集合を分析することで、クエリの最小単位（以下、「サブクエリ」と呼ぶ）を複数種類抽出する。
サーバ２は、抽出された複数種類のサブクエリの夫々を実行し、これらの実行結果の夫々と、対応する種類のサブクエリを識別可能な情報とを対応付けたデータを、対応付データとして生成する。
サーバ２は、複数種類のサブクエリ毎の対応付データを、所定のデータベース（以下、「ＰＬデータＤＢ」と呼ぶ）へ格納して管理する。

情報処理システムは、このようにしてＰＬデータＤＢに複数種類のサブクエリ毎の対応付データが格納されている状態で、「実行時（ゲームプレイ中等）」のフェイズにおけるデータの検索処理（以下、「検索処理」と呼ぶ）として、本実施形態では次のような処理を実行する。
即ち、プレイヤーがプレイヤー端末１を操作して、所定のユーザインターフェイスを介してクエリ条件を入力すると、プレイヤー端末１は、そのクエリ条件をサーバ２へ送信する。
サーバ２は、送信されてきた検索クエリ条件を受信すると、１種類以上のサブクエリの集合体に分割し、当該１種類以上のサブクエリの夫々を識別可能な情報に基づいて、当該１種類以上のサブクエリの夫々の実行結果を対応付データの中から抽出する。そして、サーバ２は、その抽出結果に基づいて、検索結果を生成して、プレイヤー端末１に提示する。

以下、このようなデータ導入時処理及び検索処理を実行可能な情報処理システムについて、その機能的構成及び処理の流れの一例について説明していく。

図４は、プレイヤー端末１とサーバ２の機能的構成のうち、データ導入時処理及び検索処理の実行時の機能的構成を示す機能ブロック図である。

図４のプレイヤー端末１のＣＰＵ２１においては、ユーザインターフェイス制御部１００と、クエリ条件送信制御部１０１と、検索結果取得部１０２と、検索結果表示制御部１０４と、が機能する。
サーバ２のＣＰＵ５１においては、データ導入時処理の実行時にはデータ導入時処理部１５１が機能し、検索処理時には検索処理部１５２が機能する。
サーバ２の記憶部５８の一領域には、クエリ集合ＤＢ２００と、検索対象データＤＢ３００と、ＰＬデータＤＢ４００とが設けられる。

先ず、データ導入時処理の機能的構成について説明する。
データ導入時処理においては、プレイヤー端末１は特に機能せず、サーバ２のうちデータ導入時処理部１５１のみが機能する。
データ導入時処理部１５１には、サブクエリ抽出部１１０と、サブクエリ実行部１１１と、ＰＬデータ生成部１１２と、が設けられている。

先ず、データ導入時処理の前提として、クエリ集合ＤＢ２００には、クエリの集合が格納されているものとする。
クエリの集合とは、導入対象のゲーム内で使用され得るクエリ条件の集合である。
具体的には、クエリ条件の集合は、次の式で定義される。
ｑＨ：＝｛ａ，ｂ，ｃ，ｄ，ｅ，・・・，ｈ｝ ・・・（１）
ここで、ｑＨは、Ｈ番目の条件に対応するクエリ条件の集合を意味する。例えば、攻撃力の検索条件等の検索条件が対象とする属性に対応する。この集合の要素であるａ，ｂ，ｃ，ｄ，ｅ，・・・，ｈは、検索条件として使用される値である。例えば、最大値が１５である攻撃力の検索条件の場合であれば、｛１，２，３，４，５，６，７，８，９，１０，１１，１２，１３，１４，１５｝が集合の要素となる。

サーバ２のＣＰＵ５１のサブクエリ抽出部１１０は、クエリ集合ＤＢ２００に格納されたクエリの集合体に基づいて、ゲーム内で実行され得るクエリの集合を分析し、その分析結果に基づいて複数種類のサブクエリを抽出する。

ここで、データ導入時処理の前提として、検索対象データＤＢ３００には、導入対象のゲーム内の検索対象データが格納されるているものとする。
なお、本実施形態で用いる検索対象データとは、ゲーム内で検索対象となるあらゆるデータであり、特定の形式に限定されるものではない。ＪＳＯＮ形式、ＣＳＶ形式、等、幅広いデータが対象となる。検索対象データの具体例については、図８を用いて後述する。

サブクエリ実行部１１１は、検索対象データＤＢ３００に格納された検索対象データを対象として、サブクエリ抽出部１１０により抽出された複数種類のサブクエリの夫々を実行する。

ＰＬデータ生成部１１２は、サブクエリ抽出部１１０により抽出された複数種類のサブクエリ毎に、サブクエリ実行部１１１による実行結果と、当該実行結果に対応する種類のサブクエリを識別可能な情報とを対応付けたデータを、対応付けデータ（ＰＬデータ（対応付データ）として生成する。なお、このような対応付けデータを、以下、「Ｐｒｅ−Ｌｉｎｋｅｄデータ」又は略記した「ＰＬデータ」と適宜呼ぶ。
ＰＬデータ管理部１２０は、このようにして生成された複数種類のサブクエリ毎のＰＬデータをＰＬデータＤＢ４００に格納して管理する。

即ち、ＰＬデータＤＢ４００は、複数種類のサブクエリ毎のＰＬデータを格納する。所定種類のサブクエリのＰＬデータは、当該所定種類のサブクエリを識別可能な情報と、当該所定種類のサブクエリの実行結果とを対応付けているデータである。
所定種類のサブクエリを識別可能な情報は、その名のごとく所定種類のサブクエリを特定可能なものであれば足り、その形態等は特に限定されない。例えば本実施形態では、所定種類のサブクエリを識別するキーとなる条件（具体的には例えば、攻撃力で検索するサブクエリでは、ａｔｋ＝１０）が、当該所定種類のサブクエリの実行結果と対応付けられて、当該所定種類のサブクエリのＰＬデータが構成されている。

次に、検索処理時の機能的構成について説明する。
検索時処理においては、プレイヤー端末１では、ユーザインターフェイス制御部１００と、クエリ条件送信制御部１０１と、検索結果取得部１０２と、検索結果表示制御部１０４と、が機能する。サーバ２では、検索処理部１５２が機能する。
検索処理部１５２には、ＰＬデータ管理部１２０と、クエリ条件取得部１２１と、分割部１２２と、実行結果抽出部１２３と、検索結果生成部１２４と、検索結果送信制御部１２５と、が設けられている。

プレイヤー端末１のＣＰＵ２１のユーザインターフェイス制御部１００は、ゲームの実行中等において、所定のユーザインターフェイス用の画面（後述の図７参照）を表示部２７に表示させる制御を実行する。
また、ユーザインターフェイス制御部１００は、上述の画面（タッチ操作入力部２６）に対してプレイヤーがしたタッチ操作の内容を受け付ける。例えば、ユーザインターフェイス制御部１００のうちクエリ条件受付部１３１は、プレイヤーがタッチ操作でタッチ操作入力部２６に対して入力した検索のための条件を、クエリ条件として受け付ける。

クエリ条件送信制御部１０１は、クエリ条件受付部１３１により受け付けられたクエリ条件を、通信部３０を介してサーバ２へ送信する制御を実行する。

サーバ２のクエリ条件取得部１２１は、このようにしてプレイヤー端末１から送信されてきたクエリ条件を、通信部５９を介して取得する。

分割部１２２は、クエリ条件取得部１２により取得されたクエリ条件を、１種類以上のサブクエリの集合体に分割する。この集合体は、それに属する１種類以上のサブクエリの夫々が例えばＯＲ、ＡＮＤ、ＮＯＴ等で接続されて構成される論理演算式の形態を有している。

実行結果抽出部１２３は、分割部１２２により分割された１種以上のサブクエリの実行結果の夫々を、ＰＬデータ管理部１２０から抽出する。

検索結果生成部１２４は、実行結果抽出部１２３により抽出された１種以上のサブクエリの実行結果の集合体に基づいて、検索結果を生成する。ここで、この集合体は、それに属する１種類以上のサブクエリの実行結果の夫々が例えばＯＲ、ＡＮＤ、ＮＯＴ等で接続されて構成される論理演算式の形態を有している。そこで、検索結果生成部１２４は、当該論理演算式を解くこと（演算すること）によって、検索結果を生成する。

ここで、検索結果生成部１２４内の一領域には演算順番決定部１４１が設けられる。
演算順番決定部１４１は、検索結果生成部１２４が検索結果を生成するにあたり、夫々のサブクエリを統合（論理演算式の集合演算）をする際の集合演算コストを見積もることができる。
演算順番決定部１４１は、見積もりの結果、最も絞り込み能力が高いサブクエリから順にソートすることにより、集合演算を適用するのに最も効率のいい順序を提案する。

検索結果送信制御部１２５は、検索結果生成部１２４により生成された検索結果を通信部５９を介してプレイヤー端末１へ送信するための制御を実行する。

プレイヤー端末１の検索結果取得部１０２は、このようにしてサーバ２から送信されてきた検索結果を通信部３０を介して取得する。
検索結果表示制御部１０３は、検索結果取得部１０２により取得された検索結果（より正確には検索結果を示す画像等）を、表示部２７に表示させる制御を実行する。

次に、図５を参照して、このような機能的構成を有するサーバ２が実行する、データ導入時処理の流れについて説明する。
図５は、図４の機能的構成を有するサーバ２が実行する、データ導入時処理の流れの一例を説明するフローチャートである。

ステップＳ１において、図４のサーバ２のサブクエリ抽出部１１０は、導入対象のゲーム内で使用され得るクエリ条件に基づいて、複数のサブクエリを抽出する。
ステップＳ２において、サブクエリ実行部１１１は、ステップＳ１の処理で抽出された複数のサブクエリの夫々を実行する。
ステップＳ３において、ＰＬデータ生成部１１２は、ステップＳ１において抽出された複数のサブクエリ毎に、ステップＳ２における所定種類のサブクエリの実行結果と、当該所定種類のサブクエリを識別可能な情報とを対応付けたデータを、ＰＬデータとして生成する。
ステップＳ４において、ＰＬデータ管理部１２０は、ステップＳ３において生成されたＰＬデータを、ＰＬデータＤＢ４００に記憶される。
これにより、データ導入時処理が終了し、これ以降、ＰＬデータＤＢ４００に複数のサブクエリ毎に記憶されたＰＬデータは、ＰＬデータ管理部１２０により管理される。

続いて、図６を参照して、このような機能的構成を有するプレイヤー端末１及びサーバ２が実行する検索処理の流れについて説明する。
図６は、図４の機能的構成を有するプレイヤー端末１及びサーバ２が実行する検索処理の流れの一例を説明するフローチャートである。

ここで、図６の検索処理の実行に際して、プレイヤー端末１のユーザインターフェイス制御部１００の制御により、プレイヤーは、所定のユーザインターフェイス（具体例について図７を用いて後述する）を用いて、所望の検索のための条件（例えば、攻撃力が１５以上のカード等の条件）を入力するものとする。
このような入力がなされると、処理はステップＳ２１に進む。

ステップＳ２１において、プレイヤー端末１のクエリ条件受付部１３１は、プレイヤーが入力した検索のための条件を、クエリ条件として受け付ける。
ステップＳ２２にいて、クエリ条件送信制御部１０１は、ステップＳ２１において受け付けられたクエリ条件を、通信部３０を介してサーバ２へ送信する。

ステップＳ４１において、サーバ２のクエリ条件取得部１２１は、プレイヤー端末１から送信されてきたクエリ条件を通信部５９を介して取得する。
ステップＳ４２において、分割部１２２は、ステップＳ４１において取得されたクエリ条件を、複数種類のサブクエリに分割する。
ステップＳ４３において、実行結果抽出部１２３は、ステップＳ４２において分割されたサブクエリの実行結果を、ＰＬデータ管理部１２０を介してＰＬデータＤＢ４００から抽出する。
ステップＳ４４において、検索結果生成部１２４は、ステップＳ４３において抽出された実行結果に基づいて、検索結果を生成する。
なお、ステップＳ４４の処理において、検索結果生成部１２４内の演算順番決定部１４１は、サブクエリの検索コストの見積もりを行う。このような実行順序の制御による最適化により、ステップＳ４４の検索処理は、従来方式の処理に比較して遥かに効率的なものとなっている。演算順番決定部１４１の処理の詳細については、図１０の具体例を用いて後述する。

ステップＳ４５において、検索結果送信制御部１２５は、ステップＳ４４において生成された検索結果を、通信部５９を介してプレイヤー端末１へ送信させる。
ステップＳ２３において、プレイヤー端末１の検索結果取得部１０２は、ステップＳ４５においてサーバ２から送信されてきた検索結果を、通信部３０を介して取得する。
ステップＳ２４において、検索結果表示制御部１０３は、ステップＳ２３において取得された検索結果を、表示部２７に表示させる。

次に、図７以降の図面を参照して、データ導入時処理又は検索処理に関する具体例について説明する。

図７は、ユーザインタフェースを構成する検索画面の一例を示す図である。
本実施形態における検索処理を実現するためのゲーム内の検索機能は、予め決められた検索項目をプルダウンメニュー等で選択し、それらをＡＮＤ条件やＯＲ条件により組み合わせたものをクエリとして検索する機能である。
例えば図７の例での検索項目については、上から「クラス」、「コスト」、「カードの種類」、「レアリティ」、「攻撃力」、「体力」、「タイプ」、「キーワード能力」、「トークンを含む」、及び「カードテキスト検索」が存在する。このように、本実施形態では検索項目の１つが、所定の１種類の属性を示している。
１つの属性に対して、複数のサブクエリの種類が存在する。図７の例では、同一属性の各種のサブクエリは、横方向に配置されて表示される。
「クラス」は、検索対象のカードのクラスである。図７の例では、「ロイヤル」、「ドラゴン」、「ビショップ」の３つがサブクエリとして選択されている。
「コスト」は、検索対象のカードのコストであり、ゲーム内にカードとして存在するコストであれば、任意の数値をサブクエリとして入力することが可能である。
「カードの種類」は、例えば「ユニット」、「スペル」、「フィールド」等の、検索対象のカードの種類を意味する。図７の例では、「ユニット」及び「スペル」の２つのサブクエリが選択されている。
「レアリティ」は、例えば「ブロンズレア」、「シルバーレア」、「ゴールドレア」、「レジェンド」等の、検索対象のカードのレアリティである。図７の例では、「レジェンド」がサブクエリとして選択されている。
「攻撃力」は、検索対象カードの攻撃力のパラメタである。図７の例では攻撃力「２」と「等しい」という条件が選択されているため、攻撃力２のカードのみがサブクエリとして選択されていることになる。
「体力」は、検索対象の体力のパラメタである。図７の例では体力「１５」と「以下」という条件が選択されているため、体力１５以下の各数値（１、２、３、４、５、６、７、８、９、１０、１１、１２、１３、１４、１５）がサブクエリとして選択されていることになる。
即ち、静的データでは、予め全てのデータの値の範囲を検証することが出来るため、例えば「攻撃力３以下」というような範囲で検索条件が設定されてる場合、値の範囲のＯＲ条件として定義できる。即ち、「攻撃力３以下」であれば「３ｏｒ２ｏｒ１」として定義できる。つまり、サブクエリ「３」、「２」、及び「１」のｏｒ条件の集合体として、「攻撃力３以下」という検索条件を表すことができる。
「トークンの有無」は、検索対象として「トークン」のカードを含むか否かである。図７の例では、「ＯＮ」が選択されていないため、「トークン」は検索対象に含まれない。
「カードテキスト検索」は、カードテキストに含まれる「キーワード」による検索であり、事前にいくつかの「キーワード」が設定され選択できるようになっている。図７の例では、「特殊能力を持つ」が選択されているため、「特殊能力を持つ」というキーワードがサブクエリとなり、当該サブクエリ（キーワード）を有するカードのみが検索対象となる。
キーワイドについては、例えばｎ−ｇｒａｍ法を用いると、検索対象データと、検索条件の両方を、ｎ個の文字の組み合わせの集合としてモデル化することができる。より具体的に言えば、「サムライ」というキーワードをｎ−ｇｒａｍの一種である２−ｇｒａｍで表現した場合、「サム」、「ムラ」、「ライ」という３つの要素に分解でき、「サムライ」というキーワード検索を、「サム ａｎｄ ムラ ａｎｄライ」という３つのクエリ条件の論理積として定義することができる。すなわち、キーワード検索のような、クエリ表現の自由度が一見高いように見える検索においても、検索条件を有限個のプリミティブなサブクエリの組み合わせとして表現することができる。
本実施形態の情報処理システムの検索処理では、上述した様に、このようなプレイヤーにより入力された検索条件を、再利用性の高い最小単位のサブクエリへと分割し、夫々を、事前の検索結果（サブクエリの事前の実行結果）を用いることで、極めて高速な検索処理が実現される。
つまり、本実施形態の検索処理のポイントは、上述した様に、その前に、本発明のデータ導入時処理が実行されていることである。そこで、以下、本発明のデータ導入時処理の詳細について説明する。

本実施形態のデータ導入時処理における静的分析では、検索対象データの集合（図４の検索対象データＤＢ３００）と、クエリを構成する最小単位のサブクエリの集合（図４のクエリ集合ＤＢ２００）の２つを入力として受け取り、その結果として、全てのサブクエリの実行結果（検索結果）が、夫々固有の識別子により識別可能になっている必要がある。
この識別により、検索処理の段階では、サブクエリを実行（検索）することなく、異なるサブクエリの実行結果を用いた統合の処理だけで、検索結果を生成することが可能になる。
具体的には例えば、検索対象データＤｉは、次式（２）に示すように、一意の識別子と、検索対象属性群の組み合わせから構成することができる。
Ｄｉ：＝｛ＩＤｉ，ａｔｔｒ１，ａｔｔｒ２，ａｔｔｒ３，・・・，ａｔｔｒＩ｝
・・・（２）
ここで、ＩＤｉは、検索対象Ｄｉを一意に識別することができる識別子である。例えば、シリアル番号を用いて識別子を実装することもできるが、本実施形態では、特定の識別子の付与方法には依存しない。
さらに、ａｔｔｒ１乃至ａｔｔｒＩは、検索対象Ｄｉに関連付けられたＩ個（Ｉは任意の整数値）の属性データである。

例えば、図８は検索対象データの具体例を示す図である。
図８の例では、夫々の行が、固有の識別子を持つ、固有のゲーム内データ（検索対象データ）に対応している。
例えば、図８の１行目のデータは、クラス「ロイヤル」、レアリティ「レジェンド」、攻撃力「１０」の条件に該当するデータであり、ＩＤ「０００１」のデータである。
また例えば、２行目のデータは、クラス「ウィッチ」、レアリティ「レジェンド」、攻撃力「７」の条件に該当するデータであり、ＩＤ「０００２」のデータである。
ここで、図８の例では、「クラス」、「レアリティ」、「攻撃力」が検索対象の属性であり、これらの属性は、入れ替えることや追加することも、もちろん自在に可能である。
これらのデータは、ゲーム内にｕ個（ｕは１以上の任意の整数）存在し、ゲーム内の検索対象データとして全て網羅することができる。

本実施形態のデータ導入時処理では、このような図８の構造のゲーム内の検索対象データについて、クエリの集合から抽出された複数種類のサブクエリの夫々が実行（検索）される。そして、複数種類のサブクエリ毎に、サブクエリの実行結果と、当該サブクエリを識別可能な情報とを対応付けたＰＬデータが生成され、ＰＬデータＤＢ４００に格納される。

図９は、このようなＰＬデータＤＢ４００の構造例を示す図である。
図９の例では、ｙ軸がテーブルの属性の種類の軸、ｘ軸がサブクエリの種類の軸、ｚ軸は対応するサブクエリの検索結果（答えの１つ）の軸を示している。
テーブルの属性の種類とは、任意の属性の種類を表す。例えば図７の例で言えば、縦方向の各検索項目に該当し、例えば図８の例で言えば、「クラス」、「レアリティ」、「攻撃力」等が該当する。図９の例で言えば、テーブルの属性の種類は、ｎ（ｎは１以上の任意の整数値）種類存在する。
サブクエリの種類とは、例えば図７の例で言えば、横方向の項目等に該当し、任意のサブクエリの種類を表している。例えば、図８の例で言えば、「攻撃力」という属性に対して取り得る値、具体的には例えば１行目では「１０」が該当する。図９の例で言えば、サブクエリの種類は、ｍ（ｍは１以上の任意の整数）種類存在する。
対応するサブクエリの検索結果とは、テーブルの属性の所定の種類（例えば「攻撃力」）のうち所定のサブクエリの種類（例えば「１０」）に対応するサブクエリの実行結果（検索結果）を示す。
図９の例で言えば、対応するサブクエリの検索結果は、０から始まるｑ（ｑは１以上の任意の整数値）個の要素を持つ配列であり、夫々の配列のサイズはサブクエリ毎に異なる。
例えば、テーブルの属性の種類「Ｋ」の中でサブクエリの種類「Ｐ」についての当該サブクエリの実行結果は、（Ｘ，Ｙ）＝（Ｐ，Ｋ）の座標においてＺ軸（対応するサブクエリの検索結果の軸方向）に配列される１以上の立方体により示されることになる。ここで、図９中で示された立方体ＣＰＫＲは、ある特定の属性の種類「Ｋ」に、ある特定のサブクエリの種類「Ｙ」で問い合わせた時の答えの１つ（検索結果の集合体の１つ）に対応するものである。

このような図９の構造のＰＬデータＤＢ４００が用意できると、上述の検索処理が実行可能になる。
上述した様に、本実施形態の検索処理では、検索クエリ条件から分割された１種類以上のサブクエリの夫々を結合した論理演算式を演算することにより、検索結果が生成される。
本実施形態では、演算順番決定部１４１（図４）が、この論理演算式の演算の順番を最適にするように決定することで、高速な検索を可能にしている。そこで、以下、図１０を参照して、演算順番決定部１４１の具体的な処理内容について説明する。
図１０は、サーバ２の検索結果生成部１２４内に設けられた演算順番決定部１４１において実行される、検索コストの見積もり処理及び実行順序の最適化処理の一例を示す図である。

演算順番決定部１４１は、実行結果抽出部１２３が抽出したサブクエリの実行結果を統合する際（論理演算式による集合演算をする際）の集合演算コストを、サブクエリの実行結果の集合の要素数を参照することにより、見積もることができる。
このように、演算コストを見積もることで、演算順番決定部１４１は、演算の順番を最適化して、クエリ条件が複雑な場合であっても、少ない回数の比較演算だけで集合演算を実行することができるようになる。
図１０の例では、まず、初期状態のクエリとして、検索対象の属性（ａｔｔｒｉｂｕｔｅ）と、その値（サブクエリ）の列（ｃｏｎｄｉｔｉｏｎ）の組の配列としてクエリが作成されている。なお、夫々の値はＯＲ条件で接続されている。
例えば、上図の一行目の場合であれば、検索対象の属性は「ｃｈａｒ＿ｔｙｐｅ」であり、その値（サブクエリ）の列は「１」である。
ここで、このクエリ自体は、ユーザインターフェイス制御部１００により制御されたユーザインターフェイスから入力されたものをそのまま連結したものであるため、効率性等は考慮されていない。
そこで、図１０に示すように、演算順番決定部１４１は、選択率が最も低いサブクエリ、言い換えると、最も制約が厳しく該当するデータ数が最小個数となる絞り込み条件から順に実行するように、サブクエリの列を並び替えるのである。
より具体的に言えばは、演算順番決定部１４１は、ＰＬデータＤＢ４００においてサブクエリに対応する検索結果の集合の要素数（サブクエリの実行結果の数）を参照し、集合の要素数が少ない種類のサブクエリから順にソートすることにより、集合演算を適用するときに最も効率の良い順序を求める。
なお、図１０の下図で追加されている属性「ｃｏｓｔ」は、その条件において返される結果の数（ＰＬデータＤＢ４００においてサブクエリに対応する検索結果の集合の要素数）を示しており、演算順番決定部は、この「ｃｏｓｔ」の値をもとに集合演算を適用するときに最も効率の良い順序を提案する。

以上本発明の一実施形態について説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。

例えば、図４の機能的構成は例示に過ぎず、特に限定されない。即ち、上述した一連の処理を全体として実行できる機能が情報処理システムに備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは特に図４の例に限定されない。また、機能ブロックの存在場所も、図４に特に限定されず、任意でよい。例えば、サーバ２の機能ブロックをプレイヤー端末１等に移譲させてもよい。逆にプレイヤー端末１の機能ブロックをサーバ２等に移譲させてもよい。
また、一つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。

各機能ブロックの処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えばサーバの他汎用のスマートフォンやパーソナルコンピュータであってもよい。

このようなプログラムを含む記録媒体は、プレイヤーにプログラムを提供するために装置本体とは別に配布される図示せぬリムーバブルメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でプレイヤーに提供される記録媒体等で構成される。

なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。
また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものとする。

また例えば、検索対象データとしては、上述の実施形態では、主にオンラインゲーム等で用いられる静的なデータが採用されていたが、特にこれに限定されない。
本発明が適用される静的分析技術は、オフライン型のカーナビゲーションシステムや、オフライン型の電子辞書のようなオフラインコンテンツ、Ｗｅｂ上の固定的な文章集合を対象とした全文検索エンジン等にも用いることもできる。
さらには、本発明が適用される静的分析技術は、単純な文字列検索や数値探索のみに限定されない。具体的には、本発明は、文字列検索等の特定の検索手段には依存しないため、例えば画像検索等の極めて複雑な条件を導入しても、静的に解決することができる。
これにより、極めて複雑な検索条件であっても、クエリの種類を静的に定めることができるものであれば、どのようのものでも対応することができる。
より具体的に言えば、クエリを構成する夫々の条件間において、減少性、冪等性、クエリ条件の交換可能性がある、という３つの条件下においてクエリ条件を表現できるのであれば、検索対象データとして採用することができる。
ここで、減少性とは、検索結果は、常に検索対象よりも小さくなるというものである。
冪等性とは、同じサブクエリを、同じデータに何度も実行しても必ず同じ結果になる。つまり、キャッシュできるというものである。つまり、「現在時間で検索」のような条件がないというものである。
交換可能性とは、条件Ａかつ条件Ｂの演算結果は、条件Ｂかつ条件Ａの検索結果と、必ず同じになるということであり、本発明においては、この交換可能性を根拠として、サブクエリの集合演算の比較順序を並び替え、最小の比較回数で、検索結果を求めることができる。

換言すると、本発明が適用される情報処理システムは、上述の図１や図４の実施形態としての情報処理システムを含め、次のような構成を有する各種各様の実施形態を取ることができる。
即ち、本発明が適用される複数の情報処理システムは、
所定のユーザインターフェイスから入力可能であり、かつ、クエリを構成する夫々の条件間において、減少性、冪等性、交換可能性の３つを満たすクエリ条件を用いて、検索対象データに対して検索の処理を実行する情報処理システムであって、
検索の処理前に処理を実行する前処理実行手段（例えば図４のデータ導入時処理部１５１）と、
検索の処理を実行する検索処理手段（例えば図４の検索処理部１５２）と、
を備え、
前記前処理実行手段は、
前記検索対象データで使用され得るクエリ条件の集合から、複数種類のサブクエリを抽出するクエリ抽出手段（例えば図４のサブクエリ抽出部１１０）と、
前記クエリ抽出手段により抽出された前記複数種類のサブクエリの夫々を実行するクエリ実行手段（例えば図４のサブクエリ実行部１１１）と、
前記クエリ抽出手段により抽出された前記複数種類のサブクエリ毎に、前記クエリ実行手段による実行結果と、当該実行結果に対応する種類のサブクエリを識別可能な情報とを対応付けたデータを、対応付データとして生成する対応付け手段（例えば図４のＰＬデータ生成部１１２）と、
前記対応付け手段により生成された、前記複数種類のサブクエリ毎の対応付データを管理する管理手段（例えば図４のＰＬデータ管理部１２０）と、
を含み、
前記検索処理手段は、
前記ユーザインターフェイスから検索用に入力されたクエリ条件を、検索クエリ条件として受け付ける受付手段（例えば図４のユーザインターフェイス制御部１００）と、
前記受付手段により受け付けられた前記検索クエリ条件を、１種類以上のサブクエリの集合体に分割する分割手段（例えば図４の分割部１２２）と、
前記分割手段により分割された前記集合体に属する前記１種類以上のサブクエリの夫々を識別可能な情報に基づいて、当該１種類以上のサブクエリの夫々の実行結果を前記対応付データの中から抽出する実行結果抽出手段（例えば図４の実行結果抽出部１２３）と、
前記実行結果抽出手段の抽出結果に基づいて、前記受付手段により受け付けられた前記検索クエリ条件に対する検索結果を生成する検索結果生成手段（例えば図４の検索結果生成部１２４）と、
を含む情報処理システムである。

また、前記検索結果生成手段は、前記実行結果抽出手段により抽出された前記１種類以上のサブクエリの夫々の実行結果に対して決定された所定の順番に従って、当該１種類以上のサブクエリの夫々の実行結果の論理演算をすることにより、前記受付手段により受け付けられた前記検索クエリ条件に対する検索結果を生成し、
前記実行結果抽出手段により抽出された前記１以上のサブクエリの夫々の実行結果について、前記検索対象データにおけるサブクエリの実行結果の量に応じた検索コストを演算し、当該検索コストに基づいて、前記検索結果生成手段における前記論理演算の前記所定の順番を決定する処理順番決定手段（例えば図４の演算順番決定部１４１）を、
さらに備えることができる。

このような、サブクエリの検索コストの見積もりと実行順序の制御による最適化により、本発明は、従来方式よりもはるかに効率的に検索処理を実行することができる。

また、前記所定のユーザインターフェイスは、複数種類の属性毎に、複数種類のサブクエリの中から所定の１種類を選択する操作機能を、
さらに備えることができる。

これにより、プレイヤーが行う検索の幅を広げることができ、また、検索対象データを追加等する場合であっても、容易に対応することが可能となる。

また、所定種類の属性の所定種類のサブクエリに対する前記クエリ実行手段による実行結果は、前記所定種類の属性、前記所定種類のサブクエリ、及び、前記検索対象データにおける、当該所定種類の属性の当該所定種類のサブクエリの実行結果の量を、
さらに含むことができる。

これにより、任意に所定の種類のサブクエリ及び所定種類の属性を決定することが可能となり、静的データを、より効率的にかつ高速に扱うことができる。

１、１−１乃至１−ｍ・・・プレイヤー端末、２・・・サーバ、２１，５１・・・ＣＰＵ、１００・・ユーザインターフェイス制御部、１０１・・・クエリ条件送信制御部、１０２・・・検索結果取得部、１０３・・・検索結果表示制御部、１１０・・・サブクエリ抽出部、１１１・・・サブクエリ実行部、１１２・・・ＰＬデータ生成部、１２０・・・ＰＬデータ管理部、１２１・・・クエリ条件取得部、１２２・・・分割部、１２３・・・実行結果抽出部、１２４・・・検索結果生成部、１２５・・・検索結果送信制御部、２００・・・クエリ集合ＤＢ、３００・・・検索対象データＤＢ、４００・・・ＰＬデータＤＢ

Claims (6)

1. 所定のユーザインターフェイスから入力可能であり、かつ、クエリを構成する夫々の条件間において、減少性、冪等性、交換可能性の３つを満たすクエリ条件を用いて、検索対象データに対して検索の処理を実行する情報処理システムにおいて、
   検索の処理前に処理を実行する前処理実行手段と、
   検索の処理を実行する検索処理手段と、
   を備え、
   前記前処理実行手段は、
   種類が静的に定められたクエリの集合を分析することで、クエリの最小単位であり、前記減少性、前記冪等性、前記交換可能性の３つを満たすサブクエリを、限定された種類数の複数種類だけ抽出するクエリ抽出手段と、
   前記クエリ抽出手段により抽出された前記複数種類のサブクエリの夫々を実行するクエリ実行手段と、
   前記クエリ抽出手段により抽出された前記複数種類のサブクエリ毎に、前記クエリ実行手段による実行結果と、当該実行結果に対応する種類のサブクエリを識別可能な情報とを対応付けたデータを、対応付データとして生成する対応付け手段と、
   前記対応付け手段により生成された、前記複数種類のサブクエリ毎の前記対応付データを管理する管理手段と、
   を含み、
   前記検索処理手段は、
   前記ユーザインターフェイスから検索用に入力されたクエリ条件を、検索クエリ条件として受け付ける受付手段と、
   前記受付手段により受け付けられた前記検索クエリ条件を、１種類以上のサブクエリの集合体に分割する分割手段と、
   前記分割手段により分割された前記集合体に属する前記１種類以上のサブクエリの夫々を識別可能な情報に基づいて、当該１種類以上のサブクエリの夫々の実行結果を前記対応付データの中から抽出する実行結果抽出手段と、
   前記実行結果抽出手段の抽出結果に基づいて、前記受付手段により受け付けられた前記検索クエリ条件に対する検索結果を生成する検索結果生成手段と、
   を含む情報処理システム。
2. 前記検索結果生成手段は、前記実行結果抽出手段により抽出された前記１種類以上のサブクエリの夫々の実行結果に対して決定された所定の順番に従って、当該１種類以上のサブクエリの夫々の実行結果の論理演算をすることにより、前記受付手段により受け付けられた前記検索クエリ条件に対する検索結果を生成し、
   前記実行結果抽出手段により抽出された前記１以上のサブクエリの夫々の実行結果について、前記検索対象データにおけるサブクエリの実行結果の量に応じた検索コストを演算し、当該検索コストに基づいて、前記検索結果生成手段における前記論理演算の前記所定の順番を決定する処理順番決定手段をさらに備える、
   請求項１に記載の情報処理システム。
3. 前記ユーザインターフェイスは、複数種類の属性毎に、前記複数種類のサブクエリの中から所定の１種類を選択する操作機能を有する、
   請求項１又は２に記載の情報処理システム。
4. 所定種類の属性の所定種類のサブクエリに対する前記クエリ実行手段による実行結果は、前記所定種類の属性、前記所定種類のサブクエリ、及び、前記検索対象データにおける、当該所定種類の属性の当該所定種類のサブクエリの実行結果の量を含む、
   請求項３に記載の情報処理システム。
5. 所定のユーザインターフェイスから入力可能であり、かつ、クエリを構成する夫々の条件間において、減少性、冪等性、交換可能性の３つを満たすクエリ条件を用いて、検索対象データに対して検索の処理を実行する情報処理システムが実行する情報処理方法において、
   検索の処理前に処理を実行する前処理実行ステップと、
   検索の処理を実行する検索処理ステップと、
   を含み、
   前記前処理実行ステップは、
   種類が静的に定められたクエリの集合を分析することで、クエリの最小単位であり、前記減少性、前記冪等性、前記交換可能性の３つを満たすサブクエリを、限定された種類数の複数種類だけ抽出するクエリ抽出ステップと、
   前記クエリ抽出ステップにおいて抽出された前記複数種類のサブクエリの夫々を実行するクエリ実行ステップと、
   前記クエリ抽出ステップにおいて抽出された前記複数種類のサブクエリ毎に、前記クエリ実行ステップによる実行結果と、当該実行結果に対応する種類のサブクエリを識別可能な情報とを対応付けたデータを、対応付データとして生成する対応付けステップと、
   前記対応付けステップにおいて生成された、前記複数種類のサブクエリ毎の前記対応付データを管理する管理ステップと、
   を含み、
   前記検索処理ステップは、
   前記ユーザインターフェイスから検索用に入力されたクエリ条件を、検索クエリ条件として受け付ける受付ステップと、
   前記受付ステップにより受け付けられた前記検索クエリ条件を、１種類以上のサブクエリの集合体に分割する分割ステップと、
   前記分割ステップにおいて分割された前記集合体に属する前記１種類以上のサブクエリの夫々を識別可能な情報に基づいて、当該１種類以上のサブクエリの夫々の実行結果を前記対応付データの中から抽出する実行結果抽出ステップと、
   前記実行結果抽出ステップにおける抽出結果に基づいて、前記受付ステップにおいて受け付けられた前記検索クエリ条件に対する検索結果を生成する検索結果生成ステップと、
   を含む情報処理方法。
6. 所定のユーザインターフェイスから入力可能であり、かつ、クエリを構成する夫々の条件間において、減少性、冪等性、交換可能性の３つを満たすクエリ条件を用いて、検索対象データに対して検索の処理を実行する情報処理システムに含まれるサーバとクライアントのうち、
   前記サーバに、検索の処理前に処理を実行する前処理実行ステップを含む制御処理を実行させ、
   前記サーバ又はクライアントに、検索の処理を実行する検索処理ステップを含む制御処理を実行させるプログラムであって、
   前記前処理実行ステップは、
   種類が静的に定められたクエリの集合を分析することで、クエリの最小単位であり、前記減少性、前記冪等性、前記交換可能性の３つを満たすサブクエリを、限定された種類数の複数種類だけ抽出するクエリ抽出ステップと、
   前記クエリ抽出ステップにおいて抽出された前記複数種類のサブクエリの夫々を実行するクエリ実行ステップと、
   前記クエリ抽出ステップにおいて抽出された前記複数種類のサブクエリ毎に、前記クエリ実行ステップによる実行結果と、当該実行結果に対応する種類のサブクエリを識別可能な情報とを対応付けたデータを、対応付データとして生成する対応付けステップと、
   前記対応付けステップにおいて生成された、前記複数種類のサブクエリ毎の前記対応付データを管理する管理ステップと、
   を含み、
   前記検索処理ステップは、
   前記ユーザインターフェイスから検索用に入力されたクエリ条件を、検索クエリ条件として受け付ける受付ステップと、
   前記受付ステップにより受け付けられた前記検索クエリ条件を、１種類以上のサブクエリの集合体に分割する分割ステップと、
   前記分割ステップにおいて分割された前記集合体に属する前記１種類以上のサブクエリの夫々を識別可能な情報に基づいて、当該１種類以上のサブクエリの夫々の実行結果を前記対応付データの中から抽出する実行結果抽出ステップと、
   前記実行結果抽出ステップにおける抽出結果に基づいて、前記受付ステップにおいて受け付けられた前記検索クエリ条件に対する検索結果を生成する検索結果生成ステップと、
   を含むプログラム。

Images