JP5871698B2 - 情報蓄積検索装置 - Google Patents

Description

本発明は、センサ情報を扱うデータベースの構成法に関する。

従来、センサの計測データのような情報すなわちセンサ情報を扱う情報管理システムとして、ｕＴｕｐｌｅＳｐａｃｅ（非特許文献１および特許文献１）があった。ｕＴｕｐｌｅＳｐａｃｅの特徴の一つに、センサ情報をｕＴｕｐｌｅ形式という、「キー＝値」の並びにより自由に表現できる点がある。

さらに、ｕＴｕｐｌｅＳｐａｃｅのもう一つの特徴に、計測されたデータ値を先に蓄積しておき後から検索式を投入することでマッチするデータ値を検索して検索式の投入元に返却するような通常のデータベース管理システムのようなデータ値蓄積型の検索処理だけでなく、検索式を先に蓄積しておき後からデータ値を登録することでマッチするデータ値を検索式の蓄積元に返却するような検索式待ち受け型の検索処理もサポートしており、これらを区別なく扱える点がある。なお、ｕＴｕｐｌｅＳｐａｃｅの用語では、データ値を示すｕＴｕｐｌｅをＥｖｅｎｔＡｃｔｕａｌ（ＥＡ）と呼び、また、検索式を表すｕＴｕｐｌｅをＥｖｅｎｔＦｏｒｍａｌ（ＥＦ）と呼ぶ。

また従来、ｕＴｕｐｌｅ形式のように複数の値を持つデータ値をまとめて索引づけするデータ構造として、多次元検索木ＵＢＩ−Ｔｒｅｅ（特許文献２および特許文献３）があった。

これらの文献に開示されているＵＢＩ−Ｔｒｅｅを蓄積検索の中心的な処理方式として用いることで、ｕＴｕｐｌｅ形式のデータ値を蓄積しておき検索式に従って取り出すといった、通常のデータベース管理システムのようなデータ値蓄積型の基本的動作を効率的かつ容易に実現することができる。

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

「Ｄｅｓｉｇｎ ａｎｄ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ｏｆ Ｎｅｗ ｕＴｕｐｌｅＳｐａｃｅ Ｅｎａｂｌｉｎｇ Ｓｔｏｒａｇｅ ａｎｄ Ｒｅｔｒｉｅｖａｌ ｏｆ Ｌａｒｇｅ Ａｍｏｕｎｔ ｏｆ Ｓｃｈｅｍａ−ｌｅｓｓ Ｓｅｎｓｏｒ Ｄａｔａ」、Ｔａｋａｙｕｋｉ Ｎａｋａｍｕｒａ， Ｋｅｉｉｃｈｉｒｏ Ｋａｓｈｉｗａｇｉ， Ｙｕｔａｋａ Ａｒａｋａｗａ， Ｍｏｔｏｎｏｒｉ Ｎａｋａｍｕｒａ著、Ｓｅｃｏｎｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｗｏｒｋｓｈｏｐ ｏｎ Ｅｎａｂｌｅｒｓ ｆｏｒ Ｕｂｉｑｕｉｔｏｕｓ ａｎｄ Ｃｏｎｔｅｘｔ−Ａｗａｒｅ Ｓｅｒｖｉｃｅｓ ｏｎ Ｓｅｎｓｏｒ Ｎｅｔｗｏｒｋｓ （ＥＵＣＡＳＳ ２０１１）、２０１１年７月

従来、データ値蓄積型の検索処理にはＵＢＩ−Ｔｒｅｅによる効率的処理が可能である反面、ｕＴｕｐｌｅＳｐａｃｅの特徴である検索式待ち受け型の検索処理には、ＵＢＩ−Ｔｒｅｅのような効率的なアルゴリズムを用いることができないという問題があった。これは、一般にＵＢＩ−Ｔｒｅｅのような木構造アルゴリズムは、データを蓄積しておき、それらを検索式で取り出す処理を前提として考案・設計されているためである。

このため、ｕＴｕｐｌｅＳｐａｃｅを実現する際には、事前に登録された検索式を線形検索のような初歩的な方式で蓄積・検索することによって検索式待ち受け型の検索処理を実現せざるを得ず、効率的な装置を実現できなかった。

本願発明の情報蓄積検索方法は、検索式蓄積手段と検索式検索手段とを備える情報蓄積検索装置が、次元及び値を少なくとも含む情報を蓄積し検索する情報蓄積検索方法において、前記検索式蓄積手段が、同時に複数次元の値による範囲検索が可能でかつ木構造のデータエントリとして、値の範囲を持つエントリを登録可能な検索式用木構造を用いて、前記情報に含まれる複数の次元の値範囲を少なくとも条件に含む与えられた検索式を蓄積する検索式蓄積手順と、前記検索式検索手段が、複数の次元の値または値範囲を少なくとも含む与えられた情報のデータ値を木構造の検索条件として、該検索式用木構造から該検索条件にマッチする登録されたエントリ群を検索する検索式検索手順と、を順に実行することを特徴とする。

