JP6477311B2 - ジョブ実行カレンダ管理プログラム、ジョブ実行カレンダ管理装置、及びジョブ実行カレンダ管理方法 - Google Patents

Description

本明細書は、ジョブ実行カレンダ管理プログラム、ジョブ実行カレンダ管理装置、及びジョブ実行カレンダ管理方法に関する。

事業所では、業務に関するデータ処理を、コンピュータが実行するジョブとして定義しておき、コンピュータを利用して作業の自動化を行うことが行われている。コンピュータが複数のジョブを実行し得る場合、ジョブスケジューラと呼ばれるソフトウェアを用いて、複数のジョブの実行を集約して管理することがある。ジョブスケジューラは、複数のジョブの登録を受け付け、登録された複数のジョブが効率的に実行されるように、複数のジョブの実行のスケジューリング等のジョブ管理を行う。

近年、統制やコスト削減目的で物理的に分散した環境に存在していたＩＣＴ（Information and Communication Technology）システムをデータセンタに集約する流れが数年前から加速している。それにより、大量のＩＣＴリソースを大規模データセンタで集中して一括管理・運用するスタイルがなる増加している。

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

ＩＣＴリソースの集約、仮想化による集約によりＩＣＴリソースのコストを削減することができる。しかしながら、そのように仮想化集約されても、管理対象となる業務システムは個別のままであり、業務の運用管理コストの削減が図られていない。

バッチ業務の場合、業務システムが配置されていた拠点毎・業務担当者毎に、カレンダ等の運用のための情報が個別に定義・管理される。そのため、単純に仮想化によるサーバ集約を実施しただけでは、例えば管理対象となるカレンダ定義が数千個や数万個レベルから削減されず、操作ミスによる運用品質低下を招く要因になる。

カレンダ定義は、業務処理に依存しており、ジョブの実行日時が業務処理によって異なるため、容易に統合することができない。

また、カレンダのジョブスケジューリングの規則性（たとえば月〜金）が共通であっても、偶然に一致しているものであるのか、カレンダ同士が関連していて一致しているのかの区別はできない。そのため、工場稼働日等の個別変化があった場合に、規則性のみで共通化すると、支障が出る。

本発明の一側面では、カレンダ情報に応じて実行するジョブが稼動するシステムにおいて、業務処理単位で用いられるカレンダ情報を特定する技術を提供する。

本発明の一側面に係るジョブ実行カレンダ管理プログラムは、コンピュータに、以下の処理を実行させる。すなわち、コンピュータは、１以上の情報処理システムから、アクセステーブル情報と、複数のカレンダ情報と、種別情報とを取得する。ここで、処理を実行する複数のジョブを起動させるタイミングをそれぞれ示す複数のカレンダ情報に基づいて複数のジョブを動作させる情報処理システムである。アクセステーブル情報は、複数のジョブのそれぞれが複数のテーブルのいずれにアクセスしたかを示す。種別情報は、複数のジョブのアクセスにより複数のテーブルに対して行われたデータ操作それぞれの種別を示す。コンピュータは、種別情報に基づいて、複数のテーブルから、複数のジョブのいずれかにより追加された情報を格納するテーブルである、トランザクションテーブルを特定する。コンピュータは、アクセステーブル情報に基づいて、複数のカレンダ情報のうち、トランザクションテーブルのうち同じトランザクションテーブルへアクセスするジョブに対応するカレンダ情報を、グループ化する。

本明細書に記載の技術によれば、カレンダ情報に応じて実行するジョブが稼動するシステムにおいて、業務処理単位で用いられるカレンダを特定することができる。

本実施形態におけるジョブ実行カレンダ管理装置の一例を示す。 本実施形態を説明するための業務システムの一例である。 本実施形態におけるジョブ名・テーブル名関係テーブルの一例を示す。 本実施形態における種別関係テーブルの一例を示す。 本実施形態における種別関係テーブル（テーブル種別：マスタテーブルを除外済み）の一例を示す。 本実施形態におけるテーブルアクセス情報テーブルの一例を示す。 本実施形態におけるテーブルアクセス情報テーブル（グループ化済み）の一例を示す。 本実施形態における周期性テーブルの一例を示す。 本実施形態におけるカレンダ管理装置の処理フローを示す。 本実施形態における業務処理に応じて共通化できるカレンダを説明するための図である。 本実施形態（実施例）における業務システムとカレンダ管理装置の一例を示す。 本実施形態（実施例）におけるジョブ定義情報の一例を示す。 本実施形態（実施例）におけるカレンダ定義情報の一例を示す。 本実施形態（実施例）におけるジョブ・ＤＢアクセス情報の一例を示す。 本実施形態（実施例）における業務ＤＢアクセスログの一例を示す。 本実施形態（実施例）における集約済ジョブ定義情報の一例を示す。 本実施形態（実施例）における集約済カレンダ定義情報の一例を示す。 本実施形態（実施例）におけるジョブ・テーブル・種別関係情報の一例を示す。 本実施形態（実施例）における周期性情報の一例を示す。 本実施形態（実施例）における業務処理単位情報の一例を示す。 本実施形態（実施例）における、業務システムの集約前でのジョブスケジューラによるバッチジョブの実行時の動作フローを示す。 本実施形態（実施例）における、システム集約を行う段階での、統合部の処理フローを示す。 本実施形態（実施例）における、テーブル種別判定フロー（Ｓ２３）を示す。 本実施形態（実施例）における、共通化可能なカレンダの共通化フロー（Ｓ２６）を示す。 本実施形態（実施例）における、業務処理単位でグループ化されたカレンダの共通化を説明するための図である。 本実施形態におけるプログラムを実行するコンピュータのハードウェア環境の構成ブロック図の一例である。

上述のように、第１〜第３技術においてサーバの集約化による重複した運用管理コストを削減する機能は、提供されていない。

先進的な顧客における業務集約においては、人力によるカレンダ定義の共通化を実施している。しかしながら、人手に多大なコストを要し、人的ミスによる問題も発生している。

そのため、人手を必要としない機械的なカレンダ定義の共通化によって管理対象数を削減することが、業務集約による運用管理コスト削減の実現に必要である。

業務システムや業務システム内の個々のサブシステムが、通常は業務目的の単位と対応する関係となる。入力に対して様々なデータを抽出・加工や集計処理を行って業務目的であるデータを得ることがバッチ処理の役割である。

バッチ処理をどの日に実行するのかを定義するカレンダ定義は、業務目的を基点に決定されるものである。例えば、販売した商品に対する対価をいつまでに確実に得るためには、入金チェックをいつ実施し、入金までの猶予期間を換算して請求日をいつにするのかという具合に、バッチ処理の実行日が決まっていく。つまり、関連する処理間では業務目的となる共通の基準日がある。

また、別の例では、工場での生産工程を管理する業務の場合、工場ごとに工程管理業務を行う必要がある。このようなケースでは物理的な拠点ごとに業務目的が設定され、拠点に依存したカレンダ定義が管理される。

このように、業務システムの設計を行う上では、最初に、ある目的を達成するための業務処理の単位（業務システム全体や業務システムに属する個々のサブシステム）や工場などの拠点の単位で目的となるデータをいつまでに得たいのかが決定される。

