JP2010538354A - データベースシステムにおける方法および装置 - Google Patents

Abstract

データベースにおける修正とデータクエリの処理とを円滑化するための方法および通信データベースシステム。データベース（３００）は、多様なオブジェクトについてのオリジナルデータを有するデータエントリを持つオリジナルデータセット（３００ａ）と、少なくとも一部のオブジェクトについての更新データを有するデータエントリを持つ少なくとも１つの補助的データセット（３００ｂ，ｃ）とを備える。どちらのデータセットの中のデータエントリにも、各エントリがどちらのデータセットに属するかを示すデータセットタグ（０，１，２）が含まれる。クエリ実行論理（Ａ，Ｂ）が，要求されたデータエントリの中のデータを求めるクエリを行うと、要求されたデータエントリのデータが、データエントリの中のデータセットタグに基づいて判定されたデータセットから取得される。

Description

本発明は一般に、通信データベースシステムにおいて、データクエリの管理およびデータ修正操作の柔軟性を増加させて円滑化するであろう方法および装置に関する。

通信システムでは、通信端末の加入者またはユーザについての多様なデータエントリのかたちで各種のデータを記憶するために大規模データベースが用いられており、権限のある要求側当事者、例えば他の端末ユーザやアプリケーションやサービスや各種のネットワークノードは、それらを検索することができる。本記述において、「要求側当事者」という用語は一般に、データベースからデータを検索するいずれかのエンティティを表すために用いられる。

記憶されるデータは、例えば、電話番号、加入設定、端末仕様、ユーザ選好等の翻訳またはマッピングに関連してもよい。一定のタイプのデータについてのデータベースの中のエントリは、すべてのユーザについてそのようなデータを含んでおり、その場合、各データエントリは、典型的には特定のユーザに関連付けられる。また、データは、個々のユーザ以外のエンティティ、例えば一般に「オブジェクト」と呼ばれるユーザグループ、サービス、ネットワークノード、装置要素等についても、このようなやり方で記憶されてよい。

そのようなデータベースにおいて、対応するオブジェクトの多数のデータエントリについて大規模な修正を行うことは、例えば、性能、柔軟性、整合性、展開に要する時間、作業負荷に関連する、さまざまな問題に結び付く可能性がある。

例えば、データベース内の多数のオブジェクトについて一定のタイプのデータを更新して他のタイプのデータと置換する場合、例えば、加入者についての回線交換型電話番号とパケット交換型アドレスとのマッピングの場合、データエントリは、１つずつ変更されなければならず、従って変更はデータベース全体を通して限られた速度で進行するであろう。データベースがアクティブであってデータクエリが利用可能な時間帯にこれらの変更が行われる場合、一部のデータエントリは更新されるが他は更新されず、結果として不整合やデータ検索エラーの恐れが生じるであろう。非常に大規模なデータベースについては、このプロセスが完了するまでに時間がかかる可能性がある。

構成エラー等の場合には、さらに、実行済みの更新を「ロールバック」する必要が生じる可能性があり、それは、個別のデータエントリを１つずつ元に戻すのに要する時間によって制限される。場合によっては、エラーおよび不整合を避けるために、すべてのエントリが適切に更新されるまで、データベースを要求から閉鎖しておくことすら必要になる可能性がある。また、新規のデータエントリは、オリジナルデータベースが閉鎖されている間に追加されるため、完全に新しいデータベースから利用可能にされることもありうるであろうから、すなわち、更新されないエントリからはデータが利用できないことになるであろう。

データタイプを変更する場合のもう１つの自明の選択肢は、すべての加入者についてデータエントリを追加することによって新たな別個のデータベースを構築する間、可能ならばオリジナルデータベースをそのまま実行させ続け、次いで、完了した時に、瞬時にオリジナルデータベースから新規データベースへと切り替えることである。後者の場合、オリジナルデータベースは、不整合とエラーとを避けるため、新規の更新済みのデータベースと一度の操作で置換してもよいが、そうすると、もちろん、新たなタイプのデータをシステム内に展開することが、すべての加入者について新規データベースが完成するまで、遅れるであろう。

さらに、この既知の解決策では、新規データベースをアクティブにすることができて旧データベースが閉鎖されるまでは２つのデータベースを維持しなければならず、それは、いかなるプロビジョニング操作も、それらの同期を維持するため、両方のデータベースの中で行われなければならないことを意味する。新規データベース内では、古いエントリが変更されるか否かに関らず、すべてのエントリが作成されなければならない。従って、普通なら大規模なデータベースの中でエントリの一部分だけが更新されることになる場合、他の諸エントリについても同じデータを旧データベースから新規データベースにコピーする作業負荷を考えると、この選択肢は適切ではない。

従って、新規データがいつどのようにして利用可能になるかに関して、上記の選択肢のいずれを選択しても、柔軟性の余地はない。また、あるタイプのデータを一定の要求側当事者に提示し、別のタイプのデータをそれ以外の当事者に提示することも望ましいであろうが、それを既知のデータベースシステムで行うことは、不可能ではないにしても、かなり複雑である。

図１は、オリジナルデータエントリ１０２Ａを持つデータベース１００Ａが、修正されたデータエントリ１０２Ｂを持つ新たな別個のデータベース１００Ｂによってどのように置換されるかを図解する。オリジナルデータベース１００Ａでは、データエントリ＃１、２、３、・・・が、例えば通信システム内のユーザのような個別のオブジェクトについて、それぞれデータＸ_１、Ｘ_２、Ｘ_３、・・・を保持する。例えば、各データエントリの見出しは、例えば従来のＰＳＴＮ（公衆交換電話網）電話番号のような加入者ＩＤであってもよく、そして、エントリの中に保持されるデータＸは、その加入について有効な対応するＳＩＰ（セッション開始プロトコル）アドレス、すなわち番号マッピングであってもよい。その後、加入者ＩＤを、データクエリを行う場合のデータエントリへのキーとして用いることができる。