本願発明の情報蓄積検索方法では、前記情報蓄積検索装置は、データ値蓄積手段とデータ値検索手段とをさらに備え、前記情報蓄積検索装置が、前記情報のデータ値の登録要求を受け付けると、前記検索式検索手段が、該データ値に対して前記検索式検索手順を行うことによって前記検索式用木構造から検索式を検索するとともに、前記データ値蓄積手段が、同時に複数次元の値による範囲検索が可能なデータ値用木構造に、該データ値を蓄積し、前記情報蓄積検索装置が、検索式の登録要求を受け付けると、前記データ値検索手段が、登録要求のあった検索式にマッチするデータ値を、該データ値用木構造から検索するとともに、前記検索式蓄積手段が、前記検索式蓄積手順において、該検索式を前記検索式用木構造に蓄積してもよい。

本願発明の情報蓄積検索方法では、前記検索式検索手順におけるマッチするか否かの判定には、判定対象の該登録されたエントリが含む全ての次元が判定対象の該検索式用木構造の検索条件にも全て含まれており、かつ、両者の該次元の値範囲と値範囲の積集合が空集合とならないことを少なくとも条件としてもよい。

本願発明の情報蓄積検索方法では、前記検索式用木構造は、ＵＢＩ−Ｔｒｅｅアルゴリズムであってもよい。

本願発明の情報蓄積検索装置は、次元及び値を少なくとも含む情報を蓄積し検索する情報蓄積検索装置であって、同時に複数次元の値による範囲検索が可能でかつ木構造のデータエントリとして、値の範囲を持つエントリを登録可能な検索式用木構造を用いて、前記情報に含まれる複数の次元の値範囲を少なくとも条件に含む与えられた検索式を蓄積する検索式蓄積手段と、複数の次元の値または値範囲を少なくとも含む与えられた情報のデータ値を木構造の検索条件として、該検索式用木構造から該検索条件にマッチする登録されたエントリ群を検索する検索式検索手段と、を備えることを特徴とする。

本願発明の情報蓄積検索装置では、与えられた情報のデータ値を、同時に複数次元の値による範囲検索が可能なデータ値用木構造に蓄積するデータ値蓄積手段と、与えられた検索式によってマッチするデータ値を検索するデータ値検索手段と、をさらに備え、前記情報のデータ値の登録要求を受け付けると、該データ値に対して前記検索式検索手段を用いて前記検索式用木構造から検索式を検索するとともに、該データ値蓄積手段を用いて該データ値を該データ値用木構造に蓄積し、検索式の登録要求を受け付けると、該検索式に対して該データ値検索手段を用いて該データ値用木構造からデータ値を検索するとともに、前記検索式蓄積手段を用いて該検索式を前記検索式用木構造に蓄積してもよい。

本願発明の情報蓄積検索装置では、前記検索式検索手段におけるマッチするか否かの判定には、判定対象の該登録されたエントリが含む全ての次元が判定対象の該検索式用木構造の検索条件にも全て含まれており、かつ、両者の該次元の値範囲と値範囲の積集合が空集合とならないことを少なくとも条件としてもよい。

本願発明の情報蓄積検索装置では、前記検索式用木構造はＵＢＩ−Ｔｒｅｅアルゴリズムであってもよい。

本願発明の情報蓄積検索プログラムは、コンピュータを、前記検索式蓄積手段及び前記検索式検索手段又は前記検索式蓄積手段、前記検索式検索手段、前記データ値蓄積手段及び前記データ値検索手段として機能させるためのプログラムである。

本発明によれば、従来同様にデータ値蓄積型の検索処理にＵＢＩ−Ｔｒｅｅによる効率的処理が可能であることに加え、検索式待ち受け型の検索処理にも改良したＵＢＩ−Ｔｒｅｅによる効率的処理が可能となる。これによって、ｕＴｕｐｌｅＳｐａｃｅの特徴であるデータ値蓄積型の検索処理と検索式待ち受け型の検索処理とを区別なく扱える点に対して、双方の検索処理ともに効率的な実現が可能となる。

本実施の形態における装置構成を示す。 ＥＡ用ＵＢＩ−Ｔｒｅｅ（１１１）が保持するＥＡの一覧を示す。 ＥＡ用ＵＢＩ−Ｔｒｅｅ（１１１）の構造を示す。 ＥＡとＥＦのマッチング規則を示す。 ＥＦ用ＵＢＩ−Ｔｒｅｅ（１１３）が保持するＥＦの一覧を示す。 ＥＦ用ＵＢＩ−Ｔｒｅｅ（１１３）の構造を示す。 ＩＰアドレス表（１１４）の内容を示す。 新たに登録するＥＦの内容を示す。 ＥＦ登録処理の手順を示す。 ＥＦ登録の結果として検索表示装置（１０３）に返却されるＥＡの一覧を示す。 ＥＦ登録処理後のＥＦ用ＵＢＩ−Ｔｒｅｅ（１１３）が保持するＥＦの一覧を示す。 ＥＦ登録処理後のＥＦ用ＵＢＩ−Ｔｒｅｅ（１１３）の構造を示す。 ＥＦ登録処理後のＩＰアドレス表（１１４）の内容を示す。 新たに登録するＥＡの内容を示す。 ＥＡ登録処理の手順を示す。 センサ装置（１０２）からのＥＡ登録の結果として検索表示装置（１０３）に返却されるＥＡを示す。 ＥＡ登録処理後のＥＡ用ＵＢＩ−Ｔｒｅｅ（１１１）が保持するＥＡの一覧を示す。 ＥＡ登録処理後のＥＡ用ＵＢＩ−Ｔｒｅｅ（１１１）の構造を示す。 ＣＡとＣＦのマッチング規則を示す。