次に、その期限までに目的となるデータを取得することを実現するための一連の個々のバッチ処理をいつ実行するのかが決定される。そして、その決定に沿う形で、カレンダ定義が作成されていく。

本実施形態では、業務目的を達成するために構成される一連の業務処理（ジョブ群）の単位を見極め、その業務処理単位でカレンダを共通化するアプローチにより、業務の運用管理コストの削減をする。

例えば、個別に定義・管理されるカレンダ定義情報が同一のカレンダ定義である場合には共通利用を行うことで数の削減を行うことができ、管理コストが削減できる。

また、ある業務処理についてのカレンダ定義が、別の業務処理のカレンダ定義との間に、例えば常に３日の前後関係がある場合もカレンダ定義を共通利用することができる。例えば、一方の業務処理のカレンダ定義について、３日間のシフト定義を行って業務目的に沿ったカレンダ定義とすることができる。これにより、直感的で解り易くなり、かつ管理コストも削減できる。

本実施形態では、データベースにおいて管理されるテーブルの性質に基づいて、業務目的を達成するために構成される一連の業務処理（ジョブ群）の単位を判別する。例えば、ある業務システムでは、データベースのテーブルには、台帳情報に該当するマスタテーブルと、日々の業務処理で生成される伝票情報に該当するトランザクションテーブルがある。例えば、マスタテーブルとして、商品マスタテーブル（商品名、商品コード、分類コード、単価、・・・）、在庫マスターテーブル（商品名、数量、・・・）がある。また、トランザクションテーブルとして、生産実績トランザクションテーブル（商品名、ロット番号、製造日付、数量）、出荷予実トランザクションテーブル（商品名、出荷先、出荷予定日時、出荷日時、輸送手段、数量）がある。

同じ伝票情報、つまり同じトランザクションテーブルを介して接続関係にある業務処理は、業務目的を達成するための一連の業務処理の単位であるといえる。ただし、業務全体を俯瞰して業務システムの運用状態が正常であることを確認するためのジョブは、業務処理の単位をまたいでトランザクションテーブルにアクセスするため、運用監視ジョブを経由して接続関係にあっても、一連の業務処理の単位とはみなさない。

この点に着目し、本実施形態では、以下の方法でカレンダ定義の共通化ができるか否かを決定し、共通化できる場合にはマージを行う。

図１は、本実施形態におけるジョブ実行カレンダ管理装置の一例を示す。ジョブ実行カレンダ管理装置１は、取得部２と、特定部３と、グループ化部４を含む。

取得部２は、１以上の情報処理システムから、アクセステーブル情報と、複数のカレンダ情報と、種別情報とを取得する。ここで、処理を実行する複数のジョブを起動させるタイミングをそれぞれ示す複数のカレンダ情報に基づいて複数のジョブを動作させる情報処理システムである。アクセステーブル情報は、複数のジョブのそれぞれが複数のテーブルのいずれにアクセスしたかを示す。種別情報は、複数のジョブのアクセスにより複数のテーブルに対して行われたデータ操作それぞれの種別を示す。取得部２の一例として、後述するカレンダ管理装置３１によるＳ１の処理または統合部５２によるＳ２１，Ｓ２２，Ｓ２３−１の処理が挙げられる。

特定部３は、種別情報に基づいて、複数のテーブルから、複数のジョブのいずれかにより追加された情報を格納するテーブルである、トランザクションテーブルを特定する。特定部３の一例として、後述するカレンダ管理装置３１によるＳ２の処理または統合部５２によるＳ２３−４の処理が挙げられる。

グループ化部４は、アクセステーブル情報に基づいて、複数のカレンダ情報のうち、トランザクションテーブルのうち同じトランザクションテーブルへアクセスするジョブに対応するカレンダ情報を、グループ化する。グループ化部４の一例として、後述するカレンダ管理装置３１によるＳ５の処理または統合部５２によるＳ２６の処理が挙げられる。

このように構成することにより、カレンダ情報に応じて実行するジョブが稼動するシステムにおいて、業務処理単位で用いられるカレンダを特定することができる。

また、特定部３は、種別情報がテーブルへのデータの追加を示す場合、テーブルをトランザクションテーブルと判定する。

このように構成することにより、ジョブがアクセスするテーブルがマスタテーブルか、トランザクションテーブルかの判別をすることができる。

ジョブ実行カレンダ管理装置１は、さらに、除去部５を含む。除去部５は、複数のジョブそれぞれの起動条件及び異常終了した場合の動作態様を定義するジョブ定義情報に基づいて、複数のジョブから、一定時間間隔で起動し、かつ異常終了した場合には再起動するジョブを除外する。除去部５の一例として、後述するカレンダ管理装置３１によるＳ４の処理または統合部５２によるＳ２４の処理が挙げられる。

このように構成することにより、運用監視目的のジョブを除外して、業務目的のジョブを残すことができる。

グループ化部４は、グループ化の結果、統合するカレンダ情報の候補を抽出する。
このように構成することにより、カレンダ情報の共通化を図ることができる。

グループ化部４は、抽出した候補をさらにカレンダの周期に基づいてグループ化する。グループ化部４は、その周期に基づいて形成されたグループ毎に、いずれかの候補を基準カレンダ情報とし、他の候補に対応するジョブに、準カレンダ情報を関係付ける。それと共に、グループ化部４は、他の候補と基準カレンダ情報との日にちの差分を保持させる。

このように構成することにより、異なる内容のカレンダ情報であっても、共通化を図ることができる。

以下では、本実施形態についてさらに詳述する。
図２は、本実施形態を説明するための業務システムの一例である。図２には、工場Ａシステム１１を形成する１以上のサーバ（以下、「工場Ａシステム」と称する。）と、本社システム２１を形成する１以上のサーバ（以下、「本社システム」と称する。）がある。

本社システム２１では、出荷指示ジョブ２２が稼動する。出荷指示ジョブ２２は、カレンダＣＡＬ２０１を使用している。出荷指示ジョブ２２は、本社営業日（ＣＡＬ２０１）を用いて、出荷予定情報を出荷予実テーブル１９に書き込むように指示する。

工場Ａシステム１１は、製品テーブル１６、生産実績テーブル１７、在庫テーブル１８、出荷予実テーブル１９を含む。また、工場Ａシステム１１では、生産管理ジョブ１２、運用管理ジョブ１３、在庫登録ジョブ１４、出荷ジョブ１５が稼動する。

製品テーブル１６は、製品を管理するテーブルであって、例えば、製品名、製品コード、分類コード、単価等の項目を含む。

生産実績テーブル１７は、製品の生産の実績について管理するテーブルであって、例えば、製品名、ロット番号、製造日付、数量等の項目を含む。

在庫テーブル１８は、製品の在庫を管理するテーブルであって、例えば、製品名、数量等の項目を含む。

出荷予実テーブル１９は、製品の出荷意の予定と実績を管理するテーブルであって、例えば、商品名、出荷先、出荷予定日時、出荷日時、輸送手段、数量等を含む。

生産管理ジョブ１２は、カレンダＣＡＬ１０１を使用している。生産管理ジョブ１２は、工場Ａの稼働日（ＣＡＬ１０１）の一日の終わりに、製品テーブル１６を参照し、その日工場Ａで生産した製品の情報を生産実績テーブル１７に書き込む。

