JP2018124828A - 表データ分析プログラム - Google Patents

Abstract

【課題】コンピュータシステムの仕様の理解を支援すること。
【解決手段】表データ分析プログラムは、第１の表データにおける列のうち、複数の種別の値を含む列を種別ごとの列に分類し、前記第１の表データの各行を、それぞれの行が含む値の種別に応じて分類する分類部と、前記分類部による分類結果に基づいて前記第１の表データを加工して第２の表データを生成する加工部と、としてコンピュータを機能させる。
【選択図】図２

Description

本発明は、表データ分析プログラムに関する。

従来、既存のシステムが無い状態において新規なシステムを開発する場合、当該システムの仕様を概念データモデルを使って統一した記法としてステークホルダ間で共有し、次第に明確化していく技術があった（例えば、特許文献１参照）。

このような技術は、トップダウンの流れによって、まず論理設計を行い、次に物理設計に進み、最終的に緻密な設計書として記述してその通りに実装するために概念データモデルを使用するものである。

一方で、既に運用されている現行システムの改変によって新たなシステムを開発する場合、ボトムアップの流れで現行システムの仕様（仕組み、構造）を理解する必要が有る。

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

しかしながら、上記のような従来法では、ボトムアップの流れで現行システムの仕様（以下、「現行仕様」という。）を理解するために、現行仕様をそのまま概念データモデルとして自動的に変換して表すことが困難であった。

現行仕様を理解するための手法として、既存ドキュメント（例えば、システム仕様書、システム設計書、ユーザ利用マニュアル、保守・運用マニュアル）を読み解いたり、システム利用者からヒアリングしたり、システムのプログラムソースコードを解析したりして仕様を理解する方法が有る。

しかし、このような方法は、入手した多種多様な様々な情報を見て総合的に判断する必要があり、様々な過去の知見を保有するベテランの熟練技術者でないと難しい作業である。また、このような方法は、作業量も多いため、多くの開発者でも作業できるように技術レベルの敷居を下げ、かつ、作業量を削減可能な技術が望まれている。

また、仕様書等のドキュメント類が紛失している場合や、現行システムの運用が長期にわたってなされてきたような場合には、システム自体が何度も修正・手直しがされているにも関わらずドキュメント類が現行化されていない場合もあり、このような場合には、ドキュメント類から仕様を抽出するのは困難である。

また、システム利用者にヒアリングする方法でも、得られる情報は、システム利用者が知っていることに限られてしまう。

更に、プログラムソースコードを解析する方法でも、ソースコードで表現されている業務ルールは分析できるが、システムを利用している業務担当者しか知らないローカルルール（見落としやすいマイナールール）などを検出することは困難である。

本発明は、上記の点に鑑みてなされたものであって、コンピュータシステムの仕様の理解を支援することを目的とする。

そこで上記課題を解決するため、表データ分析プログラムは、第１の表データにおける列のうち、複数の種別の値を含む列を種別ごとの列に分類し、前記第１の表データの各行を、それぞれの行が含む値の種別に応じて分類する分類部と、前記分類部による分類結果に基づいて前記第１の表データを加工して第２の表データを生成する加工部と、としてコンピュータを機能させる。

コンピュータシステムの仕様の理解を支援することができる。

第１の実施の形態における分析装置１０のハードウェア構成例を示す図である。 第１の実施の形態における分析装置１０の機能構成例を示す図である。 第１の実施の形態において分析装置１０が実行する処理手順の一例を説明するためのフローチャートである。 テーブルデータの一例を示す図である。 混在が解消されてラベルが付与されたテーブルデータの例を示す図である。 第２の実施の形態における分析装置１０の機能構成例を示す図である。 第２の実施の形態において分析装置１０が実行する処理手順の一例を説明するためのフローチャートである。 第２の実施の形態におけるテーブルデータの例を示す図である。 第２の実施の形態において修正後のテーブルデータの例を示す図である。 第２の実施の形態におけるテーブルデータの手修正の例を示す図である。 第３の実施の形態における分析装置１０の機能構成例を示す図である。 第３の実施の形態において分析装置１０が実行する処理手順の一例を説明するためのフローチャートである。 ノイズに該当する行又は列の一例を示す図である。 第４の実施の形態における分析装置１０の機能構成例を示す図である。 第４の実施の形態において分析装置１０が実行する処理手順の一例を説明するためのフローチャートである。 マルチレイアウト構造の単位の解析を説明するための第１の図である。 マルチレイアウト構造の単位の解析を説明するための第２の図である。 マルチレイアウト構造の単位の解析を説明するための第３の図である。 マルチレイアウト構造の単位が解析されたテーブルデータの例を示す図である。 第５の実施の形態における分析装置１０の機能構成例を示す図である。 第５の実施の形態において分析装置１０が実行する処理手順の一例を説明するためのフローチャートである。 特異点の第１の検出例を示す図である。 特異点の第２の検出例を示す図である。 特異点の第３の検出例を示す図である。 第６の実施の形態における分析装置１０の機能構成例を示す図である。 第６の実施の形態において分析装置１０が実行する処理手順の一例を説明するためのフローチャートである。 第６の実施の形態において入力される複数のテーブルデータの例を示す図である。 第６の実施の形態において関係構造が推定された複数のテーブルデータの例を示す図である。 第７の実施の形態における分析装置１０の機能構成例を示す図である。 概念データモデル図の第１の例を示す図である。 概念データモデル図の第２の例を示す図である。 特異点ごとに列が追加されたテーブルデータの例を示す図である。 概念データモデル図の第３の例を示す図である。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、第１の実施の形態における分析装置１０のハードウェア構成例を示す図である。図１の分析装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、インタフェース装置１０５、表示装置１０６、及び入力装置１０７等を有する。