本発明の実施の形態の一つを以下に示す。
第１図は本実施の形態における装置構成を示す。情報蓄積検索装置（１０１）はｕＴｕｐｌｅＳｐａｃｅを実現したサーバであり、ネットワーク（１０４）に接続され、データ値用木構造であるＥＡ用ＵＢＩ−Ｔｒｅｅ（１１１）と検索式用木構造であるＥＦ用ＵＢＩ−Ｔｒｅｅ（１１３）と要求受付処理部（１１５）とＩＰアドレス表（１１４）を具備する。ネットワーク（１０４）にはその他に、センサ装置（１０２）と検索表示装置（１０３）が接続される。それぞれの装置のＩＰアドレスは、情報蓄積検索装置（１０１）が１９２．１６８．０．１、センサ装置（１０２）が１９２．１６８．０．２、検索表示装置（１０３）が１９２．１６８．０．３である。

ＥＡ用ＵＢＩ−Ｔｒｅｅ（１１１）はセンサ値を蓄積する機能を有するが、これは通常のＵＢＩ−Ｔｒｅｅの使用法であり、以前から従来技術により実現可能であった部分である。以下ではまず、この従来技術の動作をＥＦ登録処理を通じて詳細に説明することで、本発明の前提となる動作について明確に示す。その次にＥＡ登録処理を通じて詳細説明するＥＦ用ＵＢＩ−Ｔｒｅｅ（１１３）は、検索式を蓄積する機能を有するが、これは本発明に特有の動作を行うものであり、このため本発明における動作の差異を以下で明確に示していくこととする。

第２図はＥＡ用ＵＢＩ−Ｔｒｅｅ（１１１）が保持するＥＡの一覧を示す。ここでは、以下に順次示していくＥＦ登録処理およびＥＡ登録処理に先立って、（２２１）〜（２２５）の５個のＥＡすなわちセンサ情報のデータ値が既にｕＴｕｐｌｅＳｐａｃｅに登録されているものと仮定する。なお、これらのＥＡの表す意味は、例えばＥＡ１（２２１）であれば、「登録日時が２０１２年１月３１日１１時３０分、温度が摂氏１６．２度、湿度が６０％」というセンサの測定値であることを示す。また、例えばＥＡ２（２２２）であれば、「登録日時が２０１２年１月３１日１３時３０分、温度が摂氏１５．４度」というセンサの測定値であることを示し、かつ、このデータ値には湿度に関する測定情報が含まれていないことを示す。

第３図はＥＡ用ＵＢＩ−Ｔｒｅｅ（１１１）の構造を示す。この木構造は、第２図で示した５個のＥＡを保持しつつ索引を管理している。ＵＢＩ−Ｔｒｅｅは多次元データをデータエントリとして階層構造で保持することを特徴とする木構造である。ＥＡ用ＵＢＩ−Ｔｒｅｅ（１１１）は従来技術のＵＢＩ−Ｔｒｅｅの動作そのままであり、具体的には以下に示す動作を行う。

ＵＢＩ−Ｔｒｅｅのそれぞれのノードは、該ノードが含む全データを包み込む多次元直方体の情報を保持する。例えば、ノード（２３２）は、ＥＡ１〜ＥＡ３までのデータエントリ群を保持している。該データエントリ群について、次元「日時」の最小値は「２０１２０１３１１１３０」かつ最大値は「２０１２０１３１１５３０」であり、次元「温度」の最小値は「１５．４」かつ最大値は「２１．８」であり、次元「湿度」の最小値は「３５」かつ最大値は「６０」である。これらは該多次元直方体を確定する多次元座標空間中の２つの点を表していると考えることができ、従って該ノード（２３２）はこれらの情報を表形式で保持する。同様に、ルートノード（２３１）は、ノード（２３２）およびノード（２３３）を保持しており、これらを包み込む多次元直方体の情報を表形式で保持する。

なおこの際、データエントリに存在しない次元（例えばＥＡ２における「湿度」）があったとしても、それは無視して多次元直方体を算出することに注意されたい。また、ノード（２３３）が保持する情報について、次元「湿度」が記号「φ」となっている。これは、該ノードが保持するデータエントリは全て次元「湿度」を含まない（「値が『φ』である」と表現することにする）ということを意味する。

