JP6834715B2 - 更新処理プログラム、装置、及び方法 - Google Patents

Description

本発明は、更新処理プログラム、更新処理装置、及び更新処理方法に関する。

従来、データベースに格納されたデータの管理、及びデータベースへのアクセスの制御を行う技術が存在する。例えば、オブジェクトモデルと、ワールド（ｗｏｒｌｄ）という概念をサポートするｋｅｙ−ｖａｌｕｅデータモデルとの間の、マッピングを行うことにより、データアクセスを制御する技術が提案されている。また、第１のデータソースから取り出したオブジェクトの累積スキーマを動的に作成するシステムが提案されている。このシステムは、オブジェクトからスキーマを推論し、推論されたスキーマに従って、オブジェクトを記述するように累積スキーマを選択的に更新する。

また、業務システムなどのデータを、クラウド環境上のスキーマを使用しないデータベースであるＮｏＳＱＬ（Not only SQL）データベース（ＤＢ）で管理する仕組みがある。ＮｏＳＱＬＤＢには、データ構造に柔軟性を持たせることができるというメリットがある。

特表２０１４−５００５４４号公報 特表２０１６−５１９８１０号公報

しかし、ＮｏＳＱＬＤＢは、データ構造の柔軟性を持つことができるというメリットを持つ一方、データ間の関連性を持っていないため、データ間の関連性をそのままでは利用できない。そのため、データが格納される複数のコレクション間に、重複したデータが保持されることによるデータベース全体の容量の増加が課題となる。なお、コレクションとは、ＮｏＳＱＬＤＢにおける、データの各々が格納された１以上のレコードにより構成され、データベースへのアクセス要求に応じて参照される一群のレコードに相当する参照単位の一例である。

このような容量の増加を排除するためには、コレクション間で重複しているデータを抽出し、重複データを元のコレクションから分離して別コレクションにまとめるようにコレクションを整理する方法がある。しかし、ＮｏＳＱＬＤＢでは、データ間の関連性を持つことができないため、重複データを整理した場合、アクセスの制御に問題が生じる場合がある。例えば、ユーザ端末から、重複データを保持するコレクションに対してアクセスする場合、重複データを保持するコレクションと、重複データが分離されたコレクションとのそれぞれに対して複数回のリクエストをしなければならないという問題が生じる。

また、従来技術では、データベースを統合するように更新する時にデータ間の関連性を推論し、重複データの保持方法を改善する手法が提案されている。しかし、従来技術の提案は、データベースが保持する重複データを削減するための直接的なアプローチではないため、重複データが存在することによる容量の増加を解消するものではなかった。

本発明は、一つの側面として、スキーマを使用しないデータベースにおいて、リクエスト回数を増加させることなく、データベースの容量を削減することを目的とする。

一つの態様として、共通化された、スキーマを使用しないデータベースにおける、データの各々が格納されたレコードを有する複数の参照単位に関する共通化情報を受け付ける。共通化情報は、二つ以上の前記参照単位において共通化対象の前記レコードである共通化レコードを有する前記参照単位と、前記共通化レコードが分離された前記二つ以上の前記参照単位とを含む。前記受け付けた共通化情報に基づいて、前記データベースにおける共通化されていない複数の参照単位の各々へのアクセス要求に対する前記共通化された前記複数の参照単位の各々への参照関係を定義した参照定義情報を更新する。

一つの側面として、スキーマを使用しないデータベースにおいて、リクエスト回数を増加させることなく、データベースの容量を削減することができる、という効果を有する。

本発明の実施形態に係るＤＢ管理システムの概略構成を示すブロック図である。 重複レコードを整理する前の、アクセス要求の対象となるコレクションと、参照先のコレクションとの対応関係の一例を示す図である。 重複レコードを整理した後の、アクセス要求の対象となるコレクションと、参照先のコレクションとの対応関係の一例を示す図である。 中間サーバの機能ブロック図である。 重複レコードを整理する前の状態のＮｏＳＱＬＤＢの一例を示す図である。 重複レコードを整理した後の状態のＮｏＳＱＬＤＢの一例を示す図である。 共通化情報の一例を示す図である。 ３つ以上のコレクションについて、重複レコードを整理する前の状態のＮｏＳＱＬＤＢの一例を示す図である。 ３つ以上のコレクションについて、重複レコードを整理した後の状態のＮｏＳＱＬＤＢの一例を示す図である。 中間サーバ２０として機能するコンピュータの概略構成を示すブロック図である。 各装置間での情報のやり取りを示すシーケンス図である。 更新処理の一例を示すフローチャートである。 制御処理の一例を示すフローチャートである。 ユーザ端末からのアクセス要求のリクエストパス、制御部が生成したリクエストパス、及びコレクションから取得した結果の一例を示す図である。 統合されたリクエスト結果の一例を示す図である。 重複レコードを整理した場合のアクセスの問題点の一例を示す図である。

以下、図面を参照して本発明に係る実施形態の一例を詳細に説明する。

