JP5033322B2 - 連結関係情報を用いた情報管理方法及び装置 - Google Patents

Description

本発明は、異なるテーブル間での情報間の関連付け方法に関する。特に、情報と情報が関係付けられた連結関係にあるとき、その情報および情報関係定義の生成方法、連結される情報の検索処理方法とその装置に関する。特に企業の業績測定を行うためにデータを集計する階層構造あるいは、ナレッジマネジメントにおける知識情報を取り出すための関係情報をマスタの中に持たせるのではなくマスタ間を連結させる情報として外部テーブルに持たせて管理する情報処理に関する。

業務プログラムなどをオブジェクト指向型で開発する場合、必要とされる情報と情報間の連結関係を分析し、ＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）に代表されるようなダイヤグラムなどで情報モデルとして定義してプログラム設計とＤＢ設計に繋げる。特にＤＢ設計時において、あるテーブルのキーと他のテーブルと関係を持つための連結関係のキーを見出して同一テーブル内に定義する必要があるため、情報の連結関係の定義については情報モデルを元にして、人間系での再設計が必要となる。

図２はＵＭＬを使用して、その情報の分析結果である情報モデルをＤＢ設計へと展開した例である。ＵＭＬでは、工場、原価部門、製品グループ、製品、販売などはクラスと呼ばれ、システム分析をする者は、クラス名を定義するとともにそのクラスの中に各種の属性の情報を定義し、それぞれのクラスの関係を関連種別線などで表し、クラスとクラスの関係の多重度を定義する。このようにクラスは情報をグループ化する。

図２の中で製品グループのクラスのように上下に別のクラスと関係を持つものは、検索時にその関係をたどって検索する場合、クラス間を関係付ける情報をＤＢの同一のテーブル内に持つ必要がある。このため、検索時のことを想定しながらＤＢのテーブル設計を行なう必要がある例えば図２の例においては、工場マスタと製品グループマスタに共通の属性「工場コード」が格納されている。

さらに、業務プログラムでは目的の情報を得るために、各テーブル内に定義されている連結関係を事前に知ったうえで利用しなければならない欠点があり、情報と情報の関係に変化が生じたような場合、それぞれのテーブルの連結関係を調査し、ＤＢの設計をやり直す必要がある。

このような問題を解決するための技術として特許文献１に記載の技術が提案されている。特許文献１記載の技術は、各種情報を関係付けて管理する関係付け情報管理システムであって、少なくとも各種情報の識別情報で親と子の関係付けを格納する関係管理テーブルと、指定された情報と範囲で関係管理テーブルの関係付けにより親から子、子から親へ各種情報の検索処理を行う検索処理手段とを備え、識別情報は、ＩＤ、ＦＡＴ情報、ＦＡＴ内記録アドレス、ファイル種別、ディレクトリパス、ファイル名、選択範囲、オブジェクト、属性、または属性を持つ情報を含み、また、各種情報は、識別情報と詳細情報からなるメンバーデータを格納するメンバー管理テーブルで管理される。

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

しかし、上記従来技術には未だ考慮されていない課題が残っており、本発明はその課題の一部を解決しようとするものである。課題の一部を例示すれば以下のとおりである。

業務プログラムが連結関係にある情報を得るためには、テーブル間の連結関係を司るキー情報を知った上で、その関係を順番にたどって最終的に目的の情報を取得する検索処理方式となるため、連結関係の階層分だけのアクセスが必要となりアクセス効率が低下する点は考慮されていない。

さらに、組織情報に代表されるように、情報の関係に構造変化が生じるような場合、ＤＢ内の組織情報が変わってしまうため、従来の情報の連結関係を元にした各種の集計や未来の情報関係を事前定義してシミュレーションに利用したり、情報変更作業のために前もって登録しておいたりすることができず、しかも情報の関係構造が変化すると、業務プログラムの検索インタフェースの変更が伴う場合があるなどの点も考慮されていない。

ほかに従来技術はＵＭＬなどの情報モデルからＤＢ設計に直接つなげられないこと、連結関係の階層分だけテーブル結合やそのためのアクセスが発生すること、連結関係に変化が生じた場合はＤＢ設計を見直す必要があること、過去や未来の情報の連結関係を元にした業務プログラムからの利用ができず、情報の連結関係の構造変化が生じた際、場合によっては業務プログラムの検索インタフェースを変更する必要があること、などの課題があった。

本発明の目的は、上記従来技術の課題を解決し、従来に比べてより使い勝手の良い情報管理システムを提供することにある。

本発明の一手段について説明する。本発明に係る情報管理装置は、入力部と記憶部と情報処理部を備える。前記記憶部には、連結ピンテーブル名称毎に親キー情報と子キー情報とを関連付けたレコードを複数有する複数の連結ピンテーブルと、アクセスパステーブル名称毎に任意の前記複数の連結ピンテーブルの各々を階層的に定義付けた複数のアクセスパステーブルと、が格納されている。前記情報処理部は、前記入力部を介して入力された前記親キー情報及び前記子キー情報を取得すると、前記複数の連結ピンテーブルを参照して前記親キー情報を有する連結ピンテーブル及び前記子キー情報を有する連結ピンテーブルを特定し、さらに前記複数のアクセスパステーブルを参照して、前記特定した二つの連結ピンテーブルが定義されたアクセスパステーブルを検索し、該検索された複数のアクセスパステーブルにおいて前記親キー情報と前記子キー情報との階層関係が最短の前記アクセスパステーブルを特定し、該特定したアクセスパステーブルと前記親キー情報、子キー情報に基づき前記検索処理を行う、ことを特徴とする。

本発明によれば、テーブル間を関連付けするテーブルを用いた情報管理方法において、従来より使い勝手を向上させた情報管理が可能となる。

以下に本発明の実施の形態を図面を参照して詳細に説明する。