図は、修正されるか否かを問わず、各オブジェクトについてデータエントリを追加することによって、新規データベース１００Ｂが作成されることを図解するが、この場合、エントリ＃１の中のデータＸ_１は、データＹ_１によって置換され、エントリ＃２の中のデータＸ_２は、データＹ_２によって置換され、以下同様である。このようにして、新規の修正されたデータベース１００Ｂが徐々に構築され、そしてすべてのデータエントリが記憶されると、データクエリに対してデータベース１００Ａの代わりにデータベース１００Ｂをアクティブにすることができる。あるいは、新規データベースを構築している間は、オリジナルデータベース１００Ａが閉鎖され続けてもよく、データベース１００Ｂを完成するのにかかる時間の間は、新規データベース１００Ｂに現時点で追加されたエントリだけが利用可能である。上記のように、更新／修正されないことになるエントリについても、同じデータがやはり新規データベース１００Ｂにコピーされなければならない。

図２は、データベースシステム２００がどのように操作されうるかを一般に図解する。データベース２０２は、例えば通信ユーザのような、多様なオブジェクトについての複数のデータエントリを含む。データベースのオペレータは、オペレータのコマンドと記憶されることになる各種のデータとを入力するための適切なインタフェースを有するプロビジョニング論理ユニット２０４によって、データベース２０２の内容を制御することができる。従って、オペレータは、一般に「アップデート（更新）」と呼ばれる、エントリを追加、削除、または変更することによって、データベース２０２の内容を更新するための情報を入力してもよい。またオペレータは、図示しない、まったく新しい別個のデータベースを作成して、上述した既存のものと置換してもよい。

さらにデータベースシステム２００は、第１のクエリ実行論理ユニットＡと第２のクエリ実行論理ユニットＢとを有するが、いずれも、データを取得して適切な応答を要求側当事者へ配信することを目的として、図示するように、要求側当事者からのデータ要求を処理して、対応するデータクエリをデータベース２０２に対して行うように構成される。

上記のように、データベース更新を行うためのこれらの解決策は、使いづらい可能性があり、そして、例えば、不要な遅延や、限られた柔軟性や、不整合および／または利用可能性低下等に結び付く可能性がある。従って、利用可能性を低下させたりエラーを招いたりせずに、大規模データベースの中の個別のデータエントリの瞬時の修正を行うことは不可能である。今日のデータベースシステムは、例えば、同じオブジェクトのデータの多様な表示（ビュー）またはバージョンを提示することを目的とした、多様なビュワのための多様なデータタイプへの利用可能性またはアクセスを制御するための単純で柔軟性のあるメカニズムを有していない。さらに、例えば構成エラーの場合に、実行済みの更新を「ロールバック」するためのオプションが、１つずつ個別のデータエントリを元に戻すのにかかる時間によって、限定されている。

本発明の目的は、上で概説した諸問題の少なくとも一部に取り組むことである。従って、特に上記の背景のセクションで述べた更新操作に関する大規模データベースの処理に関連する欠点を回避するか少なくとも減少させることが、概して望ましい。これらの目的およびその他の目的は、主として添付の独立請求項による方法および装置を提供することによって達成されてもよい。

一態様によって、複数のオブジェクトについてのデータエントリを有するデータベースからデータを取得するための、通信データベースシステムにおける方法が、提供される。データベースは、オブジェクトについてのオリジナルデータを保持するデータエントリを持つオリジナルデータセットと、少なくとも一部のオブジェクトについての更新データを保持するデータエントリを持つ補助的データセットとを備える。オリジナルデータセットの中のデータエントリは、第１のデータセットタグを有し、補助的データセットの中のデータエントリは、第２のデータセットタグを有しており、それらのデータセットタグは、各エントリがどちらのデータセットに属するかを示す。方法では、要求されたデータエントリからのデータを求めるクエリが行われ、要求されたデータエントリのデータが、データエントリの中のデータセットタグに基づいて判定されたデータセットから取得される。

要求されるデータセットタグがクエリの中で指定されると、指定されたデータセットタグに従ってデータセットのデータエントリからデータが取得される。オリジナルデータセットの中のデータエントリは、さらに、オリジナルデータセットと補助的データセットとのうちの１つを示すデータセットフラグを有してもよい。クエリの中でデータセットタグが指定されていないときには、データおよびデータセットフラグが、オリジナルデータセットの中の要求されたデータエントリから取得され、そして、正しいデータセットが、返信されたデータセットフラグに基づいて判定されてもよい。取得されたデータセットフラグが、オリジナルデータセットタグと等しい場合、オリジナルデータセットから取得されたデータが用いられる。

取得されたデータセットフラグがオリジナルデータセットタグと異なる場合、取得されたデータセットフラグが、要求側当事者についてアクティブに設定されているデータセットタグと等しいかどうかチェックされ、そして、等しくない場合、オリジナルデータセットから取得されたデータがデフォルトとして用いられる。取得されたデータセットフラグが、アクティブなデータセットタグと等しい場合、アクティブなデータセットタグを示す別のクエリが行われ、そして、示されたデータセットタグによるデータセットのデータエントリからデータが取得される。

どのデータセットが特定の要求側当事者にとってアクティブであって有効であるかについての情報が維持され、それによって、各要求側当事者に対してデータベースの多様な表示（ビュー）を提示してもよい。また、特定の要求側当事者について提示された多様な表示は、各要求側当事者についてのアクティブなデータセットを変更することによって変更することもできる。しかも、個別のデータエントリは、それらのデータセットタグを変更することによって、異なるデータセット間を容易に移動されうる。

別の態様によって、複数のオブジェクトについてのデータエントリを有するデータベースと、データベースからデータを取得するためのクエリ実行論理ユニットとを備えた、通信データベースシステムが提供される。データベースは、オブジェクトについてのオリジナルデータを保持するデータエントリを持つオリジナルデータセットと、少なくとも一部のオブジェクトについての更新データを保持するデータエントリを持つ補助的データセットとを備える。オリジナルデータセット内のデータエントリは、第１のデータセットタグを有し、そして、補助的データセット内のデータエントリは、第２のデータセットタグを有し、それらのデータセットタグは、各エントリがどちらのデータセットに属するかを示す。クエリ実行論理ユニットは、要求されたデータエントリからのデータを求めるクエリを行って、データエントリの中のデータセットタグに基づいて判定されたデータセットから要求されたデータエントリのデータを取得するように構成される。

