JP5452517B2 - 検索処理装置 - Google Patents

Description

この発明は、データベースに対する検索処理装置に関するものである。

従来、定周期に処理が起動し予め指定されたデータを収集するバッチ検索処理装置として、例えば特許文献１に記載するような装置が提案されている。

特開平１１−２３８０４３号公報（第４〜７頁、第１０図、第１１図）

従来のデータベース検索では、データベースに格納された情報を検索するのに逐次的な検索を行う場合、検索開始から検索結果が返ってくるまでの間、利用者は終了を待たなければならず、業務を継続することができないという問題があった。この問題に対応するため、一日の業務が終了した時刻から翌日の業務開始時刻までの間など、予め定められた時間帯に検索を実行するバッチ検索処理がある。

しかし、従来のバッチ検索処理では、バッチ検索を開始する時間のみが設定可能であり、本来、業務開始時刻までに処理が終了していなければならないバッチ検索が、業務開始時刻後も継続して行われ、業務に影響を与えてしまうという問題があった。

また、従来のバッチ検索処理では、登録しているバッチ検索処理要求の状況を確認することができず、完了状態なのか、未実施なのか、検索結果は何件あったのかなどを知ることが困難であった。

本発明は上記の問題点に鑑みてなされたものであり、終了指定時刻に確実にバッチ検索処理を終了でき、登録されているバッチ検索処理要求の管理を行うことができる検索処理装置を提供することを目的とする。

この発明に係る検索処理装置は、
データベースの検索処理を行う検索処理装置において、
検索条件を指定して検索処理のリクエストを発行するリクエスト発行手段と、
すべてのリクエストについての検索動作を定義する補助検索情報設定ファイルと、
リクエストをリクエスト管理ファイルに登録、管理するリクエスト管理手段と、
リクエスト管理ファイルに記録された各リクエストの内容を元に、検索対象テーブルに対する即時検索又はバッチ検索を実施する検索実行手段とを備え、
補助検索情報設定ファイルはバッチ検索を強制的に終了する終了時刻を有することを特徴とするものである。

この発明に係る検索処理装置は、
データベースの検索処理を行う検索処理装置において、
検索条件を指定して検索処理のリクエストを発行するリクエスト発行手段と、
すべてのリクエストについての検索動作を定義する補助検索情報設定ファイルと、
リクエストをリクエスト管理ファイルに登録、管理するリクエスト管理手段と、
リクエスト管理ファイルに記録された各リクエストの内容を元に、検索対象テーブルに対する即時検索又はバッチ検索を実施する検索実行手段とを備え、
補助検索情報設定ファイルはバッチ検索を強制的に終了する終了時刻を有することを特徴とするものなので、
バッチ検索を開始しようとする時刻とバッチ検索終了時刻の差分をデータベース検索タイムアウト時間としてデータベース接続ドライバに設定することにより、タイムアウト発生時に検索処理を自動的に停止させることが可能となる。バッチ検索終了時刻を業務開始時刻前に設定しておくことで、指定時刻までに終了しておかなければならない検索処理を必ず終了させることができる。

この発明の実施の形態１に係る検索処理装置１００のハードウェア構成を示す図である。 この発明の実施の形態１に係る検索処理装置１００のソフトウェア構成を示す図である。 この発明の実施の形態１に係るリクエスト発行画面１ａの構成を示す図である。 この発明の実施の形態１に係るリクエスト管理ファイル４の構成を示す図である。 この発明の実施の形態１に係る検索条件管理ファイル２の内容を示す図である。 この発明の実施の形態１に係るリクエスト管理画面１ｂを示す図である。 この発明の実施の形態１に係るリクエスト受付制御フラグ９の一例を示す図である。 この発明の実施の形態１に係る強制バッチ検索実行テーブル一覧１１の一例を示す図である。 この発明の実施の形態１に係るリクエスト発行のフローを示す図である。 この発明の実施の形態１に係るバッチ検索のフローを示す図である。 この発明の実施の形態１に係る補助検索情報設定ファイル１３の構成を示す図である。 この発明の実施の形態１に係るリクエスト管理画面１ｂを呼び出すフローを示す図である。 この発明の実施の形態１に係るリクエスト管理画面１ｂでのボタン操作のフローを示す図である。 この発明の実施の形態２に係るバッチ検索実行時の検索実行手段６と、リクエスト受付制御手段８と外部アプリケーション７の動作フローを示す図である。 この発明の実施の形態３に係るバッチ検索のフローを示す図である。 この発明の実施の形態４に係るリクエスト発行手段３の動作フローを示す図である。

