JP5068685B2 - 情報処理システムおよび情報処理方法 - Google Patents

Description

本発明は情報処理技術に関し、特にプログラムを実行してデータベースを操作する情報処理システムおよび当該システムに適用できる情報処理方法に関する。

近年の情報処理技術の発展およびネットワーク環境の充実化に伴い、様々な情報がネットワークを行き来し、企業、社内の部門など、端末に入力された個々のデータを統括管理する組織には、入力された膨大なデータおよびシステムを厳密に管理する技術が必要不可欠となっている。

大規模なシステムなどでは特に、実行されるプログラムが個々にどのような処理を行っているか、およびプログラム同士の関連性を運用担当者が詳細に把握していないことが多い。また以前に導入されたプログラムが今現在、システム内でどのような機能を果たしているか、わからなくなっていることも少なくない。このような状況で、プログラムの影響を解析する手法として、例えばプログラムの自動解析ツールが提案されている（例えば特許文献１参照）。
特開平１０−１８７４３１号公報

システムに導入済みのプログラムを修正したり、バッチ処理で運用されているジョブに新たなジョブを追加したりする際には、導入済みのプログラムや、新たなジョブで実行するプログラムが、出力結果にいかに作用するかをあらかじめ把握しておく必要がある。予想外の出力結果が得られた場合、システム全体に影響を及ぼす可能性があるためである。しかし上述のように、運用担当者がプログラムの処理内容を詳細に把握しているとは限らず、プログラムの修正や追加が個々の出力データに与える影響を詳細に予測することは困難であった。

また上述のプログラムの自動解析は、プログラム中のレーベルによる分析にとどまっているため、同一のレーベルに性質の異なる出力値が混在していた場合でも、同一視して解析を行う。そのため、例えば更新のタイミングが異なる出力値であっても、その更新特性の差を得ることは難しく、結果としてプログラムがデータベースにどのような操作を行っているかを具体的に把握することが難しかった。

本発明はこうした状況に鑑みてなされたものであり、その目的は、プログラムの処理内容とデータの関係やバッチ処理時のプログラム同士の関連性を詳細に把握することのできる情報処理技術を提供することにある。

本発明のある態様は、情報処理システムに関する。この情報処理システムは、プログラムを実行してデータベースの各項目に対応するデータを操作する情報処理システムであって、データベースのログに記録されたデータ操作ごとに、操作対象のデータを特定するデータキーの値を取得し、各項目に対するデータ操作の履歴をデータキーの値ごとに表した操作履歴テーブルを作成する操作履歴取得部と、操作履歴テーブルを、所定単位のデータキーの値で集計し、データ操作の履歴のパターンと各操作の操作元のプログラムとを項目ごとに表した更新特性テーブルを作成する更新特性分析部と、更新特性テーブルに係る情報を出力してユーザに提示する出力部と、を備えたことを特徴とする。

ここで「項目」とは対応する出力値を総括する名称や識別情報などであり、文字列、数値、図形などいかなる態様の情報でもよい。「データ」も数値、文字列、図形などのいずれの情報でもよく、各項目に紐づけられた値である。「操作の履歴のパターン」とは、複数の操作がどのような順序で行われたかを表す情報である。

本発明の別の態様は、情報処理方法に関する。この情報処理方法は、プログラムを実行してデータベースの各項目に対応するデータを操作する情報処理システムにおいてなされる情報処理方法であって、データベースのログに記録されたデータ操作ごとに、操作対象のデータを特定するデータキーの値を取得し、各項目に対するデータ操作の履歴をデータキーの値ごとに表した操作履歴テーブルを作成するステップと、操作履歴テーブルを、所定単位のデータキーの値で集計し、データ操作の履歴のパターンと各操作の操作元のプログラムとを項目ごとに表した更新特性テーブルを作成するステップと、更新特性テーブルに係る情報を出力してユーザに提示するステップと、
を含むことを特徴とする。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システムなどの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、データとデータを操作する操作元のプログラムとの時系列での関連性を容易に取得することができる。

図１は本実施の形態を適用できるシステムの構成例を示している。同図において情報処理システム１０は第１サーバ１２、第２サーバ１４の２つのサーバを含む。また第１サーバ１２はデータベース１６に接続している。第１サーバ１２や第２サーバ１４で実行されるプログラムによって、データベース１６内のデータが参照されたり更新され、データの保存や管理がなされる。なお、サーバやデータベースの数、データベースの接続先は図１に示したものに限らず、ジョブを処理できるシステムであればいかなる構成においても本実施の形態を適用できる。また各サーバにさらにクライアント端末などが接続していてもよい。

第１サーバ１２および第２サーバ１４はそれぞれ、一以上のＣＰＵとメモリ、記憶装置、入出力装置、表示装置など、あるいはそのいずれかの組み合わせを備えた一般的な情報処理装置であればよく、パーソナルコンピュータ、汎用大型コンピュータなどその規模は限定されない。また第１サーバ１２、第２サーバ１４はネットワーク１８に接続され、互いにデータを送受することができる。データベースへのアクセスは、第１サーバ１２から直接行ってもよいし、第２サーバ１４からネットワーク１８を介して行ってもよい。どのような形態でデータベースへアクセスを行い、どのような処理を行うかはプログラムに依存するところであり、一般的な情報処理で実施されているいかなる形態も適用範囲である。

このような情報処理システム１０において、例えば複数のプログラムを並列にバッチ処理している場合など、実行されるプログラム同士がどのように関連性を有するのかを把握するのは容易ではない。このことは、システムの規模が大きくなるほど深刻な問題となる。プログラム同士の関連性は、例えば入出力データの依存性や、それによって生じる処理順の制約などによって発生するが、直接的なものばかりでなく、あるプログラムを媒介して間接的に影響しているような場合にも発生する。そのため、プログラムを修正したり新たな機能を追加したりする場合、その後に実行されるプログラムや並列に処理されているプログラムへの影響を詳細に把握することが難しい。その結果、修正プログラムの本格導入後に障害が発生してしまうということもあり得る。

そこで本実施の形態では、データベースの監査ログを利用して、個々のデータレベルで更新内容とプログラムとの関係を取得することにより、プログラム同士の関連性やデータの更新特性を特定する。またその情報を用いて、修正プログラムの導入テストに用いられるテストケースを導出したりテストデータを準備したりして、安全な導入が行えるようにする。

図２は第１サーバ１２の構成をより詳細に示している。第２サーバ１４も同様の構成としてよい。第１サーバ１２は、監査ログを用いてデータごとの更新特性などを取得するデータ更新解析部２０、第１サーバ１２内での処理に必要な情報を記憶する情報記憶部２２、通常の運用時やプログラムのテスト時にプログラムを実行するプログラム実行部２６を含む。

図２において、様々な処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、ＣＰＵ、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、演算やファイル操作、データベースへのアクセスを行うプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。