ここではさらに、従来技術であるＥＡ用ＵＢＩ−Ｔｒｅｅ（１１１）に対する検索動作であるＥＡ検索処理についても示しておく。例として、この木構造に対して、「日時」が「−∞〜＋∞」かつ「湿度」が「０〜４０」なる検索条件で検索を行うとする。
一般に、木構造の検索操作はルートノードからの再帰的処理により規定される。すなわち、まずルートノード（２３１）の保持する情報が該検索条件に合致するかを調べる。この場合には、「日時」という次元に対して両者の値範囲の積集合が空集合ではないことをチェックし、さらに「湿度」という次元に対して両者の値範囲の積集合が空集合でないことをチェックし、両者ともにチェックＯＫとなるため、このノードは該検索条件に合致すると確認できる。
次に、再帰的にノード（２３２）とノード（２３３）を順に、同様に調べる。この場合、ノード（２３２）は該検索条件に合致すると確認できるため、さらに再帰的に、ＥＡ１〜ＥＡ３を順に、同様に調べる。その結果、ＥＡ３のみが該検索条件に合致すると確認できるため、ＥＡ３は少なくとも該検索の結果であることが分かる。なお、ＥＡ２は「湿度」という次元を含まないため、検索には合致しない。
次に再帰的処理として、ノード（２３３）を調べることになるが、このノードは「湿度」という次元を含まない（値が「φ」である）ため、検索には合致しない。よって、ノード（２３３）が保持するＥＡ４〜ＥＡ５については再帰的に確認する必要はなく、この枝についてはここで検索処理を打ち切りしてよい。
以上述べた再帰的処理の結果として、検索結果ＥＡ３を得る。なお、ＵＢＩ−Ｔｒｅｅに対するこのような基本的処理は、データエントリの挿入操作なども含めて、特許文献２および特許文献３に詳細に開示されており実施方法は明らかである。

第４図はＥＡとＥＦのマッチング規則を示す。本図は、上記述べた、データ値すなわちＥＡと検索式すなわちＥＦとの間の合致するしないに関する判定規則のうち、特に次元が存在しない場合の扱いに着目して表形式に整理したものである。ＥＦ内に存在する次元については（囲み符号２４１）、ＥＡに存在しない場合は合致しない（ｒｅｊｅｃｔ）であり、存在する場合には両者の値範囲の積集合が空集合でないことをチェックする。一方、ＥＦ内に存在しない次元については、ＥＡに存在してもしなくても構わない。このような判断をＥＦ内に存在するすべての次元に対して行い、全てＯＫの場合のみ、ＥＡとＥＦ全体のマッチングが「合致」と判定される。また上記述べたように、再帰的な検索処理の途中でｒｅｊｅｃｔがあった場合、その下に保持されるノードおよびデータエントリは全てｒｅｊｅｃｔであることは明らかであるから、従来技術であるＥＡ用ＵＢＩ−Ｔｒｅｅ（１１１）に対する検索動作に関しては、再帰的検索処理を打ち切りしてよい。

第５図はＥＦ用ＵＢＩ−Ｔｒｅｅ（１１３）が保持するＥＦの一覧を示す。ここでは、以下に順次示していくＥＦ登録処理に先立って、（２５１）〜（２５４）の４個のＥＦすなわち検索式が既にｕＴｕｐｌｅＳｐａｃｅに登録されているものと仮定する。なお、これらのＥＦの表す意味は、例えばＥＦ１（２５１）であれば、「登録日時が−∞〜＋∞、湿度が４０％〜１００％」という条件であることを示す。

第６図はＥＦ用ＵＢＩ−Ｔｒｅｅ（１１３）の構造を示す。この木構造は、第５図で示した４個のＥＦを保持しつつ索引を管理している。ここでのポイントは、ＵＢＩ−Ｔｒｅｅに登録するデータエントリとして、（ＥＡ用ＵＢＩ−Ｔｒｅｅ（１１１）が値を登録していたのとは異なり）値範囲を登録しているところである。特許文献２に開示されているように、ＵＢＩ−Ｔｒｅｅは値だけでなく値範囲もデータエントリとして登録することを可能とするアルゴリズムであり、このようなデータエントリに対する一連の木構造の基本的処理は明らかである。このＥＦ用ＵＢＩ−Ｔｒｅｅ（１１３）に対する挿入操作は、従来技術のＵＢＩ−Ｔｒｅｅの動作そのままである。一方、検索操作は、本実施の形態の後半で詳細に示す、特徴的な動作を行う。

第７図はＩＰアドレス表（１１４）の内容を示す。これは、ｕＴｕｐｌｅＳｐａｃｅに登録されているそれぞれのＥＦが、どの検索表示装置から登録されたものかを記録している。もし、登録されたＥＦにマッチする新たなＥＡがｕＴｕｐｌｅＳｐａｃｅに登録された場合、このＩＰアドレス表（１１４）に記されたホストに対して該ＥＡが返却されることを表す。ここでは全てのＥＦが、検索表示装置（１０３）のＩＰアドレス「１９２．１６８．０．３」から登録されたことを表している。

情報蓄積検索装置（１０１）はＥＦの登録要求およびＥＡの登録要求を受け付け、下記に詳述する動作を行う。ＥＦの登録要求があったときにＥＦ登録処理を行う。該ＥＦ登録処理の中ではＥＡ検索処理（ＥＡの検索操作）と検索式蓄積手順としてＥＦを挿入する操作とを行う。ＥＡの登録要求があったときにＥＡ登録処理を行う。該ＥＡ登録処理の中では検索式検索手順としてＥＦ検索処理（ＥＦの検索操作）とデータ値蓄積手順としてＥＡを挿入する操作とを行う。これら登録要求はいずれが先に要求されてもよく、ＥＦ登録処理の次にＥＡ登録処理を行ってもよいし、ＥＡ登録処理の次にＥＦ登録処理を行ってもよい。