在庫登録ジョブ１４は、カレンダＣＡＬ１０２を使用している。在庫登録ジョブ１４は、工場Ａの稼働日（ＣＡＬ１０２）の一日の終わりに、生産実績テーブルの情報を読み込み、その読み込んだ情報に基づいて在庫テーブル１８を更新する。

出荷ジョブ１５は、カレンダＣＡＬ１０３を使用している。出荷ジョブ１５は、本社営業日（ＣＡＬ１０３）の一日の終わりに、工場Ａからの出荷実績情報を出荷予実テーブル１９に書き込み、在庫テーブル１８に登録される在庫情報を更新する。

運用監視ジョブ１３は、カレンダＣＡＬ１０４を使用している。運用監視ジョブ１３は、カレンダＣＡＬ１０４に基づいて各テーブルのデータ増減状態を監視する。監視の結果、異常が検出された場合、運用監視ジョブ１３は、システム管理者へと通知を行う。

カレンダ管理装置３１は、ジョブを実行させるタイミングが設定されたカレンダを管理する。カレンダ管理装置３１は、本実施形態では具体的には、バッチシステムの集約後に、バッチ処理で使用するデータの流れから業務処理の単位を特定して、カレンダを統合するか否かを判別し、同一の業務目的のカレンダを統合する。

カレンダ管理装置３１は、ジョブ名・テーブル名関係テーブル３２、種別関係テーブル３３、テーブルアクセス情報テーブル３４、周期性テーブル３５を含む。

ジョブ名・テーブル名関係テーブル３２は、ジョブがどのテーブルにアクセスするかを管理するテーブルである。

種別関係テーブル３３は、テーブル種別及び、ジョブの目的種別を管理するテーブルである。テーブル種別とは、そのテーブルがマスタテーブルか、トランザクションテーブルかを判定するための種別である。目的種別とは、そのジョブが業務目的か、運用監視目的かを判定するための種別である。

テーブルアクセス情報テーブル３４は、ジョブ名・テーブル名関係テーブル３２に登録されたテーブル毎に生成されるテーブルであり、対象のテーブルに対するアクセス履歴を管理する。

周期性テーブル３５は、テーブルアクセス情報テーブル３４から、対象テーブルに対するデータ操作の実施時期の周期性を抽出し、抽出した対象テーブルに対するデータ操作の実施時期の周期性を管理する。

図３は、本実施形態におけるジョブ名・テーブル名関係テーブルの一例を示す。ジョブ名・テーブル名関係テーブル３２は、「ジョブ名」、「アクセス日時」、「テーブル名」の項目を含む。「ジョブ名」には、ジョブを識別する識別情報が格納される。「アクセス日時」にはそのジョブがそのテーブルにアクセスした日時がアクセスされる。「テーブル名」には、テーブルを識別する識別情報が格納される。

図４は、本実施形態における種別関係テーブルの一例を示す。種別関係テーブル３３は、「ジョブ名」、「テーブル名」、「テーブル種別」、「目的種別」の項目を含む。「ジョブ名」には、ジョブを識別する識別情報が格納される。「テーブル名」には、テーブルを識別する識別情報が格納される。「テーブル種別」には、そのテーブルがマスタテーブルか、トランザクションテーブルかを示す種別情報が格納される。「目的種別」には、そのジョブが業務目的か、運用監視目的かを示す種別情報が格納される。

図５は、本実施形態における種別関係テーブル（テーブル種別：マスタテーブルを除外済み）の一例を示す。図５の種別関係テーブル３３ａは、図４の種別関係テーブル３３から、テーブル種別「マスタテーブル」のエントリを除外したものである。

図６は、本実施形態におけるテーブルアクセス情報テーブルの一例を示す。テーブルアクセス情報テーブル３４は、「テーブル名」、「アクセス元」、「ユーザ」、「データ操作種別」、「実施日」の項目を含む。

「テーブル名」には、テーブルを識別する識別情報が格納される。「アクセス元」には、そのテーブルへのアクセス元となる端末情報が格納される。「ユーザ」には、ユーザを特定する情報が格納される。「データ操作種別」には、そのテーブルに対するデータ操作の内容（更新または追加）が格納される。「実施日」には、そのテーブルへデータ操作を実施した日が格納される。

図７は、本実施形態におけるテーブルアクセス情報テーブル（グループ化済み）の一例を示す。テーブルアクセス情報テーブル３４ａは、項目「処理種別」が追加されたテーブルアクセス情報テーブル３４に登録されたエントリを、テーブル名、アクセス元、ユーザ名、データ操作種別、処理種別、実施日の順でグループ化したものである。

図８は、本実施形態における周期性テーブルの一例を示す。周期性テーブル３５は、「テーブル名」、「アクセス元」、「ユーザ」、「データ操作種別」、「処理種別」、「周期性」の項目を含む。

「テーブル名」には、テーブルを識別する識別情報が格納される。「アクセス元」には、そのテーブルへのアクセス元となる端末情報が格納される。「ユーザ」には、ユーザを特定する情報が格納される。「データ操作種別」には、そのテーブルに対するデータ操作の内容（更新または追加）が格納される。「処理種別」には、そのデータ操作がバッチ処理で行われたのか、またはオンライン処理で行われたのかが格納される。「周期性」には、そのデータ操作の実施タイミングの周期性が格納される。

図９は、本実施形態におけるカレンダ管理装置の処理フローを示す。カレンダ管理装置３１は、業務システム毎に、カレンダ情報と、ログと、ジョブ定義情報を取得し、ジョブ名とテーブル名との関係表（ジョブ名・テーブル名関係テーブル３２）を作成する（Ｓ１）。具体的には、カレンダ管理装置３１は、業務システム毎のログから、ジョブのプロセスが発行しているＳＱＬを抽出する。カレンダ管理装置３１は、抽出したＳＱＬから、ジョブがどのテーブルにアクセスするかを抽出する。カレンダ管理装置３１は、ログおよびＳＱＬより、ジョブと、そのジョブがアクセスするテーブルと、そのアクセス日時を抽出すると、ジョブと、そのテーブルと、アクセス日時を関係付けて、ジョブ名・テーブル名関係テーブル３２に登録する。

なお、各業務システムが、ログから、ジョブのプロセスが発行しているＳＱＬを抽出し、ログおよびＳＱＬより、ジョブと、そのジョブがアクセスするテーブルと、そのアクセス日時を抽出し、ジョブ名・テーブル名関係テーブル３２を生成してもよい。また、各業務システムが、そのＳＱＬから、ジョブによりテーブルに対して行われたデータ操作種別を抽出してもよい。この場合、カレンダ管理装置３１は、各業務システムから、ジョブ名・テーブル名関係テーブル３２、データ操作種別を取得してもよい。

次に、カレンダ管理装置３１は、ジョブ名・テーブル名関係テーブル３２に登録したテーブル名のそれぞれについて、後述する方法によりテーブル種別（マスタテーブル／トランザクションテーブル）を判定し、種別関係テーブル３３に登録する（Ｓ２）。Ｓ２の詳細な処理については、後述する。