分析装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って分析装置１０に係る機能を実現する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１０６はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置１０７はキーボード及びマウス等で構成され、様々な操作指示を入力させるために用いられる。

図２は、第１の実施の形態における分析装置１０の機能構成例を示す図である。図２において、分析装置１０は、入力部１１、分類部１２及び加工部１３等を有する。これら各部は、分析装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。

入力部１１は、仕様の分析対象とされているコンピュータシステムのデータベースのデータ（以下、「ＤＢストアデータ」という。）がテキスト形式に変換されたデータ（以下、「テーブルデータ」という。）を格納したファイル（以下、「テーブルデータファイル」という。）を入力する。ＤＢストアデータは、表形式の構造を有するデータである。

分類部１２は、テーブルデータにおける列のうち、複数の種別の値を含む列を種別ごとの列に分類すると共に、テーブルデータの各行を、それぞれの行が含む値の種別に応じて分類する。

加工部１３は、分類部１２による分類結果に基づいて、入力されたテーブルデータを加工することで、当該分類結果が反映されたテーブルデータを生成する。

以下、分析装置１０が実行する処理手順について説明する。図３は、第１の実施の形態において分析装置１０が実行する処理手順の一例を説明するためのフローチャートである。

ステップＳ１００において、入力部１１は、ユーザによって指定されたテーブルデータファイルに格納されているテーブルデータを読み込む。

図４は、テーブルデータの一例を示す図である。図４に示されるように、テーブルデータは、表形式の構造を有する。

続いて、分類部１２は、テーブルデータ内の列方向又は行方向において、種別の異なるデータが混在しているか否かを判定する（Ｓ１１０）。具体的には、分類部１２は、まず、各列について、当該列に含まれる各値の種別を判定する。値の種別の判定には、例えば、「正規表現による分類フィルタ」を用いることができる。当該分類フィルタは、種別ごとに用意されており、各値に各分類フィルタを適用することで、各値の種別を判定することができる。例えば、「電話番号」を表現する分類フィルタに合致した値の種別は、「電話番号」と判定される。そうすることで、複数の種別の値が含まれている列は、種別の異なるデータが混在している列であると判定される。

図４の例では、２列目について、「住所」と「英数字」の２種類のデータが混在していることが判定される。すなわち、１行目について２列目の値は住所であるが、２行目及び４行目の値は、英数字である。一方、１列目、３列目、４列目、５列目については、それぞれ、「氏名」、「メールアドレス」、「年月日」、「数字」の単一の種別の列であると判定される。

また、行方向については、列方向の判定が行われた後に、各行を構成する列の種別の組み合わせの異同によって、各行の種別の異同が判定される。

なお、ＲＤＢ（Relational Database）等のデータベースにおいては、図４に示されるような、２種類以上のデータが混在する列又は行を含むテーブルが構築される可能性は低いが、一般的にレガシーシステムと呼ばれるような、メインフレーム系のシステムにおいては、例えば、記憶容量の削減等の目的のため、図４に示されるような形式のテーブル情報が存在する場合が有る。

列方向又は行方向において複数の種別が混在している場合（Ｓ１１０でＹｅｓ）、加工部１３は、複数の種別が混在している列を種別ごとに分類して、種別の混在を解消する（Ｓ１１１）。すなわち、加工部１３は、複数の種別が混在している列を、種別ごとの列に分類（分割）することで、テーブルデータを加工する。

続いて、加工部１３は、分類された各列及び各行にラベルを付与する（Ｓ１３０）。

図５は、混在が解消されてラベルが付与されたテーブルデータの例を示す図である。図５では、各列に対して、当該列について判定された種別（「氏名」、「住所」、「英数字」、「メールアドレス」、「年月日」、「数値」）がラベルとして付与されている。なお、当初の図４の状態では、「住所」と「英数字」とは同じ列に属していたが、図５では、ステップＳ１１１の作用により異なる列に分類（分割）されている。

また、図５では、各行に対して、「★」又は「○」がラベルとして付与されている。すなわち、「★」は、「氏名」、「住所」、「メールアドレス」、「年月日」及び「数字」を含む行に対して付与されたラベルである。「○」は、「英数字」及び「数字」を含む行に対して付与されたラベルである。なお、同じ種別の行に対して共通のラベルが付与されればよく、「★」及び「○」以外の記号又は文字列等がラベルとして使用されてもよい。

なお、加工部１３は、ラベルが付与されたテーブルデータを、例えば、図５に示されるような表形式で表示装置１０６に表示してもよい。

上述したように、第１の実施の形態によれば、異種類のデータが混在した列を含むテーブルデータについて、種別ごとに列が分類されたテーブルデータに変換することができる。その結果、分かりにくかったテーブルデータの構造の意味の明確性を向上させることができる。すなわち、現行システム等のコンピュータシステムの仕様の理解を支援することができる。例えば、新システム設計等の設計負担を軽減するとともに、データ解析等に高スキル者を不要とすることを可能とすることができる。

次に、第２の実施の形態について説明する。第２の実施の形態では第１の実施の形態と異なる点について説明する。第２の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。