別の態様によって、通信システムにおける複数のオブジェクトについてのデータエントリを有するデータベースが提供される。データベースは、オブジェクトについてのオリジナルデータを保持するデータエントリを持つオリジナルデータセットと、少なくとも一部のオブジェクトについての更新データを保持するデータエントリを持つ補助的データセットとを備える。オリジナルデータセットおよび補助的データセットの中のデータエントリは、各エントリがどちらのデータセットに属するかを示すデータセットタグを有する。それによって、クエリ実行論理ユニットが、要求されたのデータエントリからのデータを求めるクエリを行って、データエントリの中のデータセットタグに基づいて判定されたデータセットから要求されたのデータエントリのデータを取得することが可能になる。

本発明のさらなる好適な特徴と利点とが、下記の詳細記述から明らかになるであろう。

ここで本発明について、好適実施形態を使って、そして、添付図面を参照しながら、より詳細に記述しよう。

先行技術に従ってデータベースがどのように修正されうるかを図解する概略ブロック図である。 先行技術に従う、データベースシステムの管理を図解する概略ブロック図である。 一実施形態に従う通信データベースシステムを図解する概略ブロック図である。 別の実施形態に従う通信データベースシステムを図解する概略ブロック図である。 更に別の実施形態に従う通信データベースシステムのユーザ事例を図解する概略ブロック図である。 更に別の実施形態に従う、通信データベースシステム内のデータベースからデータを取得するための手順におけるステップを示すフローチャートである。

簡単に言うと、本発明は、通信システムにおいて、多様なオブジェクト、例えばユーザについての複数のエントリを持つデータベースを備えた通信データベースシステムにおいて、データクエリの管理とデータ修正操作をより容易に、より柔軟に行うための解決策を提供する。データベースは、オブジェクトについてのオリジナルデータを保持するデータエントリを持つオリジナルデータセットと、少なくとも一部のオブジェクトについての更新データを保持するデータエントリを持つ１つ以上の補助的データセットとを備える。補助的データセットはそれぞれ、「補足的な」または「二次的な」と表されることもあるだろうが、オリジナルデータセットが依然として維持されている間、「影の」データセットとして動作する。

いずれのデータセットの中のデータエントリもそれぞれ、そのエントリがどちらのデータセットに属するかを示すデータセットタグを有し、例えば、オリジナルデータセットの中のすべてのエントリは、データセットタグ０を有してもよく、第１の補助的データセットの中のすべてのエントリは、データセットタグ１を有してもよく、以下同様である。それによって、データベースシステムの中のクエリ実行論理ユニットは、データエントリについてクエリを行って、どのデータセットから所望のタイプのデータエントリを検索すべきかを示してもよい。次いで、そのデータセットからのデータは、例えば要求側当事者へ配信する目的で、クエリ実行論理ユニットへ返信されるであろう。

このようにして、クエリ実行論理は、容易に更新データの展開を制御し、および／または、クエリの中に多様なデータセットタグを示すことによって、データベースの多様な表示（ビュー）を提示することができる。例えば、各新規データエントリは、並行してオリジナルデータセットを依然として維持しながら、補助的データセットに入力された直後に展開されうる。加えて、データベースにすべての新規データが入力されるまで展開を遅らせ、次いで、新規データセットタグをクエリの中に単純に設定することによって、すべてのエントリに対して新規データを同時にアクティブにすることも可能である。多様なデータセットのエントリの中のデータセットタグをこのように用いると、同じデータベースが、両方のオプションを提供することができ、特に、同じオブジェクトについてのデータの多様な表示を提示することができる。

図３は、一実施形態による通信データベース３００の構造を図解する。データベース３００は、例えば通信システム内のユーザまたは加入者のような、個別のオブジェクトについてのオリジナルデータエントリを持つ、本書では「データセット０」と呼ばれるデータセット３００ａを有する。従って、データエントリ＃１、２、３、・・・はそれぞれ、データＸ_１、Ｘ_２、Ｘ_３、・・・を保持する。ここでは３つのデータエントリだけを示すが、通信データベースは典型的には、膨大な数のデータエントリを有する。

加えて、この例では、修正されたデータエントリを持つ２つの補助的データセットも、すなわち、第１の補助的修正データセット３００ｂ「データセット１」および第２の補助的修正データセット３００ｃ「データセット２」も、それぞれデータベース３００の中に構築され、その場合、オリジナルデータセットからのエントリの一部だけが、このように補助的データセットの中で更新済みである。いずれのデータセットの中のデータエントリもそれぞれ、そのエントリがどのデータセットに属するかを示す「データセットタグ」を持つ補助的なフィールドを有する。このように、データセット３００ａ、３００ｂ、３００ｃの中のすべてのエントリは、それぞれ、データセットタグ０、１、２を有する。データセットタグという用語は、代わりに「データセット指標」、「データセットラベル」または類似したもので呼ばれてもよいだろう。

図示した例では、オペレータが、第１の補助的データセット３００ｂの中のデータエントリ＃２を、データＸ_２をデータＹ_２に変更することによって更新したところである。さらに、第２の補助的データセット３００ｃでは、Ｘ_１をＺ_１に変更することによってデータエントリ＃１が更新されたところであり、そしてデータＸ_３をデータＺ_３に変更することによってデータエントリ＃３が更新されたところであり、他方、オリジナルエントリを持つデータセット３００ａは、並行して依然としてデータベース３００の中で維持されている。更新は、上記の図２について記述されたプロビジョニング論理（図示せず）を使って実行されていてもよい。

さらに、この例で留意すべきだが、エントリ＃１および＃３は、第１の補助的データセット３００ｂでは更新されておらず、そしてエントリ＃２は、第２の補助的データセット３００ｃでは更新されていない。従って、データＸ_１およびデータＸ_３はデータセット１において依然として有効でありうるだろうし、データＸ_２は、点線の矢印で示すように、対応するデータエントリについてはデータセット２において依然として有効でありうるであろう。図に示すように、それによってデータセット１は、Ｘ_１、Ｙ_２、Ｘ_３を使った表示を提供し、他方、データセット２は、Ｚ_１、Ｘ_２、Ｚ_３を使った表示を提供する。