次に、カレンダ管理装置３１は、ジョブ名・テーブル名関係テーブル３２に登録したジョブ名のそれぞれについて、後述する方法によりジョブの目的種別（業務処理目的／運用監視目的）を判定し、種別関係テーブル３３に登録する（Ｓ３）。Ｓ３の詳細な処理については、後述する。

次に、カレンダ管理装置３１は、図５に示すように、種別関係テーブル３３から、テーブル種別が「マスタテーブル」であるエントリと、目的種別が「運用監視」であるエントリを取り除く（Ｓ４）。これにより、種別関係テーブル３３ａには、テーブル種別が「トランザクション」で、かつ目的種別が「業務」であるエントリが残る。

それから、カレンダ管理装置３１は、種別関係テーブル３３ａから、テーブル種別が「トランザクションテーブル」であって、同一のテーブル名に関係するジョブ同士のカレンダは、共通化できると判定する（Ｓ５）。カレンダ管理装置３１は、共通化できると判定したカレンダをグループ化する。

次に、Ｓ２におけるマスタテーブル／トランザクションテーブルの判定方法について説明する。マスタテーブルとトランザクションテーブルには、以下の性質がある。

マスタテーブルに対して、日々のバッチによる業務処理では、行の更新が行われる場合と行われない場合とがある。しかし、日々のバッチによる業務処理では、マスタテーブルに対して、行の追加は行われない。

たとえば、商品マスタテーブルのように、一度内容が決まったら変化しないタイプのマスタテーブルについては、日々のバッチによる業務処理で参照はされる。しかしながら、マスタテーブルについては、行の追加及び更新は行われない。

在庫マスタテーブルのように、日々変動する在庫数等の値を保持するタイプのマスタテーブルでは、在庫数が日々更新されることはある。しかしながら、マスタテーブルに対して、日々のレベルで行の追加（この場合の行の追加は商品ラインナップが増えることを意味する）が行われることはない。

また、マスタテーブルに対して、業務管理者によるマスタメンテナンス作業（バッチ／オンライン）により、不定期に行の追加が行われる。マスタデータは、業務処理を行うための、業務処理全体に影響を及ぼす基本情報であるため、日々のバッチで更新されるデータとは管理レベルが異なる。そのため、マスタテーブルに対する行の追加は日々のバッチによる更新とは別ユーザで行われる場合がある。

一方、トランザクションテーブルに対して、日々のバッチによる業務処理により、行の追加が行われる。トランザクションテーブルに対して、行の更新は行われる場合と行われない場合がある。

例えば、発行されたらそれ以降更新されないような伝票についての生産実績トランザクションテーブルでは、商品生産が行われるたびに行が増えていき、その内容が更新されることはない。発行された後何度か行の追加が行われるタイプのトランザクションテーブルでは、出荷予定が決まるたびに行が増えていき、出荷が実際に行われるたびに実績情報が更新される。

誤入力データ修正のため、トランザクションテーブルに対して、バッチ／オンラインにより不定期に行の更新が行われる。この更新は日々のバッチによる追加とは別ユーザで行われる。

カレンダ管理装置３１は、マスタテーブルとトランザクションテーブルとの性質を利用し、以下の方法を用いて判断を行う。

（ｉ）カレンダ管理装置３１は、テーブルに対する行の追加・更新処理について、ログ及びログ内のＳＱＬから、テーブル名、アクセス元、ユーザ、データ操作種別、実施日を抽出し、図６に示すように、テーブルアクセス情報テーブル３４に登録する。データ操作種別は、ＳＱＬのデータ操作言語（Data Manipulation Language（DML））の内容（ＵＰＤＡＴＥ／ＩＮＳＥＲＴ）に応じて判別できる。

（ｉｉ）カレンダ管理装置３１は、図３のジョブ名・テーブル名関係テーブル３２に基づいて、テーブルアクセス情報テーブル３４に項目「処理種別」を追加する。
項目「処理種別」について、
カレンダ管理装置３１は、テーブルアクセス情報テーブル３４の対象テーブルと、図３のジョブ名・テーブル名関係テーブル３２との照合を行う。その照合の結果、その対象テーブルに対するアクセスがバッチ処理の延長線上で行われた場合、カレンダ管理装置３１は、「バッチ」処理と判定し、そうでない場合には「オンライン」処理と判定する。カレンダ管理装置３１は、その判定結果を、テーブルアクセス情報テーブル３４の項目「処理種別」に登録する。

カレンダ管理装置３１は、テーブルアクセス情報テーブル３４に格納されるエントリを、図７に示すように、テーブル名、アクセス元、ユーザ名、データ操作種別、処理種別、実施日の項目の順で、グループ化する。

カレンダ管理装置３１は、グループ化したテーブルアクセス情報テーブル３４ａから、対象テーブルに対するデータ操作の実施日の周期を求める。カレンダ管理装置３１は、求めた周期を、図８に示すように周期性テーブル３５の項目「周期性」に登録する。これにより、カレンダ管理装置３１は、実施日の周期性の有無を判別することができる。

（ｉｉｉ）カレンダ管理装置３１は、周期性テーブル３５から、対象テーブルに対して周期性があるアクセス情報（エントリ）が１件もないと判定した場合、対象テーブルは、マスタテーブルであると判断する。

カレンダ管理装置３１は、周期性テーブル３５から、対象テーブルに対するデータ操作種別「追加」を示すエントリが１件以上ある場合、その対象テーブルは、トランザクションテーブルであると判断する。カレンダ管理装置３１は、周期性テーブル３５から、対象テーブルに対するデータ操作種別「追加」を示すエントリが１件もなく、データ操作種別「更新」が１件以上ある場合、その対象テーブルはマスタテーブルであると判断する。

次に、Ｓ３における業務処理目的／運用監視目的のジョブの判定方法について説明する。

運用監視を目的とするジョブと業務処理を目的とするジョブとには、以下の性質がある。

運用監視を目的とするジョブは、システムの定常監視を目的としているため、一定時間間隔で動作する。また、運用監視を目的とするジョブは、情報を収集し続けることを目的としている。そのため、運用監視目的のジョブについては、想定外のエラーが発生した場合でも、次回以降の起動は継続する。

一方、業務処理を目的とするジョブは、業務データを正しく処理することを目的としている。そのため、業務処理目的のジョブについて、想定外のエラーが発生した場合、システム管理者がその問題に対処しその解決が確認できるまで、次回以降の起動は抑止される。

これらの性質を利用し、カレンダ管理装置３１は、ジョブの「起動条件」が「一定時間間隔」かつ「異常終了時の扱い」が「次回起動する」であるジョブを、運用監視目的のジョブであると判定し、それ以外のジョブを業務処理目的のジョブと判定する。カレンダ管理装置３１は、その判定結果を、種別関係テーブル３３に登録する。

図１０は、本実施形態における業務処理に応じて共通化できるカレンダを説明するための図である。カレンダ管理装置３１は、種別関係テーブル３３ａから、トランザクションテーブル「生産実績テーブル」１７にアクセスする生産管理ジョブ１２及び在庫登録ジョブ１４で用いられているカレンダＣＡＬ１０１，１０２は、共通化できると判定する。

