以下、図面を参照して本発明に係る実施形態の一例を詳細に説明する。
まず、本発明の実施形態の詳細を説明する前に、スキーマを使用しないデータベースの特徴、及びスキーマを使用しないデータベースにおいて、重複したデータ(以下、重複データと表記する)を整理しようとする場合の問題点を説明する。本発明の実施形態では、スキーマを使用しないデータベースとして、例えばNoSQL(Not only SQL)データベース(DB)を用いる。スキーマを使用しないデータベースとは、データ構造を定義していないデータベースであることを意味する。これは、RDBMS(Relational DataBase Management System)のデータベースのデータ構造が属性と組のテーブルによって定義されているのに対し、このようなデータ構造を持たないことを表す。
NoSQLDBは、スキーマを使用していないため、データ構造の柔軟性を持つことができるというメリットを持つ一方、データ間の関連性を持っていないため、データ間の関連性をそのままでは利用できない。NoSQLDBに格納されるデータは、スキーマを使用しないコレクションという参照単位によって管理される。コレクションは、データの各々が格納された1以上のレコードにより構成され、データベースへのアクセス要求に応じて参照される一群のレコードに相当する参照単位である。
このNoSQLDBでは、データ間の関連性を持つことができないため、複数のコレクション間に、重複データが保持されてしまい、データベース全体の容量が増加してしまうという問題が生じる。容量の増加の問題に対処するためには、コレクション間で重複データを抽出し、重複データを元のコレクションから分離して別コレクションにまとめるようにコレクションを整理する方法がある。ここで、本実施形態では、重複データを整理する単位は、レコード単位であるため、重複データが格納されたレコードを以下、重複レコードと表記する。重複レコードを別コレクションにまとめることにより、コレクション間で重複していたデータを共通化して取り扱うことが可能となる。また、元のコレクションからは重複レコードは削除されるため容量の削減につながる。
しかし、NoSQLDBでは、データ間の関連性を持つことができないため、重複レコードを整理した場合、アクセスの制御に問題が生じる場合がある。例えば、図16に示すように、重複レコードをcollectionA及びcollectionBから分離して、collectionABにまとめるようにコレクションを整理したとする。また、collectionA及びcollectionBから、重複レコードが分離された後は、collectionA’及びcollectionB’であるとする。この場合、ユーザ端末から、整理前のcollectionAのデータに対してアクセスしようとする場合、collectionABと、collectionA’とのそれぞれに対して複数回のリクエストをしなければならないという問題が生じる。また、この場合、ユーザ端末のリクエストを、整理後の複数のコレクションを指定するように更新する必要があるが、NoSQLDBの整理の度にユーザ端末のリクエストを更新するのは合理的ではない。
よって、NoSQLDB内のデータ間の関連性が分かっており、関連性に対応したDBの整理を行う場合には、アクセスを制御して、整理されたNoSQLDBの内容に応じて、アクセス先のコレクションを指定する機構が必要である。このような機構を導入して、整理されたNoSQLDBの内容に応じたアクセスの制御を可能にすることで、ユーザ端末からのリクエストを変えることなく、NoSQLDBの容量を削減することができる。
そこで、本発明の実施形態では、ユーザ端末からデータベースサーバへのアクセスを中継する中間サーバの機構を設け、整理されたNoSQLDBの内容に応じたアクセスの制御を行う場合について説明する。中間サーバには、定義用DBを設ける。定義用DBには、アクセスに対して、整理されたNoSQLDBの内容に対応した、整理前後のコレクションの対応関係を記述した参照定義情報が保持される。
図1に示すように、本実施形態に係るDB管理システム100は、管理者端末10と、複数のユーザ端末12と、中間サーバ20と、データベースサーバ30とを含む。管理者端末10と、複数のユーザ端末12と、中間サーバ20と、データベースサーバ30とは、インターネット等のネットワークを介して接続される。なお、ユーザ端末12の数は、図1の例に限定されない。
管理者端末10は、中間サーバ20及びデータベースサーバ30のNoSQLDB31の保守及び管理を行う管理者等が利用する情報処理端末である。NoSQLDB31の内容を更新する場合には、管理者端末10から作業を行う。管理者端末10は、例えば、パーソナルコンピュータ(PC)、ノート型PC等で実現することができる。
ユーザ端末12は、業務システム等からデータベースサーバ30に存在するデータにアクセスする情報処理端末である。ユーザ端末12は、例えば、ノート型PC、タブレット端末、スマートフォン等で実現することができる。
中間サーバ20は、定義用DB22を管理するサーバである。定義用DB22は、データベースサーバ30のNoSQLDB31のレコードが共通化されていない複数のコレクションの各々へのアクセス要求に対する、共通化された複数のコレクションの各々への参照関係を定義した参照定義情報を保持している。定義用DB22の更新は、データベースサーバ30のNoSQLDB31が更新された場合に、更新部24の処理を実行することにより行われる。また、中間サーバ20は、ユーザ端末12からデータベースサーバ30へのアクセスの制御を行うサーバである。ユーザ端末12からのアクセス要求があった場合に、リクエストに対応した定義用DB22の参照定義情報を参照し、参照定義情報に指定されたコレクションへアクセスする制御を行う。
データベースサーバ30は、NoSQLDB31を有するサーバである。NoSQLDB31は、開示の技術のスキーマを使用しないデータベースの一例である。
ここで、図2及び図3に、中間サーバ20の定義用DB22で保持される参照定義情報により定義される、アクセス要求の対象となるコレクションと、データベースサーバ30のNoSQLDB31の参照先となるコレクションとの対応関係の例を示す。図2に、重複レコードが共通化されていない想定の、アクセス要求の対象となるコレクションと、参照先のコレクションとの対応関係の例を示す。図3に、重複レコードを共通化した後の、アクセス要求の対象となるコレクションと、参照先のコレクションとの対応関係の例を示す。図2及び図3に示すように、定義用DB22には、参照定義情報として、アクセス要求の対象となるcollectionAに対応するdefinitionA、及びアクセス要求の対象となるcollectionBに対応するdefinitionBがあるとする。definitionA及びdefinitionBには、それぞれ参照先としてコレクション群が定義されている。図2に示すように、重複レコードが共通化されていない状態では、NoSQLDB31のアクセス要求の対象となるcollectionAに対応するdefinitionAのコレクション群には、collectionAが指定されている。また、アクセス要求の対象となるcollectionBに対応するdefinitionBのコレクション群には、collectionBが指定されている。ここで、collectionA、及びcollectionBの各々に含まれる1つのレコードが重複していたとすると、この重複したレコードを共通化対象の共通化レコードとする。本実施形態では、共通化レコードを元のcollectionA及びcollectionBから分離して、別のcollectionABとして共通化すると共に、共通化レコードを有していたcollectionA、及びcollectionBに対応する定義用DB22のdefinitionA、及びdefinitionBを更新する。重複レコードを共通化して更新した後の状態では、図3に示すように、アクセス要求の対象となるcollectionAに対応するdefinitionAのコレクション群には、collectionAB、及びcollectionA’(以下、説明の便宜のため、共通化レコードが分離された更新後のコレクション名に’を付す)が指定されている。また、アクセス要求の対象となるcollectionBに対応するdefinitionBのコレクション群には、collectionAB、及びcollectionB’が指定されている。
中間サーバ20は、図4に示すように、機能的には、定義用DB22と、受信部23と、更新部24と、制御部25と、送信部26とを含む。
受信部23は、例えば、管理者端末10から送信されたNoSQLDBの共通化情報(詳細は後述)を受信する。また、受信部23は、例えば、ユーザ端末12からのアクセス要求を受信する。
更新部24は、共通化情報に基づいて、定義用DB22を更新する。また、更新部24は、受信部23により共通化情報が受け付けられたときに、更新中のフラグをオンにすると共に、定義用DB22に含まれる参照定義情報の更新を開始する。これらの更新部24の処理は、例えば、参照定義情報更新API(Application Programming Interface)として実現可能である。ここで、具体的な定義用DB22の更新内容について、NoSQLDB31の更新内容と共に説明する。
例えば、重複レコードが共通化されていない状態で、図5に示すように、NoSQLDB31にcollectionA、及びcollectionBが格納されていたとする。collectionAの1行目のレコードには、keyと値のペア(以下、「"key":"値"」と表記する)をデータとして、「"name":"FujitsuTaro","age":23,"employeeNumber":00123456」が格納されている。2行目のレコードには、「"name":"FujitsuTaro","hobby":"trip"」が格納されている。また、collectionBの1行目のレコードには、「"name":"FujitsuTaro","age":23,"employeeNumber":00123456」が格納されている。collectionBの2行目のレコードには、「"ID":"UserXX","score":1234,"rank":3456,"date":20160926」が格納されている。
ここで、collectionA、及びcollectionBの1行目のレコードは、全てのデータにおいて、keyと値のペアが同一であるため、共通化対象のレコードである共通化レコードといえる。そこで、管理者は、管理者端末10を操作して、共通化レコードを有するcollectionABと、collectionA及びcollectionBの各々から共通化レコードを分離(削除)したcollectionA’、及びcollectionB’とを保持するようにNoSQLDB31のコレクション群を整理する。整理後は、図6に示すように、collectionA’の1行目のレコードには、「"name":"FujitsuTaro","hobby":"trip"」が格納されている。collectionB’の1行目のレコードには、「"ID":"UserXX","score":1234,"rank":3456,"date":20160926」が格納されている。collectionABの1行目のレコードには「"name":"FujitsuTaro","hobby":"trip"」が格納されている。
上記のようにNoSQLDB31が整理された後、管理者は、管理者端末10を操作して、中間サーバ20へ共通化情報を送信すると共に、定義用DB22に含まれる参照定義情報を更新する。管理者端末10から送信される共通化情報は、具体的には、図7に示すように、コレクションに対する参照定義情報(definition)のパスとボディによって記述される。パスは、定義用DB22の参照定義情報のうち、共通化されていないコレクションであって、アクセス要求の対象となるコレクションに対応する参照定義情報への参照パスである。ボディは、共通化されたNoSQLDB31の参照先となるコレクション群を記述したものである。図7は、definitionAの参照パス及びボディを記述したものの一例である。ボディには、共通化されたNoSQLDB31の参照先となるコレクション群(collections)として、collectionAB、及びcollectionA’が記述されている。また、共通化情報として、definitionBについても同様にパス及びボディを記述したものを受け付ける。これにより、更新の対象となる定義用DB22の参照定義情報であるdefinitionA、及びdefinitionBを更新する。
上記の例では、2つのコレクションについて共通化レコードを共通化して、コレクション群を整理する場合について説明したが、3つ以上のコレクションについて共通化レコードを共通化して、コレクション群を整理する場合の例についても説明する。
図8に示すように、NoSQLDB31にcollectionA、collectionB、collectionC、及びcollectionDが格納されていたとする。collectionA、及びcollectionBの内容については、上記図5の説明と同様である。collectionCの1行目のレコードには、keyと値のペアをデータとして、「"name":"FujitsuTaro","age":23,"employeeNumber":00123456」が格納されている。2行目のレコードには、「"ID":"UserXX","score":1234,"rank":3456,"date":20160926」が格納されている。3行目のレコードには、「"name":"YamadaHanako","age":35」が格納されている。collectionDの1行目のレコードには、「"name":"TanakaJiro","age":31,"employeeNumber":00222456」が格納されている。2行目のレコードには、「"name":"TanakaJiro","hobby":"trip"」が格納されている。
ここで、collectionA、collectionB、及びcollectionCの1行目のレコードは、全てのデータにおいて、keyと値のペアが同一であるため、共通化対象のレコードである共通化レコードといえる。また、collectionB、及びcollectionCの2行目のレコードも共通化レコードである。そこで、管理者は、管理者端末10を操作してコレクション群を整理する。例えば、共通化レコードを有するcollectionABC、及びcollectionBCと、共通化レコードが分離されたcollectionA’、及びcollectionC’と、変更のないcollectionDとを保持するようにNoSQLDB31のコレクション群に整理する。整理後は、図9に示すように、collectionABCの1行目のレコードには「"name":"FujitsuTaro","hobby":"trip"」が格納されている。collectionA’の1行目のレコードには、「"name":"FujitsuTaro","hobby":"trip"」が格納されている。collectionBCの1行目のレコードには、「"ID":"UserXX","score":1234,"rank":3456,"date":20160926」が格納されている。collectionC’の1行目のレコードには、「"name":"YamadaHanako","age":35」が格納されている。
この場合、共通化情報は、definitionA、definitionB、及びdefinitionCのそれぞれについてのパス及びボディを受け付ける。definitionAの共通化情報のボディには、共通化されたNoSQLDB31の参照先となる、collectionABC、及びcollectionA’が記述される。また、definitionBの共通化情報のボディには、共通化されたNoSQLDB31の参照先となる、collectionABC、及びcollectionBCが記述される。また、definitionCの共通化情報のボディには、共通化されたNoSQLDB31の参照先となる、collectionABC、collectionBC、及びcollectionC’が記述される。
制御部25は、ユーザ端末12からのアクセス要求に対する、データベースサーバ30への参照やユーザ端末12へのレスポンスを制御する。また、制御部25は、更新中のフラグを参照して、更新部24で定義用DB22を更新している場合、ユーザ端末12からのアクセス要求を待機させるように制御する。制御部25の具体的な処理内容は後述する作用において詳細に説明する。
送信部26は、更新部24の更新処理が終了した場合に、終了したことを管理者端末10に通知する。また、制御部25でNoSQLDB31から取得したリクエスト結果をユーザ端末12に返却する。
中間サーバ20は、例えば図10に示すコンピュータ40で実現することができる。コンピュータ40は、Central Processing Unit(CPU)41と、一時記憶領域としてのメモリ42と、不揮発性の記憶部43とを備える。また、コンピュータ40は、入出力装置44と、記憶媒体49に対するデータの読み込み及び書き込みを制御するRead/Write(R/W)部45と、インターネット等のネットワークに接続される通信インターフェース(I/F)46とを備える。CPU41、メモリ42、記憶部43、入出力装置44、R/W部45、及び通信I/F46は、バス47を介して互いに接続される。
記憶部43は、Hard Disk Drive(HDD)、Solid State Drive(SSD)、フラッシュメモリ等によって実現できる。記憶媒体としての記憶部43には、コンピュータ40を中間サーバ20として機能させるための更新処理プログラム50及び制御プログラム60が記憶される。更新処理プログラム50は、受信プロセス52と、送信プロセス54と、更新プロセス56とを有する。制御プログラム60は、受信プロセス62と、送信プロセス64と、要求プロセス66とを有する。また、記憶部43は、定義用DB22を構成する情報が記憶される情報記憶領域70を有する。
CPU41は、更新処理プログラム50を記憶部43から読み出してメモリ42に展開し、更新処理プログラム50が有するプロセスを順次実行する。CPU41は、受信プロセス52を実行することで、図4に示す受信部23として動作する。また、CPU41は、送信プロセス54を実行することで、図4に示す送信部26として動作する。また、CPU41は、更新プロセス56を実行することで、図4に示す更新部24として動作する。また、CPU41は、情報記憶領域70から情報を読み出して、定義用DB22をメモリ42に展開する。これにより、更新処理プログラム50を実行したコンピュータ40が、更新処理を行う中間サーバ20として機能することになる。
また、CPU41は、制御プログラム60を記憶部43から読み出してメモリ42に展開し、制御プログラム60が有するプロセスを順次実行する。CPU41は、受信プロセス62を実行することで、図4に示す受信部23として動作する。また、CPU41は、送信プロセス64を実行することで、図4に示す送信部26として動作する。また、CPU41は、情報記憶領域70から情報を読み出して、定義用DB22をメモリ42に展開する。また、データベースサーバ30から受信したデータをメモリ42に展開する。これにより、制御プログラム60を実行したコンピュータ40が、アクセス要求の制御を行う中間サーバ20として機能することになる。
なお、更新処理プログラム50及び制御プログラム60により実現される機能は、例えば半導体集積回路、より詳しくはApplication Specific Integrated Circuit(ASIC)等で実現することも可能である。
次に、本実施形態に係るDB管理システム100の作用について説明する。まず、図11のシーケンス図を参照して、各装置間での情報のやり取りについて説明する。
まず、管理者は管理者端末10を操作して、データベースサーバ30のNoSQLDB31に対し、共通化レコードを有するコレクションの共通化(整理)を実行する(S11)。データベースサーバ30は、コレクションの共通化が完了すると、管理者端末10に完了したことを通知する(S12)。なお、共通化を実行してから完了の通知を受け取るまでの間、管理者はデータベースサーバ30の稼動を停止させ、ユーザ端末12からのアクセス要求を受け付けないようにしてもよい。
管理者端末10がデータベースサーバ30から共通化が完了した通知を受け取ると、管理者は管理者端末10を操作して、共通化情報を中間サーバ20に送信する(S13)。
中間サーバ20は、共通化情報を受信すると、更新中のフラグをオンにすると共に、定義用DB22に含まれる更新定義情報の更新を開始する(S14)。
中間サーバ20は、共通化情報に基づいて、定義用DB22の参照定義情報のうち、コレクションの共通化によって変更があったコレクションに対応する参照定義情報の更新を定義数分だけ繰り返し実行する(S15)。また、中間サーバ20は、参照定義情報を更新する毎に、更新が成功した場合には、管理者端末10に更新の成功を示す実行結果を送信する(S16)。なお、更新がエラーだった場合には、中間サーバ20は、管理者端末10に更新がエラーになったことを示す実行結果を送信し、更新を繰り返すことなく、後述する更新中のフラグをオフにする処理に移行する。管理者は、管理者端末10で、更新がエラーになったことを示す実行結果を受信した場合、速やかにデータベースのロールバックを行うか、共通化情報を見直して改めて更新を実行する等の対応を行う必要がある。
一方、参照定義情報の更新中のフラグがオンのときに、ユーザ端末12が操作され、ユーザ端末12から中間サーバ20へ、例えばコレクションAに対するアクセス要求が送信されたとする(S17)。このとき中間サーバ20は、更新中のフラグがオンになっているため、ユーザ端末12に対して待機の通知を送信する(S18)。
中間サーバ20は、全ての参照定義情報の更新が完了すると、更新中のフラグをオフにし(S19)、管理者端末10に更新が終了したことを通知する(S20)。なお、中間サーバ20は、例えば参照定義情報ごとに更新中のフラグを設け、参照定義情報を更新するごとに当該参照定義情報の更新中のフラグをオフにするようにしてもよい。
次に、中間サーバ20は、定義用DB22から、アクセス要求があったコレクションAに対応する参照定義情報であるdefinitionAを取得し(S21)、definitionAからコレクション群を抽出する(S22)。
中間サーバ20は、抽出されたコレクション群からコレクションを指定して、データベースサーバ30に対してデータ取得のリクエストを行う(S23)。データベースサーバ30は中間サーバ20からリクエストを受け取ると、指定されたコレクションに対応するNoSQLDB31のコレクションを参照し、当該コレクションのデータを中間サーバ20に返却する(S24)。中間サーバ20は、データベースサーバ30から返却された結果をメモリ42に格納する(S25)。中間サーバ20は、S23〜S25の処理を、抽出されたコレクション群の全てのコレクションについて繰り返し行う。
中間サーバ20は、S23〜S25でメモリに格納された全てのコレクションの結果を統合し(S26)、コレクションAのレスポンス結果としてユーザ端末12に送信する(S27)。
次に、中間サーバ20で実行される更新処理、及び制御処理について説明する。例えば、管理者端末10から送信された共通化情報を中間サーバ20が受信すると、中間サーバ20において、図12に示す更新処理が実行される。また、ユーザ端末12からアクセス要求を受け付けた際などに、中間サーバ20において、図13に示す制御処理が実行される。
まず、中間サーバ20において実行される更新処理について説明する。
図12のステップS31で、受信部23が、管理者端末10から共通化情報を受け付ける。次に、ステップS32で、更新部24が、中間サーバ20の更新中のフラグをオンにすると共に、参照定義情報の更新を開始する。
ステップS33で、更新部24が、共通化情報に記述されている、共通化によって変更されたコレクションに対応する参照定義情報を指定する。ステップS34で、共通化情報に基づいて、ステップS33で指定された参照定義情報を更新する。例えば図7に示すようにdefinitionAが指定されている場合、definitionAのコレクション群が、collectionAB及びcollectionA’となるように更新される。
ステップS35で、更新部24が、指定された参照定義情報の更新が成功したか否かを判定する。
ステップS35で、更新に成功したと判定された場合には、ステップS36で、送信部26が、更新に成功したことを更新の実行結果として管理者端末10に送信し、ステップS38へ移行する。
一方、ステップS35で、更新に成功していると判定されなかった場合には、ステップS37で、送信部26が、更新にエラーが起きて失敗であったことを更新の実行結果として管理者端末10に送信し、ステップS39へ移行する。
ステップS38で、更新部24が、共通化情報において更新対象になっている全ての参照定義情報について、更新が終了したかを判定する。更新が終了していると判定された場合には、処理は、ステップS39へ移行し、更新が終了していると判定されなかった場合には、処理は、ステップS33に戻って次の参照定義情報を指定して処理を繰り返す。
ステップS39で、更新部24が、更新中のフラグをオフにする。そして、ステップS40で、送信部26が、更新の終了を管理者端末10に通知して更新処理を終了する。
次に、中間サーバ20において実行される制御処理について説明する。
図13のステップS41で、受信部23が、ユーザ端末12からのアクセス要求を受け付けると、ステップS42で、制御部25が、中間サーバ20の更新中のフラグがオンかを判定する。更新中のフラグがオンである場合には、処理は、ステップS43へ移行し、更新中のフラグがオンでない場合には、処理は、ステップS45へ移行する。
ステップS43で、送信部26が、ユーザ端末12に待機の通知を送信する。
ステップS44で、制御部25が、中間サーバ20の更新中のフラグがオフかを判定する。更新中のフラグがオフである場合には、処理は、ステップS45へ移行し、更新中のフラグがオフでない場合には、処理は、ステップS43へ移行し、ユーザ端末12に待機の通知を送信することを繰り返す。
次にステップS45で、制御部25が、ユーザ端末12からのアクセス要求のリクエストパスから参照定義情報を取得する。リクエストパスが、例えば図14(A)に示すようなGET文のパスであったとすると、制御部25は、定義用DB22から、参照定義情報であるdefinitionAを取得する。また、図14(A)のリクエストパスでは、コレクションのレコードの中から、whereによる絞り込みで「"name":"FujitsuTaro"」に該当するkeyと値のペアとなるデータを持つレコードを取得するということを表している。
ステップS46で、制御部25が、ステップS45で取得した参照定義情報からコレクション群を抽出する。例えば図3に示すdefinitionAが取得されている場合、コレクション群として、collectionAB及びcollectionA’が抽出される。
ステップS47で、制御部25が、ステップS46で抽出したコレクション群からコレクションを指定し、リクエストパスを生成する。リクエストパスは、例えば図14(B)に示すように、指定されたコレクションごとに生成したGET文とすることができる。図14(B)は、NoSQLDB31のコレクションであるcollectionAB、及びcollectionA’についてのリクエストパスの一例である。なお、「filter_name=***」によるレコードの絞り込みはDBMS(Database Management System)がmongoDBである場合の記述の一例である。
ステップS48で、制御部25が、指定したコレクションについて、データベースサーバ30にリクエストを行い、リクエストパスに記述されたNoSQLDB31のコレクションから結果を取得する。図14(C)は、collectionAB、及びcollectionA’についての取得結果の一例である。
ステップS49で、制御部25が、指定したコレクションの取得に成功したか否かを判定する。
ステップS49で、取得に成功していると判定された場合には、ステップS50で、制御部25が、指定したコレクションについての取得結果をメモリ42に格納して、ステップS52へ移行する。
一方、ステップS49で、取得に成功していないと判定された場合には、ステップS51で、送信部26が、リクエスト結果がエラーであったことをユーザ端末12に送信し、制御処理を終了する。
ステップS52で、制御部25が、取得対象の全てのコレクションについて取得処理が終了したか否かを判定する。全てのコレクションについて取得処理が終了していると判定された場合には、処理は、ステップS53へ移行する。また、全てのコレクションについて取得処理が終了していると判定されなかった場合には、ステップS47へ戻って次のコレクションを指定して取得処理を繰り返す。
ステップS53で、制御部25が、ステップS50でメモリ42に格納された、definitionAに対応する全てのコレクションについての取得結果をリクエスト結果として統合する。図15にリクエスト結果の一例を示す。図15の例では、リクエスト結果として"results"のデータにcollectionAB、及びcollectionA’の内容が統合されている。
ステップS54で、送信部26が、ステップS53で統合されたリクエスト結果をユーザ端末12に送信して、制御処理を終了する。
以上説明したように、本実施形態に係るDB管理システムによれば、スキーマを使用しないデータベースにおいて、整理されたコレクションに応じた定義用DBの更新、及び更新した定義用DBに応じたデータベースへのアクセスの制御を行うことを可能にする。このため、リクエスト回数を増加させることなく、データベースの容量を削減することができる。
また、定義用DBの更新中は、ユーザ端末からのアクセスを待機させることで、ユーザ端末に対し、定義用DBが更新される前の不整合なレスポンス結果を送信してしまうことを防止することができる。
また、上述した実施形態では、中間サーバを設ける場合について説明したが、これに限定されるものではなく、中間サーバの機能(受信部、更新部、制御部、及び送信部)をデータベースサーバに設けるようにしてもよい。
また、上述した実施形態では、NoSQLDBのコレクションを整理し、アクセスを制御する機構を設ける場合について説明したが、これに限定されるものではない。例えば、他のスキーマを使用しないデータベースに対応する参照単位を整理し、アクセスを制御する機構を設けるようにしてもよい。
以上の実施形態に関し、更に以下の付記を開示する。
(付記1)
スキーマを使用しないデータベースにおける、データの各々が格納されたレコードを有する複数の参照単位であって、二つ以上の前記参照単位において共通化対象の前記レコードである共通化レコードを有する前記参照単位と、前記共通化レコードが分離された前記二つ以上の前記参照単位とを含む、共通化された前記複数の参照単位に関する共通化情報を受け付け、
前記受け付けた共通化情報に基づいて、前記データベースにおける共通化されていない複数の参照単位の各々へのアクセス要求に対する前記共通化された前記複数の参照単位の各々への参照関係を定義した参照定義情報を更新する
ことを含む処理をコンピュータに実行させることを特徴とする更新処理プログラム。
(付記2)
前記共通化情報を受け付けてから、前記参照定義情報の更新が行われるまでの間において、前記データベースへのアクセス要求があった場合に、前記アクセス要求に対する応答を予め定められた条件を満たすまで待機させる
ことを含む処理を実行させることを特徴とする付記1に記載の更新処理プログラム。
(付記3)
前記参照定義情報を更新する際に、前記受け付けた共通化情報に基づいて、
前記アクセス要求に対する共通化された前記参照単位が変更となる、共通化されていない参照単位について、前記参照定義情報を更新することを特徴とする付記1又は付記2に記載の更新処理プログラム。
(付記4)
スキーマを使用しないデータベースにおける、データの各々が格納されたレコードを有する複数の参照単位であって、二つ以上の前記参照単位において共通化対象の前記レコードである共通化レコードを有する前記参照単位と、前記共通化レコードが分離された前記二つ以上の前記参照単位とを含む、共通化された前記複数の参照単位に関する共通化情報を受け付ける受信部と、
前記受け付けた共通化情報に基づいて、前記データベースにおける共通化されていない複数の参照単位の各々へのアクセス要求に対する前記共通化された前記複数の参照単位の各々への参照関係を定義した参照定義情報を更新する更新部と、
を含む更新処理装置。
(付記5)
前記更新部は、前記共通化情報を受け付けてから、前記参照定義情報の更新が行われるまでの間において、前記データベースへのアクセス要求があった場合に、前記アクセス要求に対する応答を予め定められた条件を満たすまで待機させる付記4に記載の更新処理装置。
(付記6)
前記更新部は、前記参照定義情報を更新する際に、前記受け付けた共通化情報に基づいて、前記アクセス要求に対する共通化された前記参照単位が変更となる、共通化されていない参照単位について、前記参照定義情報を更新する付記4又は付記5に記載の更新処理装置。
(付記7)
スキーマを使用しないデータベースにおける、データの各々が格納されたレコードを有する複数の参照単位であって、二つ以上の前記参照単位において共通化対象の前記レコードである共通化レコードを有する前記参照単位と、前記共通化レコードが分離された前記二つ以上の前記参照単位とを含む、共通化された前記複数の参照単位に関する共通化情報を受け付け、
前記受け付けた共通化情報に基づいて、前記データベース31における共通化されていない複数の参照単位の各々へのアクセス要求に対する前記共通化された前記複数の参照単位の各々への参照関係を定義した参照定義情報を更新する
ことを含む処理をコンピュータが実行することを特徴とする更新処理方法。
(付記8)
前記共通化情報を受け付けてから、前記参照定義情報の更新が行われるまでの間において、前記データベースへのアクセス要求があった場合に、前記アクセス要求に対する応答を予め定められた条件を満たすまで待機させることを特徴とする付記7に記載の更新処理方法。
(付記9)
前記参照定義情報を更新する際に、前記受け付けた共通化情報に基づいて、
前記アクセス要求に対する共通化された前記参照単位が変更となる、共通化されていない参照単位について、前記参照定義情報を更新することを特徴とする付記7又は付記8に記載の更新処理方法。