図６は、第２の実施の形態における分析装置１０の機能構成例を示す図である。図６中、図２と同一部分には同一符号を付し、その説明は省略する。図６において、分析装置１０は、更に、分類支援部１４を有する。分類支援部１４は、分析装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。

分類支援部１４は、図５のように自動的に加工（混在の解消及びラベルの付与）されたテーブルデータについて、ユーザの手作業等による更なる分類を支援する。

図７は、第２の実施の形態において分析装置１０が実行する処理手順の一例を説明するためのフローチャートである。図７中、図３と同一ステップには同一ステップ番号を付し、その説明は省略する。

ステップＳ１３０に続いて、分類支援部１４は、現時点のテーブルデータに対する修正の要否を判定する（Ｓ１４０）。現時点のテーブルデータとは、ステップＳ１１１が実行されている場合には、ステップＳ１１１の実行後のテーブルデータをいい、ステップＳ１１１が実行されていない場合には、ステップＳ１００において入力された状態のテーブルデータをいう。修正の要否の判定は、ユーザによる入力の有無に基づいて行われてもよい。例えば、加工部１３によって表示されたテーブルデータに対する修正の要否がユーザによって入力されてもよい。

続いて、分類支援部１４は、テーブルデータの修正のために、新たな分類フィルタが入力されたか否かを判定する（Ｓ１４１）。ここでは、ステップＳ１３０までが実行されることで表示されたテーブルデータが、図８に示される通りであったとする。

図８は、第２の実施の形態におけるテーブルデータの例を示す図である。図８では、「氏名」が「佐藤 誠」である行の「住所」の値が、「大阪府芸術文化管理財団」である。すなわち、図８では、「大阪府芸術文化管理財団」が、誤って「住所」に分類された例が示されている。

この場合、ユーザは、例えば、末尾が「財団」である文字列について、企業名に分類するための分類フィルタを定義し、ステップＳ１１１において利用されるフィルタ群の一つとして追加することができる。なお、新たに追加される分類フィルタは、既存の種別に対応するものであってもよいし、新たな種別に対応するものであってもよい。

新たな分類フィルタが入力されると（Ｓ１４０でＹｅｓ）、当該分類フィルタと既存の分類フィルタとが利用されてステップＳ１００以降が再実行される。その結果、図８のテーブルデータは、図９に示されるように修正される。

図９は、第２の実施の形態において修正後のテーブルデータの例を示す図である。図９では、「住所」の列の右隣に「企業名」の列が追加され、「大阪府芸術文化管理財団」が、「企業名」の列に移動されている。

このような方法をとることによって、例えば、想定した分類フィルタによって分類し切れなかった種別の混在が発見された場合に、分類フィルタを更に追加することで正しい分類を行なうことができる。

一方、分類フィルタでは分類しきれない場合（Ｓ１４１でＮｏ）、分類支援部１４は、ユーザの手修正によって混在を解消するための直接的な修正指示をユーザから受け付ける。例えば、新たな列の追加と、当該列に分類される値とがユーザによって選択される。この場合、分類支援部１４は、テーブルデータに対して新たな列を追加し、選択された値を当該列に移動する（Ｓ１４１）。

図１０は、第２の実施の形態におけるテーブルデータの手修正の例を示す図である。図１０の（１）には、テーブルデータの或る列について、氏名を抽出できる分類フィルタによって氏名の抽出を行なった結果、誤って、「氏名」のデータとして「所長」、「室長」が選択されてしまい、「氏名以外」のデータとして、「主幹研究員」、「主任研究員」、「担当課長」、「主査」等が選択されてしまった例が示されている。なお、「氏名以外」のデータとは、「氏名」として選択されなかったデータをいい、「氏名以外」という種別が存在することを意図するものではない。また、図１０に示されるデータは、便宜上、図４とは異なるデータである。

この場合、ユーザは、（２）に示されるように、「役職」というラベルが付与された新たな列をテーブルデータに追加し、「所長」、「室長」、「主幹研究員」、「主任研究員」、「担当課長」、「主査」等の役職に該当する値を当該列に移動することの指示を入力する。

このようにすれば、例えば、ユーザが、分類フィルタによる自動分類の結果に誤りが有ると気づいた場合に、手修正によって正しい分類結果に導くことができる。

次に、第３の実施の形態について説明する。第３の実施の形態では第２の実施の形態と異なる点について説明する。第３の実施の形態において特に言及されない点については、第２の実施の形態と同様でもよい。

図１１は、第３の実施の形態における分析装置１０の機能構成例を示す図である。図１１中、図６と同一部分には同一符号を付し、その説明は省略する。図１１において、分析装置１０は、更に、ノイズ除去部１５を有する。ノイズ除去部１５は、分析装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。

ノイズ除去部１５は、テーブルデータにおいて、ノイズ（テストデータ等の実際の運用では使われていないデータ）と思われるデータを行又は列において検出した場合に、当該行又は当該列を削除（除去）する。

図１２は、第３の実施の形態において分析装置１０が実行する処理手順の一例を説明するためのフローチャートである。図１２中、図７と同一ステップには同一ステップ番号を付し、その説明は省略する。

ステップＳ１１０又はステップＳ１１１に続いて、ノイズ除去部１５は、テーブルデータの中に、ノイズに該当する行又は列が有るか否かを判定する（Ｓ１２０）。ノイズに該当するか否かは、例えば、補助記憶装置１０２に予め記憶されているキーワードのうちのいずれかが含まれているか否かによって判定されてもよい。いずれかのキーワードが１つでも含まれている場合にノイズに該当すると判定されてもよいし、或るキーワードが所定の割合以上含まれている場合にノイズに該当すると判定されてもよい。この場合、キーワードと共に当該所定の割合が、ノイズ対象を特定するためのルール（規則）として補助記憶装置１０２に記憶されていてもよい。