実施の形態１．
以下、この発明の実施の形態１を図に基づいて説明する。
図１は、この発明の実施の形態１に係る検索処理装置１００のハードウェア構成を示す図である。検索処理装置１００は、アプリケーションサーバとＤＢサーバを備えたバッチ検索サーバと、これに接続されたクライアント端末で構成される。

図２は、検索処理装置１００のソフトウェア構成を示す図である。
図３は、リクエスト発行画面１ａの構成を示す図である。
リクエスト発行画面１ａは、検索処理装置１００を使用するユーザが、データベースに対する検索要求（以下リクエストという）を発行するために用いる端末画面である。

図３に示す検索条件表示領域２１には、これから検索しようとするデータベースに対する検索条件を、図示しない条件編集手段で設定した内容が表示されている。
当該データベースの検索条件は削除ボタン２２、変更ボタン２３を押すことにより削除、変更することが可能である。
検索方式選択領域２５は、データベースに対して「即時検索」を行うか、「バッチ検索」を行うかを択一的に選択可能なラジオボタンである。
検索方式選択領域２５において、検索方式にバッチ検索を選択し、リクエスト発行ボタン２４を押下すると、検索条件表示領域２１に示された検索条件でのリクエスト情報がリクエスト発行手段３に渡されるように構成されている。

図４は、ユーザによって順次要求されたリクエストを格納するリクエスト管理ファイル４の構成を示す図である。
リクエスト発行手段３は、リクエスト発行画面１ａから入力されたリクエスト情報をリクエスト管理ファイル４に図４に示す形式で格納する。
図５は、検索条件管理ファイル２の内容を示す図である。
データベース検索条件については、リクエスト管理ファイル４に格納した上述のリクエスト情報と、オブジェクトＩＤを介して１対１に対応する形で図５に示す検索条件管理ファイル２に格納する。

図６は、リクエスト管理画面１ｂを示す図である。
リクエスト管理画面１ｂは、検索処理装置１００を使用するユーザが、リクエスト発行画面１ａを利用して発行したリクエストを後から管理するために用いる端末画面である。
リクエスト管理画面１ｂには、リクエスト管理手段５によって取得された既存のリクエスト情報が一覧表示される。
リクエスト管理手段５は、リクエスト管理画面１ｂを介して、リクエスト管理ファイル４にて管理されているリクエスト情報と、検索条件管理ファイル２にて管理されているデータベース検索条件について、それぞれ更新、削除、参照を可能とする。

画面表示項目としては、オブジェクトＩＤ４０１、リクエストのタイトル４０２、リクエストの登録日時４０６、バッチ検索処理の開始時刻４０７、当該バッチ検索処理の終了時刻４０８、検索結果件数４１０、リクエストの処理の進捗状態を示すリクエスト処理状態４０３、検索処理の処理状態を示す検索処理状態４２０を表示する。
また、画面下部にはダウンロードボタン４３０、リクエスト情報の削除ボタン４３１、リクエスト情報の変更ボタン４３２、戻るボタン４３３、リクエスト管理画面の終了ボタン４３４が配置され、後述するバッチ検索実行結果のダウンロード、リクエスト情報の削除、リクエスト情報の設定変更、前画面への遷移、リクエスト管理画面１ｂの終了の各操作が行えるように構成されている。リクエスト管理画面１ｂの使用方法についての詳細は後述する。

バッチ検索処理を実行する時は、ジョブスケジューラ等の外部アプリケーション７から検索実行手段６を起動し、リクエスト管理ファイル４にて管理されているリクエスト情報と、検索条件管理ファイル２に管理されているデータベース検索条件等の各種情報を使用して検索対象データベース１２を検索する。
検索の実行結果は、検索実行手段６によってリクエスト管理ファイル４の所定の領域に格納され、リクエスト管理画面１ｂを介して実行結果の取得、バッチ検索のリクエスト管理が行えるが、検索処理動作の詳細については後述する。