まず、本発明の実施形態の詳細を説明する前に、スキーマを使用しないデータベースの特徴、及びスキーマを使用しないデータベースにおいて、重複したデータ（以下、重複データと表記する）を整理しようとする場合の問題点を説明する。本発明の実施形態では、スキーマを使用しないデータベースとして、例えばＮｏＳＱＬ（Not only SQL）データベース（ＤＢ）を用いる。スキーマを使用しないデータベースとは、データ構造を定義していないデータベースであることを意味する。これは、ＲＤＢＭＳ（Relational DataBase Management System）のデータベースのデータ構造が属性と組のテーブルによって定義されているのに対し、このようなデータ構造を持たないことを表す。

ＮｏＳＱＬＤＢは、スキーマを使用していないため、データ構造の柔軟性を持つことができるというメリットを持つ一方、データ間の関連性を持っていないため、データ間の関連性をそのままでは利用できない。ＮｏＳＱＬＤＢに格納されるデータは、スキーマを使用しないコレクションという参照単位によって管理される。コレクションは、データの各々が格納された１以上のレコードにより構成され、データベースへのアクセス要求に応じて参照される一群のレコードに相当する参照単位である。

このＮｏＳＱＬＤＢでは、データ間の関連性を持つことができないため、複数のコレクション間に、重複データが保持されてしまい、データベース全体の容量が増加してしまうという問題が生じる。容量の増加の問題に対処するためには、コレクション間で重複データを抽出し、重複データを元のコレクションから分離して別コレクションにまとめるようにコレクションを整理する方法がある。ここで、本実施形態では、重複データを整理する単位は、レコード単位であるため、重複データが格納されたレコードを以下、重複レコードと表記する。重複レコードを別コレクションにまとめることにより、コレクション間で重複していたデータを共通化して取り扱うことが可能となる。また、元のコレクションからは重複レコードは削除されるため容量の削減につながる。

しかし、ＮｏＳＱＬＤＢでは、データ間の関連性を持つことができないため、重複レコードを整理した場合、アクセスの制御に問題が生じる場合がある。例えば、図１６に示すように、重複レコードをcollectionA及びcollectionBから分離して、collectionABにまとめるようにコレクションを整理したとする。また、collectionA及びcollectionBから、重複レコードが分離された後は、collectionA’及びcollectionB’であるとする。この場合、ユーザ端末から、整理前のcollectionAのデータに対してアクセスしようとする場合、collectionABと、collectionA’とのそれぞれに対して複数回のリクエストをしなければならないという問題が生じる。また、この場合、ユーザ端末のリクエストを、整理後の複数のコレクションを指定するように更新する必要があるが、ＮｏＳＱＬＤＢの整理の度にユーザ端末のリクエストを更新するのは合理的ではない。

よって、ＮｏＳＱＬＤＢ内のデータ間の関連性が分かっており、関連性に対応したＤＢの整理を行う場合には、アクセスを制御して、整理されたＮｏＳＱＬＤＢの内容に応じて、アクセス先のコレクションを指定する機構が必要である。このような機構を導入して、整理されたＮｏＳＱＬＤＢの内容に応じたアクセスの制御を可能にすることで、ユーザ端末からのリクエストを変えることなく、ＮｏＳＱＬＤＢの容量を削減することができる。

そこで、本発明の実施形態では、ユーザ端末からデータベースサーバへのアクセスを中継する中間サーバの機構を設け、整理されたＮｏＳＱＬＤＢの内容に応じたアクセスの制御を行う場合について説明する。中間サーバには、定義用ＤＢを設ける。定義用ＤＢには、アクセスに対して、整理されたＮｏＳＱＬＤＢの内容に対応した、整理前後のコレクションの対応関係を記述した参照定義情報が保持される。

図１に示すように、本実施形態に係るＤＢ管理システム１００は、管理者端末１０と、複数のユーザ端末１２と、中間サーバ２０と、データベースサーバ３０とを含む。管理者端末１０と、複数のユーザ端末１２と、中間サーバ２０と、データベースサーバ３０とは、インターネット等のネットワークを介して接続される。なお、ユーザ端末１２の数は、図１の例に限定されない。

管理者端末１０は、中間サーバ２０及びデータベースサーバ３０のＮｏＳＱＬＤＢ３１の保守及び管理を行う管理者等が利用する情報処理端末である。ＮｏＳＱＬＤＢ３１の内容を更新する場合には、管理者端末１０から作業を行う。管理者端末１０は、例えば、パーソナルコンピュータ（ＰＣ）、ノート型ＰＣ等で実現することができる。

ユーザ端末１２は、業務システム等からデータベースサーバ３０に存在するデータにアクセスする情報処理端末である。ユーザ端末１２は、例えば、ノート型ＰＣ、タブレット端末、スマートフォン等で実現することができる。

中間サーバ２０は、定義用ＤＢ２２を管理するサーバである。定義用ＤＢ２２は、データベースサーバ３０のＮｏＳＱＬＤＢ３１のレコードが共通化されていない複数のコレクションの各々へのアクセス要求に対する、共通化された複数のコレクションの各々への参照関係を定義した参照定義情報を保持している。定義用ＤＢ２２の更新は、データベースサーバ３０のＮｏＳＱＬＤＢ３１が更新された場合に、更新部２４の処理を実行することにより行われる。また、中間サーバ２０は、ユーザ端末１２からデータベースサーバ３０へのアクセスの制御を行うサーバである。ユーザ端末１２からのアクセス要求があった場合に、リクエストに対応した定義用ＤＢ２２の参照定義情報を参照し、参照定義情報に指定されたコレクションへアクセスする制御を行う。