図１３は、ノイズに該当する行又は列の一例を示す図である。例えば、「ｔｅｓｔ」というキーワードと一致する文字を含むデータが全データのうちの８０％以上に及ぶ列をノイズ対象とするルールが有る場合、図１３における列ｃ１がノイズに該当する。列ｃ１は、２０行中１６行において「ｔｅｓｔ」を含むからである。

また、「旅費太郎」を１つでも含む行をノイズ対象とするルールが有る場合、矩形ｒ１によって囲まれている行がノイズに該当する。

なお、仮に、「旅費太郎」をキーワードと一致する文字を含むデータが全データの８０％以上に及ぶ列をノイズ対象とするルールが有ったとしても、列ｃ２はノイズに該当しない。列ｃ２において、「旅費太郎」の割合は５０％だからである。

ノイズに該当する行又は列が有る場合（Ｓ１２０でＹｅｓ）、ノイズ除去部１５は、当該行又は当該列を削除する（Ｓ１２１）。

上述したように、第３の実施の形態によれば、ノイズに該当する行又は列が削除された状態で、ステップＳ１３０以降の処理を実行することができる。したがって、ステップＳ１３０以降の処理の精度を高めることができると共に、当該処理を効率化することができる。

次に、第４の実施の形態について説明する。第４の実施の形態では第３の実施の形態と異なる点について説明する。第４の実施の形態において特に言及されない点については、第３の実施の形態と同様でもよい。

図１４は、第４の実施の形態における分析装置１０の機能構成例を示す図である。図１４中、図１１と同一部分には同一符号を付し、その説明は省略する。図１４において、分析装置１０は、更に、マルチレイアウト解析部１６を有する。マルチレイアウト解析部１６は、分析装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。

マルチレイアウト解析部１６は、テーブルデータ内におけるマルチレイアウト構造の存在を検出すると共に、当該マルチレイアウト構造の単位を解析する。マルチレイアウト構造とは、図４に示したように、１つのテーブルデータ内において、複数種別が混在した列を含む構造をいう。「マルチレイアウト構造の単位」とは、複数の種別の値を含む列における種別の繰り返しのパタンの単位をいう。

マルチレイアウト構造の検出は、通常、専門知識の豊富な高スキル者が手動で分析し、検出することで行われるが、それではごく限られた特定の人にしか検出できず、広く手法を広めることができない。また、高スキル者の手作業に委ねられるため、高コストとなり普及が阻害される。そこで、本実施の形態では、マルチレイアウト解析部１６がマルチレイアウト構造を自動で検出する。

図１５は、第４の実施の形態において分析装置１０が実行する処理手順の一例を説明するためのフローチャートである。図１５中、図１２と同一ステップには同一ステップ番号を付し、その説明は省略する。

ステップＳ１４０又はステップＳ１４２に続いて、マルチレイアウト解析部１６は、テーブルデータ内にマルチレイアウト構造が存在するか否かを判定する（Ｓ１５０）。マルチレイアウト構造が存在する場合（Ｓ１５０でＹｅｓ）、マルチレイアウト解析部１６は、マルチレイアウト構造の単位を解析する（Ｓ１５１）。

図１６は、マルチレイアウト構造の単位の解析を説明するための第１の図である。図１６の（１）には、列＃１において、住所と氏名とが交互に出現し、他の種別は単一である例が示されている。すなわち、（１）のテーブルデータは、住所と氏名との繰り返しのパタンが２行ごとであり、２行単位の周期性を有する。なお、厳密には、ステップＳ１５１の時点において、列＃１は、ステップＳ１１１の作用により、２つの列に分類されている。したがって、ステップＳ１５１では、当初同じ列であった列の集合ごとに解析が行われる。なお、列＃１〜列＃４は、各列のラベルを抽象的に示す記号である。

この場合の解析結果は（２）に示される通りである。すなわち、マルチレイアウト解析部１６は、２行をマルチレイアウト構造の単位として判定する。また、マルチレイアウト解析部１６は、２行のうちの先頭の行（「住所」を含む行）を、マルチレイアウト構造の「ヘッド構造（ヘッド行）」（主要情報構造）であると判定し、それ以外の行（「氏名」を含む行）を、マルチレイアウト構造の「ボディ構造（ボディ行）」（補助情報構造）であると判定する。

すなわち、マルチレイアウト構造に規則的な周期性が有る場合には、当該周期がマルチレイアウト構造の単位として判定される。

また、図１７は、マルチレイアウト構造の単位の解析を説明するための第２の図である。図１７の（１）には、列＃１のみならず、列＃３（厳密には、列＃３から分類された列の集合）にも周期性が有る例が示されている。但し、列＃１の周期性の単位は２であるのに対し、列＃３の周期性の単位は４である。

この場合の解析結果は（２）に示される通りである。すなわち、マルチレイアウト解析部１６は、各列の周期性（本例では２と４）の最小公倍数である４を全体の行の周期性とみなし、これをもってマルチレイアウト構造の単位と判定する。また、マルチレイアウト解析部１６は、マルチレイアウト構造の単位ごとに、先頭の行をヘッド行と判定し、それ以外の行（図１７では２〜３行目）をボディ行と判定する。