プログラム実行部２６は、情報記憶部２２に記憶されたプログラムを実行する。例えば情報処理システム１０が、ユーザが登録した複数のジョブをバッチ処理するシステムであった場合は、登録された処理内容で登録された順にジョブを実行する。このためプログラム実行部２６はユーザの登録に用いる入力装置、各種演算を行うＣＰＵ、必要な情報を出力する出力装置などを含んでよいが、一般的な情報処理装置における構成と同様とすることができるため個々の図示は省略する。ただし本実施の形態におけるプログラム実行部２６が実行するプログラムには、データベース１６のデータを操作するプログラムが含まれているとする。

データ更新解析部２０は、データベース１６の監査ログを取得し、データベースのログに記録されたデータ操作ごとに必要な情報を抽出する監査ログ分析部２８、各データ操作において操作対象の行を指定するために設定されたデータキーの値を取得し、各項目に対するデータ操作の履歴をデータキーの値ごとに表した操作履歴テーブルを作成する操作履歴取得部３０、操作履歴テーブルを、所定単位のデータキーの値で集計し、データの操作履歴のパターンや操作元のプログラムなどの情報を項目ごとに取得する更新特性分析部３２、プログラムのテストを行う際、テストケースやテストデータを準備するテスト支援部３４、および分析結果などを出力してユーザに通知する出力部３６を含む。

