JP3730174B2 - 関係付け情報管理システム、関係付け情報管理用プログラム、及び記録媒体 - Google Patents
関係付け情報管理システム、関係付け情報管理用プログラム、及び記録媒体 Download PDFInfo
- Publication number
- JP3730174B2 JP3730174B2 JP2002004203A JP2002004203A JP3730174B2 JP 3730174 B2 JP3730174 B2 JP 3730174B2 JP 2002004203 A JP2002004203 A JP 2002004203A JP 2002004203 A JP2002004203 A JP 2002004203A JP 3730174 B2 JP3730174 B2 JP 3730174B2
- Authority
- JP
- Japan
- Prior art keywords
- relationship
- parent
- child
- degree
- information
- 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.)
- Expired - Fee Related
Links
Images
Description
【発明の属する技術分野】
本発明は、各種情報を関係付けて管理する関係付け情報管理システム、関係付け情報管理用プログラム、及び記録媒体に関し、また、個人・団体の情報のデータと相互の関係を系統を持たせて記録する系図型人脈管理システムに関する。
【0002】
【従来の技術及び発明が解決しようとする課題】
情報化時代、IT革命などを経てパソコン、携帯情報端末(PDA)その他各種情報端末機器が様々な分野で飛躍的に普及している。それに伴い情報端末で処理し管理する情報は、人に関する情報、組織に関する情報、営業・顧客その他事業に関する情報、文書・文献に関する情報、各種管理に関する情報など非常に多岐に拡がっている。このように情報の種類が多くなるだけでなく、情報の量も多くなると、当然それら情報の間にもいろいろな関連がでてくる。それらの情報の関係を有効に活用するためには、情報を整理し情報の関係を管理することが必要不可欠となる。
【0003】
一般に情報の関係付けとしては、例えばあるジャンルやカテゴリーで、一定の規則にしたがって上位から下位へツリー構造に関係付けを行うことでなされている。また、家族の系図のようなものは、親から子供、さらにその子供、そして、それぞれの姻戚へと繋がっていくが、上位から下位への関係付けが基本であり、複雑に関係が錯綜することはない。
【0004】
しかし、情報の種類と量が多くなると、扱う情報によって、情報全体を整理するために、さらに、ジャンル、カテゴリーの異なる情報も含めた関係付けも管理の対象として必要となる。図44は関係図の例を示す図、図45は関係付けされた各種情報の例を示す図である。
【0005】
例えば図44に示すようにA〜Jの情報が矢印に示すように関係付けされるとすると、一般に関係付けは、情報の全てが実線のようなツリー構造にはならず、AとFとの関係は、AとBCDを介しても点線で示す関係があるというように、別の関係付けが存在する例はよくあることで、多数ある情報間ではそれらの関係が錯綜してくる。また、図45に示すように文献や、○○大学、○○建設、作成者、図面、○○文書、管理部署などがそれぞれ情報の単位とした場合、例えば○○文書に着目すると、これに対し、作成者、文献、図面、応用文書、保管場所、担当部署が関係付けられている。
【0006】
上記のようにジャンル、カテゴリーの異なる様々な情報の関係付けだけでなく、人に関する情報として、人脈を系統化しようとすると、一人の人に繋がっている人の数は数人から数百人になり、さらに、友達の友達が別の友達のまた友達というように、同じ人脈の系図に同一人物が重複して関係付けされ、非常に煩雑になる。
【0007】
このような関係付けを有する情報を一般の関係図として表すと非常に入り組んで複雑、煩雑になり、それを記録することや、まして全ての関係を記録することは非常に困難なことである。そこで、それぞれの目的に応じ限定して管理するようにしたり、例えば人脈では、重要なところだけが、人の記憶に頼って管理されている。これが現状である。
【0008】
一般の家系図では直系家族を表すことはできるが、婚姻によって結ばれた外戚を一緒に表記することは困難である。長男の外戚のみならば、図46に示すように何とかできるが、兄弟全員の外戚を表記し、その配偶者の兄弟それぞれが婚姻した外戚や、そのそれぞれの親や親の兄弟、親の実家の外戚などをすべて表記するとなると、3次元で立体的に表すほかない。しかも家族であるから、系図の中にあらわれる個人は必ず1箇所にしか名前は出てこない。兄弟も多くて10数人である。
【0009】
しかし、人脈を系統化しようとすると、図47に示すように一人の人に繋がっている人の数は数人から数百人はいるし、友達の友達が、別の友達のまた友達という風に、同じ系図に同一人物が幾度となく出てくる。こうなると、一般の関係図を記録するのは非常に困難であるし、すべての関係を記録することはできない。そこで、人脈は重要なところだけを、人の記憶に頼って管理されているのが現状である。
【0010】
従来においては、人脈情報を電子メールに含まれる発信者氏名、宛先人氏名、およびそれらの電子メールアドレスから抽出して管理するシステム(特開2000−66970号公報)や、名刺情報をコンピュータで読み取り、その名刺を誰が誰からもらったかをという情報を併せて登録することにより人脈情報を得る装置(特開平11−66082号公報)が提案されている。
【0011】
しかしながら、これらの従来技術においては、人脈の二次元的なつながりを規定するのみであり、親子関係(上下関係)などの三次元的な広がりやつながりの深さをもつ人脈についての情報は規定も検索もすることができなかった。
【0012】
【課題を解決するための手段】
本発明は、上記課題を解決するものであって、簡単な構成により様々な情報の関係付けの登録、管理を可能にし、位置時系列を含む関係の検索、抽出を簡便に行えるようにするものである。
【0016】
そのために本発明は、氏名または団体名、住所、電話番号等の個人・団体のメンバー情報を格納するメンバー管理テーブルと、
そのメンバー管理テーブルに登録されたあるメンバーとそのメンバーに関係する他のメンバーの二者の関係を親子関係で規定された関係レコードを記録するとともにその関係の種類および関係の優先順位を表す区分コードを記録する関係管理テーブルとからなるデータベースを備えた関係付け情報管理システムにおいて、 参照対象としてメンバーが指定されたときに、そのメンバーと親子関係があるメンバーを抽出して、参照対象とともに親メンバー、子メンバー、孫メンバーをリストとして表示する、次のステップを実行する手段を有する関係付け情報管理システム。
(1)特定の条件を指定して抽出されたメンバーリストで選択されているメンバーのコードを参照対象コード(以下本人CIF)とする。
(2)本人CIFを元に参照対象の情報をメンバー管理テーブルより取得し、参照対象表示域に格納する。
(3)本人CIFを元に関係管理テーブルより参照対象者の親関係にあたる全てのメンバーのコード(以下親CIF)と区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから親メンバーリスト表示領域に格納する。
(4)本人CIFを元に関係管理テーブルより参照対象者の子関係にあたる全てのメンバーのコード(以下子CIF)と区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから子メンバーリスト表示領域に格納する。
(5)子メンバーリスト表示領域の最上にある子CIFを元に関係管理テーブルより子メンバーリスト表示領域の最上にある子メンバーの子関係にあたる全てのメンバーのコード(以下孫CIF)と区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから孫メンバーリスト表示領域に格納する。
(6)表示領域を表示する。
(7)子メンバーリスト表示領域の中で最上以外のメンバーをユーザが選択したかどうかを判断する。選択したらステップ(8)に進む。選択しなければステップ(9)に進む。
(8)選択された子CIFを元に関係管理テーブルより子メンバーリスト表示領域の選択された子メンバーの子関係にあたる全てのメンバーのコードと区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから孫メンバーリスト表示領域に格納し、再度表示する。
(9)参照対象変更ボタンを押下したかどうかを判断する。押下したらステップ(10)に進む。押下しなければ次の指示を待つ。
(10)親メンバーリスト表示領域と子メンバーリスト表示領域と孫メンバーリスト表示領域の中でユーザが選択したメンバーのコードを本人CIFとする。ステップ(2)に戻る。
【0017】
さらに、本発明は、前記システムにおいて、参照対象に設定されたメンバーコードにより、親子関係があるメンバーを抽出して、親等の近い順に複数親等をツリービューに表示する、次のステップを実行する手段を有する。
(1)参照対象CIFをもとにメンバー管理テーブルの参照対象メンバーの情報を取得し、ツリービュー領域に表示する。
(2)1親等洗い出し
(2−1)参照対象CIFをもとに関係管理テーブルから親メンバーを抽出し、優先順にツリービュー領域2列目に1メンバー1段で参照対象の下に追加表示する。
(2−2)参照対象CIFをもとに関係管理テーブルから子メンバーを抽出し、優先順にツリービュー領域2列目に1メンバー1段で親メンバーの下に追加表示する。
【0018】
ただし、ツリービュー内にすでに同じCIFのメンバーが表示されていれば名前の後に省略記号を付加する。
(3)2親等洗い出し
(3−1)2列目に表示されている1親等のメンバーについて上から順にそれぞれ次の処理を行う。
(3−2)1親等者CIFをもとに関係管理テーブルから親メンバーを抽出し、優先順にツリービュー領域3列目に1メンバー1段で該当の1親等のメンバーと次の1親等のメンバーの間に挿入表示する。
【0019】
ただし、直系の2親等前(参照対象)が同じメンバーなら「2親等洗い出し」はしない。
(3−3)元にする1親等の該当段目のメンバーに省略記号がついていれば「2親等洗い出し」はしない。
(3−4)ツリービュー内にすでに同じCIFのメンバーが表示されていれば名前の後に省略記号を付加する。
(3−5)1親等者CIFをもとに関係管理テーブルから子メンバーを抽出し、優先順にツリービュー領域3列目に1メンバー1段で該当の1親等のメンバーと次の1親等のメンバーの間に挿入表示する。
【0020】
ただし、直系の2親等前(参照対象)が同じメンバーなら「2親等洗い出し」はしない。
(3−6)元にする1親等の該当段目のメンバーに省略記号がついていれば「2親等洗い出し」はしない。
(3−7)ツリービュー内にすでに同じCIFのメンバーが表示されていれば名前の後に省略記号を付加する。
(4)n親等洗い出し。(n=3)とする。
(4−1)n列目に表示されているn−1親等のメンバーについて上から順にそれぞれ次の処理を行う。
(4−2)n−1親等者CIFをもとに関係管理テーブルから親メンバーを抽出し、優先順にツリービュー領域n+1列目に1メンバー1段で該当のn−1親等のメンバーと次のn−1親等のメンバーの間に挿入表示する。
【0021】
ただし、直系の2親等前(n−2親等者)が同じメンバーなら「n親等洗い出し」はしない。
(4−3)元にするn−1親等の該当段目のメンバーに省略記号がついていれば「n親等洗い出し」はしない。
(4−4)ツリービュー内にすでに同じCIFのメンバーが表示されていれば名前の後に省略記号を付加する。
(4−5)n−1親等者CIFをもとに関係管理テーブルから子メンバーを抽出し、優先順にツリービュー領域n+1列目に1メンバー1段で該当のn−1親等のメンバーと次のn−1親等のメンバーの間に挿入表示する。
【0022】
ただし、直系の2親等前(n−2親等者)が同じメンバーなら「n親等洗い出し」はしない。
(4−6)元にするn−1親等の該当段目のメンバーに省略記号がついていれば「n親等洗い出し」はしない。
(4−7)ツリービュー内にすでに同じCIFのメンバーが表示されていれば名前の後に省略記号を付加する。
(5)以降、ステップ(4)のnを1累進させて、nが所定の数に達するまで(4)のステップを繰り返し、nが所定の数に達すれば処理終了する。
【0023】
さらに本発明は、前記システムにおいて、
参照対象に設定された二人のメンバーコードにより、その二人に関係ルートが出来上がっているかどうかを、任意の親等まで抽出して表示する、次のステップを実行する手段を有する。
(1)関係の追跡をする二人のメンバーのうち、一方を正、他方を副とし、正メンバーに副メンバーが繋がっているかを追跡するため、設定条件を保存し、検索結果を一時保存するメモリ内の配列エリアを初期化する。
(2)処理を行う際に、ユーザが指定した、最大何親等まで探すか、最短ルートか全てのルートかの設定条件を保存する。
(3)正メンバーの親子の関係である1親等目を抽出する。
(3−1)抽出された1親等目のnaのレコード数のうち、ia番目(i=1〜n)は副メンバーかを判断する。
(3−1−1)副メンバーであれば正メンバーからのルートを前記メモリ内の配列エリアに保存して次の1親等目のレコードに対し、(3−1)のステップの処理を実行する。
(4)副メンバーでなければ、1親等目のia番目のメンバーの親子の関係である2親等目を抽出する。
(4−1)抽出された2親等目のnbのレコード数のうち、ib番目(i=1〜n)は副メンバーかを判断する。
(4−1−1)副メンバーであれば正メンバーからのルートを前記メモリ内の配列エリアに保存して次の2親等目のレコードに対し、(4−1)のステップの処理を実行する。
(4−2)副メンバーでなければ、2親等目のib番目と同じメンバーがルート中の上位に存在しないかどうか判断する。
(4−2−1)存在していれば、その処理を中断し次の2親等目のレコードに対し、(4−1)のステップの処理を実行する。
(5)存在していなければ、2親等目のib番目のメンバーの親子の関係である3親等目を抽出する。
(5−1)抽出された3親等目のncのレコード数のうち、ic番目(i=1〜n)は副メンバーかを判断する。
(5−1−1)副メンバーであれば正メンバーからのルートを前記メモリ内の配列エリアに保存して次の3親等目のレコードに対し、(5−1)のステップの処理を実行する。
(5−2)副メンバーでなければ、3親等目のic番目と同じメンバーがルート中の上位に存在しないかどうか判断する。
(5−2−1)存在していれば、その処理を中断し次の3親等目のレコードに対し、(5−1)のステップの処理を実行する。
(6)存在していなければ、3親等目のic番目のメンバーの親子の関係である4親等目を抽出する。
(7)これをあらかじめ設定された数の親等まで数値を累進しながら繰り返し、最終親等で、次の処理を行う。
(7−1)抽出された最終親等目のnxのレコード数のうち、ix番目(i=1〜n)は副メンバーかを判断する。
(7−1−1)副メンバーであれば、正メンバーからのルートを前記メモリ内の配列エリアに保存し、最終親等の次のレコードに進む。
(7−2)副メンバーでなければ、最終親等の次のレコードに進む。最終親等のレコードがn迄終われば、それより1つ前の親等のレコード数を1つ累進させて処理を行う。
(7−3)1つ前の親等のレコード数がn迄終われば、さらに1つ前の親等のレコード数を1つ累進させて処理を行う。
(8)これを全ての親等のレコード数が終了するまで行う。
(9)前記メモリ内の配列エリアに保存されている検索結果をルートの親等数の少ないものから並べ直す。
(10)検索結果の1番目をツリービューに表示する。
(11)ユーザが検索結果表示の変更をプルダウンリストボックスで指示したときは、検索結果の中のユーザの選択したルートをツリービューに表示する。
【0030】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照しつつ説明する。図1は本発明に係る関係付け情報管理システムの実施の形態を示す図、図2はメンバー管理テーブルの構成例を示す図、図3は関係管理テーブルの構成例を示す図、図4はマスタテーブルの構成例を示す図である。図中、1は入力処理部、2は出力処理部、3はデータ登録・更新処理部、4は検索処理部、5は編集処理部、6は関係管理テーブル、7はメンバー管理テーブル、8はマスタテーブルを示す。
【0031】
図1において、入力処理部1は、関係管理テーブル6、メンバー管理テーブル7、マスタテーブル8などの各データに対する設定、登録、更新、削除などを行う各種データの入力や、検索、編集、出力などの各種指示の入力処理を行うものである。出力処理部2は、各データに対する設定、登録、更新、削除などを行う各種データや、検索、編集、出力などの各種指示の入力画面、各種指示の入力に基づく処理結果に関する画面、情報の表示出力、印刷出力、ネットワークや通信回線を通して他の機器へのデータ転送、送出処理を行うものである。
【0032】
データ管理を行うデータ登録・更新処理部3は、入力処理部1からの入力に基づき各データに対する設定、登録、更新、削除などの各種処理を行うものであり、例えばメンバー詳細情報登録/更新、履歴情報登録/更新、関係入力などを行う。検索処理部4は、入力処理部1からの指示入力に基づき設定された検索条件に従って各データにアクセスしてメンバー情報の検索処理を行うものであり、例えばメンバー該当検索、メンバー履歴検索、メンバー関係検索などを行う。編集処理部5は、入力処理部1からの指示入力に基づき設定された出力条件に従って検索結果を出力するための編集処理を行うものであり、例えばメンバー紹介系図、前後n親等表示、繋がり検索表示などを行う。
【0033】
メンバー詳細情報登録/更新では、メンバーの情報を登録すると共に、更にイメージ画像表示機能により、それぞれメンバーに関係する画像を表示する。また、郵便番号入力後、郵便番号検索ボタンを押すことで、郵便番号から住所を引き当てる。履歴情報登録/更新では、対応履歴、売上履歴のような細かな情報を登録メンバー毎に登録し、更に、入力された内容は、メンバー履歴検索機能を使用することで履歴内容からメンバーを引き当てる。関係入力では、どちらからどちらへ繋がっているか、そしてそれらがどういう関係なのかを登録する。関係区分では、親から見て、子のメンバーとどういう関係かを予め設定した内容から選択し、メンバー関係検索機能を使用して選択した関係区分から登録メンバーを検索する。関係詳細登録では、入力時にその繋がりに対する詳細情報を入力することでメンバー関係検索機能を使用して登録時に入力した詳細情報を利用して検索する。
【0034】
メンバー該当検索では、条件を与えて得られた結果を何度も条件を重ね合わせて目的のメンバー群に絞り込み、かつ(AND)検索では、前回の結果に今回の条件を与えてさらにデータを絞り込み、または(OR)検索では、前回の結果と今回の条件の結果のどちらか一方でも満たせば一致となる。検索により、通常は該当するメンバーをリストボックスに表示し、該当しないメンバーを選択(クリック)すると、条件で選ばれたメンバー以外のメンバーをリストボックスに表示する。メンバー履歴検索では、メンバー毎に入力された履歴を基にメンバーを検索する。例えば履歴を売買情報として使用する場合、先週1週間の内の○○を販売した人といった検索ができる。メンバー関係検索では、メンバー同士の関係を基に検索する。例えば営業マンの顧客開拓用に関係を使用した場合には、顧客毎の見込み率を登録することで、エリア別に営業戦略を立てることができる。
【0035】
メンバー紹介系図では、参照対象者を基に親方向へ2親等、子親等へ2親等表示をし、また、参照対象者を変更することで、全ての関係者を参照することができる。前後n親等表示では、参照対象者を基に、例えば親方向へ5親等と子方向へ5親等、合わせて10親等までの関係者を色分け表示し、画面の片側に親メンバー、子メンバーのリストを表示する。繋がり検索では、任意の2人を指定しそのメンバー間で繋がりがあるかを検索する。
【0036】
関係管理テーブル6は、識別情報により個別の各種情報について1対1で関係付けを行うテーブルである。本発明において、識別情報は、識別子、識別番号、識別コード、ID、ID番号、CIFのほか、OSが管理するファイルアロケーションテーブル(以下、FATという)情報、固体識別可能な属性情報などを含むものである。また、その関係付けに関しては、相互の関係する方向、例えば図3に示すように親→子、主→従、上→下或いはその逆の方向の対応で、さらに必要に応じてその関係度合いが分かる関係区分などの情報を付加したものである。関係区分としては、例えば人に関する場合、一般的には上司、部下、友人、紹介、反目、学校名簿との関係には出身(OB)、人でないものとの関係には所有、会社関係には下請け、提携、取引先、人事評定に使う関係には直属、同僚、所属、金融機関が保証の連鎖関係を管理する際に使う関係には保証人、連帯保証人、所属建物、所属土地、文書・文献・図面との関係には作成者、著作者、紹介者、推薦者など、それぞれの関係に応じて設定される。このような関係管理テーブルは、その使用目的など必要に応じて複数使用される。
【0037】
メンバー管理テーブル7は、各識別情報に対応して各メンバーの情報そのもの、あるいはその情報を取得できる関係情報、例えばFAT情報、FAT内記録アドレス、ファイル種別、位置情報、オブジェクト、属性、属性情報などを含む情報を格納したものである。メンバーは、例えば人、文書・文献・図面、企業・本支店・支社・出張所・部署、場所・施設・機関、商品・機械・設備などのような人や物、施設、機関、組織、データ、ファイルを含む有形、無形の各種管理単位であってあらゆるジャンル、カテゴリーを含む。管理するメンバーデータは、メンバー固有の識別情報と、メンバーに応じて各種別のメンバーの区分け情報やフォルダなどの位置情報や、物理アドレス番号で表される関係情報、メンバー固有の詳細情報などを登録し、メンバー情報で直接、またはメンバー情報を取得するための情報で間接に管理する。例えば図2に示すように各メンバー毎の区分けする区分け情報は、それぞれのメンバー種別、ランク、分類、業種などの情報であり、メンバー固有の詳細情報は、摘要、履歴などの情報である。日付は、登録・更新の日付である。
【0038】
区分け情報のメンバー種別、ランク、分類、業種などは、検索を行うため、編集出力するための条件であり、その指定の有無によって検索、編集出力の対象に含めるか除外するかなどを判断する。摘要の情報は、例えば人であれば氏名をメンバー名として、性別、生年月日、住所、電話、ファックス、メールアドレス勤務先・所属・役職・入社年月日、所属グループ、趣味、経歴・略歴、写真など、また、文書・文献・図面であればその名称をメンバー名として、文献分類、作成日・発行日、作成者・発行者・著者、内容の要約、推薦文・紹介文などを含む任意の情報である。履歴の情報は、メンバーの略歴や更新履歴などを含む情報である。
【0039】
マスタテーブル8は、例えばメンバー管理テーブル7にそれぞれのメンバー情報に応じて最低限必要な情報の登録がなされるようにするために登録区分を設定したり、検索や編集出力の条件として指定する際に必要な各種情報の定義テーブルなどを有するものである。例えば図4に示すような種別テーブルやランクテーブル、分類テーブル、業種テーブル、関係区分テーブルなどがそれらである。
【0040】
種別テーブルは、例えば図4(A)に示すようにどのようなメンバーかを識別する種別の情報、人、会社、文書、……などを定義するものである。ランクテーブルは、例えば図4(B)に示すようなランクと優先順位を定義するものであり、一般的なランクとしては最重要、重要、顧客Aランク、顧客Bランク、顧客Cランクなどのランクに高、中、低などの優先順位を定義し、特殊なランクとしては交渉中、再度交渉可、面識なしなど、メンバー種別が人でないものでは動産・不動産など、名寄せを処理したメンバーに使う目的のものとしては本人、名寄せ済みなどのランクに高、中、低などの優先順位を定義する。
【0041】
分類テーブルは、例えば図4(C)に示すように地域、人事評定や社内評定に使う部課、商品、グループなどを大分類、中分類、小分類に属する項目として定義する。業種テーブルは、例えば図4(D)に示すように製造業、情報サービス業、自治体、建築・建設業、保険・金融業、農林漁業、自営業など各業種を定義するものである。
【0042】
関係区分テーブルは、例えば図4(E)に示す関係区分とそれぞれの優先順位を定義するものであり、種別が人の一般的な区分としては上司、部下、友人、紹介、反目など、親を学校名等にする場合の区分としては出身(OB)、子を人でないものを対象とする場合の区分としては所有、会社と会社の間の関係を結ぶ場合の区分としては下請け、提携、取引先など、人事評定に使う場合の区分としては直属、同僚、所属などがある。
【0043】
関係区分は、登録されたメンバー同士をつなぐ「手」の役目を果たし、2つのデータ(メンバー)の係わりを表すコードで定義される。人と人、人と物、物と物とを関係付ける際に、どういう関係で結ばれているのかを指定するためのものであり、関係にも深い繋がりからちょっとした繋がり、例えば人と人の場合には顔見知り程度まで、関係の度合いに差がある。関係区分は、このことを考慮して優先順位をつけているのであり、より重要でより密接な関係を上位に表示させるなどのことができるようにしている。
【0044】
次に、本発明に係る関係付け情報管理システムの関係付け検索処理について説明する。図5は本発明に係る関係付け情報管理システムの関係付け検索処理の流れの例を説明するための図、図6は検索条件及び出力条件の例を説明するための図である。
【0045】
本発明に係る関係付け情報管理システムの関係付け検索処理は、例えば図5に示すように検索条件の設定(ステップS11)、出力条件の設定(ステップS12)を行う。ここでは、検索条件として、検索を開始するメンバーに対して、例えば図6(A)に示すようにどのようなメンバー種別を対象にするか、どのような分類、ランク、業種を対象にするか、さらには検索範囲、例えば何段まで、何親等までかを対象にするかを設定する。また、出力条件として、編集出力する範囲や条件を、例えば図6(B)に示すように親、子をどこまで出力するか、その際の出力色をどの色にするか、関係も併せて出力するか、親・子の方向を矢印で出力するか、親・子を左右方向に分けて出力するか、親・子を表形式で出力するか、ツリー構造で出力するか、など出力するモードやパターンをどのようなものにするかを設定する。
【0046】
次に、検索条件に従い親から子の検索を行って(ステップS13)、検索された子及びその関係をメモリに保持する(ステップS14)。同様に子から親の検索を行って(ステップS15)、検索された親及びその関係をメモリに保持する(ステップS16)。さらに出力条件を基に次段の検索も対象になるか否かを判定し(ステップS17)、次段の検索が必要な場合には、ステップS13〜S16で検索、保持された最終段のメンバーを検索キーとした後(ステップS18)、それら検索、保持されているメンバーと重複する場合には検索キーを削除して(ステップS19)、ステップS13に戻り同様の処理を繰り返し実行する。
【0047】
ステップS17で、検索が終了したと判断された場合には、設定された出力条件に従って検索結果の編集を行い(ステップS20)、その編集した検索結果を出力する(ステップS21)。
【0048】
次に、メンバーデータに登録される詳細情報について具体的に例示し説明する。摘要の情報は、項目名を限定せず、用途に応じて変更可能なものであり、例えば一般的な摘要項目においては、記録台帳番号、初回取引日、事業内容、取引内容覚書など、保険の外交営業に使用する場合においては、証券番号、入保月日、家族構成,病歴など、人事評定に使用する場合においては、社員番号、入社年月日、家族構成、特筆事項、総合評価など、金融機関が保証の繋がりを管理する場合においては、口座種別・番号、契約日、家族構成、保証債務の有無、資産など、営業に使用する場合においては、会員番号、初回訪問日、特徴、趣味・嗜好などの情報が登録される。
【0049】
履歴の情報は、時系列の対応記録を入力できるようにするものであり、例えば一般的な項目においては、日付、打ち合わせ内容、数値目標、達成度、次期繰延べなど、営業に使用する場合においては、購入日、購入品名、数量、購入金額、ポイント数など、保険に使用する場合においては、保険額変更月日、保険名称・内容、入金回数、基本金額、合計金額など、人事に使用する場合においては、年月日、業務名、金額、自己評価、内部評価など、金融機関が使用する場合には、貸付日、担保、貸付金額、毎月返済予定額、残高などの情報が登録される。
【0050】
関係入力の画面で繋がれるメンバー相互の関係を付加情報として関係摘要項目を入力する場合には、項目を用途に応じて設定する。例えば一般的に使用する場合には、出来事、親の注意点、子の注意点、紹介日、共通の記念日、備考日付、親→子信頼度、子→親信頼度、親密度、評価(親→子)、評価(親←子)など、取引関係に使用する場合には、受注、発注、下請、紹介日、取引日(初回)、取引日(最終)、持株、発注ウエイト、受注ウエイト、関係の変遷、取引内容など、保険に使用する場合には、共通の趣味、特技、健康状態、最新遭遇月日、初見月日、結婚記念日、親密度、知合年数、敵意、備考など、人事に使用する場合には、年度、配属部署、配属年月日、評価年月日、移動年月日、能力、協調性、頑張り、評価(親→子)、評価(親←子)など、金融機関で使用する場合には、保証内容、抵当権順位(物)、メモ、保証更新日、初回支払日、最終支払日、保証金額、保証限度額、路線価(物)、詳しい関係などが登録される。
【0051】
本発明に係る関係付け情報管理システムの拡張した実施の形態についてさらに説明する。図7はシンクロ方式を利用する場合について説明するための図、図8は親選択集団と子選択集団を使った並列の関係付けの例を説明するための図、図9はカテゴリーの一致による並列の関係付けの例を説明するための図、図10はLL方式のデータベース間インポートの例を説明するための図である。
【0052】
既に構築、運営されている他のデータベースに本発明の関係付け情報管理機能を持たせるシンクロ方式について説明する。既存のデータベースに関係管理機能を付加するには、それを運営するソフトウエアそのものをはじめから作りなおす方法とデータ受渡しインターフェースを持つ関係管理ソフトウエアを連結させる方法とがある。シンクロ方式は、その後者を指す。このシンクロ方式では、既存のデータベース構造の、ソフトウエアを全く改造することなく、図7に示すようにそのデータベースが持つデータ固有のID番号を関係管理テーブルに記録する。つまり、1つのデータベースに異なったソフトウエアが複数付いていることになる。しかし、データベース自体は既存ソフト用に設計されている場合が多いので、既存ソフトからの情報を受け取るインターフェース部分を関係管理ソフト側で持つ。それにより、関係管理ソフト側では、基本的なデータ表示部分を開発することなく、既存ソフトのデータ参照部分を利用できる。関係管理ソフト側では、既に登録されているデータ同士の関係付けをし、系図表示などの関係管理機能部分を受け持つ。関係管理ソフト内に既存ソフトの機能を全て取り込み(外部ソフト実行機能による)、外見的には既存システムに関係管理部分が追加されたようにすることも可能である。
【0053】
シンクロ方式を利用するためには、既存ソフトでの追加・修正・削除によるIDの変更を関係管理ソフト側で監視する必要があり、既存ソフトがIDの変更を許容している場合には、そのID番号振りなおしに関係管理ソフト側が対応するか、既存データに不変的なIDを付加する必要がある。シンクロ方式を応用することにより、稼働中のデータベースシステムにとって変わる新しいシステムを導入することなく、省コストで関係管理機能を持ったシステムへと移行させることができる。
【0054】
次に、自動関係付けについて説明する。与えられた条件に一致するもの、カテゴリー、選択したものなど、メンバー管理テーブルに登録された任意の1または複数のデータと、異なる1または複数のデータの関係付けの処理を行うようにしてもよい。この場合、直列の関係付けとして、任意の指定により選択された複数のデータを順に直列につなぐ関係付けが、ユーザ指定により予め並び替えされた順に、あるいは1つずつ順に行われる。
【0055】
また、並列関係付けとして、親選択集団と子選択集団に、それぞれ全てのデータの中から条件指定によって抽出されたデータ、データが個別に持つカテゴリーで抽出されたデータ、任意に選択されたデータ、または全てのデータが表示され、親子の指定により関係付けを行い関係管理テーブルを作成する。
【0056】
この場合、例えば図8(A)に示すように親選択集団と子選択集団に1つずつメンバーがあったとき、それぞれを直接親と子として1対1の関係付けを行う。また、親選択集団に1つと子選択集団に複数があったとき、1つの親をそれぞれの子と1対1の繰り返しで子の件数分、1対多の関係付けを行い、親選択集団に複数と子選択集団に1つがあったとき、1つの子をそれぞれの親と1対1の繰り返しで親の件数分、多対1の関係付けを行う。
【0057】
また、親選択集団と子選択集団にそれぞれ複数あったとき、1対多の関係付けを親の件数分、あるいは多対1の関係付けを子の件数分行ったり、図8(B)に示すように親と子の間に新規または既存のデータαを指定し、全ての親指定データはαの親、全ての子指定データはαの子として関係テーブルに保存する多対多の関係付けを行う。それぞれ関係付けは、関係付けボタンなどの一括処理起動や、ドラックアンドドロップなどで行う。
【0058】
また、カテゴリーの一致による並列の関係付けとして、図9に示すようにメンバー管理テーブルのデータ1件1件にカテゴリー登録枠を複数個設け、馬、木、りんご、花、山などそこに登録されたカテゴリーに一致するデータを選びだして新規または既存のデータに関係付けする。例えば同じグループなど同じ属性、同じ言葉を含むデータについて同様に適用できる。
【0059】
データベース間でのインポートについて説明する。本発明の関係付け情報管理システムを、例えばプロフェッショナル版、スタンダード版、パーソナル版のように複数のグレードに分けると、これらを利用して、例えば図10に示すように管理者と1人または複数の部員とでLL方式のような疑似ネットワークを組むことができる。ここで、プロフェッショナル版は、データ登録制限なし、履歴情報入力・検索可、関係詳細情報入力・検索可、複数データベース可、スタンダード版は、データ登録制限なし、履歴情報入力・検索可、パーソナル版は、数百件までの登録制限とし、共通のデータベースを利用するものとする。そして、プロフェッショナル版は、データベースを複数保有し、切り換えながら利用することができる。データベースは、同一フォルダ内でなければ、LAN上の他のパソコンのどこにあっても操作対象とすることができる。
【0060】
管理者は、プロフェッショナル版を利用することにより、自分のデータベースのほか、部員のデータベースを参照・更新可能になり、部員は、スタンダード版を利用することにより、自分のデータベースしか操作できなくなる。万が一、他の人のデータを無断コピーしてもデータベース毎に4ランクのIDとパスワードを設けることにより、内部に入ることをできなくする。プロフェッショナル版は、スタンダード版では見ることのできない関係詳細情報の部分の参照・更新ができるので、部員のデータベースに本人の管理外での書き込みが可能となる。
【0061】
また、任意に指定されたデータからn親等までの範囲で関係付けされたデータをインポートの対象とし、取り込み側のデータ識別コードと重複しないコードを振り直してインポートする。インポートの際、取り込み側と、移植側に同一データが存在した場合には、更に「本人」(同一データであるという関係区分)で関係付けを行う。同一かどうかの判定が曖昧な場合にはユーザにメッセージするか別データと判断するかを選択させる。
【0062】
次に、ファイル管理ソフトでの運用について説明する。図11は関係を繋ぐ媒体について説明するための図、図12はエクスプローラ等のファイル管理ソフトにおける関係付けについて説明するための図、図13は多種類データのファイル内の部分的な関係付けについて説明するための図、図14はその他のファイル等の関係付けについて説明するための図、図15は複数の管理テーブルを設けて関係付けする場合について説明するための図である。
【0063】
ファイル管理ソフト(エクスプローラ等)の現状を見ると、ファイル管理ソフトは、全体を1つの大きな収納庫と考え、フォルダという分類可能なコンテナボックスにファイルを分けていれるだけでファイル関係を探すことはできない。しかし、ファイルを管理している上で、ファイル同士の繋がりが分かった方が整理しやすいというのは万人の望むところである。
【0064】
例えばワードで作成された文書Aがあり、それを修正した文書A′があった場合、2つの文書に関係があるというのはファイル名か、同一フォルダに保存されているか、プロパティに関係があることを記録する他はない。もし、プロパティで識別するならば、A''、A''' 、A''''などが作成された場合、後から作成された文書が前に作成された文書と関わりがあることを、それまで作成された全ての文書のプロパティに記入していかなければならない。
【0065】
A''''を作成した時、A''' のプロパティしか変更しなければ、ひとつずつ遡ってプロパティをみていかなければ、AとA''''に関係があることが分からない。同様に、異なるファイル形式(文書、表計算、画像、CAD等)に関係があることは、カテゴリーで分けると作成者でまとめられない。ファイル種別でわけると、業務での統一ができないなどの不便が生じる。
【0066】
そこで、ファイル管理ソフトに本発明の関係付け情報管理機能が加われば、格納してある場所はカテゴリー別や作成者別など分かりやすいフォルダに整理しておき、それに関する各種ファイルの関係図を表示することによって、変更の履歴や、業務プロジェクトでの括りができるようになる。
【0067】
ファイル管理ソフト内に、自動関係付け機能、親子孫のような系図表示、前後5親等のようなツリー系図表示、繋がり検索のような一定の親等間のルート探索機能、関係入力画面などの機能を備える。関係付けは、関係入力画面等を利用しても、ドラッグアンドドロップでもできる。エクスプローラ上で関係付けされたファイルがコピーされた場合、関係付け全てをコピーするわけではなく、元ファイルと複製という関係付けでつなぎを作る。ファイルが隠しファイルであった場合には、隠しファイルを見せない設定の時には関係付けもされないような表示にする。関係付けは、ファイル名ではなく、ファイルを識別情報とし、フォルダなどの位置情報や物理アドレス番号などを利用することもできる。
【0068】
関係をつなぐ媒体について説明する。関係をつなぐという本発明の関係付け情報管理機能の思考に媒体も含めると、音声情報、時間情報、位置情報などを含め、その一部を取り出しても独立したオブジェクトとして特定できる属性または属性を持つ情報を対象とし、データベース等の配列に入れる。例えば図11に示すように表計算ソフト(A)の任意のシートや選択されたセル、ファイル管理ソフト(B)のファイル全体、CAD図面(C)の図面内の任意のオブジェクト、画像(D)の画像全体または任意の選択された部分に関して、配列の背番号もしくはアドレスなど、それぞれを特定できるキーを識別子として用い、メンバー管理テーブル(F)に関係情報を格納し、関係管理テーブル(E)で関係付けを行うことにより、エクスプローラに限らず新規または既存のアプリケーション内で利用可能とする。
【0069】
エクスプローラ等のファイル管理ソフトにおける関係付けについて説明する。エクスプローラ等において、表示されるフォルダとファイル名は、OSが管理するファイルアロケーションテーブル(以下、FATという)などのディレクトリパスに記憶している。このようなエクスプローラ等に本発明の関係付け情報管理機能を持たせるためには、メンバー管理テーブルをFAT以外に持つ方法▲1▼、FAT自体をメンバー管理テーブルとして利用する方法▲2▼、関係管理テーブルがIDを管理する考え方ではなくFAT情報そのものを持って関係管理をする方法▲3▼を利用することができる。
【0070】
メンバー管理テーブルをFAT以外に持つ▲1▼の方法では、図12(A)に示すようにメンバー管理テーブルでIDと、FATに記録されているファイル情報をそのままコピーして利用するか、FAT内の物理的な記録位置アドレスなどの情報を利用する。また、▲2▼の方法には、図12(B)に示すようにOS設計の段階でFATそのものの形状を変更してIDを持つようにする場合と、FAT内の物理的な記録位置アドレスなどの情報を関係管理テーブルに直接入れて関係付けをするか、FAT情報そのものを関係管理テーブルに格納して関係付けする場合などがある。そして、▲3▼の方法では、FAT情報それ自体が1件1件を識別できる内容になっているので、図12(C)に示すように特別にIDをつけなくてもそのまま関係管理テーブルに記録することによって関係管理ができる。この方法では、関係管理テーブルにFAT情報またはFAT内の物理的な記録位置アドレスを格納するので、ファイルやフォルダの変更時に関係管理テーブルの同時変更が必要になる。
【0071】
関係をつなぐ対象は、ファイルやフォルダを問わず、ネットワーク上であってもファイル管理ソフト上で処理可能なものであれば実施が可能である。エクスプローラと同様の機能を持つ個別アプリケーションに付属しているエクスプローラライクのものは、FATの代わりに独自のエリアにファイル情報を持っているが、機能としては同じである。
【0072】
具体的な実行例を説明すると次のようになる。まず、画面のどこかに関係付け対象とすべきファイル等を指定するエリアを設け、入力またはドラッグアンドドロップ等で関係付けをする対象を入れる。各指定領域にはリストボックスのように、1つまたは複数の指定ができ、先に図8で説明したように1対1、1対多、多対1、多対多の関係付けができる。そこで、任意のファイル等を選択し、例えば系図表示ボタンまたは右クリックからのメニューに系図表示を選択して関係を表示させる画面へ移行させる。さらに、2つ以上のファイル等の関係を追跡する繋がり検索画面や前後n浸透全ての関係表示のできる画面を持ち、任意の画面から進むことができる。関係付けされているファイルやフォルダ等がコピーされた時は、関係もコピー元と同様に継承されるか、コピー元とコピー先のみの関係付けかを選択することができる。
【0073】
多種類データのファイル内の部分的な関係付けについて説明する。多種類データの部分的な関係付けは、ファイル名やフォルダ名の関係付けのみだったファイル管理ソフトの場合と違い、関係するアプリケーションとそれにより作成されるデータファイルに関係情報や関係情報処理機能を持たせなければならない。これは、関係の管理をエクスプローラのようなOS側の管理ソフトに任せる場合やそれぞれのアプリケーションの内部だけでデータの関係付けをする場合においても同様である。
【0074】
例えば画像処理ソフトとそれにより作成された画像ファイルを例に説明する。一般にアプリケーションで作成されたファイルの持つ情報は、画像情報のほかに、形状・オブジェクト、カラー・彩度・明度・アルファチャネル・レイヤ情報・変更履歴のような属性情報を持つファイル形式(フォトショップのPSD等)から、画像情報のみを持つ形式(BMP等)といったように、利用環境によって様々である。そのファイル形式と、使用するアプリケーションによって、ファイル内に保有できる属性は、情報量が違っている。画像内で範囲切り出しされたものを、クリップボードを経由してコピー・ペーストするという場合には、コピーされた瞬間のデータのみを対象とすればよいので、その際の属性は引き継いでも、ファイル情報などは継承しなくてもよい。しかし、関係を結び、継続的な関係を維持していくには、内容の変更や関係範囲の変更・移動に対応しなければならない。従って、ファイル自体に、関係付けされた部分がどの範囲のどういう属性情報だったかを記憶しておく必要があり、画像処理ソフトでは、ファイルに保存された関係情報を表示し、変更を監視する機能が必要になる。ここでメンバー管理テーブルを用いることにより、基本的なデータを保存するのではなく、関係付けをすべき選択範囲が存在する場所やデータの特性などが記録され、データの本体はオリジナルファイルの中に存在する。勿論、データ自体をオリジナルファイルからコピーしてメンバー管理テーブルに記録することも可能である。
【0075】
即ち、図13に示すようにファイルに関係指定範囲情報を持ち、メンバー管理テーブルと関係管理テーブルを使うほか、メンバー管理テーブルは使わず、関係管理テーブルのみで関係管理をする場合、ファイルには持たず、メンバー管理テーブルまたは関係管理テーブルで情報管理をする場合などそれぞれの組み合わせに応じた利用環境がある。
【0076】
次に、関係レイヤを設けた場合の例を説明する。画像データに重ねて透明の関係指定範囲を表示する関係レイヤを設ける。画像処理ソフト内で関係付けする範囲を指定し、その範囲を関係レイヤに表示する。指定された範囲の持つ属性には、選択された形状・オブジェクトのほか、カラー・彩度・明度・アルファチャネル・レイヤ情報・変更履歴などアプリケーションによって保有できる情報量が違うので、ここでは選択範囲とその他の属性として説明する。画像処理ソフトに関係情報設定ボタン等を設け、それがオンの状態で範囲を選択すると、メンバー管理テーブルにID、ファイル種別、ディレクトリパス、ファイル名、選択範囲、その他の属性などを書き込む。同時に、選択範囲をメンバー管理テーブル書き込みのときに取得したIDを指定範囲の識別名として画像ファイル内に選択範囲情報と共に記録する。メンバー管理テーブルに書き込まれた個別情報は、関係入力ボタンまたは右クリックのメニューなどによってOSのファイル管理ソフトの関係入力の画面で、その他の情報と関係付けをし、その関係を関係管理テーブルに書き込み。画像データの関係指定範囲に含まれる部分に修正が加えられた場合には、画像処理ソフトの監視機能によって関係指定範囲の変更をするかどうかを訪ねてくることにより、変更があれば、その情報を記録している画像ファイルやメンバー管理テーブルの変更も行われる。
【0077】
メンバー管理テーブルを用いない場合には、直接、関係管理テーブルにファイル種別、ディレクトリパス、ファイル名、選択範囲、その他の属性などを書き込んで関係付けをしてもよい。しかし、同じファイルを同じ指定範囲、同じ続低で違う関係付けをするための独自のメンバーを考えるならば、IDを含め、メンバー固有の識別可能な形式にして保存しなければならない。
【0078】
画像ファイルに関係情報を記録しない場合には、それらの全ての情報をメンバー管理テーブルまたは関係管理テーブルに記録し、画像処理ソフトは、関係レイヤなどに表示するための情報を画像ファイルからではなく、それらの外部テーブルから受け取る。OSや統一管理ソフトで管理せず、アプリケーションで単独に管理せず、画像アプリケーション内で単独管理する場合には、アプリケーション独自の関係管理テーブルとメンバー管理テーブルを持ち、関係入力や系図表示等の機能は画像処理ソフト内に装備することになる。
【0079】
以上は画像についてであるが、ワープロソフトと文書ファイル、表計算ソフトとブックファイル、CADソフトと図面データ、音源ソフトと音源データなど、同様の組み合わせで記録と監視機能が必要になる。図14に示すようにメンバー管理テーブルを利用する場合には、ID、ファイル種別、ディレクトリパス、ファイル名、選択範囲、その他の属性、例えば表計算であれば、シート、セル、書式情報など、CADであればレイヤ、線種、色、形状など、文書であれば、ページ、書式情報など、音源であれば、時間、波長、音域情報などを記録する。メンバー管理テーブルを迂回せず直接関係管理テーブルに書き込む場合には、関係管理テーブルに、ファイル種別、ディレクトリパス、ファイル名、選択範囲、その他の属性などを記録する。それらは、データ同士が識別可能な形であればよいので、パソコン内部の絶対アドレスなどといった、関係をつなぐためのビット単位のメンバー同士の関係まで表すことのできる表現を用いても応用できる。それぞれの入力、表示手段は、画面、印刷媒体のほかに、Web、ASP、PDAなどの外部通信手段を利用したものでもよい。基本的には、関係管理テーブルで親子関係を繋いだデータ同士を系図型に表示し、いもづる式に辿っていくことができる機能は、各ソフトウエアのデータ側でもコンピュータのOS側でも持つことができる。その他、任意のデータ間の関係を追跡し表示する繋がり検索機能を持つこともできる。
【0080】
複数の管理テーブルを設けて関係付けする場合について説明する。関係付けの対象は、登録されたメンバー同士であるが、履歴情報同士の関係を持ちたいときや、履歴と関係情報や、画像と他メンバーの摘要項目などを関係付けたい場合など、1つのメンバー管理テーブルや関係管理テーブルでは表すことができない。これに対応するため、図15に示すようにメンバー管理テーブルや関係管理テーブルは、1つのシステム内に1つではなく、複数存在することもできる。N番目のメンバー管理テーブルは基本となるメンバー管理テーブルのどの識別情報(CIF)のどの情報のどの部分に関するものかという属性まで含んだ形で記録され、N番目の関係管理テーブルには、部分関係入力用の画面によって関係付けられた親子関係が記録され、部分関係表示用の系図に表示される。こうすることにより、頭だけの関係しか見ることのできなかった関係系図のほかに、それぞれの部位の繋がりまで見ることができるようになる。
【0081】
次に、本発明を系図型人脈管理システムとして適用した場合の実施の形態を説明する。本実施形態においては、3次元でしか表せなかった関係図をコンピュータの中で管理し、その一部を取り出して表すことにより、2次元の紙の上で表現することができるようにした。以下に、その考え方を記述する。
【0082】
本実施形態のシステムは、データ入力の際、条件検索やフリガナ検索などの検索機能を充実させ、重複データの登録を極力させないようにする。そのため、関係付けをしようとするデータが一点集中型で管理され、無駄な繋がりが作成されにくくなっている。また、重複データがあった場合にも、それらを「同じ人のデータ」という関係でつなぐことにより、系図を作成したときには必ず近所に表示されていることになる。
【0083】
一般の顧客管理の考え方からいえば、図16に示すように、データはカード形式に保存されているので、個別データの一部に次に繋がるデータの顧客番号等を記憶しておくという手法をとる。本実施形態のシステムでは個別データと関係データを完全に分離した形で管理している。関係のデータも1:1で保存する。関係を表す基本のファイル(データベースのテーブル)は親の顧客番号と子の顧客番号と関係コードを持っている。
【0084】
図17は、そのテーブルの一例を示すものである。それを、親順に並べると、一人の人に複数の子がいることがわかる。図17の例でいえば、図18に示すようにAさんには、BさんとDさんという子関係の人がいる。Cさんには、Aさんという子がいて、Dさんには、BさんとEさんという子がいる。さらに、このファイルを子順に並び替えると、図19に示すように、Aさんには、Cさんという親がいる。BさんにはAさんとDさん、DさんにはAさん、EさんにはDさんという親がいることになる。
【0085】
これをAさんを中心に親子関係を見ると、図20のようになる。本実施形態のシステムはこの連鎖を繰り返しながら、系図を作成する。ただし、系図の中に同じ人が現れた場合には、系図の中心人物により近い場所に出現したほうを正規のルートとして、それ以降のつながり表示は正規ルートと重なるので、「…」で省略している。これにより、同じ人が系図の中に何度現れても(循環しても)、確実に関係ルートを探し出せる。
【0086】
さらに、本実施形態のシステムには、繋がりをただ繋がっているというだけではなく、どっちからどっちへ繋がっているという方向性を持たせている。それは、系図をツリー構造で表すときに、非常に大切な意味を持つ。前述のように、親を元に並び替えをし、子を元に並び替えをすることにより、繋がりの方向性がはっきりし、中心になる人を決めることで、それに繋がる人を引き当てることが可能になるからである。
【0087】
一般の系図のような、「親→祖父→曽祖父」といった直系重視から、「親→子→子→親→親」といった単発的な組み合わせでの連鎖のほうが、より遠くまで関係をつないで見ることができる。また、親子の方向性を持たせたことで、対等な関係でしか表現できなかったつながり部分を、部下・上司・恩師・教え子のように、明確な関係を表現できるようになった。そして、それぞれの関係区分に優先順位をもたせたことにより、繋がりの強さを判断することができる。
【0088】
図21に示すように、本実施形態のシステムの利用者がXさんに繋がりを持ちたいと思ったとき、そのどちらのルートのコネを利用すればより効果的かがわかる。このように、繋がりを親子で表すことにより、その関係を区別でき、さらに繋がりの深さを区別できることになる。また、系図を世代で表すと「親→祖父→曽祖父」という直系での見方になるので、上は上、下は下という完全な流れができてしまう。しかし、親等で表すと、「親」と「子」しかないので親が上から下、子が下から上という概念を捨ててしまえば、図22に示すように、関係を蛇腹折のように折りたたむことができるようになる。
【0089】
これを利用して、本実施形態のシステムでは系図を作成するとき、図23に示すように、最も左に系図の中心になる人を置き、その人から、1親等目を親子を問わず、右に1段ずれて表示する。2親等目も親子を問わず、右にもう1段ずれて表示する。これを繰り返すことによって、系図はツリー構造に展開し、平面状に書き表すことができるようになる。このようにして、系図を世代ではなく、親等で表すことにより、親方向と子方向への繋がり方向を固定化せず、自由に追跡し、ツリー表示することができる。
【0090】
さらに、本実施形態では、関係のみを表すファイルに親子のつながりだけを入れてあるので、「親→子→親→子」と機械的に見ていくだけで、関係の連鎖は続く。ただ、画面表示や印刷表示の制限から、一度に見られる範囲を区切っているだけであるので、区切られた所から先に関係があれば、そこから同様に「親→子→親→子」と機械的に追跡を繰り返し、系図に作り上げていくことは可能である。それを、実際に表しているのが、「メンバー紹介系図(親・子・孫)」である。直系のみの表示であるが、関係が続く限り、どこまでも表示することができる。
【0091】
さらに、関係検索という機能では、図24に示すように、任意の二人を指定して、その二人に関係ルートができ上がっているかどうかを追跡することができる。最短の関係のほかに、指定した親等内ですべてのルートを探し出し、そのルートを系図表示する。ここでは参照対象メンバーから親方向へ5親等と子方向へ5親等、あわせて10親等のつながりを持つすべてのメンバーを表示している。図25に示すように、5親等とは関わりが5人目の人を指す。参照対象者から見たとき、Aさんは6親等目になるので系図の範囲外になるが、Bさんを参照対象者にすれば5親等目になるので系図に表れてくる。端同士のCさんから見て、Dさんは10親等目、11人のつながりが発見できる。このように、系図の表示範囲外になったメンバーも、参照対象をずらして系図を作成することにより表示が可能となる。
【0092】
以下、実施例について説明する。図26は本実施形態の系図型人脈管理システムのソフトウエア構成を示すシステムブロック図である。データベースとしては、氏名または団体名、住所、電話番号等の個人・団体のメンバー情報を格納するメンバー管理テーブルと、そのメンバー管理テーブルに登録されたあるメンバーとそのメンバーに関係する他のメンバーの二者の関係を親子関係で規定するとともにその関係の種類および関係の優先順位を表す区分コードを記入する関係管理テーブルとを有し、マスタテーブルには、区分コードがどのような関係を表すかおよびどのような優先順位を表すかを規定する区分テーブル等の参照テーブルを有している。
【0093】
以下に、本実施形態の実施例のシステムにおける基本的な操作手順とデータ処理について説明する。図27は本システムのメインメニュー画面を示すものである。
1.メンバー管理
・メンバー追加
・メンバー修正
・メンバー削除
上記の3つは個人や団体の情報の入力・更新・削除を行う。
・関係入力
・系図表示
上記の2つはメンバー同士の繋がりや系図を登録・表示する。
2.データ資料
条件を指定して、登録されているメンバーの内該当するメンバー群を抽出し、帳票やテキストファイルに出力する。
3.基本設定
システムの基本となるコード設定などを登録・管理する。
4.システム管理
データベースの保守管理をする。
【0094】
図28は図27のメインメニュー画面の「メンバー追加」ボタンを押したときに現れる入力画面を示す。この画面から、個人登録か団体登録かを選択し、個人登録の場合は氏名、フリガナ、生年月日、男女の別、住所、電話番号、ファックス番号を入力する。また、このメンバーのデータを他の閲覧者に公開するか非公開にするかを選択する。この入力画面における特殊な入力項目について説明する。
【0095】
1.BOX
BOXとはランクコードのことである。入力しようとしているメンバーが、ユーザにとってどういう相手なのかを表す。図29、図30にその例を示す。メンバーのデータカードをランクの箱に仕分けして保存するという意味で、BOXと呼ぶ。BOXは優先順位をつけることが可能である。
【0096】
本実施形態のシステムは、顧客のみを管理する顧客管理ソフトとは異なり、面識はなくとも将来つながりを持ちたいと思っている人や、その人の関係者を入力しておくことが重要になる。BOXに「面識なし」という意味のランクを設けておけば、現在の顧客との区別をつけることができる。登録データを増やし、関係をつないでいくことにより、つながりを希望していた人への人脈ルートが出来上がる可能性が広がる。その場合は「関係検索」機能によって、人脈ルートがつながったかどうかを検索することができる。
【0097】
2.分類コード
分類コードは登録メンバーの統計資料作成や所属分類に振り分けるために設けている。入力しようとするメンバーが、大分類・中分類・小分類で区分される事項のいずれに属するかを指定し、件数や比率をグラフ等で表示する。この分類コードの例を図31に示す。分類項目には「都道府県・市町村・町名」などの住所によるもののほか、所属部署や管轄地区など集計目的に合わせて三段階に分類する。
【0098】
本実施形態のシステムを人脈ではなく、物品管理などに利用する場合には、地区ではなく、管理分類として応用することも出来る。
例としては、在庫管理:倉庫、棚、箱
カー用品:メーカー、パーツ、部品
動植物 :目、科、属
等である。
【0099】
3.関係区分
関係区分は、図27の「基本設定」ボタンを押下したときに表れるメニューの一つである。この関係区分は、登録されたメンバー同士をつなぐ「手」の役目をする。人と人を関係付ける際に、どういう関係で結ばれているのかを指定するために設けている。関係にも、深いつながりから、ちょっとした顔見知り程度まで、関係の度合いによって優先順位をつけることが可能である。その例を図32、図33に示す。
【0100】
2つのデータのかかわりを表すコードであるので、別々のデータを同じものとするという指定も可能になる。たとえば、結婚による姓の変更、企業やグループの名称変更など、日常的によく見られる出来事である。この場合のように、旧名のときの内容と新名での内容をそれぞれ残す方がメンバーの状況を把握しやすいことが多々ある。
【0101】
本実施形態システムは、関係区分に既定初期コードとして「本人」という関係を用意している。一般の顧客管理ソフトであれば1つのデータにまとめて登録しなければならないが、本実施形態のシステムはデータ同士を「本人」として関係付けてしまえば、データを一本化する必要はない。不確かなデータや間違って重複して登録されたデータもデータ同士をすべて「本人」として関係付けてしまえば、見落とすことはない。
【0102】
「本人」としてつなぐメンバー同士のデータは、どれかを主データに、その他を従データとして1親等でつなぐ。どのデータが主データかが判別しにくい場合には、BOXに「重複データ」を意味するコードを設け、従データのBOX欄に指定すると見分けやすくなる。また、統計資料のデータ件数に重複を避けたい場合にも、分類コードに「重複データ」という意味の分類を設けて、従データの地区に指定すると、不要のカウントはそちらに集計される。
【0103】
人脈であるから、仲が良いという情報だけではなく、犬猿の仲という関係が登録されていてもかまわない。同じ集まりに出席を呼びかけてはいけない場合や、その人の前では話題にしてはいけない人など、要注意の関係も入れておくと非常に役立つ。また、メンバーが転勤や退職などで関係が途切れたとしても、その関係者と新たな関係ができることがあるので、関係の削除はせず、残したままとすることが好ましい。
【0104】
次に、関係入力について説明する。図28の下に表れる「関係入力」ボタンを押下すると、図34に示す関係入力画面が表れる。ここでは、メンバーとメンバーのつながり及びその内容を設定する。ただ、AさんとBさんがつながっているというだけではなく、どちらから、どちらへつながっているか、どういう関係なのかを指定する。どちらからどちらへは、主となるメンバーを親、従となるメンバーを子として関係を考える。親から見て、子のメンバーとどういう関係なのかをあらかじめ考えられるパターンを前述の関係区分に登録しておく。
【0105】
図34の画面上部には、この画面の前処理であるメンバー特定検索で選ばれて来たメンバー(基準メンバー)が表示されている。画面下半分には、対象メンバーに関係づける人の候補を一覧する。その間に上と下の関係を示す「親子切替」ボタンとリストボックスがある。「親子切替」ボタンには上下のどちらを親(主)にするかを設定し、リストボックスには関係区分が表示されるので、親からの関係を選ぶ。
【0106】
i).「関」ボタン
対象メンバーの1親等に関係づけされているメンバーを表示する。
現在の関係づけの参照/変更/削除の際に使用する。
リストの中から関係の変更又は削除する人を選ぶ。
【0107】
ii).関係更新/削除ボタン
変更の場合は、関係内容を変更して「関係更新」ボタンをクリックする。
関係を削除する場合は、「削除」ボタンをクリックする。
関係の削除は、データそのものを削除するわけではなく、つながりをなくしてしまうだけのことで、関係を削除してもデータは残る。しかし関係を削除された者どうしは別ルートでのつながりがない限り、同じ系図に現れることはない。関係は、前述の「関係区分」でも述べたが、犬猿の仲や縁切れという関係も人脈の一種ととらえて極力、削除しないようにする。
【0108】
次に、本実施形態の特徴である系図表示について説明する。本実施形態のシステムには、2種類の系図表示方式がある。1つは、図35に示す「メンバー紹介系図(親・子・孫)」である。参照対象者を中心に親と子と孫を表示する。この系図表示は「参照対象変更」ボタンをクリックして参照対象を表示されている親・子・孫にずらして行くことで、系図の中心の人を変えながら、そのメンバーにつながるすべての関係者をいもづる式に表示していく。
【0109】
登録されているメンバーすべてが、切れ目なしに関係付けされていれば、途切れることなく表示されるが、関係付けのグループが異なれば、参照対象を移動しても系図はつながることはない。この場合は別グループのメンバーを選択して系図表示に入れば、同様に関係者をいもづる式に表示していく。データベースの中では、小さな集団がいくつも形成されて少しづつ大きく成長していく。
【0110】
また、この系図の表示方式では、図36に示すように、限られたメンバーしか表示されてはいない。表示されているのは直系の親・子・孫のみである。親から別につながっているA、子から別につながっているBとその直系は、参照対象を変更することにより表示されるようになる。
【0111】
この「メンバー紹介系図(親・子・孫)」を検索処理するための手順の概要は、次の通りである。
(1)特定の条件を指定して抽出されたメンバーリストで選択されているメンバーのコードを参照対象コード(以下本人CIF)とする。
(2)本人CIFを元に参照対象の情報をメンバー管理テーブルより取得し、参照対象表示域に格納する。
(3)本人CIFを元に関係管理テーブルより参照対象者の親関係にあたる全てのメンバーのコード(以下親CIF)と区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから親メンバーリスト表示領域に格納する。
(4)本人CIFを元に関係管理テーブルより参照対象者の子関係にあたる全てのメンバーのコード(以下子CIF)と区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから子メンバーリスト表示領域に格納する。
(5)子メンバーリスト表示領域の最上にある子CIFを元に関係管理テーブルより子メンバーリスト表示領域の最上にある子メンバーの子関係にあたる全てのメンバーのコード(以下孫CIF)と区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから孫メンバーリスト表示領域に格納する。
(6)表示領域を表示する。
(7)子メンバーリスト表示領域の中で最上以外のメンバーをユーザが選択したかどうかを判断する。選択したらステップ(8)に進む。選択しなければステップ(9)に進む。
(8)選択された子CIFを元に関係管理テーブルより子メンバーリスト表示領域の選択された子メンバーの子関係にあたる全てのメンバーのコード(以下孫CIF)と区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから孫メンバーリスト表示領域に格納し、再度表示する。
(9)参照対象変更ボタンを押下したかどうかを判断する。押下したらステップ(10)に進む。押下しなければ処理を終了する。
(10)親メンバーリスト表示領域と子メンバーリスト表示領域と孫メンバーリスト表示領域の中でユーザが選択したメンバーのコードを本人CIFとする。ステップ(2)に戻る。
【0112】
この親子孫表示画面では、直系の上に1世代、下に2世代しか表示されない。この表示されない部分を補っているのが、もう1つの系図、「メンバー紹介系図(前後5親等)」である。その例を図23に示す。この「メンバー紹介系図(前後5親等)」は、図35の「メンバー紹介系図(親・子・孫)」で決定した参照対象を中心に前後5親等の範囲で、すべての関係者を系図化する。
【0113】
本実施形態のシステムのような人脈を表現する系図は、家系図のように親が上で子が下といった、一方向の流れで表すことは不可能である。それに代わるものとして、本実施形態のシステムでは、図37に示すように、系図の中心とする人を一番上の左端に表示する。1親等目を左に1段下げた位置に表示している。同様に5親等目までを1段ずつ左へ下げながら表示している。横向きの矢印は親から子への関係を表しており、「…」は他に最短ルートがある事を示している。
【0114】
例えば、(い)の「坂本竜馬」には「…」がついている。(い)の「坂本竜馬」は「勝海舟」から見て2親等目にあたるが、他のルートを見てみると、1親等目の(ろ)にも「坂本竜馬」が表示されている。(い)より(ろ)の方が参照対象の「勝海舟」により近いので、「…」のついている箇所は参考ということになる。+印はこの下にも人脈が続いていることを意味している。隠したい人脈や複雑な人脈の場合、この+機能を使って系図を自由に再構成することができる。
【0115】
このメンバー紹介系図を生成するための手順の概要は、次の通りである。
(1)参照対象CIFをもとにメンバー管理テーブルの参照対象メンバーの情報を取得し、ツリービュー領域に表示する。
(2)1親等洗い出し
(2−1)参照対象のコード(CIF)をもとに関係管理テーブルから親メンバーを抽出し、優先順にツリービュー領域2列目に1メンバー1段で参照対象の下に追加表示する。
(2−2)参照対象CIFをもとに関係管理テーブルから子メンバーを抽出し、優先順にツリービュー領域2列目に1メンバー1段で親メンバーの下に追加表示する。
【0116】
ただし、ツリービュー内にすでに同じCIFのメンバーが表示されていれば名前の後に「…」を付加する。
(3)2親等洗い出し
(3−1)2列目に表示されている1親等のメンバーについて上から順にそれぞれ次の処理を行う。
(3−2)1親等者CIFをもとに関係管理テーブルから親メンバーを抽出し、優先順にツリービュー領域3列目に1メンバー1段で該当の1親等のメンバーと次の1親等のメンバーの間に挿入表示する。
【0117】
ただし、直系の2親等前(参照対象)が同じメンバーなら「2親等洗い出し」はしない。
(3−3)元にする1親等の該当段目のメンバーに「…」がついていれば「2親等洗い出し」はしない。
(3−4)ツリービュー内にすでに同じCIFのメンバーが表示されていれば名前の後に「…」を付加する。
(3−5)1親等者CIFをもとに関係管理テーブルから子メンバーを抽出し、優先順にツリービュー領域3列目に1メンバー1段で該当の1親等のメンバーと次の1親等のメンバーの間に挿入表示する。
【0118】
ただし、直系の2親等前(参照対象)が同じメンバーなら「2親等洗い出し」はしない。
(3−6)元にする1親等の該当段目のメンバーに「…」がついていれば「2親等洗い出し」はしない。
(3−7)ツリービュー内にすでに同じCIFのメンバーが表示されていれば名前の後に「…」を付加する。
(4)n親等洗い出し。(n=3)とする
(4−1)3列目に表示されている2親等のメンバーについて上から順にそれぞれ次の処理を行う。
(4−2)2親等者CIFをもとに関係管理テーブルから親メンバーを抽出し、優先順にツリービュー領域4列目に1メンバー1段で該当の2親等のメンバーと次の2親等のメンバーの間に挿入表示する。
【0119】
ただし、直系の2親等前(1親等者)が同じメンバーなら「3親等洗い出し」はしない。
(4−3)元にする2親等の該当段目のメンバーに「…」がついていれば「3親等洗い出し」はしない。
(4−4)ツリービュー内にすでに同じCIFのメンバーが表示されていれば名前の後に「…」を付加する。
(4−5)2親等者CIFをもとに関係管理テーブルから子メンバーを抽出し、優先順にツリービュー領域4列目に1メンバー1段で該当の2親等のメンバーと次の2親等のメンバーの間に挿入表示する。
【0120】
ただし、直系の2親等前(1親等者)が同じメンバーなら「3親等洗い出し」はしない。
(4−6)元にする2親等の該当段目のメンバーに「…」がついていれば「3親等洗い出し」はしない。
(4−7)ツリービュー内にすでに同じCIFのメンバーが表示されていれば名前の後に「…」を付加する。
(5)以降、ステップ(4)の数を累進させて、4親等、5親等も同様の処理をする。
【0121】
次に、本実施形態のもう一つの特徴である関係検索機能について説明する。「関係検索」ボタンをクリックすると図24に示すメンバー関係検索の画面が表示される。ここでは2人(個人・団体とも可)を指定してメンバー間につながりがあるかを探す。上段には参照対象メンバーが入っているが「条件検索」ボタンで検索画面へ移動するので、上段・下段ともにメンバーを任意に変更することができる。1親等から10親等までの範囲で関係を追跡するが、最短ルートを見つけるのか、全てのルートを見つけるのかをラジオボタンで指定する。「全ての関係を表示する」にチェックして実行ボタンをクリックすると、図24の系図の左上にあるリストボックス内に親等数と、同親等内での連番が表示される。図38はその説明図であり、左右両側の2人のメンバー間の系図の例を示している。
【0122】
リストボックス内の参照したいルートを選択すると、そのルートの系図が表示される。「詳細」ボタンは他の画面と同様に、クリックをすると系図内で選択された人の登録内容が表示される。「印刷」ボタンは、表示されている追跡結果をプレビューし、プリンタで印刷可能な状態にする。
【0123】
この関係検索機能の処理手順は次の通りである。
(1)関係の追跡をする二人のメンバーのうち、一方を正、他方を副とし、正メンバーに副メンバーが繋がっているかを追跡するため、設定条件を保存し、検索結果を一時保存するメモリ内の配列エリアを初期化する。なお、ユーザによってキャンセルボタンが押されたときは処理を中止し、メモリ内に格納されている途中までの結果を破棄する。
(2)処理を行う際に、ユーザが指定した、最大何親等まで探すか、最短ルートか全てのルートかの設定条件を保存する。ここでは、4親等までの全てであるとして説明する。
(3)正メンバーの親子の関係である1親等目を抽出する。
(3−1)抽出された1親等目のnaのレコード数のうち、ia番目(i=1〜n)は副メンバーかを判断する。
(3−1−1)副メンバーであれば正メンバーからのルートを前記メモリ内の配列エリアに保存して次の1親等目のレコードに対し、(3−1)のステップの処理を実行する。
(4)副メンバーでなければ、1親等目のia番目のメンバーの親子の関係である2親等目を抽出する。
(4−1)抽出された2親等目のnbのレコード数のうち、ib番目(i=1〜n)は副メンバーかを判断する。
(4−1−1)副メンバーであれば正メンバーからのルートを前記メモリ内の配列エリアに保存して次の2親等目のレコードに対し、(4−1)のステップの処理を実行する。
(4−2)副メンバーでなければ、2親等目のib番目と同じメンバーがルート中の上位に存在しないかどうか判断する。
(4−2−1)存在していれば、その処理を中断し次の2親等目のレコードに対し、(4−1)のステップの処理を実行する。
(5)存在していなければ、2親等目のib番目のメンバーの親子の関係である3親等目を抽出する。
(5−1)抽出された3親等目のncのレコード数のうち、ic番目(i=1〜n)は副メンバーかを判断する。
(5−1−1)副メンバーであれば正メンバーからのルートを前記メモリ内の配列エリアに保存して次の3親等目のレコードに対し、(5−1)のステップの処理を実行する。
(5−2)副メンバーでなければ、3親等目のic番目と同じメンバーがルート中の上位に存在しないかどうか判断する。
(5−2−1)存在していれば、その処理を中断し次の3親等目のレコードに対し、(5−1)のステップの処理を実行する。
(6)存在していなければ、3親等目のic番目のメンバーの親子の関係である4親等目を抽出する。
(7)抽出された4親等目のndのレコード数のうち、id番目(i=1〜n)は副メンバーかを判断する。
(7−1−1)副メンバーであれば、正メンバーからのルートを前記メモリ内の配列エリアに保存し、4親等の次のレコードに進む。
(7−2)副メンバーでなければ、4親等の次のレコードに進む。4親等のレコードがn迄終われば、3親等のレコード数を1つ累進させて処理を行う。
(7−3)3親等のレコード数がn迄終われば、2親等のレコード数を1つ累進させて処理を行う。
(7−4)2親等のレコード数がn迄終われば、1親等のレコード数を1つ累進させて処理を行う。
(8)前記メモリ内の配列エリアに保存されている検索結果をルートの親等数の少ないものから並べ直す。
(9)検索結果の1番目をツリービューに表示する。
(10)ユーザが検索結果表示の変更をプルダウンリストボックスで指示したときは、検索結果の中のユーザの選択したルートをツリービューに表示する。
【0124】
以上の実施形態では、複雑に絡み合った関係情報に対し、部分的にスポットを当てながらそれをずらして見ていくという構成で関係系図をシンプルに表示できるように工夫されている。この構成によれば、中心データとそれから離れていくデータの繋がりを見ることは可能になる。しかし、この構成では、時間的な流れをおって結合や分離の変遷を追跡し、関係の変化を見ることはできない。関係管理テーブルでは、親子の関係付けはするが、この親子関係が必ずしも発生の順に親と子として設定されているとは限らない。親と子は、利用者の都合で設定するものとなっている。したがって、一度親と子の関係付けをすると、その逆方向の関係や複数の関係を同時に設定することはできない。それは、関係付けを辿るために2者の関係を一方向にしておかなければ、関係検索・追跡時に永久に循環する関係ができてしまうからである。
【0125】
次に、上記実施形態に対し、さらに関係ベクトルテーブルを付加して関係管理テーブルと併用して、「溯り(さかのぼり)ルート」により位置的、時間的な流れを追った関係検索・追跡を可能にした実施形態について説明する。これは、例えば次のような場合に必要になる。
【0126】
上記実施形態では、関係する人脈を入力する場合において、名前が変化すると、本人という関係で繋いでも、発生の順番を持っていないので、ルーツを溯ることはできない。それぞれのデータ内に発生順を持つことは可能であるが、系図にその順番通りの表示を反映させるのは困難である。そのためには、発生の時間と親子関係の方向ではない、場合に応じた方向が関係情報の中に必要になる。
【0127】
また、宇宙の発生を例にとると、ビッグバンである物質Aがある時間、ある位置で分離し、さらにある時間、位置で物質BとCとに分離し、物質Aは物質A′に変化する、というような現象を繰り返す。このような結合と分離を繰り返し、元の物質とは異なる物質として固有なものになる場合や、元の属性を残したまま変化する場合など、科学的な分野で関係情報を操作する場合には、関係ができた時間及び位置情報を持たなければ、同じ現象で分離・結合したものは同じものとみなしてしまう危険性がある。人脈など、任意の2人がどこで知り合ったかが重要視されない単なる関係に限ればこのままでもよい。しかし、物質の変化や微生物の分裂情報などは、時間と位置は欠かせない情報であり、このような関係情報を時間の流れや位置で溯ることにより、データの変遷を追跡することが可能になる。
【0128】
さらに、噂が広まった情報源を辿るため、情報伝達に関わった人たちに関する情報を記録する場合、噂は、A→B→C→……→A→B→G→……→B→A→…のように何度か同じ人に戻ったりすることがある。その場合、最初に聞いた内容と2度目に聞いた内容は違っている場合が多い。繋がりのみを見た場合には、最初のAとBの関係と2度目のAとBの関係は全く同じであり、3度目のBとAの関係は情報伝達方向が逆転しているだけである。しかし、情報が伝達された時間が異なっており、伝達位置によっても、それらが情報の変化に影響している可能性もある。これらの時間や位置も、それぞれ個人の情報に含まれるべきものではなく、関係情報に含まれて処理されるべきものである。
【0129】
上記のように、関係情報を操作する上で、「溯りルート」を特定することによるメリットは非常に大きい。そこで、この「溯りルート」を操作するため、データテーブルとして図39に示すように関係管理テーブルKKTに加えて関係ベクトルテーブルKVTを持つ。
【0130】
図39において、関係管理テーブルKKTは、これまでと同様であるが、関係区分などはこの中に持たず、関係ベクトルテーブルKVTに持たせてもよい。各データの詳細部分は図示しないメンバー管理テーブルに保存してあってもよい。既に説明したように関係管理テーブルKKTは、親子関係を持たせることで2者間の関係追跡の流れる方向を決定するもので、実際には処理上の検索・追跡などに永久循環を防ぐための方向付け手段としての役割がある。そのため、2者間の親子関係はダブって登録されることなく、固有の関係であり、親子が逆転して登録されることもない。
【0131】
関係ベクトルテーブルKVTは、関係管理テーブルKKTの親子とは別に2者の関係を、その方向と位置時系列、接続位置、接続順などとともに複数登録するものであり、関係ベクトルテーブルKVTに書き込むことを前提とした処理内で関係付けされた全ての関係に1レコードずつ記録され、関係の向きを親と子ではなく元と先で表す。この元と先は親子の設定には関係なく指定することができる。関係ベクトルテーブルKVTの各レコードは、個別に順指定された集合体が1つのグループとして登録されているという内容や、連結の順位付けがされているという内容の付加情報を持たせて、ユニークなレコードとして認識させる。関係ベクトルテーブルKVTは、明らかに複数の関係が発生する場合や関係に順位が生ずる場合には必要となる。しかし、関係さえ判ればよいという場合には、記憶領域を圧迫するため、利用者の必要に応じて、関係ベクトルテーブルKVTに情報を書き込むかどうかを選ぶことができるようにしておくのが望ましい。
【0132】
関係ベクトルテーブルKVTでは、関係を、1:1、1:多、多:1、多:多で接続する際、図40に示すように任意の付加情報を持たせ、ここで「同じ」、「置換」、「変体」、「連続」、「結合」、「分離」などのような分別区分を持って利用者が自由に接続位置と接続順を設定できるようにする。「同じ」は、2つのデータを同じものとみなすが、一体化はせずグループの形状を残したまま接続する、つまり関係区分「本人」と同じ考え方である。「置換」は、2つのデータを同じものとみなし、どちらかを優先的なデータとして表示し、非優先データは隠しデータ、又は名寄せデータとして1つに統合する。「変体」は、元データから先データへと変化したものとして新旧の区別を明確にして接続する。「連続」は、元データから先データへと連続したものとして新旧の区別を明確にして接続する。「結合」は、多:1の接続をし、「分離」は、1:多の接続をする。また、利用者の意思ではっきりとした時系列の関係付けが必要な場合には、図41に示すように既にグループ化された関係同士をどのグループのどのメンバーで連結させるかを指定する。
【0133】
この関係ベクトルテーブルKVTを用いることにより、参照対象中心表示(以下、関係系図ともいう)と位置時系列表示(以下、関係地図または関係年表ともいう)を併用することができる。例えば図40に示すように1:1で繋いでいくうちに利用者も気がつかない関係網で出来上がっている参照対象中心表示とは別に、位置時系列表示は、図41に示すように利用者の意思に沿った関係付けがそのまま表示される。これらを併用することで、データの関係地図や関係年表を作ることができ、その中で指定した任意のデータの参照対象中心表示を用いることができる。
【0134】
関係管理テーブルKKTでは、上記で述べた並列や直列、グループとしての関係も、全て1:1の固有の繋がりとして分解して登録され、同じ関係や逆転関係は記録されない。すなわち、関係管理テーブルKKTのみで関係を表す場合には、関係表現と関係追跡の流れを表示する親子関係を共用していたので、2者の関係パターンが複数あった場合や、A→Bであり、B→Aでもあるような関係が存在する場合には、そのひとつのみを登録するしかなかった。
【0135】
例えばAはBの上司、AとBは同じサークルに属している。また、BはAの先輩であり、師匠であるとする。この場合、もし、最初の関係がB→A(先輩)であり、その後A=B(サークル仲間)となり、しばらくしてA→B(上司)という関係が出来、最後にB→A(師匠)という関係が出来上がったとすると、関係管理テーブルKKTの親子関係のみでは表現できない。したがって、それぞれの関係とその方向と時系列情報などを関係ベクトルテーブルKVTに記録するのである。この場合の関係ベクトルテーブルKVTの概念は、この中に登録された関係情報が固有であり、任意の2者間には、まったく同じ属性の関係は存在しないという前提で作成される。ゆえに、利用者が関係の順番を意図的に指定したい場合や、同じ関係内に複数の関係の意味を持たせたい場合、逆転の関係を残したい場合には、関係ベクトルテーブルKVTに時間情報や位置情報などそれぞれのレコードが別の関係であると識別できる情報を持たせる。
【0136】
これにより、繋がりを連鎖で表したとき、同じ関係が複数の時点で表れても別物として「溯りルート」を表示することができる。しかし、この表示では、参照対象の表示位置が固有ではないため一度に全ての関係者を見ることはできない。例えば図42は図43の関係地図を関係系図に置き換えたものであり、分解し突き詰めれば同じ関係の図である。図42はそれぞれの個体から見た関係が一目でわかるし、図43は関係の変遷が理解しやすい表示になっている。しかし、図43の下方のGを参照中には、Eとの繋がりは分からないことになる。
【0137】
そこで、Gを参照中にGを参照対象にした関係系図が表示でき、ここで繋がりがあると表示された別メンバーが関係地図上のどこに表示されているかを参照することができ、さらにその位置に移動して他の繋がりまで見ることができれば、時間や位置の違いまでも同時に把握することができようになる。
【0138】
例えば関係地図(関係年表)上の複数の場所に対象とするデータが分散して、移動先が複数あったときは、リストボックスなどでそれらの位置や属性を示し、利用者に表示対象を選択させ、関係地図上の該当データ部分を高輝度表示するなどで位置を把握しやすいようにしてもよい。また、選択された位置に移動する時には、ジャンプボタンなどで関係地図上の指定位置に自動的にスクロール表示されるようにしておくのが望ましい。このように、関係地図上の任意の場所で関係系図を適宜参照し、移動することが出来れば、極めて関係の把握がしやすいシステムを構築することが可能である。
【0139】
任意の付加情報において、例えば時間は、年月日時分秒に限らず、情報の変化の過程などを表す属性でも構わない。位置と時間という表現を用いることにより、位置が3次元空間で、時間はその変化の過程などを表す4次元としての働きを持たせることができる。時間が同じであっても、AとBの関係は、Cから見れば普通の関係であるが、Dから見れば仲が悪いととられ、Eから見ればおしどり夫婦に見られている、という場合に登録者の主観が関係付けに大きく影響する。このように1つのシステムに不特定多数の利用者がいる場合、別の入力者であるという情報も1つの位置情報と見ることもできる。
【0140】
この他にも、速度、力など、同じ2者間に存在する複数の関係をそれぞれ固有であると認識するための付加情報は、その任意の付加情報をもつエリアを関係ベクトルテーブルKVT内に持っていさえすれば、システムの開発者と利用者に関わらず設定することができる。
【0141】
また、「集合体:単体」、「単体:集合体」、「集合体:集合体」などのように、作成された集合体をグループメンバーとして名前を付けて登録し、関係地図を作成することにより、集合体ごとの繋がりとそれを構成する単体メンバーとの繋がりを同時に知ることができる。さらに、特定の連鎖関係を含んだ集合体を検索することが可能になる。例えば学術的分野では、任意の分子構造を持つ多分子結合体などの研究分野、言語などのような発生と遷移を追跡すべき研究分野、天体の星座・星雲と恒星・惑星などの研究分野に広く応用することができる。
【0142】
なお、本発明は、上記実施の形態に限定されるものではなく、種々の変形が可能である。例えば上記実施の形態では、メンバーデータの詳細情報として、摘要の情報と履歴の情報を説明したが、その他、写真や添付ファイルなど様々な情報を付加してもよいし、同じメンバーに関して、識別コードで区分け情報と固有の詳細情報で登録してもよい。
【0143】
【発明の効果】
以上述べたように、本発明によれば下記の効果を奏する。
1.人脈の系図を2次元の紙に書き表すことができる
2.同じ人が系図の中に何度現れても(循環しても)、確実に関係ルートを探し出せる。
3.繋がりを親子で表し、その関係を区別でき、さらに繋がりの深さを区別できる。
4.系図を世代ではなく、親等で表すことにより、親方向と子方向への繋がり方向を固定化せず、自由に追跡し、ツリー表示することができる。
5.関係が続く限り、系図を連続で作成することができる。
6.任意の二人の繋がりを、あらゆるルートで追跡することができる。
【0144】
また、本発明によれば、各種情報を関係付けて管理する関係付け情報管理システムであって、少なくとも各種情報間の関係、該関係の方向及び位置時系列情報を格納する関係ベクトルテーブルと、関係ベクトルテーブルに格納された関係、該関係の方向及び位置時系列情報を基に関係付けの検索処理を行い関係図の出力処理を行う検索処理手段とを備え、さらに各種情報間で親と子の関係付けを格納する関係管理テーブルを備え、検索処理手段は、関係図として、各種情報間の位置時系列に沿った関係の変遷を表示する関係地図と各種情報間の繋がりを連鎖で表示する関係系図の出力処理を行うように構成することにより、関係地図と関係系図の表示を併用することができ、データの関係地図や関係年表を作ることができ、その中で指定した任意のデータの参照対象中心表示を用いることができる。したがって、「溯り(さかのぼり)ルート」により位置的、時間的な流れを追った関係検索・追跡を可能になる。
【0145】
さらに、各種情報を関係付けて管理する関係付け情報管理システムであって、少なくとも各種情報の識別情報で親と子の関係付けを格納する関係管理テーブルと、指定された情報と範囲で関係管理テーブルの関係付けにより親から子、子から親へ各種情報の検索処理を行う検索処理手段とを備えるので、データ間の関係を親(主、上)と子(従、下)で表し、世代ではなく、親等で管理することにより関係の追跡と表示を簡易にすることができる。しかも、登録されたデータ同士を関係付けすることにより、関係が続く限り引き当てることができ、2者の関係ルートを追跡したり、それらの関係を系図に表現することができる。重複データも名寄せ処理することなく、同一データという関係で結べば双方参照でき、旧姓、新姓データも関係付けにより両立させることができる。
【0146】
また、人と人だけでなく、人と物、物と物との関係付けを行い、物品のデータと人のデータを混在させて管理できるようにすることにより、例えば官庁等と取引のある会社で、また後に流用する可能性のある重要な書類を作成した場合、その文書を作成した人間や、その文書管轄の課等に関係付けを行っておくことができ、次に使用する際に記憶を辿らずに済む。
【0147】
文書を作成する際に参考にした本や地図資料等がどこの課のどの支所のものだったかなども、その課や支所などに関係付けをしておくことにより、その「課」、「本」、「資料」、「文書」のどれか1つだけでも手掛かりがあれば、詳しく覚えていない場合でも、関係をいもづる式に辿って必要な情報に辿りつくことができる。勿論、文書だけでなく、顧客と買い上げた車などの商品と結び付けておくこともでき、土地をデータとして入力しておき、所有者の変遷を辿ることもできる。曖昧なデータや不確実なデータも、ニュースソースに関係付けしておくことで行方不明データにはならない。
【図面の簡単な説明】
【図1】 本発明に係る関係付け情報管理システムの実施の形態を示す図である。
【図2】 メンバー管理テーブルの構成例を示す図である。
【図3】 関係管理テーブルの構成例を示す図である。
【図4】 マスタテーブルの構成例を示す図である。
【図5】 本発明に係る関係付け情報管理システムの関係付け検索処理の流れの例を説明するための図である。
【図6】 検索条件及び出力条件の例を説明するための図である。
【図7】 シンクロ方式を利用する場合について説明するための図である。
【図8】 親選択集団と子選択集団を使った並列の関係付けの例を説明するための図である。
【図9】 カテゴリーの一致による並列の関係付けの例を説明するための図である。
【図10】 LL方式のデータベース間インポートの例を説明するための図である。
【図11】 関係を繋ぐ媒体について説明するための図である。
【図12】 エクスプローラ等のファイル管理ソフトにおける関係付けについて説明するための図である。
【図13】 多種類データのファイル内の部分的な関係付けについて説明するための図である。
【図14】 その他のファイル等の関係付けについて説明するための図である。
【図15】 複数の管理テーブルを設けて関係付けする場合について説明するための図である。
【図16】 一般のカード形式の顧客管理の方法を示す説明図である。
【図17】 本発明における関係管理テーブルの例を示す説明図である。
【図18】 子関係の説明図である。
【図19】 親関係の説明図である。
【図20】 親子関係の説明図である。
【図21】 利用者と関係を探りたい人物とのルートの説明図である。
【図22】 本発明における親子関係によるつながりの説明図である。
【図23】 本発明のメンバー紹介系図の画面の例を示す図である。
【図24】 本発明のメンバー関係検索の画面の例を示す図である。
【図25】 本発明による系図の探り方を説明する図である。
【図26】 本発明のシステムのソフトウエア構成を示すブロック図である。
【図27】 本発明の実施システムのメインメニュー画面の図である。
【図28】 本発明実施例のメンバー情報入力画面の図である。
【図29】 本発明実施例のBOX項目入力画面の図である。
【図30】 本発明実施例のBOX項目入力画面の図である。
【図31】 本発明実施例の分類コード入力画面の図である。
【図32】 本発明実施例の関係区分登録画面の図である。
【図33】 本発明実施例の関係区分登録画面の図である。
【図34】 本発明実施例の関係入力画面の図である。
【図35】 本発明実施例のメンバー紹介系図(親、子、孫)の画面の図である。
【図36】 本発明実施例において表示されている系図の範囲の説明図である。
【図37】 図23の表示画面の詳細図である。
【図38】 関係検索において探索されるルートの説明図である。
【図39】 関係管理テーブルと関係ベクトルテーブルの併用例を示す図である。
【図40】 関係を繋ぐ方法の例を説明するための図である。
【図41】 グループ化された関係同士の連結例を示す図である。
【図42】 参照対象中心表示で作成した関係系図の例を示す図である。
【図43】 位置時系列表示で作成した関係地図の例を示す図である。
【図44】 関係図の例を示す図である。
【図45】 関係付けされた各種情報の例を示す図である。
【図46】 一般の家系図の表示例を示す説明図である。
【図47】 人脈のつながりの例を示す説明図である。
1…入力処理部、2…出力処理部、3…データ登録・更新処理部、4…検索処理部、5…編集処理部、6…関係管理テーブル、7…メンバー管理テーブル、8…マスタテーブル
Claims (3)
- 氏名または団体名、住所、電話番号等の個人・団体のメンバー情報を格納するメンバー管理テーブルと、
そのメンバー管理テーブルに登録されたあるメンバーとそのメンバーに関係する他のメンバーの二者の関係を親子関係で規定された関係レコードを記録するとともにその関係の種類および関係の優先順位を表す区分コードを記録する関係管理テーブルとからなるデータベースを備えた関係付け情報管理システムにおいて、 参照対象としてメンバーが指定されたときに、そのメンバーと親子関係があるメンバーを抽出して、参照対象とともに親メンバー、子メンバー、孫メンバーをリストとして表示する、次のステップを実行する手段を有する関係付け情報管理システム。
(1)特定の条件を指定して抽出されたメンバーリストで選択されているメンバーのコードを参照対象コード(以下本人CIF)とする。
(2)本人CIFを元に参照対象の情報をメンバー管理テーブルより取得し、参照対象表示域に格納する。
(3)本人CIFを元に関係管理テーブルより参照対象者の親関係にあたる全てのメンバーのコード(以下親CIF)と区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから親メンバーリスト表示領域に格納する。
(4)本人CIFを元に関係管理テーブルより参照対象者の子関係にあたる全てのメンバーのコード(以下子CIF)と区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから子メンバーリスト表示領域に格納する。
(5)子メンバーリスト表示領域の最上にある子CIFを元に関係管理テーブルより子メンバーリスト表示領域の最上にある子メンバーの子関係にあたる全てのメンバーのコード(以下孫CIF)と区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから孫メンバーリスト表示領域に格納する。
(6)表示領域を表示する。
(7)子メンバーリスト表示領域の中で最上以外のメンバーをユーザが選択したかどうかを判断する。選択したらステップ(8)に進む。選択しなければステップ(9)に進む。
(8)選択された子CIFを元に関係管理テーブルより子メンバーリスト表示領域の選択された子メンバーの子関係にあたる全てのメンバーのコードと区分を抽出し、それぞれの情報をメンバー管理テーブル、区分の優先順位を区分テーブルより取得し、優先順位の高い関係のメンバーから孫メンバーリスト表示領域に格納し、再度表示する。
(9)参照対象変更ボタンを押下したかどうかを判断する。押下したらステップ(10)に進む。押下しなければ次の指示を待つ。
(10)親メンバーリスト表示領域と子メンバーリスト表示領域と孫メンバーリスト表示領域の中でユーザが選択したメンバーのコードを本人CIFとする。ステップ(2)に戻る。 - 氏名または団体名、住所、電話番号等の個人・団体のメンバー情報を格納するメンバー管理テーブルと、
そのメンバー管理テーブルに登録されたあるメンバーとそのメンバーに関係する他のメンバーの二者の関係を親子関係で規定された関係レコードを記録するとともにその関係の種類および関係の優先順位を表す区分コードを記録する関係管理テーブルとからなるデータベースを備えた関係付け情報管理システムにおいて、 参照対象に設定されたメンバーコードにより、親子関係があるメンバーを抽出して、親等の近い順に複数親等をツリービューに表示する、次のステップを実行する手段を有する関係付け情報管理システム。
(1)参照対象CIFをもとにメンバー管理テーブルの参照対象メンバーの情報を取得し、ツリービュー領域に表示する。
(2)1親等洗い出し
(2−1)参照対象CIFをもとに関係管理テーブルから親メンバーを抽出し、優先順にツリービュー領域2列目に1メンバー1段で参照対象の下に追加表示する。
(2−2)参照対象CIFをもとに関係管理テーブルから子メンバーを抽出し、優先順にツリービュー領域2列目に1メンバー1段で親メンバーの下に追加表示する。
ただし、ツリービュー内にすでに同じCIFのメンバーが表示されていれば名前の後に省略記号を付加する。
(3)2親等洗い出し
(3−1)2列目に表示されている1親等のメンバーについて上から順にそれぞれ次の処理を行う。
(3−2)1親等者CIFをもとに関係管理テーブルから親メンバーを抽出し、優先順にツリービュー領域3列目に1メンバー1段で該当の1親等のメンバーと次の1親等のメンバーの間に挿入表示する。
ただし、直系の2親等前(参照対象)が同じメンバーなら「2親等洗い出し」はしない。
(3−3)元にする1親等の該当段目のメンバーに省略記号がついていれば「2親等洗い出し」はしない。
(3−4)ツリービュー内にすでに同じCIFのメンバーが表示されていれば名前の後に省略記号を付加する。
(3−5)1親等者CIFをもとに関係管理テーブルから子メンバーを抽出し、優先順にツリービュー領域3列目に1メンバー1段で該当の1親等のメンバーと次の1親等のメンバーの間に挿入表示する。
ただし、直系の2親等前(参照対象)が同じメンバーなら「2親等洗い出し」はしない。
(3−6)元にする1親等の該当段目のメンバーに省略記号がついていれば「2親等洗い出し」はしない。
(3−7)ツリービュー内にすでに同じCIFのメンバーが表示されていれば名前の後に省略記号を付加する。
(4)n親等洗い出し。(n=3)とする
(4−1)n列目に表示されているn−1親等のメンバーについて上から順にそれぞれ次の処理を行う。
(4−2)n−1親等者CIFをもとに関係管理テーブルから親メンバーを抽出し、優先順にツリービュー領域n+1列目に1メンバー1段で該当のn−1親等のメンバーと次のn−1親等のメンバーの間に挿入表示する。
ただし、直系の2親等前(n−2親等者)が同じメンバーなら「n親等洗い出し」はしない。
(4−3)元にするn−1親等の該当段目のメンバーに省略記号がついていれば「n親等洗い出し」はしない。
(4−4)ツリービュー内にすでに同じCIFのメンバーが表示されていれば名前の後に省略記号を付加する。
(4−5)n−1親等者CIFをもとに関係管理テーブルから子メンバーを抽出し、優先順にツリービュー領域n+1列目に1メンバー1段で該当のn−1親等のメンバーと次のn−1親等のメンバーの間に挿入表示する。
ただし、直系の2親等前(n−2親等者)が同じメンバーなら「n親等洗い出し」はしない。
(4−6)元にするn−1親等の該当段目のメンバーに省略記号がついていれば「n親等洗い出し」はしない。
(4−7)ツリービュー内にすでに同じCIFのメンバーが表示されていれば名前の後に省略記号を付加する。
(5)以降、ステップ(4)のnを1累進させて、nが所定の数に達するまで(4)のステップを繰り返し、nが所定の数に達すれば処理終了する。 - 氏名または団体名、住所、電話番号等の個人・団体のメンバー情報を格納するメンバー管理テーブルと、
そのメンバー管理テーブルに登録されたあるメンバーとそのメンバーに関係する他のメンバーの二者の関係を親子関係で規定された関係レコードを記録するとともにその関係の種類および関係の優先順位を表す区分コードを記録する関係管理テーブルとからなるデータベースを備えた関係付け情報管理システムにおいて、 参照対象に設定された二人のメンバーコードにより、その二人に関係ルートが出来上がっているかどうかを、任意の親等まで抽出して表示する、次のステップを実行する手段を有する関係付け情報管理システム。
(1)関係の追跡をする二人のメンバーのうち、一方を正、他方を副とし、正メンバーに副メンバーが繋がっているかを追跡するため、設定条件を保存し、検索結果を一時保存するメモリ内の配列エリアを初期化する。
(2)処理を行う際に、ユーザが指定した、最大何親等まで探すか、最短ルートか全てのルートかの設定条件を保存する。
(3)正メンバーの親子の関係である1親等目を抽出する。
(3−1)抽出された1親等目のnaのレコード数のうち、ia番目(i=1〜n)は副メンバーかを判断する。
(3−1−1)副メンバーであれば正メンバーからのルートを前記メモリ内の配列エリアに保存して次の1親等目のレコードに対し、(3−1)のステップの処理を実行する。
(4)副メンバーでなければ、1親等目のia番目のメンバーの親子の関係である2親等目を抽出する。
(4−1)抽出された2親等目のnbのレコード数のうち、ib番目(i=1〜n)は副メンバーかを判断する。
(4−1−1)副メンバーであれば正メンバーからのルートを前記メモリ内の配列エリアに保存して次の2親等目のレコードに対し、(4−1)のステップの処理を実行する。
(4−2)副メンバーでなければ、2親等目のib番目と同じメンバーがルート中の上位に存在しないかどうか判断する。
(4−2−1)存在していれば、その処理を中断し次の2親等目のレコードに対し、(4−1)のステップの処理を実行する。
(5)存在していなければ、2親等目のib番目のメンバーの親子の関係である3親等目を抽出する。
(5−1)抽出された3親等目のncのレコード数のうち、ic番目(i=1〜n)は副メンバーかを判断する。
(5−1−1)副メンバーであれば正メンバーからのルートを前記メモリ内の配列エリアに保存して次の3親等目のレコードに対し、(5−1)のステップの処理を実行する。
(5−2)副メンバーでなければ、3親等目のic番目と同じメンバーがルート中の上位に存在しないかどうか判断する。
(5−2−1)存在していれば、その処理を中断し次の3親等目のレコードに対し、(5−1)のステップの処理を実行する。
(6)存在していなければ、3親等目のic番目のメンバーの親子の関係である4親等目を抽出する。
(7)これをあらかじめ設定された数の親等まで数値を累進しながら繰り返し、最終親等で、次の処理を行う。
(7−1)抽出された最終親等目のnxのレコード数のうち、ix番目(i=1〜n)は副メンバーかを判断する。
(7−1−1)副メンバーであれば、正メンバーからのルートを前記メモリ内の配列エリアに保存し、最終親等の次のレコードに進む。
(7−2)副メンバーでなければ、最終親等の次のレコードに進む。最終親等のレコードがn迄終われば、それより1つ前の親等のレコード数を1つ累進させて処理を行う。
(7−3)1つ前の親等のレコード数がn迄終われば、さらに1つ前の親等のレコード数を1つ累進させて処理を行う。
(8)これを全ての親等のレコード数が終了するまで行う。
(9)前記メモリ内の配列エリアに保存されている検索結果をルートの親等数の少ないものから並べ直す。
(10)検索結果の1番目をツリービューに表示する。
(11)ユーザが検索結果表示の変更をプルダウンリストボックスで指示したときは、検索結果の中のユーザの選択したルートをツリービューに表示する。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002004203A JP3730174B2 (ja) | 2001-01-12 | 2002-01-11 | 関係付け情報管理システム、関係付け情報管理用プログラム、及び記録媒体 |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001005803 | 2001-01-12 | ||
JP2001-5803 | 2001-01-12 | ||
JP2002004203A JP3730174B2 (ja) | 2001-01-12 | 2002-01-11 | 関係付け情報管理システム、関係付け情報管理用プログラム、及び記録媒体 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2005112952A Division JP4215738B2 (ja) | 2001-01-12 | 2005-04-11 | 関係付け情報管理システム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2002312404A JP2002312404A (ja) | 2002-10-25 |
JP3730174B2 true JP3730174B2 (ja) | 2005-12-21 |
Family
ID=26607647
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002004203A Expired - Fee Related JP3730174B2 (ja) | 2001-01-12 | 2002-01-11 | 関係付け情報管理システム、関係付け情報管理用プログラム、及び記録媒体 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3730174B2 (ja) |
Families Citing this family (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7418663B2 (en) | 2002-12-19 | 2008-08-26 | Microsoft Corporation | Contact picker interface |
US7240298B2 (en) | 2002-12-19 | 2007-07-03 | Microsoft Corporation | Contact page |
US7636719B2 (en) | 2002-12-19 | 2009-12-22 | Microsoft Corporation | Contact schema |
US20040255301A1 (en) * | 2003-06-13 | 2004-12-16 | Andrzej Turski | Context association schema for computer system architecture |
US7953759B2 (en) | 2004-02-17 | 2011-05-31 | Microsoft Corporation | Simplifying application access to schematized contact data |
US7644089B2 (en) * | 2004-12-29 | 2010-01-05 | Barclays Capital, Inc. | System and method for corporate-wide policy management |
JP4481856B2 (ja) * | 2005-03-28 | 2010-06-16 | 日立建機ビジネスフロンティア株式会社 | データベース作成システム |
US8332386B2 (en) | 2006-03-29 | 2012-12-11 | Oracle International Corporation | Contextual search of a collaborative environment |
JP5025800B2 (ja) * | 2008-10-17 | 2012-09-12 | 株式会社日立製作所 | グループ可視化システム及びセンサネットワークシステム |
EP2575053A1 (en) * | 2011-09-27 | 2013-04-03 | Alcatel Lucent | User-enhanced ranking of information objects |
JP6321904B2 (ja) | 2012-12-27 | 2018-05-09 | 富士通株式会社 | 検索プログラム、検索方法及び情報処理装置 |
JP6114028B2 (ja) * | 2012-12-28 | 2017-04-12 | 富士通株式会社 | 情報管理プログラム、情報管理方法及び情報管理装置 |
JP6216600B2 (ja) * | 2013-10-08 | 2017-10-18 | 株式会社日立製作所 | 紹介者候補抽出システム |
JP6260195B2 (ja) * | 2013-10-22 | 2018-01-17 | 富士通株式会社 | 情報処理装置、情報処理端末、ソーシャルネットワークシステム、プログラム及び処理方法 |
JP6462611B2 (ja) * | 2016-03-10 | 2019-01-30 | ヤフー株式会社 | 生成装置、生成方法、及び生成プログラム |
JP7013791B2 (ja) * | 2017-10-25 | 2022-02-01 | 富士通株式会社 | コンタクト支援プログラム、コンタクト支援方法、および、コンタクト支援装置 |
CN113628032B (zh) * | 2021-08-12 | 2024-02-09 | 上海上湖信息技术有限公司 | 一种确定用户关系的方法及装置 |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS61267129A (ja) * | 1985-05-22 | 1986-11-26 | Hitachi Ltd | 階層木構造型デ−タの蓄積・検索方式 |
JP3765175B2 (ja) * | 1998-01-09 | 2006-04-12 | 富士ゼロックス株式会社 | コミュニケーションシステム |
JP3025479B2 (ja) * | 1998-08-12 | 2000-03-27 | 翼システム株式会社 | 関係情報提供装置、関係情報提供方法及び記録媒体 |
JP2000066970A (ja) * | 1998-08-19 | 2000-03-03 | Nec Corp | 人脈情報管理システム、人脈情報管理方法および記録媒体 |
JP2000163306A (ja) * | 1998-11-30 | 2000-06-16 | Ntt Data Corp | 情報管理システム、情報管理方法および記録媒体 |
JPH11282882A (ja) * | 1998-12-22 | 1999-10-15 | Hitachi Ltd | 文書管理方法 |
JP2001014328A (ja) * | 1999-06-30 | 2001-01-19 | Hitachi Ltd | データベースシステムとそこで用いるディレクトリデータ構造 |
JP2001076056A (ja) * | 1999-07-06 | 2001-03-23 | Semiconductor Energy Lab Co Ltd | 出願管理システム及び出願情報の処理方法 |
JP2001216330A (ja) * | 2000-02-04 | 2001-08-10 | Hitachi Ltd | 文書データベース |
JP2001282805A (ja) * | 2000-03-28 | 2001-10-12 | Fuji Xerox Co Ltd | ユーザ情報提示装置 |
-
2002
- 2002-01-11 JP JP2002004203A patent/JP3730174B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2002312404A (ja) | 2002-10-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20020107859A1 (en) | Associating information management system, program for associating information management, and recording medium | |
JP3730174B2 (ja) | 関係付け情報管理システム、関係付け情報管理用プログラム、及び記録媒体 | |
US9002900B2 (en) | Machine-implemented activity management system using asynchronously shared activity data objects and journal data items | |
Mahanti | Data quality: dimensions, measurement, strategy, management, and governance | |
CN101084494B (zh) | 用于管理计算机环境中的工作流的方法和设备 | |
US20180309807A1 (en) | Apparatus and Method for Acquiring, Managing, Sharing, Monitoring, Analyzing and Publishing Web-Based Time Series Data | |
US7698316B2 (en) | Universal knowledge information and data storage system | |
Inmon et al. | Tapping into unstructured data: Integrating unstructured data and textual analytics into business intelligence | |
Bak | Continuous classification: capturing dynamic relationships among information resources | |
EP1693793A1 (en) | Intellectual property management system | |
US20050289524A1 (en) | Systems and methods for software based on business concepts | |
JP4215738B2 (ja) | 関係付け情報管理システム | |
US20230289730A1 (en) | Platform for investigative analysis | |
US20050166139A1 (en) | System and method for managing legal documents | |
US20060122859A1 (en) | Communities of practice environment | |
JP3730156B2 (ja) | 関係付け情報管理システム、関係付け情報管理用プログラム、及び記録媒体 | |
JP7142382B1 (ja) | 特許情報の表示プログラム | |
JP7437046B2 (ja) | 年史制作方法、プログラム、年史制作装置および年史制作システム | |
US20030078938A1 (en) | Database and method of storing and retrieving data | |
Pierce | Extending IP-MAPS: Incorporating the Event-Driven Process Chain Methodology. | |
McGettigan | Technical ServiceS law librarian | |
US10607239B2 (en) | Enterprise evaluation using structured data | |
Vesterli et al. | Building Business Objects | |
MCLAUGHLIN et al. | a case study Building a business taxonomy | |
Smith et al. | Working with Lists |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050209 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050411 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050907 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20051005 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091014 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101014 Year of fee payment: 5 |
|
LAPS | Cancellation because of no payment of annual fees |