JP2008293229A - 履歴データ処理装置および方法 - Google Patents
履歴データ処理装置および方法 Download PDFInfo
- Publication number
- JP2008293229A JP2008293229A JP2007137379A JP2007137379A JP2008293229A JP 2008293229 A JP2008293229 A JP 2008293229A JP 2007137379 A JP2007137379 A JP 2007137379A JP 2007137379 A JP2007137379 A JP 2007137379A JP 2008293229 A JP2008293229 A JP 2008293229A
- Authority
- JP
- Japan
- Prior art keywords
- database
- history data
- time
- item
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
【課題】情報量の少ない履歴データを基として、監査証跡の追跡や業務上の問題の原因究明、業務効率の分析に必要な情報として構成すること。
【解決手段】データベース100をアクセスするアプリケーション(110,111)がその履歴データ(120,121)を出力するシステムにおいて、履歴データに含まれる項目のうち、データベースの項目に依存するキーとなる項目と、前述の対応するデータベースの項目とのマッピング情報(140)を定義および管理する手段と、前述のマッピング情報に基づき、履歴データのキーとなる項目の値によって対応するデータベース項目の値を照合し、照合したデータベースの値からその値と関連する他の項目の値を取得し、当該履歴データともに出力する手段(150)を備えることを特徴とする。
【選択図】図1
【解決手段】データベース100をアクセスするアプリケーション(110,111)がその履歴データ(120,121)を出力するシステムにおいて、履歴データに含まれる項目のうち、データベースの項目に依存するキーとなる項目と、前述の対応するデータベースの項目とのマッピング情報(140)を定義および管理する手段と、前述のマッピング情報に基づき、履歴データのキーとなる項目の値によって対応するデータベース項目の値を照合し、照合したデータベースの値からその値と関連する他の項目の値を取得し、当該履歴データともに出力する手段(150)を備えることを特徴とする。
【選択図】図1
Description
本発明は情報システムにおいて、システムやシステムの各部品の稼動状況や運用状況を表したシステムログなどの履歴データの処理に関する。特に、証跡監査やビジネス・アクティビティ・モニタリングにおける証跡追跡や問題分析などを目的とした業務システム(業務アプリケーション)の履歴データの処理に関する。
情報システムの稼動状況などをシステムログなどの履歴データとして蓄積することで、情報システムがダウンしたときなどに、この蓄積した履歴データを分析し、原因究明を行うことを可能とする。また、情報システムにおけるCPUなどのリソースをシステムに割り当てる際、当該システムの履歴データを分析することで適切な割り当てを行うことが可能となる。さらに、Webサーバが出力するサイトのアクセス履歴からは、どのサイトが多く閲覧されているか、どの経路でサイトがアクセスされるかなどを分析することができる。このようにシステムの履歴データはシステムがある時点でどのような状態にあったかを記録し、この情報から様々な目的に応じた情報を分析することができる。
近年では、セキュリティ観点や、法規制に基づく内部統制、戦略的な業務最適化などの観点で、業務の履歴データを蓄積し、分析する必要性に迫られている。情報システムにおいて、業務を履歴は業務を処理するアプリケーションが出力する履歴データである。これを業務の履歴データとすることで、監査証跡の追跡や、不正処理の分析、業務の最適化のための分析を行うことができる。
業務を処理する多くのアプリケーションは図2のようにデータベース100にアクセスし、業務を処理する。データベース100には売上げのような業務データ105や商品マスタ(商品ID,商品名、価格など)や従業員マスタ(従業員ID,氏名、役職など)などのマスタデータ101、102が存在する。業務データ105は、売上げなどの値や、発注・納品状況などの業務の結果や状況を保持し、関連するマスタデータ101,102を商品IDなどのIDコードによって参照している。アプリケーション1(110)は、業務データ105やマスタデータ101、102を参照・更新することで業務を処理する。このとき、業務のさまざまなフェースで履歴データをログファイル120として出力する。このときの履歴データは履歴データを出力した時間や、従業員ID、商品ID、業務によって生じた他のデータなどからなる。例えば、何時に、誰が、どの商品を販売したかというような履歴データとなる。この履歴データから、O月×日12:00にAさんが売った商品は何かというような問い合わせに応えることが可能である。
さらに、アプリケーション1と同じデータベース100をアクセスするアプリケーション2(111)が存在することがあり、このアプリケーション2(111)は履歴データをログファイル121に出力する。このときログファイル120、ログファイル121に出力された履歴データは、アプリケーションは異なるが、データベース100を共有しているため、履歴データに含まれる従業員IDなどが同じ識別子として利用できる可能性があるので、この二つのログファイルから、従業員IDをキーにして、アプリケーション1で不正を行ったある従業員がアプリケーション2で何を行ったかなどの追跡を行うことができる。特開特開2007−48266「監査証跡追跡装置、監査証跡追跡方法および監査証跡追跡プログラム」では、システムのさまざまなレイヤでのログの中から、共有できるデータを抽出することによって、ログ間の関係をすりあわせることにより、監査証跡追跡を可能としている。
しかしながら、アプリケーションの履歴データの出力はアプリケーションの負荷になるのと、ディスクなどの記憶デバイスの格納領域を圧迫するために多量に出すことはできない。したがって、多くの履歴データは、識別できる最小限の情報形態、例えば、従業員を表す情報として従業員IDなどを並べた列として構成されることが多い。これらは定型の数字や文字などの単なる記号列であることが多く、情報システムとしては扱いやすいが、人間にとってそれが実際になんであるのかの判別が困難である。
また、監査証跡の追跡や業務状況の分析などに本来必要なデータの多くは、履歴データに含まれていないことが多い。したがって、様々な履歴データを横断的に分析したとしても、時間軸上に履歴データを並べることができるだけで、報告や分析に必要な情報は別途調査する必要がある。情報システムにおいては必要なデータはデータベースに格納されていることが多い。ただし、情報システムの複雑化や情報量の増大が進み、ある履歴データがどのデータベースの情報をもとに出力されたのかは調べるのは困難である。
さらに、異なった履歴データの値が同じだったとしてもそれが、異なるデータベースから取得されたものであれば、その値が表している意味が異なる可能性がある。例えば、従業員IDとしてXXXXが出力されていたとしても、ある履歴データではAさんを、ある履歴データではBさんをあらわしている可能性がある。にもかかわらず、XXXXをキーにして履歴データを刷り合わせすると、Aさんの履歴とBさんの履歴が混ざったものとなり、正しい監査証跡の追跡ができないことがある。
履歴データとデータベースの関係が明らかになったとしても、履歴データは時間軸上に蓄積されているのに対して、データベースは現在の状態の整合性を保障するものであるので、履歴データの内容からデータベースをアクセスして必要な情報を取り出したとしても、その値が更新されており、履歴データが出力されたときのデータとは異なる場合がある。例えば、ある従業員のIDが含まれる履歴データの業務内容が、現状(現在のデータベースで管理されている内容)の権限では認められるとしても、実は当時はその権限がない場合の可能性もある。
また、システムは変更されるため、同じアプリケーションの履歴データでも同じ、データベースからとは限らない。
本発明は、上述した従来の履歴データの処理においての問題点を解消するため、アプリケーションが出力する履歴データをもとにして、監査証跡の追跡や業務上の問題の原因究明、業務効率の分析に必要な情報を提供することを目的とする。
上述の課題を解決し、目的を達成するために、データベースをアクセスするアプリケーションがその履歴データを出力するシステムにおいて、履歴データに含まれる項目のうち、データベースの項目に依存するキーとなる項目と、前述の対応するデータベースの項目とのマッピング情報を定義および管理する手段と、前述のマッピング情報に基づき、履歴データのキーとなる項目の値によって対応するデータベース項目の値を照合する手段と照合したデータベースの値からその値と関連する他の項目の値を取得し、当該履歴データともに出力する手段を備えることを特徴とする。
また、上記発明において、照合するデータベースの更新履歴やバックアップから過去のある時点でのデータベースの状況を再現する手段と、前述の再現されたデータベースに対して、前述の対応するデータベース項目の値を照合を行う手段を備えることを特徴とする。
また、上記発明において、履歴データが出力された時刻と、前述の再現されたデータベースの時刻を比較し、最も前述の履歴データが出力された時刻に近い、前述の履歴データの時刻の前後となる2つの再現されたデータベースを選択する手段と、前述の再現された2つのデータベースの照合状況に合わせて、出力する情報を切り替える手段を備えることを特徴とする。
本発明にかかる履歴データの処理方法および装置は、業務の履歴となるアプリケーションの履歴データをもとに、履歴データが発生した時点での目的に応じた情報を構成することで、監査証跡の追跡や業務上の問題の原因究明、業務効率の分析などに必要な情報を提供する。
以下に図面に基づいて、本発明を実施するための最良の形態を説明する。
本発明の基本的な構成と考え方を説明する。図1はアプリケーションが出力する業務データから目的に応じた履歴データに基づく情報を再構成する方法を表している。アプリケーション1(110)とアプリケーション2(111)は同じデータベース100にアクセスしている。データベース100には業務データ105やマスタデータ101、102を含み、アプリケーション1(110)とアプリケーション2(111)は、それぞれが処理する業務の内容にしたがって、業務データ105やマスタデータ101、102をアクセスする。
アプリケーション1(110)の履歴データはログファイル120に出力し、アプリケーション2(111)の履歴データはログファイル121に出力する。これらの履歴データは、履歴データが出力されるときの時刻(もしくは時系列の識別子)と、データベース100で管理されている情報に基づいたデータ、アプリケーションが業務を処理するときのデータ(業務アプリケーション実行者やその業務の状況など、ただし、実行者に関する情報や業務状況のマスタデータはデータベースに格納されている場合がある)などから構成される。データベース100の情報はそのままの値で出力されることもあるし、アプリケーションの処理にしたがって加工されたものである可能性もある。
130は目的に応じた履歴データに基づく情報を再構成するために必要な部分であり、データベースと履歴データのデータマッピング定義140とデータベースと履歴データの照合150からなる。データベースと履歴データのデータマッピング定義140はあるアプリケーションが出力する履歴データがどのデータベースの情報に基づいているのかのマッピングを定義している。データベースと履歴データの照合150はログファイル120,121にある履歴データを読み出し、データベースと履歴データのマッピング定義に従い、当該データベースのデータを照合し、目的に応じた情報に再構成する。また、履歴データが出力された時刻にあわせて、当該データベースの過去のスナップショットを構成し、そのスナップショットと履歴データを照合する。過去のデータベースのスナップショットは現状のデータベース100をベースにして、データベース更新履歴170やデータベースバックアップ180から構成する。この照合により、再構成された履歴データに基づく情報160が生成する。
図3は図1で説明した方法を情報システムとして実現するためのシステムブロック図である。LANなどのネットワーク300に次のシステムモジュールが接続されている。図1のデータベース100はCPUや記憶装置をもつ装置で実行するデータベース管理システム310とストレージ装置等に格納されるデータの実体であるデータベース320で構成される。アプリケーション1(110)、アプリケーション2(111)はCPUや記憶装置をもつ装置上で実行するアプリケーション311、同様にデータベースと履歴データの照合150はデータベースと履歴データの照合312で実行、再構成された履歴データに基づく情報160は再構成された情報表示313で表示する。さらに、データベースと履歴データのデータマッピング定義140はデータマッピング定義323、データベース更新履歴170はデータベース更新履歴321、データベースバックアップ180はデータベースバックアップ322、ログファイル120、121はログファイル324のストレージ装置等に格納される。
図4はデータベースと履歴データのデータマッピング定義140の内容を例示したものである。データベースと履歴データのデータマッピング定義140は、ログファイル毎に定義することになる。データベース100はDB1というデータベース識別子で管理されている。その中に含まれる一つの表Table1(401)は列COL1、COL2、COL3をもち、行402において、それぞれ値、DATA1、DATA2、DATA3が格納されているとする。一方、アプリケーション1(110)にからログファイル120に出力された履歴データは、出力時刻であるTIMEとEL1、EL2という項目をもつ。なお、このアプリケーション1(110)はAP1、ログファイル120はLOG1という識別子をそれぞれもつ。履歴データ410では、TIMEの値としてt1、EL1の値としてdata1をもつ。履歴データの項目EL1は、DB1のTABLE1のCOL1が対応している。ただしCOL1のデータ形式はTYPE1であるが、EL1のデータ形式はTYPE2である。この対応をデータベースと履歴データのデータマッピング定義140で表現する。データベースと履歴データのデータマッピング定義140には、アプリケーションとログファイルの対応を表す表420とデータベースと履歴データの対応を表す表430から構成される。表420は項目アプリケーション識別子とログファイル識別子から構成される。例えば、表420ではAP1はLOG1を出力すると管理している。表430は、ログファイル識別子、履歴データ項目識別子、データベース識別子、データベース項目識別子、データ変換定義、キーフラグ、タイムオフセットを含む。データベース項目識別子は、データベースで管理されるデータのスキーマを識別するもので、リレーショナルデータベースであれば表名と列名で表現され、例えば、TABELE1:COL1等で表現する。データ変換定義は、データベース項目識別子のデータタイプと履歴データ項目のデータタイプの関係を表し、必要に応じてタイプ変換を行うだけの情報が必要である。整数(TYPE1)から文字列(TYPE2)への単純なタイプ変換であればTYPE1→TYPE2で表現できる。アプリケーションによっては、数値演算や表記法変換などの加工がなされる場合がある。このときには数式や、表記法名称などで表記することができる。この情報はデータベースと履歴データの照合部分で解釈、実行可能なものであればよい。キーフラグは当該履歴データ項目が、データベースから関連する情報を取得する際に、データベースをアクセスするためのキー値かどうかを表すフラグである。データベースの情報と照合する再に用いる履歴データ項目となる。また、キー値であると、一意性があり、識別子として扱うことが可能である。同じ(もしくは同じ値になるように管理されている)データベースのキー値であれば、他のログファイルの履歴データをこのキー値で刷り合わせることが可能となり、履歴の追跡が容易となる。タイムオフセットはバッチ処理などの処理時間が長いアプリケーションなどで、データベースをアクセスしてから、履歴データを出力するまでのギャップを補正するための時間を入れる。
図5はデータベースと履歴データの照合の構成を表す。データベースと履歴データの照合150は表示情報定義500とデータベースの時系列化を行うモジュール501とキーとなる項目の照合を行うモジュール502と表示するデータ取得するモジュール503から構成される。表示情報定義500は、履歴データの項目を元にして、データベースに格納されている情報を再構成して、目的の情報を取得するための定義である。したがって、表示情報定義500は目的を満たすために取得したい複数の情報の項目リストとして定義される。表示情報定義500には、例として、ログファイルLOG1の項目TIME(LOG1:TIME)と、LOG1の項目EL1(LOG1:EL1)と、この履歴データの元となったデータベースに格納されたデータベース項目と関連する情報、この場合、データベースDB1(100)に管理されている表TABLE1(401)のCOL1に関連する、データベースDB1の表TABLE1の列COL2(DB1:TABLE1:COL2)と同様にCOL3を構成する場合の定義を記載している。
図6を用いてデータベースの時系列化を説明する。データベースの時系列化のモジュール501は、データベース100とデータベース更新履歴170、データベースバックアップ180から、過去のある時点のデータベースのスナップショットを再生成するモジュールである。データベースは現時点状態を保持している。しかし、履歴データは過去のある時点のデータベースに管理されているデータに基づいている。したがって、履歴データの基づいたデータベースの値は、その後、更新や削除があり、現時点でのデータベースの値とは異なる場合がある。このために、できるだけ、過去のデータベースのスナップショットを再生成することが、履歴データをより正しく分析するために必要である。多くの業務に用いられているデータベースはバックアップや更新履歴などが保存されている。これらのデータベースの過去記録を用いてスナップショットを再生成することができる。現時点をT0とし、現時点のデータベース100に格納されているデータの集合であるスナップショット600がまず照合に利用することができる。データベースバックアップ180を取得した時刻をT2とすると、T2の時点でのデータベースのスナップショット602を生成することができる。生成する手段としては、例えば、広く利用されているデータベースのバックアップツールの機能であるバックアップによる回復を用いる。データベース更新履歴170が存在する場合、データベース100やデータベースバックアップ180を起点として、ある時刻T1のデータベーススナップショット601を生成することができる。図6の場合、データベース100からデータベース更新履歴170に基づき、更新操作を逆に進めることで過去の時刻T1のスナップショットを生成できる。逆に、データベースバックアップ180からデータベース更新履歴170に基づき、更新操作を適用することで、時刻T1のスナップショットを生成できる。生成する手段としては、例えば、多くのデータベース管理システムに搭載されている機能を利用することが可能である。データベースの時系列化はこの場合T0,T1,T2の3時刻でのスナップショットであるが、どの時刻のスナップショットが作成できるかは、データベースバックアップ180の状態や、データベース更新履歴170の状態に依存する。
図7はデータベースと履歴データの照合方法(700)のフローチャートである。各ステップでの内容を順に説明する。このとき図4、図5、図6の内容を参照する。
ステップ701では表示情報定義500から照合すべきログファイルとデータベースを確定する。表示情報定義500の例では、ログファイルLOG1とデータベースDB1が確定する。
ステップ702では照合のためのキーとなる項目をデータベースと履歴データのデータマッピング定義140から特定する。データベースと履歴データのデータマッピング定義140の表430の例では、ログファイルLOG1の履歴データ項目EL1の値がキーとなることがわかる。
ステップ703では図6で説明したデータベースの時系列化を行う。このフローチャートではデータベースの時系列化が照合処理の前に生成することとなっているが、照合すべき履歴データの時刻に合わせて、その都度、必要な分だけ生成してもよい。
ステップ704では時系列化したデータベースのうち、照合する履歴データの時刻よりも後で、かつもっとも古いものを選択する。例えば、履歴データの時刻が図6のT0とT1の間であれば、T0を選択する。なお、照合する履歴データの時刻は、表430のタイムオフセットで時刻が補正されている。
ステップ705では、選択したスナップショットのキーとなる項目と履歴データのキーとなる項目をデータベースと履歴データのデータマッピング定義140のデータ変換定義に従って照合する。例えば、表430に基づいて、履歴データ410のEL1の値であるdata1を表430のデータ変換定義TYPE1→TYPE2を適用して、TYPE2であるdata1をTYPE1のDATA1に変換する。DATA1の値をキーとして、表430のデータベース項目識別子の指定に従いデータベースDB1のTABLE1の列COL1を検索し、行402を取得する。
時系列化されたデータベースのスナップショットのうち、ステップ704で選択したスナップショットよりも古いものがない場合、もしくは、古いものがあったとしてもデータベースの運用上、今回照合した値で問題ない場合、ステップ708に飛ぶ。
ステップ708では、表示情報定義に従い、データベースの一致したキー値と関連するデータベースや履歴データの値を取得し、必要に応じて表示する。例えば、表示情報定義500に基づくと、ログファイルLOG1の履歴データ410のTIMEの値t1、EL1の値data1、ステップ705で取得した行402のCOL2の値DATA2、COL3の値DATA3の値の列を構成することになる。
ステップ705において、ステップ704で選択したスナップショットよりも古いものが存在した場合、ステップ706に進む。例えば、図6の時刻T0とT1の間に生成された履歴データはステップ705において時刻T0のスナップショットを用いて照合をおこなう。このとき、データベース上のデータが更新、削除されている可能性がある。このことを確認するためにステップ706、707を行う。データベースの運用などで、更新や削除の可能性がなければ、ステップ706,707は必要ない。
ステップ706では、時系列化したデータベースのスナップショットのうち、照合する履歴データの時刻よりも前で、かつ最も新しいものを選択する。例えば、履歴データの時刻が図6のT0とT1の間であれば、T1を選択する。なお、ステップ704と同様に照合する履歴データの時刻は、表430のタイムオフセットで時刻が補正されている。
ステップ707では、ステップ705の照合処理をステップ706で選択したスナップショットに対して行う。
ステップ707からのステップ708では照合した結果のデータベースの行が、2つのスナップショットに対しての取得できることになる。どちらの行を用いて表示情報を構成すべきかは次の方法による。
図8は、時刻T0におけるスナップショット600と時刻T1におけるスナップショットの間で、キーとなる値の生成、消滅の関係を整理したものである。キーとなる値は一意性があるため、値が変更されたということは、消滅して新に生成したという位置づけで考える。
(a)はT1以前に生成されT0で存在するキーである。
(b)はT1以降に生成されてT0で存在するキーである。
(c)はT1以前に生成されT0とT1の間で消滅したキーである。
(d)はT1以降に生成されてT0以前に消滅したキーである。
(e)はT1以前に生成されてT1以前に消滅したキーである。
T1からT0にかけて生成された履歴データとしてt1、t2、t3が考えられるが、これらの履歴データには(e)のようなキーは出現しない。t2で出力された履歴データを例にステップ708での処理方法を説明する。処理は次の場合に分類できる
(1)(a)の場合はステップ705とステップ707でどちらのスナップショットでもキー値の照合が成功する。
(2)(b)の場合はステップ705では照合が成功するが、ステップ707では失敗する。
(3)(c)の場合はステップ705では照合が失敗するが、ステップ707では成功する。
(4)(d)の場合はステップ705でも照合が失敗し、ステップ707でも失敗する。
(1)(a)の場合はステップ705とステップ707でどちらのスナップショットでもキー値の照合が成功する。
(2)(b)の場合はステップ705では照合が成功するが、ステップ707では失敗する。
(3)(c)の場合はステップ705では照合が失敗するが、ステップ707では成功する。
(4)(d)の場合はステップ705でも照合が失敗し、ステップ707でも失敗する。
(2)(3)に関しては、キーの照合が成功したもので処理を進め、ステップ708で表示情報を生成することになる。
(4)では表示情報を生成することはできない。
(1)の場合は、それぞれのスナップショットにおけるキーと表示情報定義にしていされた関連するデータベース項目の値が変化していない場合は、どちらのスナップショットを選んでも問題ないが、値が異なる場合、例えば、表示情報定義500のCOL2、COL3の値がスナップショット600とスナップショット601で異なる場合、両者を表示して別の判断を促すことが必要である。これは、図9のように、キーはスナップショット600とスナップショット601で変わらないとしても、キーと関連するデータベース項目がValue1からValue2に更新されているためであり、更新の時刻と履歴データの出力の時刻によって、Value1かValue2のどちらかになる。例えばt1とt2の間に更新された場合、t1で出力された履歴データはValue2を用いるべきであり、t2で出力された履歴データはValue1を用いるべきである。しかし、一般に行員時刻がわからないことがあるため、選択ができない。したがって、2つの値を表示することが、正しい感査証跡の追跡や業務の分析、原因究明に寄与する。
100…データベース、110,111…アプリケーション、120,121…履歴データが出力されるログファイル、140…データベースと履歴データのデータマッピング定義、150…データベースと履歴データの照合モジュール、170…データベース更新履歴、180…データベースバックアップファイル、300…ネットワーク、310,311、312,313…CPUや記憶装置を備える装置とその上で実行するプログラムモジュール、320,321,322,323,324…ストレージ装置などデータを格納する装置とデータ。
Claims (6)
- データベースをアクセスするアプリケーションがその履歴データを出力するシステムにおいて、
履歴データに含まれる項目のうち、データベースの項目に依存するキーとなる項目と、前述の対応するデータベースの項目とのマッピング情報を定義および管理する手段と、
前述のマッピング情報に基づき、履歴データのキーとなる項目の値によって対応するデータベース項目の値を照合する手段と、
照合したデータベースの値からその値と関連する他の項目の値を取得し、当該履歴データともに出力する手段
を備えることを特徴とする履歴データ処理装置。 - 前記履歴データ処理装置において、
照合するデータベースの更新履歴やバックアップから過去のある時点でのデータベースの状況を再現する手段と、
前述の再現されたデータベースに対して、前述の対応するデータベース項目の値を照合を行う手段
を備えることを特徴とする履歴データ処理装置。 - 請求項2の履歴データ処理装置において、
履歴データが出力された時刻と、前述の再現されたデータベースの時刻を比較し、最も前述の履歴データが出力された時刻に近い、前述の履歴データの時刻の前後となる2つの再現されたデータベースを選択する手段と、
前述の再現された2つのデータベースの照合状況に合わせて、出力する情報を切り替える手段
を備えることを特徴とする履歴データ処理装置。 - データベースをアクセスするアプリケーションの履歴データを処理する方法において、
履歴データに含まれる項目のうち、データベースの項目に依存するキーとなる項目と、前述の対応するデータベースの項目とのマッピング情報を定義し、
前述のマッピング情報に基づき、履歴データのキーとなる項目の値によって対応するデータベース項目の値を照合し、
照合したデータベースの値からその値と関連する他の項目の値を取得し、当該履歴データの項目とともに情報を生成する
ことを特徴とする履歴データ処理方法。 - 前記履歴データ処理方法において、
照合するデータベースの更新履歴やバックアップから過去のある時点でのデータベースの状況を再現し、
前述の再現されたデータベースに対して、前述の対応するデータベース項目の値を照合する
ことを特徴とする履歴データ処理方法。 - 請求項5の履歴データ処理方法において、
履歴データが出力された時刻と、前述の再現されたデータベースの時刻を比較し、最も前述の履歴データが出力された時刻に近い、前述の履歴データの時刻の前後となる2つの再現されたデータベースを選択し、
前述の再現された2つのデータベースの照合状況に合わせて、出力する情報を切り替える
ことを特徴とする履歴データ処理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2007137379A JP2008293229A (ja) | 2007-05-24 | 2007-05-24 | 履歴データ処理装置および方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2007137379A JP2008293229A (ja) | 2007-05-24 | 2007-05-24 | 履歴データ処理装置および方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2008293229A true JP2008293229A (ja) | 2008-12-04 |
Family
ID=40167894
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2007137379A Pending JP2008293229A (ja) | 2007-05-24 | 2007-05-24 | 履歴データ処理装置および方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2008293229A (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010191873A (ja) * | 2009-02-20 | 2010-09-02 | Nomura Research Institute Ltd | 団体のデータ管理装置 |
JP2012160030A (ja) * | 2011-02-01 | 2012-08-23 | Nippon Telegr & Teleph Corp <Ntt> | 情報更新装置及び情報更新方法 |
CN110532244A (zh) * | 2019-08-20 | 2019-12-03 | 广州华资软件技术有限公司 | 一种轻量级历史系统数据转换方法及其系统 |
-
2007
- 2007-05-24 JP JP2007137379A patent/JP2008293229A/ja active Pending
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010191873A (ja) * | 2009-02-20 | 2010-09-02 | Nomura Research Institute Ltd | 団体のデータ管理装置 |
JP2012160030A (ja) * | 2011-02-01 | 2012-08-23 | Nippon Telegr & Teleph Corp <Ntt> | 情報更新装置及び情報更新方法 |
CN110532244A (zh) * | 2019-08-20 | 2019-12-03 | 广州华资软件技术有限公司 | 一种轻量级历史系统数据转换方法及其系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
González López de Murillas et al. | Connecting databases with process mining: a meta model and toolset | |
US20190317944A1 (en) | Methods and apparatus for integrated management of structured data from various sources and having various formats | |
CN102323945B (zh) | 一种基于sql的数据库管理方法和装置 | |
US7747563B2 (en) | System and method of data movement between a data source and a destination | |
EP2849098B1 (en) | Cross system analytics for in memory data warehouse | |
US9508048B2 (en) | System and method for integrated real time reporting and analytics across networked applications | |
US7099897B2 (en) | System and method for discriminatory replaying of log files during tablespace recovery in a database management system | |
Reeve | Managing data in motion: data integration best practice techniques and technologies | |
CN103582868B (zh) | 操作者状态检查点 | |
US20070294208A1 (en) | Updating a data warehouse schema based on changes in an observation model | |
US9773048B2 (en) | Historical data for in memory data warehouse | |
EP2551773A1 (en) | Data audit module for application software | |
Sarno et al. | Decision mining for multi choice workflow patterns | |
US8738768B2 (en) | Multiple destinations for mainframe event monitoring | |
EP2610749B1 (en) | Database recovery progress report | |
US20190332697A1 (en) | Database schema validations | |
JP2008293229A (ja) | 履歴データ処理装置および方法 | |
KR20120135665A (ko) | 데이터 웨어하우스를 이용한 데이터베이스 구축 방법 및 그 시스템 | |
US20080033995A1 (en) | Identifying events that correspond to a modified version of a process | |
US8635188B2 (en) | Techniques for extracting data from content databases | |
Murphey | Automated Windows event log forensics | |
Elmsheuser et al. | ATLAS Grid Workflow Performance Optimization | |
CN103713987A (zh) | 基于关键词的日志处理 | |
Singh | Extraction Transformation and Loading (ETL) of Data Using ETL Tools | |
US11232243B1 (en) | System and method for employing model repository |