監査ログ分析部２８は、プログラム実行部２６がプログラムを実行し、データベース１６に対してアクセスを行った際に記録される監査ログを取得する。監査ログは一般的なデータベースの機能によって記録され、データの操作内容を表すＳＱＬ(Structured Query Language）文を含んでいる。監査ログ分析部２８はさらに、得られた監査ログから必要な情報を抽出し、シミュレート用監査ログテーブルを作成する。シミュレート用監査ログテーブルは、各データ操作を行った日時、操作内容、操作対象となったテーブルとカラム、操作対象となる行を指定するための条件、操作元のプログラムなどの情報を、監査ログのＳＱＬ文ごとに対応付けたテーブルである。具体例は後に述べる。

なお、本実施の形態ではデータベースを操作する命令としてＳＱＬ文の一例を示しているが、同様の操作を行うためのプログラムであればその言語は限定されない。またデータベースの形式として、各項目は各「カラム」に対応し、各「行」に複数の項目のデータが羅列している、という設定で説明を行うが、「カラム」と「行」の関係を限定するものではない。

操作履歴取得部３０は、監査ログに記録された各データ操作と、操作対象となっている行のデータキーの値とを紐づける。具体的には、ログに記録されたデータ操作を再現実行した後、当該データ操作の操作対象となたった行のうち、あらかじめ設定されたカラムの値を抽出することによりデータキーの値を取得する。ここでデータキーとは、各種データを作成する対象であり、対応するデータを特定できる項目である。データベースは一般的に、人や物など、ある対象についての属性や数値が、当該対象を識別する情報と対応づけて記録される構造でデータを保持する。操作履歴取得部３０はデータ操作ごとに、具体的なデータキーの値、すなわち名前や識別番号などを取得する。データキーは名前と生年月日など、２つ以上の項目の組み合わせでもよい。

一般的にはテーブルには、カラム内で値が重複しない項目である「一意キー」のカラムの設定が付加情報として与えられている。本実施の形態のデータキーはこの「一意キー」も含むため、一意キーのカラムの設定を参照することによりデータキーのカラムを取得できる。ただし、一意キーの設定がないテーブルでは、ユーザがデータキーのカラムをあらかじめ設定しておくか、全てのカラムをデータキーのカラムとする。また、テーブルの物理的な行番号を取得できる場合は、この行番号をデータキーの値の代わりに利用して以後の処理を行ってもよい。

操作履歴取得部３０はさらに、各データ操作を、得られたデータキーごとにまとめる。この際、シミュレート用監査ログテーブルの対応する情報を参照し、操作対象の項目ごとに操作履歴を表した操作履歴テーブルを作成する。すなわち、あるデータキーの値に対応づけられたデータを対象とした操作の推移を、項目別に導出する。

更新特性分析部３２は、操作履歴取得部３０が導出したデータキーの値ごとの操作履歴の情報を、所定単位のデータキーの値で集計することにより、操作履歴のパターン、すなわちどのような順序で操作されたか、を項目ごとに導出する。所定単位とは、データベース１６で一のテーブルに含まれるデータキーの値、一度のバッチ処理で処理されたデータキーの値、ある期間内に処理されたデータキーの値など、設定が可能ないかなる単位でもよく、ユーザが任意に設定できるようにしてもよい。また、集計時に統計分析することにより、操作履歴のパターンにおいて各データ操作が発生した確率を取得する。

各データ操作はシミュレート用監査ログテーブルにおいて操作元のプログラムと紐づけられているため、操作履歴のパターンはすなわちプログラムの実行順序を表すことになる。例えばある項目のデータを、プログラムＡ、プログラムＢ、プログラムＣの順で操作している確率が１００％であれば、プログラムＡの処理結果は後続のプログラムＢ、プログラムＣの処理に影響を及ぼしており、プログラムＢはプログラムＣに影響を及ぼしている、と判断できる。従って、これらのプログラムの処理順は変更することができないことが判明する。

一方、バッチ処理などでプログラムの実行順序が定まっていても、実際には影響を及ぼし合っていないプログラムもある。このような場合も同様の論理により検出することができる。すなわち、全ての項目について操作履歴のパターンに含まれなかったプログラムＤは、プログラムＣの後に実行される設定になっていたとしても実際には順序を切り離すことが可能であると判断できる。このような判断をユーザに行わせるため、更新特性分析部３２はデータの操作履歴のパターンと、各操作の操作元のプログラムとを項目別に対応づけた更新特性テーブルを作成し、出力部３６から出力する。

また更新特性分析部３２は、上述の集計結果を利用し、操作元のプログラムに着目してデータの項目を分類する。これにより、各項目の性質を論理的に導出することができる。例えばあるプログラムにより操作される項目と操作されない項目とを分類すると、当該プログラムの実行時の入力画面における必須項目などの設定を容易に行うことができる。更新特性分析部３２が得た情報は、ユーザの初期設定などによって適宜、出力部３６から出力する。

テスト支援部３４は、操作履歴取得部３０および更新特性分析部３２が取得した情報に基づき、プログラムをテストする際に必要な入力データ、すなわちテストケースを様々な状況を考慮して作成する。本実施の形態のようにデータベース１６の操作を行うプログラムの場合、プログラムを修正した後に、正しくデータベース１６が更新されているか否かを確認するテストを行う必要がある。ここである条件によってのみ動作する機能がプログラムに含まれている場合、確認したい機能を確実に動作させる条件を入力データとしてテストを実行しないと意味がない。どのような入力データの条件でどの機能が動作するかをソースコードから取得することは困難であるため、上述の分析結果を用いて、目的の機能を動作させる入力データを作成する。

具体的には、目的の機能によって更新される項目に着目し、当該項目が更新されているデータキーを、操作履歴テーブルと更新特性テーブルを関連づけた情報から特定する。そして、特定したデータキーに対応する行をinsert（追加）しているＳＱＬ文をシミュレート用監査ログテーブルから検出し、当該ＳＱＬ文から、実際に入力されたデータを取得する。これにより、実際に目的の機能を動作させたケースの入力データを得ることができる。得られた入力データは情報記憶部２２に記憶しておき、テスト実行時に利用できるようにする。あるいはユーザに提示し、ユーザが適宜入力を行ってテストを開始させる。

テスト支援部３４はさらに、テスト開始に際し、データベース１６をテスト対象のプログラムを実行できる状態にする。更新特性分析部３２は上述のとおり、項目ごとにデータになされる操作の順序を導出している。これにより通常の運用において、テスト対象のプログラムが実行される直前に各項目のデータがどのような状態になっているか、すなわちどのような操作がなされたところでテスト対象のプログラムを実行すべきかが確認したい項目ごとに判明する。そこでテスト支援部３４は、テスト時に確認したい項目の入力を受け付け、テスト対象のプログラムを実行する前に必要なプログラムを実行して、当該項目の通常時のデータ状態を再現する。その状態でプログラム実行部２６にテスト対象のプログラムを実行させることにより、通常の場合と同一条件でのテストが行え、結果を厳密に比較することができる。

出力部３６は、データ更新解析部２０の各ユニットが導出した情報をユーザの要求や設定などにより適宜出力する。出力部３６は一般的な表示装置やプリンタなどの出力装置でもよいし、電子メールやファクシミリなどの通信機器をさらに含んでもよい。

情報記憶部２２は、プログラム実行部２６で実行されるプログラムを記憶するほか、データ更新解析部２０の監査ログ分析部２８が取得する監査ログ、作成するシミュレート用監査ログテーブル、操作履歴取得部３０が作成した操作履歴テーブル、更新特性分析部３２が作成した更新特性テーブル、テスト支援部３４が作成したテストケースなどを記憶する。

次にこれまで説明した構成による、第１サーバ１２の動作について説明する。図３は監査ログからデータの更新特性を分析する処理手順を示すフローチャートである。前提として情報処理システム１０は、プログラム実行部２６によりデータベース１６、あるいは図示しない本番用データベースのデータ操作を含むシステムの運用処理を行っているとする。あるいは情報処理システム１０を開発機として、各種テストを行っているとする。いずれの場合においても、データベースの監査機能を利用して、情報記憶部２２などの記憶装置に監査ログが記録されているとする。

そのような状況において、まずユーザが分析を開始したい旨の入力を第１サーバ１２の図示しない入力装置より入力すると、データ更新解析部２０の監査ログ分析部２８は、記録された監査ログを取得し必要な情報を抽出することにより、シミュレート用監査ログテーブルを作成する（Ｓ１０）。次に操作履歴取得部３０は、監査ログに記録されたＳＱＬ文を再現実行した後、各ＳＱＬ文に基づき操作対象の行を指定したうえあらかじめ設定されたカラムの値を抽出してデータキーの値を取得する（Ｓ１２）

ＳＱＬ文の再現実行は、プログラム実行部２６を制御して実行させるようにしてもよい。そして取得したデータキーの値ごとに、各項目のデータがどのような順序でどう操作されているかを操作履歴として取得する（Ｓ１４）。次に更新特性分析部３２は、データキーごとの操作履歴を、例えばテーブル内のデータキーの全値で項目ごとに集計し、各項目のデータの操作履歴のパターンや操作元のプログラムなどの更新特性を取得して、出力部３６から出力する（Ｓ１６）。この際、前述のとおり、プログラムと項目との関連性から項目を分類し、その結果も出力してよい。ユーザは出力結果を見ることにより、プログラムの実行順の制約や、各項目がどのプログラムによって操作されるか、などの情報を得る。これにより、プログラムの修正やシステム全体の改善、入力画面の設計などに対し指針を得ることができる。

もしユーザが、プログラムのテストを行いたい旨の入力を行ったら（Ｓ１８のＹ）、テスト支援部３４は更新特性を参照してテストケースを作成する（Ｓ２０）。この場合ユーザは、テスト対象のプログラムのうち確認したい機能、あるいはその機能で更新される項目の指定を行う。複数の項目を指定してもよい。するとテスト支援部３４は、確認したい項目が更新されているデータキーの値を取得し、当該データキーの値に対応するデータが初めて追加された際の入力データをＳＱＬ文から取得してテストケースとする。テストケースは出力部３６が出力したり情報記憶部２２に記憶したりする。

次いで、確認したい項目に対し、テスト対象のプログラムより前に操作を行っているプログラムの情報を取得したうえ、プログラム実行部２６を制御して当該プログラムを実行させ、テスト対象のプログラムを実行する直前のデータベース１６の状態、すなわち確認したい項目のデータを再現する（Ｓ２２）。この際、最初に入力するデータは、従前に作成されたテストケースである。その後、プログラム実行部２６が、テスト対象のプログラムを実行する（Ｓ２４）。テスト終了後、ユーザはデータベース１６の確認したい項目のデータを実運用におけるデータと比較するなどして、テスト対象のプログラムの問題の有無を判断する。

あるいは比較自体もテスト支援部３４が行うようにし、ユーザは問題の有無を判断するのみでもよい。複数の項目について確認したい場合は、なるべく全項目を網羅する最も少ないテストケースを抽出し作成することで、データの再現を行うことにより、効率よくテストが行えるようにする。本実施の形態では項目ごとに更新特性が得られるため、確認したい項目がある場合は必要最低限のプログラムのみを前もって実行させることにより、当該項目のデータを再現することができる。また、テストが実行されたテストケースの割合を管理することにより、テストの全工程のうち実行済みの割合をユーザに示すようにしてもよい。これによりユーザはテスト完了の見通しを得ることができる。また、必要に応じて全てもしくは一定割合のサンプリングで修正したデータを対象範囲として同様のテストを実施することで、データ修正の影響の有無をより正確に確認できる。この際、サンプリング範囲を増やすことによるコスト増加と障害発生を勘案し、サンプリングの範囲を増減させてもよい。

上述した一連の処理手順は、情報処理システム１０において実運用がされていない期間、あるいは情報処理システム１０が開発機である場合に実施される。すなわち、実運用でなされた処理をログに基づき後から分析する場合である。一方、一部の処理を実運用中に実行してもよい。この場合、実運用でのプログラム実行中、ＳＱＬの実行時にＳＱＬリクエストを取得して操作条件など必要な情報を取得し、ＳＱＬの実行直後に当該条件でデータを抽出する処理を行ってデータキーを取得してもよい。このような機能を、データベースを管理するソフトウェアに実装するようにしてもよい。

またＳＱＬ文を再現実行するために、図示しない本番用データベースのバックアップをとることにより、データベース１６を実運用時の状態と全く同じにしてもよいし、必要な情報によっては全てのデータのバックアップをとらなくてもよい。ＳＱＬ文の再現実行によりデータベース１６にデータが追加されるため、少なくとも追加されたデータについてはその後の操作も再現することができる。

次に具体的なデータ例に沿って上述の処理手順を説明する。図４はデータベース１６におけるデータの具体例を示している。データテーブル５０は例えば自動車保険の顧客データであり、顧客の名前欄５０ａ、生年月日欄５０ｂ、車の型番欄５０ｃ、見積もり依頼日欄５０ｄ、および見積もり金額欄５０ｅの５つのカラムを含む。それぞれの欄には、顧客の名前、生年月日、保有する車の型番、保険見積もりを依頼した日、保険の見積もり金額が記載されている。これらのデータにおいてデータキーは、その値を指定することにより行が定まるデータであるため、顧客の名前および生年月日となる。名前や生年月日単体では同一の顧客が存在しても、その組み合わせによればほぼ顧客の識別が可能なためである。このような項目は通常、データベース検索の際の入力データとなるため、あらかじめデータベースごとにデータキーとして設定されている。

データ操作において各カラムは、カラムの識別情報で識別される。同図の例では、名前欄５０ａのカラムを「a-label」、生年月日欄５０ｂのカラムを「b-label」、車の型番欄５０ｃのカラムを「c-label」、見積もり依頼日欄５０ｄのカラムを「d-label」、見積もり金額欄５０ｅのカラムを「e-label」なる名称で識別する。そして、データテーブル５０の準備と同時に、各項目とカラムの識別情報との対応関係、およびデータキーのカラムの識別情報を付加情報として記録しておく。またデータテーブル５０は情報処理システム１０では「aaa-table」なる名称で他のテーブルと区別するとする。

このような構造のデータに対し、情報処理システム１０がデータ操作を行う都度、データベース１６を管理するソフトウェアが提供する機能により監査ログが記録される。図５は監査ログの例を示している。監査ログ５２は日付欄５２ａ、時刻欄５２ｂ、ＳＱＬ文欄５２ｃ、対象プログラム欄５２ｄを含む。日付欄５２ａおよび時刻欄５２ｂにはデータ操作を行った日付と時刻が記録される。ＳＱＬ文欄５２ｃには操作内容であるＳＱＬ文が、対象プログラム欄５２ｄには操作元のプログラム名が記録される。

例えば同図１行目では、「20070801」（２００７年８月１日）の「12:00:00」（１２時００分００秒）に「insert into aaa-table(a-label, b-label, c-label, d-label) values('山田 太郎', '1977/1/1', 'RA11', '2007/8/1')」なる操作を「見積もり依頼登録」プログラムにより行っていることが記録されている。このＳＱＬ文は、「aaa-table」なるデータテーブルに、カラム「a-label」、「b-label」、「c-label」、「d-label」の値がそれぞれ、「山田 太郎」、「1977/1/1」、「RA11」、「2007/8/1」である行を追加する、という操作である。これは図４のデータテーブル５０における２行目のデータのうち、カラム「e-label」以外のデータを追加した操作にあたる。例えば保険料の見積もり依頼を受け付け、データベース１６に登録する時点にそのような操作を行う。

２行目では「20070801」（２００７年８月１日）の「22:00:00」（２２時００分００秒）に「select a-label, b-label, c-label, d-label from aaa-table where a-label='山田 太郎' and b-label='1977/1/1'」なる操作を「見積もり」プログラムにより行っている。このＳＱＬ文は、「aaa-table」なるデータテーブルのうち、「a-label」および「b-label」がそれぞれ「山田 太郎」および「1977/1/1」である行の、カラム「a-label」、「b-label」、「c-label」、「d-label」の値を抽出する、という操作である。例えばある顧客の登録情報を確認したり比較したりする場合にそのような操作を行う。

３行目では、「20070801」（２００７年８月１日）の「22:00:00」（２２時００分００秒）に「update aaa-table set e-labe=2400 where a-label='山田 太郎' and b-label='1977/1/1'」なる操作を「見積もり」プログラムにより行っている。このＳＱＬ文は、「aaa-table」なるデータテーブルのうち、「a-label」および「b-label」がそれぞれ「山田 太郎」および「1977/1/1」である行の、カラム「e-label」を「2400」なる値で更新する、という操作である。これは図４のデータテーブル５０における２行目のデータのうち、カラム「e-label」に値を代入した操作にあたる。例えばある顧客の保険料の見積もり金額を算出し、登録する場合にそのような操作を行う。

４行目では、「20070801」（２００７年８月１日）の「23:00:00」（２３時００分００秒）に「select a-label, b-label, c-label, d-label, e-label from aaa-table where d-label='2007/8/1'」なる操作を「見積もり印刷」プログラムにより行っている。このＳＱＬ文は、「aaa-table」なるデータテーブルのうち、「d-label」が「2007/8/1」である行の、カラム「a-label」、「b-label」、「c-label」、「d-label」、「e-label」の値を抽出する、という操作である。この操作は２行目の操作と同様であるが、同一の見積もり依頼日を有する顧客の登録情報、見積もり金額を確認したり比較したりする場合にこのような操作を行う。

図６は、図５の監査ログ５２に基づき監査ログ分析部２８が生成するシミュレート用監査ログテーブルの例を示している。シミュレート用監査ログテーブル５４は、日付欄５４ａ、時刻欄５４ｂ、更新区分欄５４ｃ、対象テーブル欄５４ｄ、対象カラム欄５４ｅ、条件欄５４ｆ、ＳＱＬ文欄５４ｇ、対象プログラム欄５４ｈを含む。シミュレート用監査ログテーブル５４の各行は、監査ログ５２の各行、すなわち各データ操作に対応している。なお、シミュレート用監査ログテーブル５４は監査ログ５２以外の情報に基づき作成してもよい。例えば、アプリケーションとＤＢＭＳ間の通信電文を解析するなど、ＳＱＬの発行内容が特定できれば情報の取得先は限定されない。

日付欄５４ａおよび時刻欄５４ｂにはデータ操作を行った日付と時刻が記録される。このデータは監査ログ５２の日付欄５２ａおよび時刻欄５２ｂのデータに対応する。更新区分欄５４ｃには、データ操作内容の名称、すなわち「insert」（追加）か「select」（抽出）か「update」（更新）か、が記録される。対象テーブル欄５４ｄには、データ操作を行う対象であるテーブルの名称が、対象カラム欄５４ｅには、操作を行う対象であるカラムの名称が記録される。条件欄５４ｆには、操作対象の行を指定するための条件が記録される。

更新区分欄５４ｃ、対象テーブル欄５４ｄ、対象カラム欄５４ｅ、条件欄５４ｆのデータは、対応するＳＱＬ文から簡単なパターン解析によって抽出できる。ただし「insert」の操作は行単位で行われるため、対象カラム欄５４ｅには全カラムが記録される。「ＳＱＬ文欄５４ｇにはＳＱＬ文の原文がそのまま記録されるが同図では省略している。対象プログラム欄５４ｈには操作元のプログラム名が記録される。このデータは監査ログ５２の対象プログラム欄５２ｄのデータに対応する。

なお図５に示したように、通常は監査ログから操作元のプログラムが特定できるが、監査ログにそのような情報が含まれていない場合でも、オンラインの稼働ログの開始・終了時刻に基づきジョブログを参照することなどから操作元のプログラムを割り出すことができる。開始・終了時刻が重なる場合は、端末識別子などからプログラムの切り分けを行うこともできる。さらに、各プログラムを既知の順序で実際に実行してみて、記録された監査ログからＳＱＬ文とプログラムとの関連づけを行ってもよいし、開発機での実験時に得られたジョブログとオンラインの稼働ログに基づき関連づけてもよい。解析したデータ量に応じて、より正確な関連づけを行うことができる。

上述のとおり操作履歴取得部３０は、監査ログに記録されたＳＱＬ文を再現実行し、図６のシミュレート用監査ログテーブル５４に基づきデータ操作ごとに操作対象の行におけるデータキーの値を求める。すなわち上記の例では、「insert」、「select」、あるいは「update」の操作を実際に行った直後に、その操作対象である行の条件で行を指定したうえ、あらかじめ設定されたデータキーのカラムを「select」（抽出）することにより、操作ごとにデータキーの値を求める。図６のシミュレート用監査ログテーブル５４の１行目のデータ操作を例にとると、以下のような処理を実行する。

insert into aaa-table(a-label, b-label, c-label, d-label) values('山田 太郎', '1977/1/1', 'RA11', '2007/8/1')
select a-label, b-label from aaa-table where a-label='山田 太郎' and b-label='1977/1/1' and c-label='RA11' and d-label='2007/8/1'

前半の処理は監査ログ５２の１行目に記録された操作そのものである。当該操作を実行後、その操作対象である行、すなわちカラム「a-label」、「b-label」、「c-label」、「d-label」の値がそれぞれ、「山田 太郎」、「1977/1/1」、「RA11」、「2007/8/1」である行のうち、データキーのカラムである「a-label」、「b-label」の値を抽出する。「select」文における「a-label, b-label」は、付加情報として設定されたデータキーのカラム情報から取得する。「aaa-table」はシミュレート用監査ログテーブル５４の対象テーブル欄５４ｄから取得する。「where a-label='山田 太郎' and b-label='1977/1/1' and c-label='RA11' and d-label='2007/8/1'」は同じくシミュレート用監査ログテーブル５４の条件欄５４ｆから取得する。「insert」処理の場合、追加されたデータがすなわち操作対象の行を指定する条件となる。以上の処理により、直前の「insert」操作の対象行におけるデータキーのうち、「a-label」の値が「山田 太郎」、「b-label」の値が「1977/1/1」である、という情報を取得することができる。

シミュレート用監査ログテーブル５４の２行目のデータ操作の場合、以下のような処理を実行する。
select a-label, b-label, c-label, d-label from aaa-table where a-label='山田 太郎' and b-label='1977/1/1'
select a-label, b-label from aaa-table where a-label='山田 太郎' and b-label='1977/1/1'

前半の処理は監査ログ５２の２行目に記録された操作そのものである。当該操作を実行後、その操作対象である行、すなわち、カラム「a-label」、「b-label」の値がそれぞれ、「山田 太郎」、「1977/1/1」である行のうち、データキーのカラムである「a-label」、「b-label」の値を抽出する。後半の「select」文における各設定は上述の場合と同様である。この処理により、直前の「select」操作の対象行におけるデータキーのうち、「a-label」の値が「山田 太郎」、「b-label」の値が「1977/1/1」である、という情報を取得することができる。

シミュレート用監査ログテーブル５４の３行目のデータ操作の場合、以下のような処理を実行する。
update aaa-table set e-labe=2400 where a-label='山田 太郎' and b-label='1977/1/1'
select a-label, b-label from aaa-table where a-label='山田 太郎' and b-label='1977/1/1'

前半の処理は監査ログ５２の３行目に記録された操作そのものである。当該操作を実行後、その操作対象である行、すなわち、カラム「a-label」、「b-label」の値がそれぞれ、「山田 太郎」、「1977/1/1」である行のうち、データキーのカラムである「a-label」、「b-label」の値を抽出する。「select」文における各指定は上述の場合と同様である。この処理により、直前の「update」操作の対象行におけるデータキーのうち、「a-label」の値が「山田 太郎」、「b-label」の値が「1977/1/1」である、という情報を取得することができる。

シミュレート用監査ログテーブル５４の４行目のデータ操作の場合は、以下のような処理を実行する。
select a-label, b-label, c-label, d-label, e-label from aaa-table where d-label='2007/8/1'
select a-label, b-label from aaa-table where d-label='2007/8/1'

この処理は上述の、シミュレート用監査ログテーブル５４の２行目の、「select」の操作の場合と同様である。ただしこの場合、操作対象である行を、カラム「d-label」の値が「2007/8/1」なる条件で指定しているため、データキーの値は１組に限らない。図４で示したデータテーブル５０の場合、データキーである（「a-label」，「b-label」）の組が、（「山田 太郎」，「1977/1/1」）と（「佐藤 花子」，「1980/3/1」）の２組定まる。なお、データテーブルにデータキーの設定がない場合は、全てのカラムの値をデータキーの値とする。

このように取得したデータキーの値は、監査ログ５２における各データ操作、ひいてはシミュレート用監査ログテーブル５４の各行に対応している。そこで各データキーの値に対応する行をシミュレート用監査ログテーブル５４より抽出し、さらに抽出した行における情報を対象カラム欄５４ｅに記載された対象カラムごとに分類することにより、項目ごとに操作履歴を特定する。図７は図６のシミュレート用監査ログテーブル５４に基づき特定した、データキーの値の組が（「山田 太郎」，「1977/1/1」）であるデータの操作履歴例を示している。操作履歴テーブル５６は、対象カラム欄５６ａ、日付欄５６ｂ、時刻欄５６ｃ、更新区分欄５６ｄ、および更新プログラム欄５６ｅを含む。

シミュレート用監査ログテーブル５４の、着目するデータキーの値に対応する行のうち、操作履歴テーブル５６の対象カラム欄５６ａに記載したカラムが対象カラム欄５４ｅに含まれている行の日付欄５４ａ、時刻欄５４ｂ、更新区分欄５４ｃ、対象プログラム欄５４ｈに記録された各値を、操作履歴テーブル５６の日付欄５６ｂ、時刻欄５６ｃ、更新区分欄５６ｄ、および更新プログラム欄５６ｅにそれぞれ記載する。例えばカラム「a-label」の場合、シミュレート用監査ログテーブル５４の１行目、２行目、４行目の対象カラム欄５４ｅに含まれているため、各行の日付欄５４ａ、時刻欄５４ｂ、更新区分欄５４ｃ、対象プログラム欄５４ｈの値を、操作履歴テーブル５６における対象カラム欄５６ａの「a-label」に対応づけて各欄に記載する。その他のカラムも同様である。

操作履歴テーブル５６によって、各項目のデータがどのような順序でどのプログラムにより操作されるかが示される。すなわち本実施の形態では、初めにデータキーの値を取得し、その値ごとに各項目のデータを分けて解析するため、あるデータが新規で生成されてからの変遷を追うことができる。

なお、「update」の操作によりデータキーの値自体が更新された場合は、当該「update」のＳＱＬ文より更新前後のデータキーの値を取得し、更新前のデータキーの値に対応するデータ操作と、更新後のデータキーの値に対応するデータ操作とを同じデータキーの値に対応するとして扱う。例えば更新前後のデータキーの値の対応表を作成し、操作履歴テーブル５６作成時にシミュレート用監査ログテーブル５４から行を抽出する際に、当該対応表を参照して更新前後の一方のデータキーの値を他方の値に読み替えることにより、同じデータキーの値に対応する行として抽出することができる。

次に、データキーの値ごとの操作履歴を、例えば同一データテーブル内の全データキーの値で集計することにより、操作履歴のパターンを項目ごとに統計分析して更新特性を取得する。すなわち図７に示した操作履歴テーブル５６はデータキーの値の組が（「山田 太郎」，「1977/1/1」）に対するテーブルであったが、これを（「佐藤 花子」，「1980/3/1」）など、データキーの他の値でも同様に作成し、テーブル単位で項目ごとにそれらを集計して分析する。図８は、図７に示した操作履歴テーブル５６などに基づき得られる更新特性を示している。更新特性テーブル６０は、カラム欄６０ａ、項目名欄６０ｂ、テーブル名欄６０ｃ、プログラム名欄６０ｄ、更新区分欄６０ｅ、日付欄６０ｆ、時刻欄６０ｇ、および発生確率欄６０ｈを含む。この更新特性テーブル６０は、出力部３６から出力することによりユーザが確認を行うことを前提とした構造としてよい。

カラム欄６０ａに記載されたカラムに対応する項目が項目名欄６０ｂに記載される。この対応関係は、データテーブル５０を作成した際の付加情報を参照することによって判明する。項目名欄６０ｂに具体的な項目名を記載することによりユーザが理解し易くなる。テーブル名欄６０ｃには集計対象のテーブル名が記載される。これも、具体的なテーブル名が設定されている場合は、そのように記載することでユーザの理解を助ける。プログラム名欄６０ｄおよび更新区分欄６０ｅに記載の値は、操作履歴テーブル５６の更新プログラム欄５６ｅおよび更新区分欄５６ｄに記載の値にそれぞれ対応する。データキーの値によって操作履歴テーブル５６の更新プログラム欄５６ｅおよび更新区分欄５６ｄに記載の値が異なる場合は、それらを全てプログラム名欄６０ｄおよび更新区分欄６０ｅに記載する。

日付欄６０ｆおよび時刻欄６０ｇの値も、操作履歴テーブル５６の日付欄５６ｂおよび時刻欄５６ｃの値にそれぞれ対応する。同図の例は、例えば一日の営業により受け付けた複数の顧客のデータについて夜間などにバッチ処理し、１つのデータテーブル５０を作成している場合を示している。そのため、複数のデータキーの値で操作履歴を集計しても、日付欄６０ｆおよび時刻欄６０ｇの値は一に定まっている。データキーの値によって操作した日時が異なる場合は、日付欄６０ｆおよび時刻欄６０ｇに全ての日時を羅列してもよい。また別の日に行われる操作は色分けしたり線で区分けするなどしておくと、同一のバッチ処理内での関連性の有無を把握し易い。

プログラム名欄６０ｄ、更新区分欄６０ｅに記載された情報は各操作の内容を表しており、それを日付欄６０ｆおよび時刻欄６０ｇに記載された操作日時でソートして表示する。これにより、最初にデータが「insert」、すなわちテーブルに加えられてから、当該データに施される可能性のある操作の順序を操作履歴のパターンとして捉えることができる。

発生確率欄６０ｈには、操作履歴のパターンにおいて各操作が発生する確率を記載する。データキーの値によって操作履歴が条件分岐したりスキップしたりする場合があるため、全データキーのうち各操作がなされる割合を確率として表す。当然、全てのデータキーで同一の操作履歴であれば、各操作の発生確率は１００％となる。当該確率は、全てのデータキーの値で操作履歴を集計した後、統計分析をおこなうことにより取得することができる。

同図１行目に示すカラム「a-label」の場合、項目名はデータテーブル５０に示すように「名前」であり、そのテーブル名は前述のとおり「aaa-table」である。そして「見積もり依頼登録」プログラムによって「insert」された後、「見積もり」プログラムで「select」される確率、その後に「見積もり印刷」プログラムで「select」される確率がいずれも「１００％」であることが、プログラム名欄６０ｄ、更新区分欄６０ｅ、発生確率欄６０ｈよりわかる。

この結果から、「見積もり依頼登録」プログラム、「見積もり」プログラム、「見積もり印刷」プログラム、という順の操作のパターンが存在し、このようなパターンで各操作が１００％発生していることから、「名前」の項目についてはこのパターンが必須であることがわかる。このような情報により、複数のジョブをバッチ処理するシステムなどで、ジョブの処理順における制約を把握することができる。例えば「見積もり依頼登録」プログラムにおいて、オンラインのみで可能であった顧客情報の入力手段に電子メールからのデータ取り込みを追加する場合、当該取り込み処理と、「見積もり」プログラムおよび「見積もり印刷」プログラムの実行順序を十分考慮する必要があることがわかる。また、電子メールからのデータ取り込みなど新たな機能を付加した際、当該機能を追加して実際に処理を実行し、追加前後のデータベースの差を取得することによりその影響を把握することもできる。

一方、同図４行目に示すカラム「ｅ−ｌａｂｅｌ」の項目名「見積もり金額」の場合、プログラム名欄６０ｄに記載された「会計計上」プログラムによる操作は、他のプログラムによる操作と日付が異なることが日付欄６０ｆによりわかる。「見積もり金額」のデータは、「見積もり」プログラムで「select」される確率、「見積もり印刷」プログラムで「select」される確率、「会計計上」プログラムで「select」される確率がいずれも１００％であるが、「会計計上」プログラムで操作される日付けのみ異なることから、バッチ処理時の処理順の制約からは除くことができることがわかる。プログラムのレーベルサーチを行う手法では、プログラムの処理順の制約や操作した日付によるプログラムの関連性などを把握することはできない。

更新特性テーブルを利用することにより、項目を更新特性によって分類することができる。例えば項目とそれを操作するプログラムとの関連づけが項目名欄６０ｂとプログラム名欄６０ｄより明らかとなるため、あるプログラムと関連性のある項目のみを入力項目としたり、入力必須項目を設定したりすることができ、適切な画面設計を行える。例えば図８のような更新特性テーブル６０において、図示しない「車のナンバー」、「現在の保険会社」といった項目が存在し、それらの項目のプログラム名欄６０ｄに「見積もり依頼登録」プログラムがふくまれていなかった場合、それらの項目は当該プログラムへの入力データを最初に入力する際の表示画面、すなわち支店の端末画面などにおいて入力項目から除外できる。同様に、各項目はどのタイミングで入力すべきかなども把握できる。

また、プログラムが提供する諸機能が正常に動作するか否かを確認する際、各機能を動作させるための最適なテストケースを作成することができる。図９はテストケースの作成手法を説明するための図である。同図の更新特性テーブル６２は、例えば図８の更新特性テーブル６０内の図示しない一行を抜き出したものと考えることができる。当該一行は、「特別割引金額」なる項目についての更新特性である。

この「特別割引金額」は、見積もり依頼時に入力される顧客情報から優良ドライバーであると判定できる場合にのみ計算されるとする。このような機能が含まれるプログラムをテストする場合、優良ドライバーと判定される基準かがわからないまま、やみくもにダミーの顧客情報をテストケースとして入力しても特別割引金額を計算する処理を確実に動作させることができない。人手によりプログラムを解析してこの基準を特定し、それに合致するテストケースを作成するのは困難な作業である。

そこで、ある基準でのみ動作する機能が実際に動作したか否かを、対応する項目が更新されたか否かで判断する。そして更新されたケースにおいて実際に入力された情報を取得する、というように処理を逆に辿る。取得した入力情報と同一の情報、あるいは名前など一部の情報をマスクした情報を、当該機能のテストケースとする。この処理は例えば次のように実現する。まず更新特性分析部３２は、操作履歴テーブル５６を集計して更新特性テーブル６２を作成する際、集計対象となったデータキーの値ごとの操作履歴テーブル５６において、更新区分欄５６ｄに「update」（更新）が含まれているデータキーの値を更新時データキー情報として項目別に記録しておく。図９における更新時データキー情報６４では、('山田 太郎','1977/1/1')、('佐藤 花子','1980/3/1')などのデータキーの値が記録されている。

そしてテスト支援部３４は、ユーザの指示によりテストケースを作成する際、ユーザからテストを行いたい機能に対応する項目の入力を受け付け、更新時データキー情報６４を参照し、該当項目、図９の例では「特別割引金額」が更新されているデータキーの値を取得する。なお更新時データキー情報を各項目と対応付けたテーブルを更新特性テーブル６２と別に設けてもよい。

そして取得したデータキーの値に対応づけられたＳＱＬ文のうち、「insert」（追加）を行っているＳＱＬ文を、操作履歴テーブル５６、シミュレート用監査ログテーブル５４と辿ることにより特定する。このＳＱＬ文には、当該データキーについて最初に入力された情報が含まれている。テスト支援部３４は、当該ＳＱＬ文から各項目の入力値を抽出し、上記のようにテストケースを作成し、出力部３６から出力してユーザに提示する。あるいは情報記憶部２２に記憶させておき、テスト開始時にそれを読み込むことによりテスト開始時の入力データとしてもよい。対象の項目の更新操作を操作履歴のパターンから検出する際は、図８の更新特性テーブル６０の発生確率欄６０ｈにおける発生確率が所定のしきい値以上の操作のみを対象に検索するようにしてもよい。

上述の例は「特別割引金額」を計算する機能を動作させるためのテストケースを作成する場合であったが、同様の処理を、プログラムに含まれる全機能について行えば、プログラム全体を入れ替えた場合などに全ての機能を網羅したテストを行うことができる。この場合、ユーザが項目を全指定することにより、テスト支援部３４は全項目に対し必要なテストケースを作成する。確認したい項目とテストケースとが対応しているため、テストが実行されたテストケースを特定することにより、確認したい全項目のうちテストによって確認済みの項目の割合を取得することができる。この情報を出力部３６から出力することにより、ユーザはテストの進捗度合いを確認することができる。

さらにテスト支援部３４は、テストしたいプログラムが実行される直前のデータベース１６の状態を項目ごとに作り出す。図９の例で、「見積もり」プログラムを他の目的で修正したが、「特別割引金額」がこれまで同様に計算されるかをテストしたい場合、更新特性テーブル６２を参照すると、「特別割引金額」を操作するプログラムのうち「見積もり」プログラムの前に実行されるプログラムが「見積もり依頼登録」プログラムであることが特定できる。テスト支援部３４はこの情報を取得すると、プログラム実行部２６を制御して、「見積もり依頼登録」プログラムを終了した時点まで処理を進めた後、テスト対象である「見積もり」プログラムを実行させる。

このようにすることで、項目ごとに必要最低限のプログラムを実行させて、各項目のデータを実運用時の状態に揃えることができる。複数のプログラムをバッチ処理するシステムなどでは、テスト対象が一のプログラムのみであっても、実運用時の状態と条件を揃えるために、バッチ処理を最初から行わざるを得なかった。本実施の形態の更新特性テーブルは、項目別に操作元のプログラムを示すため、バッチ処理されるプログラムのうち、確認したい項目と関連性のないプログラムを実行させずに効率よく実運用時の状態と条件を揃えることができる。

以上述べた本実施の形態によれば、データベースの監査ログを参照して、データベースに実際になされた操作を取得する。そして各操作を再現実行したあと、操作対象の行におけるデータキーの値を抽出する。そしてログに記録されたデータ操作とデータキーの値の対応づけを行い、各項目の操作履歴をデータキーごとに特定する。これにより、同一のデータキーの値に対応づけられた各項目のデータが、データの発生からどのように操作されていくのかを追うことができる。

そしてデータキーごとの操作履歴の情報を所定単位のデータキーで集計することにより、各項目の操作履歴と操作元のプログラムをパターン化し、その中で各操作がどのような確率で発生するかを含む更新特性を導出することができる。これにより、バッチ処理されるプログラムの処理順の制約やプログラム同士の影響の有無を把握することができる。結果としてバッチ処理の構成や一部のプログラムを修正した場合などに、制約に違反する修正を防止でき、本格導入後の障害発生確率を低くすることができる。また、修正がどの程度出力値や他のプログラムに影響を及ぼすかを事前に予測することもできる。

また更新特性として各操作が行われた日付を考慮することにより、プログラムの処理順の前後関係とは別に、同日に行うバッチ処理内での前後関係の制約について知見を得ることができる。この情報から、上述のバッチ処理時の制約から除外することのできるプログラムがわかり、より正確な修正作業や改善を行うことができる。また、項目別に更新特性を得ることができるため、あるプログラムの操作対象であるか否か、といった論理的な基準による分類が可能となり、項目自体の性質を明確に表現することができる。この情報に基づき、ユーザは入力画面の設計が適切であるか否かなどを検討することができる。

さらに、ある条件でのみ動作する機能などがプログラムに含まれる場合、当該動作と項目の更新を紐づけることにより、そのような機能を動作させるための条件を導出することができる。これにより、プログラムをテストする際に適切なテストケースを容易に作成することができ、効率的にテストを遂行することができる。また、項目別に操作元のプログラムの実行順が示されるため、テスト対象のプログラムを実行させる前に、確認したい項目のデータの状態を実運用時の状態に効率的に揃えることができ、テストの効率性および正確性が増す。

現在のデータマイニングは、あるデータのスナップショットを元に解析を行う場合が多いが、本実施の形態ではデータの更新の変遷を時系列で把握できるため、データマイニングより正確な分析が可能となる。例えばデータの変更内容を履歴として保持しないアプリケーションにおいてもデータの変遷を容易に取得できる。そのため、データ変更の履歴を記録するためのアプリケーション開発自体を行わなくてもよくなり、アプリケーション開発の効率が上がる。オンラインの性能を向上させるために、オンライン処理では対象データの更新のみを行い、本実施の機能を利用して履歴データを作成する、といった分担も可能となる。このように、システム全体の性能を向上させたり、アプリケーションの保管機能としても有効である。

また、データのスナップショットを元にしたデータ解析手法では、実運用機でリアルタイムに稼働しているデータベースに対して解析を行うことは実運用機に対する負担となる。そのため、データを開発機等にコピーして解析を行うのが一般的であるが、データ量が多い場合、コピーなどの作業に手間がかかる他、実運用機に対する負担にもなる。一方、本実施の形態では、監査ログをほぼリアルタイムで取得し、解析を同時に実施できるため、より即効性の高いデータ解析が可能となる。

以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

本実施の形態を適用できるシステムの構成例を示す図である。 本実施の形態における第１サーバの構成をより詳細に示す図である。 本実施の形態において監査ログからデータの更新特性を分析する処理手順を示すフローチャートである。 本実施の形態のデータベースにおけるデータの具体例を示す図である。 本実施の形態の監査ログ分析部が取得する監査ログの例を示す図である。 図５の監査ログに基づき監査ログ分析部が生成するシミュレート用監査ログテーブルの例を示す図である。 図６のシミュレート用監査ログテーブルに基づき作成した、操作履歴テーブルを示す図である。 図７に示した操作履歴テーブルに基づき得られる更新特性テーブルを示す図である。 本実施の形態におけるテストケースの作成手法を説明するための図である。

符号の説明

１０ 情報処理システム、１２ 第１サーバ、 １４ 第２サーバ、 １６ データベース、 ２０ データ更新解析部、 ２２ 情報記憶部、 ２６ プログラム実行部、 ２８ 監査ログ分析部、 ３０ 操作履歴取得部、 ３２ 更新特性分析部、 ３４ テスト支援部、 ３６ 出力部、 ５２ 監査ログ、 ５４ シミュレート用監査ログテーブル、 ５６ 操作履歴テーブル、 ６０ 更新特性テーブル。

Claims (8)

1. プログラムを実行してデータベースの各項目に対応するデータを操作する情報処理システムであって、
   データベースのログに記録されたデータ操作ごとに、操作対象のデータを特定するデータキーの値を取得し、各項目に対するデータ操作の履歴を前記データキーの値ごとに表した操作履歴テーブルを作成する操作履歴取得部と、
   前記操作履歴テーブルを、所定単位のデータキーの値で集計し、データ操作の履歴のパターンと各操作の操作元のプログラムとを項目ごとに表した更新特性テーブルを作成する更新特性分析部と、
   前記更新特性テーブルに係る情報を出力してユーザに提示する出力部と、
   を備えたことを特徴とする情報処理システム。
2. 前記操作履歴取得部は、前記ログに記録されたデータ操作を再現実行した後、操作対象のデータに対応するデータのうち、あらじめ設定された項目のデータを抽出することにより、前記データキーの値を取得することを特徴とする請求項１に記載の情報処理システム。
3. 前記更新特性分析部は、前記データ操作の履歴のパターンにおいて各データ操作が発生する確率を取得し、前記更新特性テーブルに表すことを特徴とする請求項１または２に記載の情報処理システム。
4. 前記更新特性分析部は、前記更新特性テーブルに基づき、操作元のプログラムに応じて項目を分類し、
   前記出力部は分類結果を出力することを特徴とする請求項１から３のいずれかに記載の情報処理システム。
5. 前記更新特性分析部は、集計対象のデータキーのうち、データが更新されているデータキーの値を項目別に抽出した結果を更新時データキーテーブルとして作成し、
   プログラムに含まれる所定の機能をテストする際、当該機能によって更新される項目のデータが更新されているデータキーの値を、前記更新時データキーテーブルから検出し、当該データキーの値に対応するデータを最初に追加したデータ操作のログに基づき、当該データキーに対応する入力データをテストケースとして取得するテストケース取得部をさらに備えたことを特徴とする請求項１に記載の情報処理システム。
6. 所定のプログラムをテストして所定の項目に与える影響を確認する際、前記更新特性テーブルを参照して、確認したい項目のデータをテスト対象のプログラムより前に操作するプログラムを特定し、テスト対象のプログラムを実行する前に特定したプログラムを実行することにより、確認したい項目の初期値を準備するテスト支援部をさらに備えたことを特徴とする請求項１に記載の情報処理システム。
7. プログラムを実行してデータベースの各項目に対応するデータを操作する情報処理システムにおいてなされる情報処理方法であって、
   データベースのログに記録されたデータ操作ごとに、操作対象のデータを特定するデータキーの値を取得し、各項目に対するデータ操作の履歴を前記データキーの値ごとに表した操作履歴テーブルを作成するステップと、
   前記操作履歴テーブルを、所定単位のデータキーの値で集計し、データ操作の履歴のパターンと各操作の操作元のプログラムとを項目ごとに表した更新特性テーブルを作成するステップと、
   前記更新特性テーブルに係る情報を出力してユーザに提示するステップと、
   を含むことを特徴とする情報処理方法。
8. 前記操作履歴テーブルを作成するステップは、通常運用において実施されたデータベースに対する操作のログを当該通常運用中に読み出すことにより通常運用と並列に行うことを特徴とする請求項７に記載の情報処理方法。

Images