知財求人 - 知財ポータルサイト「IP Force」
▶ セールスフォース ドット コム インコーポレイティッドの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-10-31
(54)【発明の名称】スキーマ変更を処理するための機構
(51)【国際特許分類】
G06F 16/21 20190101AFI20241024BHJP
G06F 16/22 20190101ALI20241024BHJP
【ＦＩ】
G06F16/21
G06F16/22
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2024529884
(86)(22)【出願日】2022-11-08
(85)【翻訳文提出日】2024-05-21
(86)【国際出願番号】 US2022079463
(87)【国際公開番号】W WO2023102307
(87)【国際公開日】2023-06-08
(31)【優先権主張番号】17/457,244
(32)【優先日】2021-12-01
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】506332063
【氏名又は名称】セールスフォース インコーポレイテッド
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100229448
【弁理士】
【氏名又は名称】中槇 利明
(72)【発明者】
【氏名】スグロイ，マイケル
(72)【発明者】
【氏名】クォン，エレン
(72)【発明者】
【氏名】バスイェーガー，ベンジャミン
(72)【発明者】
【氏名】フェドレンコ，イゴル
【テーマコード（参考）】
5B175
【Ｆターム（参考）】
5B175CA09
(57)【要約】
データベーススキーマに関する技法が開示される。コンピュータシステムは、複数のレコードを記憶するデータベースのための更新されたスキーマを記述するメタデータドキュメントを受信し得る。コンピュータシステムは、更新されたスキーマに準拠するように複数のレコードのうちのいくつかをアップグレードするためのアップグレードルーチンを実行するための一組のプロセスをインスタンス化し得る。一組のプロセスがレコードをアップグレードしている間に、コンピュータシステムは、複数のレコードのうちの１つに対して動作を実行する要求を受信し得る。コンピュータシステムは、レコードが、メタデータドキュメントの更新されたスキーマのバージョンよりも前のスキーマバージョンに対応することを検出し得、更新されたスキーマに準拠するようにレコードをアップグレードし得る。レコードをアップグレードした後、コンピュータシステムは、レコードに対して要求された動作を実行し得る。
【特許請求の範囲】
【請求項1】
方法であって、コンピュータシステムによって、複数のレコードを記憶するデータベースの更新されたスキーマを記述するメタデータドキュメントを受信するステップと、
前記コンピュータシステムによって、前記更新されたスキーマに準拠するように前記複数のレコードをアップグレードするためのアップグレードルーチンを実行するための一組のプロセスをインスタンス化するステップと、
前記一組のプロセスが前記複数のレコードをアップグレードしている間に、前記コンピュータシステムが、
前記複数のレコードのうちの１つに対して動作を実行する要求を受信するステップと、
前記レコードが、前記メタデータドキュメントの前記更新されたスキーマのバージョンよりも前のスキーマバージョンに対応することを検出するステップと、
前記更新されたスキーマに準拠するように前記レコードをアップグレードするステップと、
前記レコードをアップグレードした後に、前記レコードに対して前記要求された動作を実行するステップと
を含む方法。
【請求項2】
前記更新されたスキーマは、一組のデータベースエンティティおよび対応する一組のステータスを記述し、前記一組のステータスのステータスは、対応するエンティティを、要求の処理に使用することができるかどうかを示す、請求項１に記載の方法。
【請求項3】
前記一組のデータベースエンティティのうちの特定のデータベースエンティティのステータスを求めるステータス要求をクライアントから受信したことに応答して、前記コンピュータシステムが、前記特定のデータベースエンティティの前記ステータスを示す応答を返すステップであって、前記クライアントは、前記特定のデータベースエンティティを前記クライアントからの要求の処理に使用することができるかどうかを判定するために前記応答を使用するように動作可能である、ステップをさらに含む、請求項２に記載の方法。
【請求項4】
前記一組のデータベースエンティティのうちの１つはインデックスであり、前記方法は、前記コンピュータシステムによって、前記メタデータドキュメント内で、前記インデックスが基づくテーブルのステータスを更新するステップであって、前記テーブルの前記更新されたステータスは、前記インデックスが作成されている間に前記テーブルが削除されることを防ぐ、ステップ
をさらに含む、請求項２に記載の方法。
【請求項5】
前記更新されたスキーマは、前記前のスキーマバージョンに記述されていないインデックスを記述し、前記更新されたスキーマに準拠するように前記レコードをアップグレードするステップは、前記レコードのエントリを前記インデックスに投入するステップと、
前記インデックスに前記エントリを投入した後に、前記更新されたスキーマの前記バージョンに一致するように前記レコードのバージョンを更新するステップと
を含む、請求項１に記載の方法。
【請求項6】
前記要求は、前記受信された要求を処理する際に使用されるべき最小スキーマバージョンを指定し、前記方法は、前記コンピュータシステムによって、前記コンピュータシステムのメモリに記憶されたスキーマが前記最小スキーマバージョンを満たさないことを検出するステップと、
前記メモリ内で、前記記憶されたスキーマを前記更新されたスキーマで置き換えるステップと
をさらに含む、請求項１に記載の方法。
【請求項7】
前記更新されたスキーマは、一組のデータベースエンティティに対する一組の更新を記述し、前記一組のデータベースエンティティのうちの第１のデータベースエンティティは、前記第１のデータベースエンティティが第２のデータベースエンティティの前に使用可能となるように、前記一組のデータベースエンティティのうちの前記第２のデータベースエンティティの前に移行される、請求項１に記載の方法。
【請求項8】
前記レコードは、アップグレードされ、前記データベースに記憶されることなく前記要求の発行者に返され、前記レコードは、その後、前記一組のプロセスのうちの１つによってアップグレードされ、前記データベースに記憶される、請求項１に記載の方法。
【請求項9】
前記一組のプロセスが前記アップグレードルーチンを実行した後に、前記コンピュータシステムが、前記複数のレコードのすべてが前記更新されたスキーマに準拠するようにアップグレードされたかどうかを判定するために一組の精査プロセスをインスタンス化するステップをさらに含む、請求項１に記載の方法。
【請求項10】
コンピュータシステムであって、少なくとも１つのプロセッサと、
請求項１から９のいずれか一項に記載の方法を実行するために前記少なくとも１つのプロセッサによって実行可能なプログラム命令が記憶されたメモリと
を備える、コンピュータシステム。
【請求項11】
コンピュータシステムに動作を実行させるために前記コンピュータシステムによって実行可能なプログラム命令を記憶したコンピュータ可読媒体であって、前記動作は、複数のレコードを記憶するデータベースの更新されたスキーマを記述するメタデータドキュメントを受信することと、
前記更新されたスキーマに準拠するように前記複数のレコードをアップグレードするためのアップグレードルーチンを実行するための一組のプロセスをインスタンス化することと、
前記一組のプロセスが前記複数のレコードをアップグレードしている間に、
前記複数のレコードのうちの１つに対して動作を実行する要求を受信することと、
前記レコードが、前記メタデータドキュメントの前記更新されたスキーマのバージョンよりも前のスキーマバージョンに対応することを検出することと、
前記更新されたスキーマに準拠するように前記レコードをアップグレードすることと、
前記レコードをアップグレードした後に、前記レコードに対して前記要求された動作を実行することと
を含む媒体。
【請求項12】
前記要求は、前記受信された要求を処理する際に使用されるべき最小スキーマバージョンを指定し、前記動作は、前記コンピュータシステムのインメモリキャッシュにキャッシュされたスキーマが前記最小スキーマバージョンを満たさないことを検出することと、
前記インメモリキャッシュ内で、前記キャッシュされたスキーマを前記更新されたスキーマで置き換えることと
をさらに含む、請求項１１に記載の媒体。
【請求項13】
前記動作は、前記複数のレコードのうちの異なるレコードに対して動作を実行する別の要求を受信することであって、前記別の要求は、最小スキーマバージョンを指定しない、受信することと、
前記異なるレコードをアップグレードすることなく、前記異なるレコードに対して前記別の要求の前記動作を実行することであって、前記異なるレコードは、前記更新されたスキーマの前記バージョンよりも前のスキーマバージョンに対応する、実行することと
をさらに含む、請求項１１または１２に記載の媒体。
【請求項14】
前記要求された動作を実行することは、前記アップグレードされたレコードを前記データベースから削除することを含む、請求項１１に記載の媒体。
【請求項15】
前記動作は、前記更新されたスキーマに記述されたデータベースエンティティのステータスを識別するステータス情報を維持することと、
前記データベースエンティティに関連付けられたレコードをアップグレードすることに応答して、前記データベースエンティティを要求の処理に使用することができることを示すように前記ステータスを更新することと
をさらに含む、請求項１１に記載の媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、一般に、データベースシステムに関し、より具体的には、データベースサービスを停止させることなくメタデータドキュメントへの変更を可能にするための様々な機構に関する。
【背景技術】
【0002】
企業は、ユーザが効率的にアクセスおよび操作することができる整理された方法で情報の集合を記憶することを可能にするデータベース管理システム（または、単に「データベースシステム」）を日常的に実装する。場合によっては、データベースシステムは、キーがその関連付けられた値にアクセスするための一意の識別子としての役割を果たす、キー値ペアの集合として情報を記憶するキー値データベースを実装する。動作中、データベースシステムは、アプリケーションを介してユーザから、または別のデータベースシステムなどの他のシステムから要求を受信して、そのキー値データベースに記憶された情報に対してトランザクションを実行する。そのため、データベースシステムは、それらの要求で指定されたキーを使用して、データベースから情報を読み出し、かつ／またはデータベースに情報を書き戻す。
【図面の簡単な説明】
【0003】
【図1】いくつかの実施形態による、データベースストアおよびデータベースノードを有するシステムの例示的な要素を示すブロック図である。
【図2】いくつかの実施形態による、一組のデータベースエンティティを記述するメタデータドキュメントの例示的な要素を示すブロック図である。
【図3A】いくつかの実施形態による、レコードを書き込むことを含むトランザクションを処理するデータベースアプリケーションの例示的な要素を示すブロック図である。
【図3B】いくつかの実施形態による、レコードを返すことを含むトランザクションを処理するデータベースアプリケーションの例示的な要素を示すブロック図である。
【図4】いくつかの実施形態による、更新されたメタデータドキュメントを記憶するためにそのキャッシュをリフレッシュすることが可能なデータベースノードの例示的な要素を示すブロック図である。
【図5】いくつかの実施形態による、トランザクションを処理することの一部としてレコードをアップグレードすることに関する例示的な方法を示すフロー図である。
【図6】いくつかの実施形態による、トランザクションを処理することの一部としてレコードをアップグレードすることに関する例示的な方法を示すフロー図である。
【図7】いくつかの実施形態による、マルチテナントシステムの要素を示すブロック図である。
【図8】いくつかの実施形態による、本開示で説明される様々なシステムを実装するためのコンピュータシステムの要素を示すブロック図である。
【発明を実施するための形態】
【0004】
データベースシステムは、キー値ペアの集合としてデータを記憶するキー値データベースを実装し得る。そのキー値データベースは、典型的に、どのデータをデータベースに書き込むことができるかに関する規則をチェックまたは実施するためのサポートをほとんどまたは全く提供しない。例えば、データベースは、データベースへの書込みが許可されるデータのタイプおよび構造を定義する「強く型付けされた」スキーマをサポートしない場合がある。その結果、強く型付けされたスキーマの実施なしに、あるアプリケーションがデータをデータベースに書き込み、その後、別のアプリケーションが、特定の値が含まれていることまたは特定の方法でフォーマットされることを期待して、そのデータにアクセスし得るが、そうではない可能性がある。したがって、別のアプリケーションは、そのデータに対して正しく動作することができない場合がある。データベースはそのサポートを提供しないので、データが記憶され、後で読み出される前に正しく構造化されていることを確実にする責任は、プロバイダではなく、データベースのクライアント／ユーザにある。これにより、データベースシステムのプロバイダがキー値データベースを採用しやすくなるが、データがスキーマにしたがって書き込まれることを確実にするというさらなる負担をクライアントにかける。クライアントにかかるこの負担を軽減するために、キー値データベースの上に位置し、強く型付けされたスキーマのサポートを提供するスキーマ管理層を実装することが望ましいであろう。また、クライアントが、過度の性能低下を経験することなくスキーマを更新できるようにすることも望ましいであろう。本開示は、とりわけ、クライアント／テナントが、更新を実装するためにデータベースの一部を停止させることなくスキーマを更新することができるように、スキーマ管理層をどのように実装するかという問題に対処する。
【0005】
以下で説明される様々な実施形態では、コンピュータシステムは、データベースストアと、コンピュータシステムのクライアントからのトランザクション要求にサービスするためのプロセスを実行するデータベースノードとを含む。データベースノードは、メタデータドキュメントに記述されたスキーマにしたがってデータが操作される（例えば、アクセスされる、記憶されるなど）ことを確実にし得る。動作中、データベースノードは、更新されたスキーマを記述するメタデータドキュメントを指定するスキーマ更新要求を受信し得る。要求に応答して、様々な実施形態では、データベースノードは、スキーマに準拠するようにデータベースストアのデータをアップグレードするためのアップグレードルーチンを実行する一組のアップグレードプロセスをインスタンス化する。一例として、更新されたスキーマは、新しいフィールドをユーザテーブルに追加し得る。アップグレードプロセスは、そのユーザテーブルのレコードを、それらのレコードが新しいフィールドの値を含むようにアップグレードし得る。しかしながら、それらのアップグレードプロセスがレコードをアップグレードしている間に、データベースノードは、アップグレード中のデータベースエンティティのレコードを含むトランザクションを実行する要求を受信する場合がある。レコードに対して要求された動作を実行する前に、様々な実施形態では、レコードがアップグレードプロセスによってまだ到達されていない可能性があるので、データベースノードは、レコードのバージョンが更新されたスキーマのバージョンと一致するかどうかを判定する。それらのバージョン間に不一致がある場合、データベースノードは、更新されたスキーマに準拠するようにレコードをアップグレードするための一組のステップを実行する。そのレコードがアップグレードされると、データベースノードは、レコードに対して要求された動作を実行し得る。
【0006】
メタデータドキュメントは、様々な実施形態では、スキーマによって記述されるデータベースエンティティのうちの１つまたは複数のデータベースエンティティのステータスを識別する。データベースエンティティが作成またはアップグレードされている間、そのステータスを、これらのプロセスを反映するように設定することができ、作成／アップグレードが完了したとき、ステータスを、データベースエンティティが準備完了であることを示すように更新することができる。様々な実施形態では、メタデータドキュメントに記述されるステータスは、特定のデータベースエンティティ（例えば、インデックス）が使用可能であるかどうかを判定するために、クライアントによってクエリされ得る。クライアントは、データベースエンティティが準備完了であると決定すると、そのデータベースエンティティを利用するトランザクション要求の発行を開始し得る。トランザクション要求は、いくつかの実施形態では、要求の処理に使用される最小スキーマバージョンを指定し得る。そのため、要求を処理するとき、データベースノードは、データベースノードのメモリ内にキャッシュされたスキーマのバージョンが最小スキーマバージョンを満たすかどうかを判定し得る。最小スキーマバージョンが満たされない場合、様々な実施形態では、データベースノードは、キャッシュされたスキーマを、最新のメタデータドキュメントに記述されたスキーマで置き換える。したがって、クライアントは、最小スキーマバージョンを使用して、データベースノードにそのキャッシュをリフレッシュさせ得る（まだそうしていない場合）。
【0007】
これらの技法は、レコードがそのスキーマに準拠するようにアップグレードされる間にクライアントに過度に影響を及ぼすことなく更新されることができるスキーマを介して強い型付けを提供する「スキーマ管理層」が実装されることを可能にするので、有利であり得る。クライアントが新しいフィールドをテーブルに追加するためにそのスキーマを更新する例を考える。スキーマ管理層は、レコードがクライアントによって要求または操作された時点でレコードをアップグレードすることができるので、クライアントは、テーブルがアップグレードされている間にテーブルのレコードにアクセスし続けることができる。したがって、クライアントは、テーブルと対話する前に、更新がテーブル中に伝播されるのを待つ必要がないであろう。さらに、スキーマに記述された異なるデータベースエンティティのステータスを追跡することによって、クライアントは、新しいインデックスなどの特定のエンティティが使用可能であるかどうかを判定することができる。さらに、トランザクション要求において最小スキーマバージョンを使用することにより、クライアントは、データベースノードにそのキャッシュをリフレッシュさせ、適切なときに最新バージョンを利用することができるようになるので、因果的一貫性を確保することができる。ここで、まず図１を参照しながら、本技法の例示的な適用例について説明する。
【0008】
次に図１を参照すると、システム１００のブロック図が示されている。システム１００は、ハードウェアまたはハードウェアルーチンとソフトウェアルーチンとの組合せを介して実装され得る一組の構成要素を含む。図示の実施形態では、システム１００は、データベースストア１１０と、データベースストア１１０およびクライアント１２１と対話するデータベースノード１２０とを含む。さらに図示のように、データベースストア１１０は、レコード１１２およびメタデータドキュメント１１４を含み、データベースノード１２０は、データベースアプリケーション１３０と、メタデータドキュメント１１４をキャッシュするために使用されるインメモリキャッシュ１４０とを含む。また、図示のように、データベースアプリケーション１３０は、１つまたは複数のアップグレードプロセス１３７を生成する（spawn）ことができるスキーマエンジン１３５を含む。いくつかの実施形態では、システム１００は、図示とは異なるように実装される。例えば、システム１００は、データベースサービスを集合的に実装する複数のデータベースノード１２０を含んでもよく、データベースストア１１０は、複数のメタデータドキュメント１１４を記憶してもよく、および／または複数のクライアント１２１は、データベースノード１２０と対話してもよい。別の例として、メタデータドキュメント１１４は、データベースストア１１０とは別のメタデータストアに記憶されてもよい。
【0009】
システム１００は、様々な実施形態では、そのサービスのユーザがアプリケーションを開発し、実行し、管理することを可能にするプラットフォームサービス（例えば、顧客関係管理（ＣＲＭ）プラットフォームサービス）を実装する。システム１００は、マルチテナントシステムによってホストされるユーザ／テナントに様々な機能を提供するマルチテナントシステムであり得る。したがって、システム１００は、様々な異なるユーザ（例えば、システム１００のプロバイダおよびテナント）からのソフトウェアルーチンを実行し、コード、ウェブページ、および他のデータをユーザ、データベース（例えば、データベースストア１１０）、およびシステム１００に関連するエンティティ（例えば、サードパーティシステム）に提供し得る。様々な実施形態では、システム１００は、クラウドプロバイダによって提供されるクラウドインフラストラクチャを使用して実装される。したがって、データベースストア１１０およびデータベースノード１２０は、それらの動作を容易にするために、そのクラウドインフラストラクチャの利用可能なクラウドリソース（例えば、コンピューティングリソース、ストレージリソース、ネットワークリソースなど）上で実行し、それを利用し得る。例えば、データベースノード１２０は、クラウドプロバイダのデータセンタに含まれるサーバベースのハードウェア上でホストされる仮想環境内で実行し得る。しかしながら、いくつかの実施形態では、システム１００は、パブリッククラウドとは対照的に、ローカルまたはプライベートインフラストラクチャを利用して実装される。
【0010】
データベースストア１１０は、様々な実施形態では、情報のアクセス、記憶、および操作を可能にするように整理された情報の集合を含む。データベースストア１１０は、データベースノード１２０がデータベースストア１１０に記憶された情報に対してこれらの動作（例えば、アクセス、記憶など）を実行することを可能にするサポートソフトウェア（例えば、ストレージノード）を含み得る。様々な実施形態では、データベースストア１１０は、ネットワーク（例えば、ストレージ接続ネットワーク（ＳＡＮ））上で互いに接続され、データ損失を防ぐために情報を冗長的に記憶するように構成された単一または複数のストレージデバイスを使用して実装される。ストレージデバイスは、データを永続的に記憶し得、したがって、データベースストア１１０は、システム１００の永続ストレージとして機能し得る。様々な実施形態では、データベースノード１２０によってデータベースストア１１０に書き込まれたデータは、マルチノード構成内の他のデータベースノード１２０にとってアクセス可能である。
【0011】
様々な実施形態では、データは、データベースストア１１０において、メタデータドキュメント１１４に記述された１つまたは複数のスキーマにしたがって構造化されたレコード１１２に記憶される。場合によっては、システム１００は、リレーショナルデータベースを実装し得、したがって、メタデータドキュメント１１４は、テーブル、ビュー、インデックス、関係、トリガなどを記述し得る。したがって、レコード１１２は、データベーステーブル内の行に対応し、そのテーブルの１つまたは複数のフィールドの値を指定し得る。フィールドのうちの１つまたは複数を使用して、データベースストア１１０からそのレコードにアクセスするためのキーを定義し得る。様々な場合において、システム１００は、キー値ストア、ワイドカラムストア、ドキュメントストアなどの非リレーショナルデータベースを実装し得、したがって、メタデータドキュメント１１４は、データベースストア１１０に記憶されたアイテム／レコード１１２のプロパティおよび／または制約を記述し得る。例えば、レコード１１２は、そのレコード１１２をルックアップするために使用することができるデータおよび対応するキーを含むキー値ペアであり得る。したがって、メタデータドキュメント１１４は、レコード１１２が値を記憶することが期待される一組のフィールドを記述し得る。したがって、様々な実施形態では、メタデータドキュメント１１４は、データベースストア１１０がどのように構築されるべきかの青写真としてデータの整理を記述するモノリシックドキュメントである。例示的なメタデータドキュメント１１４は、図２に関してより詳細に説明される。
【0012】
データベースノード１２０は、様々な実施形態では、データ記憶、データ取出し、およびデータ操作などの様々なデータベースサービスを提供する。データベースノード１２０は、ハードウェアと、そのハードウェア上で実行されるソフトウェア（例えば、データベースアプリケーション１３０）との組合せであり得る。様々な実施形態では、データベースアプリケーション１３０は、データベースノード１２０のデータベースサービスを、システム１００内および／またはシステム１００の外部の構成要素に提供するように実行可能である。例えば、示されるように、データベースノード１２０は、トランザクションを実行するために、クライアント１２１（例えば、アプリケーションサーバ、ユーザデバイス、別のデータベースノードなど）からトランザクション要求１２２を（例えば、Java（登録商標）Database ConnectivityなどのＡＰＩを介して）受信することができる。データベーストランザクションは、様々な実施形態では、データベースストア１１０に関連して実行されるべき論理的な作業単位（例えば、指定された一組のデータベース操作）である。例えば、データベーストランザクションを処理することは、ＳＥＬＥＣＴコマンドを実行して、一組のテーブルから一組の行を選択することを含み得る。行のコンテンツは、レコード１１２において指定され得、したがって、データベースノード１２０は、それらの行に対応するレコード１１２を返し得る。別の例として、データベーストランザクションを処理することは、データベースストア１１０に記憶されたコレクションに、レコード１１２の形態で、一組の文書を書き込むことを含み得る。いくつかの実施形態では、データベースノード１２０は、最初にレコード１１２をインメモリキャッシュ１４０に書き込んでから、それらがコミットされた後にそれらをデータベースストア１１０にフラッシュする。本明細書で使用される場合、「トランザクションをコミットする」という表現は、そのよく理解されている意味にしたがって使用され、トランザクション中に行われた変更を保存させ、トランザクションを実行したエンティティの外部で見えるようにするプロセスを指す。
【0013】
データベーストランザクションを処理することの一部として、様々な実施形態では、データベースノード１２０は、データがメタデータドキュメント１１４に記述された一組のスキーマにしたがって管理されることを確実にする。特に、データベースストア１１０は、強い型付けのためのサポートを提供しないキー値ストアであり得るが、強い型付けは、依然としてクライアント１２１によって望まれ得る。そのため、データベースノード１２０は、様々な実施形態では、クライアント１２１が、データを構造化し、データにアクセスするためのフレームワークを定義することを可能にし、次いで、データベースノード１２０は、そのフレームワークを実施し、その結果、強い型付けが提供される。したがって、様々な実施形態では、データベースノード１２０は、前述のスキーマ管理層を実装する。トランザクションを潜在的により効率的に処理するために、データベースノード１２０は、図示のように、メタデータドキュメント１１４をそのインメモリキャッシュ１４０にキャッシュすることができる。
【0014】
インメモリキャッシュ１４０は、様々な実施形態では、データをデータベースノード１２０のメモリ（例えば、ランダムアクセスメモリ）に記憶するバッファである。インメモリキャッシュ１４０は、データベースノード１２０上で実行されるオペレーティングシステムによって指定される共有メモリ領域内に位置し得、データベースノード１２０のデータベースプロセス（例えば、アップグレードプロセス１３７）にとってアクセス可能であり得る。したがって、トランザクション要求１２２を処理する際、データベースアプリケーション１３０は、インメモリキャッシュ１４０からメタデータドキュメント１１４にアクセスし、次いで、メタデータドキュメント１１４を考慮して、要求されたトランザクションを処理し得る。図４に関してより詳細に説明するように、インメモリキャッシュ１４０にキャッシュされるメタデータドキュメント１１４は、データベースストア１１０に記憶されるものとは異なるバージョンであり得る。したがって、様々な実施形態では、データベースノード１２０は、リフレッシュ期間の後に、またはトランザクション要求１２２に応答して、最新のメタデータドキュメント１１４をキャッシュするためにインメモリキャッシュ１４０をリフレッシュする。
【0015】
メタデータドキュメント１１４内に記述されたスキーマ（複数可）を作成または更新するために、クライアント１２１は、図示のように、スキーマ要求１２６をデータベースノード１２０に送信することができる。スキーマ要求１２６は、データベースストア１１０に記憶されたメタデータドキュメントを置き換えるために使用される新しいメタデータドキュメント１１４を含み得る。新しいメタデータドキュメント１１４は、新しいデータベースエンティティ（例えば、インデックス）を定義し、および／または前のメタデータドキュメント１１４に記述された既存のデータベースエンティティを更新し得る（例えば、テーブルにフィールドを追加する）。様々な実施形態では、データベースノード１２０は、メタデータドキュメント１１４を、それらのメタデータドキュメント１１４内に記述されたデータベースエンティティのステータスを識別するステータス情報で補足する。したがって、場合によっては、クライアント１２１は、特定のデータベースエンティティのステータスを決定するためにスキーマ要求１２６を発行し得る。データベースノード１２０は、メタデータドキュメント１１４またはそれらのデータベースエンティティのステータスの表示を含むスキーマ応答１２８をそのクライアント１２１に送信し得る。データベースノード１２０はまた、最新のメタデータドキュメント１１４のバージョンを識別するスキーマ応答１２８を提供して、クライアント１２１が（例えば、最小バージョンを指定することによって）そのメタデータドキュメント１１４を利用するトランザクション要求１２２を発行することを可能にし得る。新しいメタデータドキュメント１１４を受信した後、データベースノード１２０は、スキーマエンジン１３５を実行して、新しいメタデータドキュメント１１４に準拠するようにシステム１００をアップグレードし得る。
【0016】
スキーマエンジン１３５は、様々な実施形態では、メタデータドキュメント１１４に準拠するような一組のレコード１１２のアップグレード／移行を容易にする。図示のように、スキーマエンジン１３５は、一組のアップグレードプロセス１３７をインスタンス化することができる。アップグレードプロセス１３７は、様々な実施形態では、特定のメタデータドキュメント１１４において更新または作成されたデータベースエンティティに関連付けられたレコード１１２をウォークスルーしてアップグレードする。例えば、メタデータドキュメント１１４は、テーブル上の新しいインデックスを記述し得、したがって、アップグレードプロセス１３７は、そのテーブルのレコード１１２をウォークスルーし、処理して、新しいインデックスを作成し得る。レコード１１２の処理の一部として、アップグレードプロセス１３７は、特定のメタデータドキュメント１１４のバージョンに一致するように、そのレコード１１２のバージョンを更新し得る。アップグレードプロセス１３７がレコード１１２を処理している間、データベースノード１２０は、トランザクション要求１２２をサービスし続け得る。
【0017】
様々な場合において、アップグレードプロセス１３７がレコード１１２を処理している間に、データベースノード１２０は、特定の一組のレコード１１２に対して動作を実行するトランザクション要求１２２を受信し得る。データベースノード１２０は、それらのレコード１１２にアクセスし、それらのうちの１つまたは複数がアップグレードプロセス１３７によってまだアップグレードされていないと判定し得る。それに応答して、データベースノード１２０は、まず、そのキャッシュされたメタデータドキュメント１１４に基づいてレコード１１２をアップグレードし、次いで、それらのレコード１１２に対して要求された動作を実行し得る。読取り／アクセス要求の一部としてレコード１１２をアップグレードする例を図３Ａに関して説明し、更新／書込み要求の一部としてレコード１１２をアップグレードする例を図３Ｂに関して説明する。
【0018】
次に図２を参照すると、メタデータドキュメント１１４のブロック図が示されている。図示の実施形態では、メタデータドキュメント１１４は、データベースエンティティ２００Ａ～Ｃ、ステータス２０５、およびバージョン２１０を記述する。図示のように、データベースエンティティ２００Ａ～Ｃは、各々、それぞれのステータス２０５を含む。いくつかの実施形態では、メタデータドキュメント１１４は、図示したものとは異なるように実装される。例えば、データベースエンティティ２００は、バージョン２１０を指定し得る。
【0019】
データベースエンティティ２００は、様々な実施形態では、データベースの実装を容易にするデータベース構築物または構造である。例えば、データベースエンティティ２００は、テーブル、インデックス、パッケージ、プロシージャ、関数、トリガ、ビュー、シーケンス、またはリンクであり得る。データベースエンティティ２００は、メタデータドキュメント１１４内で正式に定義され、その正式な定義に基づいて作成および管理される。したがって、様々な実施形態では、データベースエンティティ２００を作成または更新するために、新しい／更新されたデータベースエンティティ２００は、スキーマ要求１２６を介してデータベースノード１２０にサブミットされるメタデータドキュメント１１４に記述される。サブミットされたメタデータドキュメント１１４は、データベースストア１１０にある既存のメタデータドキュメント１１４を置き換え得る。次いで、データベースノード１２０は、適切なデータベースエンティティ２００の更新／作成を実施し得る。データベースエンティティ２００の現在の状態を追跡するために、図示のように、データベースエンティティ２００をステータス２０５に関連付けることができる。
【0020】
ステータス２０５は、様々な実施形態では、エンティティの現在の状態を示す。状態の例には、「作成中」、「更新中」、および「準備完了」が含まれ得る。ステータス２０５は、クライアント１２１からのトランザクション要求１２２を処理するためにデータベースエンティティ２００を使用することができるかどうかを判定するために、クライアント１２１によって使用され得る。例えば、クライアント１２１は、一組のテーブルに基づく新しいビューデータベースエンティティ２００を記述するメタデータドキュメント１１４をサブミットし得る。そのビューデータベースエンティティ２００が作成されている間、そのステータス２０５は、データベースノード１２０によって「作成中」に設定され得る。したがって、クライアント１２１がステータス２０５についてデータベースノード１２０に（例えば、スキーマ要求１２６を介して）ポーリングするとき、クライアント１２１は、ビューデータベースエンティティ２００が準備完了していないと決定し、したがって、ビューデータベースエンティティ２００を利用するトランザクション要求１２２をサブミットしないことができる。クライアント１２１が、ステータス２０５が「準備完了」に設定されたことを観察すると、クライアント１２１は、ビューデータベースエンティティ２００を利用するトランザクション要求１２２のサブミットを開始し得る。
【0021】
様々な場合において、データベースエンティティ２００は、別のデータベースエンティティ２００に依存し得る。例えば、データベースエンティティ２００Ａは、データベーステーブルに対応し得、データベースエンティティ２００Ｂは、そのテーブルに基づいて構築されたインデックスに対応し得る。したがって、いくつかの実施形態では、データベースエンティティ２００のステータス２０５は、別のデータベースエンティティ２００に対して行われた変更に応答して設定され得る。例えば、データベースエンティティ２００Ｃは、データベースエンティティ２００Ａのテーブルに基づいて新しいインデックスに対応し得る。そのインデックスが構築されている間、データベースエンティティ２００Ａのステータス２０５は、データベースエンティティ２００Ａが使用中であることを示すために「保留中」に設定され得る。これにより、データベースエンティティ２００Ａが削除されたり、その構造が変更されたりすることを防ぎ得る。そのインデックスが準備完了になると、データベースエンティティ２００Ａおよび２００Ｃのステータス２０５は、「準備完了」に設定され得る。
【0022】
図示のように、メタデータドキュメント１１４は、ステータス２０５を含む。このステータス２０５は、すべてのデータベースエンティティ２００が準備完了であるかどうか、または少なくとも１つのデータベースエンティティ２００がまだ作成中もしくは更新中であることを示し得る。様々な実施形態では、データベースエンティティ２００は、システム１００によって少なくとも部分的に並行して作成または更新される。しかしながら、いくつかの実施形態では、データベースエンティティ２００は、連続的に作成または更新される。例えば、メタデータドキュメント１１４は、データベースエンティティ２００Ｂおよび新しいデータベースエンティティ２００Ｃの新しいフィールドを記述し得る。データベースノード１２０は、物理的データベースエンティティ２００Ｃを作成する前に、データベースエンティティ２００Ｂのレコード１１２を更新し得る。結果として、一部のデータベースエンティティ２００は、他のデータベースエンティティ２００の前に使用する準備ができている場合があり、メタデータドキュメント１１４のステータス２０５を使用して、すべてのデータベースエンティティがいつ準備完了になるかを示すことができる。
【0023】
さらに図示されるように、メタデータドキュメント１１４はバージョン２１０を含む。バージョン２１０は、様々な実施形態では、メタデータドキュメント１１４の進行を示す値を識別する。したがって、所与のメタデータドキュメント１１４のバージョン２１０は、そのメタデータドキュメント１１４が別のメタデータドキュメント１１４の前のバージョンであるか後のバージョンであるかを判定するために使用され得る。バージョン２１０はさらに、クライアント１２１が、特定のデータベースエンティティ２００がトランザクション要求１２２の処理に使用可能であることを確実にすることを可能にし得る。例えば、クライアント１２１は、トランザクション要求１２２において最小スキーマバージョンを指定し得、データベースノード１２０は、その最小バージョンを、インメモリキャッシュ１４０にキャッシュされたメタデータドキュメント１１４のバージョン２１０と比較し得る。
【0024】
次に図３Ａを参照すると、データベースアプリケーション１３０がレコード１１２の書込みを含むトランザクションを処理するブロック図が示されている。図示の実施形態では、データベースストア１１０、データベースアプリケーション１３０、およびインメモリキャッシュ１４０が存在する。図示のように、データベースストア１１０は、バージョン２１０Ａ「１．２」を有するレコード１１２Ａと、バージョン２１０Ｂ～Ｄ「１．１」を有するレコード１１２Ｂ～Ｄとを含む。さらに図示されるように、データベースアプリケーション１３０は、トランザクションプロセス３２０と、アップグレードプロセス１３７を実装するスキーマエンジン１３５とを含む。また、図示されるように、インメモリキャッシュ１４０はメタデータドキュメント１１４を含む。図示の実施形態は、図示したものとは異なるように実装され得る。一例として、メタデータドキュメント１１４も記憶するメタデータストアがあってもよい。
【0025】
説明したように、データベースノード１２０は、新しいメタデータドキュメント１１４を指定するスキーマ要求１２６を受信することができる。その要求を受信したことに応答して、様々な実施形態では、スキーマエンジン１３５は、新しいメタデータドキュメント１１４に記述された変更に対応するレコード１１２に対してマイグレーションスキャン３０５を実行するために、一組のアップグレードプロセス１３７をインスタンス化する。場合によっては、データベースストア１１０内に記憶されたすべてのレコード１１２が、そのマイグレーションスキャン３０５の一部としてスキャンされる。いくつかの実施形態では、スキーマエンジン１３５は、インメモリキャッシュ１４０をクリアすることができるように、マイグレーションスキャン３０５を開始する前に一定期間待機し得る。スキャンされたレコード１１２は、新しいメタデータドキュメント１１４内に記述されたスキーマ（複数可）に準拠するように移行され得る。
【0026】
マイグレーションスキャン３０５の一部として、いくつかの実施形態では、アップグレードプロセス１３７は、（アップグレード中のデータベースエンティティ２００の）レコード１１２に、そのレコードのバージョン２１０に対応するメタデータを使用してアクセスし、新しいメタデータドキュメント１１４のメタデータに基づいてレコード１１２をアップグレードし、次いで、そのレコード１１２をデータベースストア１１０に書き戻す「オンディスク」マイグレーションを実行する。レコードが読み取られた後、レコードが書き込まれる前に別の同時書込みが発生する可能性があるので、読取り－書込みラウンドトリップはアトミックではない場合がある。したがって、様々な実施形態では、レコードの書き戻し（writeback）は、レコードがアップグレードプロセス１３７によってアクセスされた時点から変更されていないことを条件とする。この条件は、元のレコードに存在しない属性に関連し得る。
【0027】
場合によっては、一組のアップグレードプロセス１３７は、アップグレードされるべきレコード１１２を見逃す（miss）可能性があり、例えば、データベースノード１２０がクラッシュした場合にレコード１１２が見逃される可能性がある。すべての関連するレコード１１２がアップグレードされたことを確実にするために、いくつかの実施形態では、データベースノード１２０は、レコード１１２をトラバースし、アップグレードプロセス１３７によってアップグレードされなかったが、アップグレードされるべきであった任意のレコード１１２を移動させる一組の精査プロセスを生成する。精査プロセスは、定期的に、またはマイグレーションポイントに到達した後（例えば、マイグレーションスキャン３０５の完了後）に生成され得る。
【0028】
トランザクションプロセス３２０は、様々な実施形態では、データベースノード１２０の様々なデータベースサービスを提供するために実行可能なコンピュータプロセスである。トランザクションプロセス３２０は、確立されたデータベース接続を介してクライアント１２１によって渡されたトランザクション要求１２２を処理するために、インスタンス化され得る。トランザクション要求を処理することの一部として、トランザクションプロセス３２０は、その要求で指定された一組のデータベースステートメントを実行し得る。それらのデータベースステートメントを実行するために、様々な実施形態では、トランザクションプロセス３２０は、データベースステートメントを満たすために実行されるべきステップのシーケンスを定義するクエリ実行プランを実行する。したがって、トランザクションプロセス３２０は、（例えば、データベース１１０における）クエリ実行プランの定義にアクセスし、それをトランザクションプロセス３２０が実行可能な形式にコンパイルし、その後、コンパイルされた形式を実行し得る。
【0029】
様々な場合において、一組のアップグレードプロセス１３７がマイグレーションスキャン３０５を実行している間に、データベースアプリケーション１３０は、作成中または更新中のデータベースエンティティ２００にレコード１１２を書き込むことを含むトランザクションを実行するトランザクション要求１２２を受信し得る。その結果、様々な実施形態では、データベースアプリケーション１３０は、レコード１１２（これは新しいレコードまたは更新であり得る）がそのインメモリキャッシュ１４０内のメタデータドキュメント１１４に準拠することを確実にする。図４に関してより詳細に説明するように、データベースノード１２０は、最新のメタデータドキュメント１１４を記憶するように、そのインメモリキャッシュ１４０を定期的にリフレッシュし得る。書き込まれるレコード１１２が新しいレコードである場合、データベースノード１２０は、キャッシュされたメタデータドキュメント１１４にしたがって、そのレコード１１２をデータベースストア１１０に書き込み得る。
【0030】
書き込まれるレコード１１２が更新である場合、トランザクションプロセス３２０は、既存のレコード１１２にアクセスし得る。例えば、トランザクション要求１２２は、レコード１１２Ｃに更新を提供してもよく、したがって、トランザクションプロセス３２０は、図示のように、レコード１１２Ｃにアクセスし得る。アクセスされたレコード１１２のバージョン２１０が、インメモリキャッシュ１４０にキャッシュされているメタデータドキュメント１１４のバージョンと一致する場合、トランザクションプロセス３２０は、更新されたレコード１１２をデータベースストア１１０に書き込む。バージョン間に不一致がある場合、トランザクションプロセス３２０は、既存のレコード１１２をメタデータドキュメント１１４のバージョンにアップグレードするために一組のステップを実行し得る。例えば、メタデータドキュメント１１４が、アクセスされたレコード１１２を含むデータベーステーブルにフィールドを追加する場合、トランザクションプロセス３２０は、そのフィールドの値を含むようにレコード１１２をアップグレードし得る。いくつかの実施形態では、トランザクションプロセス３２０は、アップグレードされたレコード１１２をデータベースストア１１０に書き戻し、次いで、要求を再試行する。他の実施形態では、トランザクションプロセス３２０は、要求された更新をアップグレードされたレコード１１２に書き込み、そのレコード１１２をデータベースストア１１０に書き込む。様々な実施形態では、トランザクションプロセス３２０は、レコード１１２のバージョンをさらに更新する。例えば、レコード１１２Ｃが最初にアクセスされたとき、そのバージョン２１０Ｃは「１．１」である（一組のアップグレードプロセス１３７によってまだアップグレードされていない可能性があるので）が、キャッシュされたメタデータドキュメント１１４のバージョンは「１．２」である可能性がある。そのため、トランザクションプロセス３２０は、レコード１１２Ｃをバージョン「１．２」にアップグレードし、次いで、アップグレードされたレコード１１２Ｃに対して要求された動作を実行し得る。
【0031】
条件付きである他のデータベース操作（例えば、そのプロパティ「ｆｏｏ」値が「ｂｌａｈ」に等しい場合にレコード１１２を削除する）は、データベース操作を実行する前にレコード１１２をアップグレードすることを含み得る。一例として、メタデータドキュメント１１４は、データベーステーブルにフィールド「ｆｏｏ」を追加し得、データベースアプリケーション１３０は、「ｆｏｏ」の値が「ｂｌａｈ」であるそのデータベーステーブルの任意のレコード１１２を削除する要求を受信し得る。レコード１１２がそのフィールドの値を有するようにアップグレードされていない場合、様々な実施形態では、データベースアプリケーション１３０は、削除動作を実施することができるように、そのフィールドの値を有するようにレコード１１２をアップグレードする。特定のレコード１１２を別のレコード１１２に置き換える置換動作は、条件付きであり得、したがってレコード１１２のアップグレードを含み得るデータベース操作の別の例である。いくつかの実施形態では、要求された動作が条件付きでない場合、データベースアプリケーション１３０は、関連するレコード１１２をアップグレードすることなく、要求された動作を実行し得る。その代わりに、一組のアップグレードプロセス１３７は、マイグレーションスキャン３０５中にレコード１１２に到達すると、それをアップグレードし得る。
【0032】
次に図３Ｂを参照すると、データベースアプリケーション１３０がレコード１１２を返すことを含むトランザクションを処理するブロック図が示されている。図示の実施形態では、データベースストア１１０、データベースアプリケーション１３０、およびインメモリキャッシュ１４０が存在する。図示のように、データベースストア１１０は、バージョン２１０Ａ「１．２」を有するレコード１１２Ａと、バージョン２１０Ｂ～Ｄ「１．１」を有するレコード１１２Ｂ～Ｄとを含む。さらに図示されるように、データベースアプリケーション１３０は、トランザクションプロセス３２０と、アップグレードプロセス１３７を実装するスキーマエンジン１３５とを含む。また、図示されるように、インメモリキャッシュ１４０はメタデータドキュメント１１４を含む。図示の実施形態は、図示したものとは異なるように実装され得る。一例として、メタデータドキュメント１１４も記憶するメタデータストアがあってもよい。
【0033】
場合によっては、データベースアプリケーション１３０は、データベースストア１１０に記憶された１つまたは複数のレコード１１２を返すトランザクション要求１２２を受信する。レコード１１２を書き込むことと同様に、トランザクションプロセス３２０は、レコード１１２にアクセスし、そのバージョン２１０がキャッシュされたメタデータドキュメント１１４のバージョンと同じであるかどうかを判定し、次いで、レコード１１２を要求元に返す前に、（該当する場合）レコード１１２をアップグレードし得る。「オンディスク」マイグレーションを実行する代わりに、様々な実施形態では、トランザクションプロセス３２０は、レコード１１２がアップグレードされるが、データベースストア１１０に書き戻されない「インメモリ」マイグレーションを実行する。例えば、レコード１１２Ｃは、データベースアプリケーション１３０において、アクセスされ、キャッシュされたメタデータドキュメント１１４に準拠するようにアップグレードされ得るが、データベースストア１１０に書き込まれなくてもよく、むしろ、一組のアップグレードプロセス１３７は、レコード１１２Ｃがアップグレードされ、データベースストア１１０に書き込まれるオンディスクマイグレーションを実行してもよい。しかしながら、いくつかの実施形態では、トランザクションプロセス３２０は、レコード１１２をアップグレードし、それを（例えば、トランザクション応答１２４を介して）要求元に返し、次いで、それをデータベースストア１１０に書き込み得る。
【0034】
次に図４を参照すると、更新されたメタデータドキュメント１１４を記憶するためにそのインメモリキャッシュ１４０をリフレッシュするデータベースノード１２０のブロック図が示されている。図示の実施形態では、２つのデータベースノード１２０Ａ～Ｂおよびデータベースストア１１０が存在する。図示のように、両方のデータベースノード１２０Ａ～Ｂは最初、バージョン２１０Ａ「１．１」を有するメタデータドキュメント１１４Ａをキャッシュし、データベースストア１１０は、バージョン２１０Ｂ「１．２」を有するメタデータドキュメント１１４Ｂを記憶する。さらに図示されるように、データベースストア１１０は、バージョン２１０「１．１」を有するレコード１１２を記憶する。図示の実施形態は、図示したものとは異なるように実装され得る。例えば、２つのデータベースノード１２０Ａ～Ｂが存在しなくてもよい。
【0035】
説明したように、いくつかの実施形態では、データベースノード１２０は、更新されたメタデータドキュメント１１４を含むスキーマ要求１２６を受信することができる。しかしながら、様々な実施形態では、更新されたメタデータドキュメント１１４をサブミッすることができるメタデータエンドポイントが提供され、メタデータサーバ（図示せず）によって記憶される。その結果、データベースノード１２０にキャッシュされたメタデータドキュメント１１４は、一時的に、データベースストア１１０に記憶されているメタデータドキュメント１１４よりも古いバージョンになる可能性がある。上述したように、データベースノード１２０は、そのインメモリキャッシュ１４０内のメタデータドキュメント１１４にしたがってトランザクション要求１２２を処理し得る。その結果、トランザクション要求１２２は、より古いバージョンに関連付けられたメタデータドキュメント１１４にしたがって処理される可能性がある。
【0036】
様々な実施形態では、データベースノード１２０が少なくとも特定のバージョンを使用することを確実にするために、クライアント１２１は、それらのトランザクション要求１２２において最小スキーマバージョンを指定することができる。図示のように、例えば、トランザクション要求１２２Ａは、最小スキーマバージョン「１．１」を指定する。メタデータドキュメント１１４Ａはバージョン２１０Ａ「１．１」を有するので、データベースノード１２０Ａは、そのインメモリキャッシュ１４０をリフレッシュするのではなく、代わりに、メタデータドキュメント１１４Ａを使用してトランザクション要求１２２Ａを処理し得る。したがって、トランザクション要求１２２Ａが図示されたレコード１１２にアクセスしようとする場合、データベースノード１２０Ａは、レコード１１２にアクセスし、そのバージョン２１０がメタデータドキュメント１１４Ａのバージョンと一致すると判定し、そのレコード１１２をアップグレードすることなくレコード１１２を返し得る。トランザクション要求１２２Ａとは対照的に、トランザクション要求１２２Ｂは、最小バージョン「１．２」を指定する。データベースノード１２０Ｂに記憶されたメタデータドキュメント１１４Ａは最小バージョンよりも小さいので、データベースノード１２０Ｂは、メタデータドキュメント１１４Ｂにアクセスし、そのインメモリキャッシュ１４０において、メタデータドキュメント１１４Ａをメタデータドキュメント１１４Ｂで置き換える。
【0037】
次いで、データベースノード１２０Ｂは、トランザクション要求１２２Ｂを処理し得る。トランザクション要求１２２Ｂがレコード１１２にアクセスしようとする場合、データベースノード１２０Ｂは、レコード１１２にアクセスし、そのバージョン２１０がメタデータドキュメント１１４Ｂのバージョンと異なると判定し、レコード１１２をバージョン「１．２」にアップグレードし得る。その後、データベースノード１２０Ｂは、アップグレードされたレコード１１２を要求元に返し、および／またはそのレコード１１２をデータベースストア１１０に書き戻し得る。したがって、クライアント１２１は、データベースノード１２０に少なくとも最小メタデータドキュメントバージョンを使用させ得る。最新のメタデータドキュメントバージョンを決定するために、様々な実施形態では、クライアント１２１は、最新のメタデータドキュメント１１４にアクセスするスキーマ要求１２６をデータベースノード１２０またはメタデータサーバに発行する。そのメタデータドキュメント１１４は、クライアント１２１に返され得、クライアント１２１は、そのメタデータドキュメント１１４のバージョン２１０を抽出し、次いで、データベースノード１２０への後続のトランザクション要求１２２にそのバージョン２１０を含め得る。
【0038】
次に図５を参照すると、方法５００のフロー図が示されている。方法５００は、コンピュータシステム（例えば、システム１００）によって実行される方法の一実施形態であり、この方法では、一組のレコード（例えば、レコード１１２）がトランザクションを処理することの一部としてアップグレードされる。方法５００は、非一時的コンピュータ可読媒体に記憶されたプログラム命令のセットを実行することによって実行され得る。いくつかの実施形態では、方法５００は、図示されるよりも多いまたは少ないステップを含む。例えば、方法５００は、コンピュータシステムがアップグレードされたレコードをデータベース（例えば、データベースストア１１０）に書き込むステップを含んでもよい。
【0039】
方法５００は、ステップ５１０において、コンピュータシステムが、複数のレコードを記憶するデータベースのための更新されたスキーマを記述するメタデータドキュメント（例えば、メタデータドキュメント１１４）を（例えば、クライアント１２１から）受信することから開始する。更新されたスキーマは、一組のデータベースエンティティ（例えば、データベースエンティティ２００）および対応する一組のステータス（例えば、ステータス２０５）を記述し得る。一組のステータスのステータスは、様々な実施形態では、対応するエンティティが要求（例えば、トランザクション要求１２２）の処理に使用可能であるかどうかを示す。一組のデータベースエンティティのうちの特定の１つのステータスを求めるステータス要求（例えば、スキーマ要求１２６）をクライアント（例えば、クライアント１２１）から受信したことに応答して、コンピュータシステムは、その特定のデータベースエンティティのステータスを示す応答（例えば、スキーマ応答１２８）を返し得る。様々な実施形態では、クライアントは、特定のデータベースエンティティをクライアントからの要求の処理に使用することができるかどうかを判定するために応答を使用するように動作可能である。
【0040】
ステップ５２０において、コンピュータシステムは、更新されたスキーマに準拠するように複数のレコードをアップグレードするためのアップグレードルーチンを実行するために、一組のプロセス（例えば、アップグレードプロセス１３７）をインスタンス化する。更新されたスキーマは、一組のデータベースエンティティに対する一組の更新を記述し得、一組のデータベースエンティティのうちの第１のデータベースエンティティは、第２のデータベースエンティティが利用可能になる前に第１のデータベースエンティティが、要求の処理に使用可能になるように、一組のデータベースエンティティのうちの第２のデータベースエンティティの前に移行され得る。
【0041】
ステップ５３０において、一組のプロセスが複数のレコードをアップグレードしている間に、コンピュータシステムは、複数のレコードのうちの１つに対して動作を実行する要求（例えば、トランザクション要求１２２）を受信する。要求は、複数の動作および／または複数のレコードを指定し得る。いくつかの実施形態では、要求は、受信された要求を処理する際に使用されるべき最小スキーマバージョンを指定する。コンピュータシステムは、コンピュータシステムのメモリ（例えば、インメモリキャッシュ１４０）に記憶されたスキーマが最小スキーマバージョンを満たさないことを検出し得る。そのため、コンピュータシステムは、メモリ内で、記憶されたスキーマを更新されたスキーマで置き換え得る。
【0042】
ステップ５４０において、コンピュータシステムは、レコードが、メタデータドキュメントの更新されたスキーマのバージョンよりも前のスキーマバージョンに対応することを検出する。ステップ５５０において、コンピュータシステムは、更新されたスキーマに準拠するようにレコードをアップグレードする。場合によっては、一組のデータベースエンティティのうちの１つはインデックスであってもよく、コンピュータシステムは、メタデータドキュメント内で、そのインデックスが基づくテーブルのステータスを更新してもよい。テーブルの更新されたステータスは、インデックスが作成されている間にテーブルが削除されることを防ぎ得る。場合によっては、更新されたスキーマは、前のスキーマバージョンに記述されていないインデックスを記述し得る。したがって、更新されたスキーマに準拠するようにレコードをアップグレードすることは、レコードのエントリをインデックスに投入することと、インデックスにエントリを投入した後に、更新されたスキーマのバージョンに一致するようにレコードのバージョン（例えば、バージョン２１０）を更新することとを含み得る。
【0043】
ステップ５６０において、レコードをアップグレードした後、コンピュータシステムは、レコードに対して要求された動作を実行する。場合によっては、レコードは、アップグレードされ、データベースに記憶されることなく要求の発行者に返されてもよい。そのため、レコードは、その後、一組のプロセスのうちの１つによってアップグレードされ、データベースに記憶され得る。一組のプロセスがアップグレードルーチンを完了した後、いくつかの実施形態では、コンピュータシステムは、複数のレコードのすべてが更新されたスキーマに準拠するようにアップグレードされたかどうかを判定するために一組の精査プロセスをインスタンス化し得る。
【0044】
次に図６を参照すると、方法６００のフロー図が示されている。方法６００は、コンピュータシステム（例えば、システム１００）によって実行される方法の一実施形態であり、この方法では、一組のレコード（例えば、レコード１１２）がトランザクションを処理することの一部としてアップグレードされる。方法６００は、非一時的コンピュータ可読媒体に記憶されたプログラム命令のセットを実行することによって実行され得る。いくつかの実施形態では、方法６００は、図示されるよりも多いまたは少ないステップを含む。例えば、方法６００は、コンピュータシステムがアップグレードされたレコードをデータベース（例えば、データベースストア１１０）に書き込むステップを含んでもよい。
【0045】
方法６００は、ステップ６１０において、コンピュータシステムが、複数のレコードを記憶するデータベースのための更新されたスキーマを記述するメタデータドキュメント（例えば、メタデータドキュメント１１４）を受信することから開始する。様々な実施形態では、コンピュータシステムは、更新されたスキーマに準拠するように複数のレコードをアップグレードするためのアップグレードルーチンを実行するために、一組のプロセス（例えば、アップグレードプロセス１３７）をインスタンス化する。更新されたスキーマは、一組のデータベースエンティティ（例えば、データベースエンティティ２００）および対応する一組のステータス（例えば、ステータス２０５）を記述し得る。コンピュータシステムは、一組のデータベースエンティティのうちの１つについて、データベースエンティティがアップグレードされていることを示すようにデータベースエンティティのステータスを設定し得る。いくつかの実施形態では、ステータスは、システムにデータベース要求を発行するように動作可能なクライアントによって観察可能である。
【0046】
ステップ６２０において、コンピュータシステムは、複数のレコードのうちの１つに対して動作を実行する要求（例えば、トランザクション要求１２２）を受信する。要求は、最小スキーマバージョンを指定し得、コンピュータシステムは、システムのキャッシュ（例えば、インメモリ１４０）にキャッシュされたスキーマのバージョンが最小スキーマバージョン未満であると判定し得、次いで、キャッシュにおいて、キャッシュされたスキーマを更新されたスキーマで置き換えることができる。
【0047】
ステップ６３０において、コンピュータシステムは、レコードが、メタデータドキュメントの更新されたスキーマのバージョンよりも前のスキーマバージョンに対応することを検出する。ステップ６４０において、コンピュータシステムは、更新されたスキーマに準拠するようにレコードをアップグレードする。場合によっては、更新されたスキーマは、データベースのデータベーステーブルに追加のフィールドを追加する。レコードは、テーブルに対応し得、したがって、レコードを更新することは、追加のフィールドの値を含むようにレコードを修正することと、更新されたスキーマのバージョンに一致するようにレコードのバージョン（例えば、バージョン２１０）を更新することとを含み得る。
【0048】
ステップ６５０において、レコードをアップグレードした後、コンピュータシステムは、レコードに対して要求された動作を実行する。場合によっては、要求された動作を実行することは、アップグレードされたレコードをデータベースから削除することを含む。コンピュータシステムは、複数のレコードのうちの異なるレコードに対して動作を実行する別の要求を受信し得る。別の要求は、最小スキーマバージョンを指定しなくてもよい。更新されたスキーマでそのキャッシュをリフレッシュする前に、コンピュータシステムは、更新されたスキーマのバージョンよりも前のスキーマバージョンに対応し得る異なるレコードをアップグレードすることなく、異なるレコードに対して別の要求の動作を実行し得る。
【0049】
例示的なマルチテナントデータベースシステム
次に図７を参照すると、本開示の様々な技法を実装することができる例示的なマルチテナントデータベースシステム（ＭＴＳ）７００が示されており、例えば、システム１００はＭＴＳ７００であり得る。図７において、ＭＴＳ７００は、データベースプラットフォーム７１０と、アプリケーションプラットフォーム７２０と、ネットワーク７４０に接続されたネットワークインターフェース７３０とを含む。また、図示のように、データベースプラットフォーム７１０は、データストレージ７１２と、データストレージ７１２と対話する一組のデータベースサーバ７１４Ａ～Ｎとを含み、アプリケーションプラットフォーム７２０は、それぞれの環境７２４を有する一組のアプリケーションサーバ７２２Ａ～Ｎを含む。図示の実施形態では、ＭＴＳ７００は、ネットワーク７４０を介して様々なユーザシステム７５０Ａ～Ｎに接続される。開示されたマルチテナントシステムは、例示の目的で含まれるものであり、本開示の範囲を限定することを意図するものではない。他の実施形態では、本開示の技法は、クライアント／サーバ環境、クラウドコンピューティング環境、クラスタ化されたコンピュータなどの非マルチテナント環境において実装される。
次に図７を参照すると、本開示の様々な技法を実装することができる例示的なマルチテナントデータベースシステム（ＭＴＳ）７００が示されており、例えば、システム１００はＭＴＳ７００であり得る。図７において、ＭＴＳ７００は、データベースプラットフォーム７１０と、アプリケーションプラットフォーム７２０と、ネットワーク７４０に接続されたネットワークインターフェース７３０とを含む。また、図示のように、データベースプラットフォーム７１０は、データストレージ７１２と、データストレージ７１２と対話する一組のデータベースサーバ７１４Ａ～Ｎとを含み、アプリケーションプラットフォーム７２０は、それぞれの環境７２４を有する一組のアプリケーションサーバ７２２Ａ～Ｎを含む。図示の実施形態では、ＭＴＳ７００は、ネットワーク７４０を介して様々なユーザシステム７５０Ａ～Ｎに接続される。開示されたマルチテナントシステムは、例示の目的で含まれるものであり、本開示の範囲を限定することを意図するものではない。他の実施形態では、本開示の技法は、クライアント／サーバ環境、クラウドコンピューティング環境、クラスタ化されたコンピュータなどの非マルチテナント環境において実装される。
【0050】
ＭＴＳ７００は、様々な実施形態では、ＭＴＳ７００と対話するユーザ（代替的に「テナント」と呼ばれる）に様々なサービスを一緒に提供する一組のコンピュータシステムである。いくつかの実施形態では、ＭＴＳ７００は、テナント（例えば、企業、政府機関など）が顧客および潜在的顧客との関係および対話を管理するための機構を提供する顧客関係管理（ＣＲＭ）システムを実装する。例えば、ＭＴＳ７００は、テナントが、顧客連絡先情報（例えば、顧客のウェブサイト、電子メールアドレス、電話番号、およびソーシャルメディアデータ）を記憶し、販売機会を識別し、サービス問題を記録し、マーケティングキャンペーンを管理することを可能にし得る。さらに、ＭＴＳ７００は、これらのテナントが、顧客とどのようにコミュニケーションをとったか、顧客が何を購入したか、顧客が最後にアイテムを購入したのはいつか、および顧客がいくら支払ったかを識別することを可能にし得る。ＣＲＭシステムのサービスおよび／または他のサービスを提供するために、図示のように、ＭＴＳ７００は、データベースプラットフォーム７１０およびアプリケーションプラットフォーム７２０を含む。
【0051】
データベースプラットフォーム７１０は、様々な実施形態では、テナントデータを含むＭＴＳ７００のデータを記憶および管理するためのデータベースサービスを実装するソフトウェアルーチンとハードウェア要素との組合せである。図示のように、データベースプラットフォーム７１０は、データストレージ７１２を含む。データストレージ７１２は、様々な実施形態では、ネットワーク（例えば、ストレージ接続ネットワーク（ＳＡＮ））上で互いに接続され、データ損失を防ぐためにデータを冗長的に記憶するように構成された一組のストレージデバイス（例えば、ソリッドステートドライブ、ハードディスクドライブなど）を含む。様々な実施形態では、データストレージ７１２は、情報のアクセス、記憶、および操作を可能にする方法で整理された情報の集合を含むデータベース（例えば、データベースストア１１０）を実装するために使用される。データストレージ７１２は、単一のデータベース、分散データベース、分散データベースの集合、冗長オンラインもしくはオフラインバックアップまたは他の冗長性を有するデータベースなどを実装し得る。データベースを実装することの一部として、データストレージ７１２は、それぞれのデータペイロード（例えば、データベーステーブルのフィールドの値）およびメタデータ（例えば、キー値、タイムスタンプ、レコードに関連付けられたテーブルのテーブル識別子、レコードに関連付けられたテナントのテナント識別子など）を有する１つまたは複数のデータベースレコードを含むファイルを記憶し得る。
【0052】
様々な実施形態では、データベースレコードは、テーブルの行に対応し得る。テーブルは一般に、閲覧可能なスキーマの列またはフィールドとして論理的に配置された１つまたは複数のデータカテゴリを含む。したがって、テーブルの各レコードは、フィールドによって定義された各カテゴリのデータのインスタンスを含み得る。例えば、データベースは、名前、住所、電話番号、ファックス番号などの基本的な連絡先情報のフィールドを有する顧客を記述するテーブルを含み得る。したがって、そのテーブルのレコードは、テーブル内のフィールドの各々についての値（例えば、名前フィールドの名前）を含み得る。別のテーブルは、顧客、製品、販売価格、日付などの情報のフィールドを含む発注書を記述し得る。様々な実施形態では、アカウント、連絡先、リード、および機会データのためのテーブルなどの標準エンティティテーブルが、すべてのテナントによる使用のために提供され、それぞれ、事前定義されたフィールドを含む。ＭＴＳ７００は、１つまたは複数のテナントについてのデータベースレコードを同じテーブルに記憶し得る。すなわち、テナントはテーブルを共有し得る。したがって、様々な実施形態では、データベースレコードは、データベースレコードの所有者を示すテナント識別子を含む。結果として、あるテナントのデータはセキュアに保たれ、他のテナントのデータから分離されるので、データが明示的に共有されない限り、あるテナントが別のテナントのデータにアクセスすることはできない。
【0053】
いくつかの実施形態では、データストレージ７１２に記憶されたデータは、ログ構造マージツリー（ＬＳＭツリー）の一部として整理される。ＬＳＭツリーは、通常、インメモリバッファおよび永続ストレージという２つの高レベル構成要素を含む。動作中、データベースサーバ７１４は、最初にデータベースレコードをローカルインメモリバッファに書き込み、その後、これらのレコードを永続ストレージ（例えば、データストレージ７１２）にフラッシュし得る。データベースレコードをフラッシュすることの一部として、データベースサーバ７１４は、ＬＳＭツリーの「トップ」レベルに含まれる新しいファイルにデータベースレコードを書き込み得る。時間の経過とともに、データベースレコードは、データベースレコードがＬＳＭツリーのレベルを下に移動するにつれて、データベースサーバ７１４によって、より低いレベルに含まれる新しいファイルに書き換えられ得る。様々な実装形態では、データベースレコードが古くなり、ＬＳＭツリーを下に移動されるにつれて、それらは、データストレージ７１２のますます低速のストレージデバイスに（例えば、ソリッドステートドライブからハードディスクドライブに）移動される。
【0054】
データベースサーバ７１４が特定のキーについてデータベースレコードにアクセスすることを望むとき、データベースサーバ７１４は、その特定のキーについてのデータベースレコードを潜在的に含むファイルについてＬＳＭツリーの異なるレベルをトラバースし得る。データベースサーバ７１４が、ファイルが関連データベースレコードを含み得ると決定すると、データベースサーバ７１４は、そのファイルをデータストレージ７１２からデータベースサーバ７１４のメモリにフェッチし得る。次いで、データベースサーバ７１４は、特定のキーを有するデータベースレコードについて、フェッチされたファイルをチェックし得る。様々な実施形態では、データベースレコードは、データストレージ７１２に書き込まれると不変である。したがって、データベースサーバ７１４が、（アクセスされたデータベースレコードから識別され得る）テーブルの行の値を修正することを望む場合、データベースサーバ７１４は、新しいデータベースレコードをＬＳＭツリーのトップレベルに書き出す。時間の経過とともに、そのデータベースレコードは、ＬＳＭツリーのレベルを下ってマージされる。したがって、ＬＳＭツリーは、データベースキーについての様々なデータベースレコードを記憶し得、そのキーについてのより古いデータベースレコードは、より新しいデータベースレコードよりもＬＳＭツリーの下位レベルに位置する。
【0055】
データベースサーバ７１４は、様々な実施形態では、データ記憶、データ取出し、および／またはデータ操作などのデータベースサービスを提供することが可能なハードウェア要素、ソフトウェアルーチン、またはそれらの組合せである。データベースサーバ７１４は、データベースノード１２０に対応し得る。そのようなデータベースサービスは、データベースサーバ７１４によって、ＭＴＳ７００内の構成要素（例えば、アプリケーションサーバ７２２）およびＭＴＳ７００の外部の構成要素に提供され得る。一例として、データベースサーバ７１４は、データストレージ７１２へのデータの書込みまたは読取りを要求しているアプリケーションサーバ７２２からデータベーストランザクション要求を受信し得る。データベーストランザクション要求は、ＳＱＬ ＳＥＬＥＣＴコマンドを指定して、１つまたは複数のデータベーステーブルから１つまたは複数の行を選択し得る。行のコンテンツは、データベースレコードにおいて定義され得、したがって、データベースサーバ７１４は、選択された１つまたは複数のテーブル行に対応する１つまたは複数のデータベースレコードを探し出し、返し得る。様々な場合において、データベーストランザクション要求は、データベースサーバ７１４に、ＬＳＭツリーのための１つまたは複数のデータベースレコードを書き込むように命令し得、データベースサーバ７１４は、データベースプラットフォーム７１０上に実装されたＬＳＭツリーを維持する。いくつかの実施形態では、データベースサーバ７１４は、データストレージ７１２に対する情報の記憶および取出しを容易にするリレーショナルデータベース管理システム（ＲＤＭＳ）またはオブジェクト指向データベース管理システム（ＯＯＤＢＭＳ）を実装する。様々な場合において、データベースサーバ７１４は、トランザクションの処理を容易にするために互いに通信し得る。例えば、データベースサーバ７１４Ａは、データベースサーバ７１４Ｎと通信して、データベースサーバ７１４Ｎが特定のキーについてデータベースレコードをそのインメモリバッファに書き込んだかどうかを決定する。
【0056】
アプリケーションプラットフォーム７２０は、様々な実施形態では、ＣＲＭソフトウェアアプリケーションを実装および実行するとともに、関連するデータ、コード、フォーム、ウェブページ、および他の情報をユーザシステム７５０との間で提供し、データベースプラットフォーム７１０を介して、関連するデータ、オブジェクト、ウェブページコンテンツ、および他のテナント情報を記憶するソフトウェアルーチンとハードウェア要素との組合せである。これらのサービスを容易にするために、様々な実施形態では、アプリケーションプラットフォーム７２０は、データベースプラットフォーム７１０と通信して、データを記憶、アクセス、および操作する。いくつかの事例では、アプリケーションプラットフォーム７２０は、異なるネットワーク接続を介してデータベースプラットフォーム７１０と通信し得る。例えば、あるアプリケーションサーバ７２２は、ローカルエリアネットワークを介して結合され得、別のアプリケーションサーバ７２２は、直接ネットワークリンクを介して結合され得る。ＴＣＰ／ＩＰ（Transfer Control Protocol and Internet Protocol）は、アプリケーションプラットフォーム７２０とデータベースプラットフォーム７１０との間で通信するための例示的なプロトコルであるが、使用されるネットワーク相互接続に応じて他のトランスポートプロトコルが使用され得ることは当業者には明らかであろう。
【0057】
アプリケーションサーバ７２２は、様々な実施形態では、ＭＴＳ７００のテナントから受信された要求を処理することを含む、アプリケーションプラットフォーム７２０のサービスを提供することが可能なハードウェア要素、ソフトウェアルーチン、またはそれらの組合せである。アプリケーションサーバ７２２は、様々な実施形態では、開発者がアプリケーション（例えば、ビジネスロジック）を開発、実行、および管理するための機能を提供する、などの様々な目的のために使用可能な環境７２４を生成し得る。データは、別の環境７２４および／またはデータベースプラットフォーム７１０から環境７２４に転送され得る。場合によっては、環境７２４は、他の環境７２４からのデータが明示的に共有されない限り、そのようなデータにアクセスすることができない。いくつかの実施形態では、複数の環境７２４を単一のテナントに関連付けることができる。
【0058】
アプリケーションプラットフォーム７２０は、ＣＲＭアプリケーションおよび／またはテナントによって開発されたアプリケーションを含む、複数の異なるホストされた（標準および／またはカスタム）アプリケーションへのアクセスをユーザシステム７５０に提供し得る。様々な実施形態では、アプリケーションプラットフォーム７２０は、アプリケーションの作成、アプリケーションの試験、データストレージ７１２におけるデータベースオブジェクトへのアプリケーションの記憶、環境７２４（例えば、プロセス空間の仮想マシン）におけるアプリケーションの実行、またはそれらの任意の組合せを管理し得る。いくつかの実施形態では、アプリケーションプラットフォーム７２０は、いかなる理由であれ、いつでもサーバプールからアプリケーションサーバ７２２を追加および除去し得、特定のアプリケーションサーバ７２２に対するユーザおよび／または組織のサーバ親和性はないことがある。いくつかの実施形態では、ロードバランシング機能を実装するインターフェースシステム（図示せず）（例えば、Ｆ５ Ｂｉｇ－ＩＰロードバランサ）が、アプリケーションサーバ７２２とユーザシステム７５０との間に位置し、要求をアプリケーションサーバ７２２に割り振るように構成される。いくつかの実施形態では、ロードバランサは、最小接続アルゴリズムを使用して、ユーザ要求をアプリケーションサーバ７２２にルーティングする。ラウンドロビンおよび観察レスポンスタイムなどのロードバランシングアルゴリズムの他の例を使用することもできる。例えば、特定の実施形態では、同じユーザからの３つの連続した要求が３つの異なるサーバ７２２にヒットすることがあり、異なるユーザからの３つの要求が同じサーバ７２２にヒットすることがある。
【0059】
いくつかの実施形態では、ＭＴＳ７００は、データが共有されない限り、各テナントのデータを別個に保つために、暗号化などのセキュリティ機構を提供する。２つ以上のサーバ７１４または７２２が使用される場合、それらは、互いに近接して（例えば、単一の建物またはキャンパスに位置するサーバファーム内に）位置してもよいし、互いに離れた場所に分散されていてもよい（例えば、都市Ａに位置する１つまたは複数のサーバ７１４および都市Ｂに位置する１つまたは複数のサーバ７２２）。したがって、ＭＴＳ７００は、ローカルに、または１つもしくは複数の地理的な位置にわたって分散された、１つまたは複数の論理的および／または物理的に接続されたサーバを含み得る。
【0060】
１人または複数人のユーザ（例えば、ユーザシステム７５０を介する）は、ネットワーク７４０を介してＭＴＳ７００と対話し得る。ユーザシステム７５０は、例えば、ＭＴＳ７００のテナント、ＭＴＳ７００のプロバイダ（例えば、管理者）、またはサードパーティに対応し得る。各ユーザシステム７５０は、デスクトップパーソナルコンピュータ、ワークステーション、ラップトップ、ＰＤＡ、携帯電話、または任意のワイヤレスアクセスプロトコル（ＷＡＰ）対応デバイス、またはインターネットもしくは他のネットワーク接続に直接もしくは間接的にインターフェースすることが可能な任意の他のコンピューティングデバイスであり得る。ユーザシステム７５０は、ネットワーク７４０を介してＭＴＳ７００とインターフェースするように構成された専用ハードウェアを含み得る。ユーザシステム７５０は、ＭＴＳ７００に対応するグラフィカルユーザーインターフェース（ＧＵＩ）、ＨＴＴＰクライアント（例えば、MicrosoftのInternet Explorer（登録商標）ブラウザ、NetscapeのNavigator（登録商標）ブラウザ、Ｏｐｅｒａのブラウザ、または形態電話、ＰＤＡ、もしくは他のワイヤレスデバイスの場合のＷＡＰ対応ブラウザなどのブラウジングプログラムなど）、またはその両方を実行することができ、ユーザシステム７５０のユーザ（例えば、ＣＲＭシステムの加入者）が、ネットワーク７４０を介してＭＴＳ７００から入手可能な情報およびページにアクセスし、処理し、閲覧することを可能にする。各ユーザシステム７５０は、ＭＴＳ７００または他のシステムもしくはサーバによって提供されるページ、フォーム、および他の情報とともに、ディスプレイモニタスクリーン、ＬＣＤディスプレイなどの上のブラウザによって提供されるグラフィカルユーザーインターフェース（ＧＵＩ）と対話するための、キーボード、マウス、タッチスクリーン、ペンなどの１つまたは複数のユーザインターフェースデバイスを含み得る。上述したように、開示された実施形態は、ネットワークの特定のグローバルインターネットワークを指すインターネットでの使用に適している。しかしながら、インターネットの代わりに、イントラネット、エクストラネット、仮想プライベートネットワーク（ＶＰＮ）、非ＴＣＰ／ＩＰベースのネットワーク、任意のＬＡＮまたはＷＡＮなどの他のネットワークが使用され得ることを理解されたい。
【0061】
ユーザシステム７５０のユーザは、異なる能力のユーザであり得るので、特定のユーザシステム７５０の能力は、現在のユーザに関連付けられた１つまたは複数の許可レベルで決定され得る。例えば、販売員が特定のユーザシステム７５０を使用してＭＴＳ７００と対話している場合、そのユーザシステム７５０は、その販売員に割り当てられた能力（例えば、ユーザ特権）を有し得る。しかしながら、管理者が同じユーザシステム７５０を使用してＭＴＳ７００と対話している場合、ユーザシステム７５０は、その管理者に割り当てられた能力（例えば、管理特権）を有し得る。階層的役割モデルを有するシステムでは、ある許可レベルのユーザは、より低い許可レベルのユーザがアクセス可能なアプリケーション、データ、およびデータベース情報にアクセスすることができるが、より高い許可レベルのユーザがアクセス可能な特定のアプリケーション、データベース情報、およびデータにアクセスすることはできない。したがって、異なるユーザは、ユーザのセキュリティまたは許可レベルに応じて、アプリケーションおよびデータベース情報にアクセスし、それを修正することに関して異なる能力を有し得る。ＭＴＳ７００によって管理されるデータ構造の中には、テナントレベルで割り振られるものもあれば、ユーザレベルで管理されるものもある。
【0062】
いくつかの実施形態では、ユーザシステム７５０およびその構成要素は、１つまたは複数の処理要素上で実行可能なコンピュータコードを含む、ブラウザなどのアプリケーションを使用して構成可能である。同様に、いくつかの実施形態では、ＭＴＳ７００（および２つ以上存在する場合にはＭＴＳの追加のインスタンス）およびそれらの構成要素は、処理要素上で実行可能なコンピュータコードを含むアプリケーション（複数可）を使用してオペレータが構成可能である。したがって、本明細書で説明する様々な動作は、非一時的コンピュータ可読媒体上に記憶され、処理要素によって実行されるプログラム命令を実行することによって実施され得る。プログラム命令は、ハードディスクのような不揮発性媒体に記憶されてもよいし、周知のように、ＲＯＭまたはＲＡＭのような他の揮発性または非揮発性メモリ媒体またはデバイスに記憶されてもよいし、コンパクトディスク（ＣＤ）媒体、デジタル多用途ディスク（ＤＶＤ）媒体、フロッピー（登録商標）ディスクなど、プログラムコードを開始することが可能な任意の媒体に提供されてもよい。追加的に、プログラムコード全体またはその一部は、周知のように、例えば、インターネットを介して、または別のサーバから、ソフトウェアソースから送信およびダウンロードされてもよいし、周知のように、任意の通信媒体およびプロトコル（例えば、ＴＣＰ／ＩＰ、ＨＴＴＰ、ＨＴＴＰＳ、イーサネット（登録商標）など）を使用して、周知のように、任意の他の従来のネットワーク接続（例えば、エクストラネット、ＶＰＮ、ＬＡＮなど）を介して送信されてもよい。開示された実施形態の態様を実装するためのコンピュータコードは、サーバまたはサーバシステム上で実行することができる任意のプログラム言語、例えば、Ｃ、Ｃ＋＋、ＨＴＭＬ、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ（登録商標）、またはＶＢＳｃｒｉｐｔなどの任意の他のスクリプト言語で実装することができることも理解されよう。
【0063】
ネットワーク７４０は、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）、ワイヤレスネットワーク、ポイントツーポイントネットワーク、スター型ネットワーク、トークンリングネットワーク、ハブネットワーク、または任意の他の適切な構成であり得る。ネットワークのグローバルインターネットワークは、大文字の「Ｉ」を有する「インターネット」と呼ばれることが多く、ＴＣＰ／ＩＰ（Transfer Control Protocol and Internet Protocol）ネットワークの一例である。しかしながら、開示された実施形態は、様々な他の種類のネットワークのいずれかを利用し得ることを理解されたい。
【0064】
ユーザシステム７５０は、ＴＣＰ／ＩＰを使用してＭＴＳ７００と通信し得、より高いネットワークレベルでは、ＨＴＴＰ、ＦＴＰ、ＡＦＳ、ＷＡＰなどの他の一般的なインターネットプロトコルを使用して通信し得る。例えば、ＨＴＴＰが使用される場合、ユーザシステム７５０は、ＭＴＳ７００のＨＴＴＰサーバからＨＴＴＰメッセージを送受信するための、一般に「ブラウザ」と呼ばれるＨＴＴＰクライアントを含み得る。そのようなサーバは、ＭＴＳ７００とネットワーク７４０との間の唯一のネットワークインターフェースとして実装され得るが、他の技法が同様にまたは代わりに使用されてもよい。いくつかの実装形態では、ＭＴＳ７００とネットワーク７４０との間のインターフェースは、負荷を平衡させ、到来するＨＴＴＰ要求を複数のサーバにわたって均等に分配するためのラウンドロビンＨＴＴＰ要求分配器などのロードシェア機能を含む。
【0065】
様々な実施形態では、ユーザシステム７５０は、アプリケーションサーバ７２２と通信して、データストレージ７１２への１つまたは複数のクエリを必要とし得るＭＴＳ７００からのシステムレベルおよびテナントレベルのデータを要求および更新する。いくつかの実施形態では、ＭＴＳ７００は、所望の情報にアクセスするように設計された１つまたは複数のＳＱＬステートメント（ＳＱＬクエリ）を自動的に生成する。場合によっては、ユーザシステム７５０は、ＭＴＳ７００の少なくとも一部に対応する特定のフォーマットを有する要求を生成してもよい。一例として、ユーザシステム７５０は、指定された複数のオブジェクトのオブジェクト関係マッピング（例えば、ＪａｖａＳｃｒｉｐｔ（登録商標）オブジェクト表記マッピング）を記述するオブジェクト表記を使用して、データオブジェクトを特定の環境７２４に移動するように要求し得る。
【0066】
例示的なコンピュータシステム
ここで図８を参照すると、システム１００、データベース１１０、データベースノード１２０、ＭＴＳ７００、および／またはユーザシステム７５０を実装し得る例示的なコンピュータシステム８００のブロック図が示されている。コンピュータシステム８００は、相互接続８６０（例えば、システムバス）を介してシステムメモリ８２０およびＩ／Ｏインターフェース（複数可）８４０に結合されたプロセッササブシステム８８０を含む。Ｉ／Ｏインターフェース（複数可）８４０は、１つまたは複数のＩ／Ｏデバイス８５０に結合される。便宜上、図８には単一のコンピュータシステム８００が示されているが、システム８００は、一緒に動作する２つ以上のコンピュータシステムとして実装されてもよい。
ここで図８を参照すると、システム１００、データベース１１０、データベースノード１２０、ＭＴＳ７００、および／またはユーザシステム７５０を実装し得る例示的なコンピュータシステム８００のブロック図が示されている。コンピュータシステム８００は、相互接続８６０（例えば、システムバス）を介してシステムメモリ８２０およびＩ／Ｏインターフェース（複数可）８４０に結合されたプロセッササブシステム８８０を含む。Ｉ／Ｏインターフェース（複数可）８４０は、１つまたは複数のＩ／Ｏデバイス８５０に結合される。便宜上、図８には単一のコンピュータシステム８００が示されているが、システム８００は、一緒に動作する２つ以上のコンピュータシステムとして実装されてもよい。
【0067】
プロセッササブシステム８８０は、１つまたは複数のプロセッサまたは処理ユニットを含み得る。コンピュータシステム８００の様々な実施形態では、プロセッササブシステム８８０の複数のインスタンスが相互接続８６０に結合され得る。様々な実施形態では、プロセッササブシステム８８０（または８８０内の各プロセッサユニット）は、キャッシュまたは他の形態のオンボードメモリを含み得る。
【0068】
システムメモリ８２０は、システム８００に本明細書で説明される様々な動作を実行させるために、プロセッササブシステム８８０によって実行可能なプログラム命令を記憶するのに使用可能である。システムメモリ８２０は、ハードディスクストレージ、フロッピー（登録商標）ディスクストレージ、リムーバブルディスクストレージ、フラッシュメモリ、ランダムアクセスメモリ（ＲＡＭ－ＳＲＡＭ、ＥＤＯ ＲＡＭ、ＳＤＲＡＭ、ＤＤＲ ＳＤＲＡＭ、ＲＡＭＢＵＳ ＲＡＭなど）、読取り専用メモリ（ＰＲＯＭ、ＥＥＰＲＯＭなど）などの異なる物理メモリ媒体を使用して実装され得る。コンピュータシステム８００内のメモリは、メモリ８２０などの一次ストレージに限定されない。むしろ、コンピュータシステム８００はまた、プロセッササブシステム８８０内のキャッシュメモリおよびＩ／Ｏデバイス８５０上の二次ストレージ（例えば、ハードドライブ、ストレージアレイなど）などの他の形態のストレージを含み得る。いくつかの実施形態では、これらの他の形態のストレージはまた、プロセッササブシステム８８０によって実行可能なプログラム命令を記憶し得る。いくつかの実施形態では、実行されると、データベースアプリケーション１３０を実装するプログラム命令が、システムメモリ８２０内に含まれてもよい／記憶されてもよい。
【0069】
Ｉ／Ｏインターフェース８４０は、様々な実施形態によれば、他のデバイスに結合し、他のデバイスと通信するように構成された様々な種類のインターフェースのいずれかであり得る。一実施形態では、Ｉ／Ｏインターフェース８４０は、フロントサイドから１つまたは複数のバックサイドバスへのブリッジチップ（例えば、サウスブリッジ）である。Ｉ／Ｏインターフェース８４０は、１つまたは複数の対応するバスまたは他のインターフェースを介して１つまたは複数のＩ／Ｏデバイス８５０に結合され得る。Ｉ／Ｏデバイス８５０の例には、ストレージデバイス（ハードドライブ、光学ドライブ、リムーバブルフラッシュドライブ、ストレージアレイ、ＳＡＮ、またはそれらの関連コントローラ）、（例えば、ローカルまたはワイドエリアネットワークへの）ネットワークインターフェースデバイス、または他のデバイス（例えば、グラフィックス、ユーザインターフェースデバイスなど）が含まれる。一実施形態では、コンピュータシステム８００は、（例えば、ＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、イーサネット（登録商標）などを介して通信するように構成された）ネットワークインターフェースデバイス８５０を介してネットワークに結合される。
【0070】
本出願の主題の実現形態は、以下の例１～２０を含むが、これらに限定されない。
＜１＞方法であって、
コンピュータシステムによって、複数のレコードを記憶するデータベースの更新されたスキーマを記述するメタデータドキュメントを受信するステップと、
コンピュータシステムによって、更新されたスキーマに準拠するように複数のレコードをアップグレードするためのアップグレードルーチンを実行するための一組のプロセスをインスタンス化するステップと、
一組のプロセスが複数のレコードをアップグレードしている間に、コンピュータシステムが、
複数のレコードのうちの１つに対して動作を実行する要求を受信するステップと、
レコードが、メタデータドキュメントの更新されたスキーマのバージョンよりも前のスキーマバージョンに対応することを検出するステップと、
更新されたスキーマに準拠するようにレコードをアップグレードするステップと、
レコードをアップグレードした後に、レコードに対して要求された動作を実行するステップと
を含む方法。
＜２＞更新されたスキーマは、一組のデータベースエンティティおよび対応する一組のステータスを記述し、一組のステータスのステータスは、対応するエンティティを、要求の処理に使用することができるかどうかを示す、例１の方法。
＜３＞一組のデータベースエンティティのうちの特定のデータベースエンティティのステータスを求めるステータス要求をクライアントから受信したことに応答して、コンピュータシステムが、特定のデータベースエンティティのステータスを示す応答を返すステップであって、クライアントは、特定のデータベースエンティティをクライアントからの要求の処理に使用することができるかどうかを判定するために応答を使用するように動作可能である、ステップ
をさらに含む、例２の方法。
＜４＞一組のデータベースエンティティのうちの１つはインデックスであり、方法は、
コンピュータシステムによって、メタデータドキュメント内で、インデックスが基づくテーブルのステータスを更新するステップであって、テーブルの更新されたステータスは、インデックスが作成されている間にテーブルが削除されることを防ぐ、ステップ
をさらに含む、例２の方法。
＜５＞更新されたスキーマは、前のスキーマバージョンに記述されていないインデックスを記述し、更新されたスキーマに準拠するようにレコードをアップグレードするステップは、
レコードのエントリをインデックスに投入するステップと、
インデックスにエントリを投入した後に、更新されたスキーマのバージョンに一致するようにレコードのバージョンを更新するステップと
を含む、例１の方法。
＜６＞要求は、受信された要求を処理する際に使用されるべき最小スキーマバージョンを指定し、方法は、
コンピュータシステムによって、コンピュータシステムのメモリに記憶されたスキーマが最小スキーマバージョンを満たさないことを検出するステップと、
メモリ内で、記憶されたスキーマを更新されたスキーマで置き換えるステップと
をさらに含む、例１の方法。
＜７＞更新されたスキーマは、一組のデータベースエンティティに対する一組の更新を記述し、一組のデータベースエンティティのうちの第１のデータベースエンティティは、第１のデータベースエンティティが第２のデータベースエンティティの前に使用可能となるように、一組のデータベースエンティティのうちの第２のデータベースエンティティの前に移行される、例１の方法。
＜８＞レコードは、アップグレードされ、データベースに記憶されることなく要求の発行者に返され、レコードは、その後、一組のプロセスのうちの１つによってアップグレードされ、データベースに記憶される、例１の方法。
＜９＞一組のプロセスがアップグレードルーチンを実行した後に、コンピュータシステムが、複数のレコードのすべてが更新されたスキーマに準拠するようにアップグレードされたかどうかを判定するために一組の精査プロセスをインスタンス化するステップ
をさらに含む、例１の方法。
＜１０＞コンピュータシステムに動作を実行させるためにコンピュータシステムによって実行可能なプログラム命令を記憶した非一時的コンピュータ可読媒体であって、動作は、
複数のレコードを記憶するデータベースの更新されたスキーマを記述するメタデータドキュメントを受信することと、
更新されたスキーマに準拠するように複数のレコードをアップグレードするためのアップグレードルーチンを実行するための一組のプロセスをインスタンス化することと、
複数のレコードのうちの１つに対して動作を実行する要求を受信することと、
レコードが、メタデータドキュメントの更新されたスキーマのバージョンよりも前のスキーマバージョンに対応することを検出することと、
更新されたスキーマに準拠するようにレコードをアップグレードすることと、
レコードをアップグレードした後に、レコードに対して要求された動作を実行することと
を含む、媒体。
＜１１＞要求は、受信された要求を処理する際に使用されるべき最小スキーマバージョンを指定し、動作は、
コンピュータシステムのインメモリキャッシュにキャッシュされたスキーマが最小スキーマバージョンを満たさないことを検出することと、
インメモリキャッシュ内で、キャッシュされたスキーマを更新されたスキーマで置き換えることと
をさらに含む、例１０の媒体。
＜１２＞動作は、
複数のレコードのうちの異なるレコードに対して動作を実行する別の要求を受信することであって、別の要求は、最小スキーマバージョンを指定しない、受信することと、
異なるレコードをアップグレードすることなく、異なるレコードに対して別の要求の動作を実行することであって、異なるレコードは、更新されたスキーマのバージョンよりも前のスキーマバージョンに対応する、実行することと
をさらに含む、例１０の媒体。
＜１３＞要求された動作を実行することは、アップグレードされたレコードをデータベースから削除することを含む、例１０の媒体。
＜１４＞動作は、
更新されたスキーマに記述されたデータベースエンティティのステータスを識別するステータス情報を維持することと、
データベースエンティティに関連付けられたレコードをアップグレードすることに応答して、データベースエンティティを要求の処理に使用することができることを示すようにステータスを更新することと
をさらに含む、例１０の媒体。
＜１５＞動作は、
一組のプロセスがアップグレードルーチンを実行した後に、複数のレコードのうちのいくつかが更新されたスキーマに準拠するようにアップグレードされたかどうかを判定するために一組の精査プロセスをインスタンス化すること
をさらに含む、例１０の媒体。
＜１６＞システムであって、
少なくとも１つのプロセッサと、
システムに動作を実行させるために少なくとも１つのプロセスによって実行可能であるプログラム命令を記憶したメモリと
を備え、動作は、
複数のレコードを記憶するデータベースのための更新されたスキーマを記述するメタデータドキュメントを受信することと、
複数のレコードのうちの１つに対して動作を実行する要求を受信することと、
レコードが、メタデータドキュメントの更新されたスキーマのバージョンよりも前のスキーマバージョンに対応することを検出することと、
更新されたスキーマに準拠するようにレコードをアップグレードすることと、
レコードをアップグレードした後に、レコードに対して要求された動作を実行することと
を含む、システム。
＜１７＞要求は、最小スキーマバージョンを指定し、動作は、
システムのキャッシュにキャッシュされたデータベースのスキーマのバージョンが最小スキーマバージョン未満であると判定することと、
キャッシュ内で、キャッシュされたスキーマを更新されたスキーマで置き換えることと
をさらに含む、例１６のシステム。
＜１８＞更新されたスキーマは、データベースのテーブルに追加のフィールドを追加し、レコードは、テーブルに対応し、レコードを更新することは、
追加のフィールドの値を含むようにレコードを修正することと、
更新されたスキーマのバージョンに一致するようにレコードのバージョンを更新することと
を含む、例１６のシステム。
＜１９＞更新されたスキーマは、一組のデータベースエンティティおよび対応する一組のステータスを記述し、動作は、
一組のデータベースエンティティの１つについて、データベースエンティティがアップグレードされていることを示すためにデータベースエンティティのステータスを設定することであって、ステータスは、システムにデータベース要求を発行するように動作可能なクライアントによって観察可能である、設定すること
をさらに含む、例１６のシステム。
＜２０＞動作は、
更新されたスキーマに準拠するように複数のレコードをアップグレードするためのアップグレードルーチンを実行するための一組のプロセスをインスタンス化すること
をさらに含む、例１６のシステム。
＜１＞方法であって、
コンピュータシステムによって、複数のレコードを記憶するデータベースの更新されたスキーマを記述するメタデータドキュメントを受信するステップと、
コンピュータシステムによって、更新されたスキーマに準拠するように複数のレコードをアップグレードするためのアップグレードルーチンを実行するための一組のプロセスをインスタンス化するステップと、
一組のプロセスが複数のレコードをアップグレードしている間に、コンピュータシステムが、
複数のレコードのうちの１つに対して動作を実行する要求を受信するステップと、
レコードが、メタデータドキュメントの更新されたスキーマのバージョンよりも前のスキーマバージョンに対応することを検出するステップと、
更新されたスキーマに準拠するようにレコードをアップグレードするステップと、
レコードをアップグレードした後に、レコードに対して要求された動作を実行するステップと
を含む方法。
＜２＞更新されたスキーマは、一組のデータベースエンティティおよび対応する一組のステータスを記述し、一組のステータスのステータスは、対応するエンティティを、要求の処理に使用することができるかどうかを示す、例１の方法。
＜３＞一組のデータベースエンティティのうちの特定のデータベースエンティティのステータスを求めるステータス要求をクライアントから受信したことに応答して、コンピュータシステムが、特定のデータベースエンティティのステータスを示す応答を返すステップであって、クライアントは、特定のデータベースエンティティをクライアントからの要求の処理に使用することができるかどうかを判定するために応答を使用するように動作可能である、ステップ
をさらに含む、例２の方法。
＜４＞一組のデータベースエンティティのうちの１つはインデックスであり、方法は、
コンピュータシステムによって、メタデータドキュメント内で、インデックスが基づくテーブルのステータスを更新するステップであって、テーブルの更新されたステータスは、インデックスが作成されている間にテーブルが削除されることを防ぐ、ステップ
をさらに含む、例２の方法。
＜５＞更新されたスキーマは、前のスキーマバージョンに記述されていないインデックスを記述し、更新されたスキーマに準拠するようにレコードをアップグレードするステップは、
レコードのエントリをインデックスに投入するステップと、
インデックスにエントリを投入した後に、更新されたスキーマのバージョンに一致するようにレコードのバージョンを更新するステップと
を含む、例１の方法。
＜６＞要求は、受信された要求を処理する際に使用されるべき最小スキーマバージョンを指定し、方法は、
コンピュータシステムによって、コンピュータシステムのメモリに記憶されたスキーマが最小スキーマバージョンを満たさないことを検出するステップと、
メモリ内で、記憶されたスキーマを更新されたスキーマで置き換えるステップと
をさらに含む、例１の方法。
＜７＞更新されたスキーマは、一組のデータベースエンティティに対する一組の更新を記述し、一組のデータベースエンティティのうちの第１のデータベースエンティティは、第１のデータベースエンティティが第２のデータベースエンティティの前に使用可能となるように、一組のデータベースエンティティのうちの第２のデータベースエンティティの前に移行される、例１の方法。
＜８＞レコードは、アップグレードされ、データベースに記憶されることなく要求の発行者に返され、レコードは、その後、一組のプロセスのうちの１つによってアップグレードされ、データベースに記憶される、例１の方法。
＜９＞一組のプロセスがアップグレードルーチンを実行した後に、コンピュータシステムが、複数のレコードのすべてが更新されたスキーマに準拠するようにアップグレードされたかどうかを判定するために一組の精査プロセスをインスタンス化するステップ
をさらに含む、例１の方法。
＜１０＞コンピュータシステムに動作を実行させるためにコンピュータシステムによって実行可能なプログラム命令を記憶した非一時的コンピュータ可読媒体であって、動作は、
複数のレコードを記憶するデータベースの更新されたスキーマを記述するメタデータドキュメントを受信することと、
更新されたスキーマに準拠するように複数のレコードをアップグレードするためのアップグレードルーチンを実行するための一組のプロセスをインスタンス化することと、
複数のレコードのうちの１つに対して動作を実行する要求を受信することと、
レコードが、メタデータドキュメントの更新されたスキーマのバージョンよりも前のスキーマバージョンに対応することを検出することと、
更新されたスキーマに準拠するようにレコードをアップグレードすることと、
レコードをアップグレードした後に、レコードに対して要求された動作を実行することと
を含む、媒体。
＜１１＞要求は、受信された要求を処理する際に使用されるべき最小スキーマバージョンを指定し、動作は、
コンピュータシステムのインメモリキャッシュにキャッシュされたスキーマが最小スキーマバージョンを満たさないことを検出することと、
インメモリキャッシュ内で、キャッシュされたスキーマを更新されたスキーマで置き換えることと
をさらに含む、例１０の媒体。
＜１２＞動作は、
複数のレコードのうちの異なるレコードに対して動作を実行する別の要求を受信することであって、別の要求は、最小スキーマバージョンを指定しない、受信することと、
異なるレコードをアップグレードすることなく、異なるレコードに対して別の要求の動作を実行することであって、異なるレコードは、更新されたスキーマのバージョンよりも前のスキーマバージョンに対応する、実行することと
をさらに含む、例１０の媒体。
＜１３＞要求された動作を実行することは、アップグレードされたレコードをデータベースから削除することを含む、例１０の媒体。
＜１４＞動作は、
更新されたスキーマに記述されたデータベースエンティティのステータスを識別するステータス情報を維持することと、
データベースエンティティに関連付けられたレコードをアップグレードすることに応答して、データベースエンティティを要求の処理に使用することができることを示すようにステータスを更新することと
をさらに含む、例１０の媒体。
＜１５＞動作は、
一組のプロセスがアップグレードルーチンを実行した後に、複数のレコードのうちのいくつかが更新されたスキーマに準拠するようにアップグレードされたかどうかを判定するために一組の精査プロセスをインスタンス化すること
をさらに含む、例１０の媒体。
＜１６＞システムであって、
少なくとも１つのプロセッサと、
システムに動作を実行させるために少なくとも１つのプロセスによって実行可能であるプログラム命令を記憶したメモリと
を備え、動作は、
複数のレコードを記憶するデータベースのための更新されたスキーマを記述するメタデータドキュメントを受信することと、
複数のレコードのうちの１つに対して動作を実行する要求を受信することと、
レコードが、メタデータドキュメントの更新されたスキーマのバージョンよりも前のスキーマバージョンに対応することを検出することと、
更新されたスキーマに準拠するようにレコードをアップグレードすることと、
レコードをアップグレードした後に、レコードに対して要求された動作を実行することと
を含む、システム。
＜１７＞要求は、最小スキーマバージョンを指定し、動作は、
システムのキャッシュにキャッシュされたデータベースのスキーマのバージョンが最小スキーマバージョン未満であると判定することと、
キャッシュ内で、キャッシュされたスキーマを更新されたスキーマで置き換えることと
をさらに含む、例１６のシステム。
＜１８＞更新されたスキーマは、データベースのテーブルに追加のフィールドを追加し、レコードは、テーブルに対応し、レコードを更新することは、
追加のフィールドの値を含むようにレコードを修正することと、
更新されたスキーマのバージョンに一致するようにレコードのバージョンを更新することと
を含む、例１６のシステム。
＜１９＞更新されたスキーマは、一組のデータベースエンティティおよび対応する一組のステータスを記述し、動作は、
一組のデータベースエンティティの１つについて、データベースエンティティがアップグレードされていることを示すためにデータベースエンティティのステータスを設定することであって、ステータスは、システムにデータベース要求を発行するように動作可能なクライアントによって観察可能である、設定すること
をさらに含む、例１６のシステム。
＜２０＞動作は、
更新されたスキーマに準拠するように複数のレコードをアップグレードするためのアップグレードルーチンを実行するための一組のプロセスをインスタンス化すること
をさらに含む、例１６のシステム。
【0071】
本開示は、開示された概念の非限定的な実装形態である「実施形態」への言及を含む。「実施形態」、「一実施形態」、「特定の実施形態」、「いくつかの実施形態」、「様々な実施形態」などへの言及は、必ずしも同じ実施形態を指すとは限らない。詳細に説明される特定の実施形態、ならびに本開示の趣旨または範囲内に入る修正形態または代替形態を含む、多数の可能な実施形態が企図される。すべての実施形態が、本明細書に記載される潜在的な利点のいずれかまたはすべてを必ずしも明示するわけではない。
【0072】
本開示は、開示された実施形態から生じ得る潜在的な利点を説明し得る。これらの実施形態のすべての実装形態が、潜在的な利点のいずれかまたはすべてを必ずしも明示するわけではない。特定の実装形態について利点が実現されるかどうかは、多くの要因に依存し、それらのうちのいくつかは、本開示の範囲外である。実際に、特許請求の範囲に含まれる実装形態が、開示された利点の一部または全部を示さないことがあるのには、いくつかの理由がある。例えば、特定の実装形態は、開示される実施形態のうちの１つとともに、開示される利点のうちの１つまたは複数を無効にするかまたは減少させる、本開示の範囲外の他の回路を含む可能性がある。さらに、特定の実装形態（例えば、実装技法またはツール）の準最適な設計実行も、開示された利点を無効にするかまたは減少させる可能性がある。熟練した実装を想定しても、利点の実現は、依然として、実装形態が展開される環境状況などの他の要因に依存し得る。例えば、特定の実装形態に供給される入力は、本開示で対処される１つまたは複数の問題が特定の場合に発生することを防止し得、その結果、その解決策の利益が実現されないことがある。本開示の外部の可能な要因の存在を考慮すると、本明細書に記載される任意の潜在的な利点は、侵害を実証するために満たされなければならない特許請求の範囲の限定として解釈されるべきではないことが明確に意図される。むしろ、そのような潜在的な利点の識別は、本開示の利益を有する設計者に利用可能な改善のタイプ（複数可）を例示することを意図している。そのような利点が許容的に説明される（例えば、特定の利点が「生じ得る」と述べる）ことは、そのような利点が実際に実現され得るかどうかについての疑いを伝えることを意図するものではなく、むしろ、そのような利点の実現がしばしば追加の要因に依存するという技術的現実を認識することを意図するものである。
【0073】
別段の記載がない限り、実施形態は非限定的である。すなわち、開示される実施形態は、特定の特徴に関して単一の例のみが記載されている場合であっても、本開示に基づいて起草される特許請求の範囲を限定することを意図するものではない。開示された実施形態は、制限的ではなく例示的であることが意図されており、それとは反対のいかなる記述も本開示には存在しない。したがって、本出願は、開示された実施形態、ならびに本開示の利益を有する当業者には明らかであろうそのような代替形態、修正形態、および均等物をカバーする特許請求の範囲を可能にすることが意図される。
【0074】
例えば、本出願における特徴は、任意の適切な方法で組み合わされてもよい。したがって、本出願（またはそれに対する優先権を主張する出願）の審査中に、特徴の任意のそのような組合せに対して新しい請求項が策定され得る。特に、添付の特許請求の範囲を参照すると、従属請求項からの特徴は、必要に応じて、他の独立請求項に従属する請求項を含む他の従属請求項の特徴と組み合わされ得る。同様に、それぞれの独立請求項からの特徴は、必要に応じて組み合わされ得る。
【0075】
したがって、添付の従属請求項は、各々が単一の他の請求項に従属するように起草され得るが、追加の従属性も企図される。本開示と一致する従属項における特徴の任意の組合せが企図され、本出願または別の出願において特許請求され得る。要するに、組合せは、添付の特許請求の範囲に具体的に列挙されたものに限定されない。
【0076】
必要に応じて、１つの形式または法定タイプ（例えば、装置）で起草された請求項は、別の形式または法定タイプ（例えば、方法）の対応する請求項をサポートするように意図されていることも企図される。
【0077】
本開示は法的文書であるため、様々な用語および表現は、行政上および司法上の解釈の対象となり得る。以下の段落および本開示全体を通して提供される定義が、本開示に基づいて起草される特許請求の範囲をどのように解釈するかを決定する際に使用されるべきであるという公示が、本明細書によって与えられる。
【0078】
項目の単数形（すなわち、「a」、「an」、または「the」が先行する名詞または名詞句）への言及は、文脈が別途明確に指示しない限り、「１つまたは複数」を意味することが意図される。したがって、特許請求の範囲中の「ある項目」への言及は、付随する文脈がなければ、その項目の追加的な事例を排除するものではない。「複数の」項目は、２つ以上の項目のセットを指す。
【0079】
「場合がある／可能性がある／してもよい／し得る（may）」という単語は、本明細書では、強制的な意味（すなわち、～しなければならない）ではなく、許容的な意味（すなわち、する可能性を有する、することが可能である）で使用される。
【0080】
「備える／含む（comprising）」および「含む（including）」という用語、ならびにその形態は、オープンエンドであり、「含むが、これらに限定されない」を意味する。
【0081】
「または（or）」という用語が選択肢のリストに関して本開示で使用されるとき、それは、一般に、文脈が別段に規定しない限り、包括的な意味で使用されるものと理解されよう。したがって、「ｘまたはｙ」という記載は、「ｘもしくはｙ、または両方」と同等であり、したがって、１）ｙではなくｘ、２）ｘではなくｙ、および３）ｘおよびｙの両方、をカバーする。一方、「ｘまたはｙのいずれかであるが、両方ではない」などの表現は、「または」が排他的な意味で使用されていることを明らかにする。
【0082】
「ｗ、ｘ、ｙ、もしくはｚ、またはそれらの任意の組合せ」または「…ｗ、ｘ、ｙ、およびｚのうちの少なくとも１つ」という記載は、集合中の要素の総数までの単一の要素を含むすべての可能性をカバーするものとする。例えば、集合［ｗ，ｘ，ｙ，ｚ］が与えられると、これらの言い回しは、集合の任意の単一の要素（例えば、ｗであるが、ｘ、ｙ、またはｚではない）、任意の２つの要素（例えば、ｗおよびｘであるが、ｙまたはｚではない）、任意の３つの要素（例えば、ｗ、ｘ、およびｙであるが、ｚではない）、および４つすべての要素、をカバーする。したがって、「…ｗ、ｘ、ｙ、およびｚのうちの少なくとも１つ」という表現は、集合［ｗ，ｘ，ｙ，ｚ］の少なくとも１つの要素を指し、それによって、この要素のリスト中のすべての可能な組合せをカバーする。この表現は、ｗの少なくとも１つのインスタンス、ｘの少なくとも１つのインスタンス、ｙの少なくとも１つのインスタンス、およびｚの少なくとも１つのインスタンスが存在することを必要とすると解釈されるべきではない。
【0083】
本開示では、様々な「ラベル」が名詞または名詞句に先行し得る。文脈が別段に規定しない限り、特徴のために使用される異なるラベル（例えば、「第１の回路」、「第２の回路」、「特定の回路」、「所与の回路」など）は、特徴の異なるインスタンスを指す。追加的に、「第１の」、「第２の」、および「第３の」というラベルは、特徴に適用されるとき、別段の記載がない限り、いかなるタイプの順序付け（例えば、空間的、時間的、論理的など）も暗示しない。
【0084】
「に基づく」という表現は、決定に影響を及ぼす１つまたは複数の要因を説明するために使用される。この用語は、追加の要因が決定に影響を及ぼす可能性を排除するものではない。すなわち、決定は、指定された要因のみに基づいてもよく、または指定された要因ならびに他の指定されていない要因に基づき得る。「Ｂに基づいてＡを決定する」という表現について考える。この表現は、Ｂが、Ａを決定するために使用されるか、またはＡの決定に影響を及ぼす要因であることを指定する。この表現は、Ａの決定がＣのような何らかの他の要因に基づく可能性があることを排除しない。この表現はまた、ＡがＢのみに基づいて決定される実施形態をカバーすることが意図される。本明細書で使用される場合、「に基づく」という表現は、「に少なくとも部分的に基づく」という表現と同義である。
【0085】
「に応答して（in response to）」および「に応えて（responsive to）」という表現は、効果を引き起こす１つまたは複数の要因を説明する。この表現は、追加の要因が、指定された要因と共同して、または指定された要因から独立して、効果に影響を及ぼすか、またはそうでなければ効果を誘発し得る可能性を排除しない。すなわち、効果は、これらの要因のみに応答したものであってもよいし、特定された要因および他の特定されていない要因に応答したものであってもよい。「Ｂに応答してＡを実行する」という表現について考える。この表現は、Ｂが、Ａの実行をトリガする、またはＡの特定の結果をトリガする要因であることを指定する。この表現は、Ａを実行することが、Ｃなどの何らかの他の要因に応答して行われる可能性があることを排除しない。この表現はまた、Ａを実行することがＢおよびＣに共同で応答して行われる可能性があることを排除しない。この表現はまた、ＡがＢのみに応答して実行される実施形態をカバーすることも意図している。本明細書で使用される場合、「に応じて」という表現は、「に少なくとも部分的に応じて」という表現と同義である。同様に、「に応答して」という表現は、「に少なくとも部分的に応答して」という表現と同義である。
【0086】
本開示内で、（「ユニット」、「回路」、他の構成要素などと様々に呼ばれることがある）異なるエンティティが、１つまたは複数のタスクまたは動作を実行するように「構成される」ものとして説明または請求され得る。この定式化－［１つまたは複数のタスクを実行する］ように構成された［エンティティ］－は、本明細書では、構造（すなわち、何か物理的なもの）を指すために使用される。より具体的には、この定式化は、この構造が動作中に１つまたは複数のタスクを実行するように構成されることを示すために使用される。構造は、その構造が現在動作していない場合であっても、何らかのタスクを実行するように「構成されている」と言うことができる。したがって、何らかのタスクを実行する「ように構成される」ものとして説明または列挙されるエンティティは、デバイス、回路、タスクを実施するために実行可能なプログラム命令を記憶するメモリとプロセッサユニットとを有するシステムなど、何か物理的なものを指す。この表現は、本明細書では、何か無形のものを指すために使用されない。
【0087】
場合によっては、様々なユニット／回路／構成要素が、タスクまたは動作のセットを実行するものとして本明細書で説明され得る。それらのエンティティは、特に言及されていなくても、それらのタスク／動作を実行する「ように構成される」ことが理解される。
【0088】
「するように構成される」という用語は、「するように構成可能である」ことを意味するものではない。例えば、プログラムされていないＦＰＧＡは、特定の機能を実行する「ように構成されている」とはみなされない。しかしながら、このプログラムされていないＦＰＧＡは、その機能を実行するように「構成可能」であり得る。適切なプログラミングの後、ＦＰＧＡは、特定の機能を実行するように「構成されている」と言うことができる。
【0089】
本開示に基づく米国特許出願の目的のために、構造が１つまたは複数のタスクを実行する「ように構成される」という請求項における記載は、その請求項の要素に対して米国特許法第１１２条（ｆ）を行使しないことが明示的に意図される。出願人が、本開示に基づく米国特許出願の審査中に第１１２条（ｆ）を行使することを望む場合、［機能を実行する］「ための手段」構成を使用して請求項の要素を列挙する。
【図1】
【図2】
【図3A】
【図3B】
【図4】
【図5】
【図6】
【図7】
【図8】
【国際調査報告】