また、補助的データベースの中でエントリのデータを別のかたちで更新することも可能であり、従って、例えばエントリ＃１については、第１の補助的データセット３００ｂが更新データＹ_１を有してもよく、そして、第２の補助的データセット３００ｃは、同時に、別のかたちで更新データＺ_１を有してもよい。それによって、データベースの異なる表示を提供する柔軟性をさらに高めることができる。

クエリ実行論理ユニットＡおよびＢはどちらも、例えば図示する要求側当事者３０２および３０４のような多様な要求側当事者からのデータ要求を処理するため、データベース３００に接続している。あるいは、この文脈で記述したように、クエリ実行論理ユニットが、検索されたデータの実際のユーザであり、それによって、要求側当事者または「クライアント」として動作することも可能である。クエリ論理実行ユニットＡおよびＢは、データベース３００の異なる表示を提示するため、別のかたちで構成されてもよいが、それについては、以下でより詳細に説明しよう。

クエリ実行論理ユニットＡおよびＢはそれぞれ、クエリを使って適切なデータセットから正確なタイプのデータを検索する機能性を有するが、それは要求側当事者に依存してもよい。図示する実施形態によると、クエリ実行論理ユニットＡおよびＢは、データクエリの中に注目オブジェクトを参照するエントリキーもしくは番号を提供するように構成され、かつ、クエリの中に対応するデータセットタグを供給することによって、どのデータセットからそのデータを所望するかを示すように構成される。データエントリを求めるクエリが、更新されていないデータセットのタグを示す場合、すなわち、そのエントリが欠けている場合、データセットタグ０を持つオリジナルエントリからのデータが、デフォルトとして自動的に与えられてもよい。

クエリ実行論理が、エントリキーだけを提供してデータセットタグを提供しない場合、要求されたエントリをオリジナルデータセットから見つけ出すために、デフォルトとしてデータセットタグ０が用いられてもよい。また、後者の場合、オリジナルのもの以外のデータセットタグをデフォルトとして用いることも可能である。データセットタグがまったく示されないクエリを処理するためのもう１つの実施形態については、図４を参照しながら後述するであろう。

図３に示すいくつかの基本ステップは、多様な例示的なデータクエリがこの例に従ってどのように実行されるかを図解する。一般に、データクエリを行うと、その結果、データベース内の適切な図示しないデータ検索機能を用いたデータベース３００からのデータと共に、応答が返される。図示した各ステップは、用いられるプロトコル次第では１つ以上の特定のメッセージの通信が含まれてもよく、当業者であれば、記述した実施形態を実装するのにそれを適用することができるであろう。要求側当事者３０２は、エントリ＃３にデータが記憶されているオブジェクト（「オブジェクト＃３」）に関する情報を望んでおり、要求側当事者３０４は、エントリ＃１にデータが記憶されている別のオブジェクト（「オブジェクト＃１」）を望んでいると想定されている。

図示する第１のステップ３：１では、クエリ実行論理Ａが、要求側当事者３０２にサービス提供するため、エントリ＃３についてのクエリを行う。クエリ実行論理Ａは、要求側当事者３０２が第２の補助的データセット３００ｃからのデータを受け取る権利があるかまたはそれによってベストなサービスが受けられることを、判定済みである。別のオプションによると、クエリ実行論理Ａは、例えば、少なくともこの特定の要求側当事者３０２にとっては一定のデータセットが現時点で「アクティブ」であると設定することによって、どのデータセットが現在利用可能であるかに関する情報を記憶するように構成されてもよい。

従って、クエリ実行論理Ａは、クエリの中にデータセットタグ２を含めることによって、データセット３００ｃからのデータが望まれていることを示す。データベース３００では、データエントリ＃３が、データセット２、３００ｃの中のデータＺ_３を使って更新済みである。従って、データＺ_３が、ステップ３：２でクエリ実行論理Ａへ返信される。

もう１つのステップ３：３では、クエリ実行論理Ｂが、要求側当事者３０４にサービス提供するため、エントリ＃１についてのクエリを行い、ここでもまた、クエリの中にデータセットタグ１を含めることによって、第１の補助的データセット１、３００ｂからのデータが望まれていることを示す。データエントリ＃１は、データセット３００ｂの中で更新されていないため、オリジナルデータセット３００ａの中のデータエントリ＃１からの点線の矢印で示すように、オリジナルデータＸ_１がそのデータセットについても依然として有効である。従って、データセット１、３００ｂは、エントリ＃１についてはデータＸ_１を使って表示を提示し、そして、データＸ_１が、結果として、次のステップ３：４においてクエリ実行論理Ｂへ返信される。

クエリ実行論理ＡおよびＢは、どのデータセットが特定の要求側当事者に対してアクティブである、すなわち有効であるかについての情報を、例えばリスト等のかたちで維持してもよい。従って、図３に示す例では、少なくとも要求側当事者３０２および３０４それぞれについては、クエリ実行論理Ａは、データセット１をアクティブにするように構成され、そして、クエリ実行論理Ｂは、データセット２をアクティブにするように構成される。このようにして、クエリ実行論理ＡおよびＢは、多様な要求側当事者に対してデータベース３００の多様な表示を容易に提示することができ、および／または、それぞれの要求側当事者についてアクティブなデータセットを単純に変更することによって、多様な表示を変更することができる。また、もちろん、クエリ実行論理は、特定のデータセットの中のデータを一般に利用可能にすることを目的として、そのデータセットをすべての要求側当事者についてアクティブにするように構成されてもよい。

修正する場合には、データは、オリジナルエントリであろうと影のエントリであろうと、直接エントリ内で修正されてもよいし、あるいは、オリジナルデータセットの中のデータエントリを依然として維持しながら補助的データセットの中に新たな影のエントリが作成されてもよい。上記で示したように、１つ以上の補助的データセットを用いて、多様な要求側当事者について複数の表示が提示されてもよく、本発明は、この点では限定されない。例えば、１人の要求側当事者が、データセット１を表示する権限を有してもよく、他方、別の要求側当事者がデータセット２を表示する権限を有してもよく、以下同様である。

