検索処理方法及び装置
【課題】順序付けされた複数の検索条件に合致するレコード系列を抽出する際にマッチング回数を削減する。
【解決手段】本方法は、各々特定の項目に対して特定の値が指定されており且つ順序付けがなされた複数の検索条件を含む検索指示に基づき、特定の項目の各項目値にフラグを付与し、フラグ定義データとして格納する工程と、検索対象である複数のレコードを所定のルールに従ってソートする工程と、ソート後の複数のレコードの順番に、フラグ定義データを用いて、処理に係るレコードにおける特定の項目の項目値に対応するフラグを特定する工程と、ソート後の複数のレコードの順番にフラグを特定している過程において、特定されたフラグの出現態様が、検索指示に従ったものであるか判断する工程と、フラグの出現態様が検索指示に従っていると判断された場合には、当該フラグの出現態様に含まれるフラグに係るレコードのデータを出力する工程とを含む。
【解決手段】本方法は、各々特定の項目に対して特定の値が指定されており且つ順序付けがなされた複数の検索条件を含む検索指示に基づき、特定の項目の各項目値にフラグを付与し、フラグ定義データとして格納する工程と、検索対象である複数のレコードを所定のルールに従ってソートする工程と、ソート後の複数のレコードの順番に、フラグ定義データを用いて、処理に係るレコードにおける特定の項目の項目値に対応するフラグを特定する工程と、ソート後の複数のレコードの順番にフラグを特定している過程において、特定されたフラグの出現態様が、検索指示に従ったものであるか判断する工程と、フラグの出現態様が検索指示に従っていると判断された場合には、当該フラグの出現態様に含まれるフラグに係るレコードのデータを出力する工程とを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースに対する検索処理技術に関する。
【背景技術】
【０００２】
例えば、日本特許第３５８１８３１号公報には、以下のような技術が開示されている。以下、図１に示すようなリレーショナルデータベース（ＲＤＢ）のデータが存在する場合について具体的に説明する。図１は、売上履歴テーブルの一部を示しており、顧客ＩＤ、日時、商品、金額、店舗コードという項目（属性）の各々について、各項目値を含む１９のレコードを含むものである。なお、ｒｏｗｉｄは、説明の都合示している行番号（レコード番号とも呼ぶ）である。
【０００３】
図１のようなデータを、上記特許では図２に示すようなデータとして保持する。すなわち、ＲＯＯＴ配列９００１と、顧客ＩＤという項目に関するＰＯＳ配列９００２及びｖａｌｕｅテーブル９００３と、日時という項目に関するＰＯＳ配列９００４及びｖａｌｕｅテーブル９００５と、商品名という項目に関するＰＯＳ配列９００６及びｖａｌｕｅテーブル９００７とが含まれる。ＲＯＯＴ配列９００１は、各ＰＯＳ配列において参照すべき行番号を保持する配列である。顧客ＩＤについては、ｖａｌｕｅテーブル９００３が顧客ＩＤの項目値（００１乃至００７）を一意に特定しており、ＰＯＳ配列９００２は、各行（すなわちposition）にＲＯＯＴ配列９００１において対応する行に格納されたレコード番号のレコードについて参照すべきｖａｌｕｅテーブル９００３における行へのポインタを保持している。例えばＰＯＳ配列９００２の１行目であれば、レコード１についてのデータであって、ＰＯＳ配列９００２の保持する「１」は、ｖａｌｕｅテーブル９００３の１行目を参照して、顧客ＩＤが「００１」であることが分かる。同様に、日時については、ｖａｌｕｅテーブル９００５が日時の項目値（３／１ １０：００乃至３／９ １９：００）を一意に特定しており、ＰＯＳ配列９００４は、各行（すなわちposition）にＲＯＯＴ配列９００１において対応する行に格納されたレコード番号のレコードについて参照すべきｖａｌｕｅテーブル９００５における行へのポインタを保持している。商品名についても、ｖａｌｕｅテーブル９００７が商品名の項目値（ＤＶＤ ＳＯＦＴ乃至冷蔵庫）を一意に特定しており、ＰＯＳ配列９００６は、各行（すなわちposition）にＲＯＯＴ配列９００１において対応する行に格納されたレコード番号のレコードについて参照すべきｖａｌｕｅテーブル９００７における行へのポインタを保持している。
【０００４】
すなわち、各項目において、項目値を一意で特定する項目値番号と当該項目値との関係を保持するｖａｌｕｅテーブルと、レコードの順番に項目値番号を指定する情報が格納されている項目値番号指定情報配列とを保持するようなデータ構造である。
【０００５】
このようなデータ構造を保持することによって、例えば顧客ＩＤが「００１」についてのレコードを抽出する場合には、ｖａｌｕｅテーブル９００３において「００１」が保持されている行の行番号（「１」）を特定し、当該行番号を保持するＰＯＳ配列９００２における行の行番号（１，２，１０，１４）が抽出すべきレコード番号となる。
【０００６】
ここで、図１に示した売上履歴テーブルにおいて、「ＨＤＤレコーダ」、「ＤＶＤプレーヤー」又は「ＴＶ（テレビ）」を購入した後、何らかの「ＳＯＦＴ」を購入し、さらに「ＤＶＤ−Ｒ」又は「ＣＤ−ＲＷ」を購入した顧客を抽出するような検索を行うことを考える。
【０００７】
上記公報には直接このような検索の仕方は開示されていないが、通常であれば以下のような手順を行う必要がある。まず、顧客ＩＤ毎且つ日時順にソートを行う。図１のようなＲＤＢでは、データ量が多い場合にはこのようなソートを行うこと自体が困難であるが、図２のようなデータ構造を利用する場合には、データ量が削減されているのでソートを行うことができる。分かりやすくするため、図３に図１の形でソートした結果を示し、図４にレコード番号のみを含むソート結果を示す。図４のソート結果は、ＳＥＴ配列９０１１として保持され、レコード１、レコード２，レコード１０、レコード１４、．．．といった順番にソートされている。このレコード番号をＳＥＴＩＤとも呼ぶ。
【０００８】
そして、第１段階として「ＨＤＤレコーダ」、「ＤＶＤプレーヤー」又は「ＴＶ」のいずれかに該当するレコードを抽出する。その場合には、図５に示すように、ＳＥＴ配列９０１１の上から順番に、商品名についてのＰＯＳ配列９００６を参照して該当する項目値番号を読み出し、テーブル９００７において当該項目値番号の位置の項目値を特定して、上記の第１の条件に合致するか判断する。ＳＥＴ配列９０１１における１番目のレコード番号は「１」であり、ＰＯＳ配列９００６における第１番目の項目値番号である「５」を特定して、テーブル９００７における５番目の項目値を読み出すと「ＴＶ」であり、上記の第１の条件に合致するため、レコード番号「１」が抽出される。例えば、ＳＥＴ配列９０１１における３番目のレコード番号は「１０」であり、ＰＯＳ配列９００６における１０番目の項目値番号である「１」を特定して、テーブル９００７における１番目の項目値を読み出すと「ＤＶＤ ＳＯＦＴ」であるから、上記の第１の条件を満たしておらず、レコード番号「１０」は抽出されない。このような処理を繰り返す。
【０００９】
そうすると、図６の配列９０２１のようなＳＥＴＩＤ列を得ることができる。これだけでは、具体的内容が分かりにくいので、抽出された具体的なレコードの内容をテーブル９０２２に示す。しかし、このデータだけでは第２の条件を満たしているかは不明であるので、再度ＳＥＴ配列９０１１のデータを参照しなければならない。
【００１０】
具体的には、図６の配列９０２１からレコード番号を得ると、図４のＳＥＴ配列９０１１において次の順番のレコード番号を特定する。例えばレコード番号「１」であれば、レコード番号「２」が特定される。そして、商品名についてのＰＯＳ配列９００６を参照して、特定されたレコード番号の位置における項目値番号を読み出し、テーブル９００７において項目値番号の位置の項目値を特定して、上記の第２の条件に合致するか判断する。レコード番号「２」が特定されれば、ＰＯＳ配列９００６の２番目の項目値番号である「４」を読み出し、項目値番号「４」の位置の項目値である「ＨＤＤレコーダ」を特定して、第２の条件である「ＳＯＦＴ」と比較する。この場合には、合致しないという判断が行われる。同様に、配列９０２１の２番目のレコード番号「２」であれば、ＳＥＴ配列９０１１において次のレコード番号は「１０」である。レコード番号「１０」に従ってＰＯＳ配列９００６の１０番目の項目値番号「１」を読み出し、テーブル９００７において項目値番号「１」の位置の項目値である「ＤＶＤ ＳＯＦＴ」を特定して、第２の条件である「ＳＯＦＴ」と比較する。この場合には、合致するという判断が行われる。
【００１１】
上で述べたような処理は図７にまとめられている。図７には、次のレコードについてのＳＥＴ配列９０３１と、対応するデータテーブル９０３２と、商品名という項目についてのＰＯＳ配列９００６及びｖａｌｕｅテーブル９００７とが示されている。次のレコードについてのＳＥＴ配列９０３１及びデータテーブル９０３２において、ハッチングが付された行については、第２の条件を満たしておらず、結果としてレコード番号１０、レコード番号９、レコード番号１７が抽出される。
【００１２】
なお、説明を省略したが、同一顧客が第１乃至第３の条件を順番に満たす必要があるので、一人の顧客について最低でも３レコード必要であって、次のレコードが存在しない場合には処理の対象外となる。例えば次のレコードについてのＳＥＴ配列９０３１の最下行には次のレコードが存在しない場合を示しており「−」が記録されている。
【００１３】
このように第１の条件を満たすレコード番号を格納した配列９０２１が抽出されても、次のレコードを抽出するために再度ＳＥＴ配列９０１１にアクセスする必要があり、次のレコードについてのＳＥＴ配列９０３１については、第２の条件に合致するか否かを再度確認する必要がある。
【００１４】
さらに、第３の条件を満たしているかを確認するために、再度ＳＥＴ配列９０１１のデータを参照しなければならない。
【００１５】
具体的には、図７に示した次のレコードについてのＳＥＴ配列９０３１においてハッチングが付されていないレコード番号「１０」、レコード番号「９」及びレコード番号「１７」のそれぞれについて、再度ＳＥＴ配列９０１１において次の順番のレコード番号を特定する。例えば、レコード番号「１０」の次のレコードのレコード番号は、図８において次の次のレコードについてのＳＥＴ配列９０４１に示すように、レコード番号「１４」であり、レコード番号「９」の次のレコードのレコード番号は、同様にレコード番号「１８」であり、レコード番号「１７」の次のレコードのレコード番号は、存在しない。
【００１６】
次に、商品名についてのＰＯＳ配列９００６を参照して、特定されたレコード番号の位置における項目値番号を読み出し、テーブル９００７において項目値番号の位置の項目値を特定して、上記の第３の条件に合致するか判断する。すなわち、ＰＯＳ配列９００６においてレコード番号「１４」の位置における項目値番号「２」を読み出し、ｖａｌｕｅテーブル９００７において項目値番号「２」の項目値「ＤＶＤ−Ｒ」を特定して、上記の第３の条件と比較して、合致すると判断する。また、ＰＯＳ配列９００６においてレコード番号「１８」の位置における項目値番号「２」を読み出し、ｖａｌｕｅテーブル９００７において項目値番号「２」の項目値「ＤＶＤ−Ｒ」を特定して、上記の第３の条件と比較して、合致すると判断する。
【００１７】
すなわち、顧客ＩＤ「１」についてレコード番号「２」、レコード番号「１０」及びレコード番号「１４」の系列と、顧客ＩＤ「４」についてレコード番号「６」、レコード番号「９」及びレコード番号「１８」の系列とが抽出されることになる。
【００１８】
このように第２の条件を満たすレコード番号を格納した配列（次のレコードのＳＥＴ配列９０３１の一部）が抽出されても、次のレコードを抽出するために再度ＳＥＴ配列９０１１にアクセスする必要があり、次の次のレコードについてのＳＥＴ配列９０４１については、第３の条件に合致するか否かを再度確認する必要がある。
【００１９】
このように少ないレコード数であればそれほどマッチング回数は増加しないが、１レコードについて何回もマッチングの是非について判断する必要があり、レコード数が膨大になればマッチング回数も膨大となるという問題がある。
【００２０】
なお、特開２０００−２０５２７号公報には、データベースシステムで、条件検索の検索結果を再利用するための行位置情報の格納方法を、検索のヒット率により切りわけることで領域を最小化し、検索を高速に行うための技術が開示されている。具体的には、検索処理時、データベース管理プログラムが処理中の検索と一致する検索条件を検索結果管理テーブルに発見した場合、対応する検索結果位置情報を参照することで、一致した検索条件についてのデータベースの検索を不要とするものである。しかしながら、上記のような問題を解決することはできない。
【００２１】
また、特開２００５−２５１００２号公報には、基になるデータベースの構造は従来どおりとし、検索結果ファイルが一旦生成された後も絞り込み検索などのための再検索を可能とするための技術が開示されている。具体的には、所定の検索条件に該当するデータをデータベースから抽出し、その抽出データのデータベース上の格納場所を示すロケータを含む検索結果ファイルを生成する。再検索の際にはロケータによりデータベースを参照して再検索用データを取得し、再検索条件に該当するデータを抽出し、新たな検索結果ファイルとして生成する。この公報でも上記のような問題を解決することはできない。
【特許文献１】日本特許第３５８１８３１号公報
【特許文献２】特開２０００−２０５２７号公報
【特許文献３】特開２００５−２５１００２号公報
【発明の開示】
【発明が解決しようとする課題】
【００２２】
このように従来技術では、購買履歴等を抽出する際などに生ずる、順序付けされた複数の検索条件に合致するレコード系列を抽出する処理において、膨大な数に上るレコードについてのマッチング回数を減らして、処理を高速化することはできない。
【００２３】
従って、本発明の目的は、順序付けされた複数の検索条件に合致するレコード系列を抽出する際にレコードに対するマッチング回数を削減するための技術を提供することである。
【課題を解決するための手段】
【００２４】
本発明に係る検索処理方法は、各々特定の項目に対して特定の値が指定されており且つ順序付けがなされた複数の検索条件を含む検索指示に基づき、特定の項目の各項目値にフラグを付与し、フラグ定義データとして記憶装置に格納するフラグ付与ステップと、データベースに格納されており且つ検索対象である複数のレコードを所定のルール（例えば時系列）に従ってソートするソート・ステップと、ソート後の複数のレコードの順番に、記憶装置に格納されたフラグ定義データを用いて、処理に係るレコードにおける特定の項目の項目値に対応するフラグを特定するフラグ特定ステップと、ソート後の複数のレコードの順番にフラグを特定している過程において、特定されたフラグの出現態様（例えばフラグの出現順番や検出の連続性など）が、検索指示に従ったものであるか判断する判断ステップと、フラグの出現態様が検索指示に従っていると判断された場合には、当該フラグの出現態様に含まれるフラグに係るレコードのデータを出力するステップとを含む。
【００２５】
このような処理を実施すれば、従来ではデータベースのレコードと検索条件とがマッチングするか否かを何度も判断するような処理が、データベースのレコード群を検索指示に基づくフラグ系列に変換してフラグの出現態様が検索指示に従ったものであるかを確認する処理に変換され、マッチング処理の回数が削減され処理が効率化される。
【００２６】
また、上で述べたフラグ付与ステップが、特定の検索条件に含まれる、特定の項目の特定の値に対応し且つデータベース内のレコードに含まれる特定の項目の項目値を特定するステップと、特定された項目値に、特定の検索条件の順序付けに応じたフラグを付与するステップとを含むようにしてもよい。従来では、検索条件に含まれる項目値とレコードの項目値とを一致しているか否か、部分一致か否かなどを同じレコードについても何度も判断する必要があるが、最初のステップを実施すれば、項目値間の比較の処理の実施回数が最大でも検索条件に含まれる項目値の種類数×データベース内の項目値の種類数に限定され、簡略化される。また、次のステップを実施すれば、フラグが順序付けを表すようになるため、フラグの出現態様を判断しやすくなる。
【００２７】
さらに、上で述べた判断ステップが、特定されたフラグに応じて、順序付けに応じて定義される状態間の遷移が発生するか判断するステップと、状態間の遷移が発生した場合には、最終状態まで到達したか判断するステップとを含むようにしてもよい。このように状態遷移を管理することによって、フラグの出現態様が検索指示に従っているかを正確且つ簡易に判断できるようになる。また、状態間の遷移の条件を適切に定義することによって、多様な検索指示に対処できるようになる。
【００２８】
なお、所定のルールを、検索指示で指定されたグループ項目毎且つ時系列という条件としてもよい。この場合、上記判断ステップにおいて、グループ項目における同一の項目値内においてフラグの出現態様を判断するようにしてもよい。顧客の購買履歴の検索などは、このような処理を行えばよい。
【００２９】
さらに、上記データベースが、各項目において、項目値を一意で特定する項目値番号と当該項目値との関係を保持するテーブルと、レコードの順番に項目値番号を指定する情報が格納されている項目値番号指定情報配列とを保持するようにしてもよい。このようなデータ構造を用いることによって、ソート処理が簡易且つ高速に実施できる。
【００３０】
また、上記フラグが、該当する検索条件の前記順序付けに応じたビット位置に１がセットされたビット列であるようにしてもよい。より高速にフラグの出現態様を判断できるようになる。
【００３１】
なお、上で述べたフラグ特定ステップを、データベースに格納されており且つ検索対象である複数のレコードに１回のみ実施すれば、マッチング処理の回数が削減できる。
【００３２】
本発明にかかる方法をコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してディジタル信号にて頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。
【発明の効果】
【００３３】
本発明によれば、順序付けされた複数の検索条件に合致するレコード系列を抽出する際にレコードに対するマッチング回数を削減することができるようになる。
【発明を実施するための最良の形態】
【００３４】
図９に本発明の一実施の形態に係るシステム概要図を示す。例えばＬＡＮ（Local Area Network）などのネットワーク１には、１又は複数のユーザ端末３と、データベース（ＤＢ）を管理するＤＢサーバ５とが接続されている。ここでは、ＤＢサーバ５は、１台のコンピュータで実施する場合を示すが、複数台のコンピュータによって実施するようにしても良い。また、ＤＢサーバ５は、１種類だけではなく複数種類のデータベースを管理する場合もある。
【００３５】
本実施の形態では、レコードのソートを行うことを前提とするので、通常のＲＤＢでは処理速度及び記憶容量の面で実際的ではなく、図２に示したようなデータ構造（以下、ＦＡＳＴ構造と呼ぶ）でデータを管理しているものとする。ＦＡＳＴ構造で管理されたデータは、ＦＡＳＴ構造データ格納部５６に格納されているものとする。
【００３６】
ＤＢサーバ５は、ネットワーク１を介してユーザ端末３からの検索指示を受信する検索指示受信部５１と、検索指示受信部５１が受信した検索指示に係るデータを格納する検索指示データ格納部５２と、検索指示データ格納部５２に格納されているデータを用いてイベント判定処理を行うイベント判定処理部５３と、イベント判定処理部５３の処理結果を格納するイベント管理テーブル格納部５４と、検索指示データ格納部５２とイベント管理テーブル格納部５４とＦＡＳＴ構造データ格納部５６とに格納されたデータを用いて処理を行う検索前処理部５５と、検索前処理部５５による処理結果であるイベント履歴条件テーブルを格納するイベント履歴条件テーブル格納部５７と、検索前処理部５５の処理結果であるソート結果のデータを格納するソート結果格納部５８と、ＦＡＳＴ構造データ格納部５６とソート結果格納部５８とイベント履歴条件テーブル格納部５７とに格納されているデータを用いて検索前処理部５５の指示に従って検索処理を行い該当データを抽出する検索処理部５９と、検索処理部５９による処理結果を格納する検索結果格納部６０と、検索結果格納部６０に格納されたデータを要求元のユーザ端末３に出力する検索結果出力部６１とを含む。なお、検索処理部５９は、検索前処理部５５による設定に基づき状態遷移の管理を行う状態遷移管理部５９１を含む。
【００３７】
次に、図９に示したシステムの動作を図１０乃至図２４を用いて説明する。なお、従来技術で説明した具体例をそのまま用いて説明する。すなわち、図２に示したようなデータ構造がＦＡＳＴ構造データ格納部５６に格納されており、「ＨＤＤレコーダ」、「ＤＶＤプレーヤー」又は「ＴＶ（テレビ）」を購入した後、何らかの「ＳＯＦＴ」を購入し、さらに「ＤＶＤ−Ｒ」又は「ＣＤ−ＲＷ」を購入した顧客を抽出するような検索を行うことを考える。なお、ＦＡＳＴ構造に係るデータは、図１に示した売上履歴テーブルと同様の内容を保持している。
【００３８】
まず、ユーザ端末３のユーザは、ユーザ端末３を操作して、ＤＢサーバ５にアクセスし、検索指示の入力画面を表示装置に表示させる。例えば、図１０に示すような画面が表示装置に表示される。図１０の画面例では、検索対象のテーブル名、種別並びに開始ＳＥＴＩＤ及びレコード数の表示／指定欄３０１と、ソートの際にグループ化する項目であるグループ項目、ソートする項目であるソート項目及び検索条件であるイベントを指定するための抽出条件指定欄３０２と、抽出条件指定欄３０２において複数のイベントが指定された場合に当該イベント間の順序関係を指定するためのイベント順序条件指定欄３０３と、検索条件に合致したレコードについて抽出すべき項目を指定するための抽出項目指定欄３０４とを含む。なお、上で述べた条件のとおり、抽出条件であるイベント１では、商品名が「テレビ」「ＨＤＤレコーダ」又は「ＤＶＤプレーヤー」であることが条件として指定されている。同様に、イベント２では、商品名が「ＳＯＦＴ」に類似することが条件として指定されており、イベント３では、商品名が「ＤＶＤ−Ｒ」又は「ＣＤ−ＲＷ」であることが条件として指定されている。イベント順序については、昇順、降順、全組合せ（全順列）、任意指定などを行うことができるようになっており、上で述べた条件では、昇順が選択される。なお、任意指定では、様々な順序条件を指定することができ、Ｅ１，（Ｅ２，Ｅ３）は、Ｅ１，Ｅ２，Ｅ３と、Ｅ１，Ｅ３，Ｅ２という順序条件を指定したことになる。
【００３９】
ユーザは、図１０のような画面において必要な条件を指定して、ＯＫボタン３０５をクリックすると、ユーザ端末３は当該指示を受け付け、検索指示としてＤＢサーバ５に送信する。検索指示には、検索対象のデータ、抽出条件（グループ項目、ソート項目、イベント群）、抽出順序条件及び抽出項目を含む。なお、図１０では指定できないが、他の条件を付加するようにしても良い。
【００４０】
ＤＢサーバ５の検索指示受信部５１は、ユーザ端末３から検索指示を受信し、当該検索指示に係るデータを検索指示データ格納部５２に格納する（図１１：ステップＳ１）。そうすると、イベント判定処理部５３は、検索指示データ格納部５２に格納された検索指示に係るデータを用いてイベント判定処理を実施する（ステップＳ３）。このイベント判定処理については、図１２及び図１３を用いて説明する。まず、イベント判定処理部５３は、検索指示データ格納部５２に格納されているイベントのうち未処理のイベントを特定し（ステップＳ１１）、項目名と項目値のセットを当該未処理のイベントから抽出し、イベント管理テーブルに登録する（ステップＳ１３）。イベント管理テーブル格納部５４に格納されるイベント管理テーブルの一例を図１３に示す。図１３の例では、イベントと、項目名と、項目値とが登録されるようになっている。なお、同一イベントでも、項目名及び項目値の複数の組み合わせが指定される場合もあり、その場合には同一イベントに複数行のデータが登録される。上で述べた具体的な条件の場合には、図１３に示したようなデータがイベント管理テーブルに登録される。
【００４１】
そして、イベント判定処理部５３は、全てのイベントを処理したか判断し（ステップＳ１５）、未処理のイベントが存在する場合にはステップＳ１１に戻る。一方、全てのイベントについて処理した場合には元の処理に戻る。
【００４２】
図１１の説明に戻って、次に検索処理を実施する（ステップＳ５）。検索処理については、図１４乃至図２３を用いて説明する。
【００４３】
まず、検索前処理部５５は、イベント管理テーブル格納部５４に格納されているイベント管理テーブルから各イベントに使用される項目名を特定し、当該項目名毎に、全項目値をＦＡＳＴ構造データ格納部５６から取得し、項目名毎にイベント履歴条件テーブルを構成する（図１４：ステップＳ２１）。具体的には、図１５にイベント履歴条件テーブルの一例を示す。上で述べた条件では、項目は「商品名」であるから、図２のｖａｌｕｅテーブル９００７を取得する。図１５に示したイベント履歴条件テーブルでは、このｖａｌｕｅテーブル９００７に含まれる項目値を各行としており、状態遷移を表すための状態Ｓ１乃至Ｓ８の列と、イベントフラグ（ＦＬＧ）の列とが設けられている。なお、イベント履歴条件テーブルは、イベント管理テーブルに格納されているイベントと状態とを対応付けることができるような構成にもなっている。
【００４４】
次に、検索前処理部５５は、イベント管理テーブル格納部５４内のイベント管理テーブル及び検索指示データ格納部５２を参照して、各状態についてイベントを対応付けると共に該当する項目値にフラグをセットし、各項目値についてのイベントフラグを生成する（ステップＳ２３）。
【００４５】
検索指示データ格納部５２には、処理に係る検索指示におけるイベントの順序条件が格納されている。この順序条件に従って、イベントと状態との対応付けを行う。上で述べた条件においては、イベント１（Ｅ１）、イベント２（Ｅ２）、イベント３（Ｅ３）の順番で検索を行うので、状態Ｓ１とイベント１、状態Ｓ２とイベント２、状態Ｓ３とイベント３とが対応付けられ、イベント履歴条件テーブルに登録される。ここまで処理すると、イベント履歴条件テーブルは図１６に示すような状態となる。なお、状態Ｓ４乃至Ｓ８は今回はイベントとの対応付けはないので、ハッチングが付されて、各状態におけるフラグは「０」にセットされている。
【００４６】
さらに、各状態について該当する項目値にフラグをセットする。上で述べた条件においては、イベント１（Ｅ１）では、「ＤＶＤプレーヤー」、「ＨＤＤレコーダ」又は「ＴＶ」が指定されているので、該当する項目値として「ＤＶＤプレーヤー」、「ＨＤＤレコーダ」及び「ＴＶ」を特定する。さらに、それぞれの行においてイベント１に対応する状態Ｓ１の列に「１」をセットし、それ以外については「０」をセットする。
【００４７】
なお、検索条件において指定されている項目値と、実際にデータベースに登録されている項目値とは完全一致しない場合もある。本実施の形態では、レコード毎に項目値間の一致／不一致を判断するのではなく、この段階においてｖａｌｕｅテーブル９００７に登録されている項目値と検索条件において指定されている項目値との一致／不一致を判断するので、後の処理が簡略化される。
【００４８】
同様に、イベント２（Ｅ２）では、「ＳＯＦＴ」が指定されているので、該当する項目値として「ＤＶＤ ＳＯＦＴ」が特定される。このように、完全一致が存在しない場合にはレコード毎に比較する従来技術に比して、後の処理は効率化される。そして、「ＤＶＤ ＳＯＦＴ」の行においてイベント２に対応する状態Ｓ２の列に「１」をセットし、それ以外については「０」をセットする。
【００４９】
イベント３（Ｅ３）では、「ＤＶＤ−Ｒ」又は「ＣＤ−ＲＷ」が指定されているので、該当する項目値として「ＤＶＤ−Ｒ」のみが特定される。このように、完全に不一致の項目値を含む検索条件が指定されている場合には、レコード毎の比較は非常に非効率であることが分かる。そして、「ＤＶＤ−Ｒ」の行においてイベント３に対応する状態Ｓ３の列に「１」をセットし、それ以外については「０」をセットする。
【００５０】
そして、状態Ｓ１乃至Ｓ８までにセットされたフラグのビットを２進数のビット列として取り扱う。なお、イベントの順序が早いほど下位ビットに「１」がセットされ、遅いほど上位ビットに「１」がセットされる。このように、イベントの順番に応じたイベントフラグが設定される。同じ順番であれば異なる項目値であっても同じイベントフラグが設定される。図１７では、このビット列を、１０進数の値に直した値をイベントフラグ（ＦＬＧ）の列に示している。但し、２進数のままでもよい。
【００５１】
ここまででイベント履歴条件テーブルが完成するので、このイベント履歴条件テーブルのデータをイベント履歴条件テーブル格納部５７に格納する。なお、後に説明するが、ｖａｌｕｅテーブル９００７の代わりとなるテーブルが必要となるので、図１８のようなテーブル５０１を生成して、イベント履歴条件テーブル格納部５７に格納しておく。
【００５２】
その後、検索前処理部５５は、ＦＡＳＴ構造データ格納部５６を参照して、ＦＡＳＴ構造の検索対象データを、検索指示データ格納部５２に格納されているグループ項目及びソート項目に応じてソートを実施し、ソート結果をソート結果格納部５８に格納する（ステップＳ２５）。この処理自体は従来技術と同様である。ソート結果格納部５８に格納されるデータは、図４に示したようなデータである。
【００５３】
また、検索前処理部５５は、状態遷移の条件を検索指示に従って、状態遷移管理部５９１に設定する（ステップＳ２７）。以下で詳細に説明するが、状態遷移の条件は、様々に設定できる。例えば、上の例では、イベント１の次にイベント１が発生した場合の取扱いや、イベント１の次にイベント１乃至３のいずれでもないイベントが発生した後にイベント２が発生した場合の取扱いなど、検索者の意図に沿って状態遷移の条件を設定すべき場合もある。ここでは、検索指示に、イベント１の次にイベント１乃至３のいずれでもないイベントが発生した後にイベント２が発生した場合等の取扱いについて指示があれば、状態遷移管理部５９１に設定する。ステップＳ２７は、デフォルトの設定に従う場合にはスキップされる場合もある。なお、イベント数によって状態数が確定するので、当該状態数の設定は必ず行われる。処理は端子Ａを介して図２０の処理に移行する。
【００５４】
状態遷移管理部５９１により管理される状態及び状態遷移を図１９を用いて説明する。必要な状態は、イベント１乃至３に対応する状態Ｓ１乃至Ｓ３と、初期状態Ｓ０である。なお、状態Ｓ３は、最終状態として特定される。イベント数が増加すれば、その分状態は増加し、イベント数が減少すれば、その分状態は減少する。また、状態遷移は、イベント１の検索条件が満たされた場合に発生する初期状態Ｓ０から状態Ｓ１への状態遷移Ａと、イベント２の検索条件が満たされた場合に発生する状態Ｓ１から状態Ｓ２への状態遷移Ｂと、イベント３の検索条件が満たされた場合に発生する状態Ｓ２から状態Ｓ３への状態遷移Ｄと、最終状態である状態Ｓ３への到達が確認された場合に発生する状態Ｓ３から初期状態Ｓ０への状態遷移Ｆと、初期状態Ｓ０においてイベント１の検索条件が満たされない場合に発生する初期状態Ｓ０から初期状態Ｓ０への状態遷移Ｇと、状態Ｓ１においてイベント１の検索条件が再度満たされた場合に発生する状態Ｓ１から状態Ｓ１への状態遷移Ｃと、状態Ｓ２においてイベント２の検索条件が再度満たされた場合に発生する状態Ｓ２から状態Ｓ２への状態遷移Ｅと、状態Ｓ１においてイベント１又は２の条件が満たされなかった場合に発生する状態Ｓ１から状態Ｓ０への状態遷移Ｈと、状態Ｓ２においてイベント２又は３の条件が満たされなかった場合に発生する状態Ｓ２から状態Ｓ０への状態遷移Ｉとを含む。このように、初期状態から途中の状態を介して最終状態へ至る状態遷移と、最終状態以外の状態においてその状態への遷移が発生した場合に生ずる自己遷移と、最終状態に到達したことが確認された場合に生ずる最終状態から初期状態への状態遷移と、次の状態への状態遷移又は自己遷移とのいずれもが発生しなかった場合における初期状態への状態遷移とが含まれる。
【００５５】
なお、自己遷移及び初期状態への状態遷移の条件を検索指示に応じて設定することで、フレキシブルな抽出を行うことができる。例えば、それより後の状態への遷移を発生させる条件が満たされされない限り自己遷移するように設定してもよい。例えば、「ＨＤＤレコーダ」、「ＤＶＤ−ＳＯＦＴ」、「ＤＶＤ−Ｒ」の順番で購入すれば、上で述べた条件を満たすことになるが、「ＨＤＤレコーダ」、「冷蔵庫」、「ＤＶＤ−ＳＯＦＴ」、「ＤＶＤ−Ｒ」の順番で購入すると、上で述べた条件を満たしたことにはならない。但し、「冷蔵庫」のレコードが検出されても初期状態へ遷移することなく自己遷移するようにすれば、後者のような購買履歴でも条件を満たすと判断される。すなわち、大きく購買履歴を捉えて、概ね目的とする購買履歴を行っている顧客を抽出できるようになる。
【００５６】
次に、検索処理部５９は、ソート結果格納部５８に格納されているレコード（図４）から未処理レコードを特定する（図２０：ステップＳ２９）。そして、特定された未処理レコードのグループ項目の項目値を特定する（ステップＳ３１）。特定された未処理レコードのレコード番号（ＳＥＴＩＤ）を用いて、ＦＡＳＴ構造データ格納部５６に格納されている、顧客ＩＤについてのＰＯＳ配列９００２から対応する位置の項目値番号を読み出し、当該項目値番号に基づきｖａｌｕｅテーブル９００３から項目値を取得する。
【００５７】
そして、検索処理部５９は、ステップＳ３１で特定された未処理レコードのグループ項目の項目値が変化したか判断する（ステップＳ３３）。従前に処理したレコードのグループ項目の項目値を保持しておき、変化したか判断する。これは、検索条件を満たしているかは、グループ項目が同一の項目値である間のレコードについて判断すべきであるからである。なお、従前に処理したレコードが存在しない場合には、変化したと判断される。
【００５８】
もし変化したと判断された場合には、状態遷移管理部５９１に初期状態Ｓ０に遷移させる（ステップＳ３５）。ステップＳ３５の後又はグループ項目の項目値が変化していないと判断された場合には、特定された未処理レコードのイベントフラグを特定する（ステップＳ３７）。この処理については、図２１を用いて説明する。
【００５９】
まず、ソート結果格納部５８に格納されたＳＥＴ配列９０１１から未処理レコードを特定すると、その未処理レコードのレコード番号を特定し、ＦＡＳＴ構造データ格納部５６に格納されている、商品名についてのＰＯＳ配列９００６において、レコード番号の位置の項目値番号を特定し、従前のｖａｌｕｅテーブル９００７の代わりに、イベントフラグテーブル５０１における項目値番号の位置のイベントフラグを特定する。ＳＥＴＩＤが「１」であれば、ＰＯＳ配列９００６において項目値番号が「５」と特定されるが、ｖａｌｕｅテーブル９００７から「ＴＶ」を特定するのではなく、イベントフラグテーブル５０１からイベントフラグ「１」（２進数で「０００００００１」）を特定する。
【００６０】
図２０の説明に戻って、状態遷移管理部５９１は、特定されたイベントフラグに応じた状態遷移を実施する（ステップＳ４１）。なお、状態遷移に係るレコードのレコード番号（ＳＥＴＩＤ）を保持しておく。保持しておくレコード番号は、初期状態から最終状態への直接の経路上の状態遷移に係るレコードのレコード番号だけでもよい。図１９の例では、状態遷移Ａ、状態遷移Ｂ及び状態遷移Ｄを生じさせたレコードのレコード番号である。このように特定の状態遷移の発生の有無を判断する場合もある。
【００６１】
どのような状態遷移が発生するかは、現在の状態が何であるか、特定されたイベントフラグが何であるかに依存する。図１９に示したような状態及び状態遷移の場合、初期状態Ｓ０から状態Ｓ１への状態遷移Ａは、初期状態Ｓ０において、イベントフラグ（２進ビット列）の最下位ビット（第８ビット）が「１」となっているイベントフラグが特定された場合に生ずる。状態Ｓ１から状態Ｓ２への状態遷移Ｂは、状態Ｓ１において、イベントフラグの第７ビットが「１」となっているイベントフラグが特定された場合に生ずる。状態Ｓ２から状態Ｓ３への状態遷移Ｄは、状態Ｓ２において、イベントフラグの第６ビットが「１」となっているイベントフラグが特定された場合に生ずる。状態Ｓ１における自己遷移である状態遷移Ｃは、イベントフラグの最下位ビットが「１」となっているイベントフラグが特定された場合に生ずる。状態Ｓ２における自己遷移である状態遷移Ｅは、イベントフラグの第７ビットが「１」となっているイベントフラグが特定された場合に生ずる。状態Ｓ３から状態Ｓ０への状態遷移Ｆは、以下で説明する処理において管理されるが、それ以外の状態遷移Ｇ、Ｈ及びＩについては、上で述べた以外のイベントフラグが特定された場合に生ずる。なお、上で述べたように、自己遷移については、別の定義で行うようにしても良い。
【００６２】
このように、現在の状態及びイベントフラグの所定のビットを検査するだけで状態遷移が発生するか否かを判断することができる。
【００６３】
図２０の説明に戻って、状態遷移管理部５９１は、最終状態に到達したか判断する（ステップＳ４３）。図１９の例では、最終状態Ｓ３に達したかを判断する。最終状態には到達していないと判断された場合にはステップＳ４９に移行する。一方、最終状態に到達したと判断された場合には、今回の状態遷移に対応するレコード番号を検索結果格納部６０内の抽出イベントテーブルに登録する（ステップＳ４５）。抽出イベントテーブルは、例えば図２２に示すようなテーブルである。すなわち、抽出番号（Ｎｏ．）と、状態Ｓ１への状態遷移を発生させたレコード番号（ＳＥＴＩＤ）、状態Ｓ２への状態遷移を発生させたレコード番号、状態Ｓ３への状態遷移を発生させたレコード番号が登録されるようになっている。状態遷移管理部５９１は、その後、初期状態Ｓ０への状態遷移を実施させる（ステップＳ４７）。
【００６４】
ステップＳ４７の後又はステップＳ４３で最終状態に到達していないと判断された場合、検索対象レコードの最終レコードを処理したか判断する（ステップＳ４９）。未処理のレコードが存在する場合にはステップＳ２９に戻る。一方、最終レコードを処理した場合には、元の処理に戻る。
【００６５】
図４のようなソート結果を得た場合におけるステップＳ２９乃至Ｓ４９の処理の経過を図２３にまとめて示す。１番目のレコードのイベントフラグは「１」であり、最下位（第８）ビットが「１」となっているので、初期状態Ｓ０から状態Ｓ１への状態遷移を発生させる。２番目のレコードのイベントフラグは「１」であり、第８ビットが「１」となっているので、自己遷移で状態Ｓ１への状態遷移を発生させる。３番目のレコードのイベントフラグは「２」であり、第７ビットが「１」となっているので、状態Ｓ２への状態遷移を発生させる。４番目のレコードのイベントフラグは「４」であり、第６ビットが「１」となっているので、状態Ｓ３への状態遷移を発生させる。すなわち、最終状態に到達したので、図４のＳＥＴ配列９０１１において１番目、３番目及び４番目のレコード番号が出力される。なお、２番目のレコードは自己遷移を発生させているので、２番目、３番目、４番目のレコード番号を出力するようにしても良い。そして、初期状態Ｓ０に遷移する。
【００６６】
なお、５番目のレコードを処理する際には、グループ項目である顧客ＩＤが変化するので、初期状態Ｓ０に強制的に遷移させる。また、５番目のレコードのイベントフラグは「０」であり、初期状態Ｓ０への自己遷移が発生する。６番目のレコードのイベントフラグは「０」であり、初期状態Ｓ０への自己遷移が発生する。７番目のレコードのイベントフラグは「１」であり、初期状態Ｓ０から状態Ｓ１への状態遷移を発生させる。８番目のレコードのイベントフラグは「０」であり、初期状態Ｓ０への状態遷移を発生させる。
【００６７】
なお、９番目のレコードを処理する際には、グループ項目である顧客ＩＤが変化するので、初期状態Ｓ０に強制的に遷移させる。また、９番目のレコードのイベントフラグは「１」であり、初期状態Ｓ０から状態Ｓ１への状態遷移を発生させる。１０番目のレコードのイベントフラグは「１」であり、状態Ｓ１への自己遷移が発生する。１１番目のレコードのイベントフラグは「４」であり、状態Ｓ１から初期状態Ｓ０への遷移が発生する。
【００６８】
なお、１２番目のレコードを処理する際には、グループ項目である顧客ＩＤが発生するので、初期状態Ｓ０に強制的に遷移させる。また、１２番目のレコードのイベントフラグは「１」であり、初期状態Ｓ０から状態Ｓ１への状態遷移を発生させる。１３番目のレコードのイベントフラグは「２」であり、状態Ｓ１から状態Ｓ２への状態遷移を発生させる。１４番目のレコードのイベントフラグは「４」であり、状態Ｓ２から状態Ｓ３への状態遷移を発生させる。すなわち、最終状態に到達したので、図４のＳＥＴ配列９０１１において１２番目、１３番目及び１４番目のレコードが出力される。そして、初期状態Ｓ０に遷移する。
【００６９】
なお、１５番目のレコードを処理する際には、グループ項目である顧客ＩＤが変化するので、初期状態Ｓ０に強制的に遷移させる。また、１５番目のレコードのイベントフラグは「１」であり、初期状態Ｓ０から状態Ｓ１への状態遷移を発生させる。１６番目のレコードのイベントフラグは「０」であり、初期状態Ｓ０に遷移させる。
【００７０】
なお、１７番目のレコードを処理する際には、グループ項目である顧客ＩＤが変化するので、初期状態Ｓ０に強制的に遷移させる。また、１７番目のレコードのイベントフラグは「１」であり、初期状態Ｓ０から状態Ｓ１への状態遷移を発生させる。１８番目のレコードは「２」であり、状態Ｓ１から状態Ｓ２への状態遷移を発生させる。
【００７１】
なお、１９番目のレコードを処理する際には、グループ項目である顧客ＩＤが変化するので、初期状態Ｓ０に強制的に遷移させる。また、１９番目のレコードのイベントフラグは「１」であり、初期状態Ｓ０から状態Ｓ１への状態遷移を発生させる。但し、これが最終レコードであるから、処理は元の処理に戻る。
【００７２】
このように、項目値同士の比較はイベントフラグ設定時にのみ行って、各レコードについての処理についてはイベントフラグを特定し、イベントフラグに応じて発生する状態遷移が定義通り発生するか判断するだけになっている。イベントフラグのチェック処理についても、上で述べたようなイベントフラグを使用する場合には所定のビット位置に「１」が設定されているかを確認するだけであるから、非常に処理が簡単化されている。また、レコードに対する処理は１レコードにつき１回に限定されており、膨大な数のレコードを処理する場合にも、処理負荷を下げることができる。
【００７３】
図１１の説明に戻って、検索処理部５９は、検索結果格納部６０内の抽出イベントテーブルを基に、検索指示データ格納部５２に格納されている抽出項目の項目値を、ＦＡＳＴ構造データ格納部５６から抽出し、検索結果格納部６０に格納する（ステップＳ７）。この処理は、図２で説明したように、レコード番号から、抽出すべき項目のＰＯＳ配列内の対応する位置の項目値番号を取得し、当該項目値番号に対応する項目値をｖａｌｕｅテーブルから読み出す処理である。顧客ＩＤ、日時、商品名、金額、店舗コードを抽出する場合には、図２４のようなデータが、検索結果格納部６０に格納される。図２３の例では２回登録がなされているので、それぞれについて３つのレコードが２セット抽出され、格納されている。
【００７４】
そして、検索結果出力部６１は、検索結果格納部６０に格納されている検索結果を読み出して要求元のユーザ端末３に出力する（ステップＳ９）。ユーザ端末３は、ＤＢサーバ５から検索結果のデータを受信し、表示装置に表示する。例えば図２４に示したようなデータを表示装置に表示すれば、ユーザは、検索指示に合致したデータを把握することができる。
【００７５】
以上のような処理を実施することによって、検索処理全体が高速化され、様々な検索指示に対応することができるようになる。
【００７６】
以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、図９に示したＤＢサーバ５の機能ブロック図は一例であって、必ずしもプログラムモジュール構成に対応しない。
【００７７】
また、処理フローについても処理結果が同一になる限りにおいて、並列に実行したり順番を入れ替えたりすることも可能である。例えば、ソート処理については、検索処理の早期の段階で実施しても良いし、ソート処理に時間がかかるので他の処理部などによって並列に実行させるようにしても良い。
【００７８】
また、上で述べたイベントフラグの設定方法に限定されるものではなく、他の態様にてイベントフラグを設定するようにしても良い。例えば、状態遷移の発生を適切に把握できるようにするだけであれば、２進数でビットをずらす必要はなく、異なる値にするだけでよい。また、状態遷移の数が多い場合には、８ビットを超えるイベントフラグを用いる場合もある。
【００７９】
また、上で述べた具体例では、グループ項目が指定されていたが、必ずしもグループ項目が指定されるわけではない。また、時系列にソートする例を示したが、ソート項目は必ずしも日時だけではなく、他の項目をソート項目に指定しても良い。また、商品名という項目だけを検索項目としているが、複数の検索項目を取り扱うことも可能である。さらに、同一イベント内において同一検索項目についてはＯＲ条件のみ取り扱えるが、異なる検索項目間についてはＡＮＤ条件なども取り扱える。ＡＮＤ条件を取り扱う場合には、イベントフラグを検索項目毎に別々に特定して、複数のイベントフラグの組み合わせで状態遷移を判断すればよい。例えば、商品名が「ＴＶ」で金額が「５００００円以上」というイベントが定義された場合には、商品名が「ＴＶ」というフラグＡと、金額が「５００００円以上」というフラグＢとの組み合わせが生じた場合に、当該イベントに係る検索条件を満たすと判断すればよい。例えばフラグＡとフラグＸとの組み合わせが特定されても、同様の状態遷移を行わなければよい。すなわち、状態遷移の定義を適切に行うことによってフレキシブルに対応できる。
【００８０】
なお、ユーザ端末３やＤＢサーバ５は、図２５のようなコンピュータ装置であって、メモリ２５０１（記憶装置）とＣＰＵ２５０３（処理装置）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施の形態における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本発明の実施の形態では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
【００８１】
（付記１）
各々特定の項目に対して特定の値が指定されており且つ順序付けがなされた複数の検索条件を含む検索指示に基づき、前記特定の項目の各項目値にフラグを付与し、フラグ定義データとして記憶装置に格納するフラグ付与ステップと、
データベースに格納されており且つ検索対象である複数のレコードを所定のルールに従ってソートするソート・ステップと、
ソート後の前記複数のレコードの順番に、前記記憶装置に格納された前記フラグ定義データを用いて、処理に係るレコードにおける前記特定の項目の項目値に対応するフラグを特定するフラグ特定ステップと、
ソート後の前記複数のレコードの順番に前記フラグを特定している過程において、特定された前記フラグの出現態様が、前記検索指示に従ったものであるか判断する判断ステップと、
前記フラグの出現態様が前記検索指示に従っていると判断された場合には、当該フラグの出現態様に含まれるフラグに係るレコードのデータを出力するステップと、
を含む、コンピュータにより実行される検索処理方法。
【００８２】
（付記２）
前記フラグ付与ステップが、
特定の検索条件に含まれる、前記特定の項目の前記特定の値に対応し且つ前記データベース内のレコードに含まれる前記特定の項目の項目値を特定するステップと、
特定された前記項目値に、前記特定の検索条件の順序付けに応じたフラグを付与するステップと、
を含む付記１記載の検索処理方法。
【００８３】
（付記３）
前記判断ステップが、
特定された前記フラグに応じて、前記順序付けに応じて定義される状態間の遷移が発生するか判断するステップと、
前記状態間の遷移が発生した場合には、最終状態まで到達したか判断するステップと、
を含む付記１記載の検索処理方法。
【００８４】
（付記４）
前記所定のルールが、前記検索指示で指定されたグループ項目毎且つ時系列という条件であり、
前記判断ステップにおいて、前記グループ項目における同一の項目値内において前記フラグの出現態様を判断する
付記１記載の検索処理方法。
【００８５】
（付記５）
前記データベースが、
各項目において、項目値を一意で特定する項目値番号と当該項目値との関係を保持するテーブルと、前記レコードの順番に前記項目値番号を指定する情報が格納されている項目値番号指定情報配列とを保持する
付記１記載の検索処理方法。
【００８６】
（付記６）
前記フラグが、該当する前記検索条件の前記順序付けに応じたビット位置に１がセットされたビット列である
付記１記載の検索処理方法。
【００８７】
（付記７）
前記フラグ特定ステップが、
前記データベースに格納されており且つ検索対象である前記複数のレコードに１回のみ実施される
付記１記載の検索処理方法。
【００８８】
（付記８）
付記１乃至７のいずれか１つ記載の検索処理方法をコンピュータに実行させるためのプログラム。
【００８９】
（付記９）
各々特定の項目に対して特定の値が指定されており且つ順序付けがなされた複数の検索条件を含む検索指示に基づき、前記特定の項目の各項目値にフラグを付与し、フラグ定義データとして記憶装置に格納する手段と、
データベースに格納されており且つ検索対象である複数のレコードを所定のルールに従ってソートする手段と、
ソート後の前記複数のレコードの順番に、前記記憶装置に格納された前記フラグ定義データを用いて、処理に係るレコードにおける前記特定の項目の項目値に対応するフラグを特定する手段と、
ソート後の前記複数のレコードの順番に前記フラグを特定している過程において、特定された前記フラグの出現態様が、前記検索指示に従ったものであるか判断する手段と、
前記フラグの出現態様が前記検索指示に従っていると判断された場合には、当該フラグの出現態様に含まれるフラグに係るレコードのデータを出力する手段と、
を有する検索処理装置。
【図面の簡単な説明】
【００９０】
【図１】売上履歴テーブルの一例を示す図である。
【図２】従来技術のデータ構造を示す図である。
【図３】ソート後の売上履歴テーブルの一例を示す図である。
【図４】ソート後のＳＥＴ配列の一例を示す図である。
【図５】従来技術の検索処理を説明するための図である。
【図６】１番目の条件にヒットしたレコード群を示す図である。
【図７】従来技術の検索処理を説明するための図である。
【図８】従来技術の検索処理を説明するための図である。
【図９】本発明の実施の形態に係るシステム概要図である。
【図１０】検索指示の入力画面例を示す図である。
【図１１】本発明の実施の形態に係るメインの処理フローを示す図である。
【図１２】イベント判定処理の処理フローを示す図である。
【図１３】イベント管理テーブルの一例を示す図である。
【図１４】本発明の実施の形態に係る検索処理の処理フローの第１の部分を示す図である。
【図１５】イベント履歴条件テーブルの初期状態を示す図である。
【図１６】イベント履歴条件テーブルの次の状態を示す図である。
【図１７】イベント履歴条件テーブルの次の次の状態を示す図である。
【図１８】イベントフラグテーブルの一例を示す図である。
【図１９】状態遷移図の一例を示す図である。
【図２０】本発明の実施の形態に係る検索処理の処理フローの第２の部分を示す図である。
【図２１】イベントフラグテーブルの利用方法を示す図である。
【図２２】抽出イベントテーブルの一例を示す図である。
【図２３】本発明の実施の形態に係るイベントフラグと状態遷移の具体例を示す図である。
【図２４】出力結果の一例を示す図である。
【図２５】コンピュータの機能ブロック図である。
【符号の説明】
【００９１】
１ ネットワーク
３ ユーザ端末
５ ＤＢサーバ
５１ 検索指示受信部
５２ 検索指示データ格納部
５３ イベント判定処理部
５４ イベント管理テーブル格納部
５５ 検索前処理部
５６ ＦＡＳＴ構造データ格納部
５７ イベント履歴条件テーブル格納部
５８ ソート結果格納部
５９ 検索処理部
６０ 検索結果格納部
６１ 検索結果出力部
５９１ 状態遷移管理部
【技術分野】
【０００１】
本発明は、データベースに対する検索処理技術に関する。
【背景技術】
【０００２】
例えば、日本特許第３５８１８３１号公報には、以下のような技術が開示されている。以下、図１に示すようなリレーショナルデータベース（ＲＤＢ）のデータが存在する場合について具体的に説明する。図１は、売上履歴テーブルの一部を示しており、顧客ＩＤ、日時、商品、金額、店舗コードという項目（属性）の各々について、各項目値を含む１９のレコードを含むものである。なお、ｒｏｗｉｄは、説明の都合示している行番号（レコード番号とも呼ぶ）である。
【０００３】
図１のようなデータを、上記特許では図２に示すようなデータとして保持する。すなわち、ＲＯＯＴ配列９００１と、顧客ＩＤという項目に関するＰＯＳ配列９００２及びｖａｌｕｅテーブル９００３と、日時という項目に関するＰＯＳ配列９００４及びｖａｌｕｅテーブル９００５と、商品名という項目に関するＰＯＳ配列９００６及びｖａｌｕｅテーブル９００７とが含まれる。ＲＯＯＴ配列９００１は、各ＰＯＳ配列において参照すべき行番号を保持する配列である。顧客ＩＤについては、ｖａｌｕｅテーブル９００３が顧客ＩＤの項目値（００１乃至００７）を一意に特定しており、ＰＯＳ配列９００２は、各行（すなわちposition）にＲＯＯＴ配列９００１において対応する行に格納されたレコード番号のレコードについて参照すべきｖａｌｕｅテーブル９００３における行へのポインタを保持している。例えばＰＯＳ配列９００２の１行目であれば、レコード１についてのデータであって、ＰＯＳ配列９００２の保持する「１」は、ｖａｌｕｅテーブル９００３の１行目を参照して、顧客ＩＤが「００１」であることが分かる。同様に、日時については、ｖａｌｕｅテーブル９００５が日時の項目値（３／１ １０：００乃至３／９ １９：００）を一意に特定しており、ＰＯＳ配列９００４は、各行（すなわちposition）にＲＯＯＴ配列９００１において対応する行に格納されたレコード番号のレコードについて参照すべきｖａｌｕｅテーブル９００５における行へのポインタを保持している。商品名についても、ｖａｌｕｅテーブル９００７が商品名の項目値（ＤＶＤ ＳＯＦＴ乃至冷蔵庫）を一意に特定しており、ＰＯＳ配列９００６は、各行（すなわちposition）にＲＯＯＴ配列９００１において対応する行に格納されたレコード番号のレコードについて参照すべきｖａｌｕｅテーブル９００７における行へのポインタを保持している。
【０００４】
すなわち、各項目において、項目値を一意で特定する項目値番号と当該項目値との関係を保持するｖａｌｕｅテーブルと、レコードの順番に項目値番号を指定する情報が格納されている項目値番号指定情報配列とを保持するようなデータ構造である。
【０００５】
このようなデータ構造を保持することによって、例えば顧客ＩＤが「００１」についてのレコードを抽出する場合には、ｖａｌｕｅテーブル９００３において「００１」が保持されている行の行番号（「１」）を特定し、当該行番号を保持するＰＯＳ配列９００２における行の行番号（１，２，１０，１４）が抽出すべきレコード番号となる。
【０００６】
ここで、図１に示した売上履歴テーブルにおいて、「ＨＤＤレコーダ」、「ＤＶＤプレーヤー」又は「ＴＶ（テレビ）」を購入した後、何らかの「ＳＯＦＴ」を購入し、さらに「ＤＶＤ−Ｒ」又は「ＣＤ−ＲＷ」を購入した顧客を抽出するような検索を行うことを考える。
【０００７】
上記公報には直接このような検索の仕方は開示されていないが、通常であれば以下のような手順を行う必要がある。まず、顧客ＩＤ毎且つ日時順にソートを行う。図１のようなＲＤＢでは、データ量が多い場合にはこのようなソートを行うこと自体が困難であるが、図２のようなデータ構造を利用する場合には、データ量が削減されているのでソートを行うことができる。分かりやすくするため、図３に図１の形でソートした結果を示し、図４にレコード番号のみを含むソート結果を示す。図４のソート結果は、ＳＥＴ配列９０１１として保持され、レコード１、レコード２，レコード１０、レコード１４、．．．といった順番にソートされている。このレコード番号をＳＥＴＩＤとも呼ぶ。
【０００８】
そして、第１段階として「ＨＤＤレコーダ」、「ＤＶＤプレーヤー」又は「ＴＶ」のいずれかに該当するレコードを抽出する。その場合には、図５に示すように、ＳＥＴ配列９０１１の上から順番に、商品名についてのＰＯＳ配列９００６を参照して該当する項目値番号を読み出し、テーブル９００７において当該項目値番号の位置の項目値を特定して、上記の第１の条件に合致するか判断する。ＳＥＴ配列９０１１における１番目のレコード番号は「１」であり、ＰＯＳ配列９００６における第１番目の項目値番号である「５」を特定して、テーブル９００７における５番目の項目値を読み出すと「ＴＶ」であり、上記の第１の条件に合致するため、レコード番号「１」が抽出される。例えば、ＳＥＴ配列９０１１における３番目のレコード番号は「１０」であり、ＰＯＳ配列９００６における１０番目の項目値番号である「１」を特定して、テーブル９００７における１番目の項目値を読み出すと「ＤＶＤ ＳＯＦＴ」であるから、上記の第１の条件を満たしておらず、レコード番号「１０」は抽出されない。このような処理を繰り返す。
【０００９】
そうすると、図６の配列９０２１のようなＳＥＴＩＤ列を得ることができる。これだけでは、具体的内容が分かりにくいので、抽出された具体的なレコードの内容をテーブル９０２２に示す。しかし、このデータだけでは第２の条件を満たしているかは不明であるので、再度ＳＥＴ配列９０１１のデータを参照しなければならない。
【００１０】
具体的には、図６の配列９０２１からレコード番号を得ると、図４のＳＥＴ配列９０１１において次の順番のレコード番号を特定する。例えばレコード番号「１」であれば、レコード番号「２」が特定される。そして、商品名についてのＰＯＳ配列９００６を参照して、特定されたレコード番号の位置における項目値番号を読み出し、テーブル９００７において項目値番号の位置の項目値を特定して、上記の第２の条件に合致するか判断する。レコード番号「２」が特定されれば、ＰＯＳ配列９００６の２番目の項目値番号である「４」を読み出し、項目値番号「４」の位置の項目値である「ＨＤＤレコーダ」を特定して、第２の条件である「ＳＯＦＴ」と比較する。この場合には、合致しないという判断が行われる。同様に、配列９０２１の２番目のレコード番号「２」であれば、ＳＥＴ配列９０１１において次のレコード番号は「１０」である。レコード番号「１０」に従ってＰＯＳ配列９００６の１０番目の項目値番号「１」を読み出し、テーブル９００７において項目値番号「１」の位置の項目値である「ＤＶＤ ＳＯＦＴ」を特定して、第２の条件である「ＳＯＦＴ」と比較する。この場合には、合致するという判断が行われる。
【００１１】
上で述べたような処理は図７にまとめられている。図７には、次のレコードについてのＳＥＴ配列９０３１と、対応するデータテーブル９０３２と、商品名という項目についてのＰＯＳ配列９００６及びｖａｌｕｅテーブル９００７とが示されている。次のレコードについてのＳＥＴ配列９０３１及びデータテーブル９０３２において、ハッチングが付された行については、第２の条件を満たしておらず、結果としてレコード番号１０、レコード番号９、レコード番号１７が抽出される。
【００１２】
なお、説明を省略したが、同一顧客が第１乃至第３の条件を順番に満たす必要があるので、一人の顧客について最低でも３レコード必要であって、次のレコードが存在しない場合には処理の対象外となる。例えば次のレコードについてのＳＥＴ配列９０３１の最下行には次のレコードが存在しない場合を示しており「−」が記録されている。
【００１３】
このように第１の条件を満たすレコード番号を格納した配列９０２１が抽出されても、次のレコードを抽出するために再度ＳＥＴ配列９０１１にアクセスする必要があり、次のレコードについてのＳＥＴ配列９０３１については、第２の条件に合致するか否かを再度確認する必要がある。
【００１４】
さらに、第３の条件を満たしているかを確認するために、再度ＳＥＴ配列９０１１のデータを参照しなければならない。
【００１５】
具体的には、図７に示した次のレコードについてのＳＥＴ配列９０３１においてハッチングが付されていないレコード番号「１０」、レコード番号「９」及びレコード番号「１７」のそれぞれについて、再度ＳＥＴ配列９０１１において次の順番のレコード番号を特定する。例えば、レコード番号「１０」の次のレコードのレコード番号は、図８において次の次のレコードについてのＳＥＴ配列９０４１に示すように、レコード番号「１４」であり、レコード番号「９」の次のレコードのレコード番号は、同様にレコード番号「１８」であり、レコード番号「１７」の次のレコードのレコード番号は、存在しない。
【００１６】
次に、商品名についてのＰＯＳ配列９００６を参照して、特定されたレコード番号の位置における項目値番号を読み出し、テーブル９００７において項目値番号の位置の項目値を特定して、上記の第３の条件に合致するか判断する。すなわち、ＰＯＳ配列９００６においてレコード番号「１４」の位置における項目値番号「２」を読み出し、ｖａｌｕｅテーブル９００７において項目値番号「２」の項目値「ＤＶＤ−Ｒ」を特定して、上記の第３の条件と比較して、合致すると判断する。また、ＰＯＳ配列９００６においてレコード番号「１８」の位置における項目値番号「２」を読み出し、ｖａｌｕｅテーブル９００７において項目値番号「２」の項目値「ＤＶＤ−Ｒ」を特定して、上記の第３の条件と比較して、合致すると判断する。
【００１７】
すなわち、顧客ＩＤ「１」についてレコード番号「２」、レコード番号「１０」及びレコード番号「１４」の系列と、顧客ＩＤ「４」についてレコード番号「６」、レコード番号「９」及びレコード番号「１８」の系列とが抽出されることになる。
【００１８】
このように第２の条件を満たすレコード番号を格納した配列（次のレコードのＳＥＴ配列９０３１の一部）が抽出されても、次のレコードを抽出するために再度ＳＥＴ配列９０１１にアクセスする必要があり、次の次のレコードについてのＳＥＴ配列９０４１については、第３の条件に合致するか否かを再度確認する必要がある。
【００１９】
このように少ないレコード数であればそれほどマッチング回数は増加しないが、１レコードについて何回もマッチングの是非について判断する必要があり、レコード数が膨大になればマッチング回数も膨大となるという問題がある。
【００２０】
なお、特開２０００−２０５２７号公報には、データベースシステムで、条件検索の検索結果を再利用するための行位置情報の格納方法を、検索のヒット率により切りわけることで領域を最小化し、検索を高速に行うための技術が開示されている。具体的には、検索処理時、データベース管理プログラムが処理中の検索と一致する検索条件を検索結果管理テーブルに発見した場合、対応する検索結果位置情報を参照することで、一致した検索条件についてのデータベースの検索を不要とするものである。しかしながら、上記のような問題を解決することはできない。
【００２１】
また、特開２００５−２５１００２号公報には、基になるデータベースの構造は従来どおりとし、検索結果ファイルが一旦生成された後も絞り込み検索などのための再検索を可能とするための技術が開示されている。具体的には、所定の検索条件に該当するデータをデータベースから抽出し、その抽出データのデータベース上の格納場所を示すロケータを含む検索結果ファイルを生成する。再検索の際にはロケータによりデータベースを参照して再検索用データを取得し、再検索条件に該当するデータを抽出し、新たな検索結果ファイルとして生成する。この公報でも上記のような問題を解決することはできない。
【特許文献１】日本特許第３５８１８３１号公報
【特許文献２】特開２０００−２０５２７号公報
【特許文献３】特開２００５−２５１００２号公報
【発明の開示】
【発明が解決しようとする課題】
【００２２】
このように従来技術では、購買履歴等を抽出する際などに生ずる、順序付けされた複数の検索条件に合致するレコード系列を抽出する処理において、膨大な数に上るレコードについてのマッチング回数を減らして、処理を高速化することはできない。
【００２３】
従って、本発明の目的は、順序付けされた複数の検索条件に合致するレコード系列を抽出する際にレコードに対するマッチング回数を削減するための技術を提供することである。
【課題を解決するための手段】
【００２４】
本発明に係る検索処理方法は、各々特定の項目に対して特定の値が指定されており且つ順序付けがなされた複数の検索条件を含む検索指示に基づき、特定の項目の各項目値にフラグを付与し、フラグ定義データとして記憶装置に格納するフラグ付与ステップと、データベースに格納されており且つ検索対象である複数のレコードを所定のルール（例えば時系列）に従ってソートするソート・ステップと、ソート後の複数のレコードの順番に、記憶装置に格納されたフラグ定義データを用いて、処理に係るレコードにおける特定の項目の項目値に対応するフラグを特定するフラグ特定ステップと、ソート後の複数のレコードの順番にフラグを特定している過程において、特定されたフラグの出現態様（例えばフラグの出現順番や検出の連続性など）が、検索指示に従ったものであるか判断する判断ステップと、フラグの出現態様が検索指示に従っていると判断された場合には、当該フラグの出現態様に含まれるフラグに係るレコードのデータを出力するステップとを含む。
【００２５】
このような処理を実施すれば、従来ではデータベースのレコードと検索条件とがマッチングするか否かを何度も判断するような処理が、データベースのレコード群を検索指示に基づくフラグ系列に変換してフラグの出現態様が検索指示に従ったものであるかを確認する処理に変換され、マッチング処理の回数が削減され処理が効率化される。
【００２６】
また、上で述べたフラグ付与ステップが、特定の検索条件に含まれる、特定の項目の特定の値に対応し且つデータベース内のレコードに含まれる特定の項目の項目値を特定するステップと、特定された項目値に、特定の検索条件の順序付けに応じたフラグを付与するステップとを含むようにしてもよい。従来では、検索条件に含まれる項目値とレコードの項目値とを一致しているか否か、部分一致か否かなどを同じレコードについても何度も判断する必要があるが、最初のステップを実施すれば、項目値間の比較の処理の実施回数が最大でも検索条件に含まれる項目値の種類数×データベース内の項目値の種類数に限定され、簡略化される。また、次のステップを実施すれば、フラグが順序付けを表すようになるため、フラグの出現態様を判断しやすくなる。
【００２７】
さらに、上で述べた判断ステップが、特定されたフラグに応じて、順序付けに応じて定義される状態間の遷移が発生するか判断するステップと、状態間の遷移が発生した場合には、最終状態まで到達したか判断するステップとを含むようにしてもよい。このように状態遷移を管理することによって、フラグの出現態様が検索指示に従っているかを正確且つ簡易に判断できるようになる。また、状態間の遷移の条件を適切に定義することによって、多様な検索指示に対処できるようになる。
【００２８】
なお、所定のルールを、検索指示で指定されたグループ項目毎且つ時系列という条件としてもよい。この場合、上記判断ステップにおいて、グループ項目における同一の項目値内においてフラグの出現態様を判断するようにしてもよい。顧客の購買履歴の検索などは、このような処理を行えばよい。
【００２９】
さらに、上記データベースが、各項目において、項目値を一意で特定する項目値番号と当該項目値との関係を保持するテーブルと、レコードの順番に項目値番号を指定する情報が格納されている項目値番号指定情報配列とを保持するようにしてもよい。このようなデータ構造を用いることによって、ソート処理が簡易且つ高速に実施できる。
【００３０】
また、上記フラグが、該当する検索条件の前記順序付けに応じたビット位置に１がセットされたビット列であるようにしてもよい。より高速にフラグの出現態様を判断できるようになる。
【００３１】
なお、上で述べたフラグ特定ステップを、データベースに格納されており且つ検索対象である複数のレコードに１回のみ実施すれば、マッチング処理の回数が削減できる。
【００３２】
本発明にかかる方法をコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してディジタル信号にて頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。
【発明の効果】
【００３３】
本発明によれば、順序付けされた複数の検索条件に合致するレコード系列を抽出する際にレコードに対するマッチング回数を削減することができるようになる。
【発明を実施するための最良の形態】
【００３４】
図９に本発明の一実施の形態に係るシステム概要図を示す。例えばＬＡＮ（Local Area Network）などのネットワーク１には、１又は複数のユーザ端末３と、データベース（ＤＢ）を管理するＤＢサーバ５とが接続されている。ここでは、ＤＢサーバ５は、１台のコンピュータで実施する場合を示すが、複数台のコンピュータによって実施するようにしても良い。また、ＤＢサーバ５は、１種類だけではなく複数種類のデータベースを管理する場合もある。
【００３５】
本実施の形態では、レコードのソートを行うことを前提とするので、通常のＲＤＢでは処理速度及び記憶容量の面で実際的ではなく、図２に示したようなデータ構造（以下、ＦＡＳＴ構造と呼ぶ）でデータを管理しているものとする。ＦＡＳＴ構造で管理されたデータは、ＦＡＳＴ構造データ格納部５６に格納されているものとする。
【００３６】
ＤＢサーバ５は、ネットワーク１を介してユーザ端末３からの検索指示を受信する検索指示受信部５１と、検索指示受信部５１が受信した検索指示に係るデータを格納する検索指示データ格納部５２と、検索指示データ格納部５２に格納されているデータを用いてイベント判定処理を行うイベント判定処理部５３と、イベント判定処理部５３の処理結果を格納するイベント管理テーブル格納部５４と、検索指示データ格納部５２とイベント管理テーブル格納部５４とＦＡＳＴ構造データ格納部５６とに格納されたデータを用いて処理を行う検索前処理部５５と、検索前処理部５５による処理結果であるイベント履歴条件テーブルを格納するイベント履歴条件テーブル格納部５７と、検索前処理部５５の処理結果であるソート結果のデータを格納するソート結果格納部５８と、ＦＡＳＴ構造データ格納部５６とソート結果格納部５８とイベント履歴条件テーブル格納部５７とに格納されているデータを用いて検索前処理部５５の指示に従って検索処理を行い該当データを抽出する検索処理部５９と、検索処理部５９による処理結果を格納する検索結果格納部６０と、検索結果格納部６０に格納されたデータを要求元のユーザ端末３に出力する検索結果出力部６１とを含む。なお、検索処理部５９は、検索前処理部５５による設定に基づき状態遷移の管理を行う状態遷移管理部５９１を含む。
【００３７】
次に、図９に示したシステムの動作を図１０乃至図２４を用いて説明する。なお、従来技術で説明した具体例をそのまま用いて説明する。すなわち、図２に示したようなデータ構造がＦＡＳＴ構造データ格納部５６に格納されており、「ＨＤＤレコーダ」、「ＤＶＤプレーヤー」又は「ＴＶ（テレビ）」を購入した後、何らかの「ＳＯＦＴ」を購入し、さらに「ＤＶＤ−Ｒ」又は「ＣＤ−ＲＷ」を購入した顧客を抽出するような検索を行うことを考える。なお、ＦＡＳＴ構造に係るデータは、図１に示した売上履歴テーブルと同様の内容を保持している。
【００３８】
まず、ユーザ端末３のユーザは、ユーザ端末３を操作して、ＤＢサーバ５にアクセスし、検索指示の入力画面を表示装置に表示させる。例えば、図１０に示すような画面が表示装置に表示される。図１０の画面例では、検索対象のテーブル名、種別並びに開始ＳＥＴＩＤ及びレコード数の表示／指定欄３０１と、ソートの際にグループ化する項目であるグループ項目、ソートする項目であるソート項目及び検索条件であるイベントを指定するための抽出条件指定欄３０２と、抽出条件指定欄３０２において複数のイベントが指定された場合に当該イベント間の順序関係を指定するためのイベント順序条件指定欄３０３と、検索条件に合致したレコードについて抽出すべき項目を指定するための抽出項目指定欄３０４とを含む。なお、上で述べた条件のとおり、抽出条件であるイベント１では、商品名が「テレビ」「ＨＤＤレコーダ」又は「ＤＶＤプレーヤー」であることが条件として指定されている。同様に、イベント２では、商品名が「ＳＯＦＴ」に類似することが条件として指定されており、イベント３では、商品名が「ＤＶＤ−Ｒ」又は「ＣＤ−ＲＷ」であることが条件として指定されている。イベント順序については、昇順、降順、全組合せ（全順列）、任意指定などを行うことができるようになっており、上で述べた条件では、昇順が選択される。なお、任意指定では、様々な順序条件を指定することができ、Ｅ１，（Ｅ２，Ｅ３）は、Ｅ１，Ｅ２，Ｅ３と、Ｅ１，Ｅ３，Ｅ２という順序条件を指定したことになる。
【００３９】
ユーザは、図１０のような画面において必要な条件を指定して、ＯＫボタン３０５をクリックすると、ユーザ端末３は当該指示を受け付け、検索指示としてＤＢサーバ５に送信する。検索指示には、検索対象のデータ、抽出条件（グループ項目、ソート項目、イベント群）、抽出順序条件及び抽出項目を含む。なお、図１０では指定できないが、他の条件を付加するようにしても良い。
【００４０】
ＤＢサーバ５の検索指示受信部５１は、ユーザ端末３から検索指示を受信し、当該検索指示に係るデータを検索指示データ格納部５２に格納する（図１１：ステップＳ１）。そうすると、イベント判定処理部５３は、検索指示データ格納部５２に格納された検索指示に係るデータを用いてイベント判定処理を実施する（ステップＳ３）。このイベント判定処理については、図１２及び図１３を用いて説明する。まず、イベント判定処理部５３は、検索指示データ格納部５２に格納されているイベントのうち未処理のイベントを特定し（ステップＳ１１）、項目名と項目値のセットを当該未処理のイベントから抽出し、イベント管理テーブルに登録する（ステップＳ１３）。イベント管理テーブル格納部５４に格納されるイベント管理テーブルの一例を図１３に示す。図１３の例では、イベントと、項目名と、項目値とが登録されるようになっている。なお、同一イベントでも、項目名及び項目値の複数の組み合わせが指定される場合もあり、その場合には同一イベントに複数行のデータが登録される。上で述べた具体的な条件の場合には、図１３に示したようなデータがイベント管理テーブルに登録される。
【００４１】
そして、イベント判定処理部５３は、全てのイベントを処理したか判断し（ステップＳ１５）、未処理のイベントが存在する場合にはステップＳ１１に戻る。一方、全てのイベントについて処理した場合には元の処理に戻る。
【００４２】
図１１の説明に戻って、次に検索処理を実施する（ステップＳ５）。検索処理については、図１４乃至図２３を用いて説明する。
【００４３】
まず、検索前処理部５５は、イベント管理テーブル格納部５４に格納されているイベント管理テーブルから各イベントに使用される項目名を特定し、当該項目名毎に、全項目値をＦＡＳＴ構造データ格納部５６から取得し、項目名毎にイベント履歴条件テーブルを構成する（図１４：ステップＳ２１）。具体的には、図１５にイベント履歴条件テーブルの一例を示す。上で述べた条件では、項目は「商品名」であるから、図２のｖａｌｕｅテーブル９００７を取得する。図１５に示したイベント履歴条件テーブルでは、このｖａｌｕｅテーブル９００７に含まれる項目値を各行としており、状態遷移を表すための状態Ｓ１乃至Ｓ８の列と、イベントフラグ（ＦＬＧ）の列とが設けられている。なお、イベント履歴条件テーブルは、イベント管理テーブルに格納されているイベントと状態とを対応付けることができるような構成にもなっている。
【００４４】
次に、検索前処理部５５は、イベント管理テーブル格納部５４内のイベント管理テーブル及び検索指示データ格納部５２を参照して、各状態についてイベントを対応付けると共に該当する項目値にフラグをセットし、各項目値についてのイベントフラグを生成する（ステップＳ２３）。
【００４５】
検索指示データ格納部５２には、処理に係る検索指示におけるイベントの順序条件が格納されている。この順序条件に従って、イベントと状態との対応付けを行う。上で述べた条件においては、イベント１（Ｅ１）、イベント２（Ｅ２）、イベント３（Ｅ３）の順番で検索を行うので、状態Ｓ１とイベント１、状態Ｓ２とイベント２、状態Ｓ３とイベント３とが対応付けられ、イベント履歴条件テーブルに登録される。ここまで処理すると、イベント履歴条件テーブルは図１６に示すような状態となる。なお、状態Ｓ４乃至Ｓ８は今回はイベントとの対応付けはないので、ハッチングが付されて、各状態におけるフラグは「０」にセットされている。
【００４６】
さらに、各状態について該当する項目値にフラグをセットする。上で述べた条件においては、イベント１（Ｅ１）では、「ＤＶＤプレーヤー」、「ＨＤＤレコーダ」又は「ＴＶ」が指定されているので、該当する項目値として「ＤＶＤプレーヤー」、「ＨＤＤレコーダ」及び「ＴＶ」を特定する。さらに、それぞれの行においてイベント１に対応する状態Ｓ１の列に「１」をセットし、それ以外については「０」をセットする。
【００４７】
なお、検索条件において指定されている項目値と、実際にデータベースに登録されている項目値とは完全一致しない場合もある。本実施の形態では、レコード毎に項目値間の一致／不一致を判断するのではなく、この段階においてｖａｌｕｅテーブル９００７に登録されている項目値と検索条件において指定されている項目値との一致／不一致を判断するので、後の処理が簡略化される。
【００４８】
同様に、イベント２（Ｅ２）では、「ＳＯＦＴ」が指定されているので、該当する項目値として「ＤＶＤ ＳＯＦＴ」が特定される。このように、完全一致が存在しない場合にはレコード毎に比較する従来技術に比して、後の処理は効率化される。そして、「ＤＶＤ ＳＯＦＴ」の行においてイベント２に対応する状態Ｓ２の列に「１」をセットし、それ以外については「０」をセットする。
【００４９】
イベント３（Ｅ３）では、「ＤＶＤ−Ｒ」又は「ＣＤ−ＲＷ」が指定されているので、該当する項目値として「ＤＶＤ−Ｒ」のみが特定される。このように、完全に不一致の項目値を含む検索条件が指定されている場合には、レコード毎の比較は非常に非効率であることが分かる。そして、「ＤＶＤ−Ｒ」の行においてイベント３に対応する状態Ｓ３の列に「１」をセットし、それ以外については「０」をセットする。
【００５０】
そして、状態Ｓ１乃至Ｓ８までにセットされたフラグのビットを２進数のビット列として取り扱う。なお、イベントの順序が早いほど下位ビットに「１」がセットされ、遅いほど上位ビットに「１」がセットされる。このように、イベントの順番に応じたイベントフラグが設定される。同じ順番であれば異なる項目値であっても同じイベントフラグが設定される。図１７では、このビット列を、１０進数の値に直した値をイベントフラグ（ＦＬＧ）の列に示している。但し、２進数のままでもよい。
【００５１】
ここまででイベント履歴条件テーブルが完成するので、このイベント履歴条件テーブルのデータをイベント履歴条件テーブル格納部５７に格納する。なお、後に説明するが、ｖａｌｕｅテーブル９００７の代わりとなるテーブルが必要となるので、図１８のようなテーブル５０１を生成して、イベント履歴条件テーブル格納部５７に格納しておく。
【００５２】
その後、検索前処理部５５は、ＦＡＳＴ構造データ格納部５６を参照して、ＦＡＳＴ構造の検索対象データを、検索指示データ格納部５２に格納されているグループ項目及びソート項目に応じてソートを実施し、ソート結果をソート結果格納部５８に格納する（ステップＳ２５）。この処理自体は従来技術と同様である。ソート結果格納部５８に格納されるデータは、図４に示したようなデータである。
【００５３】
また、検索前処理部５５は、状態遷移の条件を検索指示に従って、状態遷移管理部５９１に設定する（ステップＳ２７）。以下で詳細に説明するが、状態遷移の条件は、様々に設定できる。例えば、上の例では、イベント１の次にイベント１が発生した場合の取扱いや、イベント１の次にイベント１乃至３のいずれでもないイベントが発生した後にイベント２が発生した場合の取扱いなど、検索者の意図に沿って状態遷移の条件を設定すべき場合もある。ここでは、検索指示に、イベント１の次にイベント１乃至３のいずれでもないイベントが発生した後にイベント２が発生した場合等の取扱いについて指示があれば、状態遷移管理部５９１に設定する。ステップＳ２７は、デフォルトの設定に従う場合にはスキップされる場合もある。なお、イベント数によって状態数が確定するので、当該状態数の設定は必ず行われる。処理は端子Ａを介して図２０の処理に移行する。
【００５４】
状態遷移管理部５９１により管理される状態及び状態遷移を図１９を用いて説明する。必要な状態は、イベント１乃至３に対応する状態Ｓ１乃至Ｓ３と、初期状態Ｓ０である。なお、状態Ｓ３は、最終状態として特定される。イベント数が増加すれば、その分状態は増加し、イベント数が減少すれば、その分状態は減少する。また、状態遷移は、イベント１の検索条件が満たされた場合に発生する初期状態Ｓ０から状態Ｓ１への状態遷移Ａと、イベント２の検索条件が満たされた場合に発生する状態Ｓ１から状態Ｓ２への状態遷移Ｂと、イベント３の検索条件が満たされた場合に発生する状態Ｓ２から状態Ｓ３への状態遷移Ｄと、最終状態である状態Ｓ３への到達が確認された場合に発生する状態Ｓ３から初期状態Ｓ０への状態遷移Ｆと、初期状態Ｓ０においてイベント１の検索条件が満たされない場合に発生する初期状態Ｓ０から初期状態Ｓ０への状態遷移Ｇと、状態Ｓ１においてイベント１の検索条件が再度満たされた場合に発生する状態Ｓ１から状態Ｓ１への状態遷移Ｃと、状態Ｓ２においてイベント２の検索条件が再度満たされた場合に発生する状態Ｓ２から状態Ｓ２への状態遷移Ｅと、状態Ｓ１においてイベント１又は２の条件が満たされなかった場合に発生する状態Ｓ１から状態Ｓ０への状態遷移Ｈと、状態Ｓ２においてイベント２又は３の条件が満たされなかった場合に発生する状態Ｓ２から状態Ｓ０への状態遷移Ｉとを含む。このように、初期状態から途中の状態を介して最終状態へ至る状態遷移と、最終状態以外の状態においてその状態への遷移が発生した場合に生ずる自己遷移と、最終状態に到達したことが確認された場合に生ずる最終状態から初期状態への状態遷移と、次の状態への状態遷移又は自己遷移とのいずれもが発生しなかった場合における初期状態への状態遷移とが含まれる。
【００５５】
なお、自己遷移及び初期状態への状態遷移の条件を検索指示に応じて設定することで、フレキシブルな抽出を行うことができる。例えば、それより後の状態への遷移を発生させる条件が満たされされない限り自己遷移するように設定してもよい。例えば、「ＨＤＤレコーダ」、「ＤＶＤ−ＳＯＦＴ」、「ＤＶＤ−Ｒ」の順番で購入すれば、上で述べた条件を満たすことになるが、「ＨＤＤレコーダ」、「冷蔵庫」、「ＤＶＤ−ＳＯＦＴ」、「ＤＶＤ−Ｒ」の順番で購入すると、上で述べた条件を満たしたことにはならない。但し、「冷蔵庫」のレコードが検出されても初期状態へ遷移することなく自己遷移するようにすれば、後者のような購買履歴でも条件を満たすと判断される。すなわち、大きく購買履歴を捉えて、概ね目的とする購買履歴を行っている顧客を抽出できるようになる。
【００５６】
次に、検索処理部５９は、ソート結果格納部５８に格納されているレコード（図４）から未処理レコードを特定する（図２０：ステップＳ２９）。そして、特定された未処理レコードのグループ項目の項目値を特定する（ステップＳ３１）。特定された未処理レコードのレコード番号（ＳＥＴＩＤ）を用いて、ＦＡＳＴ構造データ格納部５６に格納されている、顧客ＩＤについてのＰＯＳ配列９００２から対応する位置の項目値番号を読み出し、当該項目値番号に基づきｖａｌｕｅテーブル９００３から項目値を取得する。
【００５７】
そして、検索処理部５９は、ステップＳ３１で特定された未処理レコードのグループ項目の項目値が変化したか判断する（ステップＳ３３）。従前に処理したレコードのグループ項目の項目値を保持しておき、変化したか判断する。これは、検索条件を満たしているかは、グループ項目が同一の項目値である間のレコードについて判断すべきであるからである。なお、従前に処理したレコードが存在しない場合には、変化したと判断される。
【００５８】
もし変化したと判断された場合には、状態遷移管理部５９１に初期状態Ｓ０に遷移させる（ステップＳ３５）。ステップＳ３５の後又はグループ項目の項目値が変化していないと判断された場合には、特定された未処理レコードのイベントフラグを特定する（ステップＳ３７）。この処理については、図２１を用いて説明する。
【００５９】
まず、ソート結果格納部５８に格納されたＳＥＴ配列９０１１から未処理レコードを特定すると、その未処理レコードのレコード番号を特定し、ＦＡＳＴ構造データ格納部５６に格納されている、商品名についてのＰＯＳ配列９００６において、レコード番号の位置の項目値番号を特定し、従前のｖａｌｕｅテーブル９００７の代わりに、イベントフラグテーブル５０１における項目値番号の位置のイベントフラグを特定する。ＳＥＴＩＤが「１」であれば、ＰＯＳ配列９００６において項目値番号が「５」と特定されるが、ｖａｌｕｅテーブル９００７から「ＴＶ」を特定するのではなく、イベントフラグテーブル５０１からイベントフラグ「１」（２進数で「０００００００１」）を特定する。
【００６０】
図２０の説明に戻って、状態遷移管理部５９１は、特定されたイベントフラグに応じた状態遷移を実施する（ステップＳ４１）。なお、状態遷移に係るレコードのレコード番号（ＳＥＴＩＤ）を保持しておく。保持しておくレコード番号は、初期状態から最終状態への直接の経路上の状態遷移に係るレコードのレコード番号だけでもよい。図１９の例では、状態遷移Ａ、状態遷移Ｂ及び状態遷移Ｄを生じさせたレコードのレコード番号である。このように特定の状態遷移の発生の有無を判断する場合もある。
【００６１】
どのような状態遷移が発生するかは、現在の状態が何であるか、特定されたイベントフラグが何であるかに依存する。図１９に示したような状態及び状態遷移の場合、初期状態Ｓ０から状態Ｓ１への状態遷移Ａは、初期状態Ｓ０において、イベントフラグ（２進ビット列）の最下位ビット（第８ビット）が「１」となっているイベントフラグが特定された場合に生ずる。状態Ｓ１から状態Ｓ２への状態遷移Ｂは、状態Ｓ１において、イベントフラグの第７ビットが「１」となっているイベントフラグが特定された場合に生ずる。状態Ｓ２から状態Ｓ３への状態遷移Ｄは、状態Ｓ２において、イベントフラグの第６ビットが「１」となっているイベントフラグが特定された場合に生ずる。状態Ｓ１における自己遷移である状態遷移Ｃは、イベントフラグの最下位ビットが「１」となっているイベントフラグが特定された場合に生ずる。状態Ｓ２における自己遷移である状態遷移Ｅは、イベントフラグの第７ビットが「１」となっているイベントフラグが特定された場合に生ずる。状態Ｓ３から状態Ｓ０への状態遷移Ｆは、以下で説明する処理において管理されるが、それ以外の状態遷移Ｇ、Ｈ及びＩについては、上で述べた以外のイベントフラグが特定された場合に生ずる。なお、上で述べたように、自己遷移については、別の定義で行うようにしても良い。
【００６２】
このように、現在の状態及びイベントフラグの所定のビットを検査するだけで状態遷移が発生するか否かを判断することができる。
【００６３】
図２０の説明に戻って、状態遷移管理部５９１は、最終状態に到達したか判断する（ステップＳ４３）。図１９の例では、最終状態Ｓ３に達したかを判断する。最終状態には到達していないと判断された場合にはステップＳ４９に移行する。一方、最終状態に到達したと判断された場合には、今回の状態遷移に対応するレコード番号を検索結果格納部６０内の抽出イベントテーブルに登録する（ステップＳ４５）。抽出イベントテーブルは、例えば図２２に示すようなテーブルである。すなわち、抽出番号（Ｎｏ．）と、状態Ｓ１への状態遷移を発生させたレコード番号（ＳＥＴＩＤ）、状態Ｓ２への状態遷移を発生させたレコード番号、状態Ｓ３への状態遷移を発生させたレコード番号が登録されるようになっている。状態遷移管理部５９１は、その後、初期状態Ｓ０への状態遷移を実施させる（ステップＳ４７）。
【００６４】
ステップＳ４７の後又はステップＳ４３で最終状態に到達していないと判断された場合、検索対象レコードの最終レコードを処理したか判断する（ステップＳ４９）。未処理のレコードが存在する場合にはステップＳ２９に戻る。一方、最終レコードを処理した場合には、元の処理に戻る。
【００６５】
図４のようなソート結果を得た場合におけるステップＳ２９乃至Ｓ４９の処理の経過を図２３にまとめて示す。１番目のレコードのイベントフラグは「１」であり、最下位（第８）ビットが「１」となっているので、初期状態Ｓ０から状態Ｓ１への状態遷移を発生させる。２番目のレコードのイベントフラグは「１」であり、第８ビットが「１」となっているので、自己遷移で状態Ｓ１への状態遷移を発生させる。３番目のレコードのイベントフラグは「２」であり、第７ビットが「１」となっているので、状態Ｓ２への状態遷移を発生させる。４番目のレコードのイベントフラグは「４」であり、第６ビットが「１」となっているので、状態Ｓ３への状態遷移を発生させる。すなわち、最終状態に到達したので、図４のＳＥＴ配列９０１１において１番目、３番目及び４番目のレコード番号が出力される。なお、２番目のレコードは自己遷移を発生させているので、２番目、３番目、４番目のレコード番号を出力するようにしても良い。そして、初期状態Ｓ０に遷移する。
【００６６】
なお、５番目のレコードを処理する際には、グループ項目である顧客ＩＤが変化するので、初期状態Ｓ０に強制的に遷移させる。また、５番目のレコードのイベントフラグは「０」であり、初期状態Ｓ０への自己遷移が発生する。６番目のレコードのイベントフラグは「０」であり、初期状態Ｓ０への自己遷移が発生する。７番目のレコードのイベントフラグは「１」であり、初期状態Ｓ０から状態Ｓ１への状態遷移を発生させる。８番目のレコードのイベントフラグは「０」であり、初期状態Ｓ０への状態遷移を発生させる。
【００６７】
なお、９番目のレコードを処理する際には、グループ項目である顧客ＩＤが変化するので、初期状態Ｓ０に強制的に遷移させる。また、９番目のレコードのイベントフラグは「１」であり、初期状態Ｓ０から状態Ｓ１への状態遷移を発生させる。１０番目のレコードのイベントフラグは「１」であり、状態Ｓ１への自己遷移が発生する。１１番目のレコードのイベントフラグは「４」であり、状態Ｓ１から初期状態Ｓ０への遷移が発生する。
【００６８】
なお、１２番目のレコードを処理する際には、グループ項目である顧客ＩＤが発生するので、初期状態Ｓ０に強制的に遷移させる。また、１２番目のレコードのイベントフラグは「１」であり、初期状態Ｓ０から状態Ｓ１への状態遷移を発生させる。１３番目のレコードのイベントフラグは「２」であり、状態Ｓ１から状態Ｓ２への状態遷移を発生させる。１４番目のレコードのイベントフラグは「４」であり、状態Ｓ２から状態Ｓ３への状態遷移を発生させる。すなわち、最終状態に到達したので、図４のＳＥＴ配列９０１１において１２番目、１３番目及び１４番目のレコードが出力される。そして、初期状態Ｓ０に遷移する。
【００６９】
なお、１５番目のレコードを処理する際には、グループ項目である顧客ＩＤが変化するので、初期状態Ｓ０に強制的に遷移させる。また、１５番目のレコードのイベントフラグは「１」であり、初期状態Ｓ０から状態Ｓ１への状態遷移を発生させる。１６番目のレコードのイベントフラグは「０」であり、初期状態Ｓ０に遷移させる。
【００７０】
なお、１７番目のレコードを処理する際には、グループ項目である顧客ＩＤが変化するので、初期状態Ｓ０に強制的に遷移させる。また、１７番目のレコードのイベントフラグは「１」であり、初期状態Ｓ０から状態Ｓ１への状態遷移を発生させる。１８番目のレコードは「２」であり、状態Ｓ１から状態Ｓ２への状態遷移を発生させる。
【００７１】
なお、１９番目のレコードを処理する際には、グループ項目である顧客ＩＤが変化するので、初期状態Ｓ０に強制的に遷移させる。また、１９番目のレコードのイベントフラグは「１」であり、初期状態Ｓ０から状態Ｓ１への状態遷移を発生させる。但し、これが最終レコードであるから、処理は元の処理に戻る。
【００７２】
このように、項目値同士の比較はイベントフラグ設定時にのみ行って、各レコードについての処理についてはイベントフラグを特定し、イベントフラグに応じて発生する状態遷移が定義通り発生するか判断するだけになっている。イベントフラグのチェック処理についても、上で述べたようなイベントフラグを使用する場合には所定のビット位置に「１」が設定されているかを確認するだけであるから、非常に処理が簡単化されている。また、レコードに対する処理は１レコードにつき１回に限定されており、膨大な数のレコードを処理する場合にも、処理負荷を下げることができる。
【００７３】
図１１の説明に戻って、検索処理部５９は、検索結果格納部６０内の抽出イベントテーブルを基に、検索指示データ格納部５２に格納されている抽出項目の項目値を、ＦＡＳＴ構造データ格納部５６から抽出し、検索結果格納部６０に格納する（ステップＳ７）。この処理は、図２で説明したように、レコード番号から、抽出すべき項目のＰＯＳ配列内の対応する位置の項目値番号を取得し、当該項目値番号に対応する項目値をｖａｌｕｅテーブルから読み出す処理である。顧客ＩＤ、日時、商品名、金額、店舗コードを抽出する場合には、図２４のようなデータが、検索結果格納部６０に格納される。図２３の例では２回登録がなされているので、それぞれについて３つのレコードが２セット抽出され、格納されている。
【００７４】
そして、検索結果出力部６１は、検索結果格納部６０に格納されている検索結果を読み出して要求元のユーザ端末３に出力する（ステップＳ９）。ユーザ端末３は、ＤＢサーバ５から検索結果のデータを受信し、表示装置に表示する。例えば図２４に示したようなデータを表示装置に表示すれば、ユーザは、検索指示に合致したデータを把握することができる。
【００７５】
以上のような処理を実施することによって、検索処理全体が高速化され、様々な検索指示に対応することができるようになる。
【００７６】
以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、図９に示したＤＢサーバ５の機能ブロック図は一例であって、必ずしもプログラムモジュール構成に対応しない。
【００７７】
また、処理フローについても処理結果が同一になる限りにおいて、並列に実行したり順番を入れ替えたりすることも可能である。例えば、ソート処理については、検索処理の早期の段階で実施しても良いし、ソート処理に時間がかかるので他の処理部などによって並列に実行させるようにしても良い。
【００７８】
また、上で述べたイベントフラグの設定方法に限定されるものではなく、他の態様にてイベントフラグを設定するようにしても良い。例えば、状態遷移の発生を適切に把握できるようにするだけであれば、２進数でビットをずらす必要はなく、異なる値にするだけでよい。また、状態遷移の数が多い場合には、８ビットを超えるイベントフラグを用いる場合もある。
【００７９】
また、上で述べた具体例では、グループ項目が指定されていたが、必ずしもグループ項目が指定されるわけではない。また、時系列にソートする例を示したが、ソート項目は必ずしも日時だけではなく、他の項目をソート項目に指定しても良い。また、商品名という項目だけを検索項目としているが、複数の検索項目を取り扱うことも可能である。さらに、同一イベント内において同一検索項目についてはＯＲ条件のみ取り扱えるが、異なる検索項目間についてはＡＮＤ条件なども取り扱える。ＡＮＤ条件を取り扱う場合には、イベントフラグを検索項目毎に別々に特定して、複数のイベントフラグの組み合わせで状態遷移を判断すればよい。例えば、商品名が「ＴＶ」で金額が「５００００円以上」というイベントが定義された場合には、商品名が「ＴＶ」というフラグＡと、金額が「５００００円以上」というフラグＢとの組み合わせが生じた場合に、当該イベントに係る検索条件を満たすと判断すればよい。例えばフラグＡとフラグＸとの組み合わせが特定されても、同様の状態遷移を行わなければよい。すなわち、状態遷移の定義を適切に行うことによってフレキシブルに対応できる。
【００８０】
なお、ユーザ端末３やＤＢサーバ５は、図２５のようなコンピュータ装置であって、メモリ２５０１（記憶装置）とＣＰＵ２５０３（処理装置）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施の形態における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本発明の実施の形態では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
【００８１】
（付記１）
各々特定の項目に対して特定の値が指定されており且つ順序付けがなされた複数の検索条件を含む検索指示に基づき、前記特定の項目の各項目値にフラグを付与し、フラグ定義データとして記憶装置に格納するフラグ付与ステップと、
データベースに格納されており且つ検索対象である複数のレコードを所定のルールに従ってソートするソート・ステップと、
ソート後の前記複数のレコードの順番に、前記記憶装置に格納された前記フラグ定義データを用いて、処理に係るレコードにおける前記特定の項目の項目値に対応するフラグを特定するフラグ特定ステップと、
ソート後の前記複数のレコードの順番に前記フラグを特定している過程において、特定された前記フラグの出現態様が、前記検索指示に従ったものであるか判断する判断ステップと、
前記フラグの出現態様が前記検索指示に従っていると判断された場合には、当該フラグの出現態様に含まれるフラグに係るレコードのデータを出力するステップと、
を含む、コンピュータにより実行される検索処理方法。
【００８２】
（付記２）
前記フラグ付与ステップが、
特定の検索条件に含まれる、前記特定の項目の前記特定の値に対応し且つ前記データベース内のレコードに含まれる前記特定の項目の項目値を特定するステップと、
特定された前記項目値に、前記特定の検索条件の順序付けに応じたフラグを付与するステップと、
を含む付記１記載の検索処理方法。
【００８３】
（付記３）
前記判断ステップが、
特定された前記フラグに応じて、前記順序付けに応じて定義される状態間の遷移が発生するか判断するステップと、
前記状態間の遷移が発生した場合には、最終状態まで到達したか判断するステップと、
を含む付記１記載の検索処理方法。
【００８４】
（付記４）
前記所定のルールが、前記検索指示で指定されたグループ項目毎且つ時系列という条件であり、
前記判断ステップにおいて、前記グループ項目における同一の項目値内において前記フラグの出現態様を判断する
付記１記載の検索処理方法。
【００８５】
（付記５）
前記データベースが、
各項目において、項目値を一意で特定する項目値番号と当該項目値との関係を保持するテーブルと、前記レコードの順番に前記項目値番号を指定する情報が格納されている項目値番号指定情報配列とを保持する
付記１記載の検索処理方法。
【００８６】
（付記６）
前記フラグが、該当する前記検索条件の前記順序付けに応じたビット位置に１がセットされたビット列である
付記１記載の検索処理方法。
【００８７】
（付記７）
前記フラグ特定ステップが、
前記データベースに格納されており且つ検索対象である前記複数のレコードに１回のみ実施される
付記１記載の検索処理方法。
【００８８】
（付記８）
付記１乃至７のいずれか１つ記載の検索処理方法をコンピュータに実行させるためのプログラム。
【００８９】
（付記９）
各々特定の項目に対して特定の値が指定されており且つ順序付けがなされた複数の検索条件を含む検索指示に基づき、前記特定の項目の各項目値にフラグを付与し、フラグ定義データとして記憶装置に格納する手段と、
データベースに格納されており且つ検索対象である複数のレコードを所定のルールに従ってソートする手段と、
ソート後の前記複数のレコードの順番に、前記記憶装置に格納された前記フラグ定義データを用いて、処理に係るレコードにおける前記特定の項目の項目値に対応するフラグを特定する手段と、
ソート後の前記複数のレコードの順番に前記フラグを特定している過程において、特定された前記フラグの出現態様が、前記検索指示に従ったものであるか判断する手段と、
前記フラグの出現態様が前記検索指示に従っていると判断された場合には、当該フラグの出現態様に含まれるフラグに係るレコードのデータを出力する手段と、
を有する検索処理装置。
【図面の簡単な説明】
【００９０】
【図１】売上履歴テーブルの一例を示す図である。
【図２】従来技術のデータ構造を示す図である。
【図３】ソート後の売上履歴テーブルの一例を示す図である。
【図４】ソート後のＳＥＴ配列の一例を示す図である。
【図５】従来技術の検索処理を説明するための図である。
【図６】１番目の条件にヒットしたレコード群を示す図である。
【図７】従来技術の検索処理を説明するための図である。
【図８】従来技術の検索処理を説明するための図である。
【図９】本発明の実施の形態に係るシステム概要図である。
【図１０】検索指示の入力画面例を示す図である。
【図１１】本発明の実施の形態に係るメインの処理フローを示す図である。
【図１２】イベント判定処理の処理フローを示す図である。
【図１３】イベント管理テーブルの一例を示す図である。
【図１４】本発明の実施の形態に係る検索処理の処理フローの第１の部分を示す図である。
【図１５】イベント履歴条件テーブルの初期状態を示す図である。
【図１６】イベント履歴条件テーブルの次の状態を示す図である。
【図１７】イベント履歴条件テーブルの次の次の状態を示す図である。
【図１８】イベントフラグテーブルの一例を示す図である。
【図１９】状態遷移図の一例を示す図である。
【図２０】本発明の実施の形態に係る検索処理の処理フローの第２の部分を示す図である。
【図２１】イベントフラグテーブルの利用方法を示す図である。
【図２２】抽出イベントテーブルの一例を示す図である。
【図２３】本発明の実施の形態に係るイベントフラグと状態遷移の具体例を示す図である。
【図２４】出力結果の一例を示す図である。
【図２５】コンピュータの機能ブロック図である。
【符号の説明】
【００９１】
１ ネットワーク
３ ユーザ端末
５ ＤＢサーバ
５１ 検索指示受信部
５２ 検索指示データ格納部
５３ イベント判定処理部
５４ イベント管理テーブル格納部
５５ 検索前処理部
５６ ＦＡＳＴ構造データ格納部
５７ イベント履歴条件テーブル格納部
５８ ソート結果格納部
５９ 検索処理部
６０ 検索結果格納部
６１ 検索結果出力部
５９１ 状態遷移管理部
【特許請求の範囲】
【請求項１】
各々特定の項目に対して特定の値が指定されており且つ順序付けがなされた複数の検索条件を含む検索指示に基づき、前記特定の項目の各項目値にフラグを付与し、フラグ定義データとして記憶装置に格納するフラグ付与ステップと、
データベースに格納されており且つ検索対象である複数のレコードを所定のルールに従ってソートするソート・ステップと、
ソート後の前記複数のレコードの順番に、前記記憶装置に格納された前記フラグ定義データを用いて、処理に係るレコードにおける前記特定の項目の項目値に対応するフラグを特定するフラグ特定ステップと、
ソート後の前記複数のレコードの順番に前記フラグを特定している過程において、特定された前記フラグの出現態様が、前記検索指示に従ったものであるか判断する判断ステップと、
前記フラグの出現態様が前記検索指示に従っていると判断された場合には、当該フラグの出現態様に含まれるフラグに係るレコードのデータを出力するステップと、
を含む、コンピュータにより実行される検索処理方法。
【請求項２】
前記フラグ付与ステップが、
特定の検索条件に含まれる、前記特定の項目の前記特定の値に対応し且つ前記データベース内のレコードに含まれる前記特定の項目の項目値を特定するステップと、
特定された前記項目値に、前記特定の検索条件の順序付けに応じたフラグを付与するステップと、
を含む請求項１記載の検索処理方法。
【請求項３】
前記判断ステップが、
特定された前記フラグに応じて、前記順序付けに応じて定義される状態間の遷移が発生するか判断するステップと、
前記状態間の遷移が発生した場合には、最終状態まで到達したか判断するステップと、
を含む請求項１記載の検索処理方法。
【請求項４】
請求項１乃至３のいずれか１つ記載の検索処理方法をコンピュータに実行させるためのプログラム。
【請求項５】
各々特定の項目に対して特定の値が指定されており且つ順序付けがなされた複数の検索条件を含む検索指示に基づき、前記特定の項目の各項目値にフラグを付与し、フラグ定義データとして記憶装置に格納する手段と、
データベースに格納されており且つ検索対象である複数のレコードを所定のルールに従ってソートする手段と、
ソート後の前記複数のレコードの順番に、前記記憶装置に格納された前記フラグ定義データを用いて、処理に係るレコードにおける前記特定の項目の項目値に対応するフラグを特定する手段と、
ソート後の前記複数のレコードの順番に前記フラグを特定している過程において、特定された前記フラグの出現態様が、前記検索指示に従ったものであるか判断する手段と、
前記フラグの出現態様が前記検索指示に従っていると判断された場合には、当該フラグの出現態様に含まれるフラグに係るレコードのデータを出力する手段と、
を有する検索処理装置。
【請求項１】
各々特定の項目に対して特定の値が指定されており且つ順序付けがなされた複数の検索条件を含む検索指示に基づき、前記特定の項目の各項目値にフラグを付与し、フラグ定義データとして記憶装置に格納するフラグ付与ステップと、
データベースに格納されており且つ検索対象である複数のレコードを所定のルールに従ってソートするソート・ステップと、
ソート後の前記複数のレコードの順番に、前記記憶装置に格納された前記フラグ定義データを用いて、処理に係るレコードにおける前記特定の項目の項目値に対応するフラグを特定するフラグ特定ステップと、
ソート後の前記複数のレコードの順番に前記フラグを特定している過程において、特定された前記フラグの出現態様が、前記検索指示に従ったものであるか判断する判断ステップと、
前記フラグの出現態様が前記検索指示に従っていると判断された場合には、当該フラグの出現態様に含まれるフラグに係るレコードのデータを出力するステップと、
を含む、コンピュータにより実行される検索処理方法。
【請求項２】
前記フラグ付与ステップが、
特定の検索条件に含まれる、前記特定の項目の前記特定の値に対応し且つ前記データベース内のレコードに含まれる前記特定の項目の項目値を特定するステップと、
特定された前記項目値に、前記特定の検索条件の順序付けに応じたフラグを付与するステップと、
を含む請求項１記載の検索処理方法。
【請求項３】
前記判断ステップが、
特定された前記フラグに応じて、前記順序付けに応じて定義される状態間の遷移が発生するか判断するステップと、
前記状態間の遷移が発生した場合には、最終状態まで到達したか判断するステップと、
を含む請求項１記載の検索処理方法。
【請求項４】
請求項１乃至３のいずれか１つ記載の検索処理方法をコンピュータに実行させるためのプログラム。
【請求項５】
各々特定の項目に対して特定の値が指定されており且つ順序付けがなされた複数の検索条件を含む検索指示に基づき、前記特定の項目の各項目値にフラグを付与し、フラグ定義データとして記憶装置に格納する手段と、
データベースに格納されており且つ検索対象である複数のレコードを所定のルールに従ってソートする手段と、
ソート後の前記複数のレコードの順番に、前記記憶装置に格納された前記フラグ定義データを用いて、処理に係るレコードにおける前記特定の項目の項目値に対応するフラグを特定する手段と、
ソート後の前記複数のレコードの順番に前記フラグを特定している過程において、特定された前記フラグの出現態様が、前記検索指示に従ったものであるか判断する手段と、
前記フラグの出現態様が前記検索指示に従っていると判断された場合には、当該フラグの出現態様に含まれるフラグに係るレコードのデータを出力する手段と、
を有する検索処理装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【公開番号】特開２００７−３２３５４６（Ｐ２００７−３２３５４６Ａ）
【公開日】平成１９年１２月１３日（２００７．１２．１３）
【国際特許分類】
【出願番号】特願２００６−１５５５５２（Ｐ２００６−１５５５５２）
【出願日】平成１８年６月５日（２００６．６．５）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成１９年１２月１３日（２００７．１２．１３）
【国際特許分類】
【出願日】平成１８年６月５日（２００６．６．５）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]