図７は、リクエスト受付制御フラグ９の一例を示す図である。
受付状態は「受付可」か「受付不可」のいずれかである。
リクエスト受付制御手段８は、このリクエスト受付制御フラグ９の値を制御する。
動作の詳細については後述する。

図８は、強制バッチ検索実行テーブル一覧１１の一例を示す図である。
強制バッチ検索実行テーブルとは、検索方法として「即時検索」を選択できず、「バッチ検索」のみ選択可能な検索対象テーブルをいう。
強制バッチ検索実行テーブル取得手段１０は、強制バッチ検索実行テーブル一覧１１を取得し、強制的にバッチ検索を実行させるテーブルＩＤを取得し、このテーブルＩＤ情報をリクエスト発行画面１ａに渡すように構成されている。
図８ではテーブルＩＤとして３種類記載しているが、種類および数に制約はない。
強制バッチ検索実行テーブル取得手段１０は、ユーザによって発行されたリクエストの条件の中に、「即時検索」を指定できず必ずバッチ検索を指定しなければならないテーブルが有るか否かを判定するために用いられる。

次に、リクエスト発行の動作について図を用いて説明する。
図９は、リクエスト発行のフローを示す図である。
図９のフローチャート開始時点において、データベースから目的のデータを所定のテーブルおよびカラムから抽出する検索条件は、既に図示しない適切な方法で作成済みであるものとする。
また、検索条件の識別名、検索条件の作成者名、検索条件の作成ユーザＩＤも条件式の作成時に取得されているものとする。

まず、強制バッチ検索実行テーブル取得手段１０によって、強制バッチ検索実行テーブル一覧１１から、強制的にバッチ検索を実施すべきものとして指定されているテーブル情報を取得する（ステップＳ１００）。

上記、適切な方法で設定された条件式内の検索対象テーブル情報が、上記ステップＳ１００で取得したテーブル情報に含まれるかどうか判定し（ステップＳ１０１）、含まれる場合（ステップＳ１０１→ＹＥＳ）、すなわち、強制的にバッチ検索方式を採用させるべき場合は、図３に示す検索方式選択領域２５で選択可能な検索方式のうち、即時検索方式のラジオボタンを非活性にし、「バッチ検索」のラジオボタンをＯＮするように制御する（ステップＳ１０２）。
上記ステップＳ１０１において、検索対象テーブル情報が強制バッチ検索実行テーブル一覧１１に含まれていない場合（ステップＳ１０１→ＮＯ）は、検索方式選択領域２５で選択可能な方式の非活性化制御は実施しない。

次に、リクエスト発行手段３は、リクエスト受付制御フラグ９を取得する（ステップＳ１０３）。

次に、上記ステップＳ１０３で取得したフラグが示す受付可否情報の内容が「受付不可」かどうかを判定する（ステップＳ１０４）。
上記ステップＳ１０３で取得した受付可否情報の内容が「受付不可」（ステップＳ１０４→ＹＥＳ）の場合、リクエスト発行不可の通知を実施し（ステップＳ１０６）、リクエスト発行処理を終了する。
上記ステップＳ１０３で取得した受付可否情報の内容が「受付不可」でない場合（ステップＳ１０４→ＮＯ）、図４に示すリクエスト管理ファイル４にリクエスト情報を格納する（ステップＳ１０５）。

更に上記ステップＳ１０５の詳細について図４を併用して説明する。検索条件管理ファイル２から取得したタイトル４０２、ユーザ名４０５、ユーザＩＤ４０４は、リクエスト管理ファイル４のそれぞれ割り当てられた領域に格納される。オブジェクトＩＤ４０１として一意の識別子情報を発行して格納し、リクエスト処理状態４０３として「受付済」等を示す情報を格納し、登録日時４０６としてリクエスト管理ファイル４にこれらのリクエスト情報を格納した登録日時を格納し、検索処理状態４２０として「未処理」等を示す情報を格納する。
リクエスト管理ファイル４には、バッチ検索の開始時刻４０７、バッチ検索の終了時刻４０８、検索結果件数４１０、検索結果データ４１１を格納する領域を設けているが、ステップＳ１０５の時点でバッチ検索が実行されていないため、これらの情報については格納しない。