補助的データセット（影）が、その後、例えばデータを影のデータエントリからオリジナルデータエントリへとコピーすることによってかまたは、オリジナルエントリを削除して、更新された影のデータエントリの中のデータセットタグを「データセットタグ０（オリジナル）」として更新することによって、オリジナルデータセットへ統合されてもよい。これらのデータエントリは、それによって自動的にオリジナルデータセットへと移動される。データエントリを単純にそれらのデータセットタグフィールドを変更することによって多様なデータセット間で移動させることは、このように容易である。しかし、データエントリは、他の方法によっても同様に多様なデータセット間を移動させることができるため、本発明は、例えば統合を目的として、多様なデータセット間でデータエントリを移動させる上記の例に限定されない。

次に、図４を参照しながら、データセットタグを指示せずにデータクエリを用いる、別の実施形態によるデータベース構造と手順とについて記述しよう。図３の例の場合と同様に、データベース４００は、オリジナルデータエントリ＃１，２，３・・・がそれぞれ、データＸ_１、Ｘ_２、Ｘ_３、・・・を保持するようなデータセット４００ａ（「データセット０」）、並びに、２つの補助的データセット３００ｂ（データセット１）および３００ｃ（データセット２）を有する。データセット３００ａ、３００ｂ、３００ｃの中のデータエントリは、それぞれ、データセットタグ０、１、２を有する。さらに、オペレータが、図３の場合と同じように各補助的データセットの中のデータエントリを修正済みであり、それについては、再度ここで詳述しない。

加えて、本実施形態のオリジナルデータセット４００ａの中の各データエントリは、特定のデータセット、例えば、データエントリがその中で更新済みである補助的データセットを指し示す「データセットフラグ」を持つ別の補助的フィールドを有する。従って、データセット０の中のエントリ＃１は、更新データＺ_１を有するデータセット２の中の対応するエントリ＃１を指し示すデータセットフラグ２を有する。同様に、データセット０の中のエントリ＃２は、データセット１の中の対応するエントリを指し示すデータセットフラグ１を有し、そして、データセット０の中のエントリ＃３は、データセット２の中の対応するエントリを指し示すデータセットフラグ２を有する。この例には示していないが、オリジナルデータエントリがいずれの補助的データセットにおいても更新されていない場合、データエントリの中でデータセットフラグ０を用いること、すなわち自分自身を指し示すことが可能である。

オブジェクトのデータについてのクエリが、例えば要求側当事者に代わってクエリ実行論理Ａによって行われる場合であって、かつ、クエリが、オブジェクトのエントリキーまたは番号だけを参照し、いずれのデータセットタグをも参照しない場合、データエントリは、デフォルトとして、オリジナルデータセットから取得される。次いで、クエリ実行論理Ａは、受信したオリジナルデータエントリの中のデータセットフラグフィールドをチェックする。データセットフラグ＝０であってオリジナルデータセットを、すなわち自分自身を指し示す場合、オリジナルデータエントリの中のデータは有効であって更新されていないのだから、それ以上の動作は行われない。従って、取得されたオリジナルデータエントリの中のデータが、例えば要求側当事者への配信によって、用いられる。

そうではなく、データセットフラグ≠０であって補助的データセットを指し示す場合、クエリ実行論理Ａは、そのデータセットフラグを、要求側当事者についてアクティブに設定されているデータセットタグと比較する。取得されたエントリの中のデータセットフラグがアクティブなデータセットタグと異なる場合、それ以上の動作は行われず、取得されたオリジナルデータエントリの中のデータが、例えば要求側当事者への配信によって、用いられる。しかし、取得されたエントリの中のデータセットフラグが、アクティブなデータセットタグと等しい場合、データセットフラグが指し示していたアクティブなデータセットタグも含む別のクエリが行われる。それによって、正確なデータが取得されるであろうし、例えば要求側当事者へ配信されるために用いることもできる。

また、２つ以上のデータセットを、例えば特定の要求側当事者について、アクティブとして設定することも可能である。例えば、クエリ実行論理がアクティブなデータセット０とデータセット１とを両方使って構成される場合、クエリの時点で、両方のデータセットからのデータが取得されるであろう。

図４に示す一部の基本ステップは、例示的なデータクエリが本実施形態に従ってどのように実行されうるかを図解する。要求側当事者４０２が、エントリ＃３からのデータ（「オブジェクト＃３」）を望むことが想定されている。最初に示すステップ４：１では、クエリ実行論理Ａが、要求側当事者３０２にサービス提供するためにエントリ＃３について適宜にクエリを行うが、いかなるデータセットタグも含めない。次いで、データベース４００は、次のステップ４：２で、デフォルトとしてオリジナルデータセット４００ａのエントリ＃３からのデータＸ_３およびデータセットフラグ２と共に応答するであろう。

取得されたデータセットフラグ≠０であって補助的データセットを指し示すのだから、次のステップ４：３で、クエリ実行論理Ａは、受信されたエントリの中のデータセットフラグを、要求側当事者についてのアクティブなデータセットタグと比較する。データセットフラグが、アクティブなデータセットタグと等しい場合、ステップ４：４で、データセットフラグに従ってアクティブなデータセットタグ、すなわちデータセットタグ２も指定する、エントリ＃３についての別のクエリが行われる。それによって、ステップ４：５で、例えば要求側当事者へ配信するために、データセット２のエントリ＃３の中の正確なデータＺ_３が最終的にデータベース４００から取得される。

図４の上記の実施形態は、オリジナルデータセットの中のデータが有効な場合、すなわち、要求されたデータエントリの中のデータセットフラグ＝０である場合には、いかなるクエリの複雑性をも追加しないであろうし、そして、データセットタグがクエリの中にまったく含まれていないのだから、クエリは、従って、補助的データセットの追加によって影響されることはない。ここで留意されるべきだが、図４の例に従ってオリジナルデータエントリの中にデータセットフラグを含めることは、図３について記述したやり方で、すなわちクエリがデータセットタグを指定する場合に、データクエリを処理する可能性を排除しない。