＜システム構成＞
図１は本発明を実現するシステムの構成の一例を示したものであり、この図において、１０１はＵＭＬなどに代表される情報の関連をダイヤグラムで表した情報モデル、１１４は情報の関係を管理者などがメンテナンスするための画面、１０２は１０１や１１４の内容を入力する入力装置、１０３は入力した内容を解釈してＤＢのマスタレコードの定義に変換したり、マスタへのアクセス要求を制御したりするためのマスタ制御装置、１０４は１０３で変換された定義内容を管理するためのマスタ定義装置、１０５はマスタテーブルの実体であり、１０６は情報の関係を解釈して連結ピンテーブルを生成したり、連結関係のアクセス要求を処理する連結ピン制御装置、１０７はその連結ピンを管理するための連結ピン定義装置、１０８は連結ピンテーブルの実体、１０９は連結ピンテーブルをアクセスするためのパスを解釈して生成したり、パスを使った検索要求を制御するためのアクセスパス制御装置、１１０はアクセスパスを管理するためのアクセスパス定義装置、１１１はアクセスパステーブルの実体、１１２は検索要求を受けてその内容を解釈し、検索処理を行うための検索処理装置、１１４はこれらの装置を使用する業務プログラムである。ここで、連結関係とは、あるクラスと他のクラスの間に、１対多、多対１、１対１のように構造的な関係がある（ＵＭＬでいう「関連がある」）場合において、クラス間の関連のキーとなる属性（attribute）間の関係、あるいはこれらクラスをテーブルとして実装した場合におけるテーブル間の、関連のキーとなるデータ項目間の関係をいう。

また、あるクラスが他のクラスの一部を構成しているようなとき、つまり、第１のクラスと第２のクラスが１対多の関係にあるとき、第１のクラスは第２のクラスを集約する関係にあると呼ぶ。どの程度集約しているかを多重度（クラス間の関連種別線の横に「１」「１…＊」のように記載）で表す。「集約」は「関連」の特別な形である。この場合において、第１と第２のクラスをテーブルとして実装した場合に、第１のクラスに属する属性のうち１以上の属性は第２のクラスに属するいずれかの属性に対し、１対多の連結関係となる。図２においては、工場クラスと製品グループが１対多（１以上）の関係にあるので、工場クラスは製品グループを集約する関係にある。

本発明の実施形態による情報管理方法を実施するシステムは、情報モデル入力装置１０２、マスタ制御装置１０３、マスタ定義装置１０４、連結ピン制御装置１０６、連結ピン定義装置１０７、アクセスパス制御装置１０９、アクセスパス定義装置１１０、検索処理装置１１２を備えて構成される。そして、これらの装置相互間は、図１に示すように、ネットワークによって通信可能に接続されている。ネットワークは、インターネット、公衆通信網等であってよい。

各装置のメモリ上には、各機能を実現するプログラムが格納され、各装置のＣＰＵによって実行される。また、その磁気ディスク等による二次記憶装置上には、マスタテーブル１０５、連結ピンテーブル１０８、アクセスパステーブル１１１を格納した記憶装置が接続されている。前述した各テーブルは、前述の各プログラムによってアクセスされる。各装置は機能的に分割して図に示しており、各装置の分割統合はあり得る。

当該システムにおける各装置は、１つまたは複数のサーバ計算機、ＰＣ等であってよい。図１５に示すように、１つの計算機で当該システムを実装した場合、前述の各装置は、メモリ１５０４にロードされＣＰＵ１５０１により実行されるプログラムとして実装することができる。またこの場合各装置間の前述のネットワークは物理的なネットワークでなく、論理的なものである。さらにこのとき、マスタテーブル１０５、連結ピンテーブル１０８、アクセスパステーブル１１１を格納した二次記憶装置１５０５をさらに備え、各テーブルは各プログラムによってアクセスされる。プログラムとして各装置が実装される場合も、各プログラムの分割統合はあり得る。

本発明の実施形態による情報管理システムは、情報モデルの入力を受け付けるキーボードやマウス等の入力装置１５０３及び管理画面を表示する表示装置１５０２を備えて構成され、業務プログラムとのインタフェース１５０６を備える。

＜マスタテーブルの生成処理＞
図３は情報モデルを入力する図1の１０２の入力装置の処理フローであり、３０１で情報モデルを一括入力し、３０２では情報モデルのクラス単位でさらに入力を行い、３０３の判定で入力すべきクラスが無ければ終了するが、クラスがある場合は図４のマスタ定義処理を実行し、続けて３０４で関連するクラスを入力し、３０５の判定で関連するクラスが無ければ３０２に戻り、次のクラスを入力する処理を行うが、関連するクラスが存在する場合は図６の連結ピン定義処理、図８のアクセスパス定義処理を実行する。情報モデルは、図２に示すように、工場、原価部門、製品グループ、製品、販売、といったクラス名と、各クラスに属する属性と、クラス間の関連を示す関連種別線と、関連種別線で関連付けられたクラス間の多重度の関係を示す多重度とを有する。情報モデルの情報は、属性の情報をグループ化して保持するクラスの名称等識別情報とそのクラスに属する属性の名称等識別情報と、関連種別線が接続する２つのクラスの名称を示す関連種別線情報と、多重度の情報として記憶装置１５０５に格納され、情報モデルの入力においては、これらの情報が入力される。図２中、属性名の左に「−」が示された属性はキー宣言された属性であることを表す。情報モデルは、入力装置１５０３から入力しても良いし、記憶装置１５０５に予め格納した情報モデルの情報を読み出して、情報モデル入力装置１０２に入力してもよい。