リクエスト発行手段３は、上記ステップＳ１０５で発行した一意の識別子情報であるオブジェクトＩＤを付して、データベース検索条件については別途、検索条件管理ファイル２に格納する。

上記ステップＳ１００〜ステップＳ１０７の実行により、リクエスト発行画面１ａを使用して検索方式等を設定し、リクエスト発行手段３により、リクエスト管理ファイル４にはリクエスト情報を、検索条件管理ファイル２にはデータベース検索条件を格納する動作が完了する。

次に、検索処理装置１００において、検索対象データベース１２をバッチ検索する動作について説明する。

図１０は、バッチ検索のフローを示す図である。
検索実行手段６によるバッチ検索は、市販またはＯＳ付属のジョブスケジューラ等の外部アプリケーション７によるリクエスト受付制御手段８の起動から開始される。（ステップＳ２０１）。リクエスト受付制御手段８は、新規リクエストの受付可否情報であるリクエスト受付制御フラグ９の値を「受付可能」から「受付不可」に更新する（ステップＳ２０２）。これにより、バッチ検索中に新たに発行したリクエストがシステムに登録されることを防ぐことが可能となる。

次に、外部アプリケーション７により、検索実行手段６を起動する（ステップＳ２０３）。起動した検索実行手段６は、リクエスト受付制御フラグ９を取得し、受付可否情報が「受付不可」となっているかどうか判定する（ステップＳ２０４）。上記ステップにおいて、受付可否情報が「受付不可」（ステップＳ２０４→ＹＥＳ）となっている場合、既に実行しているバッチ検索が終了していないので検索実行手段６の処理を終了する（ステップＳ２１３）。

図１１は、補助検索情報設定ファイル１３の構成を示す図である。
補助検索情報設定ファイル１３には、バッチ検索処理について、全リクエストを対象とする設定事項を記載している。
上記ステップＳ２０４において受付可否情報が「受付可」（ステップＳ２０４→ＮＯ）となっている場合、検索実行手段６は補助検索情報設定ファイル１３から、バッチ検索終了時刻を取得する（ステップＳ２０５）。

検索実行手段６は、ステップＳ２０５の処理終了後、リクエスト管理ファイル４からバッチ検索処理対象となる、リクエスト情報を取得する（ステップＳ２０６）。
当該リクエスト情報は、リクエスト管理ファイル４に格納されているリクエスト情報のうち、リクエスト処理状態４０３が「受付済」かつ検索処理状態４２０が「未処理」のもの、リクエスト処理状態４０３が「完了」かつ検索処理状態４２０が「中断」のもの、リクエスト処理状態が「再実行」のものが対象となる。

次に、検索実行手段６は、上記ステップＳ２０６で取得したリクエスト情報のオブジェクトＩＤをもとに、当該オブジェクトＩＤを持つデータベース検索条件を検索条件管理ファイル２より取得する（ステップＳ２０７）。

次に、検索実行手段６は、現在時刻と上記ステップＳ２０５で取得したバッチ検索終了時刻との差分を求め、この差分をＪＤＢＣ等のデータベース接続ドライバのクエリタイムアウト時間として設定する（ステップＳ２０８）。
これにより、最長でもバッチ検索終了時刻まで検索を行い、タイムアウトにより自動的に検索を強制終了させることが可能となる。

上記ステップＳ２０８実行後、検索実行手段６は、現在処理中のリクエスト情報の開始日時を現在時刻に更新し、上記ステップＳ２０７にて取得したデータベース検索条件を元に検索を実行する。（ステップＳ２０９）。
ステップＳ２０９にてデータベースの検索を実施している間、現在時刻がバッチ終了時刻を越えていないかどうか判定し（ステップＳ２１０）、
現在時刻がバッチ終了時刻を越えていない場合（ステップＳ２１０→ＮＯ）は，検索が終了したかどうかを再度一定周期後判定し（ステップＳ２１０１）、これを繰り返す。
検索終了時刻を超えている場合（ステップＳ２１０→ＹＥＳ）は，リクエスト管理ファイル４を次の手順で更新する（ステップＳ２１１）。