また、図１８は、マルチレイアウト構造の単位の解析を説明するための第３の図である。図１８の（１）には、列＃１のみにおいて種別（種別Ａ及び種別Ｂ）が混在しており、その他の列では種別が混在していない例が示されている。但し、列＃１は、一定周期ではないが、種別Ａと種別Ｂが繰り返し現れる構造になっている。

この場合の解析結果は（２）に示される通りである。すなわち、マルチレイアウト解析部１６は、１〜３行、４〜８行をそれぞれマルチレイアウト構造の単位として判定する。また、マルチレイアウト解析部１６は、マルチレイアウト構造の単位ごとに、先頭の行をヘッド行と判定し、それ以外の行をボディ行と判定する。

なお、マルチレイアウト構造の検出及びマルチレイアウト構造の単位の解析は、例えば、各行における各列の種別の集合をベクトルとし、ベクトルのパタンが存在することを検出し（例えば、ベクトルＡとベクトルＢ）、ベクトルＡの複数回出現とベクトルＢの複数回出現が繰り返されるパタンを見出し、これらの繰り返しの単位をマルチレイアウト構造の単位として判定することで行われてもよい。

なお、マルチレイアウト解析部１６は、マルチレイアウト構造の単位の解析結果を、例えば、図１９に示されるようにテーブルデータに反映してもよい。

図１９は、マルチレイアウト構造の単位が解析されたテーブルデータの例を示す図である。図１９に示されるテーブルデータは、「マルチレイアウトフラグ」の列を含む。また、各列のラベルが、「ＨＥＡＤの場合」及び「ＢＯＤＹの場合」に分類されている。なお、図１９のテーブルデータは、便宜上、図４のテーブルデータとは異なるテーブルデータである。

「マルチレイアウトフラグ」の列は、各行が、ヘッド行であるのかボディ行であるのかを示す列である。すなわち、ヘッド行における当該列の値は「ＨＥＡＤ」であり、ボディ行における当該列の値は「ＢＯＤＹ」である。

また、「ＨＥＡＤの場合」の行は、ヘッド行における各列のラベルを示し、「ＢＯＤＹの場合」の行は、ボディ行における各列のラベルを示す。

上述したように、第４の実施の形態によれば、古い現行システムにありがちな、テーブルデータ内におけるマルチレイアウト構造を自動的に検出することができ、当該マルチレイアウト構造の単位を判定（推定）することができる。その結果、テーブル構造の明確性を向上させることができる。

なお、第４の実施の形態は、第１の実施の形態のみ又は第２の実施の形態のみと組み合わされてもよい。

次に、第５の実施の形態について説明する。第５の実施の形態では第４の実施の形態と異なる点について説明する。第５の実施の形態において特に言及されない点については、第４の実施の形態と同様でもよい。

現行システムを新システムへ移行する場合、現行システム（及びそれを用いた業務）に存在する重要なビジネスルールの検出が漏れてしまい、新システムの開発の下流工程（主にテスト工程）で問題が発見され、開発の手戻りとなることが問題となっている。この問題を解消するために、現行システムの保有するビジネスルール（特に重要なルール）を漏れなく検出する必要があるが、この作業は、現状、経験豊富な高スキル者が現行システムの各種ドキュメントを読み理解したり、現行システムの業務担当者からヒアリングしたり、更に最終手段としては現行システムのソースコードを解析するなどして検出しており、非常に手間と稼動がかかり、そのわりには抜け漏れも発生している。

そこで、第５の実施の形態では、誰でも簡単に現行システムの持つ重要なビジネスルールを検出するため、現行システムの保有するＤＢストアデータに着目し、ＤＢストアデータのみを入力情報として、重要なビジネスルールを発見する例について説明する。

図２０は、第５の実施の形態における分析装置１０の機能構成例を示す図である。図２０中、図１４と同一部分には同一符号を付し、その説明は省略する。図２０において、分析装置１０は、更に、特異点検出部１７を有する。特異点検出部１７は、分析装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。

特異点検出部１７は、ステップＳ１５１までにおいて明らかにされた（推定された）、テーブルデータ内の関係構造に基づいて、数字列ごとに、異端な値（特異点）を検出する。数字列とは、数字のみを値として含む列（すなわち、数値を値とする列）をいう。特異点検出部１７は、特異点を検出することにより、同一のジャンルに属する業務の中で、メジャーな作業に潜むマイナーな作業の兆候を発見し、そこからマイナーな業務ルールを推定することに寄与する。同一のジャンルに属する業務は、１テーブル内の１列に相当すると考え、その中で特異点となる値を検出することによってマイナーなルールの兆候を検出する。

図２１は、第５の実施の形態において分析装置１０が実行する処理手順の一例を説明するためのフローチャートである。図２１中、図１５と同一ステップには同一ステップ番号を付し、その説明は省略する。

ステップＳ１５０又はステップＳ１５１に続いて、特異点検出部１７は、テーブルデータ内に１以上の数字列が有るか否かを判定する（Ｓ１６０）。数字列の判定は、例えば、各列に含まれている値を確認することによって行われる。図１９に示したテーブルデータであれば、ヘッド行及びボディ行の「年月日」の列、ボディ行の「商品番号」の列、ボディ行の「番号」の列、ヘッド行の「電話番号」の列が数字列に該当する。