まず、段落００３３〜００３９では、一連のＥＦ登録処理について示す。
第８図は新たに登録するＥＦの内容を示す。該ＥＦの中でも特に、次元「日時」の値範囲「−∞〜＋∞」は、過去に蓄積された全てのＥＡを検索対象として蓄積型検索を行い、かつ、該ＥＦを蓄積しておき将来登録されるＥＡに対して検索を行う待ち受け型検索を同時に行うことを表している。

検索表示装置（１０３）は該ＥＦの登録要求を、ネットワーク（１０４）経由で情報蓄積検索装置（１０１）に送信する。情報蓄積検索装置（１０１）の要求受付処理部（１１５）が該登録要求を受け付け、次に示す手順で処理を行う。

第９図はＥＦ登録処理の手順を示す。
まず、要求受付処理部（１１５）は、データ値検索手段として、ＥＡ検索処理を行う。例えば、要求受付処理部（１１５）は、ＥＡ用ＵＢＩ−Ｔｒｅｅ（１１１）に対して、該ＥＦを検索条件として、検索操作を行う（手順２９１）。検索操作の詳細は段落００２７に例示した通りであり、検索結果としてＥＡ３を得る。次に、検索結果を要求元である検索表示装置（１０３）に返却する（手順２９２）。
次に、要求受付処理部（１１５）は、検索式蓄積手段として、該ＥＦが待ち受け型検索を行うかどうかを、次元「日時」の終値「＋∞」が現在時刻より大であるかどうか比較することによって、判定する（手順２９３）。ここでは真であるため、要求受付処理部（１１５）は、検索式蓄積手段として、次の処理として、ＥＦ用ＵＢＩ−Ｔｒｅｅ（１１３）に対して該ＥＦを挿入する操作を行う（手順２９４）。既に示したように、この挿入操作は、従来のＵＢＩ−Ｔｒｅｅと何ら変わるところはない。
以上でＥＦ登録処理を終了する。

第１０図はＥＦ登録の結果として検索表示装置（１０３）に返却されるＥＡの一覧を示す。ここでは既に示したように、ＥＡ３の内容が返却される。

第１１図はＥＦ登録処理後のＥＦ用ＵＢＩ−Ｔｒｅｅ（１１３）が保持するＥＦの一覧を示す。手順２９４においてＥＦ用ＵＢＩ−Ｔｒｅｅ（１１３）に登録されたＥＦは、本図におけるＥＦ５（３１５）として、追加で保持される。

第１２図はＥＦ登録処理後のＥＦ用ＵＢＩ−Ｔｒｅｅ（１１３）の構造を示す。ここでは、ＥＦ５がＵＢＩ−Ｔｒｅｅアルゴリズムによって、ノード（３２３）に追加された様子を表している。

第１３図はＥＦ登録処理後のＩＰアドレス表（１１４）の内容を示す。ＥＦ５に対応するホストとして、検索表示装置（１０３）のＩＰアドレス「１９２．１６８．０．３」が追加された様子を表している。これは、もし将来、ＥＦ５にマッチする新たなＥＡがｕＴｕｐｌｅＳｐａｃｅに登録された場合、該ＩＰアドレスに該ＥＡが返却されることを示す。該ＥＡを受け取った検索表示装置（１０３）は、その内容を画面に表示する。

次に、段落００４０〜００４８では、本発明に極めて特有の動作を含む一連のＥＡ登録処理について示す。
第１４図は新たに登録するＥＡの内容を示す。センサ装置（１０２）は、「日時」が「２０１２年１月３１日２１時３０分」に、「温度」が「−１．５度」である値を計測したものとする。該センサ装置（１０２）は該ＥＡの登録要求を、ネットワーク（１０４）経由で情報蓄積検索装置（１０１）に送信する。情報蓄積検索装置（１０１）の要求受付処理部（１１５）が該登録要求を受け付け、次に示す手順で処理を行う。

第１５図はＥＡ登録処理の手順を示す。
まず、要求受付処理部（１１５）は、検索式検索手段として、ＥＦ検索処理を行う。例えば、要求受付処理部（１１５）は、ＥＦ用ＵＢＩ−Ｔｒｅｅ（１１３）に対して、該ＥＡを検索条件として、検索操作を行う（手順３５１）。この際、通常のＵＢＩ−Ｔｒｅｅが木構造のデータエントリとしてデータ値を登録し木構造の検索条件として検索式を用いるのと比較し、該手順においては木構造のデータエントリとして検索式を登録し木構造の検索条件としてデータ値を用いるということに注意されたい。具体的な手順は次の通りである。