図４は図１の１０３のマスタ制御装置での処理フローで、図５はその結果として生成された図１の１０５のマスタテーブルの一例である。ステップ４０１では入力された情報モデルをＤＢ定義へと変換する。つまり、情報モデルの情報に基づいて、テーブル定義パラメタである、テーブル名称、テーブルのデータ項目名、テーブルのキー、及びその他属性を作成する。図１の１０１の情報モデルのＵＭＬ表記での工場クラスを例に取ると、テーブル名称を事前に決められた名称付与規則に従い定義する。例えば５０１のように、クラス名を、クラス名＋”マスタ”で“工場マスタ”と変換してテーブル名称として定義し、さらに工場クラスの中で定義された工場コード、工場名称、代表電話番号、住所などの属性名をテーブルのデータ項目名として定義し、さらに１０１の情報モデルで定義された属性の中でキー宣言された情報をテーブルのキーとして定義し、併せてそれぞれの属性で指定されている文字や数値などの属性と桁数を定義する。

次に４０２で既存のマスタ定義を取得し、４０３では既存のマスタ定義に４０１で変換したマスタと同一のものが無いかの判定を行い、無い場合は４０４の処理で１０４のマスタ定義装置に登録して管理する。

以下、同様な処理をクラスが無くなるまで繰り返すことで、５０２は原価部門クラスを、５０３は製品グループクラスを、５０４は製品クラスを、５０５は販売クラスを入力してマスタ定義したものが作成される。

図２の情報モデルでは製品グループ、製品、販売のクラスが親との関係を持っているが、マスタテーブルの定義としてはこれらの連結関係は内部に持たせないことで、単純に情報モデル個々の内容をＤＢ定義へと変換し登録する。

＜連結ピンの登録処理＞
次に、図６は図１の１０６の連結ピン制御装置での処理フロー、図７はその結果として定義される連結ピンテーブルの一例である。ここで、連結ピンとは、情報と情報の関係を繋ぐキーの対応をいい、２つのテーブル間のキーの対応関係である連結情報を連結ピンテーブル毎に格納する。例えば図７の連結ピンテーブル１においては、工場マスタで工場コードAのデータには製品グループマスタで製品グループXXの製品、及び製品グループYYのデータが連結関係にある。このように連結ピンは連結ピンテーブルにおける、個別のキー間の対応付けによって実装される。

図３の入力装置の処理３０４でそのクラスに関連する別のクラスを図２の関連種別線情報を元に入力し、３０５の判定処理で関連するクラスが無ければ次のクラスを入力するが、関連するクラスがある場合、６０１では入力された二つのクラス（クラスとその関連クラス）の図２の多重度の関係を判断し、多重度１のクラスを親と定義し、片方を子とする親子の定義を行なうが、１対１の対等関係にある場合は先に読み込んだクラスの方を親とし、もう一方のクラスを子と定義する。３０５の関連するクラスの判定においては、記憶装置１５０５に格納された情報モデルの情報のうち関連種別線情報によって対応付けられたクラスがあるか否かによって判定することができる。

次に親クラスと子クラスのキーの組合せを元に、６０２，６０３で図１の１０７の連結ピン定義装置から既存の組合せが存在しないかを確認し、存在している場合は既に図１の１０８の連結ピンテーブルに登録されていることになり、図３の３０４に戻って次の関連クラスを読み込みに行くが、無い場合は連結ピンテーブルとして新規登録するため、６０４，６０５でキーの組合せを連結ピンテーブル名、キーの項目名をデータ項目名、それぞれの属性および親クラスのキーを連結ピンテーブルのキーとして連結ピン定義装置に登録し、連結ピンテーブルを生成する。

この結果として、図２の工場クラスと製品グループクラスを例に取ると、工場クラスの関連クラスが製品グループクラスであり、その多重度は１対1以上ｎ（＊はｎを意味し、１．．＊は１以上ｎを意味する）であるため、工場クラスが親となり製品グループクラスが子になる。この組合せでそれぞれのキーである工場コードと製品グループの組合せをこの連結ピンテーブルのテーブル名称、工場コードおよび製品グループをこの連結ピンテーブルのデータ項目名、各クラスそれぞれのキー属性を連結ピンテーブルの各データ項目の属性、及び工場コードをこのテーブル自身のキーとして、図７に示す連結ピンテーブル１のような定義が連結ピン定義装置に登録される。

なお、ここで定義されるものは、あくまで連結ピンテーブルの定義情報だけであり、実際の関連情報の実体そのものは、一般的に知られているＤＢアクセス方法（例：ＲＤＢのＳＱＬなど）を使った手段で、図1の１１３の業務プログラムなどによって後から登録されることになる。関連情報の実体は、工場コードに対応する識別子Aに対して製品グループに対応する識別子XXおよびYYを対応付けるというように、親クラスのキーであるデータ項目に１以上の子クラスのキーであるデータ項目を対応付ける形で定義される。

＜アクセスパスの登録処理＞
次に連結ピン制御装置は６０７で、現在処理したキーの組合せを保持しつつ、アクセスパスの定義を生成するが、この処理方式について、図８にアクセスパスの生成を自動的に行なう図１の１０９のアクセスパス制御装置の処理フローを、図９に図１の１１１のアクセスパステーブルの生成例を示す。

アクセスパスとは、あるテーブルから他のテーブルへ、テーブル間の連続的な関連付けを辿って至る（アクセスする）経路（パス）の情報であり、図９（ａ）に模式的に示したように、連結ピンテーブルを階層的に関係付ける情報としてアクセスパステーブルに格納される。

アクセスパス制御装置１０９は、最初に８０１でキーの組合わせに該当する既存のアクセスパス定義を取得し、８０２で既に定義されているか否かを判断し、定義されていれば８０４の処理に進むが、定義されていなければアクセスパス名称を事前に決められた名称付与ルールに従い付与し、（本例ではＰａｔｈ“ｎ”としてｎの値を連番で付けていくルール）連結ピンテーブル名とキーの親子を階層レベル１に指定し、新規アクセスパステーブルとして図１の１１０のアクセスパス定義装置に登録する。アクセスパステーブルには、アクセスパスを識別する情報であるパス名及び１以上の連結ピンテーブルの名称が階層レベルと対応付けて格納される。アクセスパステーブルに格納する情報としては連結ピンテーブルの名称でなくても連結ピンテーブルを識別できる情報であればかまわない。階層レベル１の連結ピンテーブルの子キーは階層レベル２の連結ピンの親キーと対応する、というように連続する階層間では、上位階層の連結ピンの子キーが下位階層の連結ピンの親キーに対応している。