１以上の数字列が有る場合（Ｓ１６０でＹｅｓ）、特異点検出部１７は、数字列ごとに、特異点の検出を試みる（Ｓ１６１）。例えば、特異点検出部１７は、数字列ごとに、マルチレイアウト構造の各単位について、数字が示す数値の最小値、最大値及び平均値を求め、最小値、最大値、又は平均値において、他の大多数の単位における値とは異なる傾向を示す値（特異点）があれば、当該値を検出する。

図２２は、特異点の第１の検出例を示す図である。図２２では、図１９に示したテーブルデータにおいて、「年月日」の列と、ボディ行の「番号」の列について、マルチレイアウト構造の単位ごとに、最小値（最古年月日）、最大値（最新年月日）、及び平均値（平均年月日）が算出された例が示されている。

図２２の例では、「年月日」の列の最初のマルチレイアウト構造の単位の最古年月日（「１００００１０１」）が、同じ列の他のマルチレイアウト構造の単位の最古年月日から乖離していることが分かる。この場合、特異点検出部１７は、「年月日」の列の最初のマルチレイアウト構造の単位の最古年月日（「１００００１０１」）を特異点として検出し、当該最古年月日が格納されているセルの位置情報を出力する。

ユーザは、この特異点となる値がなぜ大多数の値と異なるのかを調査し、原因となるビジネスルールを、その特異点が持つ意味を知っていると思われる現場の業務担当者等に対するヒアリング等によって発見する。その結果、例えば、図２２の例によれば、ユーザは、１０００年１月１日という値は他の年月日（発送完了日）とは違って返納処理を行なったというローカルルールであるといった、見落としやすいビジネスルールを発見することができる。

又は、特異点の検出は次のように行われてもよい。図２３は、特異点の第２の検出例を示す図である。図２３では、「年月日」の列の値が、当該列内で最も古い年月日（図２３では、１行目の年月日）を基準日として、当該基準日からの積算日の数値列に変換されている。この場合、特異点検出部１７は、当該数値列内において、他とは大きくかけ離れた値を検出する。図２３の例では、０のみが他とは大きくかけ離れていることが検出される。その結果、上記したようなローカルルールの発見を支援することができる。

また、特異点の検出は次のように行われてもよい。図２４は、特異点の第３の検出例を示す図である。図２４では、列＃１及び列＃３が数字列であるとする。

特異点検出部１７は、各数字列について、分散値を算出する（１）。図２４では、列＃１についての分散値が０．１であり、列＃３についての分散値が０．００１であったとする。この場合、列＃１の分散値が最大であるため、特異点検出部１７は、列＃１の中に特異点が有るだろうと推定し（２）、列＃１の値をクラスタリング手法によって分類する（３）。クラスタリング手法としては、例えば、Ｋ−ｍｅａｎｓ法等の公知の手法が用いられればよい。特異点検出部１７は、クラスタリングの結果、相対的に要素数が少ないクラスタに属する値を、特異点として検出する（４）。

ユーザは、当該特異点に基づいて、上述したようなローカルルールを発見することができる。

上述したように、第５の実施の形態によれば、ＤＢストアデータ（テーブルデータ）から特異点を検出し、当該特異点をユーザに通知することができる。ユーザは、当該特異点の原因を調査することでビジネスルールを発見することができる。すなわち、従来法のソースコード解析などの手法では、そこに実装されているルールしか抽出できないため、業務の現場担当者のみが知っているような見落としがちなマイナー業務のビジネスルールを検出することは困難であった。本実施の形態によれば、現行の作業結果を保持しているＤＢストアデータから業務ルール等を抽出するため、このようなマイナーなビジネスルールも検出できる。したがって、高度のスキルを要することなく、重要なビジネスルールの発見を可能とすることができる。

なお、第５の実施の形態は、第４の実施の形態以外の各実施の形態とのみ組み合わされてもよい。

次に、第６の実施の形態について説明する。第６の実施の形態では第５の実施の形態と異なる点について説明する。第６の実施の形態において特に言及されない点については、第５の実施の形態と同様でもよい。

図２５は、第６の実施の形態における分析装置１０の機能構成例を示す図である。図２５中、図２０と同一部分には同一符号を付し、その説明は省略する。図２５において、分析装置１０は、更に、関係性推定部１８を有する。関係性推定部１８は、分析装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。

関係性推定部１８は、複数のテーブルデータ（複数のテーブル）が入力された場合に、テーブル間の関係性（参照関係）を推定する。

図２６は、第６の実施の形態において分析装置１０が実行する処理手順の一例を説明するためのフローチャートである。図２６中、図２１と同一ステップには同一ステップ番号を付し、その説明は省略する。

第６の実施の形態では、ステップＳ１００〜Ｓ１６０又はＳ１６１までが、複数のテーブルデータについて実行される。

図２７は、第６の実施の形態において入力される複数のテーブルデータの例を示す図である。図２７には、テーブルデータＴ１〜Ｔ３の３つのテーブルデータが示されている。

テーブルデータＴ１〜Ｔ３のそれぞれについて、ステップＳ１００〜Ｓ１６０又はＳ１６１までが実行されると、各テーブルデータは、例えば、図２８に示される状態になる。

図２８は、第６の実施の形態において関係構造が推定された複数のテーブルデータの例を示す図である。図２８では、テーブルデータＴ１〜Ｔ３の各列が、カラム１〜７、カラム１１〜１３、又はカラム２１〜２３に分類されている。特に、テーブルデータＴ１については、図２７における２番目の列が、カラム２−１及びカラム２−２に分類されている。なお、各列のラベル及び各行に対するラベルは省略されている。