図５は、ユーザデータを持つデータベース５００が、回線交換型電話番号をパケット交換型ユーザアドレスに翻訳するように構成されたＥＮＵＭサーバ５０２に接続する場合の、本発明についての実用例を図解する。ＥＮＵＭサーバ５０２は、データベース５００から関連データを検索するため、上記の諸実施形態のいずれかによるクエリ実行論理ユニットとして動作する。ＣＳＣＦ（呼セッション制御機能）と表示されたパケット交換型マルチメディアサービスのためのセッション制御ノード５０４が、セッションを制御する目的でデータベース５００からのユーザのデータをルーティングすることを必要とする要求側当事者として動作する。概要を述べると、データベース５００は、オリジナルデータセット５００ａ（データセット０）の中に「回線交換型データ」と、補助的データセット５００ｂ（データセット１）の中に「パケット交換型データ」とを持つ、ユーザのためのデータエントリを有し、すなわち、図３および図４の諸実施形態と同様の構造を有する。

この場合、オペレータは、非常に多数のユーザをＰＳＴＮ（公衆交換電話システム）サービスからＩＰネットワーク内のＩＰサービスへ移動させることを望む。オペレータは、ＩＰサービスへの期間の間に補助的データセットへのエントリとしてユーザを追加するであろうが、追加されたユーザは依然としてオリジナルデータセットの中のエントリに従って古いＰＳＴＮサービスを用いており、従って、オリジナルデータセットはＥＮＵＭサーバ５０２のクエリ実行論理ではアクティブであると設定されている。

次いで、点線の矢印で示すように、所与の瞬間に、アクティブなデータセットをＥＮＵＭサーバ５０２の中のオリジナル（０）から補助（１）へ変更することによって、一定限度のユーザが古いＰＳＴＮサービスから新たなＩＰサービスへ試行として切り替わるであろう。切替（または「カットオーバ」）が成功した場合、オペレータは、すべてのユーザを新たなサービスへ同様に「収容する」であろう。しかし、例えば構成エラー等のために切替に問題が生じた場合、本解決策によってオペレータは、ＥＮＵＭサーバ５０２の中のアクティブなデータセットを補助（１）からオリジナル（０）へ単純に変更することにより、瞬時にユーザを古いＰＳＴＮサービスへ戻すことができる。

この場合、ＥＮＵＭサーバ５０２は、ユーザが（オリジナルデータセット０がアクティブである）古いＰＳＴＮサービスを依然として用いる限り、ＥＮＵＭクエリについてはオリジナルデータセット５００ａからのＴＥＬ ＵＲＩ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）をＣＳＣＦノード５０４へ配信するであろう。それによって、呼はＰＳＴＮネットワークを通してルーティングされるであろう。切替の後（補助的データセット１がアクティブとなる）、アクティブデータセット（すなわち、補助的データセット１）が、代わりに、ドメイン名を備えたＳＩＰ（セッション開始プロトコル）ＵＲＩを有するであろうし、従って、ＣＳＣＦノード５０４へのＥＮＵＭの応答は、代わりにＳＩＰ ＵＲＩを有するであろう。それによって、呼またはセッションは、ドメイン名に基づいてＩＰネットワークを通してルーティングされるであろう。

図６は、通信システムにおけるオブジェクトのデータエントリについてオリジナルデータセットと１つ以上の補助的データセットとを持つ通信データベースからデータを取得するためのクエリ実行論理ユニットにおける手順を略示するフローチャートである。図６の手順は、基本的に、上記の図３および図４について記述した例に従って、最初のデータクエリの中にデータセットタグが指定されているか否かに依存して、実行される。従って、データベースの中の各データエントリは、それがどのデータセットに属するかを示すデータセットタグを備える。クエリ実行論理は、下記のやり方で、データエントリの中のデータセットタグに基づいて判定されるデータセットから所望のデータエントリのデータを取得することができる。

第１のステップ６００で、所望のデータエントリ、すなわちオブジェクトのデータについて最初のクエリが行われる。次いで、手順は、最初のクエリの中にデータセットタグが指定されている（右）か否（左）かについて、２つの分岐に分かれる、データセットタグがクエリの中に指定されている場合、ステップ６０２で、所与のデータセットタグによって示されるデータセットからデータが取得され、次いで、使用することができる。その場合、図５について述べたようにオリジナルエントリの中のデータセットフラグを用いる必要はない。

他方、データセットタグが最初のクエリの中に指定されていない場合、次のステップ６０４で、データは、デフォルトとして、オリジナルデータセットの中のエントリから取得される。また、そのエントリから、特定のデータセットを指し示すデータセットフラグも取得される。次のステップ６０６で、取得されたデータセットフラグがオリジナルデータセットタグと等しいかどうか、すなわち＝０かどうかが、上記の例に従ってチェックされる。そうである場合、取得されたオリジナルデータセットのデータは有効であり、次のステップ６０８において用いることができる。

取得されたデータセットフラグがオリジナルデータセットタグと異なる場合、すなわち、補助的データセットにおいてそのエントリについてデータが更新されたことが意味される場合、次のステップ６１０で、取得されたデータセットフラグが、クエリ実行論理において構成されたアクティブなデータセットと等しいかどうか、さらにチェックされる。いかなるアクティブなデータセットにも等しくない場合、それが属するデータセットはクエリ実行論理においてアクティブでないのだから、更新されたエントリが利用可能でないと結論付けることができる。代わりに、取得されたオリジナルデータセットのデータが、ステップ６０８に従って、デフォルトとして例えば要求側当事者への配信によって用いられてもよい。あるいは、エラーメッセージが要求側当事者へ送信されてもよいだろう。

ステップ６１０において、取得されたデータセットフラグが、構成されたアクティブなデータセットと等しい場合、次のステップ６１２で、アクティブなデータセットに従ってデータセットタグを指定するデータ、すなわち取得されたデータセットフラグについて、別のクエリが行われる。それによって、最後のステップ６１４に従って、問題のエントリのデータが、指定されたデータセットタグに従ってデータセットから取得され、それが最終的に用いられてもよい。後者の場合、（ステップ６０６によって、データセットフラグが補助的データセットを指し示すことから）更新済みのデータが取得され、（ステップ６１４で、構成されたアクティブなデータセットによってデータが取得されることから）使用可能である。