図２の工場クラスと製品グループクラスの組合せで新規に登録したケースを例にとると、図９のアクセスパステーブルＰａｔｈ１の階層レベル１に、工場コードと製品グループのキーの組合せが、図７で示す連結ピンテーブル名称である「連結ピンテーブル１」と共に登録される（この際、階層レベル２，３はまだ登録されていない状態）。

次に既存アクセスパステーブルに階層レベルの追加登録処理を行うため、８０４で既に登録されているアクセスパステーブルの階層レベル中で、アクセスパステーブルに追加しようとする連結ピンの親のキーを子に持つ階層レベルを取得し、８０５の判定で対象が無ければ８１２に進むが、対象があれば取得した階層レベルの次の階層に既に登録されているか否かを次に判断する。登録済であれば８０４に戻って次の検索に行くが、未登録であればそのアクセスパステーブルに追加可能か否かの判断を続けて行なう。

この判断は追加しようとする階層レベルが、そのアクセスパステーブルの中間階層レベルか、あるいは最下位層レベルかによって処理方式が異なり、最下位層レベルである場合はそのまま次の階層レベルＮｏを付与して最下位層へ追加する方式となり、８１１の処理により、製品型名クラスと販売型名クラスの組合せを追加する場合を例にとると、図９のＰａｔｈ１のように階層レベル１，２だけが登録されていたとすると、製品型名クラスと販売型名クラスの組合せは階層レベル３として追加登録され、８０９と８１０の処理で既に登録されている否かを判断しているため、重複したアクセスパスは新規には登録されない処理となる。

一方、中間階層レベルに登録する場合、そのまま該当する中間階層レベルに登録するとその次の階層レベルのパスが切れてしまうため、そのアクセスパスには登録せずに、そのアクセスパスにおけるその中間階層から最上位階層までの階層レベルのパスに今回のレベルを追加したものを８０６の処理で保持して、既にパスが登録されていないかを８０７で判断し、既存パスがある場合は処理をせず８０４に戻って次の検索に行くが、無ければ保持した内容を８０８で新規アクセスパスとしてアクセスパス定義装置によりアクセスパステーブルに登録する。

例として、製品グループクラスと販売型名クラスの組合せの連結ピンをアクセスパステーブルに登録する処理において、図９（ｂ）のアクセスパステーブルのＰａｔｈ１を検索した場合、階層レベル１の子が製品グループであるため、次の階層に登録することになるが、ここで次の階層レベルが既に登録されていたとすると、その階層レベルへのパスが切れてしまうため、階層レベル１の内容に追加して製品グループと販売型名を階層レベル２として、その組合せが既存のアクセスパステーブルになければ、Ｐａｔｈ３のように新規に登録する。

さらに追加しようとする連結ピンの親のキーを子に持つアクセスパステーブルの階層レベルが無くなるまで８０４〜８１１の処理を繰り返す。

追加しようとする連結ピンの親のキーを子に持つアクセスパステーブルの階層レベルが無くなった場合、８１２の処理で今度は追加しようとする連結ピンの子のキーを親に持つアクセスパステーブルの階層レベルを検索する。８１３の判断で対象が無ければ図３の３０４に戻るが、対象があった場合、取得した階層レベルの前の階層レベルに既に登録されているか否かを次に判断し、登録済であれば８１２に戻って次の検索に行くが、未登録であればそのアクセスパステーブルに追加可能か否かの判断を続けて行なう。

この判断は追加しようとする階層レベルが、そのアクセスパステーブルの中間階層レベルか、あるいは最上位層レベルかによって処理方式が異なり、最上位層レベルである場合は次の階層レベル以降のＮｏを一つずつずらし、Ｎｏ１を付与して最上位層へ追加する方式となり、８１６の処理によって実現される。

例として、仮に図９のＰａｔｈ１が階層レベル１に製品グループと製品型名、階層レベル２に製品型名と販売型名として登録されていた際に、工場コードと製品グループを登録しようとすると、最上位階層に登録することになり、今までの階層レベルを一つずつずらし、最上位階層レベルＮｏ１に工場コードと製品グループを追加して、全体のパスが既に他のアクセスパステーブルとして無いことを８１４，８１５の処理で確認した後、Ｐａｔｈ１のアクセスパステーブルを更新する処理となる。

一方、中間階層レベルに登録する場合、そのまま該当する中間階層レベルに登録するとそれ以前の階層レベルのパスが切れてしまうため、そのアクセスパスには登録せずに、そのアクセスパスにおいてその中間階層以下の階層レベルのパスの上位に今回のレベルを追加したものを８１４の処理で保持して、既にパスが登録されていないかを８１５で判断し、既存パスがある場合は処理をせず８１２に戻って次の検索に行くが、無ければ保持した内容を８１６で新規アクセスパステーブルとしてアクセスパス定義装置に登録する。

例として、原価部門コードクラスと製品グループクラスの組合せを登録する処理において、図９のアクセスパステーブルのＰａｔｈ１を検索した場合、階層レベル２の親が製品グループであるため、その前の階層に登録することになるが、ここで前の階層レベルが既に登録されているため、ここに追加すると以前の階層レベルからのパスが切れてしまうため、階層レベル２，３の内容の上位に原価部門コードと製品グループを階層レベル１として追加したものを、その組合せが既存のアクセスパステーブルになければ、Ｐａｔｈ２のように新規に登録する。