また、カレンダ管理装置３１は、種別関係テーブル３３ａから、トランザクションテーブル「出荷予実テーブル」１９にアクセスする出荷指示ジョブ２２及び出荷ジョブ１５で用いられているカレンダＣＡＬ２０１，１０３は、共通化できると判定する。

以下では、上述した実施形態についての実施例を説明する。
図１１は、本実施形態（実施例）における業務システムとカレンダ管理装置の一例を示す。業務システム４１は、１以上存在する。各業務システム４１は、仮想集約化する前の各業務システムを稼動する１以上のサーバである。業務システム４１は、例えば、図２の工場Ａシステム１１、・・・・、本社システム２１を含む。

業務システム４１の制御部（不図示）は、ジョブスケジューラ４２、業務プログラム（バッチ）４３、業務プログラム（オンライン）４４を実行する。業務システム４１が有する記憶装置（不図示）は、業務ＤＢ４６、ジョブ定義情報４７、カレンダ定義情報４８、ジョブ・ＤＢアクセス情報４９、業務ＤＢアクセスログ４５を格納する。

ジョブスケジューラ４２は、ジョブのスケジュールを管理するプログラムである。ジョブスケジューラ４２は、ジョブ定義情報４７に定義されたジョブの起動条件の定義に従って、ジョブを自動起動したり、ジョブの操作、実行状況や実行結果の管理を行ったりする。

ジョブ定義情報４７は、ジョブの定義データである。ジョブ定義情報４７には、起動する業務プログラム名や起動条件（時刻到来やファイル待ち合わせなど）、起動日としてどのカレンダを利用するかという情報が定義され、保存される。

カレンダ定義情報４８は、カレンダの定義データである。
業務プログラム（バッチ）４３は、業務システムで用いられた業務データをバッチ処理する業務プログラムである。

業務プログラム（オンライン）４４は、オンラインでリアルタイムで業務データの処理を行う業務プログラムである。

業務ＤＢ４６は、業務プログラム（バッチ及びオンライン）が読み書きするデータベースである。

業務ＤＢアクセスログ４５は、業務ＤＢ４６に含まれるテーブル（情報）へのアクセスに応じて出力されるアクセスログである。業務ＤＢアクセスログ４５には、アクセス元、テーブル名、ユーザ名、アクセス日、アクセス種別（更新／追加）が記録される。ここで、テーブル名、アクセス種別（更新／追加）は、ジョブが発行したＳＱＬに基づくログである。

ジョブ・ＤＢアクセス情報４９は、ジョブスケジューラ４２が、業務プログラム（バッチ）による業務ＤＢ４６へのアクセス動作をトレースして、ジョブが読み書きしたテーブルに関する情報を保存する。

カレンダ管理装置５１は、統合部５２、メモリ５３を含む。メモリ５３には、ジョブ・テーブル・種別関係情報５４、周期性情報５５、業務処理単位情報５６を含む。カレンダ管理装置５１の記憶装置には、集約済ジョブ定義情報５７、集約済カレンダ定義情報５８が格納される。

統合部５２は、業務システム４１から、ジョブ定義情報４７、カレンダ定義情報４８、ジョブ・ＤＢアクセス情報４９、業務ＤＢアクセスログ４５を取得する。統合部５２は、業務ＤＢアクセスログ４５に基づいて、業務ＤＢ４６の各テーブルがマスタテーブルかトランザクションテーブルかを判定する。統合部５２は、その判定結果とジョブのＤＢアクセス情報とを組み合わせ、ジョブ定義情報４７内に定義されるカレンダのグループ化を行うことにより、カレンダの統合を行う。

集約済ジョブ定義情報５７は、全システムのジョブ定義情報４７の結果を集約した情報である。

集約済カレンダ定義情報５８は、全システムのカレンダ定義情報４８の結果を集約した情報である。

ジョブ・テーブル・種別関係情報５４は、ジョブとテーブルの接続関係、テーブル種別、目的種別を含む情報である。

周期性情報５５は、テーブルへのアクセスの周期性の情報を保持する情報である。
業務処理単位情報５６は、業務処理単位と、業務処理単位を構成するジョブ群の情報である。

図１２は、本実施形態（実施例）におけるジョブ定義情報の一例を示す。図１２（Ａ）は、工場Ａシステム１１で用いられるジョブ定義情報４７ａの一例を示す。図１２（Ｂ）は、本社システム２１で用いられるジョブ定義情報４７ｂの一例を示す。

ジョブ定義情報４７（４７ａ，４７ｂ）は、「ジョブ名」、「カレンダ名」、「起動条件」、「異常終了時の扱い」、「シフト情報」のデータ項目を含む。「ジョブ名」には、ジョブを識別する識別情報が格納される。「カレンダ名」には、カレンダの名称が格納される。「起動条件」には、ジョブの起動するタイミングが格納される。「異常終了時の扱い」には、ジョブの異常終了時において、次回の起動を行うか、抑制するかが格納される。「シフト情報」には、カレンダに登録された日時から何日ずらすかの情報が格納される。

図１３は、本実施形態（実施例）におけるカレンダ定義情報の一例を示す。図１３（Ａ）は、工場Ａシステム１１で用いられるカレンダ定義情報４８ａの一例を示す。図１３（Ｂ）は、本社システム２１で用いられるカレンダ定義情報４７ｂの一例を示す。

カレンダ定義情報４８（４８ａ，４８ｂ）は、「カレンダ名」、「定義」の項目を含む。「カレンダ名」には、カレンダの名称が格納される。「定義」には、そのカレンダに対応する日時（例えば、工場の稼働日、営業日等）が格納される。

図１４は、本実施形態（実施例）におけるジョブ・ＤＢアクセス情報の一例を示す。ジョブ・ＤＢアクセス情報４９は、「ジョブ名」、「アクセス日時」、「テーブル名」のデータ項目を含む。

「ジョブ名」には、ジョブを識別する識別情報が格納される。「アクセス日時」にはそのジョブがそのテーブルにアクセスした日時がアクセスされる。「テーブル名」には、テーブルを識別する識別情報が格納される。

図１５は、本実施形態（実施例）における業務ＤＢアクセスログの一例を示す。業務ＤＢ４６へのアクセスが発生した場合、業務ＤＢアクセスログ４５に、「アクセス元」、「テーブル名」、「ユーザ名」、「アクセス日時」、「データ操作種別」を含む情報が出力される。

「アクセス元」には、アクセス元のＩＰ（Internet Protocol）が出力される。「テーブル名」には、アクセス対象のテーブル名が出力される。「ユーザ名」には、アクセス元の端末においてログインしているユーザ名が格納される。「アクセス日時」には、対象テーブルにアクセスした日時が格納される。「データ操作種別」には、対象テーブルに対して行ったデータ操作（更新／追加）が格納される。

図１６は、本実施形態（実施例）における集約済ジョブ定義情報の一例を示す。集約済ジョブ定義情報５７は、「ジョブ名」、「カレンダ名」、「シフト情報」の項目を含む。「ジョブ名」には、ジョブを識別する識別情報が格納される。「カレンダ名」には、そのジョブがアクセスするカレンダを識別する識別情報が格納される。「シフト情報」には、後述する基準カレンダからの、集約前に当該エントリのジョブが利用していたカレンダの日にちの差分が格納される。

