(57)【要約】  インデクシング記憶部６０は、ツリー状に配置された複数のデータベース６２〜６８を含む。データベース６２〜６８のうち、最上層の１つのデータベース（データベース６２または６３）から最下層の１つのデータベース（データベース６４〜６８のいずれか）までの経路上のデータベースに格納されたデータは、１つの属性を有する情報を表す。検索手段２０は、データベース６２〜６８の最上層から最下層までの情報を検索データに合致する結果データのポインタとしてインデクシング記憶部６０から受け、その受けた結果データのポインタに対応する実データをデータ永続化ストレージ４０から受け、その受けた実データに基づいて出力データを外部へ出力する。
2012117953.tif 000002
【特許請求の範囲】
【請求項１】
複数の実データを複数のポインタに対応付けて記憶するデータ記憶部と、
同じ意味を有するデータからなる集合を１つのグループとし、前記複数の実データを複数のグループに分類する分類処理を行う分類手段と、
前記分類手段によって複数のグループに分類された各実データのポインタをツリー構造で記憶する分類結果記憶部と、
外部からの検索要求に応じて、検索データに合致する結果データのポインタを前記分類結果記憶部から受けるとともに、その受けた結果データのポインタに対応する実データを前記データ記憶部から受け、その受けた実データに基づいて出力データを外部へ出力する検索手段とを備え、
前記分類結果記憶部は、前記検索手段からの要求に応じて前記ツリー構造を最上層から最下層へ向けて検索し、前記最上層から前記最下層までの情報から前記検索データに合致する結果データのポインタを抽出する抽出処理を行い、前記抽出した結果データのポインタを前記検索手段へ出力し、
前記データ記憶部は、前記結果データのポインタを前記検索手段から受けると、その受けたポインタに対応する実データを前記検索手段へ出力する、大規模データ最適配置システム。
【請求項２】
前記分類結果記憶部において、前記ツリー構造の最上層のルートノードが自己よりも下位層に問い合わせ、前記結果データのポインタを下位層から取得して出力する、請求項１に記載の大規模データ最適配置システム。
【請求項３】
新たな実データの登録要求に応じて新たな実データを前記データ記憶部に登録する登録手段を更に備え、
前記登録手段は、前記新たな実データが前記データ記憶部に存在するとき、前記新たな実データの永続化処理を行い、その永続化処理を行なった実データによって既に存在するデータを更新することによって前記新たな実データをポインタに対応付けて前記データ記憶部に登録し、前記新たな実データが前記データ記憶部に存在しないとき、前記新たな実データの永続化処理を行い、その永続化処理を行なった実データをポインタに対応付けて前記データ記憶部に登録し、
前記分類手段は、前記新たな実データが前記データ記憶部に登録されると、前記分類処理を行い、前記分類処理の結果に基づいて前記複数のデータベースを更新する、請求項１または２に記載の大規模データ最適配置システム。
【請求項４】
前記分類手段は、前記分類処理の対象となる実データが有する意味からなる属性が前記複数のデータベースのいずれかの属性と同じであるとき、前記分類処理の対象となる実データを前記同じ属性を有するデータベースに分類する、請求項３に記載の大規模データ最適配置システム。
【請求項５】
複数の実データを複数のポインタに対応付けて記憶するデータ記憶部と、同じ意味を有するデータからなる集合を１つのグループとし、前記複数の実データを複数のグループに分類し、前記複数のグループに分類された各実データのポインタをツリー構造で記憶する分類結果記憶部とを用いてデータの検索をコンピュータに実行させるためのコンピュータ読み取り可能な検索プログラムであって、
検索手段が、外部からの検索要求に応じて、検索データに合致する結果データのポインタの出力を前記分類結果記憶部に要求する第１のステップと、
前記検索手段が、前記検索データに合致する結果データのポインタを前記分類結果記憶部から受ける第２のステップと、
前記検索手段が、その受けた結果データのポインタに対応する実データを前記データ記憶部から受け、その受けた実データに基づいて出力データを外部へ出力する第３のステップとをコンピュータに実行させるためのコンピュータ読み取り可能な検索プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、大規模データ最適配置システムおよびそれを用いた高速な検索プログラムに関するものである。
【背景技術】
【０００２】
データ管理は、データの内容を分析し、属性として分解したものを一つの集合としてレコードと言われる単位で管理する手法が多く用いられる。また、レコード間でのデータの関係性を同時に管理することが多く、この方法で管理するソフトウェアをリレーショナルデータベースと言う。【０００３】
データ間の関係性を管理するためには、データ間の整合性を常に管理しなければならないため、多大な管理コストが発生する。このコストは、データの検索時には検索速度に影響を及ぼす。そのため、管理するデータを更に分析し、単純な索引と、それが表すデータという形式で管理する手法が用いられ始めた。これは、関係性の維持に重きを置かずにデータの関係性は、いずれ一致すればよいという楽観的制御により整合性の管理コストを下げる手段である（特許文献１および非特許文献１）。
【特許文献１】米国特許第７６５０３３１号明細書
【非特許文献１】Bigtable: A Distributed Storage System for Structure Data.
【発明の開示】
【０００４】
しかし、いずれの手法においても大量のデータを管理する場合、そのデータ間のつながりを意識すると、検索性能が著しく劣化するという問題がある。
【０００５】
この発明の実施の形態によれば、大規模データ最適配置システムは、データ記憶部と、分類手段と、分類結果記憶部と、検索手段とを備える。データ記憶部は、複数の実データを複数のポインタに対応付けて記憶する。分類手段は、同じ意味を有するデータからなる集合を１つのグループとし、複数の実データを複数のグループに分類する分類処理を行う。分類結果記憶部は、分類手段によって複数のグループに分類された各実データのポインタをツリー構造で記憶する。検索手段は、外部からの検索要求に応じて、検索データに合致する結果データのポインタを分類結果記憶部から受けるとともに、その受けた結果データのポインタに対応する実データをデータ記憶部から受け、その受けた実データに基づいて出力データを外部へ出力する。そして、分類結果記憶部は、検索手段からの要求に応じてツリー構造を最上層から最下層へ向けて検索し、最上層から最下層までの情報から検索データに合致する結果データのポインタを抽出する抽出処理を行い、抽出した結果データのポインタを検索手段へ出力する。データ記憶部は、結果データのポインタを検索手段から受けると、その受けたポインタに対応する実データを検索手段へ出力する。
【０００６】
また、この発明の実施の形態によれば、コンピュータ読み取り可能な検索プログラムは、複数の実データを複数のポインタに対応付けて記憶するデータ記憶部と、同じ意味を有するデータからなる集合を１つのグループとし、複数の実データを複数のグループに分類し、複数のグループに分類された各実データのポインタをツリー構造で記憶する分類結果記憶部とを用いてデータの検索をコンピュータに実行させるためのコンピュータ読み取り可能な検索プログラムであって、検索手段が、外部からの検索要求に応じて、検索データに合致する結果データのポインタの出力を分類結果記憶部に要求する第１のステップと、検索手段が、検索データに合致する結果データのポインタを分類結果記憶部から受ける第２のステップと、検索手段が、その受けた結果データのポインタに対応する実データをデータ記憶部から受け、その受けた実データに基づいて出力データを外部へ出力する第３のステップとをコンピュータに実行させるためのコンピュータ読み取り可能な検索プログラムである。
【０００７】
この発明の実施の形態による大規模データ最適配置システムにおいて、検索手段は、検索データに合致する結果データのポインタを分類結果記憶部から受け、その受けた結果データのポインタに対応する実データをデータ記憶部から受け、その受けた実データに基づいて出力データを外部へ出力する。この場合、分類結果記憶部は、検索手段からの要求を分析し、分類結果記憶部のある特定のツリーのみを検索する。つまり、検索範囲を限定する事で検索に掛かる時間を短縮している。さらに、検索対象がツリーおよびポインタとなる。
【０００８】
予め分類済みのツリー構造の特定のツリーに検索範囲を限定し、実際に検索を行う対象は、最下層のデータのみになるため、検索対象データの総数を少なくすることができる。
【０００９】
更に、検索データは、既にツリー構築時にデータ間の繋がりを基に分類したデータであるため、データ間の繋がりを維持したまま検索可能である。
【００１０】
更に、検索対象ツリーのデータ数が増加した場合、その増加したツリーをさらに分析および分類し、新たなツリーを派生ツリーとして作成することで検索性能を維持することが可能である。
【００１１】
従って、この発明によれば、データ間の繋がりを残しつつデータの肥大化による検索性能の劣化を抑制することができる。
【図面の簡単な説明】
【００１２】
【図１】この発明の実施の形態による大規模データ最適配置システムの概略図である。
【図２】図１に示す検索手段の機能を説明するための概念図である。
【図３】図１に示すインクデクシング記憶部の具体例を示す図である。
【図４】データの大規模データ最適配置システムへの登録方法を説明するためのフローチャートである。
【図５】図１に示すインデクシング処理手段におけるインデクシング動作を説明するためのフローチャートである。
【図６】図１に示すインデクシング処理手段におけるインデクシング処理をメンテナンスする動作を説明するためのフローチャートである。
【図７】図１に示す大規模データ最適配置システムにおける検索動作を説明するためのフローチャートである。
【図８】図１に示すインデクシング記憶部の他の具体例を示す図である。
【図９】図１に示すインデクシング記憶部の更に他の具体例を示す図である。
【発明を実施するための最良の形態】
【００１３】
本発明の実施の形態について図面を参照しながら詳細に説明する。なお、図中同一または相当部分には同一符号を付してその説明は繰返さない。【００１４】
図１は、この発明の実施の形態による大規模データ最適配置システムの概略図である。図１を参照して、この発明の実施の形態による大規模データ最適配置システム１００は、構造取得手段１０と、検索手段２０と、登録手段３０と、データ永続化ストレージ４０と、インデクシング処理手段５０と、インデクシング記憶部６０とを備える。【００１５】
構造取得手段１０、検索手段２０および登録手段３０は、ＡＰＩ層に配置される。データ永続化ストレージ４０およびインデクシング処理手段５０は、データストレージ層に配置される。インデクシング記憶部６０は、インデクシング層に配置される。そして、インデクシング記憶部６０は、ルートノード６１と、データベース６２〜６８とを含む。ルートノード６１およびデータベース６２〜６８は、ツリー構造（階層構造）に配置される。ルートノード６１は、最上層に配置され、データベース６２，６３は、第２階層に配置され、データベース６４〜６８は、第３階層に配置される。この場合、データベース６２，６３は、ルートノード６１に関係付けられる。データベース６４，６５は、データベース６２に関係付けられる。データベース６６〜６８は、データベース６３に関係付けられる。【００１６】
なお、インデクシング記憶部６０は、７個のデータベース６２〜６８を含んでいるが、データベースの個数は、７個に限定されず、任意の個数からなる。即ち、この発明の実施の形態においては、任意の個数からなるデータベースがルートノード６１の下に階層的に配置されていればよい。【００１７】
構造取得手段１０は、検索ＡＰＰ７０からのツリー構造取得依頼を受け、その受けたツリー構造取得依頼に応じて、ツリー構造要求をインデクシング記憶部６０のルートノード６１へ出力する。そして、構造取得手段１０は、ルートノード６１からツリー構造を受けると、その受けたツリー構造を検索ＡＰＰ７０へ出力する。【００１８】
図２は、図１に示す検索手段２０の機能を説明するための概念図である。図２を参照して、検索手段２０は、結果データポインタ取得キュー２０１、結果出力フォーマット用一次領域２０２、結果データ取得キュー２０３、結果データ取得用一時領域２０４、結果出力キュー２０５、結果出力フォーマットキュー２０６および結果出力用一時領域２０７を保持している。【００１９】
検索手段２０は、検索ＡＰＰ７０から検索依頼を受けるとともに、入力データを受ける。そして、検索手段２０は、検索依頼に応じてリクエストＩＤを発行する。また、検索手段２０は、入力データから検索用データを抽出する。そうすると、検索手段２０は、リクエストＩＤおよび検索用データを結果データポインタ取得キュー２０１に登録する。【００２０】
また、検索手段２０は、入力データから結果出力用データを抽出する。そして、検索手段２０は、結果出力フォーマット用一時領域２０２にリクエストＩＤを用いて結果出力用データを保存する。即ち、検索手段２０は、結果出力用データをリクエストＩＤに対応付けて結果出力フォーマット用一時領域２０２に保存する。【００２１】
その後、検索手段２０は、結果データポインタ取得キュー２０１からリクエストＩＤと検索用データとを取得し、その取得した検索用データからＳＱＬを作成する。【００２２】
そうすると、検索手段２０は、その作成したＳＱＬを用いてインデクシング記憶部６０のルートノード６１に問い合せを行い、検索用データに合致する結果データのポインタをルートノード６１から取得する。【００２３】
そして、検索手段２０は、結果データ取得用一時領域２０４にリクエストＩＤを用いて結果データのポインタを保存する。即ち、検索手段２０は、結果データのポインタをリクエストＩＤに対応付けて結果データ取得用一時領域２０４に保存する。また、検索手段２０は、結果データ取得キュー２０３にリクエストＩＤを登録する。【００２４】
なお、検索手段２０は、結果データのポインタを取得できなかった場合、結果が存在しないことを示すメッセージを出力データとして結果出力キュー２０５に登録する。【００２５】
検索手段２０は、リクエストＩＤを結果データ取得キュー２０３に登録した後、結果データ取得キュー２０３からリクエストＩＤを取得し、その取得したリクエストＩＤを元に結果データ取得用一時領域２０４から結果データのポインタを取得する。【００２６】
そして、検索手段２０は、その取得した結果データのポインタを元にデータ永続化ストレージ４０に問い合せ、データ永続化ストレージ４０から結果データのポインタに対応する結果データを取得する。【００２７】
その後、検索手段２０は、結果出力フォーマット用一時領域２０２にリクエストＩＤを用いて結果データを保存し、結果出力フォーマットキュー２０６にリクエストＩＤを登録する。【００２８】
引き続いて、検索手段２０は、結果出力フォーマットキュー２０６からリクエストＩＤを取得し、その取得したリクエストＩＤを元に結果出力フォーマット用一時領域２０２から結果出力用データおよび結果データを取得する。そして、検索手段２０は、その取得した結果出力用データおよび結果データを用いて出力データを成型し、結果出力用一時領域２０７にリクエストＩＤを用いて出力データを保存する。その後、検索手段２０は、結果出力キュー２０５にリクエストＩＤを登録する。【００２９】
そうすると、検索手段２０は、結果出力キュー２０５からリクエストＩＤを取得し、その取得したリクエストＩＤを元に結果出力用一時領域２０７から出力データを取得する。そして、検索手段２０は、出力データを検索ＡＰＰ７０へ出力する。【００３０】
従って、検索手段２０は、結果出力用データと結果データとに基づいて出力データを出力する。【００３１】
登録手段３０は、情報収集ＡＰＰ８０から登録依頼を受けるとともに入力データを受ける。そして、登録手段３０は、登録依頼に応じて、リクエストＩＤを発行し、入力データをデータ永続化キューに登録する。その後、登録手段３０は、処理受付を情報収集ＡＰＰ８０へ出力する。【００３２】
引き続いて、登録手段３０は、データ永続化キューから永続化の対象となる入力データ（即ち、永続化対象データ）を取得する。そして、登録手段３０は、その取得した永続化対象データを永続化する形式に従ってフォーマットする。即ち、登録手段３０は、データ永続化ストレージ４０にマッチする形式に永続化対象データをフォーマットする。【００３３】
その後、登録手段３０は、インデクシング待ちキューに永続化対象データを登録する。そして、登録手段３０は、永続化対象データがデータ永続化ストレージ４０に既に存在するか否かを判定する。【００３４】
登録手段３０は、永続化対象データがデータ永続化ストレージ４０に既に存在すると判定したとき、データ永続化ストレージ４０に保存されているデータを永続化対象データで更新する。【００３５】
一方、登録手段３０は、永続化対象データがデータ永続化ストレージ４０に既に存在していないと判定したとき、永続化対象データをデータ永続化ストレージ４０に登録する。【００３６】
データ永続化ストレージ４０は、登録手段３０によって登録されたデータをポインタに対応付けて記憶する。そして、データ永続化ストレージ４０は、検索手段２０からの結果データのポインタを用いた問い合せに応じて、そのポインタに対応するデータを抽出して検索手段２０へ出力する。【００３７】
なお、データ永続化ストレージ４０は、無限大のデータ数を記憶可能である。即ち、データ永続化ストレージ４０は、１つの記憶装置からなるのではなく、１つの記憶装置の記憶容量が満杯になると、別の記憶装置を追加可能な構成からなるので、無限大のデータ数を記憶可能である。【００３８】
インデクシング処理手段５０は、データ永続化ストレージ４０に登録された同じ意味を有するデータからなる集合を一つのグループに分類するための項目を保持している。この項目は、大規模データ最適配置システム１００のユーザによってインデクシング処理手段５０に入力される。【００３９】
インデクシング処理手段５０は、データ永続化ストレージ４０に登録されたデータに基づいて、保持している項目の属性と同じ属性を探索する。そして、インデクシング処理手段５０は、保持している項目の属性と同じ属性を発見できた場合、その発見した属性がインデクシング記憶部６０のデータベース６２〜６８に存在するか否かを判定する。【００４０】
インデクシング処理手段５０は、発見した属性がインデクシング記憶部６０のデータベース６２〜６８に存在すると判定した場合、発見した属性と同じ属性のデータベース（データベース６２〜６８のいずれか）にデータポインタを登録する。【００４１】
このように、インデクシング処理手段５０が保持している項目に従ってデータ永続化ストレージ４０に登録されたデータを分類し、その分類したデータをインデクシング記憶部６０に登録することを「インデクシング動作」と言う。【００４２】
なお、インデクシング処理手段５０は、データ永続化ストレージ４０に登録された同じ意味を有するデータからなる集合を一つのグループに分類するための項目を任意のタイミングで大規模データ最適配置システム１００のユーザによって更新される。そして、インデクシング処理手段５０は、項目が更新されると、上述した方法によって、データ永続化ストレージ４０に登録されたデータを分類し、その分類結果をインデクシング記憶部６０のデータベース６２〜６８に登録する。【００４３】
ルートノード６１は、データベース６２〜６８のツリー構造を管理している。そして、ルートノード６１は、構造取得手段１０からツリー構造要求を受けると、データベース６２〜６８のツリー構造を構造取得手段１０へ出力する。【００４４】
また、ルートノード６１は、検索手段２０からＳＱＬを受けると、自己の下位のデータベース６２〜６８を最上層から最下層へ向けて検索する。この場合、ルートノード６１は、自己の下位のデータベース６２〜６８のうち、検索すべきデータベースを特定のツリー構造になったデータベース（例えば、データベース６２〜６８のうち、ツリー構造になったデータベース６２，６４）に限定し、その限定した特定のツリー構造になったデータベースの最下層のデータベースのみを実際に検索する。つまり、ルートノード６１は、検索範囲を特定のツリー構造に限定し、その限定した特定のツリー構造の最下層のデータベースのみを検索する。そして、ルートノード６１は、最上層から最下層までの情報から最下層のデータベースに登録されたポインタを結果データのポインタとして取得し、その取得したポインタを検索手段２０へ出力する。【００４５】
このように、ルートノード６１は、検索範囲を特定のツリー構造に限定し、その限定した特定のツリー構造の最下層のデータベースのみを検索するので、検索対象のデータベース数を少なくできる。その結果、データを迅速に検索できる。また、ツリー構造のデータベースに登録されたデータは、データ間の繋がりを有しているためデータ間の繋がりを維持したままデータを検索できる。更に、検索対象のツリーのデータ数が増加した場合、そのツリーを更に分析および分類し、新たなツリーを派生ツリーとして作製するので、検索性能を維持することができる。【００４６】
データベース６２，６３の各々は、インデクシング処理手段５０によって登録された自己の一つ下の階層に存在するデータベースの属性を記憶し、最下層のデータベース６４〜６８の各々は、インデクシング処理手段５０によって登録されたポインタを記憶する。【００４７】
そして、データベース６２〜６８のうち、最上層の１つのデータベース（データベース６２または６３）から最下層の１つのデータベース（データベース６４〜６８のいずれか）までの経路上のデータベースに格納されたデータは、１つの属性を有する情報を表す。【００４８】
検索ＡＰＰ７０および情報収集ＡＰＰ８０は、大規模データ最適配置システム１００のユーザのプログラムである。【００４９】
検索ＡＰＰ７０は、検索を行なうアプリケーションであり、意図したデータを取得するために必要な全ての情報を指定する。そして、検索ＡＰＰ７０は、その指定した情報を用いて、大規模データ最適配置システム１００の検索手段２０へ検索依頼を行なう。【００５０】
情報収集ＡＰＰ８０は、情報を収集するアプリケーションであり、保存対象のデータを収集し、その収集したデータをデータ永続化ストレージ４０へ登録するように大規模データ最適配置システム１００の登録手段３０へ依頼する。【００５１】
図３は、図１に示すインデクシング記憶部６０の具体例を示す図である。図３を参照して、インデクシングの対象は、電子カルテである。また、インデクシングの指示内容は、「第１階層が都道府県であり、第２階層以下が市区町村（但し、区・町・村の子要素には、最下層にあたる医療施設のみが存在する）であり、最下層が医療施設であるように、行政区分とその行政区分に所属する医療施設によりインデクシングを行う」である。【００５２】
この場合、“電子カルテ”は、インデクシング処理手段５０が保持している項目であり、“都道府県”、“市区町村”および“医療施設”は、属性である。【００５３】
行政区分として最上位の都道府県を示す“東京都”、“兵庫県”、および“大阪府”は、ルートノード６１を除いて、最上位であるデータベース６２Ａ〜６２Ｃの属性となる。【００５４】
そして、行政区分として都道府県よりも下位である市町村を示す“神戸市”および“佐用町”は、データベース６２Ｂの下位であるデータベース６３Ａ，６３Ｂの属性となる。【００５５】
更に、行政区分である“市”の下位である区を示す“長田区”、“中央区”、および“灘区”は、データベース６３Ａの下位であるデータベース６４Ａ〜６４Ｃの属性となる。【００５６】
そして、行政区分に所属する医療施設である“ａ病院”、“ｂ病院”、“ｃ病院”、“ｄ病院”、および“ｅ病院”は、それぞれ最下層のデータベース６５Ａ〜６５Ｄ，６４Ｄの属性となる。【００５７】
なお、図３においては、データベース６５Ａ〜６５Ｃ，６４Ｄには、１個の病院に存在する全電子カルテのデータポインタが格納される。【００５８】
また、図３においては、“東京都”および“大阪府”の下位層が図示されていないが、実際には、“兵庫県”の場合と同様に下位の行政区分および病院施設がデータベース６２Ａ，６２Ｃの下位のデータベースに格納されている。【００５９】
図４は、データの大規模データ最適配置システム１００への登録方法を説明するためのフローチャートである。【００６０】
図４を参照して、データの登録が開始されると、登録手段３０は、情報収集ＡＰＰ８０から登録依頼を受け付ける（ステップＳ１０）。より具体的には、登録手段３０は、情報収集ＡＰＰ８０から登録対象の入力データを受けることによって登録依頼を受け付け（ステップＳ１１）、リクエストＩＤを発行する（ステップＳ１２）。【００６１】
そして、登録手段３０は、登録を受け付ける（ステップＳ２０）。より具体的には、登録手段３０は、データ永続化キューを保持しており、入力データをデータ永続化キューに登録する（ステップＳ２１）。その後、登録手段３０は、要求元（＝情報収集ＡＰＰ８０）に対して処理受付を通知する（ステップＳ２２）。【００６２】
引き続いて、登録手段３０は、データ永続化を行なう（ステップＳ３０）。より具体的には、登録手段３０は、データ永続化キューから永続化対象データ（＝入力データ）を取得し（ステップＳ３１）、永続化する形式に従って入力データをフォーマットする（ステップＳ３２）。この場合、フォーマットとは、データ永続化ストレージ４０にマッチする形式にフォーマットすることを言う。【００６３】
ステップＳ３２の後、登録手段３０は、インデクシング待ちキューに永続化するデータを登録する（ステップＳ３３）。そして、登録手段３０は、永続化するデータがデータストレージ層（＝データ永続化ストレージ４０）に既に存在するか否かを判定する（ステップＳ３４）。【００６４】
ステップＳ３４において、永続化するデータがデータストレージ層（＝データ永続化ストレージ４０）に既に存在すると判定されたとき、登録手段３０は、データストレージ層（＝データ永続化ストレージ４０）に保存されているデータを、永続化するデータで更新する（ステップＳ３５）。この場合、永続化するデータは、ポインタに対応付けられてデータストレージ層（＝データ永続化ストレージ４０）に保存される。【００６５】
一方、ステップＳ３４において、永続化するデータがデータストレージ層（＝データ永続化ストレージ４０）に既に存在していないと判定されたとき、登録手段３０は、永続化するデータをデータストレージ層（＝データ永続化ストレージ４０）に新たに登録する（ステップＳ３６）。【００６６】
そして、ステップＳ３５またはステップＳ３６の後、データの登録が終了する。【００６７】
図５は、図１に示すインデクシング処理手段５０におけるインデクシング動作を説明するためのフローチャートである。【００６８】
図５を参照して、インデクシング動作が開始されると、インデクシング処理手段５０は、外部からインデクシング要求を受け付ける（ステップＳ４１）。【００６９】
そして、インデクシング処理手段５０は、インデクシング待ちキューに永続化データが存在するか否かを判定する（ステップＳ４２）。【００７０】
ステップＳ４２において、インデクシング待ちキューに永続化データが存在すると判定されたとき、インデクシング処理手段５０は、データ（＝永続化データ）から保持しているインデクシング項目に合致するデータを探索する（ステップＳ４３）。例えば、図３に示す例では、インデクシング処理手段５０は、データ（＝永続化データ）からカルテ情報に合致するデータを探索する。【００７１】
そして、インデクシング処理手段５０は、インデクシング項目の属性情報を発見できたか否かを判定する（ステップＳ４４）。この場合、インデクシング処理手段５０は、ステップＳ４３において、インデクシング項目に合致するデータを発見できたとき、ステップＳ４４において、インデクシング項目の属性情報を発見できたと判定し、ステップＳ４３において、インデクシング項目に合致するデータを発見できなかったとき、ステップＳ４４において、インデクシング項目の属性情報を発見できなかったと判定する。【００７２】
ステップＳ４４において、インデクシング項目の属性情報を発見できなかったと判定されたとき、インデクシング動作は、ステップＳ４２へ戻る。【００７３】
一方、ステップＳ４４において、インデクシング項目の属性情報を発見できたと判定されたとき、インデクシング処理手段５０は、インデクシング層（＝インデクシング記憶部６０）に発見した属性のデータベースが存在するか否かを更に判定する（ステップＳ４５）。例えば、図３に示す例では、インデクシング処理手段５０は、“都道府県”、“市区町村”および“医療施設”がマッチするデータベースがインデクシング層（＝インデクシング記憶部６０）に存在するか否かを判定する。【００７４】
この場合、インデクシング処理手段５０は、“都道府県”、“市区町村”および“医療施設”がマッチするデータベースが存在するか否かをルートノード６１へ問い合わせ、ルートノード６１は、下位のデータベースに“都道府県”、“市区町村”および“医療施設”を属性とするデータベースが存在するか否かを判定する。そして、ルートノード６１は、下位のデータベースに“都道府県”、“市区町村”および“医療施設”を属性とするデータベースが存在していれば、“都道府県”、“市区町村”および“医療施設”を属性とするデータベースが存在することをインデクシング処理手段５０へ通知する。一方、ルートノード６１は、下位のデータベースに“都道府県”、“市区町村”および“医療施設”を属性とするデータベースが存在していなければ、“都道府県”、“市区町村”および“医療施設”を属性とするデータベースが存在しないことをインデクシング処理手段５０へ通知する。【００７５】
ステップＳ４５において、インデクシング層（＝インデクシング記憶部６０）に発見した属性のデータベースが存在しないと判定されたとき、インデクシング動作は、ステップＳ４２へ戻る。【００７６】
一方、ステップＳ４５において、インデクシング層（＝インデクシング記憶部６０）に発見した属性のデータベースが存在すると判定されたとき、インデクシング処理手段５０は、データポインタを対象のデータベースに登録する（ステップＳ４６）。【００７７】
その後、インデクシング動作は、ステップＳ４２へ戻り、ステップＳ４２において、インデクシング待ちキューに永続化データが存在しないと判定されるまで、上述したステップＳ４２〜ステップＳ４６が繰り返し実行される。そして、ステップＳ４２において、インデクシング待ちキューに永続化データが存在しないと判定されると、インデクシング動作は、終了する。【００７８】
図６は、図１に示すインデクシング処理手段５０におけるインデクシング処理をメンテナンスする動作を説明するためのフローチャートである。【００７９】
図６を参照して、インデクシング処理のメンテナンスが開始されると、インデクシング処理手段５０の項目が変更される（ステップＳ５１）。【００８０】
そして、インデクシング処理手段５０は、インデクシング項目を探索し（ステップＳ５２）、インデクシング項目を新たに発見できたか否かを判定する（ステップＳ５３）。【００８１】
ステップＳ５３において、インデクシング項目を新たに発見できなかったと判定されたとき、一連の動作は、ステップＳ５５へ移行する。【００８２】
一方、ステップＳ５３において、インデクシング項目を新たに発見できたと判定されたとき、インデクシング処理手段５０は、インデクシング項目リストに発見したインデクシング項目を追加する（ステップＳ５４）。【００８３】
そして、インデクシング処理手段５０は、インデクシング項目リストに１つ以上のインデクシング項目が存在するか否かを判定する（ステップＳ５５）。【００８４】
ステップＳ５５において、インデクシング項目リストに１つ以上のインデクシング項目が存在すると判定されたとき、インデクシング処理手段５０は、インデクシング層（＝インデクシング記憶部６０）に全インデクシング項目に対応するツリー構造のデータベース（ＤＢ）を作成する（ステップＳ５６）。【００８５】
そして、インデクシング処理手段５０は、インデクシング待ちキューに対して永続化されている全データを登録する（ステップＳ５７）。これによって、インデクシング処理手段５０のメンテナンスが終了する（ステップＳ５８）。【００８６】
一方、ステップＳ５５において、インデクシング項目リストに１つ以上のインデクシング項目が存在しないと判定されたとき、インデクシング処理手段５０のメンテナンスは、エラーによって終了する（ステップＳ５９）。【００８７】
なお、ステップＳ５８によってインデクシング処理手段５０のメンテナンスが終了した後、上述したインデクシング動作（＝図５に示すフローチャート）が実行される。【００８８】
図７は、図１に示す大規模データ最適配置システム１００における検索動作を説明するためのフローチャートである。【００８９】
図７を参照して、検索動作が開始されると、検索手段２０は、検索ＡＰＰ７０から検索依頼を受けるとともに、入力データを受ける（ステップＳ６０）。より具体的には、検索手段２０は、外部（＝検索ＡＰＰ７０）から検索依頼および入力データを受け付け（ステップＳ６１）、検索依頼に応じてリクエストＩＤを発行する（ステップＳ６２）。【００９０】
そして、検索手段２０は、入力情報を整理する（ステップＳ７０）。より具体的には、検索手段２０は、入力データから検索用データを抽出する（ステップＳ７１）。図３に示す例では、検索手段２０は、病院の市区町村までの指定と、病名とからなる検索用データを入力データから抽出する。その後、検索手段２０は、リクエストＩＤおよび検索用データを結果データポインタ取得キュー２０１に登録する（ステップＳ７２）。【００９１】
引き続いて、検索手段２０は、入力データから結果出力用データを抽出する（ステップＳ７３）。即ち、検索手段２０は、フォーマットが病院名およびカルテ番号である結果出力用データを抽出する。そして、検索手段２０は、結果出力フォーマット用一時領域２０２にリクエストＩＤを用いて結果出力用データを保存する（ステップＳ７４）。即ち、検索手段２０は、結果出力用データをリクエストＩＤに対応付けて結果出力フォーマット用一時領域２０２に保存する。【００９２】
その後、検索手段２０は、結果データのポインタを取得する（ステップＳ８０）。より具体的には、検索手段２０は、結果データポインタ取得キュー２０１からリクエストＩＤと検索用データとを取得し（ステップＳ８１）、その取得した検索用データからＳＱＬを作成する（ステップＳ８２）。図３に示す例では、検索手段２０は、検索用データの市区町村までの指定から都道府県を抽出し、都道府県のテーブルから兵庫県神戸市のテーブルを割り出す。そして、検索手段２０は、兵庫県に属する神戸市のテーブルから神戸市に属する全ての区町村のデータを結合し、それに対し、カルテに記載された病名に一致する病名を検索するＳＱＬを作成する。【００９３】
そうすると、検索手段２０は、その作成したＳＱＬを用いてインデクシング記憶部６０のルートノード６１に問い合せを行い、ルートノード６１から結果データのポインタを取得する（ステップＳ８３）。図３に示す例では、ポインタは、病院住所＋病院名＋カルテ番号からなる。【００９４】
この場合、ルートノード６１は、検索手段２０からＳＱＬを受けると、その受けたＳＱＬに基づいて、検索範囲を特定のツリー構造のデータベースに限定する。図３に示す例では、ルートノード６１は、検索範囲をデータベース６２Ｂ−データベース６３Ａ−データベース６４Ａ〜６４Ｃ−６５Ａ〜６５Ｄに限定し、実際には、データベース６５Ａ〜６５Ｄのみを検索する。そして、ルートノード６１は、データベース６５Ａ〜６５Ｄに登録されたポインタを結果データのポインタとしてデータベース６５Ａ〜６５Ｄから取得し、その取得した結果データのポインタを検索手段２０へ出力する。【００９５】
そして、検索手段２０は、結果データのポインタを取得できたか否かを判定する（ステップＳ８４）。【００９６】
ステップＳ８４において、結果データのポインタを取得できたと判定されたとき、検索手段２０は、結果データ取得用一時領域２０４にリクエストＩＤを用いて結果データのポインタを保存する（ステップＳ８５）。即ち、検索手段２０は、結果データのポインタをリクエストＩＤに対応付けて結果データ取得用一時領域２０４に保存する。そして、検索手段２０は、結果データ取得キュー２０３にリクエストＩＤを登録する（ステップＳ８６）。【００９７】
一方、ステップＳ８４において、結果データのポインタを取得できなかったと判定されたとき、検索手段２０は、結果が存在しないことを示すメッセージを出力データとして結果出力キュー２０５に登録する（ステップＳ８７）。【００９８】
そして、ステップＳ８６またはステップＳ８７の後、検索手段２０は、結果データを取得する（ステップＳ９０）。より具体的には、検索手段２０は、結果データ取得キュー２０３からリクエストＩＤを取得し（ステップＳ９１）、その取得したリクエストＩＤを元に結果データ取得用一時領域２０４から結果データのポインタを取得する（ステップＳ９２）。【００９９】
そして、検索手段２０は、その取得した結果データのポインタを元にデータ永続化ストレージ４０に問い合せ、データ永続化ストレージ４０から結果データを取得する（ステップＳ９３）。この場合、データ永続化ストレージ４０は、検索手段２０から結果データのポインタを受け、その受けたポインタに対応して記憶しているデータを結果データとして検索手段２０へ出力する。【０１００】
その後、検索手段２０は、結果出力フォーマット用一時領域２０２にリクエストＩＤを用いて結果データを保存し（ステップＳ９４）、結果出力フォーマットキュー２０６にリクエストＩＤを登録する（ステップＳ９５）。【０１０１】
引き続いて、検索手段２０は、結果出力をフォーマットする（ステップＳ１００）。より具体的には、検索手段２０は、結果出力フォーマットキュー２０６からリクエストＩＤを取得し（ステップＳ１０１）、その取得したリクエストＩＤを元に結果出力フォーマット用一時領域２０２から結果出力用データおよび結果データを取得する（ステップＳ１０２）。そして、検索手段２０は、その取得した結果出力用データおよび結果データを用いて出力データを成型し（ステップＳ１０３）、結果出力用一時領域２０７にリクエストＩＤを用いて出力データを保存する（ステップＳ１０４）。その後、検索手段２０は、結果出力キュー２０５にリクエストＩＤを登録する（ステップＳ１０５）。【０１０２】
そうすると、検索手段２０は、結果を出力する（ステップＳ１１０）。より具体的には、検索手段２０は、結果出力キュー２０５からリクエストＩＤを取得し（ステップＳ１１１）、その取得したリクエストＩＤを元に結果出力用一時領域２０７から出力データを取得する（ステップＳ１１２）。そして、検索手段２０は、出力データを要求元（＝検索ＡＰＰ７０）へ出力する（ステップＳ１１３）。【０１０３】
これによって、検索動作が終了する。【０１０４】
このように、図７に示すフローチャートに従って検索動作を実行することによって、神戸市の長田区、中央区、および灘区等の各区に存在する全ての病院、または兵庫県佐用町に存在する全ての病院が検索される。つまり、検索範囲がデータベース６２Ａ〜６２Ｃ，６３Ａ，６３Ｂ，６４Ａ〜６４Ｄ，６５Ａ〜６５Ｄのうち、データベース６２Ｂ，６３Ａ，６４Ａ〜６４Ｃ，６５Ａ〜６５Ｄに限定され、データベース６５Ａ〜６５Ｄのみが実際に検索される。そして、データベース６２Ｂ，６３Ａ，６４Ａ〜６４Ｃ，６５Ａ〜６５Ｄは、データの分類時にデータ間の繋がりを基に分類されたデータを記憶する。その結果、各ユーザが希望する情報（＝各行政区分内に存在する全ての病院）が漏れ無く抽出される。【０１０５】
従って、検索対象のデータベース数を少なくでき、データ間の繋がりを維持したままデータを検索できる。つまり、データ間の繋がりを維持したままデータの肥大化による検索機能の劣化を抑制できる。【０１０６】
図８は、図１に示すインデクシング記憶部６０の他の具体例を示す図である。図８を参照して、インデクシングの対象は、大学生情報である。また、インデクシングの指示内容は、「第１階層が学年であり、第２階層が成績（全取得単位数中における「優」の割合）であり、第３階層が学部であり、第４階層が、大学がある都道府県であり、最下層が大学であるように、学年と成績とによってインデクシングを行う」である。【０１０７】
この場合、“大学生情報”は、インデクシング処理手段５０が保持している項目であり、“学年”、“成績”、“学部”、“大学がある都道府県”および“大学”は、属性である。【０１０８】
学年を示す“学部３年”、“学部４年”、および“修士１年”は、ルートノード６１を除いて、最上位であるデータベース６２Ｄ〜６２Ｆの属性となる。【０１０９】
そして、成績を示す“「優」が５〜８割”および“「優」が８割以上”は、データベース６２Ｅの下位であるデータベース６３Ｃ，６３Ｄの属性となる。【０１１０】
更に、学部を示す“経済学部”、“工学部”、および“医学部”は、データベース６３Ｄの下位であるデータベース６４Ｅ〜６４Ｇの属性となる。【０１１１】
更に、大学をある都道府県を示す“大阪府”、“兵庫県”、“東京都”および“北海道”は、データベース６４Ｅ〜６４Ｇの下位のデータベース６５Ｅ〜６５Ｈの属性となる。【０１１２】
そして、都道府県に所属する大学である“大阪府立大学”、“大阪大学”、“神戸大学”、“東京大学”、および“北海道大学”は、それぞれ最下層のデータベース６６Ａ〜６６Ｅの属性となる。【０１１３】
なお、図８においては、図３において説明したように、データベース６２Ｅの下位に存在するデータベース６３Ｃ，６３Ｄ，６４Ｅ〜６４Ｇ，６５Ｅ〜６５Ｈ，６６Ａ〜６６Ｅと同等の構成からなるデータベースがデータベース６２Ｄ，６２Ｆの下位に存在する。【０１１４】
また、データベース６６Ａ〜６６Ｅには、１個の大学が格納されているが、実際には、各都道府県に存在する全ての大学の学生情報のポインタが格納される。【０１１５】
図１に示すインデクシング記憶部６０のツリー構造が図８に示すツリー構造からなる場合、日本全国に存在する全ての大学の特定の学年に所属する学生の成績を漏れ無く抽出できる。【０１１６】
図９は、図１に示すインデクシング記憶部６０の更に他の具体例を示す図である。図９を参照して、インデクシングの対象は、ＥＣサイトの購入履歴である。また、インデクシングの指示内容は、「第１階層が時間帯であり、第２階層が年代であり、第３階層が性別であり、最下層が、都道府県であるように、時間帯、年代、性別および都道府県によってインデクシングを行う」である。【０１１７】
この場合、“ＥＣサイトの購入履歴”は、インデクシング処理手段５０が保持している項目であり、“時間帯”、“年代”、“性別”、および“都道府県”は、属性である。【０１１８】
時間帯を示す“１９時”、“２０時”、および“２１時”は、ルートノード６１を除いて、最上位であるデータベース６２Ｇ〜６２Ｉの属性となる。【０１１９】
そして、年代を示す“３０代”および“４０代”は、データベース６２Ｈの下位であるデータベース６３Ｅ，６３Ｆの属性となる。【０１２０】
更に、性別を示す“男性”および“女性”は、データベース６３Ｆの下位であるデータベース６４Ｈ，６４Ｉの属性となる。【０１２１】
そして、都道府県である“兵庫県”、“大阪府”、“北海道”、および“東京都”は、それぞれ最下層のデータベース６５Ｉ〜６５Ｌの属性となる。【０１２２】
なお、図９においては、図３において説明したように、データベース６２Ｈの下位に存在するデータベース６３Ｅ，６３Ｆ，６４Ｈ，６４Ｉ，６５Ｉ〜６５Ｌと同等の構成からなるデータベースがデータベース６２Ｇ，６２Ｉの下位に存在する。【０１２３】
図１に示すインデクシング記憶部６０のツリー構造が図９に示すツリー構造からなる場合、各都道府県の男性または女性の特定の年代におけるＥＣサイトの購入履歴を漏れ無く抽出できる。【０１２４】
なお、この発明の実施の形態においては、図３、図８および図９に示すインデクシング対象およびインデクシング指示内容以外のインデクシング対象およびインデクシング指示内容によってインデクシングツリー構造が構築されていてもよい。【０１２５】
また、上記においては、検索手段２０は、図３に示す例では、病院の市区町村までの指定と、病名とからなる検索用データを入力データから抽出すると説明したが、この発明の実施の形態においては、これに限らず、検索手段２０は、図３に示す例では、都道府県までの指定と、病名とからなる検索用データを入力データから抽出してもよい。【０１２６】
この場合、検索手段２０は、その抽出した検索用データの都道府県までの指定から検索対象となる都道府県（＝例えば、兵庫県）を抽出する。そして、検索手段２０は、兵庫県のテーブルから兵庫県に属する全ての市区町村のデータを結合し、それに対し、カルテに記載された病名に一致する病名を検索するＳＱＬを作成する。【０１２７】
ルートノード６１は、検索手段２０からＳＱＬを受けると、その受けたＳＱＬに基づいて、検索対象のデータベースをデータベース６２Ｂ−データベース６３Ａ，６３Ｂ−データベース６４Ａ〜６４Ｄ−データベース６５Ａ〜６５Ｄに限定し、実際には、データベース６４Ｄ，６５Ａ〜６５Ｄのみを検索する。そして、ルートノード６１は、データベース６４Ｄ，６５Ａ〜６５Ｄに登録されたポインタを結果データのポインタとしてデータベース６４Ｄ，６５Ａ〜６５Ｄから取得し、その取得したポインタを検索手段２０へ出力する。これによって、兵庫県に属する全ての病院に存在する電子カルテを検索できる。【０１２８】
このように、この発明の実施の形態においては、データを検索する場合の入力データにおいては、ツリー構造のデータベースにおいて最下層のデータベースの直上のデータベースに格納された情報までを指定する必要はなく、ルートノード６１と最下層のデータベースとの間の任意の階層のデータベースに格納された情報までを指定すればよい。このようにしても、検索対象のデータベースがツリー構造からなるので、ルートノード６１がツリー構造に基づいて最下層のデータベースまで到達でき、最下層のデータベースに格納されたポインタを抽出できるからである。【０１２９】
従って、指定する情報をルートノード６１と最下層のデータベースとの間の任意の階層のデータベースに格納された情報とすることによって、検索対象の範囲を任意の範囲に設定できる。【０１３０】
更に、上記においては、病名まで指定して検索すると説明したが、この発明の実施の形態においては、これに限らず、病名まで指定せずに検索してもよい。この場合、病名に関係なく、全てのカルテ情報を検索できる。【０１３１】
上述したように、データ永続化ストレージ４０は、実際のデータをポインタに対応付けて記憶するので、複数の実データを複数のポインタに対応付けて記憶する「データ記憶部」を構成する。【０１３２】
また、インデクシング処理手段５０は、保持している項目の属性（＝都道府県、市区町村等の行政区分）に合致するデータをデータ永続化ストレージ４０に格納されたデータから探索し、項目の属性（＝都道府県、市区町村等の行政区分）を記憶するデータベースに探索したデータを格納する。従って、インデクシング処理手段５０は、同じ意味（＝属性は、例えば、行政区分という同じ意味を有する）を有するデータからなる複数のグループ（＝例えば、図３のデータベース６２Ａ〜６２Ｃ；６３Ａ，６３Ｂ等）に複数の実データ（＝データ永続化ストレージ４０に格納されたデータ）を分類する分類処理を行なう。【０１３３】
そして、インデクシング記憶部６０は、インデクシング処理手段５０の分類処理によって分類された複数のグループを表し、ツリー構造からなる複数のデータベースを有する「分類結果記憶部」を構成する。【０１３４】
なお、上述した図７に示すフローチャートは、この発明の実施の形態による「検索プログラム」を構成する。【０１３５】
この場合、コンピュータは、データ永続化ストレージ４０と、インデクシング記憶部６０と、検索プログラム（＝図７に示すフローチャートからなるプログラム）とをＲＯＭ（Ｒｅａｄ  Ｏｎ  Ｍｅｍｏｒｙ）に格納している。また、コンピュータは、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）と、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）とを備えている。そして、コンピュータのＣＰＵは、ユーザから検索指示を受け付けると、ＲＯＭから検索プログラムを読み出して実行する。そうすると、検索プログラムは、図７に示す各ステップに従って検索を実行する。その結果、ＣＰＵは、検索されたデータを取得し、その取得したデータを外部へ出力する。従って、検索プログラムは、コンピュータ（＝ＣＰＵ）読み取り可能なプログラムである。【０１３６】
今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した実施の形態の説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【産業上の利用可能性】
【０１３７】
この発明は、大規模データ最適配置システムおよびそれを用いた高速な検索プログラムに適用される。
【図１】
2012117953.tif 000003
【図２】
2012117953.tif 000004
【図３】
2012117953.tif 000005
【図４】
2012117953.tif 000006
【図５】
2012117953.tif 000007
【図６】
2012117953.tif 000008
【図７】
2012117953.tif 000009
【図８】
2012117953.tif 000010
【図９】
2012117953.tif 000011
【手続補正書】
【提出日】平成24年10月5日(2012.10.5)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数の実データを複数のポインタに対応付けて記憶するデータ記憶部と、
同じ意味を有するデータからなる集合を１つのグループとし、前記複数の実データを複数のグループに分類する分類処理を行う分類手段と、
ツリー構造に配置された複数のデータベースからなり、最上層の１つのデータベースから最下層の１つのデータベースまでの経路上のデータベースに格納されたデータは１つの属性を有する情報を表すとともに、前記分類手段によって複数のグループに分類された各実データのポインタを同じ属性を有する最下層の各データベースに記憶する分類結果記憶部と、
外部からの検索要求に応じて、検索データに合致する結果データのポインタを前記分類結果記憶部から受けるとともに、その受けた結果データのポインタに対応する実データを前記データ記憶部から受け、その受けた実データに基づいて出力データを外部へ出力する検索手段とを備え、
前記分類結果記憶部は、前記検索手段からの要求に応じて前記ツリー構造を最上層から最下層へ向けて検索し、前記最上層から前記最下層までの情報から前記検索データに合致する結果データのポインタを対象の最下層のデータベースから抽出する抽出処理を行い、前記抽出した結果データのポインタを前記検索手段へ出力し、
前記データ記憶部は、前記結果データのポインタを前記検索手段から受けると、その受けたポインタに対応する実データを前記検索手段へ出力する、大規模データ最適配置システム。
【請求項２】
前記分類結果記憶部において、前記ツリー構造の最上層のルートノードが自己よりも下位層に問い合わせ、前記結果データのポインタを下位層から取得して出力する、請求項１に記載の大規模データ最適配置システム。
【請求項３】
新たな実データの登録要求に応じて新たな実データを前記データ記憶部に登録する登録手段を更に備え、
前記登録手段は、前記新たな実データが前記データ記憶部に存在するとき、前記新たな実データの永続化処理を行い、その永続化処理を行なった実データによって既に存在するデータを更新することによって前記新たな実データをポインタに対応付けて前記データ記憶部に登録し、前記新たな実データが前記データ記憶部に存在しないとき、前記新たな実データの永続化処理を行い、その永続化処理を行なった実データをポインタに対応付けて前記記憶部に登録し、
前記分類手段は、前記新たな実データが前記データ記憶部に登録されると、前記分類処理を行い、前記分類処理の結果に基づいて前記複数のデータベースを更新する、請求項１または２に記載の大規模データ最適配置システム。
【請求項４】
前記分類手段は、前記分類処理の対象となる実データが有する意味からなる属性が前記複数のデータベースのいずれかの属性を同じであるとき、前記分類処理の対象となる実データを前記同じ属性を有するデータベースに分類する、請求項３に記載の大規模データ最適配置システム。
【請求項５】
複数の実データを複数のポインタに対応付けて記憶するデータ記憶部と、ツリー構造に配置された複数のデータベースからなり、最上層の１つのデータベースから最下層の１つのデータベースまでの経路上のデータベースに格納されたデータは１つの属性を有する情報を表すとともに、前記分類結果手段によって複数のグループに分類された各実データのポインタを同じ属性の最下層の各データベースに記憶する分類結果記憶部とを用いてデータの検索をコンピュータに実行させるためのコンピュータ読み取り可能な検索プログラムであって、
検索手段が、外部からの検索要求に応じて、検索データに合致する結果データのポインタの出力を前記分類結果記憶部に要求する第１のステップと、
前記検索手段が、前記検索データに合致する結果データのポインタを前記分類結果記憶部から受ける第２ステップと、
前記検索手段が、その受けた結果データのポインタに対応する実データを前記データ記憶部から受け、その受けた実データに基づいて出力データを外部へ出力する第３のステップとをコンピュータに実行させるためのコンピュータ読み取り可能な検索プログラム。
【国際調査報告】
2012117953.tif 000012
2012117953.tif 000013