(57)【要約】      （修正有）【課題】データ型が決められてなく、かつフィールド名と該フィールド名に対応する値とを含むドキュメントを高速検索可能にする格納技術を提供する。【解決手段】情報処理装置は、データ型が決められてなく、かつフィールド名と該フィールド名に対応する値とを含むドキュメントを取得する取得部と、ドキュメントに記述されたフィールド名を特定するフィールド名特定情報を、ドキュメントにおけるフィールド名の記述順に保持する保持部と、記述順と、該記述順に応じて特定されるドキュメントのタイプ情報とを関係付けた記述順タイプ関係情報を生成する生成部と、記述順に保持されたフィールド名特定情報に対応するフィールド名に対応する値とを関係づけたタイプ‐値関係情報を格納領域に格納する格納制御部と、を備える。【選択図】図４
2019003501.tif 000002
【特許請求の範囲】
【請求項１】
データ型が決められてなく、かつフィールド名と該フィールド名に対応する値とを含むドキュメントを取得する取得部と、
前記ドキュメントに記述されたフィールド名を特定するフィールド名特定情報を、前記ドキュメントにおける該フィールド名の記述順に保持する保持部と、
前記記述順と、該記述順に応じて特定される前記ドキュメントのタイプ情報とを関係付けた記述順タイプ関係情報を生成する生成部と、
前記タイプ情報と、前記記述順に保持された前記フィールド名特定情報に対応する前記フィールド名に対応する前記値とを関係づけたタイプ‐値関係情報を格納領域に格納する格納制御部と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記保持部は、第１木構造を用いて前記フィールド名を保持した第１木構造情報に基づいて、該フィールド名から、該フィールド名に対応する前記フィールド名特定情報を取得し、該フィールド名特定情報を、前記ドキュメントにおける該フィールド名の記述順に保持し、
前記格納制御部は、第２木構造を用いて前記フィールド名特定情報を前記記述順に保持した第２木構造情報に基づいて、該フィールド名特定情報の該記述順から、該記述順に応じて特定される前記ドキュメントの前記タイプ情報を取得し、前記記述順と該タイプ情報とを関係付けたタイプ‐値関係情報を格納領域に格納する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記情報処理装置は、さらに、
前記取得部により検索条件を取得する場合、前記タイプ情報に基づいて、前記記述順タイプ関係情報と前記タイプ‐値関係情報とを関係付け、関係づけた前記記述順タイプ関係情報と前記タイプ‐値関係情報から該検索条件に含まれるフィールド名に対応する値が該条件を満たすか否かに基づいて、検索を行う検索部
を備えることを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
コンピュータが、
データ型が決められてなく、かつフィールド名と該フィールド名に対応する値とを含むドキュメントを取得し、
前記ドキュメントに記述されたフィールド名を特定するフィールド名特定情報を、前記ドキュメントにおける該フィールド名の記述順に保持し、
前記記述順と、該記述順に応じて特定される前記ドキュメントのタイプ情報とを関係付けた記述順タイプ関係情報を生成し、
前記タイプ情報と、前記記述順に保持された前記フィールド名特定情報に対応する前記フィールド名に対応する前記値とを関係づけたタイプ‐値関係情報を格納領域に格納する、
ことを特徴とする情報処理方法。
【請求項５】
コンピュータに、
データ型が決められてなく、かつフィールド名と該フィールド名に対応する値とを含むドキュメントを取得し、
前記ドキュメントに記述されたフィールド名を特定するフィールド名特定情報を、前記ドキュメントにおける該フィールド名の記述順に保持し、
前記記述順と、該記述順に応じて特定される前記ドキュメントのタイプ情報とを関係付けた記述順タイプ関係情報を生成し、
前記タイプ情報と、前記記述順に保持された前記フィールド名特定情報に対応する前記フィールド名に対応する前記値とを関係づけたタイプ‐値関係情報を格納領域に格納する、
処理を実行させる制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法、及びプログラムに関する。
【背景技術】
【０００２】
コンピュータ上や情報通信網上で取り扱われるデータを効率よく利用するための仕組みとしてデータベース（ＤＢ）が存在し、そのＤＢを管理するシステムとしてデータベース管理システム（ＤＢＭＳ）が存在する。
【０００３】
ＤＢには、データを２次元のテーブル形式で格納し、必要に応じてテーブルを結合させることができるリレーショナルＤＢ（ＲＤＢ）及びその管理システム（ＲＤＢＭＳ）がある。
【０００４】
しかし、近年、取り扱われるデータ量の増加、レスポンス速度、データの多様化等により、利用環境や利用条件に応じて、ＲＤＢＭＳ以外のＤＢＭＳ、いわゆるＮｏＳＱＬ（Ｎｏt  Ｏｎｌｙ  ＳＱＬ）も利用されることが多くなってきている。ＮｏＳＱＬデータベースの１つに、ドキュメントＤＢと呼ばれるデータベースが存在する。
【０００５】
ドキュメントＤＢでは、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ）やＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）等の記述形式で記述されたデータが格納される。ドキュメントＤＢの一例として、ＭｏｎｇｏＤＢ やＭａｒｋＬｏｇｉｃのようなドキュメントＤＢがある。
【０００６】
ＸＭＬ形式等の所定の形式の文書を構成する個々の論理的な構造要素を識別できる文書（構造化文書）を格納し、格納した文書を検索する技術に関して、例えば、次の技術がある。
【０００７】
第１技術として、１件の文書が複数の論理構造で構成される構造化文書を検索する構造化文書検索システムがある（例えば、特許文献１）。第１の技術では、検索時に一括して参照される可能性の高い文字列データに所定のインデックスグループ識別子を付与して文書登録がされる。それから、インデックスグループ識別子の等しいインデックスデータを用いて文書検索が行われる。これにより、目的とする論理構造だけを対象に指定する構造指定検索を高速に実現することができる。
【０００８】
第２技術として、ＸＭＬ文書にインデックス付けする技術がある（例えば、特許文献２）。
【０００９】
第３技術として、バイナリ形式の構造化文書に対する検索処理技術がある。第３技術では、検索式変換部は、構造化文書に対する検索式を構成するそれぞれのノードを、ボキャブラリ一覧表を用いて対応するインデックスに変換することで、この検索式を変換する。文書解析部は、構造化文書を構成するそれぞれのノードに対応するインデックスを、ボキャブラリ一覧表を用いて特定する。検索式評価部は、変換後の検索式に該当する構造化文書中の一部を、変換後の検索式中に記されているそれぞれのインデックスと、文書解析部が特定したそれぞれのノードに対応するインデックスと、を用いて検索する。これにより、バイナリ形式の構造化文書に対するより高速な検索処理を実現することができる。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２０００−３３６６号公報
【特許文献２】特表２００７−５３３００８号公報
【特許文献３】特開２０１０−２５０４４９号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
ＲＤＢＭＳでは、テーブルの構造（列の名前やデータ型）を「スキーマ」と呼ぶことがある。ＲＤＢＭＳでは、データをテーブルに挿入（格納）する前にスキーマが定義されている。
【００１２】
一方、ドキュメントＤＢでは、データをＤＢに挿入する前に事前のスキーマの定義を必要とせず、ＪＳＯＮ形式やＸＭＬ形式等の文書データをＤＢに挿入することができる。例えば、ＭｏｎｇｏＤＢでは、以下のプログラム１のようなＪＳＯＮ形式のデータ（ＭｏｎｇｏＤＢでは「ドキュメント」と呼ぶ）をコレクションに挿入する。
【００１３】
たとえば、以下のプログラム１は、４つのドキュメントを含んでいる。ここで、以下のプログラムにおいて、１ドキュメントは、１対の“｛”と“｝”で囲まれた範囲で示される。これらの４つのプログラムは、「ｎａｍｅ」フィールドが共通だということを除けば、他のフィールドはドキュメントによって形式がバラバラである。但し、１番目と４番目のドキュメントは、同一形式である。
プログラム１
{
"name": "Horny",
"date": "1992-02-13",
"gender": "m",
"weight": 600
},
{
"name": ”SO43659”,
"date": ”2011-05-31”,
"account": “AWS29825”,
"price": 59.99,
"tags": “Sales”
},
{
"name": "sue",
"age": 26,
"status": "A",
"groups": "news"
},
{
"name": "Aurora",
"date": "1991-01-24",
"gender": "f",
"weight": 450
},
一方、ＭｏｎｇｏＤＢでは、検索時にはフィールドを指定して検索が行われる。例えば「nameフィールドが"Merry"でdateフィールドが2015年から2016年のドキュメント」のように指定するが、ＭｏｎｇｏＤＢは、各ドキュメントを解析（パース）してどのようなフィールドが入っているか確認しながら検索する。そのため、最初から各カラムが決まったスキーマで格納されているＲＤＢＭＳと比較して、ＭｏｎｇｏＤＢの処理速度は、低速である。
【００１４】
本発明は、１つの側面では、データ型が決められてなく、かつフィールド名と該フィールド名に対応する値とを含むドキュメントを高速検索可能にする格納技術を提供する。
【課題を解決するための手段】
【００１５】
本願の開示する情報処理装置は、１つの態様において、取得部、保持部、生成部、格納制御部を含む。取得部は、データ型が決められてなく、かつフィールド名とフィールド名に対応する値とを含むドキュメントを取得する保持部は、ドキュメントに記述されたフィールド名を特定するフィールド名特定情報を、ドキュメントにおけるフィールド名の記述順に保持する。生成部は、記述順と、記述順に応じて特定されるドキュメントのタイプ情報とを関係付けた記述順タイプ関係情報を生成する。格納制御部は、タイプ情報と、記述順に保持されたフィールド名特定情報に対応するフィールド名に対応する値とを関係づけたタイプ‐値関係情報を格納領域に格納する。
【００１６】
本願の開示する情報処理方法は、１つの態様において、コンピュータが、次の処理を行う。すなわち、コンピュータは、データ型が決められてなく、かつフィールド名とフィールド名に対応する値とを含むドキュメントを取得する。コンピュータは、ドキュメントに記述されたフィールド名を特定するフィールド名特定情報を、ドキュメントにおけるフィールド名の記述順に保持する。コンピュータは、記述順と、記述順に応じて特定されるドキュメントのタイプ情報とを関係付けた記述順タイプ関係情報を生成する。コンピュータは、タイプ情報と記述順に保持されたフィールド名特定情報に対応するフィールド名に対応する値とを関係づけたタイプ‐値関係情報を格納領域に格納する。
【００１７】
本願の開示するプログラムは、１つの態様において、コンピュータが、次の処理を行う。すなわち、コンピュータは、データ型が決められてなく、かつフィールド名とフィールド名に対応する値とを含むドキュメントを取得する。コンピュータは、ドキュメントに記述されたフィールド名を特定するフィールド名特定情報を、ドキュメントにおけるフィールド名の記述順に保持する。コンピュータは、記述順と、記述順に応じて特定されるドキュメントのタイプ情報とを関係付けた記述順タイプ関係情報を生成する。コンピュータは、タイプ情報と記述順に保持されたフィールド名特定情報に対応するフィールド名に対応する値とを関係づけたタイプ‐値関係情報を格納領域に格納する。
【発明の効果】
【００１８】
本発明によれば、１つの側面では、データ型が決められてなく、かつフィールド名と該フィールド名に対応する値とを含むドキュメントを高速検索可能なように格納することができる。
【図面の簡単な説明】
【００１９】
【図１】単純なＪＳＯＮデータの格納方法を説明するための図である。
【図２】ＢＳＯＮ形式によるＪＳＯＮデータの格納方法を説明するための図である。
【図３】図３（Ａ）は図１の方法により格納されたデータの読み出し方法を説明するための図であり、図３（Ｂ）は図２の方法により格納されたデータの読み出し方法を説明するための図である。
【図４】本実施形態における情報処理装置の一例を示す。
【図５】本実施形態における情報処理装置のブロック図を示す。
【図６】本実施形態で用いるプログラムＰの一例を示す。
【図７】本実施形態におけるストア領域に格納されたドキュメントの一例を示す。
【図８】本実施形態におけるフィールドＩＤ管理ツリーの一例を示す。
【図９】本実施形態におけるフィールド名管理テーブルの一例を示す。
【図１０】本実施形態におけるタイプＩＤ管理ツリーの一例を示す。
【図１１】本実施形態におけるタイプ管理テーブルの一例を示す。
【図１２】本実施形態におけるＪＳＯＮからフィールドＩＤを、ＪＳＯＮでの記述順に格納したフィールドＩＤ配列の生成について説明するための図である。
【図１３Ａ】本実施形態におけるＪＳＯＮに基づくコレクションへのドキュメントの挿入のフローチャート（その１）である。
【図１３Ｂ】本実施形態におけるＪＳＯＮに基づくコレクションへのドキュメントの挿入のフローチャート（その２）である。
【図１４】図１３Ａ及び図１３Ｂにおいて用いられるデータである。
【図１５】本実施形態におけるドキュメントの検索処理のフローチャートである。
【図１６】本実施形態を用いた場合の指定のフィールド値の取得方法について説明する図である。
【図１７】本実施形態におけるプログラムを実行するコンピュータのハードウェア構成の一例を示す。
【発明を実施するための形態】
【００２０】
検索性能を向上させるために、ドキュメント挿入時に構造を解析し、同一フィールドをまとめたり、インデックスを張ったりすることもある。この場合は検索が高速化されるが、挿入速度は低下する。
（ｉ）例えば、ＪＳＯＮ格納方法としてもっとも単純なのは、ＪＳＯＮを文字列としてそのまま格納する方法である。但し，ＪＳＯＮを構成する文字列のうち余分な空白は削除する。ＭｏｎｇｏＤＢでは、プログラムＡ１をそのまま格納すると、ストレージやメモリ中のデータは図１の形式で保存される。
【００２１】
プログラムＡ１
{
"name: "Horny",
"date": "1992-02-13",
"gender": "m",
"weight": 600
},
【００２２】
このように、ＪＳＯＮ形式のドキュメントの挿入は、前のＪＳＯＮの後に追記してゆく。入力データをＪＳＯＮに記述するだけなので高速である。
【００２３】
そして、検索の際には、格納したドキュメントについて、特定のフィールド名を指定して、フィールド値を取り出す操作になる。この場合、ＪＳＯＮの格納されたデータを先頭から順に読んでゆく。例えば、特定のフィールド名「"gender"」のフィールド値を取り出す場合、図３（Ａ）に示すように、ＪＳＯＮデータを先頭から順次読み出していく。そのため、検索に時間がかかり、検索速度は低速である。
（ｉｉ）次に、ＢＳＯＮ形式で格納する場合を述べる。ＭｏｎｇｏＤＢの格納形式では、ＢＳＯＮ（バイナリ型ＪＳＯＮ）形式で記述される。例えば、プログラムＡ１をＢＳＯＮ形式で格納すると図２の形式で保存される。
【００２４】
図２は、ＢＳＯＮ形式によるＪＳＯＮデータの格納方法を説明するための図である。符号１に示すように、ＢＳＯＮの先頭４バイトに整数値で、ＢＳＯＮ全体のバイト長が保存される。符号９に示すように、ＢＳＯＮの最後はＮＵＬＬ終端文字(「￥０」で表現)で終わる。
【００２５】
ＢＳＯＮ内の各フィールドは、フィールド名（符号３）及びフィールド名のデータ型（符号２）と、フィールド値（符号５）及びフィールド値のデータ長（符号４）とを含む。
【００２６】
フィールド名のデータ型が文字列なら“２”が設定される（符号２）。フィールド名のデータ型が４バイト整数なら“１６”が設定される（符号２”）。フィールド名（符号３）には、ＮＵＬＬが終端に付与されたフィールド名が設定される。
【００２７】
フィールド値は、指定したデータ型（符号２）によって異なる。符号２’で示すように、データ型＝文字列（２）であるなら、フィールド値には最初に文字列の長さが４バイト整数で格納され、その後にＮＵＬＬ終端文字列が入る。フィールド値のデータ長には格納したデータ長が入る。符号２”で示すように、データ型＝整数型（１６）なら、４バイト整数がそのまま格納される。フィールド値のデータ長には格納したデータ長が入る。
【００２８】
このようにＢＳＯＮ格納方式では、ＪＳＯＮを解析して図２のようなＢＳＯＮに構築するので、ＪＳＯＮをそのまま格納するよりも時間がかかり、処理速度は低下する。
【００２９】
そして、検索の際には、格納したドキュメントについて、特定のフィールド名を指定して、フィールド値を取り出す操作になる。ＢＳＯＮ形式の場合、フィールドが予め区切られているので、フィールド単位で読み飛ばして検索ができる。例えば、図３（Ｂ）に示すように、特定のフィールド名「"gender"」のフィールド値を取り出す場合、フィールド単位で読み飛ばして検索がされる。そのため、ＪＳＯＮ形式よりも検索時間が短縮されるが、それでも、先頭からフィールド名を順次読み込んでいく必要がある。
【００３０】
このように、ＭｏｎｇｏＤＢはＢＳＯＮと呼ばれるＪＳＯＮをパースした構造化データ形式となっていたが、フィールド名は文字列格納されており、文字比較によりマッチングが必要であった。ＭｅｓｓａｇｅＰａｃｋもＭｏｎｇｏＤＢと同様である。
【００３１】
また、ＯｒａｃｌｅのＪＳＯＮでは、フィールド名からフィールドＩＤへのマッチングは行っているが、ＪＳＯＮ全体のタイプ構造を識別していない。
【００３２】
そこで、本実施形態では、データ型が決められてなく、かつフィールド名と該フィールド名に対応する値とを含むドキュメントを高速検索可能にする格納技術を提供する。
【００３３】
図４は、本実施形態における情報処理装置の一例を示す。情報処理装置１１は、取得部１２、保持部１３、生成部１４、格納制御部１５を含む。
【００３４】
取得部１２は、データ型が決められてなく、かつフィールド名と該フィールド名に対応する値とを含むドキュメントを取得する。取得部２の一例として、後述する取得部２３、Ｓ１の処理が挙げられる。
【００３５】
保持部１３は、ドキュメントに記述されたフィールド名を特定するフィールド名特定情報を、ドキュメントにおけるフィールド名の記述順に保持する。保持部１３の一例として、後述する格納検索制御部２４、Ｓ９の処理が挙げられる。
【００３６】
生成部１４は、記述順と、記述順に応じて特定されるドキュメントのタイプ情報とを関係付けた記述順タイプ関係情報を生成する。生成部１４の一例として、後述する格納検索制御部２４、Ｓ１０〜Ｓ１３の処理が挙げられる。記述順タイプ関係情報の一例として、後述するタイプ管理テーブル３２が挙げられる。
【００３７】
格納制御部１５は、タイプ情報と、記述順に保持されたフィールド名特定情報に対応するフィールド名に対応する値とを関係づけたタイプ‐値関係情報を格納領域に格納する。格納制御部１５の一例として、後述する格納検索制御部２４、Ｓ１４〜Ｓ１５の処理が挙げられる。タイプ‐値関係情報の一例として、後述するストア領域２８に格納されるドキュメントが挙げられる。
【００３８】
保持部１３は、第１木構造を用いてフィールド名を保持した第１木構造情報に基づいて、該フィールド名から、フィールド名に対応するフィールド名特定情報を取得する。保持部１３は、フィールド名特定情報を、ドキュメントにおけるフィールド名の記述順に保持する。
【００３９】
格納制御部１５は、第２木構造を用いてフィールド名特定情報を記述順に保持した第２木構造情報に基づいて、フィールド名特定情報の記述順から、記述順に応じて特定されるドキュメントのタイプ情報を取得する。格納制御部１５は、記述順とタイプ情報とを関係付けたタイプ‐値関係情報を格納領域に格納する。
【００４０】
情報処理装置１１は、さらに、検索部１６を含む。検索部１６は、取得部１２により検索条件を取得する場合、タイプ情報に基づいて、記述順タイプ関係情報とタイプ‐値関係情報とを関係付ける。検索部１６は、関係づけた記述順タイプ関係情報とタイプ‐値関係情報から検索条件に含まれるフィールド名に対応する値が条件を満たすか否かに基づいて、検索を行う。検索部１６の一例として、後述する格納検索制御部２４、Ｓ２３〜Ｓ３０の処理が挙げられる。
【００４１】
このように構成することにより、データ型が決められてなく、かつフィールド名と該フィールド名に対応する値とを含むドキュメントを高速検索可能に格納することができる。すなわち、スキームレス型文書から、文書を構成する構成要素（メタ情報）と、各構成要素に対応する値とを分離させ、効率的な検索ができる形式でメタ情報を管理・保存することにより、検索速度を向上させることができる。
【００４２】
以下に本実施形態の詳細を説明する。
ここで、スキーマの定義を述べる。ＲＤＢＭＳの「スキーマ」は、テーブル定義コマンドで列形式の定義を指すものとする。ＲＤＢＭＳの1つであるＰｏｓｔｇｒｅＳＱＬの場合、テーブル定義はプログラム2のようなCREATE TABLEコマンドで行うが、これが「スキーマ」となる。
【００４３】
（プログラム 2）
CREATE TABLE tablename (
name TEXT,
date DATE,
gender CHAR(1),
weight INTGER
):
【００４４】
ＪＳＯＮ形式のドキュメントの「スキーマ」は、フィールドの名前だけを残した構造を指すものとする。プログラム３のＪＳＯＮ形式のドキュメントがあった場合、プログラム ４がそのドキュメントの「スキーマ」となる。
【００４５】
（プログラム３）
{
"name": "Horny",
"date": "1992-02-13",
"gender": "m",
"weight": 600
},
【００４６】
（プログラム４）
{
"name":, 
"date":,
"gender":,
"weight":
},
【００４７】
本実施形態では、スキーマはフィールド名の並び順を意識し、同じフィールド名が含まれていても並び順が異なる場合は別のスキーマとしている。そのためプログラム４とプログラム５は異なるスキーマである。
【００４８】
（プログラム５）
{
"date":,
"name":,
"gender":,
"weight":
},
【００４９】
但し、本実施形態の範囲内でプログラム４とプログラム５を同じスキーマと見なすバリエーションもありえる。
【００５０】
本実施形態では、ドキュメントの挿入速度を犠牲にせずに、高速検索を可能とする技術を提供する。本実施形態では、以下を実現する。
・ドキュメントＤＢへのＪＳＯＮ形式のドキュメントの挿入時にＪＳＯＮのメタ情報を解析し、ＪＳＯＮの構造に対してユニークなＩＤを付ける。これを利用して検索を高速化する。
・ドキュメントＤＢへのＪＳＯＮ形式のドキュメントの挿入時のメタ情報の解析を最適化することで挿入速度の低下を最小化する。
・ＪＳＯＮからメタ情報（フィールド等）を除くことで、格納するデータ量を削減する。これによりストレージへの入出力量を減らして全体性能を高速化する。
【００５１】
図５は、本実施形態における情報処理装置のブロック図を示す。情報処理装置２１は、例えば、コンピュータである。情報処理装置２１は、制御部２２、格納部２７を含む。
【００５２】
制御部２２は、取得部２３、格納検索制御部２４、出力部２５を含む。取得部２３は、要求元から、コマンド及びＪＳＯＮ形式のドキュメント情報を取得する。要求元は、例えば、外部の端末、または内部のプログラムを含む。
【００５３】
格納検索制御部２４は、取得したコマンドに応じて、後述する形式により受信したＪＳＯＮ形式のドキュメント（以下、「ドキュメント」と称する）を格納部２７へ格納する。また、格納検索制御部２４は、取得したコマンドに応じて、後述する形式により格納部２７からドキュメントを読み出す。出力部２５は、取得したコマンドに応じて、格納部２７から読み出されたドキュメントを要求元へ出力する。
【００５４】
ここで、本実施形態では、コレクション毎に以下の構成要素を持つものとする。コレクション毎に出現したフィールド名に対して、ユニークな番号を付与する。そのユニークな番号をフィールドＩＤ（Ｆｉｅｌｄ−ＩＤ）とする。
【００５５】
ＪＳＯＮのデータ構造はその中に含まれているフィールドＩＤの配列だと考えられる。この「フィールドＩＤの配列」に対して出現順にユニークな番号を付与する。そのユニークな番号をタイプＩＤ（Ｔｙｐｅ−ＩＤ）とする。
【００５６】
格納部２７は、ストア領域２８、フィールドＩＤ管理ツリー２９、フィールド名管理テーブル３０、タイプＩＤ管理ツリー３１、タイプ管理テーブル３２を含む。
【００５７】
ストア領域２８は、ドキュメントの主要部分、すなわち、主として、フィールドの値を格納する領域である。
【００５８】
フィールドＩＤ管理ツリー２９は、フィールド名からフィールドＩＤを検索できるツリーデータ構造である。フィールドＩＤ管理ツリー２９は、一例として、トライ木またはプレフィックス木と呼ばれるデータ構造で構成することを想定しているが、これに限定されない。
【００５９】
フィールド名管理テーブル３０は、フィールドＩＤ管理ツリー２９と対となるデータ構造で、フィールドＩＤからフィールド名を取得する場合に用いられる。フィールド名管理テーブル３０は、一例として、配列やＢ木構造で構成することを想定しているが、これに限定されない。
【００６０】
タイプＩＤ管理ツリー３１は、ＪＳＯＮ中に出現するフィールドＩＤの配列からタイプＩＤを検索するデータ構造である。タイプＩＤ管理ツリー３１は、ＪＳＯＮのスキーマを管理する。
【００６１】
タイプ管理テーブル３２は、ＪＳＯＮのスキーマにあたるタイプ毎の情報を管理する領域である。
【００６２】
図６は、本実施形態で用いるプログラムＰの一例を示す。プログラムＰは、上述したプログラム１と同じものなので、その説明を省略する。なお、図６では、プログラムＰには、４つのプログラムが含まれており、それぞれをプログラムＰ１、プログラムＰ２、プログラムＰ３、プログラムＰ４と称する。
【００６３】
図７は、本実施形態におけるストア領域２８に格納されたドキュメントの一例を示す。ストア領域２８には、図６のプログラムＰに含まれるフィールドの値がタイプＩＤ事に格納されている。
【００６４】
図８は、本実施形態におけるフィールドＩＤ管理ツリーの一例を示す。図８において、フィールドＩＤ管理ツリー２９の木構造は、プレフィックス木を想定して記述している。
【００６５】
図９は、本実施形態におけるフィールド名管理テーブルの一例を示す。フィールド名管理テーブル３０は、「フィールドＩＤ」と「フィールド名」の項目を含む。「フィールドＩＤ」は、フィールド名を識別する識別情報である。「フィールド名」には、管理対象となるフィールド名が格納される。
【００６６】
図１０は、本実施形態におけるタイプＩＤ管理ツリーの一例を示す。図１０において、タイプＩＤ管理ツリー３１の木構造は、プレフィックス木を想定して記述している。
【００６７】
図１１は、本実施形態におけるタイプ管理テーブルの一例を示す。タイプ管理テーブル３２は、「タイプＩＤ」３２−１、「フィールド数」３２−２、「フィールド」３２−３の項目を含む。項目「フィールド数」３２−２には、タイプＩＤで特定されるドキュメントを構成するフィールド数が格納される。項目「フィールド」３２−３は、タイプＩＤに対応するドキュメントに含まれるフィールドのフィールドＩＤが配置順３２−４及び昇順３２−５に、その順序に応じて、フィールドＩＤが格納される。
【００６８】
図１２は、本実施形態におけるＪＳＯＮからフィールドＩＤを、ＪＳＯＮでの記述順に格納したフィールドＩＤ配列の生成について説明するための図である。図１２については、後述する。
【００６９】
次に、図６から図１１を用いて、コレクションへのドキュメントの挿入工程について説明する。例えば、取得部２３は、コレクションへのドキュメントの挿入命令と共に、ＪＳＯＮ形式のドキュメント（図６）を取得するとする。
【００７０】
ＪＳＯＮ（図６）の中には複数のフィールドが含まれている。格納検索制御部２４は、ＪＳＯＮ（図６）から各フィールドを抽出してフィールドＩＤ管理ツリー２９を検索し、各フィールド名に対応するフィールドＩＤを取得する。
【００７１】
ＪＳＯＮ中に存在するフィールド名がフィールドＩＤ管理ツリー２９に存在しない場合は、格納検索制御部２４は、フィールドＩＤ管理ツリー２９に新たにそのフィールド名を登録する。ここで、格納検索制御部２４は、新しいフィールドＩＤをその登録するフィールド名に割り振る。同時に、格納検索制御部２４は、フィールドＩＤ管理ツリー２９に新しいフィールド名とフィールドＩＤのペアを登録する。
【００７２】
ここまででＪＳＯＮの各フィールドのフィールドＩＤを取得することができる。例えば図１２で示すＪＳＯＮの場合、“name”のフィールドＩＤが“１“、“date”のフィールドＩＤが“７”、“gender”のフィールドＩＤが“５”、“weight”のフィールドＩＤが“４”となる。これらのフィールドＩＤを登場順に並べると［１，７，５，４］の配列となる。これを、フィールドＩＤ配列と称する。
【００７３】
次に、格納検索制御部２４は、得られたフィールドＩＤ配列を用いてタイプＩＤ管理ツリー３１（図１０）を検索して、ＪＳＯＮの構造を示すタイプＩＤを取得する。検索の結果、タイプＩＤ管理ツリー３１にて、得られたフィールドＩＤ配列がヒットしない場合は、その得られたフィールドＩＤ配列は、未登録のＪＳＯＮの構造といえる。そこで、格納検索制御部２４は、その得られたフィールドＩＤ配列に新たにタイプＩＤを付与し、タイプＩＤ管理ツリー３１及びタイプ管理テーブル３２に登録する。
【００７４】
格納検索制御部２４は、タイプ管理テーブル３２の項目「フィールド」の「配置順」には、ドキュメント内のフィールドの出現順にフィールドＩＤを並べて格納する。格納検索制御部２４は、これ以外にフィールドＩＤを正順にソートし、その出現順とペアにしてタイプ管理テーブル３２に格納する。
【００７５】
格納検索制御部２４は、挿入するＪＳＯＮのタイプＩＤが得られたら、図７に示すように、タイプＩＤと共に、出現順のままフィールド値をストア領域２８へ格納する。
【００７６】
図１３Ａ及び図１３Ｂは、本実施形態におけるＪＳＯＮに基づくコレクションへのドキュメントの挿入のフローチャートである。図１４は、図１３Ａ及び図１３Ｂにおいて用いられるデータである。
【００７７】
取得部２３は、要求元から、コマンド及びＪＳＯＮを取得する（Ｓ１）。要求元は、例えば、外部の端末、または内部のプログラムを含む。ＪＳＯＮは、例えば、図１４（Ａ）に示す内容である。
【００７８】
格納検索制御部２４は、取得したコマンドを判別する。取得したコマンドがコレクションへのドキュメントの挿入コマンドであると判定した場合、格納検索制御部２４は、ＪＳＯＮの字句解析（Ｌｅｘｉｃａｌ  Ａｎａｌｙｓｉｓ）を行う（Ｓ２）。ＪＳＯＮの字句解析では、格納検索制御部２４は、ＪＳＯＮを先頭から順に読み取っていき、ＪＳＯＮの文字列をフィールド（名前と値の組）に分割する。字句解析結果として、格納検索制御部２４は、図１４（Ｂ）の内容を得る。字句解析結果には、フィールド名（Ｎａｍｅ）と値（Ｖａｌｕｅ）の組が、読み取り順に格納される。
【００７９】
格納検索制御部２４は、字句解析結果の上位から１フィールドを取得し、これをＦとする（Ｓ３）。格納検索制御部２４は、フィールドＩＤ管理ツリー２９からＦの「Ｎａｍｅ」（フィールド名）を検索する（Ｓ４）。
【００８０】
ＦのＮａｍｅがフィールドＩＤ管理ツリー２９に存在しない場合（Ｓ５で「ＮＯ」）、格納検索制御部２４は、そのＦのＮａｍｅに、新たにフィールドＩＤを割り当てる（Ｓ６）。格納検索制御部２４は、ＦのＮａｍｅと割り当てたフィールドＩＤをフィールドＩＤ管理ツリー２９とフィールド名管理テーブル３０に登録する（Ｓ７）。フィールドＩＤ管理ツリー２９は、例えば、トライ木またはプレフィックス木等のデータ構造で構築される。Ｓ７の処理後、処理はＳ４へ戻る。
【００８１】
Ｆのフィールド名がフィールドＩＤ管理ツリー２９に存在する場合（Ｓ５で「ＹＥＳ」）、格納検索制御部２４は、フィールドＩＤ管理ツリー２９から、その検索されたフィールド名のフィールドＩＤを取得する。格納検索制御部２４は、その取得したフィールドＩＤをＩとして、図１４（Ｃ）に示すように字句解析結果に付与する（Ｓ８）。
【００８２】
格納検索制御部２４は、字句解析結果の上位から順に１行ずつ取得し、字句解析結果に含まれる行数分、Ｓ３〜Ｓ８のループ処理を繰り返す。
【００８３】
格納検索制御部２４は、各フィールドのＩから配列を作成し、その作成した配列をＪとする（Ｓ９）。例えば、図１４（Ｃ）の場合、Ｉは上から「１，７，５，４」である。この場合、図１４（Ｄ）に示すように、Ｊは、［１，７，５，４］で表される。
【００８４】
格納検索制御部２４は、タイプＩＤ管理ツリー３１からＪを検索する（Ｓ１０）。ＪがタイプＩＤ管理ツリー３１に存在しない場合（Ｓ１１で「ＮＯ」）、格納検索制御部２４は、Ｊに新たにタイプＩＤを割り当てる（Ｓ１２）。
【００８５】
格納検索制御部２４は、Ｊと割り当てたタイプＩＤとを、タイプＩＤ管理ツリー３１とタイプ管理テーブル３２に登録する（Ｓ１３）。タイプＩＤ管理ツリー３１は、例えば、プレフィックス木等のデータ構造で構築される。Ｓ１３の処理後、処理はＳ９へ戻る。
【００８６】
ＪがタイプＩＤ管理ツリー３１に存在する場合（Ｓ１０で「ＹＥＳ」）、格納検索制御部２４は、タイプＩＤ管理ツリー３１から、その検索されたＪのタイプＩＤを取得する（Ｓ１４）。
【００８７】
格納検索制御部２４は、ストア領域２８に、ＪＳＯＮを登録する（Ｓ１５）。ここでは、格納検索制御部２４は、ストア領域２８に、取得したタイプＩＤと、Ｊを構成する各Ｉに対応するフィールドの値（Ｖａｌｕｅ）を順に、格納する。
【００８８】
次に、コレクションに含まれるドキュメントの検索工程について説明する。
図１５は、本実施形態におけるドキュメントの検索処理のフローチャートである。一例として、コレクションの中から条件に合致するドキュメントを抽出することを考える。例えば「“ａｇｅ”が２０以上のドキュメントを抽出する」という条件で検索すると想定する。
【００８９】
取得部２３は、要求元から、コマンド及びＪＳＯＮを取得する（Ｓ２１）。要求元は、例えば、外部の端末、または内部のプログラムを含む。ＪＳＯＮには、対象となるフィールド名（以下、「対象フィールド名」と称する）が記述されている。
【００９０】
格納検索制御部２４は、取得したコマンドを判別する。取得したコマンドがフィールドＩＤ管理ツリー２９（フィールド名管理テーブル３０）から対象フィールド名を検索するコマンドであると判定した場合、格納検索制御部２４は、フィールドＩＤ管理ツリー２９（フィールド名管理テーブル３０）から対象フィールド名を検索する（Ｓ２２）。
【００９１】
上記の検索条件の場合、格納検索制御部２４は、フィールドＩＤ管理ツリー２９（図８）（フィールド名管理テーブル３０）からフィールド名“ａｇｅ”を検索し、そのフィールド名に対応するフィールドＩＤを取得する（この場合、“ａｇｅ”のフィールドＩＤは“３”である）。
【００９２】
フィールドＩＤ管理ツリー２９（フィールド名管理テーブル３０）に、対象フィールド名が存在しない場合（Ｓ２２で「ＮＯ」）、フィールドＩＤ管理ツリー２９（フィールド名管理テーブル３０）において、取り出すドキュメントがないので、次の処理を行う。すなわち、格納検索制御部２４は、出力部２５に、検索結果として、フィールドＩＤ管理ツリー２９（フィールド名管理テーブル３０）に対象フィールド名が存在しないことを通知する。出力部２５は、要求元に、検索結果を出力する（Ｓ３１）。
【００９３】
フィールドＩＤ管理ツリー２９（フィールド名管理テーブル３０）に、対象フィールド名が存在する場合（Ｓ２２で「ＹＥＳ」）、格納検索制御部２４は、フィールドＩＤ管理ツリー２９（フィールド名管理テーブル３０）から対象フィールド名のフィールドＩＤを取得し、それをＦとする（Ｓ２３）。
【００９４】
格納検索制御部２４は、ストア領域２８から１行（１ドキュメント）を取得し、これをドキュメントＩとする（Ｓ２４）。
【００９５】
格納検索制御部２４は、ドキュメントＩからタイプＩＤを取り出し、これをＳとする（Ｓ２５）。格納検索制御部２４は、タイプ管理テーブル３２から、タイプＩＤがＳと一致する行（ドキュメント）を取り出し、これをドキュメントＴとする（Ｓ２６）。
【００９６】
タイプ管理テーブル３２の各行（各ドキュメント）には、その行（ドキュメント）に含まれるフィールドがフィールドＩＤ順に並んでいる。格納検索制御部２４は、ドキュメントＴの中のフィールドＩＤに、Ｆが含まれているか否かを検索する（Ｓ２７）。検索は２分探索でもＳＩＭＤ（Single Instruction Multiple Data）命令を用いることもできる。
【００９７】
Ｔの中のフィールドＩＤにＦが含まれない場合（Ｓ２７で「ＮＯ」）、格納検索制御部２４は、ループ処理の先頭の処理（Ｓ２４）を行う。すなわち、その行（ドキュメントＴ）には、「ａｇｅ」というフィールドが含まれていないことが分かる。この場合、格納検索制御部２４は、次のドキュメントを取り出すためにＳ２４の処理に戻る。
【００９８】
Ｔの中のフィールドＩＤにＦが含まれる場合（Ｓ２７で「ＹＥＳ」）、格納検索制御部２４は、Ｉの中のＦを抽出する（Ｓ２８）。この場合、上記の例では、格納検索制御部２４は、そのフィールド「ａｇｅ」の値をストア領域２８から取り出す。
【００９９】
格納検索制御部２４は、検索条件が成立するか否かを判定する（Ｓ２９）。上記の例では、格納検索制御部２４は、ストア領域２８から取り出したフィールド「ａｇｅ」の値と、検索条件（「“ａｇｅ”が２０以上」）とを比較する。
【０１００】
検索条件が成立しない場合（Ｓ２９で「ＮＯ」）、すなわち、ストア領域２８から取り出したフィールドの値が検索条件を満たさない場合、格納検索制御部２４は、次のドキュメントを取り出すために、ループ処理の先頭の処理（Ｓ２４）を行う。
【０１０１】
検索条件が成立する場合（Ｓ２９で「ＹＥＳ」）、すなわち、ストア領域２８から取り出したフィールドの値が検索条件を満たす場合、格納検索制御部２４は、その検索条件を満たすドキュメントを取り出し（Ｓ３０）、作業領域に保存する。具体的には、格納検索制御部２４は、Ｓ２６で取得したタイプ管理テーブル３２の行の中の配置順のフィールドＩＤの並びを取り出し、フィールド名管理テーブル３０を検索してフィールド名を作業領域に出力する。格納検索制御部２４は、同様に、ストア領域２８からフィールドの値を作業領域に出力する。格納検索制御部２４は、全てのフィールドを出力し終えたら、次のドキュメントを取り出すために、Ｓ２４の処理に戻る。
【０１０２】
格納検索制御部２４は、ストア領域の上位から順に１行ずつ取得し、字句解析結果に含まれる行数分、Ｓ２４〜Ｓ３０のループ処理を繰り返す。
【０１０３】
格納検索制御部２４は、出力部２５に、検索結果としてＳ３０で累積的に作業領域に保存したドキュメントを送信する。出力部２５は、要求元に、検索結果を出力する（Ｓ３１）。
【０１０４】
例えば、図６のプログラムＰ１を例にとる。すなわち、格納検索制御部２４は、ストア領域２８から１行目のドキュメントを取り出し、そのドキュメントからタイプＩＤ＝１を取得する。格納検索制御部２４は、タイプ管理テーブル３２から、その取得したタイプＩＤ＝１に対応する行を取得する。
【０１０５】
ここで、タイプ管理テーブル３２から取得した行に登録されたフィールドＩＤ順は、［１，４，５，７］である。したがって、Ｓ２７において、“ａｇｅ”のフィールドＩＤに３は含まれていないことが分かる。この場合、Ｓ２７で「ＮＯ」へ進み、次のドキュメントについてループ処理が実行される。
【０１０６】
次に、例えば、図６のプログラムＰ３を例にとる。この場合、格納検索制御部２４は、ストア領域２８から３行目のドキュメントを取り出し、そのドキュメントからタイプＩＤ＝３を取得する。格納検索制御部２４は、タイプ管理テーブル３２から、その取得したタイプＩＤ＝３に対応する行を取得する。
【０１０７】
ここで、タイプ管理テーブル３２から取得した行に登録されたフィールドＩＤ順は、［１，３，９，１０］である。Ｓ２７において、“ａｇｅ”のフィールドＩＤに３が含まれていることが分かるので、格納検索制御部２４は、Ｓ２８、Ｓ２９の処理を行う。
【０１０８】
ここで、タイプ管理テーブル３２から取得した行に登録されたフィールドＩＤの配置順は［１，３，１０，９］である。格納検索制御部２４は、フィールドＩＤの配置順［１，３，１０，９］に基づいて、フィールド名管理テーブル３０を検索して、対応するフィールド名が“ｎａｍｅ”、“ａｇｅ”、“ｓｔａｔｕｓ”、“ｇｒｏｕｐｓ”であることが分かる。格納検索制御部２４は、ストア領域２８から取り出したフィールドの値と合わせて出力する。
【０１０９】
図１６は、本実施形態を用いた場合の指定のフィールド値の取得方法について説明する図である。例えば、検索においてフィールド“ｇｅｎｄｅｒ”が指定されたとする。このとき、図８に示すように、フィールド“ｇｅｎｄｅｒ”のフィールドＩＤは、“５”である。タイプＩＤ＝１のドキュメントの場合には、タイプ管理テーブル３２を参照すると、第３番目の列に、フィールドＩＤは、“５”が格納されている。これに基づいて、ストア領域２８から、タイプＩＤ＝１のドキュメントについて、フィールドＩＤ＝“５”に対応する値“ｍ”が取り出される。その後は、この値について、検索条件との比較がなされる。
【０１１０】
このように、ＪＳＯＮのスキーマがタイプＩＤで管理されているので、フィールド名からフィールドＩＤを検索した後は数値の比較だけで検索できる。
【０１１１】
このように、ＪＳＯＮを解析して、値を除いたフィールド名及びどのフィールド名を含むかというドキュメントの構造に関する情報（メタ情報）と、フィールドの値とを分離させることができる。そして、検索対象となるフィールドを効率的に検索ができるように、トライ木、プレフィックス木、Ｂ木等の木構造を用いて、メタ情報は管理・保存されている。
【０１１２】
よって、本実施形態を用いることにより、スキームレス型文書を解析してメタ情報をＩＤで管理すると共に、フィールド値と管理して、高速検索可能なようにスキームレス型文書を格納することができる。
【０１１３】
図１７は、本実施形態におけるプログラムを実行するコンピュータのハードウェア構成の一例を示す。情報処理装置は、例えば、コンピュータ４１である。
【０１１４】
コンピュータ４１は、中央演算装置（ＣＰＵ）４２、メモリ４３、ハードディスクドライブ（ＨＤＤ）４４、ネットワークインターフェースカード（ＮＩＣ）４５、入力インターフェース４６及びビデオインターフェース４７を含む。以下、インターフェースを「Ｉ／Ｆ」と称する。
【０１１５】
ＣＰＵ４２、メモリ４３、ＨＤＤ４４、ＮＩＣ４５、入力Ｉ／Ｆ４６及びビデオＩ／Ｆ４７はバス４８によって接続されている。入力Ｉ／Ｆ４６にはキーボードまたはマウス等の入力装置４９が接続されている。ビデオＩ／Ｆ４７には、ディスプレイ５０が接続されている。
【０１１６】
ＣＰＵ４２は、プロセッサの一例であって、コンピュータ４１の全体動作を制御する中央演算装置である。メモリ４３は、ワーキングエリアとして機能する。
【０１１７】
ＨＤＤ４４は、オペレーティングシステム（ＯＳ）や本実施形態に係るプログラムが格納されている大容量記憶装置である。ＨＤＤ４４は、ストア領域２８を含み、フィールドＩＤ管理ツリー２９、フィールド名管理テーブル３０、タイプＩＤ管理ツリー３１、及びタイプ管理テーブル３２を格納する。ＨＤＤ４４は、大容量記憶装置の一例であって、これに限定されず、例えばＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）であってもよい。
【０１１８】
ＮＩＣ４５は、インターネット、ローカルエリアネットワーク（ＬＡＮ）等の通信ネットワークと有線または無線で接続するためのインターフェースである。
【０１１９】
入力Ｉ／Ｆ４６は、入力装置１８から入力された指令をＣＰＵ４２へ伝達するインターフェースである。ビデオＩ／Ｆ４７は、ディスプレイ５０に画像を出力するインターフェースである。
【０１２０】
ＣＰＵ４２は、本実施形態に係るプログラム、すなわちＨＤＤ４４に格納されているドキュメントＤＢに対してドキュメントの格納、検索等を行うプログラムを読み出し、実行する。これにより、ＣＰＵ４２は、取得部２３、格納検索制御部２４、出力部２５として機能する。
【０１２１】
上記実施形態で説明した処理を実現するプログラムは、プログラム提供者側から通信ネットワーク及びＮＩＣ４５を介して、例えば記憶装置ＨＤＤに格納されてもよい。また、上記実施形態で説明した処理を実現するプログラムは、市販され、流通している可搬型記憶媒体に格納されていてもよい。この場合、この可搬型記憶媒体は外付け又は内蔵の読取装置にセットされて、ＣＰＵ４２によってそのプログラムが読み出されて、実行されてもよい。可搬型記憶媒体としてはＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、フレキシブルディスク、光ディスク、光磁気ディスク、ＩＣカード、ＵＳＢメモリ装置など様々な形式の記憶媒体を使用することができる。このような記憶媒体に格納されたプログラムが読取装置によって読み取られる。
【０１２２】
本実施形態によれば、フィールド名を整数値となるフィールドＩＤにマッピングさせ、既にフィールドＩＤ順に並べられたフィールドＩＤ配列から検索することにより、検索処理の高速化を実現することができる。
【０１２３】
また、本実施形態によれば、新しいＪＳＯＮのスキーマが出現しないパターンでの高速化が極力高速に可能なようにしている。例えば、挿入対象のＪＳＯＮを先頭から最後へ一度だけパースすれば、ストア領域に格納するデータが作成可能となっている。これにより、挿入処理のオーバーヘッド削減を実現している。
【０１２４】
なお、本発明は、以上に述べた実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。
【０１２５】
以上の実施の形態に関し、更に以下の付記を開示する。
（付記１）
データ型が決められてなく、かつフィールド名と該フィールド名に対応する値とを含むドキュメントを取得する取得部と、
前記ドキュメントに記述されたフィールド名を特定するフィールド名特定情報を、前記ドキュメントにおける該フィールド名の記述順に保持する保持部と、
前記記述順と、該記述順に応じて特定される前記ドキュメントのタイプ情報とを関係付けた記述順タイプ関係情報を生成する生成部と、
前記タイプ情報と、前記記述順に保持された前記フィールド名特定情報に対応する前記フィールド名に対応する前記値とを関係づけたタイプ‐値関係情報を格納領域に格納する格納制御部と、
を備えることを特徴とする情報処理装置。
（付記２）
前記保持部は、第１木構造を用いて前記フィールド名を保持した第１木構造情報に基づいて、該フィールド名から、該フィールド名に対応する前記フィールド名特定情報を取得し、該フィールド名特定情報を、前記ドキュメントにおける該フィールド名の記述順に保持し、
前記格納制御部は、第２木構造を用いて前記フィールド名特定情報を前記記述順に保持した第２木構造情報に基づいて、該フィールド名特定情報の該記述順から、該記述順に応じて特定される前記ドキュメントの前記タイプ情報を取得し、前記記述順と該タイプ情報とを関係付けたタイプ‐値関係情報を格納領域に格納する
ことを特徴とする付記１に記載の情報処理装置。
（付記３）
前記情報処理装置は、さらに、
前記取得部により検索条件を取得する場合、前記タイプ情報に基づいて、前記記述順タイプ関係情報と前記タイプ‐値関係情報とを関係付け、関係づけた前記記述順タイプ関係情報と前記タイプ‐値関係情報から該検索条件に含まれるフィールド名に対応する値が該条件を満たすか否かに基づいて、検索を行う検索部
を備えることを特徴とする付記１又は２に記載の情報処理装置。
（付記４）
コンピュータが、
データ型が決められてなく、かつフィールド名と該フィールド名に対応する値とを含むドキュメントを取得し、
前記ドキュメントに記述されたフィールド名を特定するフィールド名特定情報を、前記ドキュメントにおける該フィールド名の記述順に保持し、
前記記述順と、該記述順に応じて特定される前記ドキュメントのタイプ情報とを関係付けた記述順タイプ関係情報を生成し、
前記タイプ情報と、前記記述順に保持された前記フィールド名特定情報に対応する前記フィールド名に対応する前記値とを関係づけたタイプ‐値関係情報を格納領域に格納する、
ことを特徴とする情報処理方法。
（付記５）
前記保持において、第１木構造を用いて前記フィールド名を保持した第１木構造情報に基づいて、該フィールド名から、該フィールド名に対応する前記フィールド名特定情報を取得し、該フィールド名特定情報を、前記ドキュメントにおける該フィールド名の記述順に保持し、
前記格納において、第２木構造を用いて前記フィールド名特定情報を前記記述順に保持した第２木構造情報に基づいて、該フィールド名特定情報の該記述順から、該記述順に応じて特定される前記ドキュメントの前記タイプ情報を取得し、前記記述順と該タイプ情報とを関係付けたタイプ‐値関係情報を格納領域に格納する
ことを特徴とする付記４に記載の情報処理方法。
（付記６）
前記情報処理方法は、さらに、
前記検索条件を取得する場合、前記タイプ情報に基づいて、前記記述順タイプ関係情報と前記タイプ‐値関係情報とを関係付け、関係づけた前記記述順タイプ関係情報と前記タイプ‐値関係情報から該検索条件に含まれるフィールド名に対応する値が該条件を満たすか否かに基づいて、検索を行う
ことを特徴とする付記４又は５に記載の情報処理方法。
（付記７）
コンピュータに、
データ型が決められてなく、かつフィールド名と該フィールド名に対応する値とを含むドキュメントを取得し、
前記ドキュメントに記述されたフィールド名を特定するフィールド名特定情報を、前記ドキュメントにおける該フィールド名の記述順に保持し、
前記記述順と、該記述順に応じて特定される前記ドキュメントのタイプ情報とを関係付けた記述順タイプ関係情報を生成し、
前記タイプ情報と、前記記述順に保持された前記フィールド名特定情報に対応する前記フィールド名に対応する前記値とを関係づけたタイプ‐値関係情報を格納領域に格納する、
処理を実行させるプログラム。
（付記８）
前記保持において、第１木構造を用いて前記フィールド名を保持した第１木構造情報に基づいて、該フィールド名から、該フィールド名に対応する前記フィールド名特定情報を取得し、該フィールド名特定情報を、前記ドキュメントにおける該フィールド名の記述順に保持し、
前記格納において、第２木構造を用いて前記フィールド名特定情報を前記記述順に保持した第２木構造情報に基づいて、該フィールド名特定情報の該記述順から、該記述順に応じて特定される前記ドキュメントの前記タイプ情報を取得し、前記記述順と該タイプ情報とを関係付けたタイプ‐値関係情報を格納領域に格納する
ことを特徴とする付記７に記載のプログラム。
（付記９）
前記プログラムは、さらに、
前記検索条件を取得する場合、前記タイプ情報に基づいて、前記記述順タイプ関係情報と前記タイプ‐値関係情報とを関係付け、関係づけた前記記述順タイプ関係情報と前記タイプ‐値関係情報から該検索条件に含まれるフィールド名に対応する値が該条件を満たすか否かに基づいて、検索を行う
ことを特徴とする付記７又は８に記載のプログラム。
【符号の説明】
【０１２６】
１１    情報処理装置
１２    取得部
１３    保持部
１４    生成部
１５    格納制御部
１６    検索部
２１    情報処理装置
２２    制御部
２３    取得部
２４    格納検索制御部
２５    出力部
２７    格納部
２８    ストア領域
２９    フィールドＩＤ管理ツリー
３０    フィールド名管理テーブル
３１    タイプＩＤ管理ツリー
３２    タイプ管理テーブル
【図１】
2019003501.tif 000003
【図２】
2019003501.tif 000004
【図３】
2019003501.tif 000005
【図４】
2019003501.tif 000006
【図５】
2019003501.tif 000007
【図６】
2019003501.tif 000008
【図７】
2019003501.tif 000009
【図８】
2019003501.tif 000010
【図９】
2019003501.tif 000011
【図１０】
2019003501.tif 000012
【図１１】
2019003501.tif 000013
【図１２】
2019003501.tif 000014
【図１３Ａ】
2019003501.tif 000015
【図１３Ｂ】
2019003501.tif 000016
【図１４】
2019003501.tif 000017
【図１５】
2019003501.tif 000018
【図１６】
2019003501.tif 000019
【図１７】
2019003501.tif 000020