図１７は、本実施形態（実施例）における集約済カレンダ定義情報の一例を示す。集約済カレンダ定義情報５８は、「カレンダ名」、「定義」の項目を含む。「カレンダ」には、カレンダを識別する識別情報が格納される。「定義」には、カレンダの定義（例えば、日にち、曜日等）が格納される。

図１８は、本実施形態（実施例）におけるジョブ・テーブル・種別関係情報の一例を示す。ジョブ・テーブル・種別関係情報５４は、「ジョブ名」、「テーブル名」、「テーブル種別」、「目的種別」の項目を含む。「ジョブ名」には、ジョブを識別する識別情報が格納される。「テーブル名」には、テーブルを識別する識別情報が格納される。「テーブル種別」には、そのテーブルがマスタテーブルか、トランザクションテーブルかを示す種別情報が格納される。「目的種別」には、そのジョブが業務目的か、運用監視目的かを示す種別情報が格納される。

図１９は、本実施形態（実施例）における周期性情報の一例を示す。周期性情報５５は、「テーブル名」、「アクセス元」、「ユーザ」、「データ操作種別」、「処理種別」、「実施日」、「周期性」の項目を含む。

「テーブル名」には、テーブルを識別する識別情報が格納される。「アクセス元」には、そのテーブルへのアクセス元となる端末情報が格納される。「ユーザ」には、ユーザを特定する情報が格納される。「データ操作種別」には、そのテーブルに対するデータ操作の内容（更新または追加）が格納される。「処理種別」には、そのデータ操作がバッチ処理で行われたのか、またはオンライン処理で行われたのかが格納される。「実施日」には、そのデータ操作を実施した日時が格納される。「周期性」には、そのデータ操作の実施タイミングの周期性が格納される。

図２０は、本実施形態（実施例）における業務処理単位情報の一例を示す。業務処理単位情報は、「グループＩＤ」、「ジョブ名」の項目を含む。

「グループＩＤ」には、グループを識別する識別情報が格納される。「ジョブ名」には、グループ化されたジョブの名称が格納される。

次に、本実施形態における処理について説明する。以下では、業務システムの集約前段階と、仮想化集約段階とに分けて説明する。

図２１は、本実施形態（実施例）における、業務システムの集約前でのジョブスケジューラによるバッチジョブの実行時の動作フローを示す。業務システムの集約を行う前の日々の運用の段階で、ジョブスケジューラ４２は、以下を行う。

ジョブスケジューラ４２は、ジョブ定義情報４７に定義されたジョブの起動条件の定義に従って、起動条件（時刻到来やファイル待ち合わせなど）の成立を待ち合わせる（Ｓ１１）。

ジョブスケジューラ４２は、起動条件の成立を検知した場合、対象のジョブ、ここでは、業務プログラム（バッチ）を起動する（Ｓ１２）。ジョブが起動すると、ジョブは、ジョブの動作条件に従って、業務ＤＢ４６へアクセスする。

ジョブスケジューラ４２は、業務ＤＢ４６から、Ｓ１２にて起動したジョブの動作トレースを採取する。ジョブスケジューラ４２は、業務ＤＢ４６への読み書き処理を検知した場合、ジョブ・ＤＢアクセス情報４９に、「ジョブ名」、「テーブル名」、「アクセス日時」を格納する（Ｓ１３）。

なお、システム集約を行う前の日々の運用の段階で、業務プログラム（バッチ）または業務プログラム（オンライン）に基づくジョブが動作し、業務ＤＢ４６へのアクセスが発生する。その場合、そのジョブは、図１５で説明したように、業務ＤＢアクセスログ４５に、「アクセス元」、「テーブル名」、「ユーザ名」、「アクセス日時」、「アクセス種別（更新／追加）」を含む情報を出力する。

図２２は、本実施形態（実施例）における、システム集約を行う段階での、統合部の処理フローを示す。

統合部５２は、全業務システムから、ジョブ定義情報４７およびカレンダ定義情報４８を取得する。統合部５２は、取得したジョブ定義情報４７およびカレンダ定義情報４８を集約し、それぞれ集約済みジョブ定義情報５７および集約済みカレンダ定義情報５８として格納する（Ｓ２１）。

統合部５２は、集約前の業務システムごとに存在しているジョブ・ＤＢアクセス情報４９から、エントリ毎に、ジョブ名とテーブル名の情報を取得する。統合部５２は、エントリ毎にジョブ・ＤＢアクセス情報４９から取得したジョブ名とテーブル名を関係付けて、ジョブ・テーブル・種別関係情報５４に格納する（Ｓ２２）。なお、その段階では、ジョブ・テーブル・種別関係情報５４内のテーブル種別情報は空のままである。

統合部５２は、ジョブ・テーブル・種別関係情報５４に登録される各テーブル名について、テーブル種別、すなわちマスタテーブルであるかトランザクションテーブルであるかの判定を行う（Ｓ２３）。テーブル種別の判定処理の詳細は、図２３にて詳述する。統合部５２は、その判定結果をジョブ・テーブル・種別関係情報５４のテーブル種別に追記する。

統合部５２は、ジョブ・テーブル・種別関係情報５４に登録される各ジョブを、ジョブ定義情報４９と照合する。照合したジョブの起動条件が間隔起動であり、かつ、異常終了時の扱いが「次回起動する」である場合、統合部５２は、そのジョブは運用監視目的のジョブと判定する。照合の結果、照合したジョブの起動条件が間隔起動でないか、または、異常終了時の扱いが「次回起動を抑止」である場合、統合部５２は、そのジョブは業務目的のジョブであると判定する。統合部５２は、その判定結果をジョブ・テーブル・種別関係情報５４の目的種別（業務目的／運用監視目的）に追記する（Ｓ２４）。

統合部５２は、ジョブ・テーブル・種別関係情報５４に登録されたエントリから、目的種別が「業務目的」で、テーブル種別が「トランザクションテーブル」であるエントリを抽出する。統合部５２は、抽出されたエントリに含まれるジョブについて、同じテーブルを介して接続関係にあるジョブ同士を同一のグループに分類する。統合部５２は、その分類結果を、業務処理単位情報５６に格納する（Ｓ２５）。

例えば、ジョブＢとジョブＣとがトランザクションテーブルであるタイムカードテーブルと接続関係にあり、ジョブＣとジョブＤとがトランザクションテーブルである出張情報テーブルと接続関係にあるとする。この場合、統合部５２は、ジョブＢ、ジョブＣ、ジョブＤを同じグループとし、業務処理単位情報５６に格納する。

統合部５２は、業務処理単位情報５６のうち、同じグループに属しているジョブのカレンダについて、共通化が可能であれば共通化を行う（Ｓ２６）。

図２３は、本実施形態（実施例）における、テーブル種別判定フロー（Ｓ２３）を示す。統合部５２は、全システムから業務ＤＢアクセスログ４５を取得する。統合部５２は、取得した全システムの業務ＤＢアクセスログ４５の各行から、「テーブル名」、「アクセス元」、「ユーザ名」、「データ操作種別」、「アクセス日時」を以下（１）〜（４）の流れで抽出して、周期性情報５５に格納する（Ｓ２３−１）。