以上のような処理により、連結ピンテーブルとアクセスパステーブルを生成することができるが、ＵＭＬのような情報モデルを読み込まなくても、画面操作を利用して管理者などが行うことができる。図１０に連結ピンテーブルメンテナンスのための画面例を示す。図１の１１４から１０２の入力装置に渡すことで、情報モデルを入力して連結ピンテーブルやアクセスパステーブルを生成する方式と同様、連結ピンテーブルやアクセスパステーブルの生成が可能で、かつ、画面からの操作では登録処理だけでなく、更新、削除も可能となる（図１０の例は連結ピンテーブルメンテナンス用画面であるが、アクセスパステーブルメンテナンス用の画面も同様の方式となる）。

＜連結ピン削除処理＞
ここで、連結ピンテーブルやアクセスパステーブルの新規登録、更新、アクセスパステーブルそのものの削除処理に関しては問題が無いが、連結ピンテーブルの削除や、アクセスパステーブルの中の階層レベルの削除処理については、アクセスパスそのものが切れてしまうことになり、これを解決する手段としてアクセスパス制御装置は次のような処理を認識し実行する。

例として、図１１のＰａｔｈ１で、仮に連結ピンテーブル３が不要になったため、管理者が図１０のメンテナンス画面を用いて削除したとするとＰａｔｈ１は階層レベル２の連結ピンテーブルが存在しないため、データの検索において、検索処理装置は連結ピンテーブル１から連結ピンテーブル５へパスをたどれなくなってしまう。このことから、アクセスパス制御装置は以降の階層レベル（ここでは連結ピンテーブル５）を別のアクセスパス（図１１の削除後のアクセスパステーブルのＰａｔｈ５）として新規登録する処理を行い、階層レベル１だけを残してアクセスパス定義装置に自動更新（図１１の削除後のアクセスパステーブルのＰａｔｈ１）する処理を実行する。

同様にアクセスパステーブルの階層レベル２以外の中間階層の連結ピンが管理者によって削除された場合も同じ処理を実行し、不要となった情報の関係を削除した場合でも連動してアクセスパス経路を必要分だけ残して更新することで、情報関係の変化にも対応することが可能となる。

＜検索処理＞
図１２を用いて業務プログラムからの検索処理について図１の１１２の検索処理装置の処理フローを説明するが、業務プログラムからの検索処理条件は、１２０１の処理で検索条件のキー名称と情報実体、および最終的に検索対象としたいキー名称を指定する形態となり、それと共に検索対象とする連結ピンテーブルの期間と検索順路である検索パスの上下（親から子、または子から親）を指定でき、さらに検索の付加条件として連結ピンテーブルを指定する場合とアクセスパステーブルを指定する場合、さらに連結ピンテーブル、アクセスパステーブル共に指定しない方式の三つの検索処理パターンがある。

（期間指定による検索）
この中で連結ピンテーブルの期間指定については、図１４の例に示すように連結ピンテーブルそのものは同じ構造のものを日時の情報と対応付けて期間単位で複数保持できる。組織変更などの情報の関係に変化が生じる場合、事前に連結ピンテーブルの中の情報を変更して用意することで、その期間になったことを中央処理装置が検知した際にその連結ピンテーブルが有効になって、検索結果が変わるなど、企業における各種構造変化への対応に関しての事前準備が可能なこと、さらには将来の情報関係構造を持てることで業務プログラムからシミュレーション的に利用できること、また、過去の情報関係に基づいた集計などを実現するためのものであり、業務プログラムが１２０１で使用する連結ピンテーブルの期間（有効日付）を指定をした場合は１２０２，１２０４でその日付がセットされ、指定しなくても１２０２，１２０４の処理で現状の日付をセットするため、以降、検索処理において指定された期間の連結ピンテーブルを対象とする処理方式となる。

図１４にしたがって具体例について説明する。２００４年４月１日から同年９月３０日の間は工場コードＡに製品グループＸＸ、ＹＹが、工場コードＢに製品グループＺＺが、工場コードＣに製品グループＷＷが対応付けられている。２００４年１０月１日から２００５年３月３１日の間は、工場コードＡに製品グループＸＸとＹＹが、工場コードＢにＹＹが、工場コードＣにＷＷが対応付けられている。つまり、工場Ｂで２００４年１０月１日以降は製品グループＺＺの生産をやめ、製品グループＹＹの生産を開始する事例である。この場合、工場コードＢで識別される工場の製品グループ名を全部抽出する場合に、２００４年９月３０日以前は、製品グループＺＺに対応するデータを返すが、２００４年１０月１以降は製品グループＹＹに属するデータを返すようになる。

（連結ピンテーブルを指定した検索）
次に検索付加条件で連結ピンテーブルを指定して検索する場合、業務プログラムが１２０１でセットした検索付加条件を１２０５で判断し、指定された連結ピンテーブルでの検索処理を行うが、連結ピンの指定は複数指定可能であり、まずは１２０６で指定された最初の連結ピンテーブルの有無を確認するため連結ピン定義装置から取得し、１２０７の判断で該当するものが無ければ、１２０９で業務プログラムにエラーを返却する。

１２０７の判断で該当する連結ピンテーブルが見つかった場合、１２０８の処理で検索パスの指定が親子なら検索条件キーと情報実体で親キーを指定し該当する子キーの内容を取得し、検索パスの指定が子親なら検索条件キーと情報実体で子キーを指定して該当する親キーの内容を取得する。取得が終了した場合、１２１０で検索対象のキーの情報を取得したかを判断し、取得できていれば１２１１で取得結果を業務プログラムに返すが、検索対象のキーがまだ取得できていない場合は、１２１２で業務プログラムが次の連結ピンテーブルの指定を行なっているかを判断し、無ければ１２０９でエラーを返す。指定されている場合は１２１３で次の連結ピンテーブルをセットし、１２０６に戻って繰り返し検索を行い、検索対象のキーにたどりつくまで検索を続ける処理となる。