続いて、関係性推定部１８は、各テーブルデータ間の関係性を推定する（Ｓ１７０）。例えば、テーブルデータ間の関係性は、例えば、一方のテーブルデータのいずれかの列に含まれている全ての値が、他方のテーブルデータのいずれかの列に含まれているか否かにより判定される。一方のテーブルデータのいずれかの列に含まれている全ての値が、他方のテーブルデータのいずれかの列に含まれている場合、当該２つのテーブルデータ間（厳密には当該２つの列の間）には参照関係が有ると判定される。この場合、参照関係にあると判定された２つの列のうち、値の重複の有る列から値の重複の無い列への方向が、参照の方向とされてもよい。値の重複の無い列は、当該列を含むテーブルデータにおいてキーとなる値を格納している列である可能性が推定されるからである。

例えば、テーブルデータＴ１のカラム２−２の全ての値は、テーブルデータＴ２カラム１１に含まれている。また、テーブルデータＴ１のカラム２−２には値の重複が有るのに対し、テーブルデータＴ２のカラム１１には値の重複が無い。したがって、テーブルデータＴ１のカラム２−２は、テーブルデータＴ２カラム１１を参照していると判定される。また、テーブルデータＴ１のカラム７の全ての値は、テーブルデータＴ３のカラム２１に含まれている。また、テーブルデータＴ１のカラム７には値の重複が有るのに対し、テーブルデータＴ３のカラム２１には値の重複が無い。したがって、テーブルデータＴ１のカラム７は、テーブルデータＴ３のカラム２１を参照していると判定される。

関係性推定部１８は、判定結果を示す情報を表示装置１０６に表示してもよい。

上述したように、第６の実施の形態によれば、テーブルデータ同士の関係構造を明確化することができる。テーブル間の関係構造の明確化により、不明だったシステムの仕様やビジネスルールの発見等の容易化を期待することができる。

なお、第６の実施の形態は、第５の実施の形態以外の各実施の形態とのみ組み合わされてもよい。

次に、第７の実施の形態について説明する。第７の実施の形態では第６の実施の形態と異なる点について説明する。第７の実施の形態において特に言及されない点については、第６の実施の形態と同様でもよい。

図２９は、第７の実施の形態における分析装置１０の機能構成例を示す図である。図２９中、図２５と同一部分には同一符号を付し、その説明は省略する。図２９において、分析装置１０は、更に、モデル生成部１９を有する。モデル生成部１９は、分析装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。

モデル生成部１９は、ステップＳ１６１以前の処理結果について、概念データモデルを生成する。現行システム上にあるＤＢストアデータはシステムが複雑かつ大規模になるほどデータ量が大量となり、テーブルデータ数も多くなる。その場合、テーブルデータ同士の関係を構造として理解することが難しくなるため、何らかの方法で図形によって表すと理解がしやすい。そこで、モデル生成部１９は、１テーブルデータを１概念とし、１テーブルデータ内の各列のラベルを当該概念の属性として概念データモデル図（クラス図）を生成して、分かりにくいデータの構造の理解の向上に寄与する。なお、モデル生成部１９は、他の各部と並行して処理を実行してもよい。

例えば、モデル生成部１９は、図２７に示した３種類のテーブルデータが入力されると、入力された状態における各テーブルデータを１個ずつの箱（概念又はクラス）として表し、各テーブル内のカラム（列構造）をクラスの属性として自動変換することで得られる概念データモデル図を表示装置１０６に表示する。

図３０は、概念データモデル図の第１の例を示す図である。図３０において、クラス１は、図２７のテーブルデータＴ１に基づくクラスである。クラス２は、テーブルデータＴ２に基づくクラスである。クラス３は、テーブルデータＴ３に基づくクラスである。各クラスは、対応するテーブルデータが有する列に対応する属性を有する。

また、各テーブルデータについてステップＳ１７０までが実行された時点において、モデル生成部１９は、概念データモデル図を図３１に示されるように更新してもよい。

図３１は、概念データモデル図の第２の例を示す図である。図３１では、クラス１が、クラス１Ｈ及びクラス１Ｂを集約することが示されている。クラス１Ｈは、テーブルＴ１についてステップＳ１５１が実行されることにより解析される、マルチレイアウト構造のヘッド行に対応するクラスである。すなわち、クラス１Ｈは、図２８のテーブルＴ１において、カラム１、カラム２−１、カラム３、カラム４、カラム５、カラム６及びカラム７に値を含む行に対応するクラスである。一方、クラス１Ｂは、テーブルＴ１について図２６のステップＳ１５１が実行されることにより解析される、マルチレイアウト構造のボディ行に対応するクラスである。すなわち、クラス１Ｂは、図２８のテーブルＴ１においてカラム２−２、カラム４及びカラム５に値を含む行に対応するクラスである。なお、クラス１は、複数のマルチレイアウト構造の単位を含む。したがって、クラス１とクラス１Ｈとの多重度は、１対多であり、当該多重度がクラス１とクラス１Ｈとの関係線に付与されている。同様に、クラス１とクラス１Ｂと多重度は、１対多であり、当該多重度がクラス１とクラス１Ｂとの関係線に付与されている。

マルチレイアウト構造のヘッド行及びボディ行が、概念データモデル上で分離して表示されることにより、当該マルチレイアウト構造の把握を容易とすることができる。

