(57)【要約】【課題】半構造データの圧縮効率を向上することを目的とする。【解決手段】データ圧縮プログラムは、半構造データに含まれるグループの構造を、グループ内の各データのデータ種類およびデータ型に基づいて特定し、前記構造毎にユニークな第１識別子を設定し、前記構造内の各データの前記データ種類および前記データ型の組に対して第２識別子を設定し、前記グループ内の前記データを、前記グループに対応する前記第１識別子と前記データに対応する前記第２識別子の組毎に異なる記憶領域に格納し、前記記憶領域毎に、前記データを圧縮する処理をコンピュータに実行させる。【選択図】図１８
2019179504.tif 000002
【特許請求の範囲】
【請求項１】
半構造データに含まれるグループの構造を、グループ内の各データのデータ種類およびデータ型に基づいて特定し、
前記構造毎にユニークな第１識別子を設定し、前記構造内の各データの前記データ種類および前記データ型の組に対して第２識別子を設定し、
前記グループ内の前記データを、前記グループに対応する前記第１識別子と前記データに対応する前記第２識別子の組毎に異なる記憶領域に格納し、
前記記憶領域毎に、前記データを圧縮する
処理をコンピュータに実行させるためのデータ圧縮プログラム。
【請求項２】
前記データが配列である場合、前記配列内の要素の数と前記配列内の要素とを異なる記憶領域に格納する
処理を前記コンピュータに実行させることを特徴とする請求項１に記載のデータ圧縮プログラム。
【請求項３】
前記データが配列であり、前記配列内の要素がグループである場合、前記配列内の前記グループに、前記配列と異なる前記第１識別子を設定し、
前記配列内の要素の数と、前記配列内の前記グループに設定された第１識別子と、前記グループ内のデータとを異なる記憶領域に格納する
処理を前記コンピュータに実行させることを特徴とする請求項１または請求項２に記載のデータ圧縮プログラム。
【請求項４】
複数の前記データ種類を階層化した第１ツリーを生成し、
新たな前記グループを取得した場合、取得した前記グループ内のデータ種類を前記第１ツリーの上位から検索し、前記データ種類が前記第１ツリーに存在しない場合、前記データ種類を前記第１ツリーに追加する、
処理を前記コンピュータに実行させることを特徴とする請求項１乃至３のうち何れか１項に記載のデータ圧縮プログラム。
【請求項５】
複数の前記構造を階層化した第２ツリーを生成し、
新たな前記グループを取得した場合、取得した前記グループの構造を前記第２ツリーの上位から検索し、前記構造が前記第２ツリーに存在しない場合、前記構造を前記第２ツリーに追加する、
処理を前記コンピュータに実行させることを特徴とする請求項１乃至４のうち何れか１項に記載のデータ圧縮プログラム。
【請求項６】
コンピュータが、
半構造データに含まれるグループの構造を、グループ内の各データのデータ種類およびデータ型に基づいて特定し、
前記構造毎にユニークな第１識別子を設定し、前記構造内の各データの前記データ種類および前記データ型の組に対して第２識別子を設定し、
前記グループ内の前記データを、前記グループに対応する前記第１識別子と前記データに対応する前記第２識別子の組毎に異なる記憶領域に格納し、
前記記憶領域毎に、前記データを圧縮する
処理を実行することを特徴とするデータ圧縮方法。
【請求項７】
半構造データに含まれるグループの構造を、グループ内の各データのデータ種類およびデータ型に基づいて特定する特定部と、
前記構造毎にユニークな第１識別子を設定し、前記構造内の各データの前記データ種類および前記データ型の組に対して第２識別子を設定する設定部と、
前記グループ内の前記データを、前記グループに対応する前記第１識別子と前記データに対応する前記第２識別子の組毎に異なる記憶領域に格納する格納部と、
前記記憶領域毎に、前記データを圧縮する圧縮部と、
を備えることを特徴とするデータ圧縮装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ圧縮プログラム、データ圧縮方法、およびデータ圧縮装置に関する。
【背景技術】
【０００２】
Relational Database Management System（ＲＤＢＭＳ）のデータを格納する場合、行形式格納または列形式格納が用いられる。一方、JavaScript（登録商標） Object Notation（ＪＳＯＮ）やExtensible Markup Language（ＸＭＬ）などの半構造データを格納するドキュメントＤＢは、通常、行形式格納が用いられる。
【０００３】
関連する技術として、半構造データのスキーマを推論し、累積スキーマを動的に生成し、推論されたスキーマを累積スキーマと併合する技術が提案されている（例えば、特許文献１を参照）。
【０００４】
また、関連する技術として、属性別のデータをファイルに分割して保持し、データ構造をスキーマ情報として保持する技術が提案されている（例えば、特許文献２を参照）。
【０００５】
また、関連する技術として、指定された領域から区切り文字を検出し、検出された区切り文字と構造情報とに基づいて、指定された領域のデータ列を符号化する技術が提案されている（例えば、特許文献３を参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特表２０１５−５０８５２９号公報
【特許文献２】特開２０１１−１３７５８号
【特許文献３】特開２００９−７５８８７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
列形式格納を用いたデータは、行形式格納を用いたデータより、圧縮効率が高い。しかし、半構造データでは、データの追加または変更等により、スキーマが変更される。そのため、列形式格納を用いることは困難であった。
【０００８】
１つの側面として、本発明は、半構造データの圧縮効率を向上することを目的とする。
【課題を解決するための手段】
【０００９】
１つの態様では、データ圧縮プログラムは、半構造データに含まれるグループの構造を、グループ内の各データのデータ種類およびデータ型に基づいて特定し、前記構造毎にユニークな第１識別子を設定し、前記構造内の各データの前記データ種類および前記データ型の組に対して第２識別子を設定し、前記グループ内の前記データを、前記グループに対応する前記第１識別子と前記データに対応する前記第２識別子の組毎に異なる記憶領域に格納し、前記記憶領域毎に、前記データを圧縮する処理をコンピュータに実行させる。
【発明の効果】
【００１０】
１つの側面によれば、半構造データの圧縮効率を向上することができる。
【図面の簡単な説明】
【００１１】
【図１】行形式格納と列形式格納とを模式的に示した図である。
【図２】基本データ型のドキュメントの例を示す図である。
【図３】フィールド値に関する説明を示す図である。
【図４】オブジェクトの入れ子構造を含むドキュメントの例を示す図である。
【図５】配列を含むドキュメントの例を示す図である。
【図６】フィールド定義の例を示す図である。
【図７】スキーマを表すドキュメントの第１の例を示す図である。
【図８】スキーマを表すドキュメントの第２の例を示す図である。
【図９】実施形態のシステム構成の一例を示す図である。
【図１０】実施形態の情報処理装置１の構成の一例を示す図である。
【図１１】実施形態で用いられる各情報を説明する図である。
【図１２】フィールド名／フィールドＩＤツリーの一例を示す図である。
【図１３】フィールドＩＤ／フィールド名テーブルの一例を示す図である。
【図１４】フィールドＩＤ配列の一例を示す図である。
【図１５】フィールドＩＤ配列／スキーマＩＤツリーの一例を示す図である。
【図１６】スキーマ管理テーブルの一例を示す図である。
【図１７】データを格納するファイルの一例を示す図である。
【図１８】データ格納方法の一例を示す図である。
【図１９】オブジェクトの入れ子が存在するドキュメントのフィールド名／フィールドＩＤツリーの一例を示す図である。
【図２０】オブジェクトの入れ子が存在するドキュメントのフィールドＩＤ／フィールド名テーブルの一例を示す図である。
【図２１】オブジェクトの入れ子が存在するドキュメントのスキーマ管理テーブルの一例を示す図である。
【図２２】オブジェクトの入れ子が存在するドキュメントのデータ格納方法の一例を示す図である。
【図２３】配列のデータ型の省略形の一例を示す図である。
【図２４】基本データ型の配列を含むドキュメントの一例を示す図である。
【図２５】基本データ型の配列を含むドキュメントのフィールドＩＤ／フィールド名テーブルの一例を示す図である。
【図２６】基本データ型の配列を含むドキュメントのスキーマ管理テーブルの一例を示す図である。
【図２７】基本データ型の配列を含むドキュメントのデータ格納方法の一例を示す図である。
【図２８】オブジェクト型の配列を含むドキュメントの一例を示す図である。
【図２９】オブジェクト型の配列を含むドキュメントのフィールドＩＤ／フィールド名テーブルの一例を示す図である。
【図３０】オブジェクト型の配列を含むドキュメントのスキーマ管理テーブルの一例を示す図である。
【図３１】オブジェクト型の配列を含むドキュメントのデータ格納方法の一例を示す図である。
【図３２】実施形態の処理の流れの一例を示すフローチャートである。
【図３３】圧縮前処理の一例を示すフローチャートである。
【図３４】第１生成処理の一例を示すフローチャートである。
【図３５】第２生成処理の一例を示すフローチャートである。
【図３６】格納処理の一例を示すフローチャートである。
【図３７】復元処理の一例を示すフローチャートである。
【図３８】展開処理の一例を示すフローチャートである。
【図３９】実施形態の処理に適用するドキュメントの第１の例を示す図である。
【図４０】ドキュメント１０に実施形態の処理を実施した場合の処理例を示す図である。
【図４１】実施形態の処理に適用するドキュメントの第２の例を示す図である。
【図４２】ドキュメント１１に実施形態の格納処理を実施した場合の格納処理例を示す図（その１）である。
【図４３】ドキュメント１１に実施形態の格納処理を実施した場合の格納処理例を示す図（その２）である。
【図４４】システム構成の第１実施例を示す図である。
【図４５】システム構成の第２実施例を示す図である。
【図４６】情報処理装置１のハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【００１２】
例えば、ＲＤＢＭＳでは１件のデータはレコード(record)またはタプル(tuple)と呼ばれる。１件のレコードは「人名」、「生年月日」、「住所」などの複数の属性(attribute)によって構成される。そして、複数のレコードの集合がテーブル(table)またはリレーション(relation)と呼ばれる。ＲＤＢＭＳでは、テーブルに対してレコードの挿入、削除、検索などの操作が実行される。
【００１３】
テーブルは設計上の概念としては「レコードの集合」だが、行と列の２次情報として解釈することも可能である。レコードの属性は列(column)と呼ばれ、各レコードは行(row)と呼ばれる。
【００１４】
図１は、行形式格納と列形式格納とを模式的に示した図である。図１に示す例では、「ＩＤ」、「ｎａｍｅ」、「ｃｉｔｙ」が属性である。図１に示すように、論理テーブルは、行形式格納（N-ary Storage Model（ＮＳＭ）)または列形式格納（Decomposition Storage Model（ＤＳＭ））により格納される。行形式格納では、レコード内の属性がまとめられて１つのストレージに格納される。列形式格納では、属性ごとに分割されてストレージに格納される。
【００１５】
ＲＤＢＭＳでは、通常、データを格納する際に行形式格納が用いられる。ＲＤＢＭＳは、レコードの挿入、削除、更新の性能が重要であり、ストレージ上にレコード単位でデータが並んでいる方がレコードの挿入、削除、更新が容易だからである。
【００１６】
一方、データ分析に用いられるビジネスインテリジェンスおよびデータウェアハウスでは、列形式格納が用いられることが多い。データの分析では、テーブル内の特定の属性のみ読み出されることが多いためである。列形式格納が採用されたデータベースは、列指向データベース(column-oriented database)またはカラムナー(columnar)と呼ばれる。列形式で格納されたデータは圧縮効率が高く、圧縮後のデータ容量が少なくなる。よって、読み出し時のInput/Output（Ｉ／Ｏ）が削減され、性能が向上する。そのため、列指向データベースは、通常、圧縮が行われる。
【００１７】
近年、列指向データベースの需要が高まっており、様々な列指向データベースが開発されている。行形式格納が採用された行指向データベースでも、列指向データベース機能をオプションで追加することが可能な製品が増加している。
【００１８】
列形式格納に適用可能な圧縮技術は、多く存在し、例えば、ラングレングス(Run-length Encoding：ＲＬＥ)圧縮、辞書圧縮（Dictionary Compression）等が用いられている。
【００１９】
ＲＤＭＢＭＳのテーブルの構造（列の名前やデータ型）は、スキーマと呼ばれる。ＲＤＭＢＭＳはデータを挿入する前にスキーマが定義されるデータベースである。一方、データを挿入する前に事前のスキーマを定義せず、ＪＳＯＮ形式やＸＭＬ形式などの半構造データを挿入することが可能なドキュメント型ＤＢと呼ばれるデータベースが存在する。
【００２０】
なお、一部のドキュメントＤＢは、行形式格納されるドキュメントの内部構造を圧縮したデータ形式を用いることで、データ量の削減が行われているが、列指向データベースと比較すると、圧縮効率は十分ではない。
【００２１】
以下、実施形態における半構造データの例について説明する。なお、以下の説明で用いるドキュメントは、ＪＳＯＮ形式の半構造データを含む、本実施形態の処理は、ＸＭＬ形式などのＪＳＯＮ以外の半構造データにも適用可能である。
【００２２】
図２は、基本データ型のドキュメントの例を示す図である。基本データ型のドキュメントとは所定のデータ型のフィールドのみを含み、オブジェクトや配列を含まないドキュメントであるとする。図１の例では、データ内の要素は、"XXXX":"YYYY"という形式で記述される。この形式のデータについて、"XXXX"を、「フィールド名」と称し、"YYYY"を「フィールド値」と称し、「フィールド名」と「フィールド値」との組を「フィールド」と称する。また、図１のように"{"と"}"で囲まれたデータのグループを「オブジェクト」と称する。
【００２３】
ドキュメント１は（１）〜（４）という４つのオブジェクトを含んでいる。（１）と（４）は、同じ構造であり、同じスキーマに従っていると言える。一方、他のオブジェクトは、"name"フィールドを含む点が共通しているが、他のフィールドが異なっており、それぞれ構造が異なる。
【００２４】
図３は、フィールド値に関する説明を示す図である。図３は、JSONにおけるフィールド値の内容、データ型の説明を示しており、本実施形態でも図３に示す例を用いる。省略形は、本実施形態の説明のために定義された記号である。
【００２５】
図３に示すように、「ｔｒｕｅ」は、真偽値のうち真を示すリテラルである。「ｆａｌｓｅ」は、真偽値のうち偽を示すリテラルである。「ｎｕｌｌ」は、フィールド値が存在しないことを示すリテラルである。
【００２６】
「数値」には、０，１，−１のような整数値と、０．１のような少数を適用することができる。「文字列」には、"string"のようにダブルクォーテーションで囲って文字列を記述する事ができる。「オブジェクト」は、{"name1":"value1",name2":"value2"}のように{}で要素が囲われたデータである。{{"name1":{name2":"value2"}}のようにオブジェクトを入れ子にすることも可能である。また、多段（３段以上）の入れ子も可能である。
【００２７】
配列は、[value,value,value]のように、複数の要素が[]で囲われたデータである。配列の要素にはデータ種類を自由に指定できる。同一の配列内の要素が同じデータ型でなくてもよい。配列の要素として配列を使うこともできる。
【００２８】
図４は、オブジェクトの入れ子構造を含むドキュメントの例を示す図である。図４に示すように、ドキュメントがオブジェクトの入れ子構造を含む可能性がある。図４に示すドキュメント２は、フィールド"address"が入れ子構造となっており、フィールド"address"が、"country"、"postnumber"、"prefecture"というサブフィールドを持つ構造となっている。本実施形態では、サブフィールドを指定する場合、"address.prefecture"のように上位のフィールド名と下位のフィールド名を"."で連結する。ドキュメント２における入れ子構造は２段であるが、３段以上の入れ子構造が適用されてもよい。
【００２９】
図５は、配列を含むドキュメントの例を示す図である。ＪＳＯＮでは、図５に示す配列をフィールドに含むことも可能であり、本実施形態でも配列を含むことが可能であるとする。ドキュメント３におけるフィールド"name"は、文字型の配列である。フィールド"address"は、要素としてオブジェクトを含む配列である。以下、要素としてオブジェクトを含む配列をオブジェクト型配列と称することがある。
【００３０】
図６は、フィールド定義の例を示す図である。各フィールドの定義は、ドキュメント内のデータを挿入するデータベースに予め設定される。例えば、本実施形態では、図６のドキュメント４に示す形式のコマンドによりデータベースに対してフィールドの定義が行われる。
【００３１】
図７は、スキーマを表すドキュメントの第１の例を示す図である。図７のドキュメント５は、図２に示すドキュメント１の（１）のスキーマを示す。本実施形態の「スキーマ」は、オブジェクト毎のデータ構造を示し、オブジェクト内の各フィールドの「フィールド名」と「フィールド値のデータ型」との組み合わせに基づいて特定される。なお、「フィールド値のデータ型」は、図３に示す省略形で表現されている。
【００３２】
図８は、スキーマを表すドキュメントの第２の例を示す図である。図７のドキュメント６は、図７のドキュメント５と比較すると、"name":Sと"date":Sの順序が入れ替わっている。本実施形態では、スキーマはフィールド名の並び順を意識し、同じフィールド名が含まれていても並び順が異なる場合は別のスキーマとみなす。ただし、同じフィールド名が含まれていて、並び順が異なるスキーマを同じスキーマとみなしてもよい。すなわち、本実施形態では、図７のドキュメント６は、図７のドキュメント５を異なるスキーマとみなすが、同じスキーマとみなしてもよい。
【００３３】
また本実施形態では、オブジェクト内のいずれかのフィールドのフィールド名が同じでもフィールド値の型が異なれば、異なるスキーマとみなす。ただし、フィールド名が同じでフィールド値の型が異なるフィールドを含むオブジェクトを同じスキーマと見なしてもよい。
【００３４】
図９は、実施形態のシステム構成の一例を示す図である。本実施形態の情報処理装置１は、半構造データを含むドキュメントを取得する。そして、情報処理装置１は、半構造データを複数のファイルに分割して格納し、ファイル毎に圧縮する。また、情報処理装置１は、圧縮後のファイル群を展開してドキュメントを復元することができる。情報処理装置１は、例えば、サーバまたはパーソナルコンピュータである。情報処理装置１は、コンピュータの一例である。
【００３５】
図１０は、実施形態の情報処理装置１の構成の一例を示す図である。実施形態の情報処理装置１は、取得部１１と特定部１２と設定部１３と生成部１４と選択部１５と格納部１６と圧縮部１８と展開部１９と制御部２０とを含む。
【００３６】
取得部１１は、半構造データを含むドキュメント等を他の情報処理装置等から取得する。特定部１２は、データ種類およびデータ型に基づいて、半構造データに含まれるグループの構造を特定する。データ種類は、例えば、フィールド名またはフィールドＩＤにより特定される。グループは、例えば、オブジェクトである。
【００３７】
設定部１３は、構造毎にユニークな第１識別子を設定し、構造内の各データのデータ種類およびデータ型の組に対して第２識別子を設定する。構造は、例えば、スキーマであり、後述するスキーマＩＤ配列で特定される。第１識別子は、例えば、後述するスキーマＩＤである。第２識別子は、例えば、後述するフィールド番号である。
【００３８】
設定部１３は、データ（例えば、フィールド値）が配列であり、配列内の要素がグループである場合、配列内のグループに、配列と異なる第１識別子を設定する。
【００３９】
生成部１４は、複数の前記データ種類を階層化した第１ツリーを生成する。第１ツリーは、例えば、後述するフィールド名／フィールドＩＤツリーである。また、生成部１４は、新たなグループを取得した場合、取得したグループ内のデータ種類を第１ツリーの上位から検索し、データ種類が第１ツリーに存在しない場合、そのデータ種類を第１ツリーに追加する。
【００４０】
生成部１４は、複数の構造を階層化した第２ツリーを生成する。第２ツリーは、例えば、後述するフィールドＩＤ配列／スキーマＩＤツリーである。また、生成部１４は、新たなグループを取得した場合、取得したグループの構造を第２ツリーの上位から検索し、構造が第２ツリーに存在しない場合、その構造を前記第２ツリーに追加する。
【００４１】
選択部１５は、新たにドキュメントを追加した場合、スキーマ管理テーブルに基づいて、ドキュメント内のグループに対応する第１識別子を選択し、各データに対応する第２識別子を選択する。
【００４２】
格納部１６は、グループ内のデータを、グループに対応する第１識別子とデータに対応する第２識別子の組毎に異なる記憶領域に格納する。記憶領域は、例えば、ファイルまたはデータベース等である。格納部１６は、データが配列である場合、配列内の要素の数と配列内の要素とを異なる記憶領域に格納する。格納部１６は、データが配列であり、配列内の要素がグループである場合、配列内の要素の数と、配列内のグループに設定された第１識別子と、グループ内のデータとを異なる記憶領域に格納する。
【００４３】
記憶部１７は、取得したドキュメント、後述する各種ツリー、管理情報、圧縮前のファイルおよび圧縮後のファイル等を記憶する。圧縮部１８は、記憶領域毎に、データを圧縮する。展開部１９は、圧縮された各ファイルを展開し、ドキュメントを復元する。制御部２０は、情報処理装置１の各種制御を実行する。
【００４４】
図１１は、実施形態で用いられる各情報を説明する図である。なお、図１１に示す情報において、フィールドＩＤは、ドキュメント内のフィールド名毎に付与されるユニークな識別情報である。スキーマＩＤは、オブジェクトの構造毎に設定されるユニークな識別情報である。スキーマＩＤには、例えば、ドキュメント中のフィールドＩＤとデータ型との組による配列（以下、フィールドＩＤ配列と称する）に対してユニークな値が設定される。すなわち、フィールドＩＤ配列は、オブジェクトの構造を示す配列である。
【００４５】
フィールド名／フィールドＩＤツリーは、フィールド名からフィールドＩＤを検索する際に用いられるツリーである。フィールド名／フィールドＩＤツリーは、トライ木またはプレフィックス木と呼ばれるデータ構造が適用される。フィールドＩＤ／フィールド名テーブルは、フィールド名／フィールドＩＤツリーに対応するテーブルである。フィールドＩＤ／フィールド名テーブルは配列やＢ木構造で構成されてもよい。
【００４６】
フィールドＩＤ配列／スキーマＩＤツリーは、フィールドＩＤ配列からスキーマＩＤを検索する際に用いられるツリーである。スキーマ管理テーブルは、フィールドＩＤ配列／スキーマＩＤツリーに対応するテーブルであり、スキーマ毎の構造の管理に用いられる。なお、図１１に示す各情報について、詳細は後述する。
【００４７】
図１２は、フィールド名／フィールドＩＤツリーの一例を示す図である。フィールド名／フィールドＩＤツリーの木構造は、トライ木またはプレフィックス木と呼ばれるデータ構造が適用される。図２の例に示すように、ドキュメントには複数のフィールドが含まれている。生成部１４は、ドキュメント内のフィールド名に基づいて、図１２に示すツリーを生成する。生成部１４は、例えば、図１２の"acount","age"のように、フィールド名の先頭文字列が共通する場合、共通する文字列を上位に配置し、残りの文字列を下位に配置する。フィールドＩＤは、設定部１３が、フィールド名毎に設定した値が付与される。
【００４８】
生成部１４は、各フィールド内のフィールド名をフィールド名／フィールドＩＤツリーから検索する。設定部１３は、新たに取得したフィールド名がフィールド名／フィールドＩＤツリーに存在しない場合、そのフィールド名に対応するフィールドＩＤを設定する。生成部１４は、そのフィールド名をフィールド名／フィールドＩＤツリーに追加し、設定されたフィールドＩＤをフィールド名に付与する。
【００４９】
図１３は、フィールドＩＤ／フィールド名テーブルの一例を示す図である。生成部１４は、設定部１３がフィールド名に対して設定したフィールドＩＤに基づいて、図１３に示すフィールドＩＤ／フィールド名テーブルを生成する。生成部１４は、フィールド名とフィールドＩＤをフィールド名／フィールドＩＤツリーに追加する際に、フィールドＩＤ／フィールド名テーブルにも同じフィールド名とフィールドＩＤとを追加する。
【００５０】
新たにドキュメントが追加された場合、設定部１３は、追加されたドキュメント内のフィールド名がフィールド名／フィールドＩＤツリーに存在するか検索し、存在していなければ、新たにフィールドＩＤをフィールド名に付与する。フィールド名を検索する際に、フィールドＩＤ／フィールド名テーブル内から検索するより、フィールド名／フィールドＩＤツリーから検索する方が短時間で検索を完了することができる。
【００５１】
例えば、図１２のフィールド名／フィールドＩＤツリーでは、root以下の項目数は８であるが、図１３のフィールドＩＤ／フィールド名テーブルのレコード数は１０である。従って、例えば、存在しないフィールド名が追加された場合、フィールドＩＤ／フィールド名テーブル内から検索する場合の検索回数は１０回であるが、フィールド名／フィールドＩＤツリーから検索する場合の検索回数は８回である。
【００５２】
図１４は、フィールドＩＤ配列の一例を示す図である。図１４は、図２に示すドキュメント１の（１）にフィールドＩＤ配列を付与した例を示す。上述のように、フィールドＩＤ配列は、ドキュメント中のフィールドＩＤとデータ型との組による配列である。本実施形態では、図１４に示すように、フィールドＩＤ配列は、フィールドＩＤとデータ型の省略形との組で表現される。
【００５３】
図１５は、フィールドＩＤ配列／スキーマＩＤツリーの一例を示す図である。図１５のフィールドＩＤ配列／スキーマＩＤツリーは、図２のドキュメント１に対応している。生成部１４は、図１５に示すように、各スキーマＩＤ配列に共通するフィールドを上位に設定し、共通しないフィールドを下位に設定したフィールドＩＤ配列／スキーマＩＤツリーを生成する。
【００５４】
例えば、図２に示すドキュメントでは、"name"フィールドが全オブジェクトに共通するため、"name"フィールドを示す"1S"が最上位に設定される。また、（１）、（２）、（４）に共通する"date"フィールドを示す"7S"がその下位に設定される。また、"date"フィールドを有していない（３）のオブジェクトを示す"3I","10S","9S"が"1S"の下位に設定される。また、"7S"の下位に（１）と（４）の"gender"フィールド、"weight"フィールドを示す"5S","4I"が設定される。また、"7S"の下位に（２）の"account"フィールド、"price"フィールド、"tagsフィールドを示す"8S","6I","2S"が設定される。
【００５５】
設定部１３は、スキーマＩＤ配列に対して、ユニークなスキーマＩＤを設定する。すなわち、設定部１３は、オブジェクトの構造毎にユニークなスキーマＩＤを設定する。生成部１４は、スキーマＩＤをツリーの末尾に付与する。なお、（１）と（４）は、同一のスキーマであるため、同一のスキーマＩＤ（１）が付与される。
【００５６】
図１６は、スキーマ管理テーブルの一例を示す図である。生成部１４は、フィールドＩＤ配列／スキーマＩＤツリーを生成するとともにスキーマ管理テーブルを生成する。設定部１３は、構造内の各フィールドのフィールドＩＤ（フィールド名）およびデータ型の組（"1S","7S"等）に対してフィールド番号を設定する。スキーマ管理テーブルにおけるスキーマ番号は、オブジェクト内のフィールドの識別情報としても用いられる。設定部１３は、例えば、スキーマ番号に、オブジェクト内のフィールドの並び順を用いる。
【００５７】
図１６に示すように、スキーマ管理テーブルは、フィールドＩＤ配列／スキーマＩＤツリーと対応している。また、スキーマ管理テーブルには、フィールドの数か記録される。
【００５８】
設定部１３は、新たなドキュメントが追加された場合、ドキュメント内のオブジェクトの構造に対応するフィールドＩＤ配列が存在するかを、図１５のフィールドＩＤ配列／スキーマＩＤツリーから検索する。設定部１３は、追加するオブジェクトの構造をフィールドＩＤ配列／スキーマＩＤツリーから検索することにより、スキーマ管理テーブルから検索するより、短時間で処理を完了することができる。
【００５９】
例えば、追加するオブジェクトの構造が、スキーマ管理テーブルに存在しない場合の検索処理について説明する。設定部１３は、スキーマ管理テーブルから検索する場合、スキーマ管理テーブルの各エントリの検索を行った結果存在しないと判定する。一方、図１５のフィールドＩＤ配列／スキーマＩＤツリーから検索する場合、追加するオブジェクトに最上位の"1S"に該当するフィールド（"name"フィールド）が存在しなければ、対応するフィールドＩＤ配列が存在しないと判定することができる。
【００６０】
図１７は、データを格納するファイルの一例を示す図である。図１７に示すように、格納部１６は、スキーマ管理テーブルにおけるスキーマＩＤとフィールド番号の組毎にファイルを生成する。また、格納部１６は、例えば、各ファイルに対し、「スキーマＩＤ−フィールド番号」という形式でファイル名を付与する。なお、本実施形態では、データの記憶領域にファイルを用いているが、データベース等を用いてもよい。
【００６１】
図１８は、データ格納方法の一例を示す図である。図１８は、図１７で生成されたファイルに図２のドキュメント１内のデータが格納され、さらにドキュメント７が追加された例を示している。
【００６２】
格納部１６は、生成したファイルにデータを格納する。図１８に示す例では、格納部１６は、ファイル"1-1","1-2","1-3","1-4"に、スキーマＩＤ"1"に該当するオブジェクト内のフィールド値を格納する。ドキュメント１では、（１）と（４）がスキーマＩＤ"1"に対応するため、格納部１６は、（１）と（４）の各フィールドのフィールド値をファイル"1-1","1-2","1-3","1-4"に格納する。同様に格納部１６は、ドキュメント１においてスキーマＩＤ"2"に対応する（２）のフィールド値をファイル"2-1","2-2","2-3","2-4","2-5"に格納する。同様に、格納部１６は、ドキュメント１においてスキーマＩＤ"3"に対応する（３）のフィールド値をファイル"3-1","3-2","3-3","3-4"に格納する。
【００６３】
さらに、ドキュメント１内のデータを格納した後、ドキュメント７が追加されたとする。選択部１５は、スキーマ管理テーブルに基づいて、ドキュメント７内のオブジェクトに対応するスキーマＩＤを選択し、各フィールドに対応するフィールド番号を選択する。図１８に示す例では、ドキュメント７内のオブジェクトの構造は、スキーマＩＤ"1"の構造に対応する。よって、格納部１６は、ドキュメント７内の各フィールド値をファイル"1-1","1-2","1-3","1-4"に格納する。
【００６４】
また、格納部１６は、格納したデータのスキーマＩＤをドキュメントインデックスとして、データ格納順に格納する。
【００６５】
圧縮部１８は、データが格納されたファイルをファイル毎に圧縮する。上述のように、ファイルは、フィールド名およびデータ型の組毎に生成される。よって、１つのファイルに格納される各データのデータ型は共通であるため、実施形態の情報処理装置１は、圧縮効率を向上させることができる。
【００６６】
図１９は、オブジェクトの入れ子が存在するドキュメントのフィールド名／フィールドＩＤツリーの一例を示す図である。図２０は、オブジェクトの入れ子が存在するドキュメントのフィールドＩＤ／フィールド名テーブルの一例を示す図である。
【００６７】
図４のドキュメント２のようにオブジェクトの入れ子が存在する場合、生成部１４は、上位のフィールド名と下位のフィールド名とを"."で連結してフィールド名を表現する。生成部１４は、"."で連結したフィールド名を用いて、フィールド名／フィールドＩＤツリーおよびフィールドＩＤ／フィールド名テーブルを生成する。
【００６８】
例えば、生成部１４は、図４のドキュメント２における"address"フィールド内のフィールドを、"address.country"、"address.postnumber"、"address.prefecture"と表現する。その結果、生成部１４は、図４のドキュメント２に関して、図１９に示すフィールド名／フィールドＩＤツリーおよび図２０に示すフィールドＩＤ／フィールド名テーブルを生成する。
【００６９】
図２１は、オブジェクトの入れ子が存在するドキュメントのスキーマ管理テーブルの一例を示す図である。図２２は、オブジェクトの入れ子が存在するドキュメントのデータ格納方法の一例を示す図である。
【００７０】
上述のように、オブジェクトの入れ子が存在する場合、下位のオブジェクト内のフィールド毎にフィールドＩＤが付与される。従って、スキーマ管理テーブルにおいても、下位のオブジェクト内のフィールド毎にフィールド番号が付与される。その結果、図２２に示すように、下位のオブジェクト内のフィールドも、フィールド値毎に異なるファイルに格納される。
【００７１】
次に、半構造データに配列が存在する場合の処理について説明する。半構造データに含まれる配列は、以下の（Ａ）〜（Ｃ）のように分類される。
（Ａ）配列内の全要素が真偽値、文字列、整数、浮動小数など基本データ型に統一されている。なお、このような配列を、基本データ型の配列と称する。
（Ｂ）配列内の全要素がオブジェクトである。各要素のオブジェクトのスキーマが異なっていてもよい。なお、このような配列をオブジェクト型の配列と称する。
（Ｃ）（Ａ）、（Ｂ）以外の配列。例えば、配列内の要素が異なるデータ型を持っていたり、基本的なデータ型とオブジェクトが混在する配列。
【００７２】
なお、（Ｃ）に該当する配列は、本実施形態の処理の適用外であるため、（Ａ）、（Ｂ）の配列に対する処理を説明する。
【００７３】
図２３は、配列のデータ型の省略形の一例を示す図である。半構造データに配列を含む場合、図３に示す省略形に加え、図２３に示す省略形が適用される。図２３に示すように、配列のデータ型は、配列内の要素のデータ型の前に"A"を付けた形式であるとする。
【００７４】
図２４は、基本データ型の配列を含むドキュメントの一例を示す図である。図２４に示すドキュメント８のうち、配列"group"は２つ存在するが、いずれの配列"group"も、全要素がstring型であるため、基本データ型の配列に該当する。
【００７５】
図２５は、基本データ型の配列を含むドキュメントのフィールドＩＤ／フィールド名テーブルの一例を示す図である。図２５のテーブルは、図２４のドキュメント８に基づいて生成されたフィールドＩＤ／フィールド名テーブルである。
【００７６】
ドキュメント８に存在するフィールド名は、"user"と配列"group"の２種類であるため、設定部１３は、各フィールド名に対してフィールドＩＤを設定する。また、生成部１４は、設定部１３が設定したフィールドＩＤを用いて、フィールドＩＤ／フィールド名テーブルを生成する。
【００７７】
なお、生成部１４は、基本データ型の配列を含むドキュメントに関して、フィールド名／フィールドＩＤツリーおよびフィールドＩＤ配列／スキーマＩＤツリーを生成するが、図示を省略する。
【００７８】
図２６は、基本データ型の配列を含むドキュメントのスキーマ管理テーブルの一例を示す図である。図２４のドキュメント８には、２つのオブジェクトが含まれるが、いずれも"user"と"group"という２つのフィールドを含み、構造が共通する。よって、設定部１３は、２つのオブジェクトに対応するスキーマＩＤを一つ設定する。なお、２つの配列"group"の要素数が異なるが、全要素が同一のデータ型（string）であるため、設定部１３は、同一の構造であるとみなす。
【００７９】
図２７は、基本データ型の配列を含むドキュメントのデータ格納方法の一例を示す図である。図２６が示すように、スキーマＩＤ"1"、フィールド番号"2"に対応するフィールドは配列である。フィールドが配列である場合、格納部１６は、配列内の要素の数と配列内の要素とを異なるファイルに格納する。
【００８０】
図２４のドキュメント８の１つ目の配列"group"は、３つの要素を含むため、格納部１６は、ファイル"1-2要素数"に"3"を格納する。また、図２４のドキュメント８の２つ目の配列"group"は、２つの要素を含むため、格納部１６は、ファイル"1-2要素数"に"2"を格納する。
【００８１】
また、図２４のドキュメント８の１つ目の配列"group"には、要素として"nminoru","wheel","dba"というフィールド値を含むため、格納部１６は、ファイル"1-2要素"に各フィールド値を格納する。また、図２４のドキュメント８の２つ目の配列"group"には、要素として"ozawa","apache"という２つのフィールド値を含むため、格納部１６は、ファイル"1-2要素"に各フィールド値を格納する。
【００８２】
図２７に示すように、フィールドが配列である場合、格納部１６は、配列内の要素の数と配列内の要素とを異なるファイルに格納するので、フィールドが配列であっても列形式でデータを格納することができる。本実施形態では、配列内の要素が全て同一のデータ型であるケースを扱っているため、ファイル内のフィールド値のデータ型は同一となる。要素の数は、整数値であるため、要素の数が格納されるファイル内もデータ型は同一となる。よって、情報処理装置１は、配列を含む半構造データの圧縮効率を向上することができる。
【００８３】
また、格納部１６は、配列内の要素の数と配列内の要素とを異なるファイルに格納するので、要素の数が異なる配列を１つのスキーマとして扱うことが可能となりファイル数を減らすことができる。
【００８４】
次に、ドキュメント内の配列がオブジェクトを要素として含む場合の処理について説明する。なお、以下に示す例では、配列内の複数のオブジェクトが異なるスキーマであるが、配列内の複数のオブジェクトが同一のスキーマであっても同様の処理を適用可能である。
【００８５】
図２８は、オブジェクト型の配列を含むドキュメントの一例を示す図である。図２８に示す例では、配列"roles"がオブジェクトを要素として含む配列である。配列"roles"は、ドキュメント９内に２つ存在し、それぞれ要素数が異なる。
【００８６】
図２９は、オブジェクト型の配列を含むドキュメントのフィールドＩＤ／フィールド名テーブルの一例を示す図である。図２９に示す"roles"は配列のフィールド名であり、"name","gender","job"は、配列内のオブジェクトに含まれるフィールド名である。すなわち、設定部１３は、配列のフィールド名と配列内のオブジェクトに含まれるフィールド名にそれぞれ異なるフィールドＩＤを設定する。
【００８７】
また、配列"roles"は、ドキュメント９内に２つ存在し、それぞれ要素数が異なるが、同一のフィールドＩＤを付与する。
【００８８】
図３０は、オブジェクト型の配列を含むドキュメントのスキーマ管理テーブルの一例を示す図である。図３０に示す"2AO"は、オブジェクト型の配列"roles"を示す。設定部１３は、オブジェクト内のフィールド数やフィールドのデータ型に関わらず、オブジェクト型の配列にはデータ型として"AO"を設定する。
【００８９】
図３０において、スキーマＩＤ"1"は、基本データ型である"user"と配列"roles"とを含む構造を示す。スキーマＩＤ"2","3"は、配列"roles"内のオブジェクトの構造を示す。
【００９０】
図３１は、オブジェクト型の配列を含むドキュメントのデータ格納方法の一例を示す図である。格納部１６は、オブジェクト型の配列に関して、配列内の要素の数と、配列内のオブジェクトに設定されたスキーマＩＤと、オブジェクト内のフィールド値とをそれぞれ異なるファイルに格納する。
【００９１】
図３１に示す例では、一つ目の配列"roles"の要素の数は２であり、二つ目の配列"roles"の要素の数は１であるため、格納部１６は、"2","1"をファイル"1-2要素数"に格納する。また、一つ目の配列"roles"内の２つのオブジェクトに設定されたスキーマＩＤは"2"および"3"であるため、格納部１６は、"2","3"をファイル"1-2スキーマID"に格納する。また、二つ目の配列"roles"内のオブジェクトに設定されたスキーマＩＤは"2"であるため、格納部１６は、"2"をファイル"1-2スキーマID"に格納する。
【００９２】
また、配列内のオブジェクトについては、格納部１６は、基本データ型のデータと同様に、スキーマ管理テーブルのスキーマＩＤとフィールド番号との組毎に異なるファイルに格納する。図３１に示す例では、格納部１６は、"2-1","2-2","3-1","3-2","3-3"に配列内のオブジェクトを格納する。
【００９３】
例えば、ドキュメント内に、要素となるオブジェクトのスキーマがそれぞれ異なる配列が複数存在する場合、各配列を異なる構造であるとみなすと、スキーマの数が多数となる可能性がある。本実施形態では、要素となるオブジェクトのスキーマがそれぞれ異なる配列を同じスキーマとみなし、配列内のオブジェクトにそれぞれスキーマＩＤを設定するので、スキーマの数の増大を防ぐことができる。
【００９４】
図３２は、実施形態の処理の流れの一例を示すフローチャートである。制御部２０は、処理対象のドキュメントにおいて、処理対象レベルをrootに設定する（ステップＳ１０１）。処理対象レベルは、ドキュメント内に複数階層のデータが存在する場合の段階を示し、rootは最上位階層を示す。
【００９５】
情報処理装置１は、圧縮前処理を実行する（ステップＳ１０２）。圧縮前処理に関して、詳細は後述する。格納部１６は、ドキュメントインデックスファイルにスキーマＩＤ（Ｐ）を格納する（ステップＳ１０３）。圧縮部１８は、ファイル毎に、データを圧縮する（ステップＳ１０４）。
【００９６】
図３３は、圧縮前処理の一例を示すフローチャートである。制御部２０は、プレフィックスを空に設定する（ステップＳ１１１）。プレフィックスは、後述の処理でフィールド名の保持に用いられる。生成部１４は、第１生成処理を実行する（ステップＳ１１２）。第１生成処理は、フィールドＩＤ配列／スキーマＩＤツリーとスキーマ管理テーブルを生成する処理であり、詳細は後述する。格納部１６は、格納処理を実行する（ステップＳ１１３）。格納処理について、詳細は後述する。
【００９７】
図３４は、第１生成処理の一例を示すフローチャートである。生成部１４は、処理対象レベルをＲに設定し、プレフィックスをＳに設定する（ステップＳ２００）。管理テーブル生成処理が１回目に呼び出された場合、Ｒにroot、Ｓに空が設定される。
【００９８】
生成部１４は、レベルＲ直下のフィールドＦ毎に繰り返し処理を開始する（ステップＳ２０１）。図４のドキュメント２を用いた場合、レベルＲ直下のフィールドＦは、Ｒがrootである場合、"name","address","gender","weight"を示し、Ｒが"address"である場合、"country","postnumber","prefecture"を示す。
【００９９】
生成部１４は、フィールドＦに対して、第２生成処理を実行する（ステップＳ２０２）。第２生成処理は、フィールド名／フィールドＩＤツリーおよびフィールドＩＤ／フィールド名テーブルを生成する処理である。各フィールドＦに対してステップＳ２０２の処理が完了した場合、生成部１４は、繰り返し処理を終了する（ステップＳ２０３）。
【０１００】
特定部１２は、オブジェクト内のフィールド名とデータ型の組み合わせに基づいてオブジェクトの構造を特定する（ステップＳ２０４）。
【０１０１】
生成部１４は、生成したフィールド名／フィールドＩＤツリーおよびフィールドＩＤ／フィールド名テーブルを用いてフィールドＩＤ配列を生成し、生成したフィールドＩＤ配列をＪとする（ステップＳ２０５）。
【０１０２】
生成部１４は、フィールドＩＤ配列／スキーマＩＤツリーに、生成したフィールドＩＤ配列（Ｊ）が存在するか判定する（ステップＳ２０６）。生成部１４は、フィールドＩＤ配列（Ｊ）が存在しないと判定した場合（ステップＳ２０６でＮＯ）、設定部１３は、フィールドＩＤ配列（Ｊ）にスキーマＩＤを設定し、オブジェクト内の各データのフィールド名およびデータ型の組に対してフィールド番号を設定する（ステップＳ２０７）。フィールドＩＤ配列（Ｊ）は、上述のように、オブジェクトの構造を示す配列である。
【０１０３】
生成部１４は、フィールドＩＤ配列（Ｊ）を追加したフィールドＩＤ配列／スキーマＩＤツリーとスキーマ管理テーブルを生成する（ステップＳ２０８）。生成部１４は、フィールドＩＤ配列（Ｊ）が存在すると判定した場合（ステップＳ２０６でＹＥＳ）、処理を終了する。
【０１０４】
なお、１回目の処理では、フィールドＩＤ配列／スキーマＩＤツリーが生成されていないため、生成部１４は、ステップＳ２０６をスキップし、ステップＳ２０７、Ｓ２０８を実行する。
【０１０５】
図３５は、第２生成処理の一例を示すフローチャートである。フィールドＦが基本データ型であるか判定する（ステップＳ３０１）。フィールドＦが基本データ型でない場合（ステップＳ３０１でＮＯ）、フィールドＦは所定形式の配列であるか判定する（ステップＳ３０２）。所定形式の配列とは、上述した基本データ型の配列またはオブジェクト型の配列である。
【０１０６】
ステップＳ３０１またはステップＳ３０２でＹＥＳの場合、フィールドＦのフィールド名がフィールド名／フィールドＩＤツリーに存在するか検索する（ステップＳ３０３）。フィールド名がフィールド名／フィールドＩＤツリーに存在しない場合（ステップＳ３０３でＮＯ）、設定部１３は、「Ｓ．Ｆのフィールド名」をフィールド名に設定し、フィールド名に対応するフィールドＩＤを設定する（ステップＳ３０４）。ステップＳ３０４が１回目に呼び出された場合、Ｓが空であるため、設定部１３は、フィールドＦのフィールド名をそのまま設定する。
【０１０７】
そして、生成部１４は、フィールド名／フィールドＩＤツリー、フィールドＩＤ／フィールド名テーブルにフィールドＦに設定されたフィールド名とフィールドＩＤを追加する（ステップＳ３０５）。
【０１０８】
フィールドＦのフィールド名がフィールド名／フィールドＩＤツリーに存在する場合（ステップＳ３０３でＹＥＳ）、処理は終了する。
【０１０９】
ステップＳ３０２でＮＯの場合、フィールドＦがオブジェクト型であるか判定する（ステップＳ３０６）。フィールドＦがオブジェクト型でない場合（ステップＳ３０６でＮＯ）、処理対象のデータでないため、情報処理装置１は、処理を中止する（ステップＳ３０７）。
【０１１０】
フィールドＦがオブジェクト型である場合（ステップＳ３０６でＹＥＳ）、設定部１３は、処理対象レベルをＦとし、「Ｓ．Ｆのフィールド名」をプレフィックスに設定する（ステップＳ３０９）。そして、生成部１４は、第１生成処理を再帰的に呼び出す（ステップＳ３１０）。
【０１１１】
図１９、図２０に示したようにオブジェクトの入れ子が存在する場合、フィールド名は「上位のフィールド名．下位のフィールド名」という形式で表される。ステップＳ３０９が１回目に呼び出された場合、Ｓが空であるため、Ｓ．Ｆのフィールド名はＦのフィールド名となる。ステップＳ３１０の第１生成処理から、再度第２生成処理が呼び出された場合、Ｓに上位のフィールド名が設定されているため、ステップＳ３０４において「Ｓ．Ｆのフィールド名」は、「上位のフィールド名．下位のフィールド名」という形式になる。
【０１１２】
図３６は、格納処理の一例を示すフローチャートである。格納部１６は、処理対象レベルをＲに設定し、対応するスキーマＩＤをＰに設定する（ステップＳ４０１）。格納部１６は、１回目の処理の場合、Ｒにrootを設定し、スキーマＩＤには、格納が完了していないスキーマＩＤのうち最小の値を設定する。
【０１１３】
格納部１６は、スキーマＩＤ（Ｐ）に対応するフィールド（Ｆ）毎に繰り返し処理を開始する（ステップＳ４０２）。なお、フィールド番号をＩとする。格納部１６は、フィールドＦが基本データ型であるか判定する（ステップＳ４０３）。フィールドＦが基本データ型である場合（ステップＳ４０３でＹＥＳ）、ファイル（Ｐ−Ｉ）にフィールド値を格納する（ステップＳ４０４）。
【０１１４】
フィールドＦが基本データ型でない場合（ステップＳ４０５でＮＯ）、フィールドＦは配列であるため、格納部１６は、ファイル（Ｐ−Ｉ要素数）に配列の要素数を格納する（ステップＳ４０５）。格納部１６は、フィールドＦが基本データ型の配列であるか判定する（ステップＳ４０６）。フィールドＦが基本データ型の配列である場合（ステップＳ４０６でＹＥＳ）、ファイル（Ｐ−Ｉ要素）に配列の要素のフィールド値を全て格納する（ステップＳ４０７）。
【０１１５】
フィールドＦが基本データ型の配列でない場合（ステップＳ４０６でＮＯ）、フィールドＦはオブジェクト型配列であり、格納部１６は、配列内の各要素Ｇ（オブジェクト）について、繰り返し処理を開始する（ステップＳ４０８）。
【０１１６】
格納部１６は、圧縮前処理を再帰的に呼び出す（ステップＳ４０９）。ステップＳ４０９において、処理対象の要素Ｇ（オブジェクト）について、フィールドＩＤ配列／スキーマＩＤツリー、スキーマ管理テーブルへの追加等が行われ、さらにオブジェクト内のフィールドの格納が行われる。
【０１１７】
格納部１６は、ファイル（Ｐ−ＩスキーマＩＤ）に、ステップＳ４０９で格納したオブジェクトに対応するスキーマＩＤを格納する（ステップＳ４１０）。格納部１６は、配列内の全ての要素についての処理（ステップＳ４０９、Ｓ４１０）が完了した場合、繰り返し処理を終了する（ステップＳ４１１）。また、格納部１６は、スキーマＩＤ（Ｐ）に対応する全てのフィールドについての処理（ステップＳ４０３〜Ｓ４１１）が完了した場合、繰り返し処理を完了する（ステップＳ４１２）。
【０１１８】
図３７は、復元処理の一例を示すフローチャートである。展開部１９は、スキーマ管理テーブルを参照し、スキーマＩＤ毎に繰り返し処理を開始する（ステップＳ５０１）。展開部１９は、処理対象のスキーマＩＤに対応するファイルの展開処理を実行する（ステップＳ５０２）。展開部１９は、展開したファイルから読み込んだ情報に基づいて、圧縮前のドキュメントを復元する（ステップＳ５０３）。展開部１９は、全てのスキーマＩＤに対応するファイルにステップＳ５０２、Ｓ５０３を実行した場合、処理を終了する（ステップＳ５０４）。
【０１１９】
図３８は、展開処理の一例を示すフローチャートである。展開部１９は、展開対象のファイルのスキーマＩＤをＰに設定する（ステップＳ６０１）。展開部１９は、展開対象のスキーマＩＤに対応するフィールドＦ毎に繰り返し処理を開始する（ステップＳ６０２）。なお、フィールド番号をＩとする。
【０１２０】
展開部１９は、フィールドＦが基本データ型であるか判定する（ステップＳ６０３）。
フィールドＦが基本データ型である場合（ステップＳ６０３でＹＥＳ）、展開部１９は、ファイル（Ｐ−Ｉ）を展開し、ファイル内のデータを読み込む（ステップＳ６０４）。フィールドＦが基本データ型でない場合（ステップＳ６０３でＮＯ）、すなわち配列である場合、展開部１９は、ファイル（Ｐ−Ｉ要素数）を展開し、ファイル内のデータを読み込む（ステップＳ６０５）。
【０１２１】
展開部１９は、フィールドＦが基本データ型の配列であるか判定する（ステップＳ６０６）。フィールドＦが基本データ型の配列である場合（ステップＳ６０６でＹＥＳ）、ファイル（Ｐ−Ｉ要素）を展開し、展開したファイルからデータを読み込む（ステップＳ６０７）。
【０１２２】
フィールドＦが基本データ型の配列でない場合（ステップＳ６０６でＮＯ）、オブジェクト型の配列である。オブジェクト型の配列は、ファイル（Ｐ−Ｉ要素）に配列内のオブジェクト毎のスキーマＩＤが格納されている。よって、展開部１９は、ファイル（Ｐ−Ｉ要素）内のスキーマＩＤ（Ｐ）毎の繰り返し処理を開始する（ステップＳ６０８）。
【０１２３】
展開部１９は、ファイル（Ｐ−Ｉ要素）内のスキーマＩＤを処理対象として、展開処理を再帰的に呼び出す（ステップＳ６０９）。展開部１９は、オブジェクト内のフィールドが基本データ型であれば、ステップＳ６０４の処理によりオブジェクト内のフィールド値が格納されたファイル（Ｐ−Ｉ）を展開し、データを読み込む。
【０１２４】
展開部１９は、ファイル（Ｐ−Ｉ要素）内の全てのスキーマＩＤについてステップＳ６０９を実行した場合、繰り返し処理を終了する（ステップＳ６１０）。展開部１９は、全てのフィールドについてステップＳ６０３〜Ｓ６１０を実行した場合、繰り返し処理を終了する（ステップＳ６１１）。
【０１２５】
＜実施例＞
図３９は、実施形態の処理に適用するドキュメントの第１の例を示す図である。図３９は、基本データ型のフィールド"name","gender","weight"およびオブジェクト型のフィールド"address"を含む。図３９に示すドキュメント１０において、ｒ１、ｒ２は、処理対象レベルを示す。
【０１２６】
図４０は、ドキュメント１０に実施形態の処理を実施した場合の処理例を示す図である。なお、図４０に示す処理はドキュメント１０に対する処理の全てではなく、一部を省略している。
【０１２７】
図４０に示すように、フィールド"name"については、プレフィックスが空の状態で、第１生成処理、第２生成処理が行われることにより、フィールド名／フィールドＩＤツリーへの追加等の各種処理が行われる。そして、フィールド"address"については、オブジェクト型であるため、プレフィックスに"address"を設定した状態で、第１生成処理、第２生成処理が行われることにより、"address"と下位のフィールドの"country","postnumber"が連結されてフィールド名として記録される。
【０１２８】
すなわち、情報処理装置１は、オブジェクト型のフィールドが存在する場合であっても、上位のフィールド名を記憶した状態で、再帰処理を行うことにより、上位のフィールド名と下位のフィールド名とを連結したフィールド名を記録することができる。
【０１２９】
図４１は、実施形態の処理に適用するドキュメントの第２の例を示す図である。図４１に示すドキュメント１１において、ｒ１、ｒ２、ｒ３は、処理対象レベルを示す。ドキュメント１１は、基本データ型のフィールド"user"とオブジェクト型の配列"roles"を含む。また、配列内の各オブジェクトに異なるレベルが設定されている。
【０１３０】
図４２および図４３は、ドキュメント１１に実施形態の格納処理を実施した場合の格納処理例を示す図である。なお、図４２および図４３に示す処理はドキュメント１１に対する処理の全てではなく、一部を省略している。図４２および図４３に示すように、格納部１６は、フィールド"user"は基本データ型であるため、フィールド値をそのままファイルに格納する。
【０１３１】
フィールド"roles"は配列であるため、格納部１６は、配列の要素数"2"をファイルに格納する。そして、格納部１６は、配列内の要素に対して圧縮前処理を呼び出すことにより、第１生成処理、第２生成処理が呼び出され、フィールド名／フィールドＩＤツリー、スキーマ管理テーブルにｒ２内のフィールドが追加される。そして、格納部１６は、再帰的に呼び出した格納処理において、オブジェクト内の要素"name","gender"のフィールド値をファイルに格納する。そして、格納部１６は、ｒ２内のフィールドもファイルに格納する。
【０１３２】
以上のように、情報処理装置１は、オブジェクト型の配列内の要素をファイルに格納することができる。
【０１３３】
図４４は、システム構成の第１実施例を示す図である。図４４におけるシステム構成は、実施形態における情報処理装置１に相当する情報処理装置１ａと情報処理装置１ｂとを含む。
【０１３４】
情報処理装置１ａは、実施形態の情報処理装置１の機能を有する圧縮ツール３１を含む。情報処理装置１ａは、半構造データが含まれるドキュメントを取得する。そして、圧縮ツール３１は、半構造データを上述した処理により複数のファイルに格納し、ファイル毎に圧縮する。情報処理装置１ａは、圧縮されたファイル群を情報処理装置１ｂに送信する。
【０１３５】
情報処理装置１ｂは、実施形態の情報処理装置１の機能を有する展開ツール３２を含む。情報処理装置１ｂは、圧縮されたファイル群を取得する。そして、展開ツール３２は、圧縮されたファイル群を上述した処理により展開し、ドキュメントを復元する。
【０１３６】
図４５は、システム構成の第２実施例を示す図である。第２実施例ではネットワーク経由でドキュメント形式のメッセージを送受信する際に圧縮が行われる。第２実施例のシステム構成は、クライアント端末２、情報処理装置１ａ、ネットワーク３、情報処理装置１ｂ、およびサーバ４を含む。
【０１３７】
クライアント端末２は、サーバ４宛の半構造データが含まれるドキュメント形式メッセージを情報処理装置１ａに送信する。情報処理装置１ａは、ドキュメント形式メッセージを取得する。そして、情報処理装置１ａは、ドキュメント形式メッセージを上述した処理により複数のファイルに格納し、ファイル毎に圧縮する。情報処理装置１ａは、圧縮したファイル群をネットワーク３経由で情報処理装置１ｂに送信する。
【０１３８】
情報処理装置１ｂは、送信された圧縮ファイル群を取得する。そして、情報処理装置１ｂは、圧縮ファイル群を上述した処理により展開し、ドキュメント形式メッセージを復元する。情報処理装置１ｂは、復元したドキュメント形式メッセージをサーバ４に送信する。
【０１３９】
なお、クライアント端末２がメッセージを連続的に送信した場合、例えば、情報処理装置１ａは、所定数のドキュメント形式メッセージを受信してから、格納および圧縮を行う。また、情報処理装置１ｂは、受信したドキュメント形式メッセージを逐次展開してサーバ４に送信する。
【０１４０】
＜情報処理装置１のハードウェア構成＞
次に、情報処理装置１のハードウェア構成の一例を説明する。図４６は、情報処理装置１のハードウェア構成の一例を示す図である。図４６の例に示すように、情報処理装置１において、バス１００に、プロセッサ１１１とメモリ１１２と補助記憶装置１１３と通信インタフェース１１４と媒体接続部１１５と入力装置１１６と出力装置１１７とが接続される。
【０１４１】
プロセッサ１１１は、メモリ１１２に展開されたプログラムを実行する。実行されるプログラムには、実施形態における処理を行うデータ圧縮プログラムが適用されてもよい。
【０１４２】
メモリ１１２は、例えば、Random Access Memory(RAM)である。補助記憶装置１１３は、種々の情報を記憶する記憶装置であり、例えばハードディスクドライブや半導体メモリ等が適用されてもよい。補助記憶装置１１３に実施形態の処理を行うデータ圧縮プログラムが記憶されていてもよい。
【０１４３】
通信インタフェース１１４は、Local Area Network（LAN）、Wide Area Network（WAN）等の通信ネットワークに接続され、通信に伴うデータ変換等を行う。
【０１４４】
媒体接続部１１５は、可搬型記録媒体１１８が接続可能なインタフェースである。可搬型記録媒体１１８には、光学式ディスク（例えば、Compact Disc(CD)やDigital Versatile Disc(DVD))、半導体メモリ等が適用されてもよい。可搬型記録媒体１１８に実施形態の処理を行うデータ圧縮プログラムが記録されていてもよい。
【０１４５】
入力装置１１６は、例えば、キーボード、ポインティングデバイス等であり、ユーザからの指示及び情報等の入力を受け付ける。
【０１４６】
出力装置１１７は、例えば、表示装置、プリンタ、スピーカ等であり、ユーザへの問い合わせ又は指示、及び処理結果等を出力する。
【０１４７】
図１０に示す記憶部１７は、メモリ１１２、補助記憶装置１１３または可搬型記録媒体１１８等により実現されてもよい。図１に示す取得部１１、特定部１２、設定部１３、生成部１４、選択部１５、格納部１６、圧縮部１８、展開部１９、および制御部２０は、メモリ１１２に展開されたデータ圧縮プログラムをプロセッサ１１１が実行することにより実現されてもよい。
【０１４８】
メモリ１１２、補助記憶装置１１３および可搬型記録媒体１１８は、コンピュータが読み取り可能であって非一時的な有形の記憶媒体であり、信号搬送波のような一時的な媒体ではない。
【０１４９】
＜その他＞
本実施形態は、以上に述べた実施の形態に限定されるものではなく、本実施形態の要旨を逸脱しない範囲内で様々な変更、追加、省略が行われてもよい。
【符号の説明】
【０１５０】
１，１ａ，１ｂ    情報処理装置
２      クライアント端末
３      ネットワーク
４      サーバ
１１    取得部
１２    特定部
１３    設定部
１４    生成部
１５    選択部
１６    格納部
１７    記憶部
１８    圧縮部
１９    展開部
２０    制御部
３１    圧縮ツール
３２    展開ツール
１００    バス
１１１    プロセッサ
１１２    メモリ
１１３    補助記憶装置
１１４    通信インタフェース
１１５    媒体接続部
１１６    入力装置
１１７    出力装置
１１８    可搬型記録媒体
【図１】
2019179504.tif 000003
【図２】
2019179504.tif 000004
【図３】
2019179504.tif 000005
【図４】
2019179504.tif 000006
【図５】
2019179504.tif 000007
【図６】
2019179504.tif 000008
【図７】
2019179504.tif 000009
【図８】
2019179504.tif 000010
【図９】
2019179504.tif 000011
【図１０】
2019179504.tif 000012
【図１１】
2019179504.tif 000013
【図１２】
2019179504.tif 000014
【図１３】
2019179504.tif 000015
【図１４】
2019179504.tif 000016
【図１５】
2019179504.tif 000017
【図１６】
2019179504.tif 000018
【図１７】
2019179504.tif 000019
【図１８】
2019179504.tif 000020
【図１９】
2019179504.tif 000021
【図２０】
2019179504.tif 000022
【図２１】
2019179504.tif 000023
【図２２】
2019179504.tif 000024
【図２３】
2019179504.tif 000025
【図２４】
2019179504.tif 000026
【図２５】
2019179504.tif 000027
【図２６】
2019179504.tif 000028
【図２７】
2019179504.tif 000029
【図２８】
2019179504.tif 000030
【図２９】
2019179504.tif 000031
【図３０】
2019179504.tif 000032
【図３１】
2019179504.tif 000033
【図３２】
2019179504.tif 000034
【図３３】
2019179504.tif 000035
【図３４】
2019179504.tif 000036
【図３５】
2019179504.tif 000037
【図３６】
2019179504.tif 000038
【図３７】
2019179504.tif 000039
【図３８】
2019179504.tif 000040
【図３９】
2019179504.tif 000041
【図４０】
2019179504.tif 000042
【図４１】
2019179504.tif 000043
【図４２】
2019179504.tif 000044
【図４３】
2019179504.tif 000045
【図４４】
2019179504.tif 000046
【図４５】
2019179504.tif 000047
【図４６】
2019179504.tif 000048