ステップＳ２１０１にて検索が終了していた（ステップＳ２１０１→ＹＥＳ）場合、検索実行手段６は、処理対象としていたリクエスト情報のリクエスト処理状態４０３を「処理中」から「完了」に更新し、終了時刻４０８に現在時刻を記入し、検索処理状態４２０を「正常終了」、「異常終了」、「中断」のいずれかに更新する。検索結果件数４１０は検索処理状態４２０の内容が「正常終了」の場合のみ更新する。また、検索結果データ４１１は、検索処理状態４２０の内容が「正常終了」または「異常終了」の場合のみ更新され、「正常終了」の場合は所定の形式で格納される。
「異常終了」の場合は、エラー情報がテキスト形式のファイルで格納される（ステップＳ２１１）。

ステップＳ２１１終了後、検索実行手段６は、現在時刻が上記ステップＳ２０５で取得したバッチ検索終了時刻を過ぎているかどうか判定する（ステップＳ２１２）。現在時刻がバッチ検索終了時刻を過ぎている場合（ステップＳ２１２→ＹＥＳ）、ステップＳ２１３にて検索実行手段６の処理を終了する。現在時刻がバッチ検索終了時刻を過ぎていない（ステップＳ２１２→ＮＯ）場合、検索実行手段６は、リクエスト管理ファイル４から次のバッチ検索の対象となるリクエスト情報を取得する（ステップＳ２０６）。これにより、検索実行手段６が再度起動してバッチ検索終了時刻までの間バッチ検索処理が継続されることとなる。

上記ステップＳ２０４でリクエスト受付制御フラグ９が「受付不可」である、（ステップＳ２０４→ＹＥＳ）場合又は、上記ステップＳ２１２で現在時刻がバッチ終了時刻を過ぎている（ステップＳ２１２→ＹＥＳ）の場合、検索実行手段６は自身の処理を終了する（ステップＳ２１３）。

上記ステップＳ２１３実行後、外部アプリケーション７に制御が返り、外部アプリケーション７がリクエスト受付制御手段８を起動する（ステップＳ２１４）。

上記ステップＳ２１４で起動されたリクエスト受付制御手段８は、リクエスト受付制御フラグ９に格納されている受付可否情報を「受付可能」に変更する（ステップＳ２１５）。これにより、リクエスト発行手段３にてリクエスト発行が可能となり、新規にリクエストを発行することができる。

次に、検索処理装置１００において、リクエスト情報の一覧表示を行う動作について、図２、図６、図１２を用いて説明する。
図２に示すように、リクエスト管理画面１ｂには、リクエスト管理手段５を介することによってリクエスト管理ファイル４から取得されるリクエスト情報が表示される。

図１２は、リクエスト管理画面１ｂを呼び出すフローを示す図である。
図１２において、リクエスト管理画面１ｂの表示要求があった場合、リクエスト管理手段５が起動される（ステップＳ３０１）。

ステップＳ３０１において起動されたリクエスト管理手段５は、リクエスト管理ファイル４に格納されているリクエスト情報の一覧を取得する（ステップＳ３０２）。

次に、ステップＳ３０２において取得されたリクエスト情報の各々について、リクエスト管理画面１ｂに出力する（ステップＳ３０３）。

次に、検索処理装置１００において、リクエスト管理画面１ｂとリクエスト管理手段５を介したリクエスト情報の削除動作と、リクエスト管理画面１ｂと検索結果取得手段１４を介した検索結果のダウンロード動作について、図１３を用いて説明する。

図１３は、リクエスト管理画面１ｂでのボタン操作のフローを示す図である。
リクエスト情報の削除は、リクエスト管理画面１ｂから実施する。図１３においてステップＳ３０１〜ステップＳ３０３は上記リクエスト一覧表示と同様の処理のため説明を省略する。リクエスト管理画面１ｂで操作対象のリクエスト情報と、このリクエスト情報への操作を選択する（ステップＳ４０１）。

上記ステップＳ４０１にて選択したリクエスト情報と、当該リクエスト情報に対して実行する操作のうち、どの操作が選択されたかを判定（ステップＳ４０２）し、選択された操作が「削除」（ステップＳ４０２→削除）の場合、上記ステップＳ４０１で取得したリクエスト情報のオブジェクトＩＤ４０１に該当するリクエスト情報をリクエスト管理ファイル４から削除する（ステップＳ４０３）。