また、情報の返却形態は最終的に検索された情報のみを返すことも可能であるが、途中の検索結果を次の検索キーの情報実体とするために保持しており、最終的に検索された情報だけでなく、途中経過として検索された情報を併せて返すことも可能であり、さらに検索順路を親子、あるいは子親のように情報関係の上下どちらからでも検索順路を可能としている。

さらに目的とする検索情報が見つかった場合、見つかった情報はあくまで、ある情報と関係を持った情報であり、ここで見つかった情報自身の属性を併せて取得したい場合、業務プログラムは呼び出しのインタフェースにそのマスタ名と属性名を指定しておけば、連結ピン制御装置からマスタ定義装置を経由してマスタテーブルそのものの内容も取得できる。

（アクセスパスを指定した検索）
次にアクセスパスを検索付加条件で指定された場合、１２０５の判断でアクセスパステーブルを使用した検索を行なうが、検索付加条件のアクセスパス名称により指定されたアクセスパスを１２１４で取得し、１２１５の判断でアクセスパスそのものが無ければ、１２２０の処理で業務プログラムにエラーを返す。存在する場合は１２１６，１２１８の処理で検索する親キーと子キーがそのアクセスパスのどの階層レベルにあるかを判断してセットする処理を実行する（検索パス指定が親子の場合、検索条件キーは各階層レベルの連結ピンの親キーと、検索対象キーは各階層レベルの連結ピンの子キーと比較する。検索パス指定が子親の場合は検索条件キーは各階層レベルの連結ピンの子キーと、検索対象キーは各階層レベルの連結ピンの親キーと比較し、検索条件キーと対応する連結ピンと検索対象キーに対応する連結ピンが存在すれば、検索条件キーに対応する連結ピンと検索対象キーに対応する連結ピンの階層レベルをそれぞれセットする）。指定された検索条件キーと検索対象キーがアクセスパスのどの階層レベルにも存在しないと１２１７，１２１９で判断された場合には、１２２０で業務プログラムにエラーを返す。

アクセスパスのいずれかの階層レベルの連結ピンに該当する検索条件キーと検索対象キーがあった場合、１２２１で検索開始階層と検索終了階層をセットするが、検索パス指定が親子なら親キーの該当階層レベルを検索開始階層に、子キーの該当階層レベルを検索終了階層としてセットし、検索パス指定が子親なら子キーの該当階層レベルを検索開始階層に親キーの該当階層レベルを検索終了階層としてセットし、最初に検索開始階層レベルで指定されている連結ピンテーブルの中で指定期間に有効な連結ピンテーブルを対象として検索を開始する。検索パスが親子なら親キーの情報実体をセットして子キーの情報を取得し、検索パスが子親なら子キーの情報実体をセットして親キーの情報を取得し、１２２３の判断で検索開始階層が検索終了階層となった場合、検索結果を１２２５で業務プログラムに返却する。

検索開始階層が検索終了階層と同じではない場合は、まだ目的の階層にたどりついていないことになり、１２２４の処理で検索パス指定が親子の場合は検索開始階層を一つ下げて、あるいは検索パス指定が子親の場合検索開始階層を一つ上げて、直前で取得した情報を検索条件キーとしてセットし、１２２２に戻り該当する連結ピンテーブルの検索を繰り返すことで、検索対象キーの階層レベルまで検索開始階層がたどりつき、目的の情報を得るまでこの処理を繰り返すが、情報の返却形態は連結ピンテーブルを指定して検索したときと同様に、最終結果のみを返却することも、あるいは中間結果も併せて返却することも可能な処理方式となる。

この処理方式によれば、アクセスパステーブルの最上位層から最下位層までの検索は当然ながら、階層レベルの途中から途中、またはある階層レベル以下全て、ある階層レベル以上全てなどの検索が可能となり、業務プログラムからは情報構造の階層レベルを知らなくても検索条件を指定することができ、検索の中間の情報関係を知る必要が無いことで、その間の情報関係になんらかの変更があった場合でも業務プログラムのインタフェースを改造しなくても良いという利点がある。

（連結ピンテーブルもアクセスパステーブルも指定しない検索）
次に連結ピンテーブルもアクセスパステーブルも検索付加条件で指定しない場合の検索処理方式について説明する。１２０５の判断で検索付加条件指定なしと判断された場合は既存のアクセスパスを見つけ出し、アクセスパスを内部セットしてアクセスパステーブルで検索する方式と、該当するアクセスパステーブルが無い場合、該当する連結ピンテーブルを見つけ出し、それを組み合わせて検索する方式の二つがあり、後者の場合は検索終了後、その連結ピンの検索組合せをアクセスパステーブルに登録する。

まずアクセスパステーブルを見つけ出して検索する方式について説明する。１２２６，１２２８で、検索パス指定が「親子」の場合、検索条件キーを親キーに持つ連結ピンテーブルと検索対象キーを子キーに持つ連結ピンテーブルをそれぞれ検索して取得する。検索パス指定が「子親」の場合、検索条件キーを子キーに持つ連結ピンテーブルと検索対象キーを親キーに持つ連結ピンテーブルをそれぞれ検索して取得する。１２２７，１２２９の判断で両方あるいはどちらか一方でも該当する連結ピンテーブルが無いと判断した場合は１２３０で業務プログラムにエラーを返却する。

検索条件に対応する連結ピンと検索対象に対応する連結ピンが両方存在していた場合、取得した２つの連結ピンの連結ピンテーブル名をキーとして、１２３１で両方の連結ピンテーブルがいずれかの階層レベルに定義されているアクセスパスを検索して取得する。無かった場合は、図１３の１３０１で連結ピンテーブルからのアクセス経路判断処理に進む。存在する場合は、検索条件キーに対応する連結ピンの階層レベルを検索開始階層として、検索対象キーに対応する連結ピンの階層レベルを検索終了階層としてそれぞれセットし、アクセスパステーブルを指定した検索処理と同様の１２２２の処理をする。複数該当するアクセスパステーブルが検索結果として得られた場合は、親子の階層レベルが一番近いアクセスパステーブルを候補としてセットして１２２２に引き渡すことで、性能の面から効率の良いアクセスパステーブルを判断する方式とすることができる。