データベースサーバ３０は、ＮｏＳＱＬＤＢ３１を有するサーバである。ＮｏＳＱＬＤＢ３１は、開示の技術のスキーマを使用しないデータベースの一例である。

ここで、図２及び図３に、中間サーバ２０の定義用ＤＢ２２で保持される参照定義情報により定義される、アクセス要求の対象となるコレクションと、データベースサーバ３０のＮｏＳＱＬＤＢ３１の参照先となるコレクションとの対応関係の例を示す。図２に、重複レコードが共通化されていない想定の、アクセス要求の対象となるコレクションと、参照先のコレクションとの対応関係の例を示す。図３に、重複レコードを共通化した後の、アクセス要求の対象となるコレクションと、参照先のコレクションとの対応関係の例を示す。図２及び図３に示すように、定義用ＤＢ２２には、参照定義情報として、アクセス要求の対象となるcollectionAに対応するdefinitionA、及びアクセス要求の対象となるcollectionBに対応するdefinitionBがあるとする。definitionA及びdefinitionBには、それぞれ参照先としてコレクション群が定義されている。図２に示すように、重複レコードが共通化されていない状態では、ＮｏＳＱＬＤＢ３１のアクセス要求の対象となるcollectionAに対応するdefinitionAのコレクション群には、collectionAが指定されている。また、アクセス要求の対象となるcollectionBに対応するdefinitionBのコレクション群には、collectionBが指定されている。ここで、collectionA、及びcollectionBの各々に含まれる１つのレコードが重複していたとすると、この重複したレコードを共通化対象の共通化レコードとする。本実施形態では、共通化レコードを元のcollectionA及びcollectionBから分離して、別のcollectionABとして共通化すると共に、共通化レコードを有していたcollectionA、及びcollectionBに対応する定義用ＤＢ２２のdefinitionA、及びdefinitionBを更新する。重複レコードを共通化して更新した後の状態では、図３に示すように、アクセス要求の対象となるcollectionAに対応するdefinitionAのコレクション群には、collectionAB、及びcollectionA’（以下、説明の便宜のため、共通化レコードが分離された更新後のコレクション名に’を付す）が指定されている。また、アクセス要求の対象となるcollectionBに対応するdefinitionBのコレクション群には、collectionAB、及びcollectionB’が指定されている。

中間サーバ２０は、図４に示すように、機能的には、定義用ＤＢ２２と、受信部２３と、更新部２４と、制御部２５と、送信部２６とを含む。

受信部２３は、例えば、管理者端末１０から送信されたＮｏＳＱＬＤＢの共通化情報（詳細は後述）を受信する。また、受信部２３は、例えば、ユーザ端末１２からのアクセス要求を受信する。

更新部２４は、共通化情報に基づいて、定義用ＤＢ２２を更新する。また、更新部２４は、受信部２３により共通化情報が受け付けられたときに、更新中のフラグをオンにすると共に、定義用ＤＢ２２に含まれる参照定義情報の更新を開始する。これらの更新部２４の処理は、例えば、参照定義情報更新ＡＰＩ（Application Programming Interface）として実現可能である。ここで、具体的な定義用ＤＢ２２の更新内容について、ＮｏＳＱＬＤＢ３１の更新内容と共に説明する。

例えば、重複レコードが共通化されていない状態で、図５に示すように、ＮｏＳＱＬＤＢ３１にcollectionA、及びcollectionBが格納されていたとする。collectionAの１行目のレコードには、keyと値のペア（以下、「"key":"値"」と表記する）をデータとして、「"name":"FujitsuTaro","age":23,"employeeNumber":00123456」が格納されている。２行目のレコードには、「"name":"FujitsuTaro","hobby":"trip"」が格納されている。また、collectionBの１行目のレコードには、「"name":"FujitsuTaro","age":23,"employeeNumber":00123456」が格納されている。collectionBの２行目のレコードには、「"ID":"UserXX","score":1234,"rank":3456,"date":20160926」が格納されている。

ここで、collectionA、及びcollectionBの１行目のレコードは、全てのデータにおいて、keyと値のペアが同一であるため、共通化対象のレコードである共通化レコードといえる。そこで、管理者は、管理者端末１０を操作して、共通化レコードを有するcollectionABと、collectionA及びcollectionBの各々から共通化レコードを分離（削除）したcollectionA’、及びcollectionB’とを保持するようにＮｏＳＱＬＤＢ３１のコレクション群を整理する。整理後は、図６に示すように、collectionA’の１行目のレコードには、「"name":"FujitsuTaro","hobby":"trip"」が格納されている。collectionB’の１行目のレコードには、「"ID":"UserXX","score":1234,"rank":3456,"date":20160926」が格納されている。collectionABの１行目のレコードには「"name":"FujitsuTaro","hobby":"trip"」が格納されている。