続いて、上記ステップＳ４０１で取得したリクエスト情報のオブジェクトＩＤ４０１に該当するデータベース検索条件を検索条件管理ファイル２から削除する（ステップＳ４０４）。これによりリクエスト情報および、データベース検索条件が削除される。

上記ステップＳ４０２で判定した結果、処理がダウンロードの場合（ステップＳ４０２→ダウンロード）、リクエスト管理ファイル４からステップＳ４０１で取得したオブジェクトＩＤ４０１に該当するリクエスト情報を取得する。（ステップＳ４０５）。

上記ステップＳ４０５で取得したリクエスト情報の検索結果データ４１１を取得し（ステップＳ４０６）、上記ステップＳ４０６で取得したデータをダウンロード可能なデータファイルに変換する（ステップＳ４０７）。

この実施の形態１に係る検索処理装置によれば、バッチ検索を開始しようとする時刻とバッチ検索終了時刻の差分をデータベース検索タイムアウト時間としてデータベース接続ドライバに設定することにより、タイムアウト発生時に検索処理を自動的に停止させることが可能となる。バッチ検索終了時刻を業務開始時刻前に設定しておくことで、業務開始時刻までに終了しておかなければならない検索処理を終了させる効果を得ることができる。

また、リクエスト管理ファイル４に格納されているリクエスト情報に基づき、バッチ検索処理が実行されているので、リクエスト管理手段５を介してリクエスト情報を表示するリクエスト管理画面１ｂによって、バッチ検索の実行状況を確認すすることができる。

実施の形態２．
以下この発明に係る検索処理装置の実施の形態２を図を用いて説明する。
この実施の形態２では、同時に検索可能な検索実行手段６の多重度を指定できる構成としてバッチ検索を実施する。

図１４は、この発明の実施の形態２に係るバッチ検索実行時の検索実行手段６と、リクエスト受付制御手段８と外部アプリケーション７の動作を示すフローを示す図である。
実施の形態１で説明した図１０と同じステップについては同じ符号を使用し、異なる部分を中心に説明する。

実施の形態１において図１１を用いて説明した補助検索情報設定ファイル１３には、バッチ検索の多重度の設定項目を設けている。
実施の形態１では、この設定について言及しなかったが、実施の形態２ではこれを２以上に設定した場合について説明する。

図１４，ステップＳ６０６にて、ステップＳ２０５で取得した補助検索情報に含まれる多重度の情報をもとに、検索実行用のスレッドを生成する。本ステップで生成した各スレッドが独立し、リクエスト管理ファイル４からリクエスト情報を取得（ステップＳ６０７）し、ステップＳ６０７で取得したリクエスト情報を元に、データベース検索条件を取得（ステップＳ６０８）する。

ステップＳ６０９にて各スレッドが現在時刻から補助検索情報設定ファイル１３で定義されているバッチ検索終了時刻との差分を計算し、ＪＤＢＣ等のデータベース接続ドライバのクエリタイムアウト値として設定し、ステップＳ６１０にてリクエスト管理ファイル４の開始時刻を現在時刻に更新し、ステップＳ６０８で取得したデータベース検索条件を用いて検索対象データベース１２を検索する。なお、クエリタイムアウトが設定されているため、タイムアウトとなった場合は自動的に検索が終了することとなる。

ステップＳ６１１では、各検索実行スレッドにおいて，現在時刻がバッチ終了時刻を越えていないかどうか判定し，超えている場合（ステップＳ６１１→ＹＥＳ）の場合は，リクエスト情報を更新する（ステップＳ６１２）。反対に現在時刻がバッチ終了時刻を越えていない場合（ステップＳ６１１→ＮＯ）は，検索が終了したかどうかを判定し（ステップＳ６１１１），検索が終了していない（ステップＳ６１１１→ＮＯ）場合、検索処理を継続する。検索が終了している（ステップＳ６１１１→ＹＥＳ）場合、検索結果、終了時刻、リクエスト情報および検索処理状態を更新し、ステップＳ６０７に移行する（ステップＳ６１３）。

ステップＳ６０７では当該スレッドがリクエスト管理ファイル４から、新しいリクエスト情報を取得し、以降のステップを実行する。