次にアクセスパステーブルに該当する検索条件キーと検索対象キーが無かった場合の処理を図１３に示し説明を加える。１３０１で検索パス指定が「親子」ならば検索条件キーを親キー、検索対象キーを子キーとし、検索パス指定が「子親」なら検索条件キーを子キー、検索対象キーを親キーとしてセットする。まずは検索条件キーに対応する連結ピンとして取得された連結ピンテーブルを１３０２で判断し、検索対象キーがその連結ピンテーブルにあるか否かを判断し（検索パス指定が親子なら検索対象キーは子キーと比較、子親なら検索対象キーは親キーと比較）判断の結果で該当した場合は検索した連結ピンテーブルの組合せで検索条件キーから検索対象キーまでたどれたことになり、この連結ピンテーブルの組合せ順序をアクセスパステーブルの階層レベルとし、１３０４でアクセスパステーブルとして新規登録したうえで、このアクセスパステーブルを使って実際の情報を検索するため、アクセスパス制御装置の処理フロー、図１２の１２１５へ進んで実際の検索を実行する。

１３０２の判断で該当する連結ピンテーブルにたどりついていない場合、１３０７で読み込んだ連結ピンテーブルの定義を保持し、検索パス指定が親子なら取得した連結ピンテーブルの親キーを検索条件キーにセット、子親なら子キーを検索条件キーにセットし、次の連結ピンテーブルを検索するため１３０１に戻って検索を繰り返すが、１３０５の連結ピンテーブル取得行為で該当する連結ピンテーブルが無かった場合、業務プログラムが指定した検索条件キーから検索対象キーをたどるための連結ピンテーブルの組合せが存在しなかったことになり、１３０９でエラーを返却する。 以上のとおり、本実施例によれば、ＵＭＬのような情報モデルからＤＢのテーブル定義を生成する手段と、それとは別に、情報と情報の関係から連結関係を保持するテーブルを生成、修正、削除する手段と、その連結関係をたどってアクセスするためのアクセス制御を行なうテーブルを生成、更新、削除する手段と、アクセス処理そのものを効率よく実現するための検索処理手段と、連結関係の適用期間に応じて該当する連結関係の情報を返却する手段を備えた装置と処理方式を設ける。このため、情報モデルからＤＢ設計に展開し、情報自体のテーブル定義とは別に連結関係とそのアクセス経路を生成して管理し、業務プログラムからは、検索条件のキーとその内容、および最終検索目的のキーをもらえば、関係する目的の情報を検索して返却し、アクセス回数を削減した検索処理によりアクセス効率を上げることが可能となる。

情報の分析で得られた情報モデルからＤＢのテーブル定義をマスタテーブルとして生成でき、情報の連結関係とそのアクセス経路を連結ピンテーブルとアクセスパステーブルとして自動的に生成でき、さらに業務プログラムからの検索条件に応じてアクセスパスが無い場合は生成でき、かつ、これらを生成した後でも追加生成、変更、削除が可能となる。

目的とする情報を検索する過程で、複数の情報の関係が間に入っている多段構造の場合でも、その情報にたどり着くまでの経路を事前に定義したアクセスパステーブルを用いて検索することで、検索時間を短縮できる。

また、情報の連結関係は複数期間保持可能な構造とすることで、情報の構造変化に柔軟に対応できる装置と処理方法が提供できる。情報の関係に変化が生じた場合、あるいは生じることが予想された場合は、連結関係の適用期間による管理が可能なため、事前定義での利用や過去情報の利用ができ、連結関係の構造変化に対して業務プログラムの検索インタフェースを改造することなく利用できるという効果がある。

連結ピンテーブルの適用期間は過去、現在、未来系を含む複数個保有し保持するため、マスタテーブルの期間と連結ピンの期間を独立に指定することで特定期間のデータを別の期間の連結ピンを用いて情報処理することができ、組織変更などのように年度途中での情報の関係に変化が生じた際でも、マスタテーブルを２種類もつ必要は無く、組織変更前のマスタテーブルと組織変更後の連結ピンテーブルを業務プログラムが指定することで、新組織を当てはめた集計ができ、集計や組織情報を持つデータの洗い替え処理が不要となる。また、未来の仮想連結ピンテーブルを業務プログラムが指定することにより、仮想組織でのデータ集計等のシミュレーションが可能となる。

本発明の一実施例であるシステムの構成図である。 本発明の一実施例である情報モデルの構成とそれをＤＢ定義した例の図である。 本発明の一実施例である情報モデルを入力する処理のフローチャートである。 本発明の一実施例である情報モデルからＤＢのマスタテーブルを自動生成する処理のフローチャートである。 本発明の一実施例である情報モデルからＤＢのマスタテーブルを自動生成した結果のマスタテーブル定義例の図である。 本発明の一実施例である情報モデルから連結ピンテーブルを自動生成する処理のフローチャートである。 本発明の一実施例である情報モデルから連結ピンテーブルを自動生成した結果の連結ピンテーブル定義例と情報実体の図である。 本発明の一実施例である情報モデルからアクセスパステーブルを自動生成する処理のフローチャートである。 本発明の一実施例である情報モデルからアクセスパステーブルを自動生成した結果のアクセスパステーブルの構造関係とアクセスパステーブル定義例の図である。 本発明の一実施例である連結ピンテーブルメンテナンス画面例の図である。 本発明の一実施例である連結ピンテーブル削除時のアクセスパステーブル自動変更例の図である。 本発明の一実施例である業務プログラムからの情報検索方式のフローチャートである。 本発明の一実施例である業務プログラムからの情報検索方式における連結ピンテーブル、アクセスパステーブル指定無しの場合のフローチャートである。 本発明の一実施例である連結ピンテーブル有効期間指定の例を示す図である。 本発明の一実施例である情報管理システムのハードウェア構成の一例を示す図である。

符号の説明

１０１：情報モデル
１０２：情報モデル入力装置
１０３：マスタ制御装置
１０４：マスタ定義装置
１０５：マスタテーブル
１０６：連結ピン制御装置
１０７：連結ピン定義装置
１０８：連結ピンテーブル
１０９：アクセスパス制御装置
１１０：アクセスパス定義装置
１１１：アクセスパステーブル
１１２：検索処理装置
１１３：業務プログラム
１１４：管理画面

Claims (8)

1. 入力部を介して入力された情報と記憶部に記憶された情報に基づき検索処理を行う情報処理部を有する情報管理装置における情報管理方法であって、
   前記情報処理部によって、
   前記入力部を介して入力された、検索条件の親キー情報と子キー情報を取得し、
   前記記憶部に格納されている、連結ピンテーブル名称毎に親キー情報と子キー情報とを関連付けたレコードを複数有する複数の連結ピンテーブルを参照して、前記入力部を介して入力された親キー情報を有する連結ピンテーブル及び前記入力部を介して入力された子キー情報を有する連結ピンテーブルを特定し、
   アクセスパステーブル名称毎に任意の前記複数の連結ピンテーブルの各々を階層的に定義付けた複数のアクセスパステーブルを参照して、前記特定した二つの連結ピンテーブルが定義されたアクセスパステーブルを検索し、
   該検索された複数のアクセスパステーブルにおいて、前記入力部を介して入力された、親キー情報と子キー情報との階層関係が最短の前記アクセスパステーブルを特定し、
   該特定したアクセスパステーブルと前記入力部を介して入力された親キー情報、子キー情報に基づき前記検索処理を行う、
   ことを特徴とする情報管理方法。
2. 前記情報処理部によって、
   前記入力部を介して入力された、前記検索条件の前記親キー情報、子キー情報と、さらに検索付加条件として指定された前記何れかの連結ピンテーブル名称を取得すると、該取得された連結ピンテーブル名称と前記複数の連結ピンテーブルに基づき前記検索処理を行う、
   ことを特徴とする請求項１に記載の情報管理方法。
3. 前記情報処理部によって、
   前記入力部を介して入力された、前記検索条件の前記親キー情報、子キー情報と、さらに検索付加条件として指定された前記何れかのアクセスパステーブル名称を取得すると、該取得されたアクセスパステーブル名称と前記アクセスパステーブルに基づき前記検索処理を行う、
   ことを特徴とする請求項１に記載の情報管理方法。
4. 前記複数の連結ピンテーブルの各々には有効期間情報が関連付けられて記憶されており、
   前記情報処理部によって、
   前記入力部を介して入力された、前記検索条件の前記有効期間情報及び前記親キー情報、子キー情報と、さらに前記検索付加条件として指定された前記何れかの連結ピンテーブル名称を取得すると、該取得された連結ピンテーブル名称と前記複数の連結ピンテーブルに基づき前記検索処理を行う、
   ことを特徴とする請求項２に記載の情報管理方法。
5. 入力部を介して入力された情報と記憶部に記憶された情報に基づき検索処理を行う情報処理部を有する情報管理装置であって、
   前記記憶部には、
   連結ピンテーブル名称毎に親キー情報と子キー情報とを関連付けたレコードを複数有する複数の連結ピンテーブルと、アクセスパステーブル名称毎に任意の前記複数の連結ピンテーブルの各々を階層的に定義付けた複数のアクセスパステーブルと、が格納されており、
   前記情報処理部は、
   前記入力部を介して入力された、検索条件の前記親キー情報及び前記子キー情報を取得すると、前記複数の連結ピンテーブルを参照して前記入力部を介して入力された親キー情報を有する連結ピンテーブル及び前記入力部を介して入力された子キー情報を有する連結ピンテーブルを特定し、さらに前記複数のアクセスパステーブルを参照して、前記特定した二つの連結ピンテーブルが定義されたアクセスパステーブルを検索し、該検索された複数のアクセスパステーブルにおいて、前記入力部を介して入力された、親キー情報と子キー情報との階層関係が最短の前記アクセスパステーブルを特定し、該特定したアクセスパステーブルと前記入力部を介して入力された親キー情報、子キー情報に基づき前記検索処理を行う、
   ことを特徴とする情報管理装置。
6. 前記情報処理部は、
   前記入力部を介して入力された、前記検索条件の前記親キー情報、子キー情報と、さらに検索付加条件として指定された前記何れかの連結ピンテーブル名称を取得すると、該取得された連結ピンテーブル名称と前記複数の連結ピンテーブルに基づき前記検索処理を行う、
   ことを特徴とする請求項５に記載の情報管理装置。
7. 前記情報処理部は、
   前記入力部を介して入力された、前記検索条件の前記親キー情報、子キー情報と、さらに検索付加条件として指定された前記何れかのアクセスパステーブル名称を取得すると、該取得されたアクセスパステーブル名称と前記アクセスパステーブルに基づき前記検索処理を行う、
   ことを特徴とする請求項５に記載の情報管理装置。
8. 前記複数の連結ピンテーブルの各々には有効期間情報が関連付けられて記憶されており、
   前記情報処理部は、
   前記入力部を介して入力された、前記検索条件の前記有効期間情報及び前記親キー情報、子キー情報と、さらに前記検索付加条件として指定された前記何れかの連結ピンテーブル名称を取得すると、該取得された連結ピンテーブル名称と前記複数の連結ピンテーブルに基づき前記検索処理を行う、
   ことを特徴とする請求項６に記載の情報管理装置。

Images