基本的な検索操作は従来のＵＢＩ−Ｔｒｅｅに倣う。すなわち、まずルートノード（３２１）の保持する情報が該検索条件に合致するかを調べる。この場合には、「日時」という次元に対して両者の値範囲の積集合が空集合ではないことをチェックし、さらに「温度」という次元に対して両者の値範囲の積集合が空集合でないことをチェックし、両者ともにチェックＯＫとなるため、このノードは該検索条件に合致すると確認できる。
次に、再帰的にノード（３２２）とノード（３２３）を順に、同様に調べる。この場合、ノード（３２２）は、「日時」という次元に対して両者の値範囲の積集合が空集合ではないことはチェックしＯＫとなるが、「温度」という次元は持っておらず、これをチェックＯＫとして扱う。その結果、ノード（３２２）は該検索条件に合致すると確認できるため、さらに再帰的に、ＥＦ１〜ＥＦ２を順に調べる。これらは中間ノードではなくデータエントリであるため、既に示した本来のＥＡとＥＦとの間のマッチング規則に従って判定を行い、その結果、ＥＦ２のみが該検索条件に合致すると確認できるため、ＥＦ２は少なくとも該検索の結果であることが分かる。
次に再帰的処理として、ノード（３２３）を調べ、「日時」という次元に対しても「温度」という次元に対してもチェックＯＫとなる。その結果、ノード（３２３）は該検索条件に合致すると確認できるため、さらに再帰的に、ＥＦ３〜ＥＦ５を順に調べる。先に述べた場合と同様に、これらはデータエントリであるため本来のマッチング規則に従って判定を行い、その結果、ＥＦ４のみが該検索条件に合致すると確認できるため、ＥＦ４は少なくとも該検索の結果であることが分かる。以上述べた再帰的処理の結果として、要求受付処理部（１１５）は、検索結果ＥＦ２とＥＦ４を得る。

以上の規則を、第４図に示したＥＡとＥＦのマッチング規則で再度確認する。ＥＡ内に存在する次元については（囲み符号２４２）、ＥＦ内に含まなくてもＯＫであることから、再帰的処理の途中でｒｅｊｅｃｔ判定にならないことが分かる。従って、既に示した従来技術におけるＥＡ用ＵＢＩ−Ｔｒｅｅ（１１１）に対する検索操作とは異なり、再帰的処理を途中で打ち切ることができないことに注意されたい。

このことはノード（３２２）とＥＦ２の例で考えると分かりやすい。ＥＦ２は「日時＝２０１２年１月３１日２０時００分〜２２時００分」を満たす全てのＥＡにマッチするのであるから、当然、現在登録しようとしている第１４図のＥＡにもマッチする。このため該検索処理においては、ノード（３２２）が保持する下位のデータエントリに対する再帰的処理を、省略することができない。このように、ＥＡとＥＦとのマッチング規則の特徴に基づき、ＥＦ用ＵＢＩ−Ｔｒｅｅ（１１３）の検索操作は通常のＵＢＩ−Ｔｒｅｅから上記述べたような若干の処理規則の変更を加えたものとなっている。

該ＥＡ登録処理の手順の続きを示す。
次に、要求受付処理部（１１５）は、検索結果を対応する検索式の登録元に返却する（手順３５２）。この例では、手順３５１によってＥＦ２とＥＦ４が検索結果であることが分かるので、ＩＰアドレス表（１１４）から該ＥＦに対応するＩＰアドレスを検索する。ここではいずれのＥＦに関してもＩＰアドレス「１９２．１６８．０．３」が登録元であることが分かるので、該ＩＰアドレスすなわち検索表示装置（１０３）に対して、該ＥＡの内容をネットワーク（１０４）を経由して返却する。
次に、要求受付処理部（１１５）は、データ値蓄積手段として、ＥＡ用ＵＢＩ−Ｔｒｅｅ（１１１）に対して該ＥＡを挿入する操作を行う（手順３５３）。既に示したように、この挿入操作は、従来のＵＢＩ−Ｔｒｅｅそのものである。以上でＥＡ登録処理を終了する。なお、ＥＦ登録処理の際にはＥＦが待ち受け検索を行う場合と行わない場合があるため判定処理（手順２９３）が必要であったが、ＥＡ登録処理の際には全てのＥＡは蓄積対象となるため判定処理は必要ないことに注意されたい。

第１６図はセンサ装置（１０２）からのＥＡ登録の結果として検索表示装置（１０３）に返却されるＥＡを示す。これは該ＥＡ登録処理の契機となったＥＡ登録要求の内容と同じである。該ＥＡを受け取った検索表示装置（１０３）は、その内容を画面に表示する。

第１７図はＥＡ登録処理後のＥＡ用ＵＢＩ−Ｔｒｅｅ（１１１）が保持するＥＡの一覧を示す。登録されたＥＡは、本図におけるＥＡ６（３７６）として、追加で保持される。

第１８図はＥＡ登録処理後のＥＡ用ＵＢＩ−Ｔｒｅｅ（１１１）の構造を示す。ここでは、ＥＡ６がＵＢＩ−Ｔｒｅｅアルゴリズムによって、ノード（３８３）に追加された様子を表している。なお、このようにして登録されたＥＡが、将来、別のＥＦ登録処理の際に検索対象となることは言うまでもない。

