入力文について構文解析を行った後、処理の意味に関係ない部分を除去して抽象構文木を生成し、前記抽象構文木を複数の引数をとり得る各引数に対応する各ノードが同じ階層になるように処理し、前記抽象構文木において、終端記号が出現するノードのうち出現する前記終端記号の種類が前記入力文を呼び出す処理の種類の所定数倍以下となる前記抽象構文木の部分のノードに対応する文字列を含む文字列パターンを、前記入力文を分類するための分類文字列パターンとして生成する、ことを特徴とする名寄せ規則生成方法。前記分類文字列パターンの生成において、前記抽象構文木について、根ノードに対応する第1階層から所定階層の深さまで見て葉ノード以外の節点ノードの非終端記号が同一となる抽象構文木ごとの集合に分類し、前記分類された抽象構文木の集合において、終端記号が出現する各ノードのうち出現する前記終端記号の種類が前記処理の種類の前記所定数倍以下となる共通部分のノードに対応する文字列の箇所を列挙し、前記共通部分のノード以外のノードを無視して得られる抽象構文木の種類を数え上げ、前記数え上げの結果数が所定の上限閾値以上の場合には、前記終端記号の種類が多いノードから順次無視していって前記数え上げの結果数が前記所定の上限閾値よりも少なくなるよう調整する処理を繰り返し実行し、前記数え上げの結果数が所定の下限閾値よりも小さくなった場合には、前記所定階層の深さを深くして、前記抽象構文木を分類する処理、前記抽象構文木を数え上げる処理、および前記数え上げの結果数を調整する処理を繰り返し実行し、前記数え上げの結果数が前記所定の下限閾値以上かつ前記所定の上限閾値よりも小さくなった場合に、前記分類された集合に含まれる抽象構文木に対応するもとの入力文から、前記共通部分のノードに対応する文字列の箇所を残した文字列パターンを、前記分類文字列パターンとして生成する、ことを特徴とする請求項1に記載の名寄せ規則生成方法。入力文について構文解析を行った後、処理の意味に関係ない部分を除去し、かつ複数の引数をとり得る各引数に対応する各ノードは同じ階層になるように処理して前記入力文に対応する抽象構文木を生成する抽象構文木生成部と、前記抽象構文木において、終端記号が出現する各ノードのうち出現する前記終端記号の種類が前記入力文を呼び出す処理の種類の所定数倍以下となる前記抽象構文木の部分のノードに対応する文字列を含む文字列パターンを、観測される各入力文を分類するための分類文字列パターンとして生成する分類文字列パターン生成部と、を備えることを特徴とする名寄せ規則生成装置。前記分類文字列パターン生成部は、前記抽象構文木について、根ノードに対応する第1階層から所定階層の深さまで見て葉ノード以外の節点ノードの非終端記号が同一となる抽象構文木ごとの集合に分類する処理部と、前記分類された抽象構文木の集合において、終端記号が出現する木のノードのうち出現する前記終端記号の種類が前記処理の種類の前記所定数倍以下となる共通部分のノードに対応する文字列の箇所を列挙し、前記共通部分のノード以外のノードを無視して得られる抽象構文木の種類を数え上げる処理部と、前記数え上げの結果数が所定の上限閾値よりも多い場合には、前記終端記号の種類が多いノードから順次無視していって前記数え上げの結果数が前記所定の上限閾値よりも少なくなるよう調整する処理を繰り返し実行する処理部と、前記数え上げの結果数が所定の下限閾値よりも小さくなった場合には、前記所定階層の深さを深くして、前記抽象構文木を分類する処理、前記抽象構文木を数え上げる処理、および前記数え上げの結果数を調整する処理を繰り返し実行する処理部と、前記数え上げの結果数が前記所定の下限閾値以上かつ前記所定の上限閾値よりも小さくなった場合に、前記分類された集合に含まれる抽象構文木に対応するもとの入力文から、前記共通部分のノードに対応する文字列の箇所を残した文字列パターンを、前記入力文を分類するため、分類文字列パターンとして生成する処理部と、を備えることを特徴とする請求項3に記載の名寄せ規則生成装置。コンピュータに、入力文について構文解析を行った後、処理の意味に関係ない部分を除去して抽象構文木を生成し、前記抽象構文木を複数の引数をとり得る各引数に対応する各ノードが同じ階層になるように処理し、前記抽象構文木において、終端記号が出現する各ノードのうち出現する前記終端記号の種類が前記入力文を呼び出す処理の種類の所定数倍以下となる前記抽象構文木の部分のノードに対応する文字列を含む文字列パターンを、各入力文を分類するための分類文字列パターンとして生成する、処理を実行させるためのプログラム。前記分類文字列パターンを生成する処理において、前記抽象構文木について、根ノードに対応する第1階層から所定階層の深さまで見て葉ノード以外の節点ノードの非終端記号が同一となる抽象構文木ごとの集合に分類し、前記分類された抽象構文木の集合において、終端記号が出現する木のノードのうち出現する前記終端記号の種類が前記処理の種類の前記所定数倍以下となる共通部分のノードに対応する文字列の箇所を列挙し、前記共通部分のノード以外のノードを無視して得られる抽象構文木の種類を数え上げ、前記数え上げの結果数が所定の上限閾値よりも多い場合には、前記終端記号の種類が多いノードから順次無視していって前記数え上げの結果数が前記所定の上限閾値よりも少なくなるよう調整する処理を繰り返し実行し、前記数え上げの結果数が所定の下限閾値よりも小さくなった場合には、前記所定階層の深さを深くして、前記抽象構文木を分類する処理、前記抽象構文木を数え上げる処理、および前記数え上げの結果数を調整する処理を繰り返し実行し、前記数え上げの結果数が前記所定の下限閾値以上かつ前記所定の上限閾値よりも小さくなった場合に、前記分類された集合に含まれる抽象構文木に対応するもとの入力文から、前記共通部分のノードに対応する文字列の箇所を残した文字列パターンを、前記分類文字列パターンとして生成する、処理を前記コンピュータに実行させるための請求項5に記載のプログラム。しかし、従来の技術では、HTTPリクエストに基づくURIのような単純な構文ならいいが、SQLストラクチャドクエリランゲージのようなデータベース問い合わせ言語のように文脈自由文法で記述される言語の高速な名寄せは困難であるという問題点を有していた。というのも、構文解析器は一般に遅いからである。また構文解析器の出力する結果は木構造であり、木構造の特定箇所を抽出するよう指定するのは容易ではない。正規表現regularexpressionを使って適当な部分を取り出して比較するシステムが考えられるが、正規表現は構文的な知識を用いることがでず、文法的に不適切な文字列を取り出してしまうことがあるという問題点を有していた。そこで、本発明の課題は、適切な箇所を見るパターンを自動生成することにある。態様の一例では、入力文について構文解析を行った後、処理の意味に関係ない部分を除去して抽象構文木を生成し、前記抽象構文木を複数の引数をとり得る各引数に対応する各ノードが同じ階層になるように処理し、前記抽象構文木において、終端記号が出現するノードのうち出現する前記終端記号の種類が前記入力文を呼び出す処理の種類の所定数倍以下となる前記抽象構文木の部分のノードに対応する文字列を含む文字列パターンを、前記入力文を分類するための分類文字列パターンとして生成する。名寄せのための文字列変換規則に相当するパターンの抽出が自動的に可能になる。また、実時間処理を求められるマッチング時に構文解析という重い処理をしないで、パターンマッチだけで処理が可能になる。以下、本発明を実施するための形態について図面を参照しながら詳細に説明する。以下の説明では、まず、システム可視化の名寄せの一般的な考え方について説明した後、その問題点を明らかにし、その後に、本実施形態について説明する。システムの可視化の例として、インターネット銀行システムで考えてみる。残高照会のトランザクションのモデルを作成するとき、処理中では期間やユーザIDといったトランザクション毎に異なるパラメータもあれば、参照する表のように常に同一なパラメータもある。そのため残高照会のモデルを作成するためには、異なる文字列に表されるイベントを同一視する必要がある。この処理を名寄せと呼ぶ。名寄せとは、本来の意味としては、複数の銀行口座の所有者について、名前、生年月日、住所などの属性情報から、その所有者の同一性を判定することなどを言う。それになぞらえて、文字列中の特定箇所を銀行口座の名寄せの場合でいう属性情報に対応させ、文字列の特定箇所が同じもの同士を同一視する処理を、システムの可視化における名寄せと呼ぶ。すなわち、システムの可視化における名寄せの目的は、イベントの一般化のための文字列の同一視にある。例えば、インターネット銀行システムにおける残高照会の例におけるシステムの可視化では、ユーザや期間といったパラメータは無視して、口座情報を保存してある表のように常に出現する文字列箇所を見て、名寄せが行われる。また例えば、HTTPハイパーテキストトランスファプロトコルを用いたWWWワールドワイドウェブシステム以下、Webシステムと呼ぶの可視化を考える。この場合、HTTPリクエストについて、特定のcgiコモンゲートウェイインタフェースのパラメータが同一のものを同じものと扱うことにより、ユーザ等のパラメータに依らずある種の処理を同じものと見做す名寄せが行われる。例えば、下記の3つのURIユニフォームトリソースロケータ形式のHTTPリクエストを考える。httpservicecomindexhtmluidkuroyanagicom1httpservicecomindexhtmluidtanakacom1httpservicecomindexhtmluidshimizucom1この場合に、それぞれユーザIDを示すuidkuroyanagiuidtanakauidshimizuというパラメータ文字列の箇所に依らず、同一のcom1というパラメータ文字列の箇所を見て、名寄せが行われる。図1は、一般的に考えられる名寄せシステムの構成図である。モデリング装置101は、システムの可視化におけるイベントのモデルを生成する。変換器101-2が、モデルとなるイベントの文字列101-1を入力し、そのイベントの文字列101-1に対して、文字列変換規則101-3に従って変換をし、モデルとなるイベントに対応する変換文字列101-4を出力する。ここで、文字列変換規則101-3は例えば、イベントの文字列101-1に対して構文解析を行って木構造を生成するための規則である。変換器101-2は、この文字列変換規則101-3に従って、イベントの文字列101-1に対して構文解析を行い、モデルとなるイベントに対応する木構造の変換文字列101-4を生成する。マッチング装置102は、システムの可視化におけるイベントのマッチングを実行する。変換器102-2が、実際に観測されたイベントの文字列102-1を入力し、そのイベントの文字列102-1に対して、モデリング装置101における文字列変換規則101-3と同じ文字列変換規則102-3に従って構文解析を行う。そして、変換器102-2は、観測されたイベントに対応する木構造の変換文字列102-4を生成する。そして、各観測されたイベントに対応する変換文字列102-4のうち、同じモデルとなるイベントに対応する変換文字列101-4に変換されたものが、同一のイベントであると判定される。より具体的な名寄せシステムとしては例えば、Webサーバ、アプリケーションサーバ、データベースサーバからなる3階層システムにおいて、各トランザクションを観測して各サービス提供機能の処理時間を算出するようなシステムが一般的に考えられる。このようなシステムでは、各計算機上で動くサービス提供機能に手をいれることなく、ネットワーク上を流れるデータを観測して、システムの動作状況を把握する。そして、このようなシステムでは、予め得られたデータからあるイベントがどういう種類のイベントを起こしたかという関係を木構造で得て、それに観測データをマッチさせることでイベントの間の起動関係を推定し、各トランザクションについてどの階層でどのくらい処理時間がかかったかを把握することを可能にする。あるいは、WebシステムにおけるURIの名寄せを行うような手法も考えられるここで、HTTPリクエストに基づくURIのような単純な構文のみならず、SQLのようなデータベース問い合わせ言語のように、文脈自由文法で記述される言語の名寄せが必要になるケースも多い。しかし、上述のような構文解析のみをベースとする一般的に考えられる技術では、文脈自由文法で記述されるイベント文字列に対して、構文解析木の特定箇所を抽出するように、文字変換規則を指定するのは容易ではない。通常、構文解析木のどの特定箇所に着目し他のどの箇所を無視するかを決定することは、自明ではない。また、構文解析の処理は遅いため、モデリングにおいて構文解析を行うのはよいとしても、マッチングにおいて観測される文脈自由文法で記述されるイベントごとにリアルタイムで構文解析を行うことは、困難である。一方、図1の文字列変換規則101-3、102-3を、無視する文字列の箇所を正規表現によって指定した文字列変換規則として、変換器101-2、102-2で文字列変換を行う技術も、一般的に考えられる。例えば、変換規則を、sSELECTFROMSELECT1FROMg1とする。この変換規則は、入力されたイベントの文字列として、文字列SELECTのあとに、任意の第1の文字列が現れた後に、文字列FROMが現れ、その後に任意の第2の文字列が続いて現れた場合に、SELECT第1の文字列FROMという文字列を変換文字列として出力する規則を指定する。ここで、sABgは、入力された文章全体にわたって文字列パターンAを文字列パターンBに変換する置換演算子を示す。また、上記の変換規則の例1において、上記置換演算子中の文字列パターンBに相当する領域中の1は、文字列パターンAに相当する領域中のの部分を参照して転記することを指定する変数である。上述のような変換規則の例1を使って、例えば、SELECTzandakaFROMtable1WHEREEXISTS2というSQL文として指定される入力されたイベントの文字列を変換することを考える。この場合、本来であれば、SELECTzandakaFROM3という変換文字列を出力したい。しかし、前述の変換規則の例1により、1として、入力されたイベント文字列の例2における第2番目に現れる文字列FROMまでの文字列zandakaFROMtable1WHEREEXISTSというのも困るので、そうなった場合には抽象構文木のより深い階層まで木を見て、さらにパターン分類を行うようにする。分類文字列パターン出力部405は、数え上げの結果数が所定の下限閾値以上かつ所定の上限閾値よりも小さくなった場合に、次の動作を実行する。分類された集合に含まれる抽象構文木に対応するもとの入力文であるイベントの文字列201-1図2から、共通部分のノードに対応する文字列の箇所を残した文字列パターンを、図2の分類文字列パターン201-4として生成する。図5は、本実施形態における文字列パターン201-4の作成の基本的な考え方の説明図である。説明を簡単にするために、例えば入力されたイベントの文字列201-1が、a-1に示される文字列123とa-2に示される文字列123のいずれであっても、bに示される同じ抽象構文木が生成される。そして、図4の抽象構文木数え上げ処理部402により、黒丸で示される数字3に対応するノードが、無視できるノードとされて、cに示されるパターンの木が決定されたとする。このようにして決定された木から、正規表現を含む文字列パターン201-4を作るときに、システムが、どのような規則でイベントの文字列を生成しているかを知る必要がある。そこで、本実施形態では、抽象構文木が生成されるときの元の文字列201-1を保存しておき、それに基づいて、文字列パターン201-4を生成する。例えば、元の文字列がa-1に示される文字列123であれば、文字列パターン201-4はd-1に示される12.となる。また、元の文字列がa-2に示される文字列123であれば、文字列パターン201-4はd-2に示される12.となる。ここで、.は、任意の1文字へのマッチを示す正規表現である。上述の文字列中の括弧は、抽象構文木の生成においては重要でないが、図2の分類文字列パターンへのマッチ器202-2におけるパターンマッチング処理では、たとえ括弧1つでもマッチング性能に影響する。本実施形態では、システムの文字列生成規則に良く適合した文字列パターン201-4を生成することが可能となる。上記構成の本実施形態の詳細な動作について、以下に説明する。本実施形態は、以下のようなシステムを前提とする。まず、本実施形態のシステムは、処理の種類が決まっている。例えば、インターネット銀行の残高照会処理や、入出金明細問合せ処理等である。ここで、処理の種類とは、名寄せの対象となる入力文を呼び出した業務システム上の業務の種類のことをいう。次に、本実施形態のシステムでは、特定の単語が似た意味の構文解析木の異なる場所には出現しない。図6および図7は、同じ単語が違う箇所に出現する例を説明するための図である。図6は、SELECTaFROMtableWHEREEXISTS5というSQL文を構文解析して得られる構文解析木を示す図である。図6の構文解析木では、まず、第1階層の根ノードに文字列が対応付けられる。ここで、で囲まれた文字列を有するノードは、そのノードを表記する記号が非終端記号であって、そのノードの下にさらに下位層のノードが接続されていることを示している。非終端記号文字列に対応するノードの下に接続する第2階層の左から右に向かう6個のノードにはそれぞれ、文字列SELECT、、FROM、、WHERE、が対応付けられる。文字列SELECTは、データベースのテーブルからレコードデータを取得するためのSQL文法のキーワードを示す終端記号である。は、SELECT文によって取得されるテーブルの項目名のリストの文字列を示す葉ノードが対応付いていることを示す非終端記号である。FROMは、参照先のテーブルを指定するためのSQL文法のキーワードを示す終端記号である。は、参照先のテーブル名の文字列を示す葉ノードが対応付いていることを示す非終端記号である。WHEREは、検索条件を指定するためのSQL文法のキーワードを示す終端記号である。は、検索条件の内容を示す文字列を示すノードが対応付いていることを示す非終端記号である。第2階層の文字列に対応するノードの下に接続する第3階層の1つの葉ノードには、実際のテーブル項目名を示す終端記号の文字列aが対応付けられる。第2階層の文字列に対応するノードの下に接続する第3階層の1つの葉ノードには、実際のテーブル名を示す終端記号の文字列tableが対応付けられる。第2階層の文字列に対応するノードの下に接続する第3階層の2つのノードにはそれぞれ、実際の検索条件の内容を示す終端記号の文字列EXISTSと非終端記号の文字列が対応付けられる。第3階層の文字列に対応するノードの下に接続する第4階層の左から右に向かう4個のノードにはそれぞれ、文字列SELECT、、FROM、が対応付けられる。これらの文字列の意味は、既に説明した。第4階層の文字列に対応するノードの下に接続する第5階層の1つの葉ノードには、実際のテーブル項目名を示す終端記号の文字列bが対応付けられる。第2階層の文字列に対応するノードの下に接続する第5階層の1つの葉ノードには、実際のテーブル名を示す終端記号の文字列tが対応付けられる。図6に対して図7は、SELECTcFROMsWHEREEXISTS6というSQL文を構文解析して得られる構文解析木を示す図である。このSQL文6は、前述の図6に対応するSQL文5と比較して、テーブル名tableが、SQL文法上の異なる位置に現れている。すなわち、SQL文5ではFROM句の中に、SQL文6ではEXISTS句内のFROM句の中に、テーブル名tableがそれぞれ指定されている。図7の構文解析木では、まず、第1階層の根ノードに非終端記号の文字列が対応付けられる。文字列に対応するノードの下に接続する第2階層の左から右に向かう6個のノードにはそれぞれ、文字列SELECT、、FROM、、WHERE、が対応付けられる。それぞれの文字列の意味は、図6の場合と同様である。第2階層の非終端記号の文字列に対応するノードの下に接続する第3階層の1つのノードには、実際のテーブル項目名を示す終端記号の文字列cが対応付けられる。第2階層の文字列に対応するノードの下に接続する第3階層の1つのノードには、実際のテーブル名を示す文字列sが対応付けられる。第2階層の非終端記号の文字列に対応するノードの下に接続する第3階層の2つのノードにはそれぞれ、実際の検索条件の内容を示す終端記号の文字列EXISTSと非終端記号の文字列が対応付けられる。第3階層の非終端記号の文字列に対応するノードの下に接続する第4階層の左から右に向かう4個のノードにはそれぞれ、文字列SELECT、、FROM、が対応付けられる。第4階層の非終端記号の文字列に対応するノードの下に接続する第5階層の1つの葉ノードには、実際のテーブル項目名を示す終端記号の文字列dが対応付けられる。第2階層の文字列に対応する葉ノードの下に接続する第5階層の1つのノードには、実際のテーブル名を示す終端記号の文字列tableが対応付けられる。以上のように、図6のSQL文5と図7のSQL文6を比較すると、同じテーブル名tableが、SQL文法中の異なる位置に現れていることがわかる。しかし、本実施形態では、本実施形態が対象とする入力文はシステムがパラメータのみ違える形で生成する文である。従って、同じような処理の種類のグループの中では、同じ意味のテーブル名tableを表わすのに、SQL文5やSQL文6のように、違う形で表現されることは、通常はないとして扱う。上述の前提に加えて、本実施形態では、同じ意味の処理を括弧がついたりつかなかったりというように違う構文で表わすこともないものとして扱う。上述の場合と同様に、本実施形態が対象とする入力文はシステムがパラメータのみ違える形で生成する文だからである。本実施形態では、前述したように、正規表現を設定すべき文字列を、処理の種類に関する知識を用いずに、抽象構文木に対する判別処理により適切に設定することを可能にするものである。具体的には、本実施形態では、次のような処理を実行する。まず、図2の抽象構文木生成部201-2が、全ての入力文について構文解析を行って、さらに抽象構文木を生成する。図8は、抽象構文木の例aとそうでない例bを示す図である。抽象構文木とは、構文解析木のうち、プログラムの意味に関係ない部分とプログラミングに用いる特定のキーワードを省略したものをいう。省略するものには、例えば括弧や、SELECTDELETEUPDATEFROMWHEREORDERBYEXISTなどがあげられる。木構造は構造上その括弧による区切は不要であるため、構文解析木にあった括弧を省略することができる。図8aの例では、例えば、SELECTbalanceFROMaccountyenaccounteuro7という入力文があったとき、このSQL文7のような文脈自由言語の入力文について構文解析を行う。文法規則ごとに新たな節点を作成し、葉はその規則における記号に対応させる。その後、処理プログラムの意味に関係ないグループ化規則のような部分は無視される。上記SQL文7に対して、構文解析では、図8bに示されるような構文解析木が得られるが、これから冗長な部分を取り除くことにより、図8aに示される抽象構文木が得られる。すなわち、図8bに示される構文解析木では、まず、第1階層の根ノードに非終端記号の文字列が対応付けられる。非終端記号文字列に対応するノードの下に接続する第2階層の左から右に向かう6個のノードにはそれぞれ、文字列SELECT、、FROM、が対応付けられる。第2階層の文字列に対応するノードの下に接続する第3階層の1つの葉ノードには、実際のテーブル項目名を示す終端記号の文字列balanceが対応付けられる。第2階層の文字列に対応するノードの下に接続する第3階層の1つの葉ノードには、実際のテーブル名の1つを示す終端記号の文字列accountyenが対応付けられる。さらに、その下方の階層に向かって、同じくテーブル名の1つを示す終端記号の文字列accounteuroなどが順次対応付けられる。一方、図8のaの抽象構文木では、第1階層の根ノードには、図8bの場合と同様に、非終端記号の文字列が対応付けられる。非終端記号文字列に対応するノードの下に接続する第2階層では、図8bの終端記号の文字列SELECTを有する葉ノードと終端記号の文字列FROMを有する葉ノードが除去される。そして、非終端記号の文字列を有するノードと非終端記号の文字列を有するノードが残される。このとき本実施形態では、抽象構文解析木の生成時に、例えばSQL文7のFROM句のテーブル名などの、複数の引数を取れるところの各引数であるテーブル名accountyenやaccounteuroに対応する各ノードは、同一階層に配置される。これは後述するように、同一の階層でこれら複数の引数を有するパターンが同じかどうか判定するためである。本実施形態では、以上のようにして抽象構文木を生成するとき、抽象構文木を生成したもとの入力文のイベント文字列とその抽象構文木とで対応関係を保持しておく。次に、図4の抽象構文木分類処理部401が、構文解析して得られた各抽象構文木について、ある深さまで見て、葉ノード以外の節点ノードの非終端記号が同一で葉ノード部分の終端記号が同一の抽象構文木ごとに、各集合に分類する。なお、葉ノードは、非終端記号は異なってもよい。図9は、本実施形態において、抽象構文木の名寄せで着目する文字列の特定箇所を説明する図である。図9のa、b、cの3種類の抽象構文木が入力されているとする。図9aの抽象構文木は、下記のSQL文から生成される。DELETEEMPLOYEEWHERELNAMEtanaka8そして、図9aの抽象構文では、第1階層の根ノードに非終端記号の文字列が対応付けられる。非終端記号文字列に対応するノードの下に接続する第2階層の2個のノードにはそれぞれ、非終端記号の文字列と非終端記号の文字列が対応付けられる。第2階層の文字列に対応するノードの下に接続する第3階層の1つの葉ノードには、実際のテーブル項目名を示す終端記号の文字列EMPLOYEEが対応付けられる。第2階層の文字列に対応するノードの下に接続する第3階層の1つのノードには、非終端記号の文字列が対応付けられる。第3階層の文字列に対応するノードの下に接続する第4階層の2つのノードには、終端記号の文字列LNAMEと終端記号の文字列tanakaが対応付けられる。図9bの抽象構文木では、図9aの抽象構文木に対して、第4階層の終端記号の文字列tanakaがkuroyanagiに変更された以外は、図9aの抽象構文木と同一である。図9cの抽象構文木も、図9aの抽象構文木に対して、第4階層の終端記号の文字列tanakaがshimizuに変更された以外は、図9aの抽象構文木と同一である。これらの3つの抽象構文木について、根ノードが含まれる第1階層から順に見た場合、第2階層において、非終端記号の文字列と同じく非終端記号の文字列が、図9a、b、cの3つの抽象構文木で同一である。従って、これらの3つの抽象構文木は、1つの集合に分類される。なお、本実施形態では、抽象構文木のノードに対応付けられる条件や表の名前が一部同一のものを同一視はしないが、同一視するように実施することも可能である。次に、図4の抽象構文木数え上げ処理部402が、分類された各抽象構文木の集合で、終端記号が出現する各ノードのうち、その出現する終端記号の種類が処理の種類の所定数倍以下となる共通部分のノードに対応する文字列の箇所を列挙する。そして、それらの共通部分のノード以外のノードを無視して得られる抽象構文木の種類を数え上げる。今、図9に示されるように同一の集合に分類された3つの抽象構文木a、b、cにおいて、終端記号が出現するノードとしては、1種類の終端記号の文字列EMPLOYEEに対応する第3階層のノードがある。また、1種類の終端記号の文字列LNAMEに対応する第4階層のノードがある。さらに、3種類の終端記号の文字列tanakakuroyanagishimizuに対応する第4階層のノードがある。いま例えば、処理の種類が1種類で、所定数倍を1とすれば、上記終端記号が出現するノードのうち、終端記号の種類が処理の種類×所定数倍=1種類のみのノードEMPLOYEEとLNAMEが列挙される。そして、これら2つのノード以外のノードを無視して得られる抽象構文木の種類が数え上げられる。これにより、数え上げの結果は1種類となる。ここで、数え上げの結果数があまりにも多くなって所定の上限閾値以上の場合には、終端記号の種類が多いノードから順次無視していって数え上げの結果数が所定の上限閾値よりも少なくなるように調整する処理を繰り返し実行する。この処理は、図4の数え上げ結果数調整部403により実行される。一方、数え上げの数を減らしすぎて抽象構文木の種類が所定の下限値より小さくなってしまう例えば1つになってしまう、つまり全部を同一視するというのも困るので、そうなった場合にはより深い階層まで抽象構文木を見て、さらに分類を繰り返す。この処理は、図4の階層深さ制御部404により実行される。以上のようにして、数え上げの結果数が適切な数になった場合に、分類された集合に含まれる抽象構文木に対応するもとの入力文から、無視しない共通部分のノードに対応する文字列の箇所を残した文字列パターンを、分類文字列パターンとして生成する。この処理は、図4の分類文字列パターン出力部405により実行される。図10は、名寄せのための変換規則例、すなわち観測される各入力文を分類するための分類文字列パターンの例の説明図である。図9a、b、cの集合に対する上述の数え上げの処理により、図10aに示される分類文字列パターンの木が得られる。図中、黒丸は、数え上げ処理において無視するノード部分である。前述のように、ノードEMPLOYEEとLNAMEが残される。これと、前述した8のもとのSQL文とから、下記のように、無視するノードに対応する文字列部分が正規表現された図10bまたは下記に示される分類文字列パターンが生成される。DELETEEMPLOYEEWHERELNAME8ここで、LNAMEに続くは任意の1文字を指定可能なことを示し、は直前の任意の1文字の繰り返しを許すことを示している。前述したように、本実施形態では、同じ意味を与える文を違う構文で与えることはないと仮定することから、意味に違いのない抽象構文木を与える具体的な構文入力文はもともと同じと考えられる。このため、括弧がついていたりいなかったりという差はないと考えられるため、以上のようにして分類文字列パターンを作ることができる。図11は、抽象構文木の深さと形の同一性との関係の説明図である。前述したように、抽象構文木を集合に分類する際には、根ノードに対応する第1階層から所定階層の深さまで見て葉ノード以外の節点ノードの非終端記号が同一となる抽象構文木をまとめる。この場合、例えば図11aとbに示される2つの抽象構文木は、第2階層までしか見ないなら、葉ノード以外の節点ノードの非終端記号の文字列と非終端記号の文字列が2つの抽象構文木で同一である。このため、2つの抽象構文木は、同じ形と解釈される。一方、第3階層まで見る場合には、葉ノード以外の節点ノードの非終端記号の文字列はとというように2つの抽象構文木で同一ではない。このため、2つの抽象構文木は、違う形と解釈される。このように、根ノードに対応する第1階層から所定階層の深さまで見て葉ノード以外の節点ノードの非終端記号が同一となる抽象構文木をまとめることは、分類文字列パターンの特性を決定する上で、重要な判断要素である。以上説明した本実施形態の動作においては、抽象構文木から共通部分のノードを抽出するための判定基準として、文字列の種類が入力文を呼び出した処理の種類の所定数倍以下となるものを基準として判定している。このため、入力文を呼び出した処理の種類を決定する処理が必要となる。本実施形態では、複数のイベントがあって、あるイベントが別のイベントを引き起こしているとき、引き起こすイベントを親、引き起こされるイベントを子と呼ぶ。例えば、銀行振込みという処理の種類業務種類を依頼するリクエストイベントがユーザコンピュータからアプリケーションサーバに対して送信された場合を考える。このとき、そのリクエストイベントを受信したアプリケーションサーバが、データベースサーバに対して、銀行振込の処理を指定するSQL文のイベントをさらに発行したとする。このとき、銀行振込みを依頼するリクエストイベントが親、それに従って発行されるSQL文のイベントが子となる。2つのイベントefが親子である場合に、イベントの属性a1a1a2a2が関係a1R1a1a2R2a2を満たしているとする。任意の2つのイベントghが関係a1R1a1a2R2a2を満たすとき、gはhの親候補であるという。システム可視化における例:R1R2属性イベントの開始時刻、終了時刻の組関係R1≡s1R2≡q1p2という関係がある。以下に、親候補の種類数の第1の算出方法について説明する。まず、各イベントの文字列に対して親候補を列挙する。システム可視化の場合には、開始終了時刻の包含関係で親子候補は決まる。本実施形態では、同じ種類の各イベントの文字列について、各親候補を調べ、頻度が多い順に累積度数を取って、全体の90が入る種類を候補数とする。例えば、同じ形の文の文字列群、s1s2s3s4s5の親候補の文字列群をそれぞれ、H11H21H12H31H41H12H22H11H51H23H32とする。ここで、H12のうちH1はイベントの種類を表し、添え字は同一イベントのIDを表わす。つまり例えば、H11H12は、同じ種類の別のイベントの文字列である。この結果、親候補の集合Sは、SH21H22H23∪H11H12∪H31H32∪H41∪H51となる。これを添字を削除して頻度順に並べると、H2H2H2H1H1H3H3H4H5となる。左から全体9個の90を取ると切り下げでH1H2H3H4の4種類が、親候補の種類数として決定される。次に、親候補の種類数の第2の算出方法について説明する。第2の算出方法では、既存のモデリング手法を使ってモデリングし、親子関係を確定する。図12は、親候補の種類数の第2の算出方法の説明図である。今、親イベントの文字列H1と、子イベントの文字列S1、S2、S3等との親子関係のパターンとして、図12のa、b、cの3パターンがあったとする。これらのパターンより、既存のモデリング手法により、例えば図12のdに示されるように、H1とS1についてのみ親子関係が確定しその他の子イベントについては任意というようなモデルが決定できたとする。そして、新たなイベントの文字列として、eに示されるS4またはfに示されるS5が入力された場合を考える。この場合、dのモデルを適用することにより、イベントS4またはS5の親候補はH1であるというように親子関係を算出することができる。この場合、誤った名寄せは多少あるかもしれない。しかしそれらは、図12dに示されるように、多少のぶれを吸収できるように広めの範囲をカバーするようなモデルに作成されたモデルにより確定した親子関係を使うことで、親候補を1つに定めることができる。本実施形態では、以上の第1または第2の親候補の種類数の算出方法により、処理の種類を決定すればよい。図13は、図2および図4に示されるモデリング装置201に対応する実施形態の制御処理を示すフローチャートである。このフローチャートは例えば、後述する図17に示されるハードウェア構成を有するコンピュータにおいて、CPU1701がメモリ1702等に記憶された制御プログラムを実行する処理である。以下、このフローチャートの詳細について、図14から図16の動作説明図を参照しながら説明する。以下のフローチャートの制御処理において、処理の種類業務種類がセットされる変数をnとする。また、abcを正の定数とし、b≧aとする。そして、ana×nを、抽象構文木から共通部分のノードを抽出するための判定基準としての、処理の種類の所定数倍として定まる閾値とする。また、bnb×nを、前述した本実施形態の原理説明における数え上げの結果数の所定の上限閾値とする。さらに、cを、前述した本実施形態の原理説明における数え上げの結果数の所定の下限閾値とする。また、所定階層数を制御するための変数Lの初期値を0とする。まず、各入力文について構文解析が行われる図13のステップS1401。さらに、各構文解析木から、処理の意味に関係ない部分を除去し、かつ複数の引数をとり得る各引数に対応する各ノードは同じ階層になるように処理して、各入力文に対応する各抽象構文木が生成される図13のステップS1302。以上の処理は、図2の抽象構文木生成部201-2の機能に対応する。この処理により例えば、3つの入力文から図9のa、b、cに示されるような3種類の抽象構文木が生成される。次に、変数Lの値初期値は0以上で葉ノードが出現する抽象構文木上の最小の階層所定階層の深さがL’とされる。図9a、b、cの例では、終端記号の文字列EMPLOYEEに対応する葉ノードが最初に出現するため、L’3となる。階層L’まで抽象構文木が比較されて、同じ形のものごとに分類される。前述した図9の例では、第3階層において、非終端記号の文字列が、a、b、cの3つの抽象構文木で同一である。従って、これらの3つの抽象構文木が、1つの集合に分類される。続いて、分類された各抽象構文木の集合において、終端記号が出現する各葉ノードにおいて、それぞれの出現する終端記号の種類が数え上げられる。前述の図9の抽象構文木群の例に対しては、図14に例示されるように、終端記号の文字列EMPLOYEEに対応するノードIが1種類、終端記号の文字列LNAMEに対応するノードIIが1種類である。また、終端記号の文字列tanakakuroyanagishimizuに対応するノードIIIが3種類である。その後、所定階層数制御用の変数Lに現在の所定階層数L’の値がセットされる以上、図13のステップS1303。以上の処理は、図2の分類文字列パターン生成部201-3内の図4の抽象構文木分類処理部401の機能および抽象構文木数え上げ処理部402の一部の機能に対応する。次に、ステップS1303で分類された同一の形の抽象構文木の集合ついて、親候補の種類が案出されて、変数nに設定される図13のステップS1304。処理の種類業務種類nは、前述した親子候補の種類数の第1または第2の算出方法に基づいて決定することができる。次に、前述したように、分類された各抽象構文木の集合において、ステップS1303で数え上げられた終端記号が出現する各葉ノードの種類のうち、種類がanの値以下の箇所以外が無視されて、抽象構文木が分類され、種類が数え上げられる図13のステップS1305。いま例えば、処理の種類nが1と求まり、定数aの値が1である場合、anの値は1となる。これにより、図14に示されるノードIIIは無視され、ノードIとIIがカウントされる。この結果、抽象構文木の種類は図15aに示されるように1種類となる。一方例えば、処理の種類nが4と求まり、定数aの値が1である場合、anの値は4となる。これにより、図14に示されるノードI、II、IIIのすべてがカウントされ、無視されるノードは無い。この結果、抽象構文木の種類は図15bに示されるように、3種類となる。以上の処理は、図2の分類文字列パターン生成部201-3内の図4の抽象構文木数え上げ処理部402の一部の機能に対応する。次に、ステップS1305で数え上げられた抽象構文木の種類が、所定の上限閾値bn以上であるか否かが判定される図13のステップS1306。この処理は、図2の分類文字列パターン生成部201-3内の図4の数え上げ結果数調整部403の一部の機能に対応する。数え上げられた抽象構文木の種類が所定の上限閾値bn以上でステップS1306の判定がyesならば、ステップS1307が実行される。ここでは、現在処理している抽象構文木の集合において、終端記号の種類が最も多いノードが除かれて無視され、再び抽象構文木の種類がカウントされる。例えば、前述したように、an4である場合において、ノードI、II、IIIのすべてがカウントされて抽象構文木の種類3となった場合図15bの場合で、変数bの値を1とすれば、抽象構文木の種類3は、bnの値3以上となる。この場合には、ステップS1307で、図15bに示される抽象構文木の集合において、終端記号の種類が3種類図14参照と最も多いノードIIIが除かれて無視される。その後再び、数え上げられた抽象構文木の種類が分類して数え上げられ図13のステップS1307→S1308、所定の上限閾値bnよりも大きいか否かが判定される図13のステップS1308→S1306。上述の例では、ノードIIIが無視された結果、抽象構文木の種類が、図15aに示されるように1種類となる。そして、ステップS1306の判定がnoとなる。以上の処理は、図2の分類文字列パターン生成部201-3内の図4の数え上げ結果数調整部403の一部の機能に対応する。数え上げられた抽象構文木の種類が所定の上限閾値bn以下となりステップS1306の判定がnoならば、数え上げられた抽象構文木の種類が所定の下限閾値cより小さいか否かが判定される図13のステップS1309。この処理は、図2の分類文字列パターン生成部201-3内の図4の階層深さ制御部404の一部の機能に対応する。数え上げの数を減らしすぎて抽象構文木の種類が所定の下限値より小さくなってしまう例えば1つになってしまう、つまり全部を同一視する状態になってしまう場合には、ステップS1309の判定がyesとなる。この場合には、ステップS1303に戻って、より深い階層まで抽象構文木を見て、さらに分類が繰り返される。つまり、変数Lの値現在は3になっている以上で葉ノードが出現する抽象構文木上の最小の階層所定階層の深さがL’とされる。この処理は、図2の分類文字列パターン生成部201-3内の図4の階層深さ制御部404の一部の機能に対応する。ステップS1309の判定がnoならば、上述の数え上げの処理により、例えば図16aに示される抽象構文木から、図16bに示される分類文字列パターンの木が得られる。図中、黒丸は、数え上げ処理において無視するノード部分である。この例では、ノードEMPLOYEEが残される。これと、例えば図16cに示される元のSQL文、DELETEEMPLOYEEWHERELNAMEBrown9とから、下記のように、無視するノードに対応する文字列部分が正規表現された図16dまたは下記に示される分類文字列パターンが生成される。DELETEEMPLOYEEWHERE10ここで、LNAMEに続くは任意の1文字にマッチする正規表現を示し、は直前の任意の1文字の繰り返しにマッチする正規表現を示している。この動作原理については、図5を使って前述した。なお、上述の例では、残されたノード部分はEMPLOYEEの1種類である。これに対して、この部分のパターンが複数種類残った場合には、それぞれのパターンを含む上記10式と同様の分類文字列パターンが複数パターン生成される。以上説明した実施形態により、名寄せのための文字列変換規則に相当するパターンの抽出が自動的に可能になる。また、実時間処理を求められるマッチング時に構文解析という重い処理をしないで、パターンマッチだけで処理が可能になる。図17は、上記名寄せシステムをソフトウェア処理として実現できるコンピュータのハードウェア構成の一例を示す図である。図17に示されるコンピュータは、CPU1701、メモリ1702、入力装置1703、出力装置1704、外部記憶装置1705、可搬記録媒体1709が挿入される可搬記録媒体駆動装置1706、及び通信インタフェース1707を有し、これらがバス1708によって相互に接続された構成を有する。同図に示される構成は上記システムを実現できるコンピュータの一例であり、そのようなコンピュータはこの構成に限定されるものではない。CPU1701は、当該コンピュータ全体の制御を行う。メモリ1702は、プログラムの実行、データ更新等の際に、外部記憶装置1705或いは可搬記録媒体1709に記憶されているプログラム又はデータを一時的に格納するRAM等のメモリである。CUP1701は、プログラムをメモリ1702に読み出して実行することにより、全体の制御を行う。入出力装置1703は、ユーザによるキーボードやマウス等による入力操作を検出し、その検出結果をCPU1701に通知し、CPU1701の制御によって送られてくるデータを表示装置や印刷装置に出力する。外部記憶装置1705は、例えばハードディスク記憶装置である。主に各種データやプログラムの保存に用いられる。可搬記録媒体駆動装置1706は、光ディスクやSDRAM、コンパクトフラッシュ等の可搬記録媒体1709を収容するもので、外部記憶装置1705の補助の役割を有する。通信インターフェース1707は、例えばLANローカルエリアネットワーク又はWANワイドエリアネットワークの通信回線を接続するための装置である。本実施形態によるシステムは、図13のフローチャート等で実現される機能を搭載したプログラムをCPU1701が実行することで実現される。そのプログラムは、例えば外部記憶装置1705や可搬記録媒体1709に記録して配布してもよく、或いはネットワーク接続装置1707によりネットワークから取得できるようにしてもよい。