この実施の形態２によれば、データベース検索を行う検索処理部をマルチスレッド化することによって、複数のバッチ検索を並行して実施することが可能となる。これによって、データベース検索処理効率が向上し、短時間により多くのリクエストを処理する効果を得ることができる。

実施の形態３．
以下この発明に係る検索処理装置の実施の形態３を図を用いて説明する。
図１５は、この発明の実施の形態３に係るバッチ検索のフローを示す図である。

実施の形態１において、検索対象データベース１２に強制的にバッチ検索を適用するテーブルが含まれている場合について述べた。
本実施の形態３に係る検索処理装置３００では、検索対象テーブルの結合数が閾値以上の場合は、強制的にバッチ検索のみが選択可能となる構成を付加している。
このテーブル結合数の閾値の設定は、補助検索情報設定ファイル１３（図１３）でおこなう。）
以下、この設定を２以上とした場合の検索フローについて、実施の形態１，２と異なる部分を中心に説明する。

図１５、ステップＳ７００において、データベース検索条件のうち、検索対象テーブルに強制的にバッチ検索を適用するテーブルが含まれているか、又はテーブル結合数が閾値以上であるかを判定する。
ＹＥＳの場合は、ステップＳ１０２に進み、「即時検索」のラジオボタンを非活性化する。
この場合、強制的にバッチ検索のみが選択可能なように構成されることとなる。
ＮＯの場合は、ステップＳ１０３へ進み実施の形態１と同様の処理を進める。

これにより、複数の検索対象テーブルのレコード数に依存して検索時間が大きく変化するような結合が行われているテーブルの検索において、誤って即時検索を実行し、自業務への悪影響、他利用者への悪影響を及ぼす可能性を低減することができる。

この実施の形態３によれば、検索処理装置３００での検索処理において、予め指定されたテーブルが含まれている場合だけでなく、テーブル間の結合度合いにより、検索にかかる時間が大きくなるような検索条件であっても、検索方式にバッチ検索のみが選択できるようになり、検索処理が長時間継続して他の業務が遂行できないといった状況や、業務時間中にデータベースサーバのリソースを大量に消費することによる他利用者への悪影響を軽減することができ、データベースサーバの利用効率を高める効果が得られる。

実施の形態４．
実施の形態１〜３では、リクエストの発行数について上限が設けられていなかったため、１人の利用者が多数のリクエストを発行することが可能であり、これによって他利用者がリクエストしたバッチ検索が実行されなくなるといった問題が発生する可能性がある。
実施の形態４に係る検索処理装置４００は、利用者およびシステム全体でのリクエスト上限数を設け、利用者のリクエストが公平に実行される構成としている。

図１６は、実施の形態４のリクエスト発行手段３の動作フローを示す図である。
実施の形態３で説明した図１５と異なる部分を中心に説明する。

図１６のステップＳ８０５にて、リクエスト発行手段３が補助検索情報設定ファイル１３から補助検索情報を取得する。
この補助検索情報に格納されているユーザ単位でのリクエスト上限数とシステム全体でのリクエスト上限数と、現在リクエストを発行しようとしているユーザの発行済リクエスト数とシステム全体のリクエスト数を比較する（ステップＳ８０６）。

ユーザの発行リクエスト数、システム全体のリクエスト数のいずれか、またはその両方が定義された値より大きい場合は（ステップＳ８０６→ＹＥＳ）、リクエスト発行不可の通知を実施し（ステップＳ８０７）、リクエスト発行処理を終了する。
ユーザの発行済リクエスト数が上記ステップＳ８０５で取得した補助検索情報のユーザ単位でのリクエスト上限数未満である場合かつ、システム全体のリクエスト数が上記ステップＳ８０５で取得した補助検索情報のシステム全体でのリクエスト上限数未満である場合（ステップＳ８０６→ＮＯ）は、後段のリクエスト発行処理を継続する。

この実施の形態５によれば、リクエストを発行する際、ユーザ単位でのリクエスト発行上限数と、システム全体でのリクエスト発行数が補助検索情報設定ファイル１３に格納されたユーザ単位でのリクエスト上限数と、システム全体のリクエスト上限数のいずれかを超える場合、リクエスト処理が終了することとなる。これにより、あるユーザにバッチ検索処理が占有されてしまうことを回避し、またシステム全体でも無制限にリクエストが発行されてしまうことを回避する効果を得ることが可能となる。