以上で、ＥＡとＥＦに対して、蓄積型検索と待ち受け型検索、すなわちＥＡとＥＦのどちらが先に到着しても正しく動作するｕＴｕｐｌｅＳｐａｃｅのセンサ情報のデータ値に対する一連の処理手順を示した。本発明は、ＥＡとＥＦ間の処理に限らず、ｕＴｕｐｌｅＳｐａｃｅのもう一つの特徴であるコマンド型の通信すなわちＣｏｍｍａｎｄＡｃｔｕａｌ（ＣＡ）とＣｏｍｍａｎｄＦｏｒｍａｌ（ＣＦ）との間の順不同のマッチング処理にもそのまま適用できる。

第１９図はＣＡとＣＦのマッチング規則を示す。この規則を、第４図に示したＥＡとＥＦのマッチング規則と比較すると、まったく同じであることが分かる。ｕＴｕｐｌｅＳｐａｃｅにおけるＣＡとＣＦのマッチング規則は特許文献１に開示されているが、その特徴はどちらに単一の値を記載しどちらに値範囲を記載するかの規則を巧妙に入れ替えている点にある。一方、本発明で特徴的な動作となっている、特定の次元が存在しなかった（「φ」）場合の扱いについて、ＣＡとＣＦ間のマッチング規則には何ら特別な点は無い。このため、以上示した一連の処理手順は、「ＥＡとＥＦ」を「ＣＡとＣＦ」にそのまま読み替えることによって、基本的にそのまま適用可能である。

なお本発明では、データエントリを索引づける木構造としてＵＢＩ−Ｔｒｅｅアルゴリズムを用いた。本発明の範囲はこれに限るものではなく、同時に複数次元の値による範囲検索が可能で（例えばＲ−Ｔｒｅｅやその拡張アルゴリズム等）、かつ、データエントリとして値の範囲を持つエントリを登録可能で（例えばＲ−Ｔｒｅｅの自明な拡張で対応可能）、かつ、次元が存在しない（ある次元の値が「φ」）場合にも対応可能（例えばＲ−Ｔｒｅｅで「φ」を示す特別な数値を登録する等）といった特徴を満たす索引付け技術であれば、同様に適用可能である。一方で、ＵＢＩ−Ｔｒｅｅは上記の条件を満たす上に、取り扱うデータエントリがｕＴｕｐｌｅＳｐａｃｅにおけるｕＴｕｐｌｅ形式の要件と良く一致すること、さらに上記の条件を満たしたデータエントリの蓄積型検索処理が特に効率的に行えることなどから、本実施の形態で例示した手順との相乗効果は顕著である。

なお、本発明のいうセンサ情報とは、本実施の形態に示したセンサ装置によって得られる温度や湿度の情報に限らず、その他次元及び値を少なくとも含む様々な情報も対象とすることができる。具体的に一例を挙げると、電流あるいは電圧値、流体の流量、物質の濃度、明度、騒音、位置、加速度などを含むセンサデバイスが計測した値を取り扱ってよく、またそれに限らず、センサ以外の例えばＷｅｂやインターネットを経由して取得した情報であってもよい。さらに、それら値に加えて、センサの特性や状態、計測日時等を示すメタデータを含む情報であってもよい。

一般にＴｒｅｅ（＝木）データ構造を用いて多数のデータを管理すると、検索速度が向上するというメリットが得られる。木構造による検索速度の向上の本質的な理由は、木構造にデータエントリを挿入する際に、「似たデータが近い部分に寄り集まるように、うまく規則的に入れる先を選択する」という動作を行っていることにある。例えば、最も単純な検索木である２分木アルゴリズムでは、各ノードがデータ値と左右２本の子孫への枝を持ち、左には自身より小さい値が、右には自身より大きい値が入るように、挿入先を決めていく。そうするとできあがるデータ構造は、Ｘ軸だけに着目して左から右に眺めていくと、ちょうど昇順にきれいに並んだ形になる。このように、値が似たデータが近い位置に整理されるため、目的とする値を探す際に、左右どちらの枝をたどれば目標にたどりつけるかが容易かつ高速に決定できる。

本発明におけるＥＡ用ＵＢＩ−ＴｒｅｅおよびＥＦ用ＵＢＩ−Ｔｒｅｅにおいても、基本的な考え方は同様であり、「似た種類の項目を含むデータエントリ」、「項目種類が同じなら、近い値を持つデータエントリ」がある方へと新規データエントリの挿入先を決定するので、似た値が自動的に集まって管理される。従って、検索の際には、どの枝をたどればよいかの候補を絞り込むことができるため、高速な検索が行える。

ここで、ＥＡ用ＵＢＩ−Ｔｒｅｅにおける再帰的処理の打ち切り動作は、検索効率をさらに向上させる工夫ではあるが、再帰的処理の打ち切り動作ができない場合があるＥＦ用ＵＢＩ−Ｔｒｅｅにおいても、上述した本質的な検索高速化のメリットは無くならない。別の言い方をすると、値の範囲が外れているかどうかに基づく打ち切り（枝刈り）の動作は、ＥＡ用／ＥＦ用いずれのＵＢＩ−Ｔｒｅｅであっても問題なく行うことができる。

本発明の装置はコンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通して提供することも可能である。

本発明は情報通信産業に適用することができる。