（１） 統合部５２は、ジョブ・ＤＢアクセス情報４９の各エントリの「テーブル名」及び「アクセス日時」をキーとして、業務ＤＢアクセスログ４５から、対応するエントリを抽出する。

このとき、統合部５２は、業務ＤＢアクセスログ４５から抽出したエントリに含まれるユーザ名に基づいて、処理種別（バッチ／オンライン）を判定する。ユーザ名が所定の管理レベルの権限を有する者の名前である場合、統合部５２は、処理種別はバッチであると判定する。一方、ユーザ名が所定の管理レベルの権限を有する者の名前でない場合、統合部５２は、処理種別はオンラインであると判定する。

（２） 統合部５２は、業務ＤＢアクセスログ４５のアクセス日時情報から、時刻情報を取り除くことにより、実施日情報へ変換する。

（３） 統合部５２は、業務ＤＢアクセスログ４５から取り出した「テーブル名」、統合部５２は、「アクセス元」、「ユーザ名」、「データ操作種別」を周期性情報５５に格納する。また、上記（１）で判定された結果を、周期性情報５５の「処理種別」に格納する。さらに、統合部５２は、上記（２）で変換した実施日情報を、周期性情報５５の「実施日」に格納する。

（４）統合部５２は、周期性情報５５において、「テーブル名」、「アクセス元」、「ユーザ名」、「データ操作種別」、「処理種別（バッチ／オンライン）」の順でグループ化を行う。

統合部５２は、グループ化した周期性情報５５に基づいて、テーブル、アクセス元、ユーザ名、データ操作種別、及び処理種別毎に、テーブルへのアクセスの実施日の周期性を算出する。統合部５２は、算出した周期性を、アクセス周期性情報５５の項目「周期性」に登録する。例えば、統合部５２は、周期性が一定間隔（例：毎日、３日おき）、毎週特定曜日（例：毎週月曜日、毎週の土曜日と日曜日）、毎月特定日（例：毎月２０日、毎月２５日と２６日）にあてはまるか順番に判定を行う。統合部５２は、最初に当てはまった周期性のモデルをそのグループの周期性とみなす（Ｓ２３−２）。

統合部５２は、ジョブ・テーブル・種別関係情報５４のそれぞれのテーブルについて.Ｓ２３−４を行う（Ｓ２３−３）。

統合部５２は、グループ化された周期性情報５５に登録された各テーブルについて、アクセスの実施日に周期性があるエントリのうち、データ操作種別が「追加」であるエントリが１件以上存在するか否かを判定する。アクセスの実施日に周期性があるエントリのうち、データ操作種別が「追加」であるエントリが１件以上存在する場合（Ｓ２３−４で「ＹＥＳ」）、統合部５２は、そのテーブルをトランザクションテーブルと判定する（Ｓ２３−５）。そうでない場合（Ｓ２３−４で「ＮＯ」）、統合部５２は、そのテーブルをマスタテーブルと判定する（Ｓ２３−６）。統合部５２は、その判定結果をジョブ・テーブル・種別関係情報５４の項目「テーブル種別」に追記する。

図２４は、本実施形態（実施例）における、共通化可能なカレンダの共通化フロー（Ｓ２６）を示す。図２５は、本実施形態（実施例）における、業務処理単位でグループ化されたカレンダの共通化を説明するための図である。以下では、図２５を参照しながら、図２４を説明する。

統合部５２は、業務処理単位情報５６のグループ毎に、以下を行う（Ｓ２６−１）。
統合部５２は、集約済ジョブ定義情報５７及び集約済カレンダ定義情報５８を参照し、次の処理を行う。すなわち、統合部５２は、図２５（Ａ）に示すように、業務処理単位情報５６のグループ内の各ジョブ（集合Ｘ）が参照するカレンダを、同じサイクルを持つカレンダ同士でグループ化する。同じサイクルを持つ他のカレンダが存在しないカレンダについては、統合部５２は、そのカレンダ１を含むグループを作る（Ｓ２６−２）。

統合部５２は、グループ化した同じサイクルを持つカレンダのうち、一番未来となるカレンダを基準カレンダと決定する（Ｓ２６−３）。例えば、サイクルが毎週の場合は、統合部５２は、日曜日を一番未来として扱う。

統合部５２は、集合Ｘのうち、元々基準カレンダを参照していたジョブは継続して基準カレンダを参照し続けるようにする。図２５（Ｂ）に示すように、集合Ｘのうち、基準カレンダを参照していなかったジョブは基準カレンダを参照するように、統合部５２は、集約後ジョブ定義情報５２のカレンダ名を更新する。統合部５２は、元々基準カレンダと、元々参照していたカレンダとの日付差分を計算した上で、その差分をシフト情報として集約済みジョブ定義情報５７に格納する（Ｓ２６−４）。

図２６は、本実施形態におけるプログラムを実行するコンピュータのハードウェア環境の構成ブロック図の一例である。コンピュータ６０は、ジョブ実行カレンダ管理装置１、カレンダ管理装置３１として機能する。コンピュータ６０は、ＣＰＵ６２、ＲＯＭ６３、ＲＡＭ６６、通信Ｉ／Ｆ６４、記憶装置６７、出力Ｉ／Ｆ６１、入力Ｉ／Ｆ６５、読み取り装置６８、バス６９、出力機器７１、入力機器７２によって構成される。

ここで、ＣＰＵは、中央演算装置を示す。ＲＯＭは、リードオンリメモリを示す。ＲＡＭは、ランダムアクセスメモリを示す。Ｉ／Ｆは、インターフェースを示す。バス６９には、ＣＰＵ６２、ＲＯＭ６３、ＲＡＭ６６、通信Ｉ／Ｆ６４、記憶装置６７、出力Ｉ／Ｆ６１、入力Ｉ／Ｆ６５、及び読み取り装置６８が接続される。読み取り装置６８は、可搬型記録媒体を読み出す装置である。出力機器７１は、出力Ｉ／Ｆ６１に接続される。入力機器７２は、入力Ｉ／Ｆ６５に接続にされる。

記憶装置６７としては、ハードディスク、フラッシュメモリ、磁気ディスクなど様々な形式の記憶装置を使用することができる。記憶装置６７またはＲＯＭ６３には、ＣＰＵ６２を取得部２と、特定部３と、グループ化部４、除去部５として実行させる本実施形態に係るプログラムが格納される。より具体的には、統合部５２として機能させる本実施形態に係るプログラムが格納される。

また、記憶装置６７は、集約済ジョブ定義情報５７、集約済カレンダ定義情報５８等を格納する。ＲＡＭ６６には、情報、例えば、ジョブ・テーブル・種別関係情報５４、周期性情報５５、業務処理単位情報５６等が一時的に記憶される。

ＣＰＵ６２は、制御部２２として、記憶装置６７またはＲＯＭ６３から本実施形態に係るプログラムを読み出し、当該プログラムを実行する。

通信Ｉ／Ｆ６４は、ネットワークと接続して他の機器と通信するためのポート等のインターフェースである。