また、図３１では、クラス１Ｈとクラス３とが関係線で接続されており、クラス１Ｂとクラス２とが関係線で接続されている。関係線の矢印の方向は、当該関係線に係るクラス間の参照方向に従う。これは、テーブルデータＴ１〜Ｔ３についての図２６のステップＳ１７０の実行結果に基づく。すなわち、ステップＳ１７０では、テーブルデータＴ１のカラム７に係る列が、テーブルデータ３のカラム１に係る列を参照していることが推定される。また、テーブルデータＴ１のカラム２−２に係る列が、テーブルデータ２のカラム１に係る列を参照していることが推定される。なお、図３１では、矢印の元の概念が矢印の先の概念を参照していることを示す。なお、図３１に示されるように、各関係線には、参照関係を有する列のラベル等が付記されてもよい。

更に、図２６のステップＳ１６１の実行結果が概念データモデル図に反映されてもよい。この場合、ステップＳ１６１において、特異点検出部１７は、検出した特異点ごとの列をテーブルデータに追加し、当該列に対して当該特異点を移動する。その結果、図２８のテーブルデータＴ１であれば、例えば、図３２に示されるように更新される。

図３２は、特異点ごとに列が追加されたテーブルデータの例を示す図である。図３２において、テーブルデータＴ１のカラム４は、カラム４−１、４−２、及び４−３に分類されている。カラム４−２は、カラム４に含まれていた特異点「１００００１０１」の移動先の列である。カラム４−３は、カラム４に含まれていた特異点「９９９９９９９９」の移動先の列である。

モデル生成部１９は、このようなテーブルデータＴ１について、図３３に示されるような概念データモデル図を生成してもよい。

図３３は、概念データモデル図の第３の例を示す図である。図３３では、特異点に対応する列（カラム４−２、４−３）についても、クラス１Ｈの属性として明確に示されている。そうすることで、概念データモデル構造を用いて、特異点の情報（特異点の存在）を分かり易く示すことができる。

上述したように、第７の実施の形態によれば、テーブルデータ内及びテーブルデータ間の構造を明確化した結果を概念データモデルを用いて自動変換し表現することによって、テーブルデータの構造の理解を容易化することができる。

なお、第７の実施の形態は、第６以外の各実施の形態とのみ組み合わされてもよい。

また、上記各実施の形態によれば、ＤＢストアデータを入力情報として使用することにより、様々な入力情報を総合的に判断する技量を不要とすることができる。

また、上記各実施の形態によれば、本発明では、現行システムの持つ仕様の情報をＤＢストアデータから抽出することによって、様々なドキュメントやヒアリングやプログラム解析を行なわずに、ＤＢストアデータのみを分析するという唯一の方法によって熟練者でなくても現行システムの仕様を推定することができる。更に、概念データモデルによって、システムの構造を表現することによって、現行システムの仕様を推定する人が分かりやすく理解することができる。

なお、上記各実施の形態において、列と行との概念が入れ替えられてもよい。すなわち、列が行として把握されてもよいし、行が列として把握されてもよい。

なお、上記各実施の形態において、分析装置１０にインストールされるプログラムは、表データ分析プログラムの一例である。テーブルデータは、表データの一例である。分類支援部１４は、受付部の一例である。マルチレイアウト解析部１６は、解析部の一例である。特異点検出部１７は、検出部の一例である。モデル生成部１９は、生成部の一例である。ノイズ除去部１５は、削除部の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０ 分析装置
１１ 入力部
１２ 分類部
１３ 加工部
１４ 分類支援部
１５ ノイズ除去部
１６ マルチレイアウト解析部
１７ 特異点検出部
１８ 関係性推定部
１９ モデル生成部
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
１０６ 表示装置
１０７ 入力装置
Ｂ バス

Claims (7)

1. 第１の表データにおける列のうち、複数の種別の値を含む列を種別ごとの列に分類し、前記第１の表データの各行を、それぞれの行が含む値の種別に応じて分類する分類部と、
   前記分類部による分類結果に基づいて前記第１の表データを加工して第２の表データを生成する加工部と、
   としてコンピュータを機能させることを特徴とする表データ分析プログラム。
2. 前記分類部は、前記種別を判定するための分類情報に基づいて前記第１の表データにおける各値の種別を判定し、前記分類結果に対して更に分類情報が追加された場合には、当該分類情報に基づいて、複数の種別の値を含む列を種別ごとの列に分類する、
   ことを特徴とする請求項１記載の表データ分析プログラム。
3. 前記分類結果に対してユーザによる修正を受け付ける受付部としてコンピュータを機能させる、
   ことを特徴とする請求項１又は２記載の表データ分析プログラム。
4. 前記第２の表データにおける列及び行のうち、所定の規則に合致する列又は行を削除する削除部としてコンピュータを機能させる、
   ことを特徴とする請求項１乃至３いずれか一項記載の表データ分析プログラム。
5. 前記第２の表データにおいて複数の種別の値を含む列における種別の繰り返しのパタンの単位を解析する解析部としてコンピュータを機能させる、
   ことを特徴とする請求項１乃至４いずれか一項記載の表データ分析プログラム。
6. 前記第２の表データにおける数値に係る列について、当該列に含まれる数値の集合の中で、他の数値とは異なる傾向を示す数値を検出する検出部としてコンピュータを機能させる、
   ことを特徴とする請求項１乃至４いずれか一項記載の表データ分析プログラム。
7. 前記第２の表データをクラスとし、前記第２の表データの列を属性とする概念データモデル図を生成する生成部としてコンピュータを機能させる、
   ことを特徴とする請求項１乃至６いずれか一項記載の表データ分析プログラム。

Images