上記のようにＮｏＳＱＬＤＢ３１が整理された後、管理者は、管理者端末１０を操作して、中間サーバ２０へ共通化情報を送信すると共に、定義用ＤＢ２２に含まれる参照定義情報を更新する。管理者端末１０から送信される共通化情報は、具体的には、図７に示すように、コレクションに対する参照定義情報（definition）のパスとボディによって記述される。パスは、定義用ＤＢ２２の参照定義情報のうち、共通化されていないコレクションであって、アクセス要求の対象となるコレクションに対応する参照定義情報への参照パスである。ボディは、共通化されたＮｏＳＱＬＤＢ３１の参照先となるコレクション群を記述したものである。図７は、definitionAの参照パス及びボディを記述したものの一例である。ボディには、共通化されたＮｏＳＱＬＤＢ３１の参照先となるコレクション群（collections）として、collectionAB、及びcollectionA’が記述されている。また、共通化情報として、definitionBについても同様にパス及びボディを記述したものを受け付ける。これにより、更新の対象となる定義用ＤＢ２２の参照定義情報であるdefinitionA、及びdefinitionBを更新する。

上記の例では、２つのコレクションについて共通化レコードを共通化して、コレクション群を整理する場合について説明したが、３つ以上のコレクションについて共通化レコードを共通化して、コレクション群を整理する場合の例についても説明する。

図８に示すように、ＮｏＳＱＬＤＢ３１にcollectionA、collectionB、collectionC、及びcollectionDが格納されていたとする。collectionA、及びcollectionBの内容については、上記図５の説明と同様である。collectionCの１行目のレコードには、keyと値のペアをデータとして、「"name":"FujitsuTaro","age":23,"employeeNumber":00123456」が格納されている。２行目のレコードには、「"ID":"UserXX","score":1234,"rank":3456,"date":20160926」が格納されている。３行目のレコードには、「"name":"YamadaHanako","age":35」が格納されている。collectionDの１行目のレコードには、「"name":"TanakaJiro","age":31,"employeeNumber":00222456」が格納されている。２行目のレコードには、「"name":"TanakaJiro","hobby":"trip"」が格納されている。

ここで、collectionA、collectionB、及びcollectionCの１行目のレコードは、全てのデータにおいて、keyと値のペアが同一であるため、共通化対象のレコードである共通化レコードといえる。また、collectionB、及びcollectionCの２行目のレコードも共通化レコードである。そこで、管理者は、管理者端末１０を操作してコレクション群を整理する。例えば、共通化レコードを有するcollectionABC、及びcollectionBCと、共通化レコードが分離されたcollectionA’、及びcollectionC’と、変更のないcollectionDとを保持するようにＮｏＳＱＬＤＢ３１のコレクション群に整理する。整理後は、図９に示すように、collectionABCの１行目のレコードには「"name":"FujitsuTaro","hobby":"trip"」が格納されている。collectionA’の１行目のレコードには、「"name":"FujitsuTaro","hobby":"trip"」が格納されている。collectionBCの１行目のレコードには、「"ID":"UserXX","score":1234,"rank":3456,"date":20160926」が格納されている。collectionC’の１行目のレコードには、「"name":"YamadaHanako","age":35」が格納されている。

この場合、共通化情報は、definitionA、definitionB、及びdefinitionCのそれぞれについてのパス及びボディを受け付ける。definitionAの共通化情報のボディには、共通化されたＮｏＳＱＬＤＢ３１の参照先となる、collectionABC、及びcollectionA’が記述される。また、definitionBの共通化情報のボディには、共通化されたＮｏＳＱＬＤＢ３１の参照先となる、collectionABC、及びcollectionBCが記述される。また、definitionCの共通化情報のボディには、共通化されたＮｏＳＱＬＤＢ３１の参照先となる、collectionABC、collectionBC、及びcollectionC’が記述される。

制御部２５は、ユーザ端末１２からのアクセス要求に対する、データベースサーバ３０への参照やユーザ端末１２へのレスポンスを制御する。また、制御部２５は、更新中のフラグを参照して、更新部２４で定義用ＤＢ２２を更新している場合、ユーザ端末１２からのアクセス要求を待機させるように制御する。制御部２５の具体的な処理内容は後述する作用において詳細に説明する。

送信部２６は、更新部２４の更新処理が終了した場合に、終了したことを管理者端末１０に通知する。また、制御部２５でＮｏＳＱＬＤＢ３１から取得したリクエスト結果をユーザ端末１２に返却する。

中間サーバ２０は、例えば図１０に示すコンピュータ４０で実現することができる。コンピュータ４０は、Central Processing Unit（ＣＰＵ）４１と、一時記憶領域としてのメモリ４２と、不揮発性の記憶部４３とを備える。また、コンピュータ４０は、入出力装置４４と、記憶媒体４９に対するデータの読み込み及び書き込みを制御するRead/Write（Ｒ／Ｗ）部４５と、インターネット等のネットワークに接続される通信インターフェース（Ｉ／Ｆ）４６とを備える。ＣＰＵ４１、メモリ４２、記憶部４３、入出力装置４４、Ｒ／Ｗ部４５、及び通信Ｉ／Ｆ４６は、バス４７を介して互いに接続される。