上記の諸実施形態のいずれかに従って本発明を用いると、下記の利点が得られうる。クエリ実行論理の中でアクティブなデータセットタグを変更することによって１つのデータセットから別のデータセットへ瞬時に切り替わる能力によって、多数のデータエントリの瞬時のアクティブ化とロールバックとが可能になる。例えば、ＥＮＵＭデータベースにおいて、多数の加入者を追加することは、数日間続く可能性もあるかなり遅いプロセスとなる可能性がある。従来なら、これは、加入者がＥＮＵＭデータベース内でプロビジョニングされたときに加入者が利用可能になることをも意味したであろう。しかし、上述の解決策を用いると、すべての加入者が適切にプロビジョニングされるまで、加入者データの利用可能性をオペレータが遅らせることができる。すべての加入者が適切にプロビジョニングされた後では、オペレータは、すべての加入者を一度に、瞬時にアクティブ化することができる。

また、オペレータが、例えば、構成エラー等の場合に、オリジナルデータセットへ単純に切り替えることによって、アクティブ化を瞬時にロールバックすることも可能である。次いで、オペレータは、諸問題を訂正し、再度、すべてのエントリを瞬時にアクティブ化してもよい。

また、オペレータは、例えば、データベースのうちの新規データセットの中で最初に１人の試行クライアントまたは限定数の試行クライアントをアクティブにすることによって、試行を行ってもよい。次いでオペレータは、新規データセットを検証するため、試行クライアントに対して各種の試験を実行してもよい。データセットが正確であると確信された後、次いで、オペレータは、（ライブ状態の）システム全体の中のデータをアクティブにすることに進んでもよい。

図３および図４についてそれぞれ記述した２つの手法を用いることによって、データベースシステムを、２つの異なるシナリオについて最適化することができる。図３の選択肢では、オリジナルデータセットに対するものも含めて、すべてのクエリについてクエリを若干複雑化することを犠牲にして、補助的データセットに対するクエリのレイテンシが減少する。他方の図４の選択肢では、オリジナルデータセットに対するクエリには複雑性は追加されないが、補助的データセットに着信するクエリのレイテンシが、若干増加する。

データベースシステムの全体的な論理は主に、クエリ実行論理に存在しており、そして、データベース自体には特別な適応を施す必要がないようなかたちで構成することができるであろう。すべての必要な論理は、データの構造と、プロビジョニングプロセスおよびクエリ実行論理の実装とだけで提供できる。これによって、いかなる共通タイプのデータベースについてもデータベース内のいかなる適応作業も必要とせず、本発明の展開が可能になる。

本発明について特定の例示的な諸実施形態を参照しながら記述してきたが、本記述は、本発明の範囲を限定すると解釈されるべきではない。本発明は、添付の請求項によって定義される。

Claims (21)

1. 通信データベースシステムにおいて複数のオブジェクトのためのデータエントリを含んだデータベース（３００）からデータを取得する方法であって、
   前記データベースは、前記オブジェクトのためのオリジナルデータを保持するデータエントリを伴うオリジナルデータセット（３００ａ）と、前記オブジェクトのうちの少なくとも一部のための更新されたデータを保持するデータエントリを伴う補助的データセット（３００ｂ，３００ｃ）とを含み、
   前記オリジナルデータセット中のデータエントリは第１のデータセットタグ（０）を含み、前記補助的データセット中のデータエントリは第２のデータセットタグ（１）を含み、当該第１及び第２のデータセットタグ（０，１）は各データエントリがどのデータセットに属するかを示し、
   前記方法は、
   要求されたデータエントリからのデータを求めるクエリを行うステップと、
   前記要求されたデータエントリ中のデータセットタグに基づいて決定されたデータセットから、前記要求されたデータエントリのデータを取得するステップと、
   を備えることを特徴とする方法。
2. 要求されるデータセットタグが前記クエリの中で指定され、
   前記指定されたデータセットタグに従うデータセットのデータエントリからデータが取得される
   ことを特徴とする請求項１に記載の方法。
3. 前記オリジナルデータセット中のデータエントリは更に、前記オリジナルデータセットと前記補助的データセットとのうちの１つを指すデータセットフラグ（０，１，２）を含み、
   データセットタグが前記クエリの中で指定されない場合、前記オリジナルデータセット中の前記要求されたデータエントリからデータ及びデータセットフラグが取得され、
   前記返されたデータセットフラグに基づいて正しいデータセットが決定される
   ことを特徴とする請求項１に記載の方法。
4. 前記取得されたデータセットフラグが前記オリジナルデータセットのタグと等しい場合、前記オリジナルデータセットから取得されたデータが使用される
   ことを特徴とする請求項３に記載の方法。
5. 前記取得されたデータセットフラグが前記オリジナルデータセットのタグと異なる場合、前記取得されたデータセットフラグが前記要求側当事者に対してアクティブにセットされているデータセットのタグと等しいか否かがチェックされ、
   等しくない場合、前記オリジナルデータセットから取得されたデータがデフォルトとして使用される
   ことを特徴とする請求項３に記載の方法。
6. 前記取得されたデータセットフラグが前記オリジナルデータセットのタグと異なる場合、前記取得されたデータセットフラグが前記要求側当事者に対してアクティブにセットされているデータセットのタグと等しいか否かがチェックされ、
   等しい場合、前記アクティブなデータセットのタグを示す別のクエリが行われ、当該示されたデータセットタグに従うデータセットのデータエントリからデータが取得される
   ことを特徴とする請求項３に記載の方法。
7. 特定の要求側当事者にとってどのデータセットがアクティブであり有効であるかに関する情報が保持され、これにより、各々の要求側当事者に対して前記データベースの異なるビューを提示する
   ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