上記実施形態で説明した処理を実現するプログラムは、プログラム提供者側から通信ネットワーク７０、および通信Ｉ／Ｆ６４を介して、例えば記憶装置６７に格納されてもよい。また、上記実施形態で説明した処理を実現するプログラムは、市販され、流通している可搬型記憶媒体に格納されていてもよい。この場合、この可搬型記憶媒体は読み取り装置６８にセットされて、ＣＰＵ６２によってそのプログラムが読み出されて、実行されてもよい。可搬型記憶媒体としてはＣＤ−ＲＯＭ、フレキシブルディスク、光ディスク、光磁気ディスク、ＩＣカード、ＵＳＢメモリ装置、半導体メモリカードなど様々な形式の記憶媒体を使用することができる。このような記憶媒体に格納されたプログラムが読み取り装置６８によって読み取られる。

入力機器７２には、キーボード、マウス、電子カメラ、ウェブカメラ、マイク、スキャナ、センサ、タブレット、タッチパネルなどを用いることが可能である。また、出力機器７１には、ディスプレイ、プリンタ、スピーカなどを用いることが可能である。

ネットワーク７０は、業務ネットワーク２１と接続される。ネットワーク７０は、インターネット、ＬＡＮ、ＷＡＮ、専用線、有線、無線等の通信網であってよい。

本実施形態によれば、バッチシステムの仮想集約後に、バッチ処理で使用するデータの流れから業務処理の単位を特定することにより、カレンダを統合すべきか否かを判定し、同一目的のカレンダを統合することができる。

また、バッチ処理で使用するデータをマスタテーブルおよびトランザクションテーブルに分類分けすることにより、トランザクションテーブルでつながる範囲を業務処理の単位と特定することができる。

その結果、カレンダ定義の共通化により管理対象数を削減できる。それにより、カレンダ定義の変更が必要になった際に、大量にあったカレンダをそれぞれ修正するのではなく、共通化されたカレンダのみを修正すれば良くなり、運用管理コストを削減できる。また、その際に人的ミスによる問題が発生する可能性も低減できる。

なお、本発明は、以上に述べた実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。

１ ジョブ実行カレンダ管理装置
２ 取得部
３ 特定部
４ グループ化部
５ 除去部
１１ 工場Ａシステム
２１ 本社システム
３１ カレンダ管理装置
３２ ジョブ名・テーブル名関係テーブル
３３ 種別関係テーブル
３４ テーブルアクセス情報テーブル
３５ 周期性テーブル
４１ 業務システム
４２ ジョブスケジューラ
４３ 業務プログラム（バッチ）
４４ 業務プログラム（オンライン）
４５ 業務ＤＢアクセスログ
４６ 業務ＤＢ
４７ ジョブ定義情報
４８ カレンダ定義情報
４９ ジョブ・ＤＢアクセス情報
５１ カレンダ管理装置
５２ 統合部
５３ メモリ
５４ ジョブ・テーブル・種別関係情報
５５ 周期性情報
５６ 業務処理単位情報
５７ 集約済ジョブ定義情報
５８ 集約済カレンダ定義情報

Claims (7)

1. コンピュータに、
   処理を実行する複数のジョブを起動させるタイミングをそれぞれ示す複数のカレンダ情報に基づいて該複数のジョブを動作させる１以上の情報処理システムから、該複数のジョブのそれぞれが複数のテーブルのいずれにアクセスしたかを示すアクセステーブル情報と、該複数のカレンダ情報と、前記複数のジョブのアクセスにより前記複数のテーブルに対して行われたデータ操作それぞれの種別を示す種別情報とを取得し、
   前記種別情報に基づいて、前記複数のテーブルから、前記複数のジョブのいずれかにより追加された情報を格納するテーブルである、トランザクションテーブルを特定し、
   前記アクセステーブル情報に基づいて、前記複数のカレンダ情報のうち、前記トランザクションテーブルのうち同じトランザクションテーブルへアクセスするジョブに対応する前記カレンダ情報を、グループ化する
   処理を実行させるジョブ実行カレンダ管理プログラム。
2. 前記トランザクションテーブルの特定において、
   前記種別情報が前記テーブルへのデータの追加を示す場合、該テーブルを前記トランザクションテーブルと判定する
   処理を実行させる請求項１に記載のジョブ実行カレンダ管理プログラム。
3. 前記コンピュータに、さらに、
   前記複数のジョブそれぞれの起動条件及び異常終了した場合の動作態様を定義するジョブ定義情報に基づいて、前記複数のジョブから、一定時間間隔で起動し、かつ異常終了した場合には再起動するジョブを除外する
   処理を実行させる請求項１に記載のジョブ実行カレンダ管理プログラム。
4. 前記グループ化において、
   前記グループ化の結果、統合する前記カレンダ情報の候補を抽出する
   処理を実行させる請求項１に記載のジョブ実行カレンダ管理プログラム。
5. 前記候補の抽出において、
   抽出した候補をさらにカレンダの周期に基づいてグループ化し、該周期に基づいて形成されたグループ毎に、いずれかの候補を基準カレンダ情報とし、他の候補に対応するジョブに、該基準カレンダ情報を関係付けると共に、該他の候補と該基準カレンダ情報との日にちの差分を保持させる、
   処理を実行させる請求項４に記載のジョブ実行カレンダ管理プログラム。
6. 処理を実行する複数のジョブを起動させるタイミングをそれぞれ示す複数のカレンダ情報に基づいて該複数のジョブを動作させる１以上の情報処理システムから、該複数のジョブのそれぞれが複数のテーブルのいずれにアクセスしたかを示すアクセステーブル情報と、該複数のカレンダ情報と、前記複数のジョブのアクセスにより前記複数のテーブルに対して行われたデータ操作それぞれの種別を示す種別情報とを取得する取得部と、
   前記種別情報に基づいて、前記複数のテーブルから、前記複数のジョブのいずれかにより追加された情報を格納するテーブルである、トランザクションテーブルを特定する特定部と、
   前記アクセステーブル情報に基づいて、前記複数のカレンダ情報のうち、前記トランザクションテーブルのうち同じトランザクションテーブルへアクセスするジョブに対応する前記カレンダ情報を、グループ化するグループ化部と、
   を備えることを特徴とするジョブ実行カレンダ管理装置。
7. コンピュータが、
   処理を実行する複数のジョブを起動させるタイミングをそれぞれ示す複数のカレンダ情報に基づいて該複数のジョブを動作させる１以上の情報処理システムから、該複数のジョブのそれぞれが複数のテーブルのいずれにアクセスしたかを示すアクセステーブル情報と、該複数のカレンダ情報と、前記複数のジョブのアクセスにより前記複数のテーブルに対して行われたデータ操作それぞれの種別を示す種別情報とを取得し、
   前記種別情報に基づいて、前記複数のテーブルから、前記複数のジョブのいずれかにより追加された情報を格納するテーブルである、トランザクションテーブルを特定し、
   前記アクセステーブル情報に基づいて、前記複数のカレンダ情報のうち、前記トランザクションテーブルのうち同じトランザクションテーブルへアクセスするジョブに対応する前記カレンダ情報を、グループ化する
   処理を実行するジョブ実行カレンダ管理方法。

Images