記憶部４３は、Hard Disk Drive（ＨＤＤ）、Solid State Drive（ＳＳＤ）、フラッシュメモリ等によって実現できる。記憶媒体としての記憶部４３には、コンピュータ４０を中間サーバ２０として機能させるための更新処理プログラム５０及び制御プログラム６０が記憶される。更新処理プログラム５０は、受信プロセス５２と、送信プロセス５４と、更新プロセス５６とを有する。制御プログラム６０は、受信プロセス６２と、送信プロセス６４と、要求プロセス６６とを有する。また、記憶部４３は、定義用ＤＢ２２を構成する情報が記憶される情報記憶領域７０を有する。

ＣＰＵ４１は、更新処理プログラム５０を記憶部４３から読み出してメモリ４２に展開し、更新処理プログラム５０が有するプロセスを順次実行する。ＣＰＵ４１は、受信プロセス５２を実行することで、図４に示す受信部２３として動作する。また、ＣＰＵ４１は、送信プロセス５４を実行することで、図４に示す送信部２６として動作する。また、ＣＰＵ４１は、更新プロセス５６を実行することで、図４に示す更新部２４として動作する。また、ＣＰＵ４１は、情報記憶領域７０から情報を読み出して、定義用ＤＢ２２をメモリ４２に展開する。これにより、更新処理プログラム５０を実行したコンピュータ４０が、更新処理を行う中間サーバ２０として機能することになる。

また、ＣＰＵ４１は、制御プログラム６０を記憶部４３から読み出してメモリ４２に展開し、制御プログラム６０が有するプロセスを順次実行する。ＣＰＵ４１は、受信プロセス６２を実行することで、図４に示す受信部２３として動作する。また、ＣＰＵ４１は、送信プロセス６４を実行することで、図４に示す送信部２６として動作する。また、ＣＰＵ４１は、情報記憶領域７０から情報を読み出して、定義用ＤＢ２２をメモリ４２に展開する。また、データベースサーバ３０から受信したデータをメモリ４２に展開する。これにより、制御プログラム６０を実行したコンピュータ４０が、アクセス要求の制御を行う中間サーバ２０として機能することになる。

なお、更新処理プログラム５０及び制御プログラム６０により実現される機能は、例えば半導体集積回路、より詳しくはApplication Specific Integrated Circuit（ＡＳＩＣ）等で実現することも可能である。

次に、本実施形態に係るＤＢ管理システム１００の作用について説明する。まず、図１１のシーケンス図を参照して、各装置間での情報のやり取りについて説明する。

まず、管理者は管理者端末１０を操作して、データベースサーバ３０のＮｏＳＱＬＤＢ３１に対し、共通化レコードを有するコレクションの共通化（整理）を実行する（Ｓ１１）。データベースサーバ３０は、コレクションの共通化が完了すると、管理者端末１０に完了したことを通知する（Ｓ１２）。なお、共通化を実行してから完了の通知を受け取るまでの間、管理者はデータベースサーバ３０の稼動を停止させ、ユーザ端末１２からのアクセス要求を受け付けないようにしてもよい。

管理者端末１０がデータベースサーバ３０から共通化が完了した通知を受け取ると、管理者は管理者端末１０を操作して、共通化情報を中間サーバ２０に送信する（Ｓ１３）。

中間サーバ２０は、共通化情報を受信すると、更新中のフラグをオンにすると共に、定義用ＤＢ２２に含まれる更新定義情報の更新を開始する（Ｓ１４）。

中間サーバ２０は、共通化情報に基づいて、定義用ＤＢ２２の参照定義情報のうち、コレクションの共通化によって変更があったコレクションに対応する参照定義情報の更新を定義数分だけ繰り返し実行する（Ｓ１５）。また、中間サーバ２０は、参照定義情報を更新する毎に、更新が成功した場合には、管理者端末１０に更新の成功を示す実行結果を送信する（Ｓ１６）。なお、更新がエラーだった場合には、中間サーバ２０は、管理者端末１０に更新がエラーになったことを示す実行結果を送信し、更新を繰り返すことなく、後述する更新中のフラグをオフにする処理に移行する。管理者は、管理者端末１０で、更新がエラーになったことを示す実行結果を受信した場合、速やかにデータベースのロールバックを行うか、共通化情報を見直して改めて更新を実行する等の対応を行う必要がある。

一方、参照定義情報の更新中のフラグがオンのときに、ユーザ端末１２が操作され、ユーザ端末１２から中間サーバ２０へ、例えばコレクションＡに対するアクセス要求が送信されたとする（Ｓ１７）。このとき中間サーバ２０は、更新中のフラグがオンになっているため、ユーザ端末１２に対して待機の通知を送信する（Ｓ１８）。

中間サーバ２０は、全ての参照定義情報の更新が完了すると、更新中のフラグをオフにし（Ｓ１９）、管理者端末１０に更新が終了したことを通知する（Ｓ２０）。なお、中間サーバ２０は、例えば参照定義情報ごとに更新中のフラグを設け、参照定義情報を更新するごとに当該参照定義情報の更新中のフラグをオフにするようにしてもよい。

