JP6260339B2 - 情報処理装置，データ変換プログラム，及びデータ変換方法 - Google Patents
情報処理装置，データ変換プログラム，及びデータ変換方法 Download PDFInfo
- Publication number
- JP6260339B2 JP6260339B2 JP2014032652A JP2014032652A JP6260339B2 JP 6260339 B2 JP6260339 B2 JP 6260339B2 JP 2014032652 A JP2014032652 A JP 2014032652A JP 2014032652 A JP2014032652 A JP 2014032652A JP 6260339 B2 JP6260339 B2 JP 6260339B2
- Authority
- JP
- Japan
- Prior art keywords
- key
- data
- unit
- tables
- value
- 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.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/282—Hierarchical databases, e.g. IMS, LDAP data stores or Lotus Notes
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
本発明は、情報処理装置，データ変換プログラム，及びデータ変換方法に関する。
図２３は情報処理システム１００の構成例を示す図であり、図２４は図２３に示すアプリサーバ１２０の機能構成例を示す図である。図２３に示すように、情報処理システム１００は、複数のアプリケーションサーバ（以下、単にアプリサーバという）１２０，複数のデータベース（database；ＤＢ）サーバ１４０，並びにアプリサーバ１２０及びＤＢサーバ１４０間を接続するネットワークスイッチ１３０をそなえる。
情報処理システム１００では、図２４に示すように、アプリサーバ１２０が、データベース接続部１２２によりＤＢサーバ１４０が管理するＤＢ１４１へアクセスを行なうことで、所定のアプリケーション１２１を実行する。アプリサーバ１２０がアクセス、すなわちデータの入出力等の操作を行なうＤＢ１４１としては、データ及び複数のデータ間の関連を１以上の表（テーブル）形式で表現する関係データベース（Relational DB；ＲＤＢ）が用いられることが多い。ＲＤＢは、その普及率の高さから、管理システム（RDB Management System；ＲＤＢＭＳ）の提供者（ベンダ）や使用者等による機能改善及びバグフィックスの動きが活発であり、性能が良く安定性が高いＤＢであるといえる。
ところで、アプリケーション１２１は、入れ子構造を含むツリー（木）構造のデータモデル（データ形式）を使用することが多い。なお、データモデルとは、アプリケーション１２１がＤＢ１４１へアクセスするためのデータ形式であり、アプリケーション１２１がＤＢ１４１へのアクセスにおいてデータをどのような形で扱うかを定めるものである。表形式のデータを扱うＲＤＢでツリー構造のデータモデルを実現する場合、アプリケーション１２１の開発者は、複数の表が複雑に関連したデータモデルを設計することになる。しかし、複数の表を複雑に連携させる場合、アプリケーション１２１の設計の段階で、開発者は、ツリーを認識し難くなり、アプリケーション１２１の設計や更新等を容易に行なうことができない場合がある。
一方で、入れ子構造を含むツリー構造のデータモデルを扱うことが容易なドキュメントＤＢ（Document DB；ＤＤＢ）も知られている。ＤＤＢは、アプリケーション１２１側に特化したＤＢであり、開発者等にツリー構造をそのまま扱うように見せ、データモデルを直感的に設計させることが可能である。
なお、関連技術として、電子取引伝票の変換装置が、ＥＤＩ（Electronic Data Interchange）伝票データをＲＤＢ形式に変換する変換規則を用いて、ＥＤＩ伝票データをＲＤＢ化された取引データに変換する技術が知られている（例えば、特許文献１参照）。
なお、関連技術として、電子取引伝票の変換装置が、ＥＤＩ（Electronic Data Interchange）伝票データをＲＤＢ形式に変換する変換規則を用いて、ＥＤＩ伝票データをＲＤＢ化された取引データに変換する技術が知られている（例えば、特許文献１参照）。
また、他の関連技術として、ＯＤＢ（Object DB）のモデルとＲＤＢのモデルとを作成し、ＯＤＢの組をＲＤＢに変換する技術も知られている（例えば、特許文献２参照）。
ＤＤＢは、ＲＤＢと比べて製品の歴史が浅いため、導入実績が少なく、バグフィックス等も活発には行なわれていない。従って、ＤＤＢはＲＤＢよりも性能や安定性が優れているとは言い難い。このため、ＤＢサーバ１４０がＤＤＢを用いる場合、ＲＤＢを用いる場合よりもアプリサーバ１２０には高い性能が要求されることになる。また、アプリケーション１２１がデータの誤りや喪失を許容しない又は許容量が小さい場合には、ＤＤＢの導入は困難となる。
一方、ＲＤＢで入れ子構造を含むツリー構造（以下、単にツリー構造という）を表現しようとする場合、以下の（ａ）又は（ｂ）の手法が考えられる。
（ａ）ツリー構造のデータ形式を単一の表形式に変換する。
（ｂ）ツリー構造のデータ形式を複数の表形式に変換する。
上記（ａ）の手法において、ツリー構造のデータを単一の表形式データに変換してＲＤＢに格納しようとすると、入れ子構造のためにデータ内容に重複が生じて、ＲＤＢのデータサイズが大きくなってしまう。
（ａ）ツリー構造のデータ形式を単一の表形式に変換する。
（ｂ）ツリー構造のデータ形式を複数の表形式に変換する。
上記（ａ）の手法において、ツリー構造のデータを単一の表形式データに変換してＲＤＢに格納しようとすると、入れ子構造のためにデータ内容に重複が生じて、ＲＤＢのデータサイズが大きくなってしまう。
また、上記（ｂ）の手法において、ツリー構造のデータを単純に複数の表形式データに変換すると、テーブル数が多くなるため、アプリサーバ１２０による参照の際に多数のテーブルを参照することになり、結果として多数のメモリを消費してしまう。
このように、アプリケーション１２１の設計や更新等に適したＤＤＢをＤＢ１４１に採用する場合、ＲＤＢを扱うＤＢ１４１と比較して、システムの性能低下や導入／運用コストの増加が生じ得るという課題がある。
このように、アプリケーション１２１の設計や更新等に適したＤＤＢをＤＢ１４１に採用する場合、ＲＤＢを扱うＤＢ１４１と比較して、システムの性能低下や導入／運用コストの増加が生じ得るという課題がある。
なお、上述したＥＤＩ伝票データをＲＤＢ化された取引データに変換する技術は、特定の形式のデータをＲＤＢ形式のデータに変換するものであり、入れ子や階層の構造が多様なツリー構造のデータを適応的にＲＤＢ形式のデータに変換することは困難である。
１つの側面では、本発明は、情報処理装置において、入れ子構造を含むツリー構造のデータを、性能の低下又はコストの増加を抑止して、容易に扱うことを目的とする。
１つの側面では、本発明は、情報処理装置において、入れ子構造を含むツリー構造のデータを、性能の低下又はコストの増加を抑止して、容易に扱うことを目的とする。
なお、前記目的に限らず、後述する発明を実施するための形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の１つとして位置付けることができる。
本件の情報処理装置は、第１のデータ形式で入力された入れ子構造を含む階層構造のデータを、複数のテーブルにより前記データを表す第２のデータ形式に変換して、格納部へ格納する変換部をそなえる。また、前記変換部は、前記入力されたデータの情報要素ごとに、当該情報要素の属する階層及び当該情報要素の要素名を表すテーブル名を設定した第１テーブルを生成し、前記データの入れ子構造に応じて、前記複数の第１テーブルの各々を対応する他の第１テーブルと関係付ける第１生成部をそなえる。さらに、前記変換部は、複数の前記第１テーブルの各々のテーブル名に基づき、前記複数の第１テーブルの中から、前記階層構造における情報要素の属する階層及び当該情報要素の種類がそれぞれ所定の関係にある第１テーブルを検出し、当該検出した第１テーブル同士を統合して第２テーブルを生成する第２生成部さらにそなえる。
一実施形態によれば、情報処理装置において、入れ子構造を含むツリー構造のデータを、性能の低下又はコストの増加を抑止して、容易に扱うことができる。
以下、図面を参照して実施の形態を説明する。
〔１〕一実施形態
〔１−１〕情報処理システムの説明
図１は一実施形態に係る情報処理システム１の構成例を示す図である。図１に示すように、情報処理システム１は、複数のアプリケーションサーバ（以下、単にアプリサーバという）２，ネットワークスイッチ３，及び複数のデータベース（ＤＢ）サーバ４をそなえる。
〔１〕一実施形態
〔１−１〕情報処理システムの説明
図１は一実施形態に係る情報処理システム１の構成例を示す図である。図１に示すように、情報処理システム１は、複数のアプリケーションサーバ（以下、単にアプリサーバという）２，ネットワークスイッチ３，及び複数のデータベース（ＤＢ）サーバ４をそなえる。
なお、図１において、情報処理システム１は、アプリサーバ２及びＤＢサーバ４をそれぞれ複数そなえるものとしたが、これに限定されるものではなく、それぞれを１つそなえるものとしてもよい。この場合、ネットワークスイッチ３を省略してもよい。また、図１において、全てのアプリサーバ２及びＤＢサーバ４が同一ネットワークに属しているものとしたが、これに限定されるものではなく、ネットワークに階層構造を持たせてもよい。
ネットワークスイッチ３は、アプリサーバ２及びＤＢサーバ４間を相互に通信可能に接続する装置である。ネットワークスイッチ３としては、例えばＬ３（Layer 3）スイッチやスイッチングハブ等が挙げられる。
アプリサーバ２は、ネットワークスイッチ３を介してＤＢサーバ４へアクセスを行なうことで、データベース（ＤＢ）４１を使用する所定のアプリケーションを実行する。
アプリサーバ２は、ネットワークスイッチ３を介してＤＢサーバ４へアクセスを行なうことで、データベース（ＤＢ）４１を使用する所定のアプリケーションを実行する。
ＤＢサーバ４は、アプリサーバ２が使用するＤＢ４１を管理（格納）するサーバである。ＤＢ４１としては、例えば性能が良く安定性が高いＲＤＢが挙げられる。
アプリサーバ２及びＤＢサーバ４としては、例えばＰＣ（Personal Computer）やサーバ等の情報処理装置が挙げられる。
〔１−２〕アプリサーバ及びＤＢサーバのハードウェア構成例
ここで、図２及び図３を参照して、一実施形態に係るアプリサーバ２及びＤＢサーバ４のハードウェア構成例について説明する。図２は図１に示すアプリサーバ２及びＤＢサーバ４のハードウェア構成例を示す図であり、図３は図２に示すハードウェアの接続例を示す図である。
アプリサーバ２及びＤＢサーバ４としては、例えばＰＣ（Personal Computer）やサーバ等の情報処理装置が挙げられる。
〔１−２〕アプリサーバ及びＤＢサーバのハードウェア構成例
ここで、図２及び図３を参照して、一実施形態に係るアプリサーバ２及びＤＢサーバ４のハードウェア構成例について説明する。図２は図１に示すアプリサーバ２及びＤＢサーバ４のハードウェア構成例を示す図であり、図３は図２に示すハードウェアの接続例を示す図である。
アプリサーバ２及びＤＢサーバ４としての情報処理装置は、それぞれ、図２に示すように、ＣＰＵ（Central Processing Unit）５１，メモリ５２，記憶部５３，インタフェース部５４，入出力部５５，記録媒体５６，及び読取部５７をそなえることができる。なお、図１に示す複数のアプリサーバ２及びＤＢサーバ４は、いずれも同様のハードウェアをそなえることができるため、以下、代表して、１つのアプリサーバ２又は１つのＤＢサーバ４がそなえるハードウェアについて説明する。
ＣＰＵ５１は、図２における対応する各ブロック５２〜５７と接続され、種々の制御や演算を行なう演算処理装置（プロセッサ）である。ＣＰＵ５１は、メモリ５２，記憶部５３、記録媒体５６や５８、又は図示しないＲＯＭ（Read Only Memory）等に格納されたプログラムを実行することにより、アプリサーバ２又はＤＢサーバ４における種々の機能を実現することができる。
メモリ５２は、種々のデータやプログラムを格納する記憶装置である。ＣＰＵ５１は、プログラムを実行する際に、メモリ５２にデータやプログラムを格納し展開する。なお、メモリ５２としては、例えばＲＡＭ（Random Access Memory）等の揮発性メモリが挙げられる。
記憶部５３は、種々のデータやプログラム等を格納するハードウェアである。記憶部５３としては、例えばＨＤＤ（Hard Disk Drive）等の磁気ディスク装置，ＳＳＤ（Solid State Drive）等の半導体ドライブ装置，フラッシュメモリ等の不揮発性メモリ等の各種デバイスが挙げられる。なお、記憶部５３として複数のデバイスが用いられてもよく、これらのデバイスでＲＡＩＤ（Redundant Arrays of Inexpensive Disks）が構成されてもよい。
記憶部５３は、種々のデータやプログラム等を格納するハードウェアである。記憶部５３としては、例えばＨＤＤ（Hard Disk Drive）等の磁気ディスク装置，ＳＳＤ（Solid State Drive）等の半導体ドライブ装置，フラッシュメモリ等の不揮発性メモリ等の各種デバイスが挙げられる。なお、記憶部５３として複数のデバイスが用いられてもよく、これらのデバイスでＲＡＩＤ（Redundant Arrays of Inexpensive Disks）が構成されてもよい。
インタフェース部５４は、有線又は無線による、ネットワーク（図示省略）や他のサーバ２又は４との間の接続及び通信の制御等を行なうものである。インタフェース部５４は、図３に示すネットワークインタフェース５４ａを含んでもよい。インタフェース部５４としては、例えば、ＬＡＮ（Local Area Network），ファイバチャネル（Fibre Channel；ＦＣ），インフィニバンド（InfiniBand）等に準拠したアダプタが挙げられる。
入出力部５５は、マウスやキーボード等の入力装置及びディスプレイやプリンタ等の出力装置の少なくとも一方を含むことができる。例えば、入出力部５５は、アプリサーバ２又はＤＢサーバ４の使用者又は管理者等による種々の作業に用いられる。
記録媒体５６は、例えばフラッシュメモリやＲＯＭ等の記憶装置であり、種々のデータやプログラムを記録することができる。読取部５７は、コンピュータ読取可能な記録媒体５８に記録されたデータやプログラムを読み出す装置である。記録媒体５６及び５８の少なくとも一方には、本実施形態に係るアプリサーバ２又はＤＢサーバ４の各種機能の全部もしくは一部を実現するデータ変換プログラムが格納されてもよい。例えば、ＣＰＵ５１は、記録媒体５６から読み出したプログラム、又は、読取部５７を介して記録媒体５８から読み出したプログラムを、メモリ５２等の記憶装置に展開して実行することができる。これにより、コンピュータ（ＣＰＵ５１，情報処理装置，各種端末を含む）は、上述したアプリサーバ２又はＤＢサーバ４の機能を実現することができる。
記録媒体５６は、例えばフラッシュメモリやＲＯＭ等の記憶装置であり、種々のデータやプログラムを記録することができる。読取部５７は、コンピュータ読取可能な記録媒体５８に記録されたデータやプログラムを読み出す装置である。記録媒体５６及び５８の少なくとも一方には、本実施形態に係るアプリサーバ２又はＤＢサーバ４の各種機能の全部もしくは一部を実現するデータ変換プログラムが格納されてもよい。例えば、ＣＰＵ５１は、記録媒体５６から読み出したプログラム、又は、読取部５７を介して記録媒体５８から読み出したプログラムを、メモリ５２等の記憶装置に展開して実行することができる。これにより、コンピュータ（ＣＰＵ５１，情報処理装置，各種端末を含む）は、上述したアプリサーバ２又はＤＢサーバ４の機能を実現することができる。
なお、記録媒体５８としては、例えばフレキシブルディスク、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ブルーレイディスク等の光ディスクや、ＵＳＢ（Universal Serial Bus）メモリやＳＤカード等のフラッシュメモリが挙げられる。なお、ＣＤとしては、ＣＤ−ＲＯＭ、ＣＤ−Ｒ（CD-Recordable）、ＣＤ−ＲＷ（CD-Rewritable）等が挙げられる。また、ＤＶＤとしては、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ等が挙げられる。
なお、上述した各ブロック５１〜５７間はバスで相互に通信可能に接続される。例えばＣＰＵ５１と記憶部５３との間は、ディスクインタフェース５９（図３参照）を介して接続される。また、アプリサーバ２又はＤＢサーバ４の上述したハードウェア構成は例示である。従って、アプリサーバ２又はＤＢサーバ４内でのハードウェアの増減（例えば任意のブロックの追加や省略），分割，任意の組み合わせでの統合，バスの追加又は省略等は適宜行なわれてもよい。また、アプリサーバ２のハードウェアとＤＢサーバ４のハードウェアとを統合してもよい。さらに、アプリサーバ２間，ＤＢサーバ４間，又はアプリサーバ２とＤＢサーバ４との間で、異なるハードウェア構成が採用されてもよい。
〔１−３〕ＤＢサーバの説明
次に、ＤＢサーバ４について説明する。図４は図１に示すＤＢサーバ４の機能構成例を示す図である。図４に示すように、ＤＢサーバ４は、機能ブロックとして、上記ＤＢ４１のほかに、管理部４２をそなえる。
ＤＢ４１は、アプリケーション２１が利用するデータベースであり、種々のデータを格納する格納部の一例である。ＤＢ４１としては、上述のように、例えば性能が良く安定性が高いＲＤＢが挙げられる。図４に示すように、ＤＢ４１は、１以上の第１テーブル４１２及び１以上の第２テーブル４１４を格納する。なお、第１テーブル４１２は、後述するデータモデル変換エンジン２３によるデータモデルの変換の過程で生成されるテーブルである。従って、ＤＢ４１は、データモデルの変換後には、少なくとも第２テーブル４１４を格納していればよく、第１テーブル４１２を格納していなくてよい。このため、図４では、第１テーブル４１２のブロックを破線で示している。第１テーブル４１２及び第２テーブル４１４の詳細は後述する。
次に、ＤＢサーバ４について説明する。図４は図１に示すＤＢサーバ４の機能構成例を示す図である。図４に示すように、ＤＢサーバ４は、機能ブロックとして、上記ＤＢ４１のほかに、管理部４２をそなえる。
ＤＢ４１は、アプリケーション２１が利用するデータベースであり、種々のデータを格納する格納部の一例である。ＤＢ４１としては、上述のように、例えば性能が良く安定性が高いＲＤＢが挙げられる。図４に示すように、ＤＢ４１は、１以上の第１テーブル４１２及び１以上の第２テーブル４１４を格納する。なお、第１テーブル４１２は、後述するデータモデル変換エンジン２３によるデータモデルの変換の過程で生成されるテーブルである。従って、ＤＢ４１は、データモデルの変換後には、少なくとも第２テーブル４１４を格納していればよく、第１テーブル４１２を格納していなくてよい。このため、図４では、第１テーブル４１２のブロックを破線で示している。第１テーブル４１２及び第２テーブル４１４の詳細は後述する。
管理部４２は、ＤＢ４１に対するアプリサーバ２からのアクセスの管理を行なうものである。アクセスの管理には、アプリサーバ２からの要求に応じた、ＤＢ４１への第１テーブル４１２又は第２テーブル４１４の生成，更新，削除，又は参照等の各種処理が含まれてもよい。
なお、ＤＢサーバ４におけるＤＢ４１は、例えば上述したメモリ５２及び記憶部５３の少なくとも一方により実現され、管理部４２の機能は、例えば上述したＣＰＵ５１がメモリ５２に展開したプログラムを実行することにより実現される。
なお、ＤＢサーバ４におけるＤＢ４１は、例えば上述したメモリ５２及び記憶部５３の少なくとも一方により実現され、管理部４２の機能は、例えば上述したＣＰＵ５１がメモリ５２に展開したプログラムを実行することにより実現される。
〔１−４〕アプリサーバの説明
次に、アプリサーバ２について説明する。図５は図１に示すアプリサーバ２の機能構成例を示す図である。図５に示すように、アプリサーバ２は、機能ブロックとして、アプリケーション２１，ＤＢ接続部２２，及びデータモデル変換エンジン２３をそなえる。なお、アプリケーション２１，ＤＢ接続部２２，及びデータモデル変換エンジン２３の各機能は、例えば上述したＣＰＵ５１がメモリ５２に展開したプログラムを実行することにより実現される。
次に、アプリサーバ２について説明する。図５は図１に示すアプリサーバ２の機能構成例を示す図である。図５に示すように、アプリサーバ２は、機能ブロックとして、アプリケーション２１，ＤＢ接続部２２，及びデータモデル変換エンジン２３をそなえる。なお、アプリケーション２１，ＤＢ接続部２２，及びデータモデル変換エンジン２３の各機能は、例えば上述したＣＰＵ５１がメモリ５２に展開したプログラムを実行することにより実現される。
アプリケーション２１は、入れ子構造を含むツリー（階層）構造のデータモデル（データ形式，第１のデータ形式）を使用してＤＢ４１（図４参照）へアクセスし、所定の機能を実現するソフトウェアである。アプリケーション２１は、例えばＭｏｎｇｏＤＢ等のＤＤＢを用いることができる。
例えば、アプリケーション２１は、提供するサービスにおいてＤＢ４１へアクセスを行なうと判断すると、データモデル変換エンジン２３へ、ＤＢ４１との間の種々のアクセス要求を発行する。アクセス要求としては、例えばＤＢ４１へのドキュメント（オブジェクト）の格納／更新要求（書込要求），ＤＢ４１からのドキュメントの参照要求（読出要求）等が挙げられる。そして、アプリケーション２１は、データモデル変換エンジン２３からの格納／更新要求又は参照要求に対する応答を用いて、サービスの提供を行なう。
例えば、アプリケーション２１は、提供するサービスにおいてＤＢ４１へアクセスを行なうと判断すると、データモデル変換エンジン２３へ、ＤＢ４１との間の種々のアクセス要求を発行する。アクセス要求としては、例えばＤＢ４１へのドキュメント（オブジェクト）の格納／更新要求（書込要求），ＤＢ４１からのドキュメントの参照要求（読出要求）等が挙げられる。そして、アプリケーション２１は、データモデル変換エンジン２３からの格納／更新要求又は参照要求に対する応答を用いて、サービスの提供を行なう。
ＤＢ接続部２２は、ＤＢサーバ４に対するアクセスを行なう。具体的には、ＤＢ接続部２２は、データモデル変換エンジン２３に、ＤＢサーバ４が管理するＲＤＢのデータモデル（表形式，第２のデータ形式）でのＡＰＩ（Application Programming Interface）を提供する。そして、ＤＢ接続部２２は、データモデル変換エンジン２３による格納／更新要求又は参照要求に応じた種々のアクセスをＤＢサーバ４に対して行なう。
データモデル変換エンジン（変換部）２３は、アプリケーション２１とＤＢ接続部２２との間に設けられ、アプリケーション２１が扱うＤＤＢのデータモデルとＤＢサーバ４が扱うＲＤＢのデータモデルとを相互に変換する。例えば、データモデル変換エンジン２３は、第１のデータ形式で入力された入れ子構造を含む階層構造のデータを、複数のテーブルにより当該データを表す第２のデータ形式に変換して、ＤＢ４１へ格納することができる。
〔１−５〕データモデル変換エンジンの説明
以下、データモデル変換エンジン２３について、詳細に説明する。図６は図５に示すデータモデル変換エンジン２３の詳細な構成例を示す図である。図６に示すように、データモデル変換エンジン２３は、機能ブロックとして、アプリケーション側通信部２１０，データベース（ＤＢ）側通信部２２０，書込制御部２３０，及び読出制御部２４０をそなえる。
以下、データモデル変換エンジン２３について、詳細に説明する。図６は図５に示すデータモデル変換エンジン２３の詳細な構成例を示す図である。図６に示すように、データモデル変換エンジン２３は、機能ブロックとして、アプリケーション側通信部２１０，データベース（ＤＢ）側通信部２２０，書込制御部２３０，及び読出制御部２４０をそなえる。
アプリケーション側通信部２１０は、アプリケーション２１との通信を制御するものである。
例えば、アプリケーション側通信部２１０は、アプリケーション２１に対してＤＢサーバ４が管理するＤＢ４１であるＲＤＢとは異なるＤＢ（例えばＤＤＢ）のデータモデルでのＡＰＩを提供する。なお、アプリケーション側通信部２１０は、当該ＡＰＩを介して、アプリケーション２１から、上述した格納／更新要求又は参照要求等のアクセス要求を受け取る。
例えば、アプリケーション側通信部２１０は、アプリケーション２１に対してＤＢサーバ４が管理するＤＢ４１であるＲＤＢとは異なるＤＢ（例えばＤＤＢ）のデータモデルでのＡＰＩを提供する。なお、アプリケーション側通信部２１０は、当該ＡＰＩを介して、アプリケーション２１から、上述した格納／更新要求又は参照要求等のアクセス要求を受け取る。
具体的には、アプリケーション側通信部２１０は、アプリケーション２１からＡＰＩが呼び出されると、当該ＡＰＩが格納／更新要求に係るものであるのか、参照要求に係るものであるのかを判定する。そして、アプリケーション側通信部２１０は、判定の結果、呼び出されたＡＰＩが格納／更新要求に係るものである場合には当該格納／更新要求を書込制御部２３０へ出力する一方、参照要求に係るものである場合には当該参照要求を読出制御部２４０へ出力する。
また、アプリケーション側通信部２１０は、書込制御部２３０によるＤＢ４１へのドキュメント（オブジェクト）の格納／更新結果に応じて、格納／更新要求に対する応答をアプリケーション２１へ出力する。さらに、アプリケーション側通信部２１０は、読出制御部２４０によるＤＢ４１からのオブジェクトの参照結果に応じて、参照要求に対する応答を、ＤＢ４１から取得した参照データ（戻り値）とともにアプリケーション２１へ出力する。
ここで、アプリケーション側通信部２１０がアプリケーション２１に提供するＡＰＩとしては、Ｊａｖａ（登録商標）等のオブジェクト指向言語でのオブジェクト（配列が含まれてもよい）を受け渡しするものが好ましいが、これに限定されるものではない。例えば、アプリケーション側通信部２１０は、アプリケーション２１に、オブジェクトの構造を文字列に変換する形式であるＪＳＯＮ形式（JavaScript Object Notation）の文字列を受け渡しするＡＰＩを提供することができる。
このように、アプリケーション２１に提供されるＡＰＩとしては、情報を失うことなく通信路に乗せることができ、入れ子構造を含むツリー構造のように構造化された形式を表すことができれば、どのようなＡＰＩが用いられてもよい。他の例として、アプリケーション２１にＢＳＯＮ（Binary JSON；転送効率の良いバイナリ型ＪＳＯＮ）形式等のバイナリデータを受け渡しするＡＰＩが提供されてもよい。
以下、説明の簡略化のために、アプリケーション側通信部２１０は、アプリケーション２１にＪＳＯＮ形式の文字列を受け渡しするＡＰＩを提供するものとする。
図７はＤＤＢにおけるドキュメントをＪＳＯＮ形式で表記した例を示す図であり、図８及び図９は、それぞれ図７に示すドキュメントをグラフ形式で表記した例を示す図である。なお、以下の説明において、ドキュメント（オブジェクト），配列を、それぞれマップ，リストと表記する場合がある。
図７はＤＤＢにおけるドキュメントをＪＳＯＮ形式で表記した例を示す図であり、図８及び図９は、それぞれ図７に示すドキュメントをグラフ形式で表記した例を示す図である。なお、以下の説明において、ドキュメント（オブジェクト），配列を、それぞれマップ，リストと表記する場合がある。
図７では、“document-id: 20”及び“document-id: 30”の２つのドキュメントに、それぞれ構造化されたデータが格納される例を示している。図７に示すＪＳＯＮ形式，並びに図８に示す“document-id: 20”のグラフ表記及び図９に示す“document-id: 30”のグラフ表記において、“{}”は子要素（下位の要素）を持つマップを表し、“[]”は子要素を持つリストを表す。マップは、図８及び図９に示すように、子要素と繋がるグラフの辺に文字列を持ち、この文字列がキー（情報要素）である。また、図８及び図９に示すように、各ツリーの頂点は、マップ，リスト，又はそれ以外の文字列を持つ。マップ及びリスト以外の文字列は、値を表す。
例えば、図８に示す“document:20”の最上位の頂点（マップ）の子要素は、“url”をキーとする値“ggg”，“title”をキーとする値“google”，“tags”をキーとする（子要素を持つ）リスト，及び“bookmarks”をキーとする（子要素を持つ）リストである。なお、リストの子要素はキーを持たない。例えば、上記“tags”をキーとするリストの子要素は、値“goo”及び“gle”である。また、上記“bookmarks”をキーとするリストの子要素は、多段の入れ子構造を形成するマップ（キー“user”，キー“comment”，及び子要素にマップを持つリスト、を子要素とするマップ）である。
図７〜図９に示すように、ＪＳＯＮ形式のＡＰＩが提供される場合、アプリケーション２１は、入れ子構造を含むツリー構造のドキュメント（オブジェクト）をＪＳＯＮ形式の文字列に正確に変換することができる。従って、アプリケーション２１は、自身のプログラムで処理されるオブジェクトが持つ情報を失うことなくＪＳＯＮ形式に変換することができるとともに、ＪＳＯＮ形式で表現された文字列から情報を失うことなく自身のプログラムで処理されるオブジェクトに変換することができる。なお、ＪＳＯＮ形式でなくＢＳＯＮ形式のＡＰＩが提供される場合も同様である。
ＤＢ側通信部２２０は、ＤＢ４１側、すなわちＤＢ接続部２２との通信を制御するものであり、上述のようにＤＢ接続部２２が提供するＡＰＩを利用してＤＢサーバ４との通信を行なう。
具体的には、ＤＢ側通信部２２０は、書込制御部２３０からの要求に応じて、ＤＢ４１へのテーブルの格納／更新要求をＤＢ接続部２２へ出力する。また、ＤＢ側通信部２２０は、読出制御部２４０からの要求に応じて、ＤＢ４１からのテーブルの参照要求をＤＢ接続部２２へ出力する。
具体的には、ＤＢ側通信部２２０は、書込制御部２３０からの要求に応じて、ＤＢ４１へのテーブルの格納／更新要求をＤＢ接続部２２へ出力する。また、ＤＢ側通信部２２０は、読出制御部２４０からの要求に応じて、ＤＢ４１からのテーブルの参照要求をＤＢ接続部２２へ出力する。
書込制御部２３０は、アプリケーション側通信部２１０から入力される格納／更新要求に応じて、当該格納／更新要求に係るドキュメントを表形式に変換し、ＤＢ４１へ格納するためにＤＢ側通信部２２０へ出力する。また、書込制御部２３０は、格納／更新結果をアプリケーション側通信部２１０へ出力する。
読出制御部２４０は、アプリケーション側通信部２１０から入力される参照要求に応じて、当該参照要求に係るドキュメントに相当するデータを、ＤＢ側通信部２２０によるアクセスを通じてＤＢ４１内の第２テーブル４１４から取得し、ドキュメントを生成する。そして、読出制御部２４０は、生成したドキュメントを参照要求の戻り値として、参照結果をアプリケーション側通信部２１０へ出力する。
読出制御部２４０は、アプリケーション側通信部２１０から入力される参照要求に応じて、当該参照要求に係るドキュメントに相当するデータを、ＤＢ側通信部２２０によるアクセスを通じてＤＢ４１内の第２テーブル４１４から取得し、ドキュメントを生成する。そして、読出制御部２４０は、生成したドキュメントを参照要求の戻り値として、参照結果をアプリケーション側通信部２１０へ出力する。
なお、データモデル変換エンジン２３は、アプリケーション２１により、ＡＰＩが呼び出されたタイミング、すなわちアクセス要求が発行されたタイミングで動作する。
以下、書込制御部２３０及び読出制御部２４０の詳細な動作について説明する。
〔１−６〕書込制御部の説明
図６に示すように、書込制御部２３０は、格納／更新要求に係るオブジェクト又はオブジェクト内のデータに応じた処理を行なうために、生成部２３２，統合部２３４，及び更新部２３６をそなえる。
以下、書込制御部２３０及び読出制御部２４０の詳細な動作について説明する。
〔１−６〕書込制御部の説明
図６に示すように、書込制御部２３０は、格納／更新要求に係るオブジェクト又はオブジェクト内のデータに応じた処理を行なうために、生成部２３２，統合部２３４，及び更新部２３６をそなえる。
ここで、書込制御部２３０は、格納／更新要求を入力されると、ＤＢ側通信部２２０を介して、ＤＢ４１に、入力されたドキュメントに係る第２テーブル４１４が生成されているか否かを判定する。書込制御部２３０は、ＤＢ４１に第２テーブル４１４が生成されていない場合に生成部２３２及び統合部２３４の処理を実行する一方、第２テーブル４１４が生成されている場合に更新部２３６の処理を実行する。以下、上記判定結果に応じた生成部２３２，統合部２３４，及び更新部２３６の処理について説明する。
〔１−６−１〕ＤＢに第２テーブルが生成されていない場合
はじめに、ＤＢ４１に第２テーブル４１４が生成されていない場合に実行される、生成部２３２及び統合部２３４について説明する。
〔１−６−１−１〕生成部の説明
生成部２３２は、入力された格納／更新要求に係るオブジェクトに対して内部的にデータモデルの変換を行ない、１以上の第１テーブル４１２を生成する。具体的には、生成部２３２は、入力されたＪＳＯＮ形式のツリー構造のオブジェクトを、以下の第１条件に従って、キーごとに、ＤＢサーバ４が管理するＲＤＢのデータモデル、つまり表形式に変換する。そして、生成部２３２は、変換したテーブルを、ＤＢ側通信部２２０を介してＤＢサーバ４へ出力し、１以上の第１テーブル４１２として格納する。
はじめに、ＤＢ４１に第２テーブル４１４が生成されていない場合に実行される、生成部２３２及び統合部２３４について説明する。
〔１−６−１−１〕生成部の説明
生成部２３２は、入力された格納／更新要求に係るオブジェクトに対して内部的にデータモデルの変換を行ない、１以上の第１テーブル４１２を生成する。具体的には、生成部２３２は、入力されたＪＳＯＮ形式のツリー構造のオブジェクトを、以下の第１条件に従って、キーごとに、ＤＢサーバ４が管理するＲＤＢのデータモデル、つまり表形式に変換する。そして、生成部２３２は、変換したテーブルを、ＤＢ側通信部２２０を介してＤＢサーバ４へ出力し、１以上の第１テーブル４１２として格納する。
より具体的に、生成部２３２は、入力されたドキュメントについて、例えば文字列の記述順（ツリーの頂点から子要素に向かって順）にキーを探索し、キーごとに、以下の（ｉ）〜（iv）により定義される第１条件に従って、親要素（上位の要素）名と値とを含むテーブルを生成する。なお、生成部２３２は、生成した第１テーブル４１２のテーブル名に、ツリーの頂点から当該テーブルのキーまでの階層を表す文字列、例えば最上位から当該キーまでを“.”で結合した文字列を設定する。
（ｉ）キーが値を直接持つ場合：生成部２３２は、“（ＵＮＩＱＵＥ属性を持つ）parent”，“value”の２つの列を持つテーブルを生成する。
（ii）キーが、値を直接持つリストを持つ場合：生成部２３２は、“parent”，“value”の２つの列を持つテーブルを生成する。
（iii）キーがマップを持つ場合：生成部２３２は、当該キーについてはテーブルを生成しない。なお、テーブルが生成されない当該キーは、当該キーの下位のマップにおける値を持つキーについて生成部２３２がテーブルを生成する際に、当該テーブルのテーブル名（階層を表す文字列）に含まれることになる。
（ii）キーが、値を直接持つリストを持つ場合：生成部２３２は、“parent”，“value”の２つの列を持つテーブルを生成する。
（iii）キーがマップを持つ場合：生成部２３２は、当該キーについてはテーブルを生成しない。なお、テーブルが生成されない当該キーは、当該キーの下位のマップにおける値を持つキーについて生成部２３２がテーブルを生成する際に、当該テーブルのテーブル名（階層を表す文字列）に含まれることになる。
（iv）キーが、マップを持つリストを持つ場合：生成部２３２は、“parent”，“（ＵＮＩＱＵＥ属性及びＡＵＴＯ＿ＩＮＣＲＥＭＥＮＴ属性を持つ）id”の２つの列を持つテーブルを生成する。例えば生成部２３２は、重複しない昇順の“id”を生成する。
ここで、生成部２３２による上記（ｉ）〜（iv）の第１条件の具体的な判定手法の一例を、図７に示すようなＪＳＯＮ形式のドキュメントを例に挙げて説明する。
ここで、生成部２３２による上記（ｉ）〜（iv）の第１条件の具体的な判定手法の一例を、図７に示すようなＪＳＯＮ形式のドキュメントを例に挙げて説明する。
はじめに、生成部２３２は、変換対象のドキュメント（マップ）のＩＤを取得する。例えば生成部２３２は、ドキュメントの先頭から最初のマップの開始までの文字列（情報）“document-id: xx {”（“xx”は任意の文字列）を抽出し、“parent=xx”をメモリ５２等に記憶する。
次いで、生成部２３２は、直前に抽出した位置から、キーと当該キーの構造とを識別するのに用いる所定の情報を検出するまで、所定の文字列（情報）を抽出する。なお、所定の情報としては、例えば“,”（カンマ），“｛”（マップの開始），“document-id:”
（次のドキュメントの開始），ドキュメント（データ）内の最後の“｝”等が挙げられる。そして、生成部２３２は、抽出した文字列に係るキーが上記（ｉ）〜（iv）のいずれに該当するかを以下のように判定する。
次いで、生成部２３２は、直前に抽出した位置から、キーと当該キーの構造とを識別するのに用いる所定の情報を検出するまで、所定の文字列（情報）を抽出する。なお、所定の情報としては、例えば“,”（カンマ），“｛”（マップの開始），“document-id:”
（次のドキュメントの開始），ドキュメント（データ）内の最後の“｝”等が挙げられる。そして、生成部２３２は、抽出した文字列に係るキーが上記（ｉ）〜（iv）のいずれに該当するかを以下のように判定する。
（Ａ）抽出した文字列の末尾が“,”又はドキュメント（データ）内の最後の“｝”である場合。
（Ａ−１）（Ａ）において、抽出した文字列中に“[”（リストの開始）が含まれる場合：生成部２３２は、キーは「値を直接持つリストを持つキー」（上記（ii）に対応）であると判断する。
（Ａ−１）（Ａ）において、抽出した文字列中に“[”（リストの開始）が含まれる場合：生成部２３２は、キーは「値を直接持つリストを持つキー」（上記（ii）に対応）であると判断する。
（Ａ−２）（Ａ−１）に該当しない場合において、１つ前に抽出した文字列中のキーについて「値を直接持つリストを持つ」と判断した場合。
（Ａ−２−１）（Ａ−２）において、１つ前に抽出した文字列でリストが閉じられている場合：生成部２３２は、キーは「値を直接持つキー」（上記（ｉ）に対応）であると判断する。
（Ａ−２−１）（Ａ−２）において、１つ前に抽出した文字列でリストが閉じられている場合：生成部２３２は、キーは「値を直接持つキー」（上記（ｉ）に対応）であると判断する。
（Ａ−２−２）（Ａ−２−１）に該当しない場合：生成部２３２は、キーは「値を直接持つリストを持つキー」（上記（ii）に対応）であると判断する。
（Ａ−３）（Ａ−２）に該当しない場合：生成部２３２は、キーは「値を直接持つキー」（上記（ｉ）に対応）であると判断する。
（Ｂ）抽出した文字列の末尾が“｛”である場合。
（Ａ−３）（Ａ−２）に該当しない場合：生成部２３２は、キーは「値を直接持つキー」（上記（ｉ）に対応）であると判断する。
（Ｂ）抽出した文字列の末尾が“｛”である場合。
（Ｂ−１）（Ｂ）において、抽出した文字列中に“[”（リストの開始）が含まれる場合：生成部２３２は、キーは「マップを持つリストを持つキー」（上記（iv）に対応）であると判断する。
（Ｂ−２）（Ｂ−１）に該当しない場合において、１つ前に抽出した文字列中のキーについて「値を直接持つリストを持つ」と判断した場合。
（Ｂ−２）（Ｂ−１）に該当しない場合において、１つ前に抽出した文字列中のキーについて「値を直接持つリストを持つ」と判断した場合。
（Ｂ−２−１）（Ｂ−２）において、１つ前に抽出した文字列でリストが閉じられている場合：生成部２３２は、キーは「マップを持つキー」（上記（iii）に対応）であると判断する。
（Ｂ−２−２）（Ｂ−２−１）に該当しない場合：生成部２３２は、キーは「マップを持つリストを持つキー」（上記（iv）に対応）であると判断する。
（Ｂ−２−２）（Ｂ−２−１）に該当しない場合：生成部２３２は、キーは「マップを持つリストを持つキー」（上記（iv）に対応）であると判断する。
なお、上記（ｉ）〜（iv）において、生成部２３２は、生成するテーブルの“parent”に、キーが最上位の場合には“document-id”の値“xx”を設定し、キーが最上位ではない場合には上位のキーに対応するテーブルにおける“id”を設定する。また、生成部２３２は、生成するテーブルの“value”には当該キーの値を格納する。
以上のように、生成部２３２は、入力されるドキュメントに含まれる複数のキーについて、それぞれ対応するテーブル４１２ａ〜４１２ｉ（第１テーブル４１２）を生成／更新し、ＤＢ側通信部２２０を介してＤＢ４１に格納／更新する。このとき、生成部２３２は、複数の第１テーブル４１２の各々におけるキーの種類に応じた列に、他の第１テーブル４１２の参照情報を設定することで、複数の第１テーブル４１２の各々を対応する他の第１テーブル４１２と関係付けることができる。
以上のように、生成部２３２は、入力されるドキュメントに含まれる複数のキーについて、それぞれ対応するテーブル４１２ａ〜４１２ｉ（第１テーブル４１２）を生成／更新し、ＤＢ側通信部２２０を介してＤＢ４１に格納／更新する。このとき、生成部２３２は、複数の第１テーブル４１２の各々におけるキーの種類に応じた列に、他の第１テーブル４１２の参照情報を設定することで、複数の第１テーブル４１２の各々を対応する他の第１テーブル４１２と関係付けることができる。
〔１−６−１−２〕統合部の説明
統合部２３４は、生成部２３２によるＤＢ４１への複数の第１テーブル４１２の生成／更新が完了すると、統合可能なテーブル４１２ａ〜４１２ｉを１以上の第２テーブル４１４として統合する。具体的には、統合部２３４は、複数の第１テーブル４１２のうちの以下の第２条件を満たす第１テーブル４１２のグループを第２テーブル４１４として統合する。
統合部２３４は、生成部２３２によるＤＢ４１への複数の第１テーブル４１２の生成／更新が完了すると、統合可能なテーブル４１２ａ〜４１２ｉを１以上の第２テーブル４１４として統合する。具体的には、統合部２３４は、複数の第１テーブル４１２のうちの以下の第２条件を満たす第１テーブル４１２のグループを第２テーブル４１４として統合する。
例えば、統合部２３４は、複数の第１テーブル４１２のうちの２以上の第１テーブル４１２が以下の（Ｉ）及び（II）の双方を満たす場合に、当該２以上の第１テーブル４１２が第２条件を満たすと判断する。そして、統合部２３４は、当該２以上の第１テーブル４１２を１つの第２テーブル４１４にまとめる。
（Ｉ）各第１テーブル４１２の属する階層が所定の関係にあること。具体的には、２以上の第１テーブル４１２が同一階層にあると見做せること。より具体的に、２以上の第１テーブル４１２が以下の（Ｉ−１）又は（Ｉ−２）を満たすこと。
（Ｉ）各第１テーブル４１２の属する階層が所定の関係にあること。具体的には、２以上の第１テーブル４１２が同一階層にあると見做せること。より具体的に、２以上の第１テーブル４１２が以下の（Ｉ−１）又は（Ｉ−２）を満たすこと。
（Ｉ−１）いずれも「値を直接持つキー」に基づき生成されたテーブルである場合：それぞれ同一のマップに属する別のキーに基づき生成されたテーブルであること。
（Ｉ−２）それぞれ「値を直接持つキー」及び「マップを持つリストを持つキー」に基づき生成されたテーブルである場合：当該「値を直接持つキー」が当該「マップを持つリストを持つキー」のリストに含まれること。
（Ｉ−２）それぞれ「値を直接持つキー」及び「マップを持つリストを持つキー」に基づき生成されたテーブルである場合：当該「値を直接持つキー」が当該「マップを持つリストを持つキー」のリストに含まれること。
（II）２以上の第１テーブル４１２の構造が所定の関係にあること。具体的には、２以上の第１テーブル４１２が同じ構造であると見做せること。より具体的に、２以上の第１テーブル４１２が以下の（II−１）〜（II−３）のいずれかを満たすこと。
（II−１）いずれも「値を直接持つキー」に基づき生成されたテーブルであること。
（II−２）いずれも「マップを持つリストを持つキー」に基づき生成されたテーブルであること。
（II−１）いずれも「値を直接持つキー」に基づき生成されたテーブルであること。
（II−２）いずれも「マップを持つリストを持つキー」に基づき生成されたテーブルであること。
（II−３）それぞれ「値を直接持つキー」及び「マップを持つリストを持つキー」に基づき生成されたテーブルであること。
なお、統合部２３４は、第２テーブル４１４のテーブル名に、第２条件を満たすと判断した２以上の第１テーブル４１２の各階層を表す文字列、例えば各第１テーブル４１２のテーブル名で共通な部分と共通ではない部分とを“_”で結合した文字列を設定する。また、統合部２３４は、第２テーブル４１４には、各第１テーブル４１２における“parent”，“id”の列名を、それぞれ“_parent”，“_id”に変更して設定する。これは、キーとの名前の重複を避けるためである。さらに、統合部２３４は、第２テーブル４１４には、各第１テーブル４１２における“value”の列名を、キーの名前に変更して設定する。
なお、統合部２３４は、第２テーブル４１４のテーブル名に、第２条件を満たすと判断した２以上の第１テーブル４１２の各階層を表す文字列、例えば各第１テーブル４１２のテーブル名で共通な部分と共通ではない部分とを“_”で結合した文字列を設定する。また、統合部２３４は、第２テーブル４１４には、各第１テーブル４１２における“parent”，“id”の列名を、それぞれ“_parent”，“_id”に変更して設定する。これは、キーとの名前の重複を避けるためである。さらに、統合部２３４は、第２テーブル４１４には、各第１テーブル４１２における“value”の列名を、キーの名前に変更して設定する。
また、統合部２３４は、統合可能な２以上の第１テーブル４１２のグループのうち、いずれかの第１テーブル４１２を元にして、第２テーブル４１４を生成してもよい。この場合、統合部２３４は、当該第１テーブル４１２のテーブル名や列名を変更するとともに、当該第１テーブル４１２に当該グループの他の第１テーブル４１２の内容を追加すればよい。或いは、統合部２３４は、当該グループの第１テーブル４１２の内容を統合した第２テーブル４１４を新たに生成してもよい。いずれの場合においても、統合部２３４は、ＤＢ４１の記憶領域の確保のため、第２テーブル４１４に内容が含まれることになった第１テーブル４１２を削除することが好ましい。
さらに、統合部２３４は、第２条件を満たさないと判断した第１テーブル４１２については統合を行なわないが、当該第１テーブル４１２についても列名の変更を行なう。以下の説明では、便宜上、統合を行なわずに列名の変更のみを行なった第１テーブル４１２についても、第２テーブル４１４と表記する。
以上のように、統合部２３４は、複数の第１テーブル４１２のうちの第２条件を満たす第１テーブル４１２のグループについて、ＤＢサーバ４が扱うＲＤＢに適した第２テーブル４１４として統合する。
以上のように、統合部２３４は、複数の第１テーブル４１２のうちの第２条件を満たす第１テーブル４１２のグループについて、ＤＢサーバ４が扱うＲＤＢに適した第２テーブル４１４として統合する。
上述した統合部２３４によれば、複数の第１テーブル４１２のうち、階層構造におけるキーの属する階層及び当該キーの種類がそれぞれ所定の関係にある第１テーブル４１２同士を統合することができる。これにより、統合部２３４は、統合する第１テーブル４１２を、所定の関係（第２条件）に基づいて容易に特定することができる。
また、統合部２３４によれば、複数の第１テーブル４１２の各々のテーブル名に基づき、キーの属する階層が互いに所定の関係にある第１テーブル４１２を検出することができる。さらに、統合部２３４は、複数の第１テーブル４１２の各々における、キーの種類に応じた列に基づき、キーの種類が互いに所定の関係にある第１テーブル４１２を検出することができる。このように、統合部２３４は、統合の処理において、他の情報を参照せずに、第１テーブル４１２に関する情報に基づき、第１テーブル４１２の統合の有無や統合先の第１テーブル４１２を判定できる。
また、統合部２３４によれば、複数の第１テーブル４１２の各々のテーブル名に基づき、キーの属する階層が互いに所定の関係にある第１テーブル４１２を検出することができる。さらに、統合部２３４は、複数の第１テーブル４１２の各々における、キーの種類に応じた列に基づき、キーの種類が互いに所定の関係にある第１テーブル４１２を検出することができる。このように、統合部２３４は、統合の処理において、他の情報を参照せずに、第１テーブル４１２に関する情報に基づき、第１テーブル４１２の統合の有無や統合先の第１テーブル４１２を判定できる。
従って、統合部２３４によれば、データモデル変換エンジン２３による変換速度を向上できるため、情報処理システム１によるＤＢ４１へのアクセス性能を向上させることができる。
〔１−６−１−３〕生成部及び統合部の処理の具体例
次に、上述した生成部２３２及び統合部２３４の処理を、図１０〜図１３を参照しながら具体例を挙げて説明する。図１０及び図１１は、それぞれ図６に示す生成部２３２が生成する第１テーブル４１２の一例を示す図であり、図１２及び図１３は、それぞれ図６に示す統合部２３４が生成する第２テーブル４１４の一例を示す図である。
〔１−６−１−３〕生成部及び統合部の処理の具体例
次に、上述した生成部２３２及び統合部２３４の処理を、図１０〜図１３を参照しながら具体例を挙げて説明する。図１０及び図１１は、それぞれ図６に示す生成部２３２が生成する第１テーブル４１２の一例を示す図であり、図１２及び図１３は、それぞれ図６に示す統合部２３４が生成する第２テーブル４１４の一例を示す図である。
なお、図１０及び図１１では、生成部２３２による変換対象のドキュメント（マップ）が、図７に示す“document-id: 20”及び“document-id: 30”の２つのドキュメントであるものとする。また、図１２及び図１３では、統合部２３４が、図１０及び図１１に示すテーブル４１２ａ〜４１２ｉに基づいて、第２テーブル４１４を生成するものとする。さらに、図１０及び図１１の各テーブル４１２ａ〜４１２ｉにおいて、テーブル名，列（カラム）名，及び各レコードに付された“Ｔ”で始まる符号は、生成部２３２による第１テーブル４１２の生成又はレコードの追加の処理順序を示す。なお、この処理順序は、入力されたドキュメントの文字列の順序に対応するものであるが、当該処理順序はこれに限定されるものではない。
まず、生成部２３２の処理について説明する。
はじめに、生成部２３２は、変換対象のドキュメント（マップ）のＩＤとして、“document-id: 20 {”を抽出し、“parent=20”をメモリ５２等に記憶する（処理Ｔ１，図示省略）。
次いで、生成部２３２は、“url: “ggg”,”を抽出し、上記（Ａ−３）の論理で、キー“url”は「値を直接持つキー」であると判断する。そして、生成部２３２は、第１条件のうちの上記（ｉ）に基づき、“（ＵＮＩＱＵＥ属性を持つ）parent”，“value”の２つの列を持つ“url”という名前のテーブル４１２ａを生成する。また、生成部２３２は、テーブル４１２ａのうち、“parent”にはキーが最上位であるため処理Ｔ１で記憶した“20”を、“value”にキーの値“ggg”を格納する（処理Ｔ２）。
はじめに、生成部２３２は、変換対象のドキュメント（マップ）のＩＤとして、“document-id: 20 {”を抽出し、“parent=20”をメモリ５２等に記憶する（処理Ｔ１，図示省略）。
次いで、生成部２３２は、“url: “ggg”,”を抽出し、上記（Ａ−３）の論理で、キー“url”は「値を直接持つキー」であると判断する。そして、生成部２３２は、第１条件のうちの上記（ｉ）に基づき、“（ＵＮＩＱＵＥ属性を持つ）parent”，“value”の２つの列を持つ“url”という名前のテーブル４１２ａを生成する。また、生成部２３２は、テーブル４１２ａのうち、“parent”にはキーが最上位であるため処理Ｔ１で記憶した“20”を、“value”にキーの値“ggg”を格納する（処理Ｔ２）。
また、生成部２３２は、“title: “google”,”について、処理Ｔ２と同様に、キー“title”は「値を直接持つキー」であると判断する。そして、生成部２３２は、“（ＵＮＩＱＵＥ属性を持つ）parent”，“value”の２つの列を持つ“title”という名前のテーブル４１２ｂを生成する。また、生成部２３２は、テーブル４１２ｂのうち、“parent”にはキーが最上位であるため処理Ｔ１で記憶した“document-id”の“20”を、“value”にキーの値“google”を格納する（処理Ｔ３）。
次に、生成部２３２は、“tags: [“goo”,”を抽出し、上記（Ａ−１）の論理で、キー“tags”は「値を直接持つリストを持つキー」であると判断する。そして、生成部２３２は、第１条件のうちの上記（ii）に基づき、ＵＮＩＱＵＥ属性を持たない“parent”，“value”の２つの列を持つ“tags”という名前のテーブル４１２ｃを生成する。また、生成部２３２は、テーブル４１２ｃのうち、“parent”にはキーが最上位であるため処理Ｔ１で記憶した“20”を、“value”にキーの値“goo”を格納する（処理Ｔ４）。
また、生成部２３２は、““gle”],”を抽出し、上記（Ａ−２−２）の論理で、キーは「値を直接持つリストを持つキー」であると判断する。なお、““gle”],”のキーは、処理Ｔ４で抽出したキー“tags”である。そして、生成部２３２は、処理Ｔ４で生成した“tags”という名前のテーブル４１２ｃのうち、“parent”にはキーが最上位であるため処理Ｔ１で記憶した“20”を、“value”にキーの値“gle”を格納する（処理Ｔ５）。
次いで、生成部２３２は、“bookmarks: [{”を抽出し、上記（Ｂ−１）の論理で、キー“bookmarks”は「マップを持つリストを持つキー」であると判断する。そして、生成部２３２は、第１条件のうちの上記（iv）に基づき、“parent”，“（ＵＮＩＱＵＥ属性及びＡＵＴＯ＿ＩＮＣＲＥＭＥＮＴ属性を持つ）id”の２つの列を持つ“bookmarks”という名前のテーブル４１２ｄを生成する。また、生成部２３２は、テーブル４１２ｄのうち、“parent”にはキーが最上位であるため処理Ｔ１で記憶した“20”を、“id”に自動生成された“0”を格納する（処理Ｔ６）。
また、生成部２３２は、“user: “userA”,”について、処理Ｔ３と同様に、キー“user”は「値を直接持つキー」であると判断する。そして、生成部２３２は、“（ＵＮＩＱＵＥ属性を持つ）parent”，“value”の２つの列を持つ“bookmarks.user”という名前のテーブル４１２ｅを生成する。また、生成部２３２は、テーブル４１２ｅのうち、“parent”には、キーが最上位ではないため、キー“user”の親要素に対応するテーブル４１２ｄで生成された“id”の“0”を、“value”にはキー“user”の値“userA”を格納する（処理Ｔ７）。
さらに、生成部２３２は、“comment: “search engine”,”について、処理Ｔ７と同様に、キー“comment”は「値を直接持つキー」であると判断する。そして、生成部２３２は、“（ＵＮＩＱＵＥ属性を持つ）parent”，“value”の２つの列を持つ“bookmarks.comment”という名前のテーブル４１２ｆを生成する。また、生成部２３２は、テーブル４１２ｆのうち、“parent”には、キーが最上位ではないため、キー“comment”の親要素に対応するテーブル４１２ｄで生成された“id”の“0”を、“value”にはキー“comment”の値“search engine”を格納する（処理Ｔ８）。
次に、生成部２３２は、“tags: [{”について、処理Ｔ６と同様に、キー“tags”は「マップを持つリストを持つキー」であると判断する。そして、生成部２３２は、“parent”，“（ＵＮＩＱＵＥ属性及びＡＵＴＯ＿ＩＮＣＲＥＭＥＮＴ属性を持つ）id”の２つの列を持つ“bookmarks.tags”という名前のテーブル４１２ｇを生成する。また、生成部２３２は、テーブル４１２ｇのうち、“parent”には、キーが最上位ではないため、キー“tags”の親要素に対応するテーブル４１２ｄで生成された“id”の“0”を、“id”に自動生成された“0”を格納する（処理Ｔ９）。
さらに、生成部２３２は、“tag: “search”,”について、処理Ｔ８と同様に、キー“tag”は「値を直接持つキー」であると判断する。そして、生成部２３２は、“（ＵＮＩＱＵＥ属性を持つ）parent”，“value”の２つの列を持つ“bookmarks.tags.tag”という名前のテーブル４１２ｈを生成する。また、生成部２３２は、テーブル４１２ｈのうち、“parent”には、キーが最上位ではないため、キー“tag”の親要素に対応するテーブル４１２ｇで生成された“id”の“0”を、“value”にはキー“tag”の値“search”を格納する（処理Ｔ１０）。
次いで、生成部２３２は、“chars: [“s”,”について、処理Ｔ４と同様に、キー“chars”は「値を直接持つリストを持つキー」であると判断する。そして、生成部２３２は、ＵＮＩＱＵＥ属性を持たない“parent”，“value”の２つの列を持つ“bookmarks.tags.chars”という名前のテーブル４１２ｉを生成する。また、生成部２３２は、テーブル４１２ｉのうち、“parent”には、キーが最上位ではないため、キー“chars”の親要素に対応するテーブル４１２ｇで生成された“id”の“0”を、“value”にはキー“chars”の値“s”を格納する（処理Ｔ１１）。
処理Ｔ１２〜Ｔ４４においても、生成部２３２は、既に生成されているテーブル４１２ａ〜４１２ｉに対して、上述した処理と同様に、レコードを追加してテーブル４１２ａ〜４１２ｉを更新する。
なお、テーブル４１２ｅ，４１２ｆ，又は４１２ｉにレコードを追加する際には、その都度、親要素に対応するテーブル４１２ｄ又は４１２ｈにレコードを追加して“id”を自動生成させる。そして、テーブル４１２ｅ，４１２ｆ，又は４１２ｉに追加するレコードの“parent”に、親要素に対応するテーブル４１２ｄ又は４１２ｈで自動生成された“id”を追加すればよい。
なお、テーブル４１２ｅ，４１２ｆ，又は４１２ｉにレコードを追加する際には、その都度、親要素に対応するテーブル４１２ｄ又は４１２ｈにレコードを追加して“id”を自動生成させる。そして、テーブル４１２ｅ，４１２ｆ，又は４１２ｉに追加するレコードの“parent”に、親要素に対応するテーブル４１２ｄ又は４１２ｈで自動生成された“id”を追加すればよい。
また、生成部２３２は、処理Ｔ２９において、ドキュメント（データ）“document-id: 20”内の最後の“｝”を検出すると、入力された格納／更新要求に他のドキュメントが含まれているか否かを判断する。他のドキュメント（例えば“document-id: 30”）がある場合、生成部２３２は、処理Ｔ１と同様に、“parent=30”をメモリ５２等に記憶する（処理Ｔ３０，図示省略）。そして、生成部２３２は、“document-id: 30”内の処理である処理Ｔ３１〜Ｔ４４において、キーが最上位であるテーブル４１２ａ〜４１２ｃにレコードを追加する際には、“parent”に処理Ｔ３０で記憶した“30”を格納する。
次に、統合部２３４の処理について説明する。
統合部２３４は、生成部２３２が生成したテーブル４１２ａ〜４１２ｉから、２つのテーブルを順に抽出して第２条件を満たすか否かを判断し、第２条件を満たす組（グループ）を、図１２及び図１３に示すような第２テーブル４１４として統合する。
例えば、統合部２３４は、図１０のテーブル４１２ａ及び４１２ｂが、いずれもトップレベルにあり、「直接値を持つキー」に基づくテーブルであるため（上記（Ｉ−１）及び（ＩＩ−１）参照）、第２条件を満たすと判断する。そして、統合部２３４は、テーブル４１２ａ及び４１２ｂを１つの第２テーブル４１４にまとめる（図１２のテーブル４１４ａ参照）。このとき、統合部２３４は、テーブル４１２ａ及び４１２ｂのテーブル名に共通部分がないため、テーブル４１４ａのテーブル名には、テーブル４１２ａ及び４１２ｂのテーブル名を“_”で結合した文字列を設定する。また、統合部２３４は、テーブル４１４ａの列名として、テーブル４１２ａ及び４１２ｂの列名“parent”を“_parent”に、テーブル４１２ａの列名“value”を“url”に、テーブル４１２ｂの列名“value”を“title”にそれぞれ変更した文字列を設定する。
統合部２３４は、生成部２３２が生成したテーブル４１２ａ〜４１２ｉから、２つのテーブルを順に抽出して第２条件を満たすか否かを判断し、第２条件を満たす組（グループ）を、図１２及び図１３に示すような第２テーブル４１４として統合する。
例えば、統合部２３４は、図１０のテーブル４１２ａ及び４１２ｂが、いずれもトップレベルにあり、「直接値を持つキー」に基づくテーブルであるため（上記（Ｉ−１）及び（ＩＩ−１）参照）、第２条件を満たすと判断する。そして、統合部２３４は、テーブル４１２ａ及び４１２ｂを１つの第２テーブル４１４にまとめる（図１２のテーブル４１４ａ参照）。このとき、統合部２３４は、テーブル４１２ａ及び４１２ｂのテーブル名に共通部分がないため、テーブル４１４ａのテーブル名には、テーブル４１２ａ及び４１２ｂのテーブル名を“_”で結合した文字列を設定する。また、統合部２３４は、テーブル４１４ａの列名として、テーブル４１２ａ及び４１２ｂの列名“parent”を“_parent”に、テーブル４１２ａの列名“value”を“url”に、テーブル４１２ｂの列名“value”を“title”にそれぞれ変更した文字列を設定する。
また、統合部２３４は、図１０のテーブル４１２ｃには同一階層であって同じ構造の第１テーブル４１２がないため、第２条件を満たさないと判断し、テーブル４１２ｃの統合を行なわない。このとき、統合部２３４は、テーブル名を変更せずにテーブル４１２ｃを第２テーブル４１４とする（図１２のテーブル４１４ｂ参照）。また、統合部２３４は、テーブル４１４ｂの列名として、テーブル４１２ｃの列名“parent”を“_parent”に、テーブル４１２ｃの列名“value”を“tags”にそれぞれ変更する。
さらに、統合部２３４は、図１０のテーブル４１２ｄ及び４１２ｅがそれぞれ「マップを持つリストを持つキー」，「直接値を持つキー」に基づくテーブルであり、一方のキーが他方のキーに含まれると判断する（上記（Ｉ−２）及び（II−３）参照）。同様に、統合部２３４は、図１０のテーブル４１２ｄ及び４１２ｆについてもテーブル４１２ｄ及び４１２ｅと同様の判断をする。なお、この場合、テーブル４１２ｅ及び４１２ｆは、同一階層にあり、いずれも「マップを持つリストを持つキー」である（上記（Ｉ−１）及び（II−２）参照）。このように、統合部２３４は、図１０のテーブル４１２ｄ，４１２ｅ，及び４１２ｆが第２条件を満たすと判断し、テーブル４１２ｄ〜４１２ｆを１つの第２テーブル４１４にまとめる（図１２のテーブル４１４ｃ参照）。
このとき、統合部２３４は、テーブル４１２ｄ〜４１２ｆのテーブル名のうち“bookmarks”が共通のため、テーブル４１４ｃのテーブル名には、“bookmarks”と“.user”及び“.comment”をそれぞれ“_”で結合した“bookmarks_.user_.comment”を設定する。また、統合部２３４は、テーブル４１４ｃの列名として、テーブル４１２ｄ〜４１２ｆの列名“parent”を“_parent”に、テーブル４１２ｄの列名“id”を“_id”にそれぞれ変更した文字列を設定する。さらに、統合部２３４は、テーブル４１４ｃの列名として、テーブル４１２ｅの列名“value”を“user”に、テーブル４１２ｆの列名“value”を“comment”にそれぞれ変更した文字列を設定する。
なお、統合部２３４は、図１１のテーブル４１２ｇ及び４１２ｈについても、テーブル４１２ｄ及び４１２ｅと同様の判断により、第２テーブル４１４にまとめる（図１２のテーブル４１４ｄ参照）。
また、統合部２３４は、図１１のテーブル４１２ｉについては、テーブル４１２ｃと同様の判断により、統合を行なわず、列名の変更を行ない、テーブル４１２ｉを第２テーブル４１４とする（図１３のテーブル４１４ｅ参照）。
また、統合部２３４は、図１１のテーブル４１２ｉについては、テーブル４１２ｃと同様の判断により、統合を行なわず、列名の変更を行ない、テーブル４１２ｉを第２テーブル４１４とする（図１３のテーブル４１４ｅ参照）。
以上のように、生成部２３２及び統合部２３４の処理によって、入力されたＤＤＢに係るデータが、ＲＤＢのデータモデルに変換される。
〔１−６−２〕ＤＢに第２テーブルが生成されている場合
次に、ＤＢ４１に第２テーブル４１４が格納されている状態で実行される、更新部２３６について説明する。
〔１−６−２〕ＤＢに第２テーブルが生成されている場合
次に、ＤＢ４１に第２テーブル４１４が格納されている状態で実行される、更新部２３６について説明する。
〔１−６−２−１〕更新部の説明
更新部２３６は、データモデル変換後の第２テーブル４１４に対して、入力されたドキュメントの書込を行なう。具体的には、更新部２３６は、入力されたドキュメントについて、例えば文字列の記述順（ツリーの頂点から子要素に向かって順）にキーを探索し、キーごとに、対応する第２テーブル４１４を更新する。
更新部２３６は、データモデル変換後の第２テーブル４１４に対して、入力されたドキュメントの書込を行なう。具体的には、更新部２３６は、入力されたドキュメントについて、例えば文字列の記述順（ツリーの頂点から子要素に向かって順）にキーを探索し、キーごとに、対応する第２テーブル４１４を更新する。
より具体的に、更新部２３６は、全ての第２テーブル４１４を列挙し、探索したキーを含む第２テーブル４１４、すなわちテーブル名を“_”の箇所で分割したときに、探索したキーの名前と完全一致するものがある第２テーブル４１４を特定する。
そして、更新部２３６は、探索したキーを含む（特定した）更新対象の第２テーブル４１４に対して、以下の（１）〜（４）により定義される第３条件に従って更新を行なう。
そして、更新部２３６は、探索したキーを含む（特定した）更新対象の第２テーブル４１４に対して、以下の（１）〜（４）により定義される第３条件に従って更新を行なう。
（１）探索したキーが値を直接持つ場合：更新部２３６は、更新対象の第２テーブル４１４における“_parent”列が探索したキーの“parent”と一致する行（レコード）において、キー名の列に当該キーの値を書き込む。なお、当該行がなければ、更新部２３６は、新たに当該行を作成（追加）して上記値を書き込む。
（２）探索したキーが、値を直接持つリストを持つ場合：更新部２３６は、更新対象の第２テーブル４１４において、“_parent”列に探索したキーの“parent”を、キー名の列に当該キーの値を持つ行を作成（追加）する。
（２）探索したキーが、値を直接持つリストを持つ場合：更新部２３６は、更新対象の第２テーブル４１４において、“_parent”列に探索したキーの“parent”を、キー名の列に当該キーの値を持つ行を作成（追加）する。
（３）探索したキーがマップを持つ場合：更新部２３６は、当該キーについては第２テーブル４１４の更新を行なわないテーブルを生成しない。
（４）探索したキーが、マップを持つリストを持つ場合：更新部２３６は、更新対象の第２テーブル４１４の“_parent”列が探索したキーの“parent”と一致する行において、キー名の列に当該キーの値を書き込む。なお、当該行がなければ、更新部２３６は、新たに当該行を作成（追加）して上記値を書き込む。
（４）探索したキーが、マップを持つリストを持つ場合：更新部２３６は、更新対象の第２テーブル４１４の“_parent”列が探索したキーの“parent”と一致する行において、キー名の列に当該キーの値を書き込む。なお、当該行がなければ、更新部２３６は、新たに当該行を作成（追加）して上記値を書き込む。
なお、更新部２３６は、生成部２３２による上記（Ａ）及び（Ｂ）の判定と同様の手法により、探索したキーが上記（１）〜（４）のいずれに該当するかを判定することができる。
以上のように、更新部２３６は、入力されるオブジェクトに含まれる複数のキーについてそれぞれ対応する第２テーブル４１４を特定し、特定した第２テーブル４１４を第３条件に従って対応するキーにより更新する。
以上のように、更新部２３６は、入力されるオブジェクトに含まれる複数のキーについてそれぞれ対応する第２テーブル４１４を特定し、特定した第２テーブル４１４を第３条件に従って対応するキーにより更新する。
上述した更新部２３６によれば、対応する第２テーブル４１４が存在する状態で第１のデータ形式で入力された入れ子構造を含む階層構造の更新データから、更新データのキーごとに当該キーの値を抽出することができる。そして、更新部２３６によれば、抽出したキーの値に基づいて、対応する第２テーブル４１４を更新することができる。このように、予め第２テーブル４１４がＤＢ４１に格納されている場合には、更新部２３６により、第１のデータ形式で入力されたドキュメント（更新データ）を、第２のデータ形式で表された第２テーブル４１４へ直接書き込むことができる。従って、更新部２３６によれば、データモデル変換エンジン２３による変換速度を向上できるため、情報処理システム１によるＤＢ４１へのアクセス性能を向上させることができる。
〔１−６−２−２〕更新部の処理の具体例
次に、上述した更新部２３６の処理を、図１４〜図１６を参照しながら具体例を挙げて説明する。図１４は図６に示す更新部２３６により更新される第２テーブル４１４の一例を示す図であり、図１５及び図１６は、それぞれ図１４に示す第２テーブル４１４の更新後の一例を示す図である。なお、前提として、図１４では、生成部２３２及び統合部２３４により、図７に示す“document-id: 20”のドキュメントのみが第２テーブル４１４に変換されているものとする。また、図１５及び図１６では、格納／更新要求により図７に示す“document-id: 30”のドキュメントが新たに書込制御部２３０に入力され、更新部２３６が図１４に示す第２テーブル４１４へ当該ドキュメントを追加する様子を示す。さらに、図１５及び図１６の各テーブル４１４ａ〜４１４ｅ内に付された“Ｔ”で始まる符号は、更新部２３６による処理順序を示す。なお、この処理順序は、入力されたドキュメントの文字列の順序に対応するものであるが、当該処理順序はこれに限定されるものではない。
次に、上述した更新部２３６の処理を、図１４〜図１６を参照しながら具体例を挙げて説明する。図１４は図６に示す更新部２３６により更新される第２テーブル４１４の一例を示す図であり、図１５及び図１６は、それぞれ図１４に示す第２テーブル４１４の更新後の一例を示す図である。なお、前提として、図１４では、生成部２３２及び統合部２３４により、図７に示す“document-id: 20”のドキュメントのみが第２テーブル４１４に変換されているものとする。また、図１５及び図１６では、格納／更新要求により図７に示す“document-id: 30”のドキュメントが新たに書込制御部２３０に入力され、更新部２３６が図１４に示す第２テーブル４１４へ当該ドキュメントを追加する様子を示す。さらに、図１５及び図１６の各テーブル４１４ａ〜４１４ｅ内に付された“Ｔ”で始まる符号は、更新部２３６による処理順序を示す。なお、この処理順序は、入力されたドキュメントの文字列の順序に対応するものであるが、当該処理順序はこれに限定されるものではない。
はじめに、更新部２３６は、更新対象（書込対象）のドキュメント（マップ）のＩＤとして、図７に示す“document-id: 30 {”を抽出し、“parent=30”をメモリ５２等に記憶する（処理Ｔ５１，図示省略）。
次いで、更新部２３６は、更新対象のドキュメントから“url: “yyy”,”を抽出し、第２テーブル４１４から、キー“url”をテーブル名“url_title”に含むテーブル４１４ａを特定する（図１４参照）。また、更新部２３６は、生成部２３２と同様の手法によりキー“url”は「値を直接持つキー」であると判断する。そして、更新部２３６は、第３条件のうちの上記（１）に基づき、テーブル４１４ａにおいて、“_parent”列に“30”、“url”列に“yyy”を持つ行を追加する（図１５の処理Ｔ５２）。
次いで、更新部２３６は、更新対象のドキュメントから“url: “yyy”,”を抽出し、第２テーブル４１４から、キー“url”をテーブル名“url_title”に含むテーブル４１４ａを特定する（図１４参照）。また、更新部２３６は、生成部２３２と同様の手法によりキー“url”は「値を直接持つキー」であると判断する。そして、更新部２３６は、第３条件のうちの上記（１）に基づき、テーブル４１４ａにおいて、“_parent”列に“30”、“url”列に“yyy”を持つ行を追加する（図１５の処理Ｔ５２）。
また、更新部２３６は、“title: “yahoo”,”について、キー“title”は、テーブル４１４ａに含まれる（図１４参照）、「値を直接持つキー」であると判断する。そして、更新部２３６は、テーブル４１４ａの“_parent”列が“30”の行における、“title”列に“yahoo”を格納する（図１５の処理Ｔ５３）。
次に、更新部２３６は、“tags: [“yah”],”を抽出し、第２テーブル４１４から、キー“tags”をテーブル名“tags”に含むテーブル４１４ｂを特定する（図１４参照）。また、更新部２３６は、キー“tags”は「値を直接持つリストを持つキー」であると判断する。そして、更新部２３６は、第３条件のうちの上記（２）に基づき、テーブル４１４ｂにおいて、“_parent”列に“30”、“tags”列に“yah”を持つ行を追加する（図１５の処理Ｔ５４）。
次に、更新部２３６は、“tags: [“yah”],”を抽出し、第２テーブル４１４から、キー“tags”をテーブル名“tags”に含むテーブル４１４ｂを特定する（図１４参照）。また、更新部２３６は、キー“tags”は「値を直接持つリストを持つキー」であると判断する。そして、更新部２３６は、第３条件のうちの上記（２）に基づき、テーブル４１４ｂにおいて、“_parent”列に“30”、“tags”列に“yah”を持つ行を追加する（図１５の処理Ｔ５４）。
次いで、更新部２３６は、“bookmarks: [{”を抽出し、第２テーブル４１４から、キー“bookmarks”をテーブル名“bookmarks_.user_.comment”に含むテーブル４１４ｃを特定する（図１４参照）。また、更新部２３６は、キー“bookmarks”は「マップを持つリストを持つキー」であると判断する。そして、更新部２３６は、第３条件のうちの上記（４）に基づき、テーブル４１４ｃにおいて、“_parent”列に“30”を持つ行を追加する（図１５の処理Ｔ５５）。このとき、“_id”列には自動生成された“2”が格納される。
また、更新部２３６は、“user: “userA”,”について、キー“user”は、テーブル４１４ｃに含まれる（図１４参照）、「値を直接持つキー」であると判断する。そして、更新部２３６は、テーブル４１４ｃの“_id”列が“2”の行における、“user”列に“userA”を格納する（図１５の処理Ｔ５６）。同様に、更新部２３６は、“comment: “yahoooooo”,”について、テーブル４１４ｃの“_id”列が“2”の行における、“comment”列に“yahoooooo”を格納する（図１５の処理Ｔ５７）。
次に、更新部２３６は、“tags: [{”について、第２テーブル４１４から、キー“tags”をテーブル名“bokmarks.tags_.tag”に含むテーブル４１４ｄを特定する（図１４参照）。また、更新部２３６は、キー“tags”は「マップを持つリストを持つキー」であると判断する。そして、更新部２３６は、テーブル４１４ｄにおいて、“_parent”列に“2”を持つ行を追加する（図１５の処理Ｔ５８）。このとき、“_id”列には自動生成された“4”が格納される。
また、更新部２３６は、“tag: “yah”,”について、キー“tag”は、テーブル４１４ｄに含まれる（図１４参照）、「値を直接持つキー」であると判断する。そして、更新部２３６は、テーブル４１４ｄの“_id”列が“4”の行における、“tag”列に“yah”を格納する（図１５の処理Ｔ５９）。
次いで、更新部２３６は、“chars: [“y”,”について、第２テーブル４１４から、キー“chars”をテーブル名“bookmarks.tags.chars”に含むテーブル４１４ｅを特定する（図１４参照）。また、更新部２３６は、キー“chars”は「値を直接持つリストを持つキー」であると判断する。そして、更新部２３６は、テーブル４１４ｅにおいて、“_parent”列に“4”、“chars”列に“y”を持つ行を追加する（図１６の処理Ｔ６０）。
次いで、更新部２３６は、“chars: [“y”,”について、第２テーブル４１４から、キー“chars”をテーブル名“bookmarks.tags.chars”に含むテーブル４１４ｅを特定する（図１４参照）。また、更新部２３６は、キー“chars”は「値を直接持つリストを持つキー」であると判断する。そして、更新部２３６は、テーブル４１４ｅにおいて、“_parent”列に“4”、“chars”列に“y”を持つ行を追加する（図１６の処理Ｔ６０）。
処理Ｔ６１〜Ｔ６５においても、更新部２３６は、上述した処理と同様に、既に生成されているテーブル４１４ａ〜４１４ｅを更新する。
また、更新部２３６は、処理Ｔ６５において、ドキュメント（データ）“document-id: 30”内の最後の“｝”を検出すると、入力された格納／更新要求に、更新対象の他のドキュメントが含まれているか否かを判断する。更新対象の他のドキュメントがある場合、更新部２３６は、処理Ｔ５１と同様に、“document-id”の値“xx”を“parent”としてメモリ５２等に記憶すればよい。
また、更新部２３６は、処理Ｔ６５において、ドキュメント（データ）“document-id: 30”内の最後の“｝”を検出すると、入力された格納／更新要求に、更新対象の他のドキュメントが含まれているか否かを判断する。更新対象の他のドキュメントがある場合、更新部２３６は、処理Ｔ５１と同様に、“document-id”の値“xx”を“parent”としてメモリ５２等に記憶すればよい。
〔１−７〕読出制御部の説明
読出制御部（読出部）２４０は、入力される参照要求に応じて、当該参照要求で指定された条件を満たすデータを第２テーブル４１４から取得し、取得したデータをＪＳＯＮ形式のドキュメント（マップ）に変換して、アプリケーション側通信部２１０へ出力する。
例えば、読出制御部２４０は、参照要求により指定される読出条件に合致するデータを、書込制御部２３０によって変換された第２テーブル４１４から取得し、（元の）ドキュメントを構築する。なお、読出条件としては、読出対象の“document-id: xx”，又は１以上の特定の第２テーブル４１４及び値等が挙げられる。
読出制御部（読出部）２４０は、入力される参照要求に応じて、当該参照要求で指定された条件を満たすデータを第２テーブル４１４から取得し、取得したデータをＪＳＯＮ形式のドキュメント（マップ）に変換して、アプリケーション側通信部２１０へ出力する。
例えば、読出制御部２４０は、参照要求により指定される読出条件に合致するデータを、書込制御部２３０によって変換された第２テーブル４１４から取得し、（元の）ドキュメントを構築する。なお、読出条件としては、読出対象の“document-id: xx”，又は１以上の特定の第２テーブル４１４及び値等が挙げられる。
具体的には、読出制御部２４０は、参照要求を入力されると、戻り値のドキュメント（マップ）を“{}”で初期化する。また、読出制御部２４０は、参照要求で指定された読出条件を満たす読出対象の第２テーブル４１４のうち、読出条件の値と一致する読出対象の行について以下の処理を実行する。なお、読出条件として“document-id xx”のみが指定されたとき、読み出す第２テーブル４１４や値は指定されなくてよい。この場合、読出制御部２４０は、トップレベルの第２テーブル４１４のうち、“xx”と一致する行について、以下の処理を実行する。
・“_parent”列にＵＮＩＱＵＥ属性がある場合：読出制御部２４０は、“_parent”列以外の各列について、各列名を“key”とし、当該“key”列における読出対象の行の値を“value”として、“key: value”の要素を戻り値のマップに追加する。なお、当該“key”は、「値を直接持つキー」となる。
・“_parent”列にＵＮＩＱＵＥ属性がなく、且つ“_id”列がない場合：読出制御部２４０は、“_parent”列以外の各列について、各列名を“key”とし、当該“key”列における読出対象の行の値を“value”として、“key: [value]”の要素を戻り値のマップに追加する。なお、当該“key”は、「値を直接持つリストを持つキー」となる。また、当該“key”列における読出対象の行が複数ある場合、“key: [value]”のリスト“[]”には、複数の値“value”が“,”（カンマ）区切りで設定される。
・“_parent”列にＵＮＩＱＵＥ属性がなく、且つ“_id”列がない場合：読出制御部２４０は、“_parent”列以外の各列について、各列名を“key”とし、当該“key”列における読出対象の行の値を“value”として、“key: [value]”の要素を戻り値のマップに追加する。なお、当該“key”は、「値を直接持つリストを持つキー」となる。また、当該“key”列における読出対象の行が複数ある場合、“key: [value]”のリスト“[]”には、複数の値“value”が“,”（カンマ）区切りで設定される。
・“_parent”列にＵＮＩＱＵＥ属性がなく、且つ“_id”列がある場合：読出対象の第２テーブル４１４のテーブル名の共通部分のうち、“.”で区切った最後の部分（直近の親要素のキーの名前）を“table”とする。そして、読出制御部２４０は、“table: [{}]”の要素を戻り値のマップに追加する。なお、当該“table”は、「マップを持つリストを持つキー」となる。以下、テーブル名の共通部分のうち、“.”で区切った最後の部分を、共通部分（最後の部分）と表記する場合がある。
ここで、第２テーブル４１４のテーブル名の共通部分（最後の部分）とは、テーブル名で最初に現れる“_”と、当該“_”の直前にある“.”との間の文字列とすることができる。但し、テーブル名において“_”より前に“.”がない場合、共通部分（最後の部分）は、テーブル名の先頭とテーブル名で最初に現れる“_”との間の文字列とすることができる。また、テーブル名に“_”がない場合、共通部分（最後の部分）は、テーブル名の末尾から先頭に向かって最初に現れる“.”（“.”がない場合はテーブル名の先頭）と末尾との間の文字列とすることができる。例えば、テーブル名“bookmarks_.user_.comment”では“bookmarks”が共通部分（最後の部分）になり、テーブル名“bookmarks.tags_.tag”では“tags”が共通部分（最後の部分）になる。なお、テーブル名の共通部分は、テーブル名のうち、上述した共通部分（最後の部分）の末尾と、テーブル名の先頭との間の文字列である。
また、読出制御部２４０は、“_parent”列及び“_id”列以外にも列がある場合には、“_parent”列及び“_id”列以外の各列について、各列名を“key”とし、当該“key”列における読出対象の行の値を“value”とする。そして、読出制御部２４０は、“key: value”の要素を、戻り値のマップにおける“table: [{}]”の要素のマップに追加する。
さらに、読出制御部２４０は、参照要求で指定された“document-id”の値“xx”と一致する行における“_id”列のリスト“[]”を取得するため、以下の読出条件で自分自身の呼出（再帰呼出）を行なうことができる。そして、読出制御部２４０は、再帰呼出における戻り値についても、呼出元で処理された“table: [{key: value}]”のマップ“{}”に追加する。再帰呼出での読出条件の第２テーブル４１４としては、読出対象の第２テーブル４１４のテーブル名の共通部分と“key”とを“.”で結合したテーブル名で始まる全ての第２テーブル４１４のうち、呼出元における読出対象の第２テーブル４１４とは異なる第２テーブル４１４となる。また、再帰呼出での読出条件の値としては、呼出元での読出対象の行の“_id”列の値となる。
さらに、読出制御部２４０は、参照要求で指定された“document-id”の値“xx”と一致する行における“_id”列のリスト“[]”を取得するため、以下の読出条件で自分自身の呼出（再帰呼出）を行なうことができる。そして、読出制御部２４０は、再帰呼出における戻り値についても、呼出元で処理された“table: [{key: value}]”のマップ“{}”に追加する。再帰呼出での読出条件の第２テーブル４１４としては、読出対象の第２テーブル４１４のテーブル名の共通部分と“key”とを“.”で結合したテーブル名で始まる全ての第２テーブル４１４のうち、呼出元における読出対象の第２テーブル４１４とは異なる第２テーブル４１４となる。また、再帰呼出での読出条件の値としては、呼出元での読出対象の行の“_id”列の値となる。
読出制御部２４０は、再帰呼出での処理においても、上述した手法により要素を取得し、取得した要素を戻り値（この場合、呼出元へ返す戻り値）のマップに追加する。例えば、読出制御部２４０は、再帰呼出において、呼出元より指定された条件を満たす第２テーブル４１４の“_parent”列の値が、呼出元より指定された値と一致する行における、各列名を“key”とし、当該“key”列の値を“value”とする。そして、読出制御部２４０は、“key: value”等の要素を、呼出元への戻り値のマップに追加する。
このように、読出制御部２４０は、第２テーブル４１４から、入れ子構造を含むツリー構造のドキュメントを読み出すことができる。なお、読出制御部２４０は、再帰呼出の処理において、さらに再帰呼出を行なうことが行なうこともできる。この場合、第２テーブル４１４から読み出されるドキュメントは、多重の入れ子構造を含むツリー構造となる。
また、読出制御部２４０は、全ての読出対象の第２テーブル４１４について上記処理を行なうと、生成された戻り値のマップを、参照要求への応答とともにアプリケーション側通信部２１０へ出力する。
また、読出制御部２４０は、全ての読出対象の第２テーブル４１４について上記処理を行なうと、生成された戻り値のマップを、参照要求への応答とともにアプリケーション側通信部２１０へ出力する。
以上のように、読出制御部２４０は、入力される参照要求により指定されるオブジェクトのデータを１以上の第２テーブル４１４から取得し、取得したデータをドキュメントの形式に変換して、アプリケーション２１へ応答する。
上述した読出制御部２４０によれば、第２テーブル４１４から、入力された読出要求で指定される読出条件に応じた情報を取得し、第２テーブル４１４から取得した情報に基づいて、読出要求に対する入れ子構造を含む階層構造の読出データを生成できる。すなわち、読出制御部２４０により、第２のデータ形式で表された第２テーブル４１４から、第１のデータ形式のドキュメント（読出データ）を直接抽出し生成することができる。従って、読出制御部２４０によれば、データモデル変換エンジン２３による変換速度を向上できるため、情報処理システム１によるＤＢ４１へのアクセス性能を向上させることができる。
上述した読出制御部２４０によれば、第２テーブル４１４から、入力された読出要求で指定される読出条件に応じた情報を取得し、第２テーブル４１４から取得した情報に基づいて、読出要求に対する入れ子構造を含む階層構造の読出データを生成できる。すなわち、読出制御部２４０により、第２のデータ形式で表された第２テーブル４１４から、第１のデータ形式のドキュメント（読出データ）を直接抽出し生成することができる。従って、読出制御部２４０によれば、データモデル変換エンジン２３による変換速度を向上できるため、情報処理システム１によるＤＢ４１へのアクセス性能を向上させることができる。
〔１−８〕動作例
次に、上述のごとく構成された一実施形態に係る情報処理システム１（データモデル変換エンジン２３）の動作例を、図１７〜図２２を参照して説明する。図１７はデータモデル変換エンジン２３による全体の処理の一例を説明するフローチャートであり、図１８〜図２０は、それぞれ生成部２３２，統合部２３４，及び更新部２３６による処理の一例を説明するフローチャートである。図２１及び図２２は、それぞれ読出制御部２４０による処理の一例を説明するフローチャートである。
次に、上述のごとく構成された一実施形態に係る情報処理システム１（データモデル変換エンジン２３）の動作例を、図１７〜図２２を参照して説明する。図１７はデータモデル変換エンジン２３による全体の処理の一例を説明するフローチャートであり、図１８〜図２０は、それぞれ生成部２３２，統合部２３４，及び更新部２３６による処理の一例を説明するフローチャートである。図２１及び図２２は、それぞれ読出制御部２４０による処理の一例を説明するフローチャートである。
〔１−８−１〕データモデル変換エンジンの動作例
はじめに、図１７を参照して、データモデル変換エンジン２３による全体の処理を説明する。なお、図１７のフローチャートに示す全体の処理は、アプリケーション２１からアプリケーション２１を介して格納／更新要求又は参照要求等の各種要求が入力される都度、実行される。
はじめに、図１７を参照して、データモデル変換エンジン２３による全体の処理を説明する。なお、図１７のフローチャートに示す全体の処理は、アプリケーション２１からアプリケーション２１を介して格納／更新要求又は参照要求等の各種要求が入力される都度、実行される。
図１７に示すように、アプリケーション側通信部２１０により、アプリケーション２１から入力されたコマンドが格納／更新要求であるか否かが判定される（ステップＳ１）。入力されたコマンドが格納／更新要求である場合（ステップＳ１のＹｅｓルート）、アプリケーション側通信部２１０により、格納／更新要求が書込制御部２３０へ通知される。書込制御部２３０では、格納／更新要求に係るドキュメント（書込データ）がＤＢ４１内で変換された第２テーブル４１４に対するものか、例えば対応する第２テーブル４１４がＤＢ４１内に存在するか否かが判定される（ステップＳ２）。
ドキュメントが、変換された第２テーブル４１４に対するものではない場合（ステップＳ２のＮｏルート）、生成部２３２の処理が実行される。すなわち、生成部２３２により、後述するステップＳ１１〜Ｓ２９の処理が実行され、ドキュメントが変換され、第１テーブル４１２としてＤＢ４１へ格納される（ステップＳ３）。また、書込制御部２３０により、生成した第１テーブル４１２を統合するか、つまり第１テーブル４１２へ統合部２３４による変換を適用するか否かが判定される（ステップＳ４）。
例えば、ドキュメントが入れ子構造ではないツリー構造である場合のように第１テーブル４１２を統合しなくてもよい場合（ステップＳ４のＮｏルート）、処理が終了する。一方、ドキュメントが入れ子構造を含むツリー構造である場合等のように第１テーブル４１２を統合する場合（ステップＳ４のＹｅｓルート）、統合部２３４の処理が実行される。すなわち、統合部２３４により、後述するステップＳ３１〜Ｓ４０の処理が実行され、第１テーブル４１２が第２テーブル４１４へ変換され（第１テーブル４１２が統合され）（ステップＳ５）、処理が終了する。
一方、ステップＳ２において、ドキュメントが、変換された第２テーブル４１４に対するものである場合（ステップＳ２のＹｅｓルート）、更新部２３６の処理が実行される。すなわち、更新部２３６により、後述するステップＳ４１〜Ｓ５７の処理が実行され、ドキュメントが第２テーブル４１４へ格納され（ステップＳ６）、処理が終了する。
また、ステップＳ１において、入力されたコマンドが格納／更新要求ではない、例えば参照要求である場合（ステップＳ１のＮｏルート）、アプリケーション側通信部２１０により、参照要求が読出制御部２４０へ通知される。読出制御部２４０では、後述するステップＳ６１〜Ｓ８３の処理が実行され、参照要求に係るドキュメント（読出データ）が第２テーブル４１４から読み出される（ステップＳ７）。また、読み出されたドキュメントがアプリケーション側通信部２１０を介してアプリケーション２１へ出力され、処理が終了する。
また、ステップＳ１において、入力されたコマンドが格納／更新要求ではない、例えば参照要求である場合（ステップＳ１のＮｏルート）、アプリケーション側通信部２１０により、参照要求が読出制御部２４０へ通知される。読出制御部２４０では、後述するステップＳ６１〜Ｓ８３の処理が実行され、参照要求に係るドキュメント（読出データ）が第２テーブル４１４から読み出される（ステップＳ７）。また、読み出されたドキュメントがアプリケーション側通信部２１０を介してアプリケーション２１へ出力され、処理が終了する。
〔１−８−２〕生成部の動作例
次に、図１８を参照して、生成部２３２による処理を説明する。
図１８に示すように、生成部２３２により、格納／更新要求に係るドキュメントが１つ選択され、“document-id”の値“xx”がメモリ５２等に記憶される（ステップＳ１１）。また、生成部２３２により、選択したドキュメントから所定の文字列が１つ抽出される（ステップＳ１２）。そして、生成部２３２により、抽出した文字列に係るキーが値を直接持つか否かが判定される（ステップＳ１３）。
次に、図１８を参照して、生成部２３２による処理を説明する。
図１８に示すように、生成部２３２により、格納／更新要求に係るドキュメントが１つ選択され、“document-id”の値“xx”がメモリ５２等に記憶される（ステップＳ１１）。また、生成部２３２により、選択したドキュメントから所定の文字列が１つ抽出される（ステップＳ１２）。そして、生成部２３２により、抽出した文字列に係るキーが値を直接持つか否かが判定される（ステップＳ１３）。
キーが値を直接持つキーである場合（ステップＳ１３のＹｅｓルート）、生成部２３２により、キーに対応する第１テーブル４１２がＤＢ４１にあるか否かが判定される（ステップＳ１４）。例えば、生成部２３２は、最上位から当該キーまでを“.”で結合した、キーの階層を表す名前の第１テーブル４１２がＤＢ４１にあるか否かを判定する。キーに対応する第１テーブル４１２がない場合（ステップＳ１４のＮｏルート）、生成部２３２により、“（ＵＮＩＱＵＥ属性を持つ）parent”及び“value”の列を持つ第１テーブル４１２がＤＢ４１に生成される（ステップＳ１５）。なお、当該テーブル名には、最上位から当該キーまでを“.”で結合した、キーの階層を表す文字列が設定される。
ステップＳ１５の処理が実行された場合、又はキーに対応する第１テーブル４１２がある場合（ステップＳ１４のＹｅｓルート）、生成部２３２により、当該第１テーブル４１２へ、キーの親要素名“parent”及び値“value”が格納される（ステップＳ１６）。なお、トップレベルのキーの親要素名は、メモリ５２に格納された“document-id”の値“xx”となる。
次いで、生成部２３２により、選択したドキュメントから全ての文字列を抽出したか、例えばドキュメント（マップ）の終了“}”を検出したか否かが判定される（ステップＳ１７）。選択したドキュメントから全ての文字列を抽出していない場合（ステップＳ１７のＮｏルート）、処理がステップＳ１２に移行し、生成部２３２により次の文字列がドキュメントから抽出される。
一方、選択したドキュメントから全ての文字列を抽出した場合（ステップＳ１７のＹｅｓルート）、生成部２３２により、入力された格納／更新要求に係る全てのドキュメントを選択したか否かが判定される（ステップＳ１８）。全てのドキュメントを選択していない場合（ステップＳ１８のＮｏルート）、処理がステップＳ１１に移行し、生成部２３２により次のドキュメントが選択され、“document-id”の値“xx”が記憶される。一方、全てのドキュメントが選択された場合（ステップＳ１８のＹｅｓルート）、生成部２３２により、格納／更新要求に係る処理が正常終了したと判定され（ステップＳ１９）、処理が終了する。なお、書込制御部２３０は、アプリケーション側通信部２１０を介して格納／更新要求の処理結果（正常終了）をアプリケーション２１へ通知する。
ステップＳ１３において、キーが値を直接持つキーではない場合（ステップＳ１３のＮｏルート）には、生成部２３２により、抽出した文字列に係るキーが値を直接持つリストを持つか否かが判定される（ステップＳ２０）。
キーが値を直接持つリストを持つキーである場合（ステップＳ２０のＹｅｓルート）、生成部２３２により、キーに対応する第１テーブル４１２がＤＢ４１にあるか否かが判定される（ステップＳ２１）。キーに対応する第１テーブル４１２がない場合（ステップＳ２１のＮｏルート）、生成部２３２により、“parent”及び“value”の列を持つ第１テーブル４１２がＤＢ４１に生成される（ステップＳ２２）。
キーが値を直接持つリストを持つキーである場合（ステップＳ２０のＹｅｓルート）、生成部２３２により、キーに対応する第１テーブル４１２がＤＢ４１にあるか否かが判定される（ステップＳ２１）。キーに対応する第１テーブル４１２がない場合（ステップＳ２１のＮｏルート）、生成部２３２により、“parent”及び“value”の列を持つ第１テーブル４１２がＤＢ４１に生成される（ステップＳ２２）。
ステップＳ２２の処理が実行された場合、又はキーに対応する第１テーブル４１２がある場合（ステップＳ２１のＹｅｓルート）、生成部２３２により、当該第１テーブル４１２へ、キーの親要素名“parent”及び値“value”が格納される（ステップＳ２３）。そして、処理がステップＳ１７に移行する。
ステップＳ２０において、キーが値を直接持つリストを持つキーではない場合（ステップＳ２０のＮｏルート）には、生成部２３２により、抽出した文字列に係るキーがマップを持つか否かが判定される（ステップＳ２４）。キーがマップを持つキーである場合（ステップＳ２４のＹｅｓルート）、処理がステップＳ１７に移行する。一方、キーがマップを持つキーではない場合（ステップＳ２４のＮｏルート）、生成部２３２により、抽出した文字列に係るキーがマップを持つリストを持つか否かが判定される（ステップＳ２５）。
ステップＳ２０において、キーが値を直接持つリストを持つキーではない場合（ステップＳ２０のＮｏルート）には、生成部２３２により、抽出した文字列に係るキーがマップを持つか否かが判定される（ステップＳ２４）。キーがマップを持つキーである場合（ステップＳ２４のＹｅｓルート）、処理がステップＳ１７に移行する。一方、キーがマップを持つキーではない場合（ステップＳ２４のＮｏルート）、生成部２３２により、抽出した文字列に係るキーがマップを持つリストを持つか否かが判定される（ステップＳ２５）。
キーがマップを持つリストを持つキーである場合（ステップＳ２５のＹｅｓルート）、生成部２３２により、キーに対応する第１テーブル４１２がＤＢ４１にあるか否かが判定される（ステップＳ２６）。キーに対応する第１テーブル４１２がない場合（ステップＳ２６のＮｏルート）、生成部２３２により、第１テーブル４１２がＤＢ４１に生成される（ステップＳ２７）。ここで生成される第１テーブル４１２は、“parent”及び“（ＵＮＩＱＵＥ属性及びＡＵＴＯ＿ＩＮＣＲＥＭＥＮＴ属性を持つ）id”の列を持つ。
ステップＳ２７の処理が実行された場合、又はキーに対応する第１テーブル４１２がある場合（ステップＳ２６のＹｅｓルート）、生成部２３２により、当該第１テーブル４１２へ、キーの親要素名“parent”及び“id”が格納される（ステップＳ２８）。なお、“id”は、昇順で自動生成される、他の“id”と重複しない値である。ステップＳ２８の処理が終了すると、処理がステップＳ１７に移行する。
一方、ステップＳ２５において、キーがマップを持つリストを持つキーではない場合（ステップＳ２５のＮｏルート）には、ドキュメントがＪＳＯＮ形式等のＤＤＢに対応するデータ形式ではない可能性がある。従って、生成部２３２により、格納／更新要求に係る処理に異常が発生したと判定され（ステップＳ２９）、処理が終了する。なお、書込制御部２３０は、アプリケーション側通信部２１０を介して格納／更新要求の処理結果（異常終了）をアプリケーション２１へ通知する。
以上により、生成部２３２による処理が終了する。なお、ステップＳ１３，Ｓ２０，Ｓ２４，及びＳ２５における判定の実行順序は、上述したものに限定されるものではなく、実行順序を変更してもよい。
〔１−８−３〕統合部の動作例
次に、図１９を参照して、統合部２３４による処理を説明する。
〔１−８−３〕統合部の動作例
次に、図１９を参照して、統合部２３４による処理を説明する。
図１９に示すように、統合部２３４により、第１テーブル４１２を順に比較するため、変数ｉ＝１及びｊ＝２が定義され（ステップＳ３１）、第１テーブルｉ，ｊがそれぞれ特定される（ステップＳ３２）。なお、第１テーブルｉ，ｊは、それぞれ、第１テーブル４１２を生成順やＩＤ順等の任意の順序でソートしたときのｉ番目，ｊ番目の第１テーブル４１２を示すものとする。
次いで、統合部２３４により、第１テーブルｉ，ｊが同一階層にあると見做せるか否かが判定される（ステップＳ３３）。第１テーブルｉ，ｊが同一階層にあると見做せる場合（ステップＳ３３のＹｅｓルート）、統合部２３４により、第１テーブルｉ，ｊが同じ構造であると見做せるか否かが判定される（ステップＳ３４）。第１テーブルｉ，ｊが同じ構造である場合（ステップＳ３４のＹｅｓルート）、統合部２３４により、第１テーブルｉ，ｊを統合すると判定され（ステップＳ３５）、処理がステップＳ３６に移行する。なお、ステップＳ３５において、統合部２３４は、ｉ，ｊの値をメモリ５２等に格納することができる。一方、第１テーブルｉ，ｊが同一階層にない又は同じ構造ではない場合（ステップＳ３３のＮｏルート又はステップＳ３４のＮｏルート）にも、処理がステップＳ３６に移行する。
ステップＳ３６では、統合部２３４により、ｊ＝ｎであるか否かが判定される。なお、ｎは第１テーブル４１２の総数である。ｊ＝ｎではない場合（ステップＳ３６のＮｏルート）、統合部２３４により、ｊに１が加算され（ステップＳ３７）、処理がステップＳ３２に移行する。一方、ｊ＝ｎである場合（ステップＳ３６のＹｅｓルート）、統合部２３４により、ｉ＝ｎ−１であるか否かが判定される（ステップＳ３８）。ｉ＝ｎ−１ではない場合（ステップＳ３８のＮｏルート）、ｉに１が加算される。また、統合部２３４により、ｊには、１が加算された上記ｉにさらに１を加算した値が設定され（ステップＳ３９）、処理がステップＳ３２に移行する。なお、ｊ＝ｉ＋１としたのは、ｊをｉよりも常に大きな値にすることで、ｉ及びｊの値が入れ替わって第１テーブル４１２の重複した比較が行なわれないようにするためである。
ｉ＝ｎ−１である場合（ステップＳ３８のＹｅｓルート）、統合部２３４により、メモリ５２等に記憶されたｉ，ｊの１以上の組が参照され、ステップＳ３５で統合すると判定した第１テーブル４１２の組が統合されて（ステップＳ４０）、処理が終了する。
以上により、統合部２３４による処理が終了する。
このように、統合部２３４は、ｉ，ｊを変化させて、全てのパターンについて第１テーブルｉ，ｊを比較する。そして、統合部２３４は、統合可能な全ての第１テーブルｉ，ｊの組を統合する。なお、統合部２３４がｉ，ｊを変化させる手法は、上述したものに限定されず、種々の手法を用いることができる。つまり、統合部２３４は、ｉとｊとが同一とならず、且つｉ及びｊの値が入れ替わらないように（重複した比較を行なわないように）ｉ，ｊを変化させて、ｉ，ｊの組について全てのパターンを得ることができればよい。
以上により、統合部２３４による処理が終了する。
このように、統合部２３４は、ｉ，ｊを変化させて、全てのパターンについて第１テーブルｉ，ｊを比較する。そして、統合部２３４は、統合可能な全ての第１テーブルｉ，ｊの組を統合する。なお、統合部２３４がｉ，ｊを変化させる手法は、上述したものに限定されず、種々の手法を用いることができる。つまり、統合部２３４は、ｉとｊとが同一とならず、且つｉ及びｊの値が入れ替わらないように（重複した比較を行なわないように）ｉ，ｊを変化させて、ｉ，ｊの組について全てのパターンを得ることができればよい。
〔１−８−４〕更新部の動作例
次に、図２０を参照して、更新部２３６による処理を説明する。
図２０に示すように、更新部２３６により、格納／更新要求に係るドキュメントが１つ選択され、“document-id”の値“xx”がメモリ５２等に記憶される（ステップＳ４１）。また、更新部２３６により、選択したドキュメントから所定の文字列が１つ抽出される（ステップＳ４２）。そして、更新部２３６により、抽出した文字列に係るキーが値を直接持つか否かが判定される（ステップＳ４３）。
次に、図２０を参照して、更新部２３６による処理を説明する。
図２０に示すように、更新部２３６により、格納／更新要求に係るドキュメントが１つ選択され、“document-id”の値“xx”がメモリ５２等に記憶される（ステップＳ４１）。また、更新部２３６により、選択したドキュメントから所定の文字列が１つ抽出される（ステップＳ４２）。そして、更新部２３６により、抽出した文字列に係るキーが値を直接持つか否かが判定される（ステップＳ４３）。
キーが値を直接持つキーである場合（ステップＳ４３のＹｅｓルート）、更新部２３６により、キーに対応する第２テーブル４１４に値を格納可能な行があるか否かが判定される（ステップＳ４４）。値を格納可能な行がない場合（ステップＳ４４のＮｏルート）、更新部２３６により、抽出した文字列に係るキーの親要素名を“_parent”列に設定した行が、キーに対応する第２テーブル４１４に追加される（ステップＳ４５）。なお、キーに対応する第２テーブル４１４とは、最上位からキーまでを“.”で結合したテーブル名の第２テーブル４１４である。
ステップＳ４５の処理が実行された場合、又はキーに対応する第２テーブル４１４に値を格納可能な行がある場合（ステップＳ４４のＹｅｓルート）、更新部２３６により、当該第２テーブル４１４のキー名の列に値“value”が格納される（ステップＳ４６）。
次いで、更新部２３６により、生成部２３２と同様に、選択したドキュメントから全ての文字列を抽出したか否かが判定される（ステップＳ４７）。選択したドキュメントから全ての文字列を抽出していない場合（ステップＳ４７のＮｏルート）、処理がステップＳ４２に移行し、更新部２３６により次の文字列がドキュメントから抽出される。
次いで、更新部２３６により、生成部２３２と同様に、選択したドキュメントから全ての文字列を抽出したか否かが判定される（ステップＳ４７）。選択したドキュメントから全ての文字列を抽出していない場合（ステップＳ４７のＮｏルート）、処理がステップＳ４２に移行し、更新部２３６により次の文字列がドキュメントから抽出される。
一方、選択したドキュメントから全ての文字列を抽出した場合（ステップＳ４７のＹｅｓルート）、更新部２３６により、生成部２３２と同様に、入力された格納／更新要求に係る全てのドキュメントを選択したか否かが判定される（ステップＳ４８）。全てのドキュメントを選択していない場合（ステップＳ４８のＮｏルート）、処理がステップＳ４１に移行し、更新部２３６により次のドキュメントが選択され、“document-id”の値“xx”が記憶される。一方、全てのドキュメントが選択された場合（ステップＳ４８のＹｅｓルート）、更新部２３６により、格納／更新要求に係る処理が正常終了したと判定され（ステップＳ４９）、処理が終了する。なお、書込制御部２３０は、アプリケーション側通信部２１０を介して格納／更新要求の処理結果（正常終了）をアプリケーション２１へ通知する。
ステップＳ４３において、キーが値を直接持つキーではない場合（ステップＳ４３のＮｏルート）には、更新部２３６により、抽出した文字列に係るキーが値を直接持つリストを持つか否かが判定される（ステップＳ５０）。
キーが値を直接持つリストを持つキーである場合（ステップＳ５０のＹｅｓルート）、更新部２３６により、“_parent”列にはキーの親要素名を、キー名の列には値“value”を設定した行がキーに対応する第２テーブル４１４に追加される（ステップＳ５１）。そして、処理がステップＳ４７に移行する。
キーが値を直接持つリストを持つキーである場合（ステップＳ５０のＹｅｓルート）、更新部２３６により、“_parent”列にはキーの親要素名を、キー名の列には値“value”を設定した行がキーに対応する第２テーブル４１４に追加される（ステップＳ５１）。そして、処理がステップＳ４７に移行する。
ステップＳ５０において、キーが値を直接持つリストを持つキーではない場合（ステップＳ５０のＮｏルート）には、更新部２３６により、抽出した文字列に係るキーがマップを持つか否かが判定される（ステップＳ５２）。キーがマップを持つキーである場合（ステップＳ５２のＹｅｓルート）、処理がステップＳ４７に移行する。一方、キーがマップを持つキーではない場合（ステップＳ５２のＮｏルート）、更新部２３６により、抽出した文字列に係るキーがマップを持つリストを持つか否かが判定される（ステップＳ５３）。
キーがマップを持つリストを持つキーである場合（ステップＳ５３のＹｅｓルート）、更新部２３６により、キーに対応する第２テーブル４１４に値を格納可能な行があるか否かが判定される（ステップＳ５４）。値を格納可能な行がない場合（ステップＳ５４のＮｏルート）、更新部２３６により、抽出した文字列に係るキーの親要素名を“_parent”列に設定した行が、キーに対応する第２テーブル４１４に追加される（ステップＳ５５）。
ステップＳ５５の処理が実行された場合、又はキーに対応する第２テーブル４１４に値を格納可能な行がある場合（ステップＳ５４のＹｅｓルート）、更新部２３６により、当該第２テーブル４１４のキー名の列に値“id”が格納される（ステップＳ５６）。なお、“id”は、昇順で自動生成される、他の“id”と重複しない値である。ステップＳ５６の処理が終了すると、処理がステップＳ４７に移行する。
一方、ステップＳ５３において、キーがマップを持つリストを持つキーではない場合（ステップＳ５３のＮｏルート）には、更新部２３６により、格納／更新要求に係る処理に異常が発生したと判定され（ステップＳ５７）、処理が終了する。なお、書込制御部２３０は、アプリケーション側通信部２１０を介して格納／更新要求の処理結果（異常終了）をアプリケーション２１へ通知する。
以上により、更新部２３６による処理が終了する。なお、ステップＳ４３，Ｓ５０，Ｓ５２，及びＳ５３における判定の実行順序は、上述したものに限定されるものではなく、実行順序を変更してもよい。
〔１−８−５〕読出制御部の動作例
次に、図２１及び図２２を参照して、読出制御部２４０による処理を説明する。
〔１−８−５〕読出制御部の動作例
次に、図２１及び図２２を参照して、読出制御部２４０による処理を説明する。
図２１に示すように、読出制御部２４０により、戻り値のマップが“{}”で初期化され（ステップＳ６１）、参照要求で指定される読出条件に係る第２テーブル４１４が１つ特定される（ステップＳ６２）。また、読出制御部２４０により、“_parent”列の値が読出条件の値と一致する第２テーブル４１４の行が特定される（ステップＳ６３）。以下、特定された第２テーブル４１４を第２テーブルｘと表記し、特定された行を行ｙと表記する。
なお、第２テーブルｘは、例えば読出条件で特定の第２テーブル４１４が指定されずに、“document-id: xx”が指定された場合、トップレベルの第２テーブル４１４になる。図１２の例では、第２テーブルｘは、ＵＮＩＱＵＥ属性を持つ“_parent”列を含むテーブル４１４ａになる。また、第２テーブルｘは、例えば読出条件が１以上の第２テーブル４１４である場合、当該第２テーブル４１４のうちのいずれかになる。
また、特定される行ｙは、例えば読出条件で値が指定されない場合、“_parent”列の値が“document-id”の値“xx”と一致する第２テーブルｘの行になる。図１２の例では、“document-id: 20”の場合、行ｙは、第２テーブルｘにおける“_parent”列が“20”の行になる。また、行ｙは、例えば読出条件の値が“_id”の値“y”等である場合、“_parent”列の値が“y”と一致する全ての行のうちのいずれかになる。
次いで、読出制御部２４０により、第２テーブルｘの“_parent”列にＵＮＩＱＵＥ属性があるか否かが判定される（ステップＳ６４）。“_parent”列にＵＮＩＱＵＥ属性がある場合（ステップＳ６４のＹｅｓルート）、読出制御部２４０により、第２テーブルｘの“_parent”列以外の列が１つ特定される（ステップＳ６５）。以下、特定された列を列ｚと表記する。
そして、読出制御部２４０により、第２テーブルｘの列ｚにおける行ｙの値を“value”，列ｚの名前を“key”として、要素“key: value”が戻り値のマップに追加される（ステップＳ６６）。また、読出制御部２４０により、他の未処理の列ｚが第２テーブルｘに存在するか否かが判定される（ステップＳ６７）。他の未処理の列ｚが存在する場合（ステップＳ６７のＹｅｓルート）、処理がステップＳ６５に移行する。一方、他の未処理の列ｚが存在しない場合（ステップＳ６７のＮｏルート）、処理がステップＳ６８に移行する。
ステップＳ６８では、読出制御部２４０により、“_parent”列の値が読出条件の値と一致する他の行ｙが第２テーブルｘに存在するか否かが判定される。他の行ｙが第２テーブルｘに存在する場合（ステップＳ６８のＹｅｓルート）、処理がステップＳ６３に移行し、他の行ｙについて、上述した処理が行なわれる。一方、他の行ｙが第２テーブルｘに存在しない場合（ステップＳ６８のＮｏルート）、読出制御部２４０により、読出条件を満たす他の第２テーブルｘが存在するか否かが判定される（ステップＳ６９）。
読出条件を満たす他の第２テーブルｘが存在する場合（ステップＳ６９のＹｅｓルート）、処理がステップＳ６２に移行し、他の第２テーブルｘについて、上述した処理が行なわれる。一方、読出条件を満たす他の第２テーブルｘが存在しない場合（ステップＳ６９のＮｏルート）、読出制御部２４０により、参照要求に係る処理が正常終了したと判定される。そして、読出制御部２４０により、戻り値のマップがアプリケーション側通信部２１０を介して参照要求の処理結果をとともにアプリケーション２１へ通知され（ステップＳ７０）、処理が終了する。
ステップＳ６４において、“_parent”列にＵＮＩＱＵＥ属性がない場合（ステップＳ６４のＮｏルート）には、読出制御部２４０により、第２テーブルｘに“_id”列が存在するか否かが判定される（ステップＳ７１）。第２テーブルｘに“_id”列が存在しない場合（ステップＳ７１のＮｏルート）、読出制御部２４０により、第２テーブルｘの“_parent”列以外の列ｚが１つ特定される（ステップＳ７２）。
そして、読出制御部２４０により、第２テーブルｘの列ｚにおける行ｙの値を“value”，列ｚの名前を“key”として、戻り値のマップに要素“key: [value]”が存在するか否かが判定される（ステップＳ７３）。戻り値のマップに要素“key: [value]”が存在しない場合（ステップＳ７３のＮｏルート）、読出制御部２４０により、戻り値のマップに要素“key: [value]”が追加される（ステップＳ７４）。
ステップＳ７４の処理が実行された場合、又は戻り値のマップに要素“key: [value]”が存在する場合（ステップＳ７３のＹｅｓルート）、読出制御部２４０により、戻り値のマップの要素“key: [value]”に、行ｙの値“value”が追加される（ステップＳ７５）。また、読出制御部２４０により、他の未処理の列ｚが第２テーブルｘに存在するか否かが判定される（ステップＳ７６）。他の未処理の列ｚが存在する場合（ステップＳ７６のＹｅｓルート）、処理がステップＳ７２に移行する。一方、他の未処理の列ｚが存在しない場合（ステップＳ７６のＮｏルート）、処理がステップＳ６８に移行する。
ステップＳ７１において、第２テーブルｘに“_id”列が存在する場合（ステップＳ７１のＹｅｓルート）には、処理が図２２に示すステップＳ７７に移行する。図２２に示すように、ステップＳ７７では、読出制御部２４０により、第２テーブルｘの名前の共通部分のうち、“.”で区切った最後の文字列（共通部分（最後の部分）の文字列）を“table”として、要素“table: [{}]”が戻り値のマップに追加される。
次いで、読出制御部２４０により、第２テーブルｘに“_parent”列及び“_id”列以外の列が存在するか否かが判定される（ステップＳ７８）。第２テーブルｘに“_parent”列及び“_id”列以外の列が存在する場合（ステップＳ７８のＹｅｓルート）、読出制御部２４０により、第２テーブルｘの“_parent”列及び“_id”列以外の列ｚが１つ特定される（ステップＳ７９）。
そして、読出制御部２４０により、第２テーブルｘの列ｚにおける行ｙの値を“value”，列ｚの名前を“key”として、戻り値のマップの要素“table: [{}]”のマップ内に要素“key: value”が追加される（ステップＳ８０）。また、読出制御部２４０により、他の未処理の列ｚが第２テーブルｘに存在するか否かが判定される（ステップＳ８１）。他の未処理の列ｚが存在する場合（ステップＳ８１のＹｅｓルート）、処理がステップＳ７９に移行する。
一方、他の未処理の列ｚが存在しない場合（ステップＳ８１のＮｏルート）、又はステップＳ７８において、第２テーブルｘに“_parent”列及び“_id”列以外の列が存在しない場合（ステップＳ７８のＮｏルート）、処理がステップＳ８２に移行する。
ステップＳ８２では、読出制御部２４０により、以下の第２テーブルｗ及び値を指定する読出条件で再帰読出が行なわれる。例えば、第２テーブルｗは、第２テーブルｘの名前の共通部分と“key”とを“.”で結合した名前で始まる全ての第２テーブル４１４のうち、第２テーブルｘとは異なる第２テーブル４１４であるものとする。また、値は、第２テーブルｗの“_parent”列の値が第２テーブルｘの行ｙに設定された“_id”列の値であるものとする。
ステップＳ８２では、読出制御部２４０により、以下の第２テーブルｗ及び値を指定する読出条件で再帰読出が行なわれる。例えば、第２テーブルｗは、第２テーブルｘの名前の共通部分と“key”とを“.”で結合した名前で始まる全ての第２テーブル４１４のうち、第２テーブルｘとは異なる第２テーブル４１４であるものとする。また、値は、第２テーブルｗの“_parent”列の値が第２テーブルｘの行ｙに設定された“_id”列の値であるものとする。
ステップＳ８２において、再帰読出が完了し戻り値のマップが得られると、読出制御部２４０により、再帰読出からの戻り値が、再帰読出の読出元の戻り値のマップにおける要素“table: [{}]”のマップ内に格納される（ステップＳ８３）。そして、処理がステップＳ６８に移行する。
以上により、読出制御部２４０による処理が終了する。
以上により、読出制御部２４０による処理が終了する。
〔１−９〕まとめ
上述のように、一実施形態に係る情報処理システム１によれば、生成部２３２により、入力された入れ子構造を含む階層構造のデータのキーごとに、当該キーの値を含む第１テーブル４１２が生成される。また、生成部２３２により、当該データの入れ子構造に応じて、複数の第１テーブル４１２の各々が対応する他の第１テーブル４１２と関係付けられる。そして、統合部２３４により、複数の第１テーブル４１２における所定の条件を満たす第１テーブル４１２同士が統合されて第２テーブル４１４が生成される。
上述のように、一実施形態に係る情報処理システム１によれば、生成部２３２により、入力された入れ子構造を含む階層構造のデータのキーごとに、当該キーの値を含む第１テーブル４１２が生成される。また、生成部２３２により、当該データの入れ子構造に応じて、複数の第１テーブル４１２の各々が対応する他の第１テーブル４１２と関係付けられる。そして、統合部２３４により、複数の第１テーブル４１２における所定の条件を満たす第１テーブル４１２同士が統合されて第２テーブル４１４が生成される。
これにより、アプリケーション２１の開発者等は、複雑な構造のデータをそのまま扱うようにアプリケーション２１の設計や更新を行なえるＤＤＢを採用しながら、ＤＢとして性能が良く安定性が高いＲＤＢを利用する（高速なＤＢを利用する）ことができる。さらに、開発者等は、アプリケーション２１及びＤＢサーバ４で使用するデータモデルを柔軟に決定することができ、情報処理システム１の開発コストを軽減することができる。
例えば、データモデル変換エンジン２３によれば、キーごとに生成された第１テーブル４１２の少なくとも一部が、統合部２３４により１以上の第２テーブル４１４として統合される。従って、入れ子構造を含むツリー構造のデータを単一の表形式データとしてＲＤＢに格納する（上記（ａ）参照）場合と比べて、ＤＢ４１内のＲＤＢのデータサイズを小さくすることができる。また、入れ子構造を含むツリー構造のデータを単純に複数の表形式データとしてＲＤＢに格納する（上記（ａ）参照）場合と比べて、テーブル数を少なくすることができるため、参照されるテーブル数を少なくでき、結果としてメモリ消費量を低減できる。
また、データモデル変換エンジン２３によれば、入れ子や階層の構造が多様なツリー構造のデータを、適応的に表形式のデータに変換することができ、利便性が高い。
さらに、データモデル変換エンジン２３によれば、アプリケーション２１に提供するＡＰＩとして、オブジェクト指向言語よりも制約の大きいＪＳＯＮ形式又はＢＳＯＮ形式の文字列を受け渡しするＡＰＩを用いることができる。このように、オブジェクト指向言語でのオブジェクトを受け渡しするＡＰＩに代えて、オブジェクトの構造を文字列に変換する形式の文字列を受け渡しするＡＰＩを用いることにより、データモデル変換エンジン２３の設計及び実装を単純化することができる。従って、データモデル変換エンジン２３の開発コストを低減させることができる。
さらに、データモデル変換エンジン２３によれば、アプリケーション２１に提供するＡＰＩとして、オブジェクト指向言語よりも制約の大きいＪＳＯＮ形式又はＢＳＯＮ形式の文字列を受け渡しするＡＰＩを用いることができる。このように、オブジェクト指向言語でのオブジェクトを受け渡しするＡＰＩに代えて、オブジェクトの構造を文字列に変換する形式の文字列を受け渡しするＡＰＩを用いることにより、データモデル変換エンジン２３の設計及び実装を単純化することができる。従って、データモデル変換エンジン２３の開発コストを低減させることができる。
また、図５に示すように、第１のデータ形式を扱うアプリケーション２１と第２のデータ形式を扱うＤＢ接続部２２との間に、データモデル変換エンジン２３を設けることができる。これにより、情報処理システム１は、ＲＤＢを扱うＤＢ接続部２２の機能やＤＢサーバ４に実質的な変更を加えずに、ＤＤＢを扱うアプリケーション２１を実行することができる。従って、情報処理システム１の設計の自由度を向上させることができるとともに、情報処理システム１の導入／運用コストを低減させることができる。
〔２〕その他
以上、本発明の好ましい実施形態について詳述したが、本発明は、係る特定の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲内において、種々の変形、変更して実施することができる。
例えば、一実施形態において、データモデル変換エンジン２３は、アプリサーバ２において、アプリケーション２１とＤＢ接続部２２との間にそなえられるものとして説明したが、これに限定されるものではない。データモデル変換エンジン２３は、例えばＤＢサーバ４にそなえられてもよいし、アプリサーバ２とＤＢサーバ４との間にそなえられてもよい。データモデル変換エンジン２３がＤＢサーバ４にそなえられる場合、アプリケーション２１及びＤＢ接続部２２は、いずれもＤＤＢのデータモデル等の第１のデータ形式によりＤＢサーバ４へアクセスすることができる。データモデル変換エンジン２３は、ＤＢサーバ４に入ってきた各種要求について、ＤＢ４１との間ではＲＤＢのデータモデル（第２のデータ形式）を用いてアクセスすることができる。
以上、本発明の好ましい実施形態について詳述したが、本発明は、係る特定の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲内において、種々の変形、変更して実施することができる。
例えば、一実施形態において、データモデル変換エンジン２３は、アプリサーバ２において、アプリケーション２１とＤＢ接続部２２との間にそなえられるものとして説明したが、これに限定されるものではない。データモデル変換エンジン２３は、例えばＤＢサーバ４にそなえられてもよいし、アプリサーバ２とＤＢサーバ４との間にそなえられてもよい。データモデル変換エンジン２３がＤＢサーバ４にそなえられる場合、アプリケーション２１及びＤＢ接続部２２は、いずれもＤＤＢのデータモデル等の第１のデータ形式によりＤＢサーバ４へアクセスすることができる。データモデル変換エンジン２３は、ＤＢサーバ４に入ってきた各種要求について、ＤＢ４１との間ではＲＤＢのデータモデル（第２のデータ形式）を用いてアクセスすることができる。
〔３〕付記
以上の実施形態に関し、更に以下の付記を開示する。
（付記１）
第１のデータ形式で入力された入れ子構造を含む階層構造のデータを、複数のテーブルで前記データを表す第２のデータ形式に変換して、格納部へ格納する変換部をそなえ、
前記変換部は、
前記入力されたデータの情報要素ごとに、当該情報要素の値を含む第１テーブルを生成し、前記データの入れ子構造に応じて、前記複数の第１テーブルの各々を対応する他の第１テーブルと関係付ける第１生成部と、
複数の前記第１テーブルにおける所定の条件を満たす第１テーブル同士を統合して第２テーブルを生成する第２生成部と、
をそなえることを特徴とする、情報処理装置。
以上の実施形態に関し、更に以下の付記を開示する。
（付記１）
第１のデータ形式で入力された入れ子構造を含む階層構造のデータを、複数のテーブルで前記データを表す第２のデータ形式に変換して、格納部へ格納する変換部をそなえ、
前記変換部は、
前記入力されたデータの情報要素ごとに、当該情報要素の値を含む第１テーブルを生成し、前記データの入れ子構造に応じて、前記複数の第１テーブルの各々を対応する他の第１テーブルと関係付ける第１生成部と、
複数の前記第１テーブルにおける所定の条件を満たす第１テーブル同士を統合して第２テーブルを生成する第２生成部と、
をそなえることを特徴とする、情報処理装置。
（付記２）
前記第２生成部は、前記複数の第１テーブルのうち、前記階層構造における情報要素の属する階層及び当該情報要素の種類がそれぞれ所定の関係にある第１テーブル同士を統合する、
ことを特徴とする、付記１記載の情報処理装置。
前記第２生成部は、前記複数の第１テーブルのうち、前記階層構造における情報要素の属する階層及び当該情報要素の種類がそれぞれ所定の関係にある第１テーブル同士を統合する、
ことを特徴とする、付記１記載の情報処理装置。
（付記３）
前記第１生成部は、生成する前記第１テーブルに、前記情報要素の属する階層及び当該情報要素の要素名を表すテーブル名を設定し、
前記第２生成部は、前記複数の第１テーブルの各々のテーブル名に基づき、前記情報要素の属する階層が互いに所定の関係にある第１テーブルを検出する、
ことを特徴とする、付記２記載の情報処理装置。
前記第１生成部は、生成する前記第１テーブルに、前記情報要素の属する階層及び当該情報要素の要素名を表すテーブル名を設定し、
前記第２生成部は、前記複数の第１テーブルの各々のテーブル名に基づき、前記情報要素の属する階層が互いに所定の関係にある第１テーブルを検出する、
ことを特徴とする、付記２記載の情報処理装置。
（付記４）
前記第１生成部は、生成する前記第１テーブルに、前記情報要素の種類に応じた列を設定し、
前記第２生成部は、前記複数の第１テーブルの各々の前記列に基づき、前記情報要素の種類が互いに所定の関係にある第１テーブルを検出する、
ことを特徴とする、付記２又は付記３記載の情報処理装置。
前記第１生成部は、生成する前記第１テーブルに、前記情報要素の種類に応じた列を設定し、
前記第２生成部は、前記複数の第１テーブルの各々の前記列に基づき、前記情報要素の種類が互いに所定の関係にある第１テーブルを検出する、
ことを特徴とする、付記２又は付記３記載の情報処理装置。
（付記５）
前記変換部は、
前記第２テーブルから、入力された読出要求で指定される読出条件に応じた情報を取得し、前記第２テーブルから取得した情報に基づいて、前記読出要求に対する入れ子構造を含む階層構造の読出データを生成する読出部、
をさらにそなえることを特徴とする、付記１〜４のいずれか１項記載の情報処理装置。
前記変換部は、
前記第２テーブルから、入力された読出要求で指定される読出条件に応じた情報を取得し、前記第２テーブルから取得した情報に基づいて、前記読出要求に対する入れ子構造を含む階層構造の読出データを生成する読出部、
をさらにそなえることを特徴とする、付記１〜４のいずれか１項記載の情報処理装置。
（付記６）
前記変換部は、
対応する第２テーブルが存在する状態で前記第１のデータ形式で入力された入れ子構造を含む階層構造の更新データから、前記更新データの情報要素ごとに当該情報要素の値を抽出し、抽出した情報要素の値に基づいて、対応する第２テーブルを更新する更新部、
をさらにそなえることを特徴とする、付記１〜５のいずれか１項記載の情報処理装置。
前記変換部は、
対応する第２テーブルが存在する状態で前記第１のデータ形式で入力された入れ子構造を含む階層構造の更新データから、前記更新データの情報要素ごとに当該情報要素の値を抽出し、抽出した情報要素の値に基づいて、対応する第２テーブルを更新する更新部、
をさらにそなえることを特徴とする、付記１〜５のいずれか１項記載の情報処理装置。
（付記７）
入力された要求に応じた処理を格納部に対して行なうコンピュータに、
第１のデータ形式で入力された入れ子構造を含む階層構造のデータを、複数のテーブルで前記データを表す第２のデータ形式に変換して、前記格納部へ格納し、
前記変換において、
前記入力されたデータの情報要素ごとに、当該情報要素の値を含む第１テーブルを生成し、前記データの入れ子構造に応じて、前記複数の第１テーブルの各々を対応する他の第１テーブルと関係付け、
複数の前記第１テーブルにおける所定の条件を満たす第１テーブル同士を統合して第２テーブルを生成する、
処理を実行させることを特徴とする、データ変換プログラム。
入力された要求に応じた処理を格納部に対して行なうコンピュータに、
第１のデータ形式で入力された入れ子構造を含む階層構造のデータを、複数のテーブルで前記データを表す第２のデータ形式に変換して、前記格納部へ格納し、
前記変換において、
前記入力されたデータの情報要素ごとに、当該情報要素の値を含む第１テーブルを生成し、前記データの入れ子構造に応じて、前記複数の第１テーブルの各々を対応する他の第１テーブルと関係付け、
複数の前記第１テーブルにおける所定の条件を満たす第１テーブル同士を統合して第２テーブルを生成する、
処理を実行させることを特徴とする、データ変換プログラム。
（付記８）
前記第２テーブルの生成において、
前記複数の第１テーブルのうち、前記階層構造における情報要素の属する階層及び当該情報要素の種類がそれぞれ所定の関係にある第１テーブル同士を統合する、
ことを特徴とする、付記７記載のデータ変換プログラム。
前記第２テーブルの生成において、
前記複数の第１テーブルのうち、前記階層構造における情報要素の属する階層及び当該情報要素の種類がそれぞれ所定の関係にある第１テーブル同士を統合する、
ことを特徴とする、付記７記載のデータ変換プログラム。
（付記９）
前記第１テーブルの生成において、
生成する前記第１テーブルに、前記情報要素の属する階層及び当該情報要素の要素名を表すテーブル名を設定し、
前記第２テーブルの生成において、
前記複数の第１テーブルの各々のテーブル名に基づき、前記情報要素の属する階層が互いに所定の関係にある第１テーブルを検出する、
ことを特徴とする、付記８記載のデータ変換プログラム。
前記第１テーブルの生成において、
生成する前記第１テーブルに、前記情報要素の属する階層及び当該情報要素の要素名を表すテーブル名を設定し、
前記第２テーブルの生成において、
前記複数の第１テーブルの各々のテーブル名に基づき、前記情報要素の属する階層が互いに所定の関係にある第１テーブルを検出する、
ことを特徴とする、付記８記載のデータ変換プログラム。
（付記１０）
前記第１テーブルの生成において、
生成する前記第１テーブルに、前記情報要素の種類に応じた列を設定し、
前記第２テーブルの生成において、
前記複数の第１テーブルの各々の前記列に基づき、前記情報要素の種類が互いに所定の関係にある第１テーブルを検出する、
ことを特徴とする、付記８又は付記９記載のデータ変換プログラム。
前記第１テーブルの生成において、
生成する前記第１テーブルに、前記情報要素の種類に応じた列を設定し、
前記第２テーブルの生成において、
前記複数の第１テーブルの各々の前記列に基づき、前記情報要素の種類が互いに所定の関係にある第１テーブルを検出する、
ことを特徴とする、付記８又は付記９記載のデータ変換プログラム。
（付記１１）
前記コンピュータに、
前記第２テーブルから、入力された読出要求で指定される読出条件に応じた情報を取得し、
前記第２テーブルから取得した情報に基づいて、前記読出要求に対する入れ子構造を含む階層構造の読出データを生成する、
処理をさらに実行させることを特徴とする、付記７〜１０のいずれか１項記載のデータ変換プログラム。
前記コンピュータに、
前記第２テーブルから、入力された読出要求で指定される読出条件に応じた情報を取得し、
前記第２テーブルから取得した情報に基づいて、前記読出要求に対する入れ子構造を含む階層構造の読出データを生成する、
処理をさらに実行させることを特徴とする、付記７〜１０のいずれか１項記載のデータ変換プログラム。
（付記１２）
前記コンピュータに、
対応する第２テーブルが存在する状態で前記第１のデータ形式で入力された入れ子構造を含む階層構造の更新データから、前記更新データの情報要素ごとに当該情報要素の値を抽出し、
抽出した情報要素の値に基づいて、対応する第２テーブルを更新する、
処理をさらに実行させることを特徴とする、付記７〜１１のいずれか１項記載のデータ変換プログラム。
前記コンピュータに、
対応する第２テーブルが存在する状態で前記第１のデータ形式で入力された入れ子構造を含む階層構造の更新データから、前記更新データの情報要素ごとに当該情報要素の値を抽出し、
抽出した情報要素の値に基づいて、対応する第２テーブルを更新する、
処理をさらに実行させることを特徴とする、付記７〜１１のいずれか１項記載のデータ変換プログラム。
（付記１３）
第１のデータ形式で入力された入れ子構造を含む階層構造のデータを、複数のテーブルで前記データを表す第２のデータ形式に変換して、前記格納部へ格納し、
前記変換において、
前記入力されたデータの情報要素ごとに、当該情報要素の値を含む第１テーブルを生成し、前記データの入れ子構造に応じて、前記複数の第１テーブルの各々を対応する他の第１テーブルと関係付け、
複数の前記第１テーブルにおける所定の条件を満たす第１テーブル同士を統合して第２テーブルを生成する、
ことを特徴とする、データ変換方法。
第１のデータ形式で入力された入れ子構造を含む階層構造のデータを、複数のテーブルで前記データを表す第２のデータ形式に変換して、前記格納部へ格納し、
前記変換において、
前記入力されたデータの情報要素ごとに、当該情報要素の値を含む第１テーブルを生成し、前記データの入れ子構造に応じて、前記複数の第１テーブルの各々を対応する他の第１テーブルと関係付け、
複数の前記第１テーブルにおける所定の条件を満たす第１テーブル同士を統合して第２テーブルを生成する、
ことを特徴とする、データ変換方法。
（付記１４）
前記第２テーブルの生成において、
前記複数の第１テーブルのうち、前記階層構造における情報要素の属する階層及び当該情報要素の種類がそれぞれ所定の関係にある第１テーブル同士を統合する、
ことを特徴とする、付記１３記載のデータ変換方法。
前記第２テーブルの生成において、
前記複数の第１テーブルのうち、前記階層構造における情報要素の属する階層及び当該情報要素の種類がそれぞれ所定の関係にある第１テーブル同士を統合する、
ことを特徴とする、付記１３記載のデータ変換方法。
（付記１５）
前記第１テーブルの生成において、
生成する前記第１テーブルに、前記情報要素の属する階層及び当該情報要素の要素名を表すテーブル名を設定し、
前記第２テーブルの生成において、
前記複数の第１テーブルの各々のテーブル名に基づき、前記情報要素の属する階層が互いに所定の関係にある第１テーブルを検出する、
ことを特徴とする、付記１４記載のデータ変換方法。
前記第１テーブルの生成において、
生成する前記第１テーブルに、前記情報要素の属する階層及び当該情報要素の要素名を表すテーブル名を設定し、
前記第２テーブルの生成において、
前記複数の第１テーブルの各々のテーブル名に基づき、前記情報要素の属する階層が互いに所定の関係にある第１テーブルを検出する、
ことを特徴とする、付記１４記載のデータ変換方法。
（付記１６）
前記第１テーブルの生成において、
生成する前記第１テーブルに、前記情報要素の種類に応じた列を設定し、
前記第２テーブルの生成において、
前記複数の第１テーブルの各々の前記列に基づき、前記情報要素の種類が互いに所定の関係にある第１テーブルを検出する、
ことを特徴とする、付記１４又は付記１５記載のデータ変換方法。
前記第１テーブルの生成において、
生成する前記第１テーブルに、前記情報要素の種類に応じた列を設定し、
前記第２テーブルの生成において、
前記複数の第１テーブルの各々の前記列に基づき、前記情報要素の種類が互いに所定の関係にある第１テーブルを検出する、
ことを特徴とする、付記１４又は付記１５記載のデータ変換方法。
（付記１７）
前記第２テーブルから、入力された読出要求で指定される読出条件に応じた情報を取得し、
前記第２テーブルから取得した情報に基づいて、前記読出要求に対する入れ子構造を含む階層構造の読出データを生成する、
ことを特徴とする、付記１３〜１６のいずれか１項記載のデータ変換方法。
前記第２テーブルから、入力された読出要求で指定される読出条件に応じた情報を取得し、
前記第２テーブルから取得した情報に基づいて、前記読出要求に対する入れ子構造を含む階層構造の読出データを生成する、
ことを特徴とする、付記１３〜１６のいずれか１項記載のデータ変換方法。
（付記１８）
対応する第２テーブルが存在する状態で前記第１のデータ形式で入力された入れ子構造を含む階層構造の更新データから、前記更新データの情報要素ごとに当該情報要素の値を抽出し、
抽出した情報要素の値に基づいて、対応する第２テーブルを更新する、
ことを特徴とする、付記１３〜１７のいずれか１項記載のデータ変換方法。
対応する第２テーブルが存在する状態で前記第１のデータ形式で入力された入れ子構造を含む階層構造の更新データから、前記更新データの情報要素ごとに当該情報要素の値を抽出し、
抽出した情報要素の値に基づいて、対応する第２テーブルを更新する、
ことを特徴とする、付記１３〜１７のいずれか１項記載のデータ変換方法。
１，１００ 情報処理システム
１４０ データベースサーバ
１４１ データベース
２，１２０ アプリサーバ（情報処理装置）
２１，１２１ アプリケーション
２２，１２２ データベース接続部
２３ データモデル変換エンジン（変換部）
２１０ アプリケーション側通信部
２２０ データベース側通信部
２３０ 書込制御部
２３２ 生成部（第１生成部）
２３４ 統合部（第２生成部）
２３６ 更新部
２４０ 読出制御部
３，１３０ ネットワークスイッチ
４ データベースサーバ（情報処理装置）
４１ データベース（格納部）
４１２ 第１テーブル
４１２ａ〜４１２ｉ，４１４ａ〜４１４ｅ テーブル
４１４ 第２テーブル
４２ 管理部
５１ ＣＰＵ
５２ メモリ
５３ 記憶部
５４ インタフェース部
５４ａ ネットワークインタフェース
５５ 入出力部
５６，５８ 記録媒体
５７ 読取部
１４０ データベースサーバ
１４１ データベース
２，１２０ アプリサーバ（情報処理装置）
２１，１２１ アプリケーション
２２，１２２ データベース接続部
２３ データモデル変換エンジン（変換部）
２１０ アプリケーション側通信部
２２０ データベース側通信部
２３０ 書込制御部
２３２ 生成部（第１生成部）
２３４ 統合部（第２生成部）
２３６ 更新部
２４０ 読出制御部
３，１３０ ネットワークスイッチ
４ データベースサーバ（情報処理装置）
４１ データベース（格納部）
４１２ 第１テーブル
４１２ａ〜４１２ｉ，４１４ａ〜４１４ｅ テーブル
４１４ 第２テーブル
４２ 管理部
５１ ＣＰＵ
５２ メモリ
５３ 記憶部
５４ インタフェース部
５４ａ ネットワークインタフェース
５５ 入出力部
５６，５８ 記録媒体
５７ 読取部
Claims (6)
- 第１のデータ形式で入力された入れ子構造を含む階層構造のデータを、複数のテーブルで前記データを表す第２のデータ形式に変換して、格納部へ格納する変換部をそなえ、
前記変換部は、
前記入力されたデータの情報要素ごとに、当該情報要素の属する階層及び当該情報要素の要素名を表すテーブル名を設定した第１テーブルを生成し、前記データの入れ子構造に応じて、前記複数の第１テーブルの各々を対応する他の第１テーブルと関係付ける第１生成部と、
複数の前記第１テーブルの各々のテーブル名に基づき、前記複数の第１テーブルの中から、前記階層構造における情報要素の属する階層及び当該情報要素の種類がそれぞれ所定の関係にある第１テーブルを検出し、当該検出した第１テーブル同士を統合して第２テーブルを生成する第２生成部と、
をそなえることを特徴とする、情報処理装置。 - 前記第１生成部は、生成する前記第１テーブルに、前記情報要素の種類に応じた列を設定し、
前記第２生成部は、前記複数の第１テーブルの各々の前記列に基づき、前記情報要素の種類が互いに所定の関係にある第１テーブルを検出する、
ことを特徴とする、請求項１記載の情報処理装置。 - 前記変換部は、
前記第２テーブルから、入力された読出要求で指定される読出条件に応じた情報を取得し、前記第２テーブルから取得した情報に基づいて、前記読出要求に対する入れ子構造を含む階層構造の読出データを生成する読出部、
をさらにそなえることを特徴とする、請求項１又は２記載の情報処理装置。 - 前記変換部は、
対応する第２テーブルが存在する状態で前記第１のデータ形式で入力された入れ子構造を含む階層構造の更新データから、前記更新データの情報要素ごとに当該情報要素の値を抽出し、抽出した情報要素の値に基づいて、対応する第２テーブルを更新する更新部、
をさらにそなえることを特徴とする、請求項１〜３のいずれか１項記載の情報処理装置。 - 入力された要求に応じた処理を格納部に対して行なうコンピュータに、
第１のデータ形式で入力された入れ子構造を含む階層構造のデータを、複数のテーブルで前記データを表す第２のデータ形式に変換して、前記格納部へ格納し、
前記変換において、
前記入力されたデータの情報要素ごとに、当該情報要素の属する階層及び当該情報要素の要素名を表すテーブル名を設定した第１テーブルを生成し、前記データの入れ子構造に応じて、前記複数の第１テーブルの各々を対応する他の第１テーブルと関係付け、
複数の前記第１テーブルの各々のテーブル名に基づき、前記複数の第１テーブルの中から、前記階層構造における情報要素の属する階層及び当該情報要素の種類がそれぞれ所定の関係にある第１テーブルを検出し、当該検出した第１テーブル同士を統合して第２テーブルを生成する、
処理を実行させることを特徴とする、データ変換プログラム。 - 入力された要求に応じた処理を格納部に対して行なうデータ変換方法であって、
第１のデータ形式で入力された入れ子構造を含む階層構造のデータを、複数のテーブルで前記データを表す第２のデータ形式に変換して、前記格納部へ格納し、
前記変換において、
前記入力されたデータの情報要素ごとに、当該情報要素の属する階層及び当該情報要素の要素名を表すテーブル名を設定した第１テーブルを生成し、前記データの入れ子構造に応じて、前記複数の第１テーブルの各々を対応する他の第１テーブルと関係付け、
複数の前記第１テーブルの各々のテーブル名に基づき、前記複数の第１テーブルの中から、前記階層構造における情報要素の属する階層及び当該情報要素の種類がそれぞれ所定の関係にある第１テーブルを検出し、当該検出した第１テーブル同士を統合して第２テーブルを生成する、
ことを特徴とする、データ変換方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2014032652A JP6260339B2 (ja) | 2014-02-24 | 2014-02-24 | 情報処理装置，データ変換プログラム，及びデータ変換方法 |
| US14/601,275 US10268644B2 (en) | 2014-02-24 | 2015-01-21 | Information processing apparatus, computer-readable recording medium having stored therein data conversion program, and data conversion method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2014032652A JP6260339B2 (ja) | 2014-02-24 | 2014-02-24 | 情報処理装置，データ変換プログラム，及びデータ変換方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2015158767A JP2015158767A (ja) | 2015-09-03 |
| JP6260339B2 true JP6260339B2 (ja) | 2018-01-17 |
Family
ID=53882412
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2014032652A Active JP6260339B2 (ja) | 2014-02-24 | 2014-02-24 | 情報処理装置，データ変換プログラム，及びデータ変換方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US10268644B2 (ja) |
| JP (1) | JP6260339B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP7189180B2 (ja) | 2019-07-10 | 2022-12-13 | フラウンホファー ゲセルシャフト ツール フェールデルンク ダー アンゲヴァンテン フォルシュンク エー．ファオ． | 逆向き磁化磁気構造体を生成する方法 |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10963963B2 (en) * | 2016-03-28 | 2021-03-30 | Investcloud Inc | Rule based hierarchical configuration |
| CN111078680B (zh) * | 2018-10-18 | 2023-09-26 | 杭州海康威视数字技术股份有限公司 | 表格信息处理方法、装置、电子设备及可读存储介质 |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH11504451A (ja) | 1995-04-24 | 1999-04-20 | アスペクト・ディベロップメント・インコーポレイテッド | データベース構造に適したオブジェクトのモデリング、リレーショナルデータベース構造への翻訳、それらへの流動的なサーチ |
| JPH09319811A (ja) | 1996-05-30 | 1997-12-12 | Toshiba Corp | 電子取引伝票の変換装置 |
| US20020116371A1 (en) * | 1999-12-06 | 2002-08-22 | David Dodds | System and method for the storage, indexing and retrieval of XML documents using relation databases |
| JP3719125B2 (ja) * | 2000-10-11 | 2005-11-24 | 日本電気株式会社 | データ格納装置及び方法 |
| JP4152107B2 (ja) * | 2002-01-16 | 2008-09-17 | 富士通株式会社 | データベース更新情報の反映システムおよびそのためのプログラム |
| JP4207438B2 (ja) * | 2002-03-06 | 2009-01-14 | 日本電気株式会社 | Ｘｍｌ文書格納／検索装置及びそれに用いるｘｍｌ文書格納／検索方法並びにそのプログラム |
| JP4272076B2 (ja) * | 2004-01-19 | 2009-06-03 | 日本電信電話株式会社 | 情報処理装置および情報処理プログラム |
| JP4822889B2 (ja) * | 2006-03-20 | 2011-11-24 | 富士通株式会社 | データベース統合参照プログラム、データベース統合参照方法及びデータベース統合参照装置 |
| JP5028894B2 (ja) * | 2006-07-18 | 2012-09-19 | 富士通株式会社 | データベースを構成する複数のテーブルを結合する結合処理をコンピュータに行わせるためのコンピュータ実行可能なプログラム |
| US8484626B2 (en) * | 2007-09-28 | 2013-07-09 | Verizon Patent And Licensing Inc. | Generic XML screen scraping |
| US8078638B2 (en) * | 2008-07-09 | 2011-12-13 | Yahoo! Inc. | Operations of multi-level nested data structure |
-
2014
- 2014-02-24 JP JP2014032652A patent/JP6260339B2/ja active Active
-
2015
- 2015-01-21 US US14/601,275 patent/US10268644B2/en active Active
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP7189180B2 (ja) | 2019-07-10 | 2022-12-13 | フラウンホファー ゲセルシャフト ツール フェールデルンク ダー アンゲヴァンテン フォルシュンク エー．ファオ． | 逆向き磁化磁気構造体を生成する方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20150242453A1 (en) | 2015-08-27 |
| US10268644B2 (en) | 2019-04-23 |
| JP2015158767A (ja) | 2015-09-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5492187B2 (ja) | 編集距離および文書情報を使用する検索結果順位付け | |
| Tiwari | Professional nosql | |
| US9760347B2 (en) | Method and system to identify GUI objects for non-markup-language-presented applications | |
| CN104573124B (zh) | 一种基于并行化关联规则算法的教育云应用统计方法 | |
| JP5710851B2 (ja) | 影響分析のためのシステムおよび方法 | |
| JP4365162B2 (ja) | 構造化文書のデータを検索する装置および方法 | |
| US7730099B2 (en) | Storage and retrieval of richly typed hierarchical network models | |
| JP2005285127A5 (ja) | ||
| CN102893281A (zh) | 信息搜索设备、信息搜索方法、计算机程序和数据结构 | |
| US20100223231A1 (en) | Merging Records From Different Databases | |
| JP2004246879A (ja) | フローデータ生成方法およびフローデータ生成装置 | |
| JP6260339B2 (ja) | 情報処理装置，データ変換プログラム，及びデータ変換方法 | |
| JP2004030221A (ja) | 変更対象テーブル自動検出方法 | |
| US10437872B2 (en) | Computer implemented and computer controlled method, computer program product and platform for arranging data for processing and storage at a data storage engine | |
| WO2017198087A1 (en) | Feature-set augmentation using knowledge engine | |
| JPWO2013111287A1 (ja) | Ｓｐａｒｑｌクエリ最適化方法 | |
| JP2006338303A (ja) | 表記変換装置、整合性チェック装置、及びプログラム | |
| JP5069525B2 (ja) | データ処理システム | |
| JP2004287835A (ja) | オブジェクト表作成方法及びオブジェクト推薦方法及びオブジェクト表作成プログラム及びオブジェクト推薦方法 | |
| JP5063447B2 (ja) | コンテンツ管理装置及び方法及びプログラム | |
| JP2007310842A (ja) | データ処理システム | |
| KR20220099745A (ko) | 지리공간 블록체인 데이터 검색을 위한 공간 분할 기반의 트리 인덱싱 및 질의어 처리 방법 및 장치 | |
| JPH10240741A (ja) | 木構造型データの管理方法 | |
| JP2009104276A (ja) | データ管理装置 | |
| JP5248762B2 (ja) | 設計データ依存関係管理装置、設計データ依存関係管理方法及びプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20161102 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20170822 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20170905 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20171102 |
|
| 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: 20171114 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20171127 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6260339 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |