(57)【要約】【課題】  バッチの処理結果に基づいて遂行される後続業務を信頼性高く支援し得る情報処理装置及び方法を提案する。【解決手段】  登録された各バッチをそれぞれ実行し、実行したバッチの処理結果をそれぞれ対応するデータマートに格納する情報処理装置及び方法において、各データマートの各レコードに対してそれぞれ重要度を設定し、バッチが処理時に参照するデータの変更を検出した場合に、当該データの変更が後続業務に与える影響度を算出し、変更されたデータを参照するバッチの処理結果が格納されるデータマートの各レコードにそれぞれ設定された重要度と、算出した影響度とに基づいて、影響度が許容範囲内にあるか否かを当該データマートのレコードごとにそれぞれ判定し、いずれかのレコードの影響度が許容範囲を超えている場合に、当該データの変更を当該データマートに反映させるようにした。【選択図】        図３０
2019091197.tif 000002
【特許請求の範囲】
【請求項１】
登録された各バッチをそれぞれ実行し、実行したバッチの処理結果をそれぞれ対応するデータマートに格納する情報処理装置において、
各前記データマートの各レコードに対してそれぞれ重要度を設定する重要度設定部と、
各前記バッチが処理時にそれぞれ参照するデータを監視し、いずれかの前記データが変更された場合に当該変更を検出する変更検出部と、
前記変更検出部がいずれかの前記データの変更を検出した場合に、当該データの変更が後続業務に与える影響度を算出する影響度算出部と、
変更された前記データを参照する前記バッチの処理結果が格納される前記データマートの各前記レコードにそれぞれ設定された前記重要度と、前記影響度算出部により算出された前記影響度とに基づいて、必要に応じて当該データの変更を当該データマートに反映させるバッチ制御部と
を備え、
前記重要度ごとにそれぞれ前記影響度の許容範囲が予め設定され、
前記バッチ制御部は、
前記データを参照する前記バッチの処理結果が格納される前記データマートの各前記レコードにそれぞれ設定された前記重要度と、前記影響度算出部により算出された前記影響度とに基づいて、前記影響度が前記許容範囲内にあるか否かを当該データマートの前記レコードごとにそれぞれ判定し、いずれかの前記レコードの前記影響度が前記許容範囲を超えている場合に、当該データの変更を当該データマートに反映させる
ことを特徴とする情報処理装置。
【請求項２】
前記バッチ制御部は、
前記データマートのいずれかの前記レコードの前記影響度が前記許容範囲を超えている場合には、当該データマートに処理結果を格納する前記バッチを再実行させることにより、当該バッチが参照する前記データの変更を当該データマートに反映させる
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記バッチ制御部は、
前記データマートのいずれの前記レコードも前記影響度が前記許容範囲を超えていない場合には、当該バッチを再実行したとしても、登録された他のすべての前記バッチが当該バッチについて設定された完了期限に間に合う場合に当該バッチを再実行させる
ことを特徴とする請求項２に記載の情報処理装置。
【請求項４】
登録された各前記バッチの実行スケジュールを管理するバッチスケジュール管理部を備え、
前記バッチ制御部は、
前記変更検出部がいずれかの前記データの変更を検出した場合に、当該データを参照する前記バッチを再実行する空き時間が存在するか否かを前記バッチスケジュール管理部に問い合わせ、
前記バッチスケジュール管理部は、
前記バッチ制御部から問い合わされた前記バッチを再実行する前記空き時間が存在しない場合には、登録された他の前記バッチの実行時間を当該バッチについて設定された前記完了期限を含む実行条件の範囲内において遅延させることにより前記バッチ制御部から問い合わされた前記バッチを再実行するための前記空き時間を捻出し、捻出した前記空き時間に当該バッチを再実行させるよう前記実行スケジュールを更新する
ことを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記重要度設定部は、
各前記データマートの各レコードの前記重要度を、当該レコードに格納された前記データに関する経時的に変化する所定値に基づいて設定し、
設定した前記レコードごとの前記重要度を定期的に更新する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項６】
各前記バッチの処理内容に応じた複数種類の影響度算出ルールが予め登録され、
前記影響度算出部は、
前記バッチの登録の際に当該バッチについて設定された前記影響度算出ルールに従って当該バッチの前記影響度を算出する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項７】
登録された各バッチをそれぞれ実行し、実行したバッチの処理結果をそれぞれ対応するデータマートに格納する情報処理装置により実行される情報処理方法において、
各前記データマートの各レコードに対してそれぞれ重要度を設定する第１のステップと、
各前記バッチが処理時にそれぞれ参照するデータを監視し、いずれかの前記データの変更を検出した場合に、当該データの変更が後続業務に与える影響度を算出する第２のステップと、
変更された前記データを参照する前記バッチの処理結果が格納される前記データマートの各前記レコードにそれぞれ設定した前記重要度と、算出した前記影響度とに基づいて、必要に応じて当該データの変更を当該データマートに反映させる第３のステップと
を備え、
前記重要度ごとにそれぞれ前記影響度の許容範囲が予め設定され、
前記第３のステップにおいて、前記情報処理装置は、
前記データを参照する前記バッチの処理結果が格納される前記データマートの各前記レコードにそれぞれ設定された前記重要度と、算出した前記影響度とに基づいて、前記影響度が前記許容範囲内にあるか否かを当該データマートの前記レコードごとにそれぞれ判定し、いずれかの前記レコードの前記影響度が前記許容範囲を超えている場合に、当該データの変更を当該データマートに反映させる
ことを特徴とする情報処理方法。
【請求項８】
前記第３のステップにおいて、前記情報処理装置は、
前記データマートのいずれかの前記レコードの前記影響度が前記許容範囲を超えている場合には、当該データマートに処理結果を格納する前記バッチを再実行させることにより、当該バッチが参照する前記データの変更を当該データマートに反映させる
ことを特徴とする請求項７に記載の情報処理方法。
【請求項９】
前記第３のステップにおいて、前記情報処理装置は、
前記データマートのいずれの前記レコードも前記影響度が前記許容範囲を超えていない場合には、当該バッチを再実行したとしても、登録された他のすべての前記バッチが当該バッチについて設定された完了期限に間に合う場合に当該バッチを再実行させる
ことを特徴とする請求項８に記載の情報処理方法。
【請求項１０】
前記情報処理装置は、
登録された各前記バッチの実行スケジュールを管理し、
前記第３のステップにおいて、前記情報処理装置は、
いずれかの前記データの変更を検出した場合に、当該データを参照する前記バッチを再実行する空き時間が存在するか否かを前記実行スケジュールに基づいて判定し、
当該バッチを再実行する前記空き時間が存在しない場合には、登録された他の前記バッチの実行時間を当該バッチについて設定された前記完了期限を含む実行条件の範囲内において遅延させることにより、変更された前記データを参照する前記バッチを再実行するための前記空き時間を捻出し、捻出した前記空き時間に当該バッチを再実行させるよう前記実行スケジュールを更新する
ことを特徴とする請求項９に記載の情報処理方法。
【請求項１１】
前記情報処理装置は、
各前記データマートの各レコードの前記重要度を、当該レコードに格納された前記データに関する経時的に変化する所定値に基づいて設定し、
設定した前記レコードごとの前記重要度を定期的に更新する
ことを特徴とする請求項７に記載の情報処理方法。
【請求項１２】
各前記バッチの処理内容に応じた複数種類の影響度算出ルールが予め登録され、
前記第２のステップにおいて、前記情報処理装置は、
前記バッチの登録の際に当該バッチについて設定された前記影響度算出ルールに従って当該バッチの前記影響度を算出する
ことを特徴とする請求項７に記載の情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置及び方法に関し、例えば、店舗管理システムに適用して好適なものである。
【背景技術】
【０００２】
コンビニエンスストアなどの複数の店舗を展開する企業では、各店舗にそれぞれ設置された店舗端末からその店舗における売上実績を表す販売データが本部に設置された本部システムに日々送信される。そして本部システム側では、これらの販売データを参照する（入力とする）定期的なバッチ処理を実行することにより、店舗ごと、商品ごとの日別売上や販売実績などの集計データをそれぞれ生成し、生成したこれら集計データをそれぞれ異なるデータマートに格納して管理している。このようにして生成されたこれらのデータマートに格納された集計データは、この後、本部の経理部門における売上管理や、企画部門における販売企画などに活用される。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００８−９７４７６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、本部システムにおいて、あるバッチの処理が開始された後に当該バッチが参照する販売データやデータマートのデータ（以下、これらを元データと呼ぶ）が変更、追加又は削除された場合を考える。このような状況は、バッチ処理の開始後に店舗の担当者が入力ミスを修正した場合や、バッチ処理の開始後に返品があった場合などに発生する。
【０００５】
この場合、本部システム側では、変更等があった元データを参照するバッチを再実行する必要があるが、再実行によってそのバッチの完了時刻が遅れるため、当該バッチの処理結果を利用する後続の業務（経理部や企画部等における業務であり、以下、これを後続業務と呼ぶ）の開始時間までにそのバッチを完了させられない場合があった。
【０００６】
この点について、例えば、特許文献１には、バッチ対象データが確定していない状態でも、バッチ対象データが発生した段階でそのデータをロット化してバッチ処理を実行することにより、バッチ処理の終了時間を早め得る発明が開示されている。
【０００７】
しかしながら、元データが変更等されたとしても、そもそもその変更等が後続業務に与える影響が小さい場合には、その元データを参照して処理を行うバッチを再実行する必要はない。よって、元データが変更等された場合、その変更等が後続業務に与える影響が大きい場合にのみそのバッチを再実行すればよい。ところが、元データの変更等が後続業務に与える影響の大きさを判断することは難しく、元データの変更等があった場合における対応するバッチの再実行の要否を容易には判断し得ない問題があった。
【０００８】
従って、元データの変更等があった場合に、本部システム側において、その変更等が後続業務に与える影響を判定すると共に、判定結果に基づいて対応するバッチの再実行の要否を判断し、本当に必要なバッチのみを再実行するようにできれば、バッチの再実行に起因して後続業務の開始時刻までにバッチ処理が完了しないといった事態の発生を極力抑制でき、後続業務の遂行を信頼性高く支援し得るものと考えられる。また、このような方法により、元データの変更が後続業務に与える影響を確認する作業も不要となり、システム管理者や後続業務担当者の負担を軽減させ得るものと考えられる。
【０００９】
本発明は以上の点を考慮してなされたもので、バッチの処理結果に基づいて遂行される後続業務を信頼性高く支援し得る情報処理装置及び方法を提案しようとするものである。
【課題を解決するための手段】
【００１０】
かかる課題を解決するため本発明においては、登録された各バッチをそれぞれ実行し、実行したバッチの処理結果をそれぞれ対応するデータマートに格納する情報処理装置において、各前記データマートの各レコードに対してそれぞれ重要度を設定する重要度設定部と、各前記バッチが処理時にそれぞれ参照するデータを監視し、いずれかの前記データが変更された場合に当該変更を検出する変更検出部と、前記変更検出部がいずれかの前記データの変更を検出した場合に、当該データの変更が後続業務に与える影響度を算出する影響度算出部と、変更された前記データを参照する前記バッチの処理結果が格納される前記データマートの各前記レコードにそれぞれ設定された前記重要度と、前記影響度算出部により算出された前記影響度とに基づいて、必要に応じて当該データの変更を当該データマートに反映させるバッチ制御部とを設け、前記重要度ごとにそれぞれ前記影響度の許容範囲が予め設定され、前記バッチ制御部が、前記データを参照する前記バッチの処理結果が格納される前記データマートの各前記レコードにそれぞれ設定された前記重要度と、前記影響度算出部により算出された前記影響度とに基づいて、前記影響度が前記許容範囲内にあるか否かを当該データマートの前記レコードごとにそれぞれ判定し、いずれかの前記レコードの前記影響度が前記許容範囲を超えている場合に、当該データの変更を当該データマートに反映させるようにした。
【００１１】
また本発明においては、登録された各バッチをそれぞれ実行し、実行したバッチの処理結果をそれぞれ対応するデータマートに格納する情報処理装置により実行される情報処理方法において、各前記データマートの各レコードに対してそれぞれ重要度を設定する第１のステップと、各前記バッチが処理時にそれぞれ参照するデータを監視し、いずれかの前記データの変更を検出した場合に、当該データの変更が後続業務に与える影響度を算出する第２のステップと、変更された前記データを参照する前記バッチの処理結果が格納される前記データマートの各前記レコードにそれぞれ設定した前記重要度と、算出した前記影響度とに基づいて、必要に応じて当該データの変更を当該データマートに反映させる第３のステップとを設け、前記重要度ごとにそれぞれ前記影響度の許容範囲が予め設定され、前記第３のステップにおいて、前記情報処理装置が、前記データを参照する前記バッチの処理結果が格納される前記データマートの各前記レコードにそれぞれ設定された前記重要度と、算出した前記影響度とに基づいて、前記影響度が前記許容範囲内にあるか否かを当該データマートの前記レコードごとにそれぞれ判定し、いずれかの前記レコードの前記影響度が前記許容範囲を超えている場合に、当該データの変更を当該データマートに反映させるようにした。
【００１２】
本情報処理装置及び方法によれば、バッチが参照するデータが更新された場合に、その変更が後続業務に与える影響が大きい場合にのみ、そのデータの変更が対応するデータマートに反映され、その変更が後続業務に与える影響が小さい場合には、そのデータの変更がそのデータマートに反映されない。従って、本当に必要な場合にのみ、かかるデータの変更が対応するデータマートに反映されることになるため、かかるデータの変更を対応するデータマートに反映させる処理が、後続業務の開始に間に合わないといった事態の発生を極力抑制することができる。
【発明の効果】
【００１３】
本発明によれば、バッチの処理結果に基づいて遂行される後続業務を信頼性高く支援し得る情報処理装置及び方法を実現できる。
【図面の簡単な説明】
【００１４】
【図１】本実施の形態による店舗管理システムの全体構成を示すブロック図である。
【図２】本店舗管理システムにおける業務の流れの説明に供するブロック図である。
【図３】（Ａ）は販売データの構成、（Ｂ）は日別売上マート、（Ｃ）は販売実績マート、（Ｄ）は人気商品マート、（Ｅ）は売上順位マートをそれぞれ示す図表である。
【図４】（Ａ）〜（Ｃ）は影響度算出ルールの説明に供する図表である。
【図５】（Ａ）〜（Ｃ）は影響度算出ルールの説明に供する図表である。
【図６】（Ａ）〜（Ｃ）は影響度算出ルールの説明に供する図表である。
【図７】アプリケーションサーバの論理構成を示すブロック図である。
【図８】アプリケーションサーバの論理構成を示すブロック図である。
【図９】影響度算出ルール決定テーブルの構成例を示す図表である。
【図１０】重要度設定ルール決定テーブルの構成例を示す図表である。
【図１１】担当者連絡先テーブルの構成例を示す図表である。
【図１２】入出力管理テーブルの構成例を示す図表である。
【図１３】バッチ実行条件管理テーブルの構成例を示す図表である。
【図１４】バッチ実行スケジュールテーブルの構成例を示す図表である。
【図１５】バッチ優先順位管理テーブルの構成例を示す図表である。
【図１６】リソース管理テーブルの構成例を示す図表である。
【図１７】バッチ実行履歴管理テーブルの構成例を示す図表である。
【図１８】マート参照履歴管理テーブルの構成例を示す図表である。
【図１９】参照頻度管理テーブルの構成例を示す図表である。
【図２０】重要度管理テーブルの構成例を示す図表である。
【図２１】バッチ登録画面の構成例を示す図である。
【図２２】重要度設定ルール決定画面の構成例を示す図である。
【図２３】担当者連絡先登録画面の構成例を示す図である。
【図２４】第１の新規バッチ登録処理の処理手順を示すフローチャートである。
【図２５】第２の新規バッチ登録処理の処理手順を示すフローチャートである。
【図２６】通常運行処理の処理手順を示すフローチャートである。
【図２７】重要度管理テーブル更新処理の処理手順を示すフローチャートである。
【図２８】算出用テーブルの構成例を示す図表である。
【図２９】変更検出処理の処理手順を示すフローチャートである。
【図３０】バッチ再実行処理の処理手順を示すフローチャートである。
【図３１】空き時間探索処理の処理手順を示すフローチャートである。
【図３２】影響度算出処理の処理手順を示すフローチャートである。
【発明を実施するための形態】
【００１５】
以下図面について、本発明の一実施の形態を詳述する。
【００１６】
（１）本実施の形態による店舗管理システムの構成
図１において、１は全体として本実施の形態による店舗管理システムを示す。この店舗管理システム１は、コンビニエンスストアやファミリーレストランなどの複数の店舗２を営業する企業において、各店舗２の売上等を管理するために利用されるシステムである。
【００１７】
この店舗管理システム１は、各店舗２にそれぞれ設置された店舗端末３と、本部に設置されたウェブサーバ４、アプリケーションサーバ５、データベースサーバ６及び複数のホスト装置７からなる本部システム８とを備えて構成される。
【００１８】
店舗端末３は、その店舗２における売上状況を管理するために利用されるＰＯＳ（Point Of Sales）端末などのコンピュータ装置であり、ＣＰＵ（Central Processing Unit）１０、メモリ１１、記憶装置１２及び通信装置１３などを備えて構成される。
【００１９】
ＣＰＵ１０は、店舗端末３全体の動作制御を司るプロセッサである。またメモリ１１は、必要なプログラムを一時的に保持するために利用されるほか、ＣＰＵ１０のワークメモリとしても利用される。メモリ１１に格納されたプログラムをＣＰＵ１０が実行することにより、店舗端末３全体としての各種処理が行われる。
【００２０】
また記憶装置１２は、例えばハードディスク装置やＳＳＤ（Solid State Drive）などの大容量の不揮発性記憶装置から構成され、プログラムや日々の販売データ１４などの必要な情報を長期間保持するために利用される。さらに通信装置１３は、ＮＩＣ（Network Interface Card）などから構成され、本部システム８との通信時におけるプロトコル制御を行う。
【００２１】
ウェブサーバ４は、各店舗２の店舗端末３とインターネットなどから構成されるネットワーク９Ａを介して接続され、これら店舗端末３から日々送信されてくる毎日の販売実績を表す販売データ１４をアプリケーションサーバ５に転送する機能を有する汎用のサーバ装置である。ウェブサーバ４は、ＣＰＵ２０、メモリ２１、記憶装置２２及び通信装置２３等の情報処理資源を備えて構成される。これらＣＰＵ２０、メモリ２１及び記憶装置２２及び通信装置２３は、店舗端末３のＣＰＵ１０、メモリ１１、記憶装置１２及び通信装置１３とほぼ同様の機能及び構成を有するものであるため、ここでの説明は省略する。
【００２２】
アプリケーションサーバ５は、インストールされたアプリケーションプログラム３４（図７）に従った各種処理を実行する機能を有するサーバ装置である。アプリケーションサーバ５は、ＣＰＵ３０、メモリ３１、記憶装置３２及び通信装置３３等の情報処理資源を備える汎用のサーバ装置から構成される。ＣＰＵ３０、メモリ３１、記憶装置３２及び通信装置３３は、ウェブサーバ４のＣＰＵ２０、メモリ２１、記憶装置２２及び通信装置２３とほぼ同様の機能及び構成を有するものであるため、ここでの説明は省略する。
【００２３】
アプリケーションサーバ５のメモリ３１には、アプリケーションプログラム３４（図７）のほか、本部の各部門の担当者によりそれぞれ登録された複数のバッチ３５（図７）が格納される。アプリケーションプログラム３４は、各店舗端末３からウェブサーバ４を介して転送されてきた販売データ１４をデータベースサーバ６が保持するデータベース４０に格納したり、データベースサーバ６が保持するデータマート４１に格納されたデータをホスト装置７からの要求に応じて読み出してそのホスト装置７に転送する機能を有するプログラムである。またバッチ３５は、１つ以上のデータを入力して処理を実行し、その処理結果に基づいて１つ以上のデータマート４１を更新するプログラムである。
【００２４】
データベースサーバ６は、データベース４０を管理及び保持する機能を有するサーバ装置である。データベースサーバ６は、ＣＰＵ、メモリ、記憶装置及び通信装置（いずれも図示せず）等の情報処理資源を備える汎用のサーバ装置から構成される。これらＣＰＵ、メモリ、記憶装置及び通信装置は、ウェブサーバ４のＣＰＵ２０、メモリ２１、記憶装置２２及び通信装置２３とほぼ同様の機能及び構成を有するものであるため、ここでの説明は省略する。データベースサーバ６の記憶装置には、各店舗２からの販売データ１４が登録されるデータベース４０と、各バッチ３５（図７）の処理結果がそれぞれ登録される複数のデータマート４１となどが格納される。
【００２５】
ホスト装置７は、本部の経理部、企画部及び総務部などの各部門の担当者にそれぞれ貸与されたコンピュータ装置であり、それぞれ社内ＬＡＮ（Local Area Network）などのネットワーク９Ｂを介してアプリケーションサーバ５と接続されている。各部門の担当者は、自己のホスト装置７を用いてアプリケーションサーバ５にアクセスし、当該アプリケーションサーバ５に所定の処理を実行するバッチ３５（図７）を登録したり、所望するデータマート４１のデータをアプリケーションサーバ５を介してデータベースサーバ６から取得する。
【００２６】
（２）本実施の形態によるバッチ管理機能
次に、本実施の形態のアプリケーションサーバ５に搭載されたバッチ管理機能について説明する。これに際して、まず、本店舗管理システム１における業務の流れについて、図２を参照して説明する。
【００２７】
本店舗管理システム１において、各店舗２の担当者４５は、売上に関する情報（売上情報）を逐次店舗端末３に入力する。そして店舗端末３は、入力された売上情報に基づいて例えば図３（Ａ）に示すような販売データ１４を日々生成し、生成した販売データ１４をその店舗端末３内の記憶装置１２（図１）に格納する。また店舗端末３は、記憶装置１２に格納している販売データ１４を毎日定時にネットワーク９Ａを介して本部システム８に送信する。
【００２８】
本部システム８側では、各店舗端末３からそれぞれ送信されてきた販売データ１４がウェブサーバ４（図１）を介してアプリケーションサーバ５に与えられる。そしてアプリケーションサーバ５は、これら販売データ１４をデータベースサーバ６（図１）が保持するデータベース４０（図１）に格納して管理する。またアプリケーションサーバ５は、予め本部の各部門の担当者４６Ａ〜４６Ｃによりそれぞれ登録された各バッチ３５（図７）の実行タイミングをそれぞれ規定したスケジュール（以下、これをバッチ実行スケジュールと呼ぶ）を作成し、当該バッチ実行スケジュールに従って各バッチ３５をそれぞれ実行する。
【００２９】
ここでは、アプリケーションサーバ５に、経理部の担当者４６Ａにより作成された第１の集計バッチ３５Ａ（「集計バッチ１」）と、企画部の担当者４６Ｂにより作成された第２及び第３の集計バッチ３５Ｂ，３５Ｃ（「集計バッチ２」及び「集計バッチ３」）と、総務部の担当者４６Ｃにより作成された第４の集計バッチ３５Ｄ（「集計バッチ４」）とが登録されているものとする。
【００３０】
第１の集計バッチ３５Ａは、各店舗２の日々の売上をそれぞれ集計するバッチであり、この第１の集計バッチ３５Ａにより店舗２ごとの日別の売上が算出され、算出結果をデータベースサーバ６が保持する例えば図３（Ｂ）に示すような構成のデータマート４１（日別売上マート４１Ａ）に格納される。かくして、経理部の担当者４６Ａは、自己のホスト装置７（図１）を用いてこの日別売上マート４１Ａに格納された各店舗の日別の売上データを取得し、取得した売上データに基づいて各店舗２の毎日の売上を管理する業務を行う。
【００３１】
また第２の集計バッチ３５Ｂは、商品ごとの販売実績を集計するためのバッチであり、この第２の集計バッチ３５Ｂにより日別の商品ごとの販売数が算出され、算出結果をデータベースサーバ６が保持する例えば図３（Ｃ）に示すようなデータマート４１（販売実績マート４１Ｂ）に格納される。かくして企画部の担当者４６Ｂは、自己のホスト装置７を用いてこの販売実績マート４１Ｂに格納された商品ごとの販売数を取得し、取得した商品ごとの販売数に基づいて、例えば各店舗２が販売強化指定商品の販売ノルマを達成しているか否かを管理したり、各店舗２に対する各商品の出荷数量を調整するなどの業務を行う。
【００３２】
さらに第３の集計バッチ３５Ｃは、各店舗２の人気商品を特定するバッチであり、この第３の集計バッチ３５Ｃにより各店舗２において販売数が最も多い商品が抽出され、抽出結果をデータベースサーバ６が保持する例えば図３（Ｄ）に示すようなデータマート４１（人気商品マート４１Ｃ）に格納される。かくして企画部の担当者４６Ｂは、自己のホスト装置７を用いてこの人気商品マート４１Ｃに格納された店舗ごとの最も販売数が多い商品を取得し、取得したこの情報に基づいて販売キャンペーンを企画するなどの業務を行う。
【００３３】
さらに第４の集計バッチ３５Ｄは、店舗２の売上ランキングを算出するバッチであり、この第４の集計バッチにより売上の多い順に店舗２がソートされ、そのソート結果をデータベースサーバ６が保持する例えば図３（Ｅ）に示すようなデータマート４１（売上順位マート４１Ｄ）に格納される。かくして総務部の担当者４６Ｃは、自己のホスト装置７を用いてこの店舗売上順位マート４１Ｄに格納された各店舗２の売上ランキングの情報を取得し、取得したこの情報に基づいて売上が多い上位数店舗を表彰するなどの業務を行う。
【００３４】
ところで、上述の第１〜第４の集計バッチ３５Ａ〜３５Ｄの処理開始後にその第１〜第４の集計バッチ３５Ａ〜３５Ｄが参照する販売データ１４が変更された場合に、常にその第１〜第４の集計バッチ３５Ａ〜３５Ｄを再実行するものとすると、その第１〜第４の集計バッチ３５Ａ〜３５Ｄの完了が後続業務（管理部、企画部又は総務部などの業務）の開始時刻に間に合わなくなる場合がある。
【００３５】
また、その再実行すべきバッチ（第１のバッチとする）の処理結果を第２のバッチが利用し、第２のバッチの処理結果を第３のバッチが利用し、……というように複数のバッチが数珠繋ぎに実行されるような設定がなされている場合（以下、第２のバッチ以降の各バッチを、適宜、第１のバッチの後続バッチと呼ぶ）、後続バッチ３５を特定したり、どの後続バッチ３５まで再実行すべきかを判断することも難しい。
【００３６】
そこで本店舗管理システム１では、バッチ３５（図７）の処理開始後にそのバッチ３５が参照する販売データ１４やデータマート４１のデータ（元データ）が変更された場合に、そのバッチ３５の後続バッチ３５を特定し、これらバッチ３５及び後続バッチ３５について、元データの変更の後続業務への影響度を算出し、算出した影響度の大きさを評価し、その評価結果に基づいてそのバッチ３５や後続バッチ３５を再実行するか否かを判定するバッチ管理機能がアプリケーションサーバ５に搭載されている。
【００３７】
実際上、アプリケーションサーバ５は、自己に登録された各バッチ３５がそれぞれ参照（入力）するデータと、処理結果を格納（出力）するデータマート４１とを図１２について後述する入出力管理テーブル６３に登録して管理している。またアプリケーションサーバ５は、データベースサーバ６が保持するデータベース４０（図１）に格納された各店舗２からの販売データ１４と、各データマート４１（図１）の各レコードのデータとをそれぞれ監視している。
【００３８】
そしてアプリケーションサーバ５は、これら販売データ１４及び各データマート４１のデータのうちのいずれかのデータが変更された場合に、その変更されたデータを参照する（そのデータを元データとして入力とする）すべてのバッチ３５及びその後続バッチ３５をかかる入出力管理テーブル６３を参照して特定する。またアプリケーションサーバ５は、特定した各バッチ３５及びその後続バッチ３５を再実行するための空き時間があるか否かを、バッチ実行スケジュールを参照して判定する。以下においては、この判定をスケジュール空き判定と呼ぶものとする。
【００３９】
またアプリケーションサーバ５は、かかるスケジュール空き判定と並行して、かかる元データの変更が後続業務に与える影響度が許容範囲内であるか否かを、当該元データを参照して処理を実行するバッチ３５の処理結果が格納されるデータマート４１のレコードごとにそれぞれ判定（以下、この判定を影響度判定と呼ぶ）する。
【００４０】
このような影響度判定を行うための手段として、アプリケーションサーバ５には、各バッチ３５の処理内容に応じた複数種類の影響度算出ルールが予め登録されている。そしてアプリケーションサーバ５は、影響度判定を行う場合、まず、かかる元データを参照するバッチ３５に対応付けられた影響度算出ルールに従って当該元データの変更が後続業務に与える影響度を算出する。
【００４１】
例えば、かかる元データを入力として実行されるバッチ３５が上述の第１の集計バッチ３５Ａや第２の集計バッチ３５Ｂであり、これら第１の集計バッチ３５Ａや第２の集計バッチ３５Ｂのように集計処理を含むバッチ３５に対して予め用意された影響度算出ルール（以下、これを第１の影響度算出ルールと呼ぶ）が、『変更された元データを参照して実行されるバッチの処理結果を格納するデータマートのレコードのデータについて、元データの変更に伴って変更される当該データの変更後の値と、当該データの変更前の値との差分の絶対値を当該データの変更前の値で除算（｜変更前の値−変更後の値｜／変更前の値）することにより、かかる影響度を算出する』というルールであるものとする。
【００４２】
また図４（Ａ）に示すように、「店舗１」という店舗２の販売データ１４における「2017/2/1 11:00」に販売された商品名「チョコレート」の販売数量が「２」から「３」に、また「2017/2/2 12:00」に販売された商品名「ビール」の単価が「200」から「300」に変更されたものとする。
【００４３】
この場合、対応するデータマート４１（日別売上マート４１Ａ）の内容が、図４（Ｂ）のように「2/1」の売上が「380,000円」、「2/2」の売上が「390,000円」となっている状態から、図４（Ｃ）のように「2/1」の売上が「380,800円」、「2/2」の売上が「390,100円」に変更されることになるため、かかる「2/1」の販売データ１４（元データ）の変更が後続業務に与える影響度は、次式
【数１】
2019091197.tif 000003
のように「0.002」と算出され、かかる「2/2」の販売データの変更が後続業務に与える影響度は、次式
【数２】
2019091197.tif 000004
のように「0.0002」と算出される。
【００４４】
また、かかる元データを参照するバッチ３５が上述の第３の集計バッチ３５Ｃであり、この第３の集計バッチ３５Ｃのように最大値を算出するバッチ３５に対して予め用意された影響度算出ルール（以下、これを第２の影響度算出ルールと呼ぶ）が、『元データの変更後に、当該元データの変更前の最大値を超えた最大値が算出される場合には第１の影響度算出ルールと同様の演算方法により影響度を算出し、これ以外の場合には影響度を常に「０」とする』というルールであるものとする。また図５（Ａ）に示すように、「店舗１」という店舗２の販売データにおける「2017/2/1 11:00」に販売された商品名「チョコレート」の販売数量が「２」から「５」に変更されたものとする。
【００４５】
この場合、対応するデータマート４１（人気商品マート４１Ｃ）の内容が図５（Ｂ）の状態から図５（Ｃ）に変更されることになる。従って、この場合における販売データ１４（元データ）の変更が後続業務に与える影響度は、次式
【数３】
2019091197.tif 000005
のように「0.00009」と算出される。
【００４６】
さらに、元データを参照するバッチ３５が上述の第４の集計バッチ３５Ｄであり、この第４の集計バッチ３５Ｄのように並替え処理を含むバッチ３５に対して予め用意された影響度算出ルール（以下、これを第３の影響度算出ルールと呼ぶ）が、『元データの変更後に値が変更されるデータマートのレコードの変更前の順位ｎと、当該レコードの変更後の順位ｍとの差分の絶対値を変更後の当該データマートの全体の行数Ｓで除算（｜ｎ−ｍ｜／Ｓ）することにより、かかる影響度を算出する』というルールであるものとする。
【００４７】
また図６（Ａ）に示すように、「店舗１」の販売データ１４における「2017/2/1 11:00」に販売された商品名「チョコレート」の販売数量が「２」から「３」に変更され、これに伴って、対応するデータマート４１（店舗売上順位マート４１Ｄ）の内容が図６（Ｂ）の状態から図６（Ｃ）に変更されることになるものとする。
【００４８】
この場合、元データの変更後に値が変更されるデータマート４１のレコードの変更前の順位ｎが「３」、当該レコードの変更後の順位ｍが「２」、当該データマート４１の全体の行数Ｓが「100」であるため、かかる元データの変更が後続業務に与える影響度は、次式
【数４】
2019091197.tif 000006
のように「0.01」と算出される。
【００４９】
一方、かかる元データの変更が後続業務に与える「影響度が許容範囲内」であるか否かの判定は、その元データを参照するバッチの処理結果が格納されるデータマート４１の各レコードのデータに対してそれぞれ設定されたそのデータの重要度に応じて行われる。本実施の形態の場合、このようにデータマート４１の各レコードのデータの重要度を設定するためのルール（以下、これを重要度設定ルールと呼ぶ）として、各種バッチの処理内容に応じた複数種類の重要度設定ルールが予め幾つかアプリケーションサーバ５に登録されている。
【００５０】
そして新たなバッチ３５（第１〜第４の集計バッチ３５Ａ〜３５Ｄ）をアプリケーションサーバ５に登録しようとする後続業務の担当者４６Ａ〜４６Ｃは、そのバッチ３５の処理結果が格納されるデータマート４１（４１Ａ〜４１Ｄ）の各レコードのデータの重要度をどの重要度設定ルールを用いて設定するかを、そのバッチ３５をアプリケーションサーバ５に登録する際に決定して設定する。
【００５１】
例えば、第１の集計バッチ３５Ａや第２の集計バッチ３５Ｂについて設定された重要度設定ルールが、『頻繁に参照されるレコードのデータの需要度を高く設定する』というルール（以下、これを第１の重要度設定ルールと呼ぶ）であるものとする。
【００５２】
この場合、アプリケーションサーバ５は、その第１の集計バッチ３５Ａや第２の集計バッチ３５Ｂの処理結果が格納される日別売上マート４１Ａ（図３（Ｂ））や販売実績マート４１Ｂ（図３（Ｃ））については、参照回数が多い上位20％の各レコードのデータの重要度をそれぞれ「Ａ」、参照回数が上位20〜40％の各レコードのデータの重要度をそれぞれ「Ｂ」、参照回数が上位40〜60％の各レコードのデータの重要度をそれぞれ「Ｃ」、参照回数が上位60〜100％の各レコードのデータの重要度をそれぞれ「Ｄ」、重要度が「Ａ」〜「Ｄ」のいずれにも該当しない（つまり一度も参照されたことがない）各レコードのデータの重要度をそれぞれ「Ｅ」のように、レコードごと（データごと）の重要度をそれぞれ設定する。
【００５３】
また、例えば、第３の集計バッチ３５Ｃや第４の集計バッチ３５Ｄについて設定された重要度設定ルールが、『他のレコードと数値の傾向が異なるレコードのデータの重要度を高く設定する』というルール（以下、これを第２の重要度設定ルールと呼ぶ）であるものとする。
【００５４】
この場合、アプリケーションサーバ５は、その第３の集計バッチ３５Ｃや第４の集計バッチ３５Ｄの処理結果が格納される人気商品マート４１Ｃ（図３（Ｄ））や売上順位マート４１Ｄ（図３（Ｅ））については、そのデータマート４１のレコードごとに、そのレコードの数値と、そのデータマート４１の各レコードの数値の平均値との差分の絶対値をそのレコードの偏差としてそれぞれ求め、偏差の大きい上位20％の各レコードのデータの重要度をそれぞれ「Ａ」、上位20〜40％の各レコードのデータの重要度をそれぞれ「Ｂ」、上位40〜60％の各レコードのデータの重要度をそれぞれ「Ｃ」、上位60〜100％の各レコードのデータの重要度をそれぞれ「Ｄ」のように、レコードごと（データごと）の重要度をそれぞれ設定する。
【００５５】
そしてアプリケーションサーバ５は、例えば、重要度が「Ａ」のレコードのデータについては、影響度が「０」以内の場合に「影響度が許容範囲内」であると判定し、重要度が「Ｂ」のレコードのデータについては、影響度が「0.5」以内の場合に「影響度が許容範囲内」であると判定する。またアプリケーションサーバ５は、重要度が「Ｃ」のレコードのデータについては、影響度が「１」以内の場合に「影響度が許容範囲内」であると判定し、重要度が「Ｄ」のレコードのデータについては、影響度が「10」以内の場合に「影響度が許容範囲内」であると判定する。さらにアプリケーションサーバ５は、重要度が「Ａ」〜「Ｄ」に該当しないレコードのデータについては、影響度の値に関わりなく（無制限）、常に「影響度が許容範囲内」であると判定する。
【００５６】
従って、第１の集計バッチ３５Ａや第２の集計バッチ３５Ｂについて上述したように、影響度が「0.002」と算出されたレコードのデータの重要度が「Ａ」であった場合には、元データの変更が後続業務に与える影響度は許容範囲を超えると判定され、当該データの重要度が「Ｂ」〜「Ｅ」であった場合には、元データの変更が後続業務に与える影響度は許容範囲内であるとの判定されることになる。
【００５７】
なお本実施の形態の場合、上述のようにデータマート４１の各レコードのデータの重要度がそのレコードのデータの参照回数や平均値からの偏差の大きさといった、経時的に変化する当該データに関する所定値に応じて設定されるため、各レコード（各データ）の重要度をなるべく最新の情報に基づいて設定する必要がある。このためアプリケーションサーバ５は、個々のレコード（データ）の重要度を定期的（例えば、毎日）に更新する。
【００５８】
そしてアプリケーションサーバ５は、上述のスケジュール空き判定の判定結果と、上述の影響度判定の判定結果とに基づいて、例えば、元データの変更が後続業務に与える影響度が許容範囲内にあるか否かを、元データの変更の影響を受けるデータマート４１（つまり元データを参照するバッチ３５の処理結果が登録されるデータマート４１）のレコードごとにそれぞれ判定する。そしてアプリケーションサーバ５は、かかる影響度が許容範囲を超えるレコードが存在する場合には、そのデータマート４１に処理結果を格納するバッチ３５を再実行すべきと判断する。
【００５９】
またアプリケーションサーバ５は、元データの変更により影響度が許容範囲を超えたレコードが存在しない場合でも、そのデータマート４１に処理結果を格納するバッチ３５を再実行できる空き時間があるときにはそのバッチ３５を再実行すべきと判断し、そのような空き時間がない場合にはそのバッチ３５を再実行すべきでないと判断する。
【００６０】
そしてアプリケーションサーバ５は、バッチ３５を再実行すべきと判断した場合には、そのバッチ３５の再実行するようバッチ実行スケジュールを変更し、変更したバッチ実行スケジュールに従ってそのバッチ３５を再実行する。
【００６１】
以上のような本実施の形態によるバッチ再実行要否判定機能を実現するための手段として、図７に示すように、アプリケーションサーバ５のメモリ３１には、バッチ解析部５０、バッチスケジュール管理部５１、履歴管理部５２、重要度設定部５３、変更検出部５４、影響度算出部５５、バッチ制御部５６及び反映通知部５７が格納されている。またアプリケーションサーバ５の記憶装置３２には、影響度算出ルール決定テーブル６０、重要度設定ルール決定テーブル６１、担当者連絡先テーブル６２、入出力管理テーブル６３、バッチ実行条件管理テーブル６４、バッチ実行スケジュールテーブル６５、バッチ優先順位管理テーブル６６、リソース管理テーブル６７、バッチ実行履歴管理テーブル６８、マート参照履歴管理テーブル６９、参照頻度管理テーブル７０及び重要度管理テーブル７１と、それぞれ複数の影響度算出ルール７２及び重要度設定ルール７３とが格納されている。
【００６２】
そして図８に示すように、バッチ解析部５０は、影響度算出ルール決定テーブル６０、重要度設定ルール決定テーブル６１、担当者連絡先テーブル６２及び入出力管理テーブル６３を管理し、バッチスケジュール管理部５１は、バッチ実行条件管理テーブル６４、バッチ実行スケジュールテーブル６５、バッチ優先順位管理テーブル６６及びリソース管理テーブル６７を管理している。また履歴管理部５２は、バッチ実行履歴管理テーブル６８及びマート参照履歴管理テーブル６９を管理し、重要度設定部５３は、参照頻度管理テーブル７０、重要度管理テーブル７１及びシステム管理者等により予め登録された幾つかの重要度設定ルール７３を管理し、影響度算出部５５は、システム管理者等により予め登録された幾つかの影響度算出ルール７２を管理している。
【００６３】
バッチ解析部５０は、後続業務の担当者がバッチ３５をアプリケーションサーバ５に登録する際に、そのバッチ３５の実行条件を入力させる機能を有するプログラムである。実際上、バッチ解析部５０は、後続業務の担当者がバッチ３５をアプリケーションサーバ５に登録する際、図２１について後述するバッチ登録画面８０をその担当者のホスト装置７に表示させる。
【００６４】
そしてバッチ解析部５０は、かかる担当者がこのバッチ登録画面８０を用いて登録したそのバッチの実行頻度（毎日、毎週又は毎月など）と、「午前０時以降に実行」、「バッチＡ完了後に開始」などのそのバッチ３５を開始するために満たすべき条件（以下、これを開始条件と呼ぶ）と、そのバッチ３５を完了させておかなければならない時刻などの条件（以下、これを完了条件と呼ぶ）と、そのバッチ３５を開始してから終了するまでに要すると想定される所要時間（以下、これを想定所要時間と呼ぶ）と、そのバッチ３５を実行するために割り当てるべきリソースとをそのバッチ３５の実行条件として取得し、取得したその実行条件をバッチ実行条件管理テーブル６４に登録する。
【００６５】
またバッチ解析部５０は、後続業務の担当者がバッチ３５をアプリケーションサーバ５に登録したときにそのバッチ３５の処理内容を解析し、そのバッチ３５に適用すべき上述の影響度算出ルール７２を決定する。例えば、バッチ解析部５０は、そのバッチ３５が実行するバッチ処理が集計処理を含む場合には上述の第１の影響度算出ルールを、またそのバッチ３５が実行するバッチ処理が最大値を算出する処理を含む場合には上述の第２の影響度算出ルールを、さらにそのバッチ３５が実行するバッチ処理がソート処理を含む場合には上述の第３の影響度算出ルールをそのバッチ３５に適用すべき影響度算出ルール７２として決定する。そしてバッチ解析部５０は、決定した影響度算出ルール７２をそのバッチ３５と対応付けて影響度算出ルール決定テーブル６０に登録する。
【００６６】
さらにバッチ解析部５０は、後続業務の担当者がバッチ３５をアプリケーションサーバ５に登録する際、図２２について後述する重要度設定ルール決定画面９０と、図２３について後述する担当者連絡先登録画面１００とを順番にその担当者のホスト装置７に表示させる。そしてバッチ解析部５０は、重要度設定ルール決定画面９０を用いて担当者により設定されたそのバッチ３５に適用すべき上述の重要度設定ルールを重要度設定ルール決定テーブル６１に登録して管理する。またバッチ解析部５０は、担当者連絡先登録画面１００を用いて担当者により登録されたその担当者の連絡先を担当者連絡先テーブル６２に登録して管理する。
【００６７】
加えて、バッチ解析部５０は、アプリケーションサーバ５にバッチ３５が登録されるごとに、そのバッチ３５が参照するテーブル（データベース４０又はデータマート４１）と、処理結果を格納するデータマート４１とを特定し、特定結果を入出力管理テーブル６３に登録して管理する。そしてバッチ解析部５０は、例えば、販売データ１４やデータマート４１（元データ）が変更されたときに、後述のようなバッチ制御部５６からの要求に応じて、かかる入出力管理テーブル６３を参照してその変更の影響を受けるバッチ３５やデータマート４１のレコードを特定する。
【００６８】
バッチスケジュール管理部５１は、上述のバッチ実行スケジュールを作成して管理する機能を有するプログラムである。実際上、バッチスケジュール管理部５１は、後続業務の担当者により新たなバッチ３５がアプリケーションサーバ５に登録された場合、上述したそのバッチ３５の実行条件と、図１５について後述する各バッチ３５の優先順位とに基づいてそのバッチ３５の実行タイミングを決定し、決定した実行タイミングをバッチ実行スケジュールテーブル６５に登録して管理する。なおバッチスケジュール管理部５１は、かかるシステム管理者等により設定されたアプリケーションサーバ５に登録された各バッチ３５の優先順位をバッチ優先順位管理テーブル６６に登録して管理する。
【００６９】
またバッチスケジュール管理部５１は、アプリケーションサーバ５のリソースをリソース管理テーブル６７に登録して管理しており、後述のようにバッチ制御部５６からバッチ３５を指定してその再実行が可能であるか否かの問い合わせが与えられた場合には、かかるリソース管理テーブル６７と、バッチ実行スケジュールテーブル６５とを参照して、リソース的及び時間的にそのバッチ３５を再実行できるか否かを判定し、判定結果をバッチ制御部５６に通知する。この場合、バッチスケジュール管理部５１は、そのバッチ３５の再実行が可能であると判定した場合には、そのバッチ３５の再実行するための実行スケジュールを組み込むようバッチ実行スケジュールを更新（つまりその実行スケジュールをバッチ実行スケジュールテーブル６５に登録）する。
【００７０】
履歴管理部５２は、アプリケーションサーバ５に登録された各バッチ３５の実行履歴や、後続業務の担当者が自己のホスト装置７を用いてアプリケーションサーバ５を介して行ったデータマート４１の各レコードの参照履歴を管理する機能を有するプログラムである。履歴管理部５２は、アプリケーションサーバ５に登録されたバッチ３５が実行されるごとに、そのバッチ３５の実行履歴をバッチ実行履歴管理テーブル６８に登録して管理すると共に、いずれかのデータマート４１のレコードのデータが後続業務の担当者により参照されるごとに、その参照履歴をマート参照履歴管理テーブル６９に登録して管理する。
【００７１】
重要度設定部５３は、データマート４１ごとにそのデータマート４１の各レコードの重要度をそれぞれ設定すると共に、これらの重要度を定期的に更新する機能を有するプログラムである。実際上、重要度設定部５３は、履歴管理部５２が管理するマート参照履歴管理テーブル６９を参照してデータごとの参照頻度を参照頻度管理テーブル７０に登録して管理する。そして重要度設定部５３は、新たなバッチ３５が登録された場合、そのバッチ３５について設定された重要度設定ルール７３（図７）を重要度設定ルール決定テーブル６１から取得し、取得した重要度設定ルール７３と、上述の参照頻度管理テーブル７０とを参照して、そのバッチ３５の処理結果が登録されるデータマート４１の各レコード（各データ）の重要度をそれぞれ設定する。また重要度設定部５３は、上述のようにして設定したデータマート４１の各レコードの重要度を定期的に更新する。
【００７２】
変更検出部５４は、データベース４０（図１）に格納されている各店舗端末３からの販売データ１４及び各データマート４１の各レコードのデータをそれぞれ監視し、いずれかの販売データ１４又はデータマート４１のデータが更新された場合にこれを検出する機能を有するプログラムである。変更検出部５４は、販売データ１４やデータマート４１のデータの変更を検出した場合、入出力管理テーブル６３を参照してその販売データ１４やそのデータマート４１のレコードのデータを参照するバッチ３５をすべて特定し、これらバッチ３５のバッチ名と、変更された販売データ１４やデータマート４１のレコードのデータの変更前後の値とをバッチ制御部５６に通知する。
【００７３】
影響度算出部５５は、販売データ１４又はデータマート４１のデータが変更された場合に、その変更が後続業務に与える影響度を算出する機能を有するプログラムである。影響度算出部５５は、変更されたデータ（元データ）を参照するバッチ３５ごとに、そのバッチ３５について設定された影響度算出ルール７２を影響度算出ルール決定テーブル６０から取得し、取得した影響度算出ルール７２に従って、かかる元データの変更が後続業務に与える影響を算出する。
【００７４】
バッチ制御部５６は、通常時にはバッチスケジュール管理部５１が管理しているバッチ実行スケジュールに従って各バッチ３５を起動して実行させる機能を有するプログラムである。またバッチ制御部５６は、変更検出部５４により販売データ１４やデータマート４１のデータ（元データ）の変更が検出された場合には、変更された元データを入力とするバッチ３５の特定をバッチ解析部５０に依頼する。
【００７５】
そしてバッチ制御部５６は、バッチ解析部５０により特定されたバッチ３５を再実行する空き時間があるか否かの判定（スケジュール空き判定）をバッチスケジュール管理部５１に依頼する。またバッチ制御部５６は、かかる元データの変更が後続業務に与える影響度の算出を影響度算出部５５に依頼し、その算出結果に基づいて、かかる元データの変更が後続業務に与える影響度が許容範囲内であるか否か元データの影響を受けるデータマート４１のレコードごとにそれぞれ判定（影響度判定）する。
【００７６】
そしてバッチ制御部５６は、上述のスケジュール空き判定の判定結果及び影響度判定の判定結果に基づいて、かかる影響度が許容範囲を超えるレコードがある場合には、そのデータマート４１に処理結果を格納するバッチ３５を再実行すべきと判定し、バッチスケジュール管理部５１及び反映通知部５７にそのバッチ３５の再実行を通知する。
【００７７】
反映通知部５７は、バッチ３５の再実行をそのバッチを登録した後続業務の担当者に通知する機能を有するプログラムである。実際上、反映通知部５７は、バッチ３５の再実行がバッチ制御部５６から通知された場合に、そのバッチ３５を登録した担当者の連絡先を担当者連絡先テーブル６２から取得し、かかるバッチ３５を再実行する旨の通知をその連絡先に送信する。
【００７８】
一方、影響度算出ルール決定テーブル６０は、アプリケーションサーバ５に登録された各バッチ３５に対してバッチ解析部５０が設定した影響度算出ルール７２を管理するために利用されるテーブルであり、図９に示すように、対象バッチ欄６０Ａ及び影響度算出ルール欄６０Ｂを備えて構成される。
【００７９】
そして対象バッチ欄６０Ａには、アプリケーションサーバ５に登録された各バッチ３５のバッチ名がそれぞれ格納され、影響度算出ルール欄６０Ｂには、対応するバッチ３５に対して設定された影響度算出ルール７２の識別子が格納される。
【００８０】
従って図９の例の場合、例えば、「集計バッチ１」及び「集計バッチ２」に対しては影響度算出ルール７２として「影響度算出ルール１」がそれぞれ設定され、「集計バッチ３」に対しては影響度算出ルール７２として「影響度算出ルール２」が設定され、「集計バッチ３」に対しては影響度算出ルール７２として「影響度算出ルール３」が設定されていることが示されている。
【００８１】
また重要度設定ルール決定テーブル６１は、後続業務の担当者がバッチ３５をアプリケーションサーバ５に登録する際に設定したそのバッチ３５の処理結果を登録するデータマート４１の各レコードに対する重要度の設定ルール（重要度設定ルール７３）を管理するために利用されるテーブルである。この重要度設定ルール決定テーブル６１は、図１０に示すように、対象バッチ欄６１Ａ、重要度設定ルール欄６１Ｂ及び起動条件欄６１Ｃを備えて構成される。
【００８２】
そして対象バッチ欄６１Ａには、アプリケーションサーバ５に登録された各バッチ３５のバッチ名がそれぞれ格納され、重要度設定ルール欄６１Ｂには、対応するバッチ３５に対して設定された重要度設定ルール７３の識別子が格納される。また起動条件欄６１Ｃには、対応するバッチ３５が登録された際に設定された、そのバッチ３５が処理結果を格納するデータマート４１の各レコードの重要度を更新する処理を実行する条件（起動条件）が格納される。
【００８３】
従って図１０の例の場合、例えば、「集計バッチ１」に対しては、重要度設定ルール７３として「重要度設定ルール１」が設定されると共に、その「集計バッチ１」が処理結果を格納するデータマート４１の各レコードのデータに対して設定された重要度を「毎日午前０時」に更新すべき旨の設定がなされていることが示されている。
【００８４】
担当者連絡先テーブル６２は、後続業務の担当者がバッチ３５をアプリケーションサーバ５に登録する際に設定されたその担当者への連絡先（以下、メールアドレスとする）を管理するために利用されるテーブルであり、図１１に示すように、対象バッチ欄６２Ａ及びメールアドレス欄６２Ｂを備えて構成される。
【００８５】
そして対象バッチ欄６２Ａには、アプリケーションサーバ５に登録された各バッチ３５のバッチ名がそれぞれ格納され、メールアドレス欄６２Ｂには、対応するバッチ３５をアプリケーションサーバ５に登録した担当者のメールアドレスが格納される。
【００８６】
従って図１１の例の場合、例えば、「集計バッチ１」をアプリケーションサーバ５に登録した担当者のメールアドレスは「batch1_tantou@gyoumu.com」、「集計バッチ２」をアプリケーションサーバ５に登録した担当者のメールアドレスは「batch2_tantou@gyoumu.com」であり、「集計バッチ３」をアプリケーションサーバ５に登録した担当者のメールアドレスは「batch3_tantou@gyoumu.com」、「集計バッチ４」をアプリケーションサーバ５に登録した担当者のメールアドレスは「batch4_tantou@gyoumu.com」であることが示されている。
【００８７】
入出力管理テーブル６３は、アプリケーションサーバ５に登録された各バッチ３５がそれぞれ処理を実行する際に参照するテーブル（データベース４０のテーブル又はデータマート４１）と、処理結果を格納するデータマート４１とを管理するために利用されるテーブルであり、図１２に示すように、バッチ名欄６３Ａ、参照テーブル欄６３Ｂ及び更新テーブル欄６３Ｃを備えて構成される。
【００８８】
そしてバッチ名欄６３Ａには、アプリケーションサーバ５に登録された各バッチ３５のバッチ名がそれぞれ格納される。また参照テーブル欄６３Ｂには、対応するバッチ３５が処理を実行する際に参照するテーブルの識別子が格納され、更新テーブル欄６３Ｃには、そのバッチ３５が処理結果を登録するデータマート４１の識別子が格納される。
【００８９】
従って、図１２の例の場合、例えば、「集計バッチ１」というバッチ３５は、「店舗１  販売データ（コピー）」というテーブル（データベース４０のテーブル）に格納されたデータを入力として処理を実行し、処理結果を「日別売上マート」というデータマート４１に格納することが示されている。
【００９０】
バッチ実行条件管理テーブル６４は、上述のように後続業務の担当者がバッチ３５をアプリケーションサーバ５に登録する際に登録したそのバッチ３５の実行条件を管理するために利用されるテーブルである。このバッチ実行条件管理テーブル６４は、図１３に示すように、バッチ名欄６４Ａ、実行頻度欄６４Ｂ、開始条件欄６４Ｃ、完了条件欄６４Ｄ、想定所要時間欄６４Ｅ及び割当てリソース欄６４Ｆを備えて構成される。
【００９１】
そしてバッチ名欄６４Ａには、対応するバッチ３５が登録される際にそのバッチ３５を登録した担当者により設定されたそのバッチ３５の名称（バッチ名）が格納され、実行頻度欄６４Ｂには、その担当者により設定されたそのバッチ３５の実行頻度が格納される。また開始条件欄６４Ｃには、その担当者により設定されたそのバッチ３５の開始条件が格納され、完了条件欄６４Ｄには、その担当者により設定されたそのバッチ３５の完了条件が格納される。
【００９２】
さらに想定所要時間欄６４Ｅには、その担当者により登録されたそのバッチ３５の想定所要時間が格納され、割当てリソース欄６４Ｆには、その担当者により登録されたそのバッチ３５を実行する際に割り当てるべきリソースが格納される。
【００９３】
従って、図１３の例の場合、「集計バッチ１」というバッチ３５については、想定所要時間が「３時間」であり、「毎日」、「午前０時以降」に処理を開始し、「翌午前９時」までに処理を完了させる必要があり、処理実行時には１つのＣＰＵ及び２ＧＢ分のメモリ（「ＣＰＵ＝１、メモリ＝２ＧＢ」）を割り当てるべき旨の登録がなされていることが示されている。
【００９４】
またバッチ実行スケジュールテーブル６５は、アプリケーションサーバ５に登録された各バッチ３５の実行スケジュールをそれぞれ管理するためにバッチスケジュール管理部５１（図７、図８）により作成されるテーブルであり、図１４に示すように、バッチ名欄６５Ａ及び実行タイミング欄６５Ｂを備えて構成される。
【００９５】
そしてバッチ名欄６５Ａには、アプリケーションサーバ５に登録された各バッチ３５のバッチ名がそれぞれ格納され、実行タイミング欄６５Ｂには、バッチスケジュール管理部５１によりスケジュールされた対応するバッチ３５の実行タイミング（そのバッチ３５の開始日時）が格納される。
【００９６】
従って、図１４の例の場合、例えば、「集計バッチ１」というバッチ３５は、「毎日」、「午前０時」に実行するようスケジュールされ、「集計バッチ２」というバッチ３５は、「毎週金曜日」の「午前３時」に実行するようスケジュールされていることが示されている。
【００９７】
バッチ優先順位管理テーブル６６は、アプリケーションサーバ５に登録された各バッチ３５についてシステム管理者等により設定されたバッチ３５ごとの優先順位を管理するために利用されるテーブルであり、図１５に示すように、バッチ名欄６６Ａ及び優先順位欄６６Ｂを備えて構成される。
【００９８】
そしてバッチ名欄６６Ａには、アプリケーションサーバ５に登録された各バッチ３５のバッチ名がそれぞれ格納され、優先順位欄６６Ｂには、対応するバッチ３５に対してシステム管理者等により設定されたそのバッチ３５の優先順位が格納される。なお、あるバッチ３５の後続バッチ３５は、そのバッチ３５よりも優先順位が低く設定される。
【００９９】
従って、図１５の例の場合、アプリケーションサーバ５に登録されたバッチ３５の中では「集計バッチ２」が最も優先順位が高く、その後、「集計バッチ３」、「集計バッチ４」及び「集計バッチ１」の順番で優先順位が低くなるよう「集計バッチ１」〜「集計バッチ４」の優先順位が設定されていることが示されている。
【０１００】
リソース管理テーブル６７は、アプリケーションサーバ５のリソースを管理するために利用されるテーブルであり、図１６に示すように、リソース名欄６７Ａ及びリソース量欄６７Ｂを備えて構成される。
【０１０１】
そしてリソース名欄６７Ａには、アプリケーションサーバ５が保有するリソースのうち、バッチ３５の実行に必要な各リソースのリソース名が格納され、リソース量欄６７Ｂには、対応するリソースのリソース量が格納される。
【０１０２】
従って、図１６の例の場合、アプリケーションサーバ５は、かかるリソースとして「ＣＰＵ」については「12」個（正確にはＣＰＵのコア数が12個）、「メモリ」として「32」ＧＢを保有していることが示されている。
【０１０３】
バッチ実行履歴管理テーブル６８は、アプリケーションサーバ５に登録された各バッチ３５の実行履歴を管理するために利用されるテーブルであり、図１７に示すように、バッチ名欄６８Ａ、開始日時欄６８Ｂ及び終了日時欄６８Ｃを備えて構成される。
【０１０４】
そしてバッチ名欄６８Ａには、アプリケーションサーバ５に登録された各バッチ３５のうち、実行されたバッチ３５のバッチ名が格納される。また開始日時欄６８Ｂには、そのバッチ３５の実行が開始された日時が格納され、終了日時欄６８Ｃにはそのバッチ３５が終了した日時が格納される。
【０１０５】
従って、図１７の例の場合、「集計バッチ１」というバッチ３５は「2017/2/3 1:00」に実行が開始され、「2017/2/2 4:05」に処理が完了し、「集計バッチ２」というバッチ３５は「2017/2/3 3:00」に実行が開始され、「2017/2/3 5:21」に処理が完了したことが示されている。
【０１０６】
マート参照履歴管理テーブル６９は、データベースサーバ６が保持するデータマート４１に対する後続業務の担当者等の参照履歴を管理するために利用されるテーブルであり、図１８に示すように、対象マート欄６９Ａ、対象カラム欄６９Ｂ、対象値欄６９Ｃ及び参照日時欄６９Ｄを備えて構成される。
【０１０７】
そして対象マート欄６９Ａには、参照されたデータマート４１の名称が格納され、参照日時欄６９Ｄには、その参照が行われた日時が格納される。また対象カラム欄６９Ｂには、そのデータマート４１におけるそのとき参照されたカラム（欄）の名称が格納され、対象値欄６９Ｃには、そのカラム内のそのとき参照された値の名称が格納される。
【０１０８】
従って、図１８の例の場合、「販売実績マート」の「商品名」というカラム（商品名欄）の「チョコレート」という商品名に対する参照が「2017/2/2 9:00」に行われたことが示されている。
【０１０９】
参照頻度管理テーブル７０は、後続業務の担当者等が所望するデータマート４１に格納されたデータを参照する際に利用したキーワードごとの参照回数を管理するために利用されるテーブルであり、図１９に示すように、対象マート欄７０Ａ、対象カラム欄７０Ｂ、対象値欄７０Ｃ、複合キー欄７０Ｄ及び参照回数欄７０Ｅを備えて構成される。
【０１１０】
そして対象マート欄７０Ａには、そのとき検索対象とされたデータマート４１の識別子が格納され、対象値欄７０Ｃには、その検索で使用されたキーワードが対象値として格納される。
【０１１１】
また対象カラム欄７０Ｂには、そのデータマート４１におけるかかる対象値に対応するカラム（欄）の識別子が格納され、参照回数欄７０Ｅには、そのデータマート４１のその対象値が参照された回数が格納される。
【０１１２】
さらに複合キー欄７０Ｄには、検索で使用されたキーワードの種類ごとにそれぞれ異なる数値が格納される。この場合、複数のキーワードを組み合せて検索が行われた場合には、これら複数のキーワードの複合キー欄にそれぞれ同じ数値が格納される。
【０１１３】
従って図１９の例の場合、「販売実績」というデータマート４１を対象として、「チョコレート」及び「2/1〜2/28」という２つのキーワードの組み合せ（２つのキーワードのアンド条件）で行われた検索が「10」回あったことが示されている。
【０１１４】
重要度管理テーブル７１は、重要度設定部５３（図７、図８）が設定したデータマート４１の各レコードの重要度を管理するために利用されるテーブルであり、図２０に示すように、重要度ＩＤ欄７１Ａ、対象マート欄７１Ｂ、対象カラム欄７１Ｃ、対象値欄７１Ｄ、重要度欄７１Ｅ及び設定日時欄７１Ｆを備えて構成される。
【０１１５】
そして対象マート欄７１Ｂ、対象カラム欄７１Ｃ及び対象値欄７１Ｄには、それぞれ参照頻度管理テーブル７０の対象マート欄７０Ａ、対象カラム欄７０Ｂ及び対象値欄７０Ｃに格納された情報と同様の情報がそれぞれ格納され、重要度ＩＤ欄７１Ａには、参照頻度管理テーブル７０の複合キー欄７０Ｄと同様の情報が格納される。また重要度欄７１Ｅには、対象値欄７１Ｄに格納された対象値のレコード（データ）に対して設定された重要度が格納され、設定日時欄７１Ｆには、その重要度が設定された日時が格納される。
【０１１６】
従って、図２０の例の場合、「販売実績」というデータマート４１について、例えば、「売上日」が「2/1〜2/28」の期間内の「商品名」が「チョコレート」に関するレコード（データ）の重要度が「2017/2/12」に「Ａ」に設定されたことが示されている。
【０１１７】
なお各データマート４１の各レコードの重要度を、そのデータマート４１に処理結果を登録するバッチ３５をアプリケーションサーバ５に登録した後続業務の担当者や、本店舗管理システム１のシステム管理者等が自由に設定及び変更できるようにしてもよい。
【０１１８】
（３）各種画面の構成
図２１は、後続業務の担当者が自己のホスト装置７を用いてアプリケーションサーバ５に新たなバッチ３５を登録するための所定操作を行ったときにそのホスト装置７に表示されるバッチ登録画面８０の概略構成を示す。このバッチ登録画面８０は、バッチ本体登録方法指定フィールド８１、バッチ名設定フィールド８２及びバッチ実行条件設定フィールド８３と、ＯＫボタン８４及びキャンセルボタン８５とを備えて構成される。
【０１１９】
バッチ本体登録方法指定フィールド８１は、そのとき対象としているバッチ３５の本体をどのような方法によりアプリケーションサーバ５に登録するかを指定するためのフィールドであり、登録方法指定欄８１Ａ及びプルダウンボタン８１Ｂを備える。
【０１２０】
そしてバッチ本体登録方法指定フィールド８１では、プルダウンボタン８１Ｂをクリックすることにより、対象とするバッチ３５をアプリケーションサーバ５に登録する方法として利用可能な幾つかの方法が掲載された図示しないプルダウンメニューを表示させることができる。かくして担当者は、このプルダウンメニューに掲載された登録方法の中から所望する方法を選択することにより、そのとき対象としているバッチ３５のアプリケーションサーバ５への登録方法としてその登録方法を指定することができる。そしてこのとき指定した登録方法が登録方法指定欄８１Ａに表示される。
【０１２１】
またバッチ名設定フィールド８２は、そのとき登録しようとするバッチ３５のバッチ名を指定するためのフィールドであり、当該バッチ名を入力するためのバッチ名入力テキストボックス８２Ａが設けられている。
【０１２２】
さらにバッチ実行条件設定フィールド８３は、そのとき登録しようとするバッチ３５の実行条件を設定するためのフィールドであり、そのバッチ３５の実行頻度、開始条件及び完了条件や、そのバッチ３５の想定所要時間、並びに、そのバッチ３５に割り当てるべきリソースを指定できるようになされている。
【０１２３】
かくして後続業務の担当者は、そのとき登録しようとするバッチ３５のアプリケーションサーバ５への登録方法を上述のようにして登録方法指定欄８１Ａに表示させると共に、そのバッチ３５のバッチ名をバッチ名入力テキストボックス８２Ａに入力し、さらにそのバッチ３５の実行条件をバッチ実行条件設定フィールド８３で設定した後、ＯＫボタン８４をクリックすることにより、そのバッチ３５をアプリケーションサーバ５に登録することができる。
【０１２４】
このときアプリケーションサーバ５では、バッチ解析部５０（図７、図８）の制御のもとに、そのバッチ３５本体のデータが取り込まれて記憶装置３２（図１、図７）に格納されると共に、バッチ登録画面８０において後続業務の担当者により設定されたそのバッチ３５の実行条件がバッチ実行条件管理テーブル６４（図１３）に格納される。
【０１２５】
また後続業務の担当者は、キャンセルボタン８５をクリックすることにより、そのときバッチ登録画面８０上で行われた各設定をすべてキャンセルした上で、このバッチ登録画面８０を閉じさせることができる。
【０１２６】
一方、図２２は、後続業務の担当者がかかるバッチ登録画面８０を用いてバッチ３５をアプリケーションサーバ５に登録した後にホスト装置７に表示される重要度設定ルール決定画面９０の概略構成を示す。この重要度設定ルール決定画面９０は、そのとき登録されたバッチ３５に対する重要度設定ルール７３を決定するための画面である。この重要度設定ルール決定画面９０は、重要度設定ルール決定フィールド９１及び起動条件設定フィールド９２と、ＯＫボタン９３及びキャンセルボタン９４とを備えて構成される。
【０１２７】
重要度設定ルール決定フィールド９１は、そのとき登録したバッチ３５に対する重要度設定ルールを決定及び設定するためのフィールドであり、予めシステム管理者等により登録されているすべての重要度設定ルール７３の名称（以下、これを重要度設定ルール名と呼ぶ）９１Ａと、その重要度設定ルールの簡単な解説９１Ｂと、各重要度設定ルール名の左側にそれぞれ配置されたトグルボタン９１Ｃとが表示される。
【０１２８】
かくして担当者は、重要度設定ルール決定画面９０内のそのバッチ３５に対して適切と考える重要度設定ルール７３の名称（重要度設定ルール名９１Ａ）の前に表示されたトグルボタン９１Ｃをオンに設定した上でＯＫボタン９３をクリックすることにより、その重要度設定ルール７３をそのバッチ３５に適用すべき重要度設定ルールとして指定することができる。
【０１２９】
また起動条件設定フィールド９２は、そのとき選択したバッチ３５が処理結果を登録するデータマート４１の各レコードの重要度を更新する周期を設定するためのフィールドであり、かかる更新の頻度や日時を指定できるようになされている。
【０１３０】
かくして、担当者は、そのときアプリケーションサーバ５に登録したバッチ３５に適用すべき重要度設定ルール７３を重要度設定ルール決定フィールド９１で指定し、さらにその重要度設定ルール７２に従って対応するデータマート４１の各レコードの重要度の更新周期を起動条件設定フィールド９２で指定した後、ＯＫボタン９３をクリックすることにより、かかるバッチ３５に対する重要度設定ルール７３を決定及び設定できる。
【０１３１】
このときアプリケーションサーバ５では、バッチ解析部５０の制御のもとに、この重要度設定ルール決定画面９０を用いて担当者により設定されたそのバッチ３５に対する重要度設定ルール７３が当該バッチ３５と対応付けて重要度設定ルール決定テーブル６１（図１０）に格納される。
【０１３２】
また、かかる担当者は、キャンセルボタン９４をクリックすることにより、そのとき重要度設定ルール決定画面９０上で行われた各設定をすべてキャンセルした上で、この重要度設定ルール決定画面９０を閉じさせることができる。
【０１３３】
他方、図２３は、後続業務の担当者がかかる重要度設定ルール決定画面９０を用いてそのとき登録したバッチ３５の重要度設定ルール７３を決定した後にホスト装置７に表示される担当者連絡先登録画面１００の概略構成を示す。
【０１３４】
この担当者連絡先登録画面１００では、かかる担当者が自己のメールアドレスを入力するための担当者連絡先入力テキストボックス１０１と、ＯＫボタン１０２及びキャンセルボタン１０３とが表示される。
【０１３５】
かくして、かかる担当者は、担当者連絡先入力テキストボックス１０１に自己のメールアドレスを入力した後、ＯＫボタン１０２をクリックすることにより、自己のメールアドレスを登録することができる。この場合、アプリケーションサーバ５では、バッチ解析部５０の制御のもとに、かかる担当者連絡先入力テキストボックス１０１に入力されたメールアドレスがそのとき登録されたバッチ３５と対応付けて担当者連絡先テーブル６２に登録される。
【０１３６】
また、かかる担当者は、キャンセルボタン１０３をクリックすることにより、自己のメールアドレスをアプリケーションサーバ５に登録することなく、この担当者連絡先登録画面１００を閉じることができる。
【０１３７】
（４）本実施の形態によるバッチ管理機能に関連する各種処理
次に、本実施の形態によるバッチ管理機能に関連してアプリケーションサーバ５において実行される各種処理について、「新規バッチの登録時に実行される各種処理」、「通常運行時に実行される各種処理」及び「データ変更が検出された場合に実行される各種処理」に分けて、この順番で説明する。
【０１３８】
なお、以下においては、各種処理の処理主体をプログラム（「〜部」）として説明するが、実際上は、そのプログラムに基づいてアプリケーションサーバ５のＣＰＵ３０（図１）がその処理を実行する。
【０１３９】
（４−１）新規バッチの登録時に実行される各種処理
（４−１−１）第１の新規バッチ登録処理
図２４は、後続業務の担当者の所定操作に応じていずれかのホスト装置（以下、これを対象ホスト装置と呼ぶ）７から新規のバッチ３５を登録したい旨の要求（以下、これを新規バッチ登録要求と呼ぶ）がアプリケーションサーバ５に与えられた場合にバッチ解析部５０（図７、図８）により実行される第１の新規バッチ登録処理の処理手順を示す。
【０１４０】
バッチ解析部５０は、かかる新規バッチ登録要求が与えられるとこの図２４に示す第１の新規バッチ登録処理を開始し、まず、図２１について上述したバッチ登録画面８０をその対象ホスト装置７に表示させる（Ｓ１）。またバッチ解析部５０は、担当者がこのバッチ登録画面８０を用いて登録対象のバッチ（以下、これを登録対象バッチと呼ぶ）３５の実行条件等の必要な設定が完了するのを待ち受ける（Ｓ２）。
【０１４１】
そしてバッチ解析部５０は、やがて登録対象バッチ３５に対する必要な設定が完了すると、そのときバッチ登録画面８０に入力されたその登録対象バッチ３５の実行条件をバッチ実行条件管理テーブル６４（図１３）に格納する（Ｓ３）。
【０１４２】
続いて、バッチ解析部５０は、かかる実行条件を満たすように登録対象バッチ３５を実行する空き時間が存在するか否かをバッチスケジュール管理部５１（図７、図８）に問い合わせる（Ｓ４）。そしてバッチ解析部５０は、かかる問合せの結果がバッチスケジュール管理部５１から通知されると、通知された問合せ結果に基づいて、かかる登録対象バッチ３５を実行する空き時間がある否かを判断する（Ｓ５）。
【０１４３】
バッチ解析部５０は、この判断で否定結果を得ると、現在の実行条件ではその登録対象バッチ３５を登録できない旨のエラー表示を対象ホスト装置に表示させると共に、ステップＳ３でバッチ実行条件管理テーブル６４に登録したその登録対象バッチ３５の実行条件をバッチ実行条件管理テーブル６４から削除する（Ｓ６）。そしてバッチ解析部５０は、この後、この第１の新規バッチ登録処理を終了する。
【０１４４】
これに対して、バッチ解析部５０は、ステップＳ５の判断で肯定結果を得ると、登録対象バッチ３５を解析することにより必要な情報を抽出し、抽出した情報を入出力管理テーブル６３（図１２）及び影響度算出ルール決定テーブル６０（図９）にそれぞれ登録する（Ｓ７）。
【０１４５】
具体的に、バッチ解析部５０は、登録対象バッチ３５を解析することにより、当該登録対象バッチ３５が参照するデータと、処理結果を出力するデータマート４１とを検出し、検出結果をその登録対象バッチ３５と対応付けて入出力管理テーブル６３に登録する。またバッチ解析部５０は、その登録対象バッチ３５の処理内容（集計処理を含む、最大値の算出処理を含む、又は、ソート処理を含むなど）に基づいて、その登録対象バッチ３５に適用すべき影響度算出ルール７２を決定し、決定した影響度算出ルール７２をその登録対象バッチ３５と対応付けて影響度算出ルール決定テーブル６０（図９）に登録する。
【０１４６】
続いて、バッチ解析部５０は、図２２について上述した重要度設定ルール決定画面９０を対象ホスト装置７に表示させる（Ｓ８）。またバッチ解析部５０は、この後、この重要度設定ルール決定画面９０を用いてその登録対象バッチ３５に適用すべき重要度設定ルール７３が担当者により設定されるのを待ち受ける（Ｓ９）。
【０１４７】
そしてバッチ解析部５０は、やがてその登録対象バッチ３５に適用すべき重要度設定ルールが担当者により設定されると、そのとき設定された重要度設定ルール７３をその登録対象バッチ３５と対応付けて重要度設定ルール決定テーブル６１（図１０）に登録する（Ｓ１０）。
【０１４８】
次いで、バッチ解析部５０は、図２３について上述した担当者連絡先登録画面１００を対象ホスト装置７に表示させる（Ｓ１１）。またバッチ解析部５０は、この後、この担当者連絡先設定画面１００を用いてその登録対象バッチ３５をアプリケーションサーバ５に登録した後続業務の担当者の連絡先（メールアドレス）が設定されるのを待ち受ける（Ｓ１２）。
【０１４９】
そしてバッチ解析部５０は、やがてその登録対象バッチ３５を登録した担当者の連絡先が設定されると、そのとき設定された連絡先をその登録対象バッチ３５と対応付けて担当者連絡先テーブル６２（図１１）に登録する（Ｓ１３）。そしてバッチ解析部５０は、この後、この第１の新規バッチ登録処理を終了する。
【０１５０】
（４−１−２）第２の新規バッチ登録処理
一方、図２５は、図２４について上述した第１の新規バッチ登録処理のステップＳ４においてバッチ解析部５０から登録対象バッチ３５を実行する空き時間が存在するか否かを問い合わせられたバッチスケジュール管理部５１（図７、図８）により実行される第２の新規バッチ登録処理の処理手順を示す。
【０１５１】
バッチスケジュール管理部５１は、かかる問合せがバッチ解析部５０から与えられるとこの図２５に示す第２の新規バッチ登録処理を開始し、まず、かかる問合せに含まれる登録対象バッチ３５のバッチ名を取得する（Ｓ２０）。
【０１５２】
続いて、バッチスケジュール管理部５１は、ステップＳ２０で取得したバッチ名をキーワードとしてバッチ実行条件管理テーブル６４（図１３）を検索することによりその登録対象バッチ３５の実行条件を取得する（Ｓ２１）。またバッチスケジュール管理部５１は、この後、バッチ実行スケジュールテーブル６５（図１４）を参照して、その登録対象バッチ３５の実行条件を満たす空き時間を探索する（Ｓ２２）。
【０１５３】
次いで、バッチスケジュール管理部５１は、ステップＳ２２の探索により登録対象バッチ３５の実行条件を満たす空き時間を検出できたか否かを判断する（Ｓ２３）。そしてバッチスケジュール管理部５１は、この判断で否定結果を得ると、その登録対象バッチ３５をバッチ実行スケジュールに登録できない旨を問合せ結果としてバッチ解析部５０に通知し（Ｓ２４）、この後、この第２の新規バッチ登録処理を終了する。
【０１５４】
これに対して、バッチスケジュール管理部５１は、ステップＳ２３の判断で肯定結果を得ると、その登録対象バッチ３５をバッチ実行スケジュールに登録できる旨をバッチ解析部５０に通知する。またバッチスケジュール管理部５１は、その登録対象バッチ３５の開始時刻等を決定して当該登録対象バッチ３５の実行スケジュールをバッチ実行スケジュールに組み込むようバッチ実行スケジュールテーブル６５を更新（つまり登録対象バッチ３５の実行スケジュールをバッチ実行スケジュールテーブル６５に登録）する（Ｓ２５）。そしてバッチスケジュール管理部５１は、この後、この第２の新規バッチ登録処理を終了する。
【０１５５】
（４−２）通常運行時に実行される各種処理
（４−２−１）通常運行処理
図２６は、アプリケーションサーバ５の通常運行時にバッチ制御部５６（図７、図８）により実行される通常運行処理の処理手順を示す。バッチ制御部５６は、アプリケーションサーバ５が起動されるとこの通常運行処理を開始し、まず、バッチ実行スケジュールテーブル６５（図１４）を参照して（Ｓ３０）、現在時刻に開始すべきバッチ３５が存在するか否かを判断する（Ｓ３１）。
【０１５６】
バッチ制御部５６は、この判断で否定結果を得るとステップＳ３０に戻り、この後、ステップＳ３１で肯定結果を得るまでステップＳ３０−ステップＳ３１−ステップＳ３０のループを繰り返す。
【０１５７】
そしてバッチ制御部５６は、やがて現在時刻に実行すべきバッチ３５をバッチ実行スケジュールテーブル６５上で検出することによりステップＳ３１で肯定結果を得ると、そのバッチ３５が参照すべきデータ（販売データ１４又はデータマート４１のレコードのデータ）の前回実行時からの差分データをデータベースサーバ６（図１）から取得する。またバッチ制御部５６は、取得した差分データを入力としてそのバッチ３５を実行し、実行結果を対応するデータマート４１に格納する（Ｓ３２）。
【０１５８】
さらにバッチ制御部５６は、バッチスケジュール管理部５１にそのバッチ３５の実行が完了した旨を通知し、そのバッチ３５の次回の実行スケジュールをバッチ実行スケジュールテーブル６５に登録させる（Ｓ３３）。そしてバッチ制御部５６は、ステップＳ３０に戻り、この後、ステップＳ３０以降の処理を繰り返す。
【０１５９】
（４−２−２）重要度管理テーブル更新処理
図２７は、通常運行時に、図２６について上述した通常運行処理と並行して重要度設定部５３（図７、図８）により実行される重要度管理テーブル更新処理の処理手順を示す。
【０１６０】
重要度設定部５３は、アプリケーションサーバ５が起動されるとこの図２７に示す重要度設定処理を開始し、まず、重要度設定ルール決定テーブル６１（図１０）を参照して、アプリケーションサーバ５に登録されている各バッチ３５に対してそれぞれ設定された各重要度設定ルールの起動条件をそれぞれ確認する（Ｓ４０）。
【０１６１】
続いて、重要度設定部は５３、ステップＳ４０の確認結果に基づいて、現在時刻において起動条件を満たす重要度設定ルールが存在するか否かを判断する（Ｓ４１）。そして重要度設定部５３は、ステップＳ４１の判断で否定結果を得るとステップＳ４０に戻り、この後、ステップＳ４０−ステップＳ４１−ステップＳ４０のループを繰り返す。
【０１６２】
また重要度設定部５３は、やがていずれかの重要度設定ルールの起動条件が満たされることによりステップＳ４１で肯定結果を得ると、その重要度設定ルールに従って対応するバッチ３５の処理結果が格納されるデータマート（以下、これを対象データマートと呼ぶ）４１の各レコードの重要度をそれぞれ算出し、算出結果に従って重要度管理テーブル７１（図１９）を更新する（Ｓ４２）。
【０１６３】
例えば、起動条件を満たした重要度設定ルールが上述の第１の重要度設定ルールであった場合、重要度設定部５３は、そのときのマート参照履歴管理テーブル６９（図１８）に基づいて参照頻度管理テーブル７０（図１９）を更新する。また重要度設定部５３は、更新した参照頻度管理テーブル７０に基づいて、対象データマート４１ごとに、それぞれ参照回数が多い上位20％の各レコードのデータの重要度を「Ａ」、参照回数が上位20〜40％の各レコードのデータの重要度を「Ｂ」、参照回数が上位40〜60％の各レコードのデータの重要度を「Ｃ」、参照回数が上位60〜100％の各レコードのデータの重要度を「Ｄ」とするように重要度管理テーブル７１（図２０）を更新する（Ｓ４３）。
【０１６４】
また起動条件を満たした重要度設定ルールが上述の第２の重要度設定ルールであった場合、重要度設定部５３は、対象データマート４１（例えば図３（Ｅ）に示すものであるとする）をコピーした図２８に示すような算出用テーブル１１１を作成した後、各レコードの対象値（売上欄１１１Ｃに格納された数値）の平均値を算出する。また重要度設定部５３は、算出した平均値を利用して、レコードごとにそのレコードの対象値と、平均値との差分の絶対値をそのレコードの偏差欄１１１Ｄに格納する。
【０１６５】
そして重要度設定部５３は、上述のようにして求めたレコードごとの偏差に基づいて、偏差が大きい上位20％のレコードの重要度を「Ａ」、上位20〜40％のレコードの重要度を「Ｂ」、上位40〜60％のレコードの重要度を「Ｃ」、上位60〜80％のレコード重要度を「Ｄ」とするように重要度管理テーブル７１を更新する。
【０１６６】
次いで、重要度設定部５３は、上述のようにして更新した重要度管理テーブル７１の各レコードを設定日時欄７１Ｆに格納された設定日時の新しい順にソートし、下位ｘ％の重要度を１つ下の重要度にそれぞれ再設定する。なお「ｘ」は予め設定された値である。従って、対象となったレコードは、例えば、それまでの重要度が「Ａ」であれば「Ｂ」に、「Ｂ」であれば「Ｃ」に、「Ｃ」であれば「Ｄ」に再設定されることになる。
【０１６７】
そして重要度設定部５３は、この後、この重要度設定処理を終了する。
【０１６８】
（４−２−３）変更検出処理
図２９は、通常運行時に変更検出部５４（図７、図８）により実行される変更検出処理の処理手順を示す。変更検出部５４は、アプリケーションサーバ５が起動されるとこの図２９に示す重要度設定処理を開始し、まず、データベースサーバ６（図１）のデータベース４０（図１）に登録された販売データ１４と、各データマート４１の各レコードのデータとについて、そのデータの変更の有無を当該データへのアクセスログ等に基づいて順番に確認する（Ｓ５０）。
【０１６９】
続いて、変更検出部５４は、ステップＳ５０の確認結果に基づいて、いずれかのデータが変更されたか否かを判断する（Ｓ５１）。そして変更検出部５４は、この判断で否定結果を得るとステップＳ５０に戻り、この後、ステップＳ５０−ステップＳ５１−ステップＳ５０のループを繰り返す。
【０１７０】
また変更検出部５４は、やがていずれかのデータが変更されることによりステップＳ５１で肯定結果を得ると、変更されたデータを指定して、そのデータが変更された旨の通知（以下、これを変更検出通知と呼ぶ）をバッチ制御部５６（図７、図８）に送信する（Ｓ５２）。なお、この変更検出通知には、そのデータの変更内容を表す情報も含まれる。そして変更検出部５４は、ステップＳ５０に戻り、この後、ステップＳ５０以降の処理を繰り返す。
【０１７１】
（４−３）データ変更が検出された場合に実行される各種処理
（４−３−１）バッチ再実行判定処理
一方、図３０は、上述の変更検出通知がバッチ制御部５６に与えられた場合に当該バッチ制御部５６により実行されるバッチ再実行判定処理の処理手順を示す。バッチ制御部５６は、変更検出部からかかる変更検出通知が与えられるとこの図３０に示すバッチ再実行判定処理を開始し、まず、入出力管理テーブル６３（図１２）を参照して、変更されたデータを参照するすべてのバッチ３５と、これらバッチ３５がそれぞれ処理結果を格納するすべてのデータマート４１のレコードとを特定する（Ｓ６０）。
【０１７２】
続いて、バッチ制御部５６は、ステップＳ６０で特定した各バッチ３５の中から１つのバッチ３５を選択し（Ｓ６１）、選択したバッチ（以下、これを選択バッチと呼ぶ）３５を再実行する空き時間が存在するか否かをバッチスケジュール管理部５１に問い合わせると共に（Ｓ６２）、かかるデータの変更が後続業務に与える影響度の算出を要求する影響度算出要求を影響度算出部５５（図７、図８）に送信する（Ｓ６３）。なお、この影響度算出要求には、変更されたデータの変更内容と、ステップＳ６０で特定した選択バッチ３５の情報とが含まれる。
【０１７３】
次いで、バッチ制御部５６は、かかる影響度算出要求に対する影響度算出部５５からの回答（つまりステップＳ６０で特定したデータマート４１のレコードごとの影響度）を受領するのを待ち受け（Ｓ６４）、やがてかかる回答を受領すると、ステップＳ６０で特定した各データマート４１のうち、選択バッチ３５が処理結果を登録するデータマート４１のレコードの重要度を重要度管理テーブル７１（図２０）からそれぞれ取得する（Ｓ６５）。なお、このときバッチ制御部５６は、当該データマート４１のレコードのデータのうち、重要度管理テーブル７１において重要度が設定されていないデータについては、重要度を「Ｅ」に設定する。
【０１７４】
さらにバッチ制御部５６は、ステップＳ６３の影響度算出要求に応じて影響度算出部５５により算出された影響度と、ステップＳ６５で取得した該当するデータマート４１のレコードごとの重要度とに基づいて、選択バッチ３５を再実行する必要があるか否かを判断する（Ｓ６６）。この判断は、影響度が許容範囲を超えるレコードが存在するか否かを判断することにより行われる。
【０１７５】
そしてバッチ制御部５６は、この判断で肯定結果を得ると、選択バッチ３５を再実行すべき旨をバッチスケジュール管理部５１に通知する（Ｓ６８）。またバッチ制御部５６は、反映通知部５７にも選択バッチ３５を再実行する旨を通知し（Ｓ６９）、この後、ステップＳ７２に進む。かくして、この通知を受信した反映通知部５７は、選択バッチ３５を登録した担当者の連絡先を担当者連絡先テーブル６２（図１１）から取得し、その連絡先に選択バッチ３５を再実行する旨を通知する。
【０１７６】
これに対して、バッチ制御部５６は、ステップＳ６６の判断で否定結果を得ると、ステップＳ６２の問合せに対するバッチスケジュール管理部５１からの回答に基づいて、選択バッチ３５を再実行したとしても、アプリケーションサーバ５に登録された他のすべてのバッチ３５がその実行条件で定められた完了期限に間に合うか否かを判断する（Ｓ６７）。なお、ステップＳ６２の問合せに対するバッチスケジュール管理部５１からの回答の内容については、後述する（図３１のステップＳ９０）。
【０１７７】
そしてバッチ制御部５６は、この判断で肯定結果を得るとステップＳ６８に進み、この後、ステップＳ６８及びステップＳ６９を上述と同様に処理した後、ステップＳ７２に進む。
【０１７８】
これに対して、バッチ制御部５６は、ステップＳ６７の判断で否定結果を得ると、選択バッチ３５の再実行を行わず、選択バッチ３５の次回の実行時にかかるデータの変更を対応するデータマート４１に反映させる旨の決定を行い（Ｓ７０）、その旨をバッチスケジュール管理部５１に通知する（Ｓ７１）。
【０１７９】
この後、バッチ制御部５６は、ステップＳ６０で特定したすべてのバッチ３５について、ステップＳ６１以降の処理を実行し終えたか否かを判断する（Ｓ７２）。そしてバッチ制御部５６は、この判断で否定結果を得るとステップＳ６１に戻り、この後、ステップＳ６１で選択するバッチ３５を未処理の他のバッチ３５に順次切り替えながら、ステップＳ６１以降の処理を繰り返す。
【０１８０】
そしてバッチ制御部５６は、やがてステップＳ６０で特定したすべてのバッチ３５についてステップＳ６１以降の処理を実行し終えることによりステップＳ７２で肯定結果を得ると、このバッチ再実行判定処理を終了する。
【０１８１】
なお、バッチ３５が再実行された場合、既にそのバッチ３５の処理が完了してその処理結果が対応するデータマート４１に登録されているときには、当該バッチ３５の再実行に伴ってそのデータマート４１に格納されているそのバッチ３５の処理結果も更新されることになる。そして、この場合には、このデータマート４１のデータの変更が変更検出部５４により検出されるため、この処理結果を参照して処理を実行するそのバッチ３５の後続バッチ３５についても同様のバッチ再実行判定処理が実行される。
【０１８２】
このようにあるバッチ３５について再実行が決定された場合、そのバッチ３５の既に処理が完了した各後続バッチ３５については、直前の後続バッチ３５について再実行しない旨の決定がなされるまでバッチ再実行判定処理がそれぞれ実行されることとなる。
【０１８３】
（４−３−２）空き時間探索処理
他方、図３１は、図３０について上述したバッチ再実行判定処理のステップＳ６２において、当該バッチ再実行判定処理のステップＳ６１で選択されたバッチ３５（選択バッチ３５）を再実行する空き時間が存在するか否かを問い合わせられたバッチスケジュール管理部５１（図７、図８）により実行される空き時間探索処理の処理手順を示す。
【０１８４】
バッチスケジュール管理部５１は、かかる問合せが与えられると、この空き時間探索処理を開始し、まず、この問合せに含まれる選択バッチ３５のバッチ名を取得する（Ｓ８０）。またバッチスケジュール管理部５１は、選択バッチ３５の実行条件をバッチ実行条件管理テーブル６４（図１３）から取得する（Ｓ８１）。
【０１８５】
続いて、バッチスケジュール管理部５１は、バッチ実行スケジュールテーブル６５（図１４）を参照して、ステップＳ８１で取得した実行条件を満たす空き時間を探索し（Ｓ８２）、そのような空き時間を検出できたか否かを判断する（Ｓ８３）。
【０１８６】
そしてバッチスケジュール管理部５１は、この判断で肯定結果を得ると、その空き時間にその選択バッチ３５を再実行するよう選択バッチ３５の開始タイミングをバッチ実行スケジュールテーブル６５に追加する（Ｓ８９）。またバッチスケジュール管理部５１は、選択バッチ３５を再実行したとしても、すべてのバッチ３５をその実行条件で定められた完了期限までに完了できる旨の回答をバッチ制御部５６に送信した後（Ｓ９０）、この空き時間探索処理を終了する。
【０１８７】
これに対して、バッチスケジュール管理部５１は、ステップＳ８３の判断で否定結果を得ると、バッチ優先順位管理テーブル６６（図１５）を参照して、そのときバッチ実行スケジュールテーブル６５に実行スケジュールが登録されているバッチ３５のうち、優先順位が最も低いバッチ３５を特定する（Ｓ８４）。
【０１８８】
次いで、バッチスケジュール管理部５１は、ステップＳ８４で特定したバッチ３５の実行時間を当該バッチ３５の実行条件の範囲内において遅延させることにより、選択バッチ３５を再実行するための空き時間を捻出できるか否かを判断する（Ｓ８５）。この際、バッチスケジュール管理部５１は、選択バッチ３５に後続バッチ３５が存在する場合には、その後続バッチ３５の実行条件をも考慮して、選択バッチ３５を再実行するための空き時間を捻出できるか否かを判断する。
【０１８９】
そしてバッチスケジュール管理部５１は、この判断で肯定結果を得るとステップＳ８９に進み、このステップＳ８９を上述のように処理した後に、選択バッチ３５を再実行したとしても、すべてのバッチ３５をその実行条件で定められた完了期限までに完了できる旨の回答をバッチ制御部５６に送信する（Ｓ９０）。そしてバッチスケジュール管理部５１は、この後、この空き時間探索処理を終了する。
【０１９０】
これに対して、バッチスケジュール管理部５１は、ステップＳ８５の判断で否定結果を得ると、バッチ実行スケジュールテーブル６５に実行スケジュールが登録されたすべてのバッチ３５についてステップＳ８５の処理を実行し終えたか否かを判断する（Ｓ８６）。
【０１９１】
そしてバッチスケジュール管理部５１は、この判断で否定結果を得ると、バッチ優先順位管理テーブル６６を参照して、ステップＳ８４で特定したバッチ３５よりも優先順位が１つ高いバッチ３５を選択した後（Ｓ８７）、ステップＳ８５に戻り、この後、ステップＳ８５又はステップＳ８６で肯定結果を得るまでステップＳ８５〜ステップＳ８７の処理を繰り返す。
【０１９２】
そしてバッチスケジュール管理部５１は、やがてバッチ実行スケジュールテーブル６５に実行スケジュールが登録されたすべてのバッチ３５についてステップＳ８５の処理を実行し終えることによりステップＳ８６で肯定結果を得た場合には、そのときバッチ実行スケジュールテーブル６５に実行スケジュールが登録されているバッチ３５のうち、優先順位が最も低いバッチ３５の実行時間をそのバッチ３５の実行条件を考慮せずに遅延させることにより選択バッチ３５を実行するための空き時間を捻出する（Ｓ８８）。
【０１９３】
そしてバッチスケジュール管理部５１は、この後、ステップＳ８９に進み、このステップＳ８９を上述のように処理した後に、１つ以上のバッチ３５の完了時刻をその実行条件で定められた完了期限よりも遅らせることにより選択バッチ３５を実行できる旨の回答をバッチ制御部５６に送信する（Ｓ９０）。そしてバッチスケジュール管理部５１は、この後、この空き時間探索処理を終了する。
【０１９４】
なおバッチスケジュール管理部５１は、この後、図３０について上述したバッチ再実行処理のステップＳ７１の通知を受信した場合には、ステップＳ８９でバッチ実行スケジュールテーブル６５に登録した選択バッチ３５の再実行の実行タイミングをバッチ実行スケジュールテーブル６５から削除すると共にバッチ実行スケジュールテーブル６５をステップＳ８９の更新前の状態に戻す。
【０１９５】
（４−３−３）影響度算出処理
他方、図３２は、図３０について上述したバッチ再実行判定処理のステップＳ６３において、バッチ制御部５６から上述の影響度算出要求が与えられた影響度算出部５５（図７、図８）により実行される影響度算出処理の処理手順を示す。
【０１９６】
影響度算出部５５は、かかる影響度算出要求がバッチ制御部５６から与えられるとこの影響度算出処理を開始し、まず、影響度算出ルール決定テーブル６０（図９）を参照して、影響度算出要求において指定された選択バッチ３５に適用すべき影響度算出ルールを特定する（Ｓ１００）。
【０１９７】
続いて、影響度算出部５５は、ステップＳ１００で特定した影響度算出ルールに従って、影響度算出要求に含まれるデータの変更が後続業務に与える影響度を算出する（Ｓ１０１）。なお、この影響度の算出手法は、図４〜図６について上述した通りであるため、ここでの再度の説明は省略する。
【０１９８】
そして影響度算出部５５は、この後、算出した影響度をバッチ制御部５６に通知し（Ｓ１０２）、この後、この影響度算出処理を終了する。
【０１９９】
（５）本実施の形態の効果
以上のように本実施の形態の店舗管理システム１では、バッチ３５の処理開始後にそのバッチ３５が参照する元データ（販売データ１４やデータマート４１のデータ）が変更された場合に、アプリケーションサーバ５が、その変更の後続業務への影響度を算出し、算出した影響度が許容範囲内であるか否かを該当するデータマート４１のレコードごとにそれぞれ判定し、影響度が許容範囲を超えているレコードがある場合にのみそのバッチ３５を再実行する。
【０２００】
従って、本店舗管理システム１によれば、元データが変更された場合、その変更が後続業務に与える影響が大きい場合にのみ対応するバッチ３５が再実行され、その変更が後続業務に与える影響が小さい場合にはそのバッチ３５が再実行されないため、バッチの再実行に起因して後続業務の開始時刻までにバッチ処理が完了しないといった事態の発生を極力抑制でき、後続業務の遂行を信頼性高く支援することができる。
【０２０１】
（６）他の実施の形態
なお上述の実施の形態においては、本発明を図１のように構成された店舗管理システム１に適用するようにした場合について述べたが、本発明はこれに限らず、この他種々の構成の情報処理システムに広く適用することができる。
【０２０２】
また上述の実施の形態においては、本部システム８をウェブサーバ４、アプリケーションサーバ５及びデータベースサーバ６により構成するようにした場合について述べたが、本発明はこれに限らず、本部システム８を１つのサーバ装置により構成するようにしてもよい。また上述の実施の形態においては、ネットワーク９Ａをインターネット等により構成し、ネットワーク９Ｂを社内ＬＡＮ等により構成するようにした場合について述べたが、本発明はこれに限らず、これらネットワーク９Ａ，９ＢをＷＡＮ（Wide Area Network）や、専用回線又は無線通信回線等により構成するようにしてもよく、ネットワーク９Ａ，９Ｂの構成としてはこの他種々の構成を広く適用することができる。
【０２０３】
さらに上述の実施の形態においては、データの変更を対応するデータマートに反映させる方法として、対応するバッチ３５を再実行するようにした場合について述べたが、本発明はこれに限らず、例えば、特開２０１０−１２２８８０号公報に開示された方法によりデータの変更を対応するデータマートに反映するようにしてもよく、データの変更を対応するデータマートに反映させる方法としては、この他種々の方法を広く適用することができる。
【産業上の利用可能性】
【０２０４】
本発明は、登録された各バッチをそれぞれ実行し、実行したバッチの処理結果をそれぞれ対応するデータマートに格納する種々の構成の情報処理装置に広く適用することができる。
【符号の説明】
【０２０５】
１……店舗管理システム、２……店舗、３……店舗端末、５……アプリケーションサーバ、６……データベースサーバ、７……ホスト装置、８……本部システム、１０，３０……ＣＰＵ、１４……販売データ、３５，３５Ａ〜３５Ｄ……バッチ、４０……データベース、４１，４１Ａ〜４１Ｄ……データマート、５０……バッチ解析部、５１……バッチスケジュール管理部、５２……履歴管理部、５３……重要度設定部、５４……変更検出部、５５……影響度算出部、５６……バッチ制御部、５７……反映通知部、６０……影響度算出ルール決定テーブル、６１……重要度設定ルール決定テーブル、６２……担当者連絡先テーブル、６３……入出力管理テーブル、６４……バッチ実行条件管理テーブル、６５……バッチ実行スケジュールテーブル、６６……バッチ優先順位管理テーブル、６７……リソース管理テーブル、６８……バッチ実行履歴管理テーブル、６９……マート参照履歴管理テーブル、７０……参照頻度管理テーブル、７１……重要度管理テーブル、７２……影響度算出ルール、７３……重要度設定ルール。
【図１】
2019091197.tif 000007
【図２】
2019091197.tif 000008
【図３】
2019091197.tif 000009
【図４】
2019091197.tif 000010
【図５】
2019091197.tif 000011
【図６】
2019091197.tif 000012
【図７】
2019091197.tif 000013
【図８】
2019091197.tif 000014
【図９】
2019091197.tif 000015
【図１０】
2019091197.tif 000016
【図１１】
2019091197.tif 000017
【図１２】
2019091197.tif 000018
【図１３】
2019091197.tif 000019
【図１４】
2019091197.tif 000020
【図１５】
2019091197.tif 000021
【図１６】
2019091197.tif 000022
【図１７】
2019091197.tif 000023
【図１８】
2019091197.tif 000024
【図１９】
2019091197.tif 000025
【図２０】
2019091197.tif 000026
【図２１】
2019091197.tif 000027
【図２２】
2019091197.tif 000028
【図２３】
2019091197.tif 000029
【図２４】
2019091197.tif 000030
【図２５】
2019091197.tif 000031
【図２６】
2019091197.tif 000032
【図２７】
2019091197.tif 000033
【図２８】
2019091197.tif 000034
【図２９】
2019091197.tif 000035
【図３０】
2019091197.tif 000036
【図３１】
2019091197.tif 000037
【図３２】
2019091197.tif 000038