次に、中間サーバ２０は、定義用ＤＢ２２から、アクセス要求があったコレクションＡに対応する参照定義情報であるdefinitionAを取得し（Ｓ２１）、definitionAからコレクション群を抽出する（Ｓ２２）。

中間サーバ２０は、抽出されたコレクション群からコレクションを指定して、データベースサーバ３０に対してデータ取得のリクエストを行う（Ｓ２３）。データベースサーバ３０は中間サーバ２０からリクエストを受け取ると、指定されたコレクションに対応するＮｏＳＱＬＤＢ３１のコレクションを参照し、当該コレクションのデータを中間サーバ２０に返却する（Ｓ２４）。中間サーバ２０は、データベースサーバ３０から返却された結果をメモリ４２に格納する（Ｓ２５）。中間サーバ２０は、Ｓ２３〜Ｓ２５の処理を、抽出されたコレクション群の全てのコレクションについて繰り返し行う。

中間サーバ２０は、Ｓ２３〜Ｓ２５でメモリに格納された全てのコレクションの結果を統合し（Ｓ２６）、コレクションＡのレスポンス結果としてユーザ端末１２に送信する（Ｓ２７）。

次に、中間サーバ２０で実行される更新処理、及び制御処理について説明する。例えば、管理者端末１０から送信された共通化情報を中間サーバ２０が受信すると、中間サーバ２０において、図１２に示す更新処理が実行される。また、ユーザ端末１２からアクセス要求を受け付けた際などに、中間サーバ２０において、図１３に示す制御処理が実行される。

まず、中間サーバ２０において実行される更新処理について説明する。

図１２のステップＳ３１で、受信部２３が、管理者端末１０から共通化情報を受け付ける。次に、ステップＳ３２で、更新部２４が、中間サーバ２０の更新中のフラグをオンにすると共に、参照定義情報の更新を開始する。

ステップＳ３３で、更新部２４が、共通化情報に記述されている、共通化によって変更されたコレクションに対応する参照定義情報を指定する。ステップＳ３４で、共通化情報に基づいて、ステップＳ３３で指定された参照定義情報を更新する。例えば図７に示すようにdefinitionAが指定されている場合、definitionAのコレクション群が、collectionAB及びcollectionA’となるように更新される。

ステップＳ３５で、更新部２４が、指定された参照定義情報の更新が成功したか否かを判定する。

ステップＳ３５で、更新に成功したと判定された場合には、ステップＳ３６で、送信部２６が、更新に成功したことを更新の実行結果として管理者端末１０に送信し、ステップＳ３８へ移行する。

一方、ステップＳ３５で、更新に成功していると判定されなかった場合には、ステップＳ３７で、送信部２６が、更新にエラーが起きて失敗であったことを更新の実行結果として管理者端末１０に送信し、ステップＳ３９へ移行する。

ステップＳ３８で、更新部２４が、共通化情報において更新対象になっている全ての参照定義情報について、更新が終了したかを判定する。更新が終了していると判定された場合には、処理は、ステップＳ３９へ移行し、更新が終了していると判定されなかった場合には、処理は、ステップＳ３３に戻って次の参照定義情報を指定して処理を繰り返す。

ステップＳ３９で、更新部２４が、更新中のフラグをオフにする。そして、ステップＳ４０で、送信部２６が、更新の終了を管理者端末１０に通知して更新処理を終了する。

次に、中間サーバ２０において実行される制御処理について説明する。

図１３のステップＳ４１で、受信部２３が、ユーザ端末１２からのアクセス要求を受け付けると、ステップＳ４２で、制御部２５が、中間サーバ２０の更新中のフラグがオンかを判定する。更新中のフラグがオンである場合には、処理は、ステップＳ４３へ移行し、更新中のフラグがオンでない場合には、処理は、ステップＳ４５へ移行する。

ステップＳ４３で、送信部２６が、ユーザ端末１２に待機の通知を送信する。

ステップＳ４４で、制御部２５が、中間サーバ２０の更新中のフラグがオフかを判定する。更新中のフラグがオフである場合には、処理は、ステップＳ４５へ移行し、更新中のフラグがオフでない場合には、処理は、ステップＳ４３へ移行し、ユーザ端末１２に待機の通知を送信することを繰り返す。

次にステップＳ４５で、制御部２５が、ユーザ端末１２からのアクセス要求のリクエストパスから参照定義情報を取得する。リクエストパスが、例えば図１４（Ａ）に示すようなＧＥＴ文のパスであったとすると、制御部２５は、定義用ＤＢ２２から、参照定義情報であるdefinitionAを取得する。また、図１４（Ａ）のリクエストパスでは、コレクションのレコードの中から、whereによる絞り込みで「"name":"FujitsuTaro"」に該当するkeyと値のペアとなるデータを持つレコードを取得するということを表している。

ステップＳ４６で、制御部２５が、ステップＳ４５で取得した参照定義情報からコレクション群を抽出する。例えば図３に示すdefinitionAが取得されている場合、コレクション群として、collectionAB及びcollectionA’が抽出される。