なお、実施の形態１〜４ではデータの格納先として「ファイル」を指定した場合を記載したが、ファイルはデータベースとしても良いことは言うまでもない。

１００，３００，４００ 検索処理装置、１ａ リクエスト発行画面、
１ｂ リクエスト管理画面、２ 検索条件管理ファイル、３ リクエスト発行手段、
４ リクエスト管理ファイル、５ リクエスト管理手段、６ 検索実行手段、
７ 外部アプリケーション、８ リクエスト受付制御手段、
９ リクエスト受付制御フラグ、１０ 強制バッチ検索実行テーブル取得手段、
１１ 強制バッチ検索実行テーブル一覧、１２ 検索対象データベース、
１３ 補助検索情報設定ファイル、１４ 検索結果取得手段、２１ 検索条件表示領域、２２ 削除ボタン、２３ 変更ボタン、２４ リクエスト発行ボタン、
２５ 検索方式選択領域、４０１ オブジェクトＩＤ、４０２ タイトル、
４０３ リクエスト処理状態、４０４ ユーザＩＤ、４０５ ユーザ名、
４０６ 登録日時、４０７ 開始時刻、４０８ 終了時刻、４１０ 検索結果件数、
４１１ 検索結果データ、４２０ 検索処理状態、４３０ ダウンロードボタン、
４３１ 削除ボタン、４３２ 変更ボタン、４３３ 戻るボタン、４３４ 終了ボタン。

Claims (9)

1. データベースの検索処理を行う検索処理装置において、
   検索条件を指定して上記検索処理のリクエストを発行するリクエスト発行手段と、
   すべてのリクエストについての検索動作を定義する補助検索情報設定ファイルと、
   上記リクエストをリクエスト管理ファイルに登録、管理するリクエスト管理手段と、
   上記リクエスト管理ファイルに記録された各リクエストの内容を元に、検索対象テーブルに対する即時検索又はバッチ検索を実施する検索実行手段とを備え、
   上記補助検索情報設定ファイルは上記バッチ検索を強制的に終了する終了時刻を有することを特徴とする検索処理装置。
2. 上記リクエスト管理手段は、リクエストの処理状態、検索の処理状態、検索結果を上記リクエスト管理ファイルに格納することを特徴とする請求項１に記載の検索処理装置。
3. 上記リクエストに従ってする上記検索処理の実行の可否、及び新規リクエストの上記リクエスト管理ファイルへの登録の可否を、リクエスト受付制御フラグの値に従って制御するリクエスト受付制御手段を備えたことを特徴とする請求項１又は請求項２に記載の検索処理装置。
4. 強制的に上記バッチ検索を実行させる対象テーブルを記載する、強制バッチ検索実行テーブル一覧から対象テーブル名を取得する強制バッチ検索実行テーブル取得手段を備え、
   上記リクエストの上記検索条件の中に、上記対象テーブル名が含まれる場合は、強制的に上記バッチ検索のみを選択可能とする請求項１乃至請求項３のいずれか１項に記載の検索処理装置。
5. 上記検索実行手段は、上記リクエスト管理ファイルに記録した個別のリクエストを識別する識別子をもとに、データベース検索結果の格納場所を決定することを特徴とする請求項１乃至請求項４のいずれか１項に記載の検索処理装置。
6. 上記検索実行手段は、上記識別子をもとに検索条件管理ファイルから上記検索条件を取得することを特徴とする請求項５に記載の検索処理装置。
7. 上記補助検索情報設定ファイルには、同時に起動できる上記検索実行手段の数を含むことを特徴とする請求項１乃至請求項６のいずれか１項に記載の検索処理装置。
8. 上記補助検索情報設定ファイルには、上記検索実行手段が強制的にバッチ検索対象に含める検索対象テーブルの外部結合の閾値を含むことを特徴とする請求項１乃至請求項７のいずれか１項に記載の検索処理装置。
9. 上記補助検索情報設定ファイルには、１ユーザが発行できるリクエスト数の上限値又は上記バッチ検索処理装置全体で登録できるリクエストの上限値の少なくともいずれか一方が含まれることを特徴とする請求項１乃至請求項８のいずれか１項に記載の検索処理装置。

Images