１０１：情報蓄積検索装置
１０２：センサ装置
１０３：検索表示装置
１０４：ネットワーク
１１１：ＥＡ用ＵＢＩ−Ｔｒｅｅ
１１３：ＥＦ用ＵＢＩ−Ｔｒｅｅ
１１４：ＩＰアドレス表
１１５：要求受付処理部
２３１、２６１、３２１、３８１：ルートノード
２３２、２３３、２６２、２６３、３２２、３２３、３８２、３８３：ノード

Claims (9)

1. 検索式蓄積手段と検索式検索手段とを備える情報蓄積検索装置が、次元及び値を少なくとも含む情報を蓄積し検索する情報蓄積検索方法において、
   前記検索式蓄積手段が、同時に複数次元の値による範囲検索が可能でかつ木構造のデータエントリとして、値の範囲を持つエントリを登録可能な検索式用木構造を用いて、前記情報に含まれる複数の次元の値範囲を少なくとも条件に含む与えられた検索式を蓄積する検索式蓄積手順と、
   前記検索式検索手段が、複数の次元の値または値範囲を少なくとも含む与えられた情報のデータ値を木構造の検索条件として、該検索式用木構造から該検索条件にマッチする登録されたエントリ群を検索する検索式検索手順と、
   を順に実行することを特徴とする情報蓄積検索方法。
2. 請求項１に記載の情報蓄積検索方法であって、
   前記情報蓄積検索装置は、データ値蓄積手段とデータ値検索手段とをさらに備え、
   前記情報蓄積検索装置が、前記情報のデータ値の登録要求を受け付けると、
   前記検索式検索手段が、該データ値に対して前記検索式検索手順を行うことによって前記検索式用木構造から検索式を検索するとともに、
   前記データ値蓄積手段が、同時に複数次元の値による範囲検索が可能なデータ値用木構造に、該データ値を蓄積し、
   前記情報蓄積検索装置が、検索式の登録要求を受け付けると、
   前記データ値検索手段が、登録要求のあった検索式にマッチするデータ値を、該データ値用木構造から検索するとともに、
   前記検索式蓄積手段が、前記検索式蓄積手順において、該検索式を前記検索式用木構造に蓄積する
   ことを特徴とする情報蓄積検索方法。
3. 請求項１又は２に記載の情報蓄積検索方法であって、
   前記検索式検索手順におけるマッチするか否かの判定には、
   判定対象の該登録されたエントリが含む全ての次元が判定対象の該検索式用木構造の検索条件にも全て含まれており、かつ、
   両者の該次元の値範囲と値範囲の積集合が空集合とならないことを少なくとも条件とすることを特徴とする情報蓄積検索方法。
4. 請求項１から３のいずれかに記載の情報蓄積検索方法であって、
   前記検索式用木構造は、ＵＢＩ−Ｔｒｅｅアルゴリズムであることを特徴とする情報蓄積検索方法。
5. 次元及び値を少なくとも含む情報を蓄積し検索する情報蓄積検索装置であって、
   同時に複数次元の値による範囲検索が可能でかつ木構造のデータエントリとして、値の範囲を持つエントリを登録可能な検索式用木構造を用いて、前記情報に含まれる複数の次元の値範囲を少なくとも条件に含む与えられた検索式を蓄積する検索式蓄積手段と、
   複数の次元の値または値範囲を少なくとも含む与えられた情報のデータ値を木構造の検索条件として、該検索式用木構造から該検索条件にマッチする登録されたエントリ群を検索する検索式検索手段と、
   を備えることを特徴とする情報蓄積検索装置。
6. 請求項５に記載の情報蓄積検索装置であって、
   与えられた情報のデータ値を、同時に複数次元の値による範囲検索が可能なデータ値用木構造に蓄積するデータ値蓄積手段と、
   与えられた検索式によってマッチするデータ値を検索するデータ値検索手段と、
   をさらに備え、
   前記情報のデータ値の登録要求を受け付けると、
   該データ値に対して前記検索式検索手段を用いて前記検索式用木構造から検索式を検索するとともに、
   該データ値蓄積手段を用いて該データ値を該データ値用木構造に蓄積し、
   検索式の登録要求を受け付けると、
   該検索式に対して該データ値検索手段を用いて該データ値用木構造からデータ値を検索するとともに、
   前記検索式蓄積手段を用いて該検索式を前記検索式用木構造に蓄積する
   ことを特徴とする情報蓄積検索装置。
7. 請求項５又は６に記載の情報蓄積検索装置であって、
   前記検索式検索手段におけるマッチするか否かの判定には、
   判定対象の該登録されたエントリが含む全ての次元が判定対象の該検索式用木構造の検索条件にも全て含まれており、かつ、
   両者の該次元の値範囲と値範囲の積集合が空集合とならないことを少なくとも条件とすることを特徴とする情報蓄積検索装置。
8. 請求項５から７のいずれかに記載の情報蓄積検索装置であって、
   前記検索式用木構造はＵＢＩ−Ｔｒｅｅアルゴリズムであることを特徴とする情報蓄積検索装置。
9. コンピュータを、請求項５から８のいずれかに記載の
   前記検索式蓄積手段及び前記検索式検索手段
   又は
   前記検索式蓄積手段、前記検索式検索手段、前記データ値蓄積手段及び前記データ値検索手段
   として機能させるための情報蓄積検索プログラム。

Images