ステップＳ４７で、制御部２５が、ステップＳ４６で抽出したコレクション群からコレクションを指定し、リクエストパスを生成する。リクエストパスは、例えば図１４（Ｂ）に示すように、指定されたコレクションごとに生成したＧＥＴ文とすることができる。図１４（Ｂ）は、ＮｏＳＱＬＤＢ３１のコレクションであるcollectionAB、及びcollectionA’についてのリクエストパスの一例である。なお、「filter_name=***」によるレコードの絞り込みはＤＢＭＳ（Database Management System）がmongoDBである場合の記述の一例である。

ステップＳ４８で、制御部２５が、指定したコレクションについて、データベースサーバ３０にリクエストを行い、リクエストパスに記述されたＮｏＳＱＬＤＢ３１のコレクションから結果を取得する。図１４（Ｃ）は、collectionAB、及びcollectionA’についての取得結果の一例である。

ステップＳ４９で、制御部２５が、指定したコレクションの取得に成功したか否かを判定する。

ステップＳ４９で、取得に成功していると判定された場合には、ステップＳ５０で、制御部２５が、指定したコレクションについての取得結果をメモリ４２に格納して、ステップＳ５２へ移行する。

一方、ステップＳ４９で、取得に成功していないと判定された場合には、ステップＳ５１で、送信部２６が、リクエスト結果がエラーであったことをユーザ端末１２に送信し、制御処理を終了する。

ステップＳ５２で、制御部２５が、取得対象の全てのコレクションについて取得処理が終了したか否かを判定する。全てのコレクションについて取得処理が終了していると判定された場合には、処理は、ステップＳ５３へ移行する。また、全てのコレクションについて取得処理が終了していると判定されなかった場合には、ステップＳ４７へ戻って次のコレクションを指定して取得処理を繰り返す。

ステップＳ５３で、制御部２５が、ステップＳ５０でメモリ４２に格納された、definitionAに対応する全てのコレクションについての取得結果をリクエスト結果として統合する。図１５にリクエスト結果の一例を示す。図１５の例では、リクエスト結果として"results"のデータにcollectionAB、及びcollectionA’の内容が統合されている。

ステップＳ５４で、送信部２６が、ステップＳ５３で統合されたリクエスト結果をユーザ端末１２に送信して、制御処理を終了する。

以上説明したように、本実施形態に係るＤＢ管理システムによれば、スキーマを使用しないデータベースにおいて、整理されたコレクションに応じた定義用ＤＢの更新、及び更新した定義用ＤＢに応じたデータベースへのアクセスの制御を行うことを可能にする。このため、リクエスト回数を増加させることなく、データベースの容量を削減することができる。

また、定義用ＤＢの更新中は、ユーザ端末からのアクセスを待機させることで、ユーザ端末に対し、定義用ＤＢが更新される前の不整合なレスポンス結果を送信してしまうことを防止することができる。

また、上述した実施形態では、中間サーバを設ける場合について説明したが、これに限定されるものではなく、中間サーバの機能（受信部、更新部、制御部、及び送信部）をデータベースサーバに設けるようにしてもよい。

また、上述した実施形態では、ＮｏＳＱＬＤＢのコレクションを整理し、アクセスを制御する機構を設ける場合について説明したが、これに限定されるものではない。例えば、他のスキーマを使用しないデータベースに対応する参照単位を整理し、アクセスを制御する機構を設けるようにしてもよい。

以上の実施形態に関し、更に以下の付記を開示する。

（付記１）
スキーマを使用しないデータベースにおける、データの各々が格納されたレコードを有する複数の参照単位であって、二つ以上の前記参照単位において共通化対象の前記レコードである共通化レコードを有する前記参照単位と、前記共通化レコードが分離された前記二つ以上の前記参照単位とを含む、共通化された前記複数の参照単位に関する共通化情報を受け付け、
前記受け付けた共通化情報に基づいて、前記データベースにおける共通化されていない複数の参照単位の各々へのアクセス要求に対する前記共通化された前記複数の参照単位の各々への参照関係を定義した参照定義情報を更新する
ことを含む処理をコンピュータに実行させることを特徴とする更新処理プログラム。

（付記２）
前記共通化情報を受け付けてから、前記参照定義情報の更新が行われるまでの間において、前記データベースへのアクセス要求があった場合に、前記アクセス要求に対する応答を予め定められた条件を満たすまで待機させる
ことを含む処理を実行させることを特徴とする付記１に記載の更新処理プログラム。

（付記３）
前記参照定義情報を更新する際に、前記受け付けた共通化情報に基づいて、
前記アクセス要求に対する共通化された前記参照単位が変更となる、共通化されていない参照単位について、前記参照定義情報を更新することを特徴とする付記１又は付記２に記載の更新処理プログラム。

（付記４）
スキーマを使用しないデータベースにおける、データの各々が格納されたレコードを有する複数の参照単位であって、二つ以上の前記参照単位において共通化対象の前記レコードである共通化レコードを有する前記参照単位と、前記共通化レコードが分離された前記二つ以上の前記参照単位とを含む、共通化された前記複数の参照単位に関する共通化情報を受け付ける受信部と、
前記受け付けた共通化情報に基づいて、前記データベースにおける共通化されていない複数の参照単位の各々へのアクセス要求に対する前記共通化された前記複数の参照単位の各々への参照関係を定義した参照定義情報を更新する更新部と、
を含む更新処理装置。