8. 前記各々の要求側当事者にとってのアクティブなデータセットを変更することにより、特定の要求側当事者に対して提示される前記異なるビューが変更される
   ことを特徴とする請求項７に記載の方法。
9. 各データエントリは、各データエントリのデータセットタグを変更することにより、異なるデータセットの間で移動される
   ことを特徴とする請求項１乃至８のいずれか１項に記載の方法。
10. 前記データベースは、データエントリを伴う複数の補助的データセット（３００ｂ，３００ｃ）を含み、
    前記データエントリは、前記オブジェクトの少なくとも一部のための更新されたデータを保持し、また、データエントリがどの補助的データセットに属するかを示すデータセットタグ（１，２）を含む
    ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
11. 通信データベースシステムであって、複数のオブジェクトのためのデータエントリを含んだデータベース（３００）を備え、
    前記データベースは、
    前記オブジェクトのためのオリジナルデータを保持するデータエントリを伴うオリジナルデータセット（３００ａ，４００ａ）と、
    前記オブジェクトのうちの少なくとも一部のための更新されたデータを保持するデータエントリを伴う補助的データセット（３００ｂ，３００ｃ，４００ｂ，４００ｃ）と
    を含み、
    前記オリジナルデータセット中のデータエントリは第１のデータセットタグ（０）を含み、前記補助的データセット中のデータエントリは第２のデータセットタグ（１，２）を含み、当該第１及び第２のデータセットタグ（０，１，２）は各データエントリがどのデータセットに属するかを示し、
    前記通信データベースシステムは、前記データベースからデータを取得するクエリ実行論理ユニット（Ａ，Ｂ）を備え、
    前記クエリ実行論理ユニットは、
    要求されたデータエントリからのデータを求めるクエリを行い、
    前記要求されたデータエントリ中のデータセットタグに基づいて決定されたデータセットから、前記要求されたデータエントリのデータを取得する
    ように構成される
    ことを特徴とする通信データベースシステム。
12. 前記クエリ実行論理ユニットは更に、
    要求されるデータセットタグを前記クエリの中で指定し、
    前記指定されたデータセットタグに従うデータセットのデータエントリからデータを取得する
    ように構成されることを特徴とする請求項１１に記載のシステム。
13. 前記オリジナルデータセット中のデータエントリは更に、前記オリジナルデータセットと前記補助的データセットとのうちの１つを指すデータセットフラグ（０，１，２）を含み、
    前記クエリ実行論理ユニットは更に、
    データセットタグが前記クエリの中で指定されない場合、前記オリジナルデータセット中の前記要求されたデータエントリからデータ及びデータセットフラグを取得し、
    前記返されたデータセットフラグに基づいて正しいデータセットを決定する
    ように構成される
    ことを特徴とする請求項１１に記載のシステム。
14. 前記取得されたデータセットフラグが前記オリジナルデータセットのタグと等しい場合、前記オリジナルデータセットから取得されたデータが使用される
    ことを特徴とする請求項１３に記載のシステム。
15. 前記クエリ実行論理ユニットは更に、前記取得されたデータセットフラグが前記オリジナルデータセットのタグと異なる場合、前記取得されたデータセットフラグが要求側当事者に対してアクティブにセットされているデータセットのタグと等しいか否かをチェックするように構成され、
    等しくない場合、前記オリジナルデータセットから取得されたデータがデフォルトとして使用される
    ことを特徴とする請求項１３に記載のシステム。
16. 前記クエリ実行論理ユニットは更に、
    前記取得されたデータセットフラグが前記オリジナルデータセットのタグと異なる場合、前記取得されたデータセットフラグが要求側当事者に対してアクティブにセットされているデータセットのタグと等しいか否かをチェックし、
    等しい場合、前記アクティブなデータセットのタグを示す別のクエリを行い、当該示されたデータセットタグに従うデータセットのデータエントリからデータを取得する
    ように構成されることを特徴とする請求項１３に記載のシステム。
17. 前記クエリ実行論理ユニットは更に、特定の要求側当事者にとってどのデータセットがアクティブであり有効であるかに関する情報を保持し、これにより、各々の要求側当事者に対して前記データベースの異なるビューを提示するように構成される
    ことを特徴とする請求項１１乃至１６のいずれか１項に記載のシステム。
18. 前記クエリ実行論理ユニットは更に、前記各々の要求側当事者にとってのアクティブなデータセットを変更することにより、特定の要求側当事者に対して提示される前記異なるビューを変更するように構成される
    ことを特徴とする請求項１７に記載のシステム。
19. 各データエントリのデータセットタグを変更することにより、各データエントリを異なるデータセットの間で移動させるように構成される
    ことを特徴とする請求項１１乃至１８のいずれか１項に記載のシステム。
20. 前記データベースは、データエントリを伴う複数の補助的データセット（３００ｂ，３００ｃ）を含み、
    前記データエントリは、前記オブジェクトの少なくとも一部のための更新されたデータを保持し、また、データエントリがどの補助的データセットに属するかを示すデータセットタグ（１，２）を含む
    ことを特徴とする請求項１１乃至１９のいずれか１項に記載のシステム。
21. 通信システムにおける、複数のオブジェクトのためのデータエントリを含んだデータベース（３００）であって、
    前記オブジェクトのためのオリジナルデータを保持するデータエントリを伴うオリジナルデータセット（３００ａ，４００ａ）と、
    前記オブジェクトのうちの少なくとも一部のための更新されたデータを保持するデータエントリを伴う補助的データセット（３００ｂ，３００ｃ，４００ｂ，４００ｃ）と
    を含み、
    前記オリジナルデータセット中のデータエントリは第１のデータセットタグ（０）を含み、前記補助的データセット中のデータエントリは第２のデータセットタグ（１，２）を含み、当該第１及び第２のデータセットタグ（０，１，２）は各データエントリがどのデータセットに属するかを示し、
    これにより、クエリ実行論理ユニット（Ａ，Ｂ）が、要求されたデータエントリからのデータを求めるクエリを行い、前記要求されたデータエントリ中のデータセットタグに基づいて決定されたデータセットから、前記要求されたデータエントリのデータを取得することを可能にする
    ことを特徴とするデータベース。

Images