（付記５）
前記更新部は、前記共通化情報を受け付けてから、前記参照定義情報の更新が行われるまでの間において、前記データベースへのアクセス要求があった場合に、前記アクセス要求に対する応答を予め定められた条件を満たすまで待機させる付記４に記載の更新処理装置。

（付記６）
前記更新部は、前記参照定義情報を更新する際に、前記受け付けた共通化情報に基づいて、前記アクセス要求に対する共通化された前記参照単位が変更となる、共通化されていない参照単位について、前記参照定義情報を更新する付記４又は付記５に記載の更新処理装置。

（付記７）
スキーマを使用しないデータベースにおける、データの各々が格納されたレコードを有する複数の参照単位であって、二つ以上の前記参照単位において共通化対象の前記レコードである共通化レコードを有する前記参照単位と、前記共通化レコードが分離された前記二つ以上の前記参照単位とを含む、共通化された前記複数の参照単位に関する共通化情報を受け付け、
前記受け付けた共通化情報に基づいて、前記データベース３１における共通化されていない複数の参照単位の各々へのアクセス要求に対する前記共通化された前記複数の参照単位の各々への参照関係を定義した参照定義情報を更新する
ことを含む処理をコンピュータが実行することを特徴とする更新処理方法。

（付記８）
前記共通化情報を受け付けてから、前記参照定義情報の更新が行われるまでの間において、前記データベースへのアクセス要求があった場合に、前記アクセス要求に対する応答を予め定められた条件を満たすまで待機させることを特徴とする付記７に記載の更新処理方法。

（付記９）
前記参照定義情報を更新する際に、前記受け付けた共通化情報に基づいて、
前記アクセス要求に対する共通化された前記参照単位が変更となる、共通化されていない参照単位について、前記参照定義情報を更新することを特徴とする付記７又は付記８に記載の更新処理方法。

１０ 管理者端末
１２ ユーザ端末
２０ 中間サーバ
２２ 定義用ＤＢ
２３ 受信部
２４ 更新部
２５ 制御部
２６ 送信部
３０ データベースサーバ
３１ ＮｏＳＱＬＤＢ
４０ コンピュータ
４１ ＣＰＵ
４２ メモリ
４３ 記憶部
４９ 記憶媒体
５０ 更新処理プログラム
６０ 制御プログラム
７０ 情報記憶領域
１００ 管理システム

Claims (5)

1. スキーマを使用しないデータベースにおける、データの各々が格納されたレコードを有する複数の参照単位であって、二つ以上の前記参照単位において共通化対象の前記レコードである共通化レコードを有する前記参照単位と、前記共通化レコードが分離された前記二つ以上の前記参照単位とを含む、共通化された前記複数の参照単位に関する共通化情報を受け付け、
   前記受け付けた共通化情報に基づいて、前記データベースにおける共通化されていない複数の参照単位の各々へのアクセス要求に対する前記共通化された前記複数の参照単位の各々への参照関係を定義した参照定義情報を更新する、
   ことを含む処理をコンピュータに実行させることを特徴とする更新処理プログラム。
2. 前記共通化情報を受け付けてから、前記参照定義情報の更新が行われるまでの間において、前記データベースへのアクセス要求があった場合に、前記アクセス要求に対する応答を予め定められた条件を満たすまで待機させることを特徴とする請求項１に記載の更新処理プログラム。
3. 前記参照定義情報を更新する際に、前記受け付けた共通化情報に基づいて、
   前記アクセス要求に対する共通化された前記参照単位が変更となる、共通化されていない参照単位について、前記参照定義情報を更新することを特徴とする請求項１又は請求項２に記載の更新処理プログラム。
4. スキーマを使用しないデータベースにおける、データの各々が格納されたレコードを有する複数の参照単位であって、二つ以上の前記参照単位において共通化対象の前記レコードである共通化レコードを有する前記参照単位と、前記共通化レコードが分離された前記二つ以上の前記参照単位とを含む、共通化された前記複数の参照単位に関する共通化情報を受け付ける受信部と、
   前記受け付けた共通化情報に基づいて、前記データベースにおける共通化されていない複数の参照単位の各々へのアクセス要求に対する前記共通化された前記複数の参照単位の各々への参照関係を定義した参照定義情報を更新する更新部と、
   を含む更新処理装置。
5. スキーマを使用しないデータベースにおける、データの各々が格納されたレコードを有する複数の参照単位であって、二つ以上の前記参照単位において共通化対象の前記レコードである共通化レコードを有する前記参照単位と、前記共通化レコードが分離された前記二つ以上の前記参照単位とを含む、共通化された前記複数の参照単位に関する共通化情報を受け付け、
   前記受け付けた共通化情報に基づいて、前記データベースにおける共通化されていない複数の参照単位の各々へのアクセス要求に対する前記共通化された前記複数の参照単位の各々への参照関係を定義した参照定義情報を更新する
   ことを含む処理をコンピュータが実行することを特徴とする更新処理方法。