特許 7547707 異なるアプリケーションバージョンに対するデータベース実装

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-09-02

(45)【発行日】2024-09-10

(54)【発明の名称】異なるアプリケーションバージョンに対するデータベース実装

(51)【国際特許分類】

   G06F 16/21 20190101AFI20240903BHJP

   G06F 16/22 20190101ALI20240903BHJP

【ＦＩ】

G06F16/21

G06F16/22

【請求項の数】 15

(21)【出願番号】P 2022567071

(86)(22)【出願日】2021-01-26

(65)【公表番号】

(43)【公表日】2023-06-19

(86)【国際出願番号】 US2021015025

(87)【国際公開番号】W WO2021225646

(87)【国際公開日】2021-11-11

【審査請求日】2022-11-02

(31)【優先権主張番号】16/866,331

(32)【優先日】2020-05-04

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】506332063

【氏名又は名称】セールスフォース インコーポレイテッド

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】リーラウ，サージ フィリップ

(72)【発明者】

【氏名】スパルテン，ランディー フィリップ

(72)【発明者】

【氏名】コーエン，ジェフリー アイラ

【審査官】齊藤 貴孝

(56)【参考文献】

【文献】特開２００５－０７８２３７（ＪＰ，Ａ）

【文献】特開２０１１－２１５９８４（ＪＰ，Ａ）

【文献】国際公開第２０１４／１８１４７５（ＷＯ，Ａ１）

【文献】米国特許出願公開第２０１１／０１７３１６８（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １６／００－１６／９５８

(57)【特許請求の範囲】

【請求項1】

データベース管理システム（ＤＢＭＳ）を実行するコンピュータシステムによって、データベースに対するデータベースクエリを受信することであって、前記データベースクエリは、複数のバージョンを有するアプリケーションの特定のバージョンから受信され、前記データベースクエリは、前記特定のバージョンを指定する、受信することと、
前記コンピュータシステムによって、１つ以上のカタログテーブルを識別することであって、前記１つ以上のカタログテーブルは、開始バージョン列を含む第１の列と、停止バージョン列を含む異なる第２の列と、を含み、所与のデータベースオブジェクトに対する前記開始バージョン列及び前記停止バージョン列は、前記所与のデータベースオブジェクトがアクセス可能であるアプリケーションバージョンの範囲を指定する、識別することと、
前記コンピュータシステムによって、前記１つ以上のカタログテーブルに記憶されたバージョンアクセス情報に基づいて、前記データベースクエリに対応する１つ以上のデータベースオブジェクトが、前記アプリケーションの前記特定のバージョンでアクセス可能であることを決定することと、
前記コンピュータシステムによって、前記決定に基づいて、前記データベースクエリに応答して、前記アプリケーションの前記特定のバージョンでアクセス可能な１つ以上のデータベースオブジェクトにアクセスすることと、を含む、方法。

【請求項2】

前記データベースに記憶されたデータベーステーブルオブジェクトに含まれた列データベースオブジェクトに対するカタログテーブルに含まれた前記開始バージョン列及び前記停止バージョン列は、前記列データベースオブジェクトがアクセス可能である２つ以上のアプリケーションバージョンの範囲を指定する、請求項１に記載の方法。

【請求項3】

前記開始バージョン列及び前記停止バージョン列は、スキーマ、テーブル、列、インデックス、トリガ、プロシージャ、及び統計のうちの１つ以上に対するバージョンアクセス情報を指定する、請求項１及び２のいずれか一項に記載の方法。

【請求項4】

前記データベースに対する前記データベースクエリを受信する前に、
前記コンピュータシステムによって、前記アプリケーションの前記特定のバージョンから、前記アプリケーションに対する更新を受信することであって、前記更新は、前記特定のバージョンに関連付けられている、受信することと、
前記コンピュータシステムによって、前記受信した更新に基づいて、前記１つ以上のカタログテーブルを変更することであって、前記変更は、前記特定のバージョンでアクセス可能な前記データベースに記憶された１つ以上のデータベースオブジェクトを指定する前記カタログテーブルに記憶されたメタデータを変更することと、を更に含む、請求項１～３のいずれか一項に記載の方法。

【請求項5】

前記更新は、前記特定のバージョンでアクセス可能なデータベースオブジェクトと、前記アプリケーションの以前のバージョンでアクセス可能なデータベースオブジェクトとの間の１つ以上の差異を示す、請求項４に記載の方法。

【請求項6】

前記カタログテーブルのうちの１つは、少なくとも１つのアプリケーションに対して、その１つのアプリケーションに適用可能なスキーマを指定するスキーマカタログテーブルである、請求項１～５のいずれか一項に記載の方法。

【請求項7】

前記データベースクエリに対する前記バージョンアクセス情報は、前記アプリケーションの前記特定のバージョンに対して、前記１つ以上のデータベースオブジェクトに含まれるデータの第１の部分へのアクセスを許可し、前記方法は、
前記アプリケーションの異なるバージョンから追加のデータベースクエリを受信することに応答して、前記コンピュータシステムによって、前記アプリケーションの前記異なるバージョンに対するバージョンアクセス情報に基づいて、前記１つ以上のデータベースオブジェクトに含まれる前記データの異なる第２の部分にアクセスすることを更に含む、請求項１～６のいずれか一項に記載の方法。

【請求項8】

前記識別されたカタログテーブルは、バージョンアクセス情報を第１のフォーマットで定義する第１のカタログテーブルと、バージョンアクセス情報を第２のフォーマットで定義する第２のカタログテーブルを含む、請求項１～７のいずれか一項に記載の方法。

【請求項9】

前記第１のフォーマットは、特定のアプリケーションバージョンとしてバージョンアクセス情報を指定し、前記第２のフォーマットは、アプリケーションバージョンの範囲としてバージョンアクセス情報を指定する、請求項８に記載の方法。

【請求項10】

少なくとも１つのプロセッサと、
請求項１～９のいずれか一項に記載の方法を実行するために前記少なくとも１つのプロセッサによって実行可能なプログラム命令を記憶したメモリと、を含む、コンピュータシステム。

【請求項11】

データベース管理システム（ＤＢＭＳ）を実行するコンピューティングデバイスに動作を実行させることができる命令を記憶した非一時的なコンピュータ可読媒体であって、前記動作は、
データベースに対するデータベースクエリを受信することであって、前記データベースクエリは、複数のバージョンを有するアプリケーションの特定のバージョンから受信され、前記データベースクエリは、前記特定のバージョンを指定する、受信することと、
１つ以上のカタログテーブルを識別することであって、前記１つ以上のカタログテーブルは、開始バージョン列を含む第１の列と、停止バージョン列を含む異なる第２の列と、を含み、所与のデータベースオブジェクトに対する前記開始バージョン列及び前記停止バージョン列は、前記所与のデータベースオブジェクトがアクセス可能であるアプリケーションバージョンの範囲を指定する、識別することと、
前記１つ以上のカタログテーブルに記憶されたバージョンアクセス情報に基づいて、前記データベースクエリに対応する１つ以上のデータベースオブジェクトが、前記アプリケーションの前記特定のバージョンでアクセス可能であることを決定することと、
前記決定に基づいて、前記データベースクエリに応答して、前記アプリケーションの前記特定のバージョンでアクセス可能な１つ以上のデータベースオブジェクトにアクセスすることと、を含む、非一時的なコンピュータ可読媒体。

【請求項12】

前記１つ以上のバージョン情報列は、前記データベースに記憶されたデータベーステーブルオブジェクトに含まれた列データベースオブジェクトに対するカタログテーブルに含まれた前記開始バージョン列及び前記停止バージョン列は、前記列データベースオブジェクトがアクセス可能である２つ以上のアプリケーションバージョンの範囲を指定する、請求項１１に記載の非一時的なコンピュータ可読媒体。

【請求項13】

前記開始バージョン列及び前記停止バージョン列は、前記データベースの少なくとも１つのスキーマオブジェクト及びデータベーステーブルオブジェクトに対するバージョンアクセス情報を指定し、前記スキーマオブジェクトは、テーブルの名付けられたコレクションであり、前記データベーステーブルオブジェクトは、前記複数のバージョンを有する前記アプリケーションに対する前記データベースにデータを記憶する特定のタイプのテーブルである、請求項１１及び１２のいずれか一項に記載の非一時的なコンピュータ可読媒体。

【請求項14】

前記動作は、
前記データベースに対する前記データベースクエリを受信する前に、
前記アプリケーションの前記特定のバージョンから、前記アプリケーションに対する更新を受信することであって、前記更新は、前記特定のバージョンに関連付けられている、受信することと、
前記受信した更新に基づいて、前記１つ以上のカタログテーブルを変更することであって、前記変更は、前記特定のバージョンでアクセス可能な前記データベースに記憶された１つ以上のデータベースオブジェクトを指定する前記カタログテーブルに記憶されたメタデータを変更することと、を更に含む、請求項１１～１３のいずれか一項に記載の非一時的なコンピュータ可読媒体。

【請求項15】

前記カタログテーブルのうちの１つは、少なくとも１つのアプリケーションに対して、その１つのアプリケーションに適用可能なスキーマを指定するスキーマカタログテーブルであり、前記スキーマカタログテーブルは、異なるアプリケーションに対応するスキーマ名を指定する、請求項１１～１４のいずれか一項に記載の非一時的なコンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、一般に、データベースに関連し、より具体的には、複数のアプリケーションバージョンに対して単一のデータベースを実装することに関連する。

【背景技術】

【0002】

アプリケーションが更新されると、その対応するデータベースが更新される間に、例えば、データ定義言語（ＤＬＬ、ｄａｔａ ｄｅｆｉｎｉｔｉｏｎ ｌａｎｇｕａｇｅ）ステートメントを使用して、シャットダウンされることが多い。例えば、更新されたアプリケーションに対してデータベースのスキーマが変更されることがある。これは、アプリケーションに対するダウンタイムを招くことが多く、これは、アプリケーションのパフォーマンス、ひいてはユーザ体験を妨げることがある。追加的に、アプリケーションの所有者又は開発者は、アプリケーションの更新された新しいバージョンと共に、アプリケーションの前のバージョンを維持することを希望することがある。このようなマルチバージョン実装は、アプリケーションの複数バージョンに対してデータベースを処理しているデータベース管理システム（ＤＢＭＳ）によるアプリケーションの実装中のエラー及び／又は遅延を招くことがある。例えば、新しいアプリケーションバージョンに対するデータベースインデックスは、アプリケーションの前のバージョンの実装に干渉することがある。具体的には、アプリケーションの前のバージョンに対応するインデックスが新しいバージョンにおいてドロップされるときに、ＤＢＭＳは、新しく作成されたインデックスが前のバージョンに干渉することを防止する必要がある。この防止がうまく行かない場合、アプリケーションの前のバージョンからのクエリを処理する際に遅延を招くことがある。

【図面の簡単な説明】

【0003】

【図1】いくつかの実施形態による、異なるアプリケーションバージョンからのデータベースクエリを処理するように構成されている例示的なシステムを例示するブロック図である。

【0004】

【図2】いくつかの実施形態による、データベース管理システムのシステムの例示的なシステムカタログを例示するブロック図である。

【0005】

【図3】いくつかの実施形態による、例示的なバージョンカタログテーブル及びスキーマカタログテーブルを例示するブロック図である。

【0006】

【図4】いくつかの実施形態による、人事（ＨＲ）アプリケーションのための従業員テーブルを含む例示的なデータベースを例示するブロック図である。

【0007】

【図5A】いくつかの実施形態による、データベーステーブルに対する列の追加に基づく列カタログテーブルの例示的な変更を例示するブロック図である。

【図5B】いくつかの実施形態による、データベーステーブルに対する列のリタイアに基づく列カタログテーブルの例示的な変更を例示するブロック図である。

【図5C】いくつかの実施形態による、データベーステーブルに対する列のリタイア解除に基づく列カタログテーブルの例示的な変更を例示するブロック図である。

【図5D】いくつかの実施形態による、データベーステーブルに対する列のドロップに基づく列カタログテーブルの例示的な変更を例示するブロック図である。

【0008】

【図6】いくつかの実施形態による、データベーステーブルの作成中の例示的なデータベーステーブルカタログテーブルを例示するブロック図である。

【0009】

【図7】いくつかの実施形態による、データベースインデックスの作成中の例示的なインデックスカタログテーブルを例示するブロック図である。

【0010】

【図8】いくつかの実施形態による、データベーストリガの追加中の例示的なトリガカタログテーブルを例示するブロック図である。

【0011】

【図9】いくつかの実施形態による、データベースプロシージャの追加中の例示的なプロシージャカタログテーブルを例示するブロック図である。

【0012】

【図10】いくつかの実施形態による、データベース統計の追加中の例示的な統計カタログテーブルを例示するブロック図である。

【0013】

【図11】いくつかの実施形態による、例示的なデータベースクエリを例示するブロック図である。

【0014】

【図12】いくつかの実施形態による、複数の異なるアプリケーションバージョンからのデータベースクエリを処理するための方法を例示するフロー図である。

【0015】

【図13】いくつかの実施形態による、例示的なコンピューティングデバイスを例示するブロック図である。

【発明を実施するための形態】

【0016】

本開示は、「一実施形態」又は「ある実施形態」への言及を含む。「一実施形態において」又は「ある実施形態において」という語句があっても、必ずしも同じ実施形態を指す訳ではない。特定の特徴、構造、又は特性は、本開示と矛盾しない任意の好適な様式で組み合わされ得る。

【0017】

本開示においては、異なるエンティティ（「ユニット」、「回路」、他の構成要素などと様々に称され得る）は、１つ以上のタスク又は動作を実行するように「構成」されていると記載されるか、又は特許請求の範囲において記載され得る。この定式化、つまり、［１つ以上のタスクを実行する］ように構成されている［エンティティ］は、本明細書において構造（すなわち、電子回路などの何らかの物理的なもの）を指すために使用される。より具体的には、この定式化は、この構造が、動作中に１つ以上のタスクを実行するように配置されていることを示すために使用される。構造は、たとえその構造が現在動作していなくても、いくつかのタスクを実行するように「構成」されているということができる。「データベースに対するデータベースクエリを受信するように構成されているコンピュータシステム」は、当該コンピュータシステムが現在使用されていない場合（例えば、電源が接続されていない場合）でも、例えば、動作中にはこの機能を実行するために、プロセッサ、ネットワークインターフェース、プログラム命令を有するメモリなどを有するコンピュータシステムをカバーすることが意図される。したがって、いくつかのタスクを実行するように「構成されている」と記載されるか、又は規定されるエンティティは、デバイス、回路、タスクを実行するために実行可能なプログラム命令を記憶するメモリなどの何らかの物理的なものを指す。この語句は、本明細書において何らかの無形のものを指すためには使用されない。

【0018】

用語「～ように構成されている」が、「～ように構成可能である」ことを意味するように意図されていない。例えば、プログラムされていないＦＰＧＡは、何らかの指定の機能を実行する「ように構成可能で」あり得、プログラミングされた後は、その機能を実行するように「構成されている」が、その機能を実行するように「構成されている」とはみなされないだろう。

【0019】

本明細書において使用される場合、用語「第１」、「第２」などは、先行して名詞のラベルとして使用され、具体的に記載されない限り、いかなる種類の順序付け（例えば、空間的、時間的、論理的など）も示唆しない。例えば、複数のユーザアカウントを有するコンピューティングシステムでは、用語「第１の」及び「第２の」ユーザアカウントは、任意のユーザを指すように使用され得る。言い換えれば、「第１」及び「第２」のユーザアカウントは、例えば、最初に作成される２つのユーザアカウントに限定されない。

【0020】

本明細書において使用される場合、用語「～に基づいて」は、決定に影響する１つ以上の要因を記載するために使用される。この用語は、追加的な要因が決定に影響を及ぼす可能性を排除しない。すなわち、決定は、指定された要因のみに基づくか、又は指定された要因及び他の指定されていない要因に基づき得る。「Ｂに基づいてＡを決定する」という語句を考える。この語句は、ＢがＡを決定するために使用される要因であるか、又はＢがＡの決定に影響を及ぼすこと指定する。この語句は、Ａの決定がＣなどの他の要因にも基づき得ること除外しない。この語句は、ＡがＢのみに基づいて決定される実施形態をもカバーすることを意図している。したがって、本明細書で使用される場合、「～に基づいて」という語句は、語句「～に少なくとも部分的に基づいて」と同義である。

【0021】

従来のＤＢＭＳ実装では、複数のアプリケーションバージョンを処理するための１つのアプローチは、ユーザ要求を処理するためにデータを検索するためにデータベース管理システム（ＤＢＭＳ）にアクセスする新しいバーションのアプリケーションを含んでいた。この実装では、ＤＢＭＳは、そのアプリケーションのための新しいデータベーススキーマを新しいスキーマ名でデータベースにロードし得る。この例では、新しいデータベーススキーマは、単に以前のバージョンのアプリケーションのスキーマの重複であるが、新しいアプリケーションの実行に対応する変更を有している。この実装は、簡単にコピーされるデータベースオブジェクト（トリガ、インデックス、統計などの非永続性オブジェクト）に対してはうまく機能するものの、テーブルなどの永続性データベースオブジェクトに対しては問題を招く。例えば、複数の異なるスキーマに対してデータベーステーブルの全内容を複数回コピーすることは、コストが高く、非効率的である。

【0022】

本開示は、単一のデータベースにおいて複数の異なるアプリケーションバージョンのためのデータを維持するための技術を記載する。例えば、開示された技術は、データベース内の異なるオブジェクトに対するデータベースのシステムカタログ内のアプリケーションバージョニングを実装することによって、所与の時点における複数のアプリケーションバージョンからのクエリを処理する。システムカタログは、データベースに記憶されたデータベースオブジェクトを記載するメタデータを保持する。例えば、アプリケーションは、データベース内の特定のスキーマに関連付けられてもよく、このスキーマは、名前とバージョンを含む（スキーマバージョンが、所与のアプリケーションバージョンに対応するようにする）。新しいバージョニング技術は、追加の列をデータベースカタログテーブルに追加して、データベースに記憶されている様々なデータベースオブジェクトに関連付けられたアプリケーションバージョンを指定することを伴う。例えば、これらの列は、開始バージョンと停止バージョンを使用してアプリケーションバージョンの範囲を指定するか、又はデータベース内のオブジェクトに対して特定のアプリケーションバージョンを指定し得る。これらのデータベースオブジェクトは、テーブル、列、トリガ、インデックス、統計、プロシージャ、ビューなどを含み得る。

【0023】

本明細書に記載される実施形態では、クライアントアプリケーションの新しいバージョンは、「販売（ｓａｌｅｓ）」データベーステーブルに新しい列「通貨（ｃｕｒｒｅｎｃｙ）」を追加し得る。この例では、データベース管理システムは、データベース列に対するメタデータ含むシステムカタログ内のテーブルに新しい行を追加する。この列カタログテーブルは、データベーステーブルの名前（売上）、追加される列の名前（通貨）、及びこの追加されるデータベース列に関連付けられたアプリケーションの開始バージョンと停止バージョンを指定する。本開示に記載されるデータベース管理技術は、データベースに記憶されるデータの重複を低減又は回避しつつ、アプリケーションの複数の異なるバージョンのサービス提供を同時に有利に可能にし得る。

【0024】

例示的なＤＢＭＳ
図１は、異なるアプリケーションバージョンからのデータベースクエリを処理するように構成されている例示的なシステムを例示するブロック図である。例示される実施形態では、システム１００は、アプリケーション要求を処理するために通信するように構成されているユーザコンピューティングシステム１１０及びＤＢＭＳ１３０を含む。

【0025】

ユーザコンピューティングシステム１１０は、例示される実施形態では、アプリケーション１２０を含む。ユーザコンピューティングシステム１１０は、様々な異なるユーザによるアプリケーション１２０の使用を容易にするように構成されているアプリケーションサーバであり得る。例えば、いくつかの実施形態では、システム１１０は、様々な異なる顧客に対するアプリケーションを管理する顧客関係管理システムであり得る。いくつかの状況では、（同じ又は異なる顧客の）異なるユーザが同じアプリケーションを使用するが、このアプリケーションの異なるバージョンを実装する。例えば、システム１１０は、２つの異なるユーザに対して人事アプリケーションを管理し得るが、各ユーザは、ＤＢＭＳによって維持される異なるデータへのアクセスを有する異なるバージョンの人事アプリケーションを実装する。いくつかの実施形態では、システム１１０以外のコンピューティングシステムは、アプリケーション１２０の異なるバージョンを含み、これらのアプリケーションからのクエリを処理するためにＤＢＭＳ１３０と通信するように構成されている。例示される実施形態では、ユーザコンピューティングシステム１１０は、アプリケーション１２０に対するクエリ１０２をＤＢＭＳ１３０に送信する。このクエリ１０２は、特定のアプリケーションバージョンを指定する。

【0026】

例示される実施形態では、ＤＢＭＳ１３０は、システムカタログ１４０及びデータベース１５０を含む。本明細書において使用される場合、用語「システムカタログ」は、その十分に理解された意味に従って解釈されることを意図しており、これは、データベースオブジェクトを定義するスキーマなどの、データベースに記憶されるデータに関するメタデータを記憶するデータベースの一部分を含む。例えば、システムカタログは、様々なカタログテーブル及び／又はカタログビューを含み得る。これらのカタログテーブルは、例えば、データベースのテーブル、列、トリガ、インデックス、統計、プロシージャ、ビューなど、ＤＢＭＳによって管理されるデータベースに含まれる様々なオブジェクトに記憶されるデータを記載するメタデータを含み得る。これらのカタログテーブルは、例えば、アプリケーションから受信した構造化クエリ言語（ＳＱＬ）クエリを評価する最善の方法を決定するために使用され得る。用語「カタログ」及び「カタログテーブル」という用語は、互換的に使用され得る。本開示では、カタログテーブルは、どのデータベーステーブルが特定のアプリケーションに対して可視であるかを含む、異なるアプリケーションバージョンでアクセス可能であるデータベースに記憶されているデータセットのサブセットを指定する。

【0027】

例示される実施形態では、システムカタログ１４０は、データベース１５０に記憶されたデータベースオブジェクトに関する情報を含むテーブルのコレクションである。例えば、システムカタログ１４０は、異なるバージョンのアプリケーション（又は異なるアプリケーション）に対応するスキーマ識別子のリストを含み得る。システムカタログ１４０は、各々が異なるバージョンに対するメタデータを含む様々なカタログテーブル１４２Ａ～１４２Ｎを含む。例えば、図１では、カタログテーブル１４２Ａ～１４２Ｎは、アプリケーション１２０のバージョンＡ及びバージョンＢに対するメタデータ１４４を含む。図２を参照して、例示的なカタログテーブルが以下に議論される。

【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】

例示される実施形態では、ＤＢＭＳ１３０は、データベース１５０内に新しいインデックスを作成するために指定するデータベースコマンド７０２をアプリケーション１２０から受信する。このコマンドに基づいて、ＤＢＭＳ１３０は、新しいインデックスｈｒ．ｅｍｐ＿ｎａｍｅ＿ｃｏｍｐ４３０を生成する。ＤＢＭＳ１３０は、新しいインデックスを生成した後、インデックス作成動作７１２を実行して、インデックス４３０に対してインデックスカタログテーブル２５０にエントリを追加して、このインデックスがアプリケーションバージョン２０４．７．３（及びより新しいバージョン）にアクセス可能であり、したがって、このインデックスはアプリケーションバージョン２０４．７．２及びより古いバージョンでは使用不可能であることを示す。しかし、ＤＢＭＳ１３０は、特定のアプリケーションバージョン（バージョン２０４．７．２以前など）によって、これらのインデックスが使用可能ではない（利用できない）状況であっても、データベース内に存在するインデックスを維持する。

【0057】

図８は、データベーストリガの追加中の例示的なトリガカタログテーブルを例示するブロック図である。例示される実施形態では、トリガカタログテーブル２６０は、データベース１５０に記憶されたトリガを指定するメタデータを有する以下の列、すなわち、テーブルＩＤ５３２、トリガＩＤ８６２、トリガ名８６４、開始バージョン５９０、及び停止バージョン５９２を含む。トリガＩＤ８６２及びトリガ名８６４は、例えば、様々なデータベーストリガに対して、それぞれ識別子及び名前を指定する値を記憶する。

【0058】

例示される実施形態では、ＤＢＭＳ１３０は、データベース１５０にトリガを追加することを指定するデータベースコマンド８０２をアプリケーション１２０から受信する。このコマンドに基づいて、ＤＢＭＳ１３０は、データベース１５０内の従業員テーブルの賞与列に新しいトリガを生成する。ＤＢＭＳは、データベース１５０にトリガを追加した後、トリガ追加動作８１２を実行して、アプリケーションバージョン２０４．７．３に対する新しい「ｂｏｎｕｓ＿ｔｒｉｇｇｅｒ」のためのトリガカタログテーブル２６０にエントリを追加する。この例では、「ｂｏｎｕｓ＿ｔｒｉｇｇｅｒ」は、バージョン２０４．７．３以降に関連付けられたアプリケーションに対してのみ実行する。

【0059】

図９は、データベースプロシージャの追加中の例示的なプロシージャカタログテーブルを例示するブロック図である。例示される実施形態では、プロシージャカタログテーブル２７０は、データベース１５０に記憶されたプロシージャを指定するメタデータを有する以下の列、すなわち、プロシージャＩＤ９７２、スキーマＩＤ９７４、及びプロシージャ名９７６を含む。プロシージャＩＤ９７２列及びプロシージャ名９７６列は、例えば、様々なデータベースプロシージャの識別子及び名前をそれぞれ指定する値を記憶する。

【0060】

例示される実施形態では、ＤＢＭＳ１３０は、データベース１５０にプロシージャを追加することを指定するデータベースコマンド９０２をアプリケーション１２０から受信する。このコマンドに基づいて、ＤＢＭＳ１３０は、データベース１５０内の特定のスキーマ（図３のスキーマカタログテーブル２２０によるアプリケーションバージョン２０４．７．４に対応する）に対して「リタイア（ｒｅｔｉｒｅｍｅｎｔ）」と呼ばれる新しいプロシージャを生成する。ＤＢＭＳ１３０は、新しいプロシージャをデータベース１５０に追加した後、プロシージャ追加動作９１２を実行して、スキーマＩＤ３に対する新しい「リタイア（ｒｅｔｉｒｅｍｅｎｔ）」プロシージャに対するエントリをプロシージャカタログテーブル２７０に追加する。この例では、プロシージャ「リタイア（ｒｅｔｉｒｅｍｅｎｔ）」は、バージョン２０４．７．４に関連付けられたアプリケーションに対するクエリでのみ可視である。

【0061】

図１０は、データベース統計の追加中の例示的な統計カタログテーブルを例示するブロック図である。例示される実施形態では、統計カタログテーブル２８０は、データベース１５０に記憶された異なるデータベーステーブルに対する統計を指定するメタデータを有する以下の列、すなわち、テーブルＩＤ５３２、幅統計９８２、ヌル統計９８４、開始バージョン５９０、及び停止バージョン５９２を含む。幅統計９８２及びヌル統計９８４は、所与のデータベーステーブルに対して生成され得る統計のタイプの非限定的な例である。幅統計９８２は、例えば、所与のデータベーステーブル内のヌルではないエントリの平均記憶幅をバイト単位で指定し得る。

【0062】

例示される実施形態では、データベースコマンド１００２は、ｈｒ．ｅｍｐｌｏｙｅｅデータベーステーブル４１０に対する統計をデータベース１５０にロードするための動作を含む。ＤＢＭＳ１３０は、この動作を実行した後、統計加算動作１０１２を実行して、人事アプリケーションバージョン２０４．７．２に対する幅及びヌル統計を指定するエントリを統計カタログテーブル２８０に追加する。この例では、ＤＢＭＳ１３０に対するクエリ最適化プログラムは、バージョン２０４．７．２以降に関連付けられたアプリケーションからのクエリに対するヌル統計を使用することができるのみである。

【0063】

図１１は、例示的なデータベースクエリを例示するブロック図である。例示される実施形態では、システム１１００は、アプリケーション１２０及びＤＢＭＳ１３０を含む。アプリケーション１２０は、クエリ１１０２をＤＢＭＳ１３０に送信する。クエリ１１０２は、アプリケーション１２０が現在バージョン２０４．７．２の下で動作しており、したがって、このクエリは、このバージョンでアクセス可能なデータベースオブジェクトにアクセスすることを要求していることを指定する。加えて、クエリ１１０２は、「Ｊｏｈｎ Ｄｏｅ」という名前の従業員について、ｈｒ．ｔｏｔａｌｃｏｍｐプロシージャ４４０によって生成されるデータを選択することを指定する。

【0064】

以下の例示的な説明は、図４に示されるデータベースオブジェクトへの参照を含む。図１１に示されるアプリケーション１２０は、特定の従業員（Ｊｏｈｎ Ｄｏｅ）に対する報酬情報を要求する人事アプリケーションであり得る。クエリ１１０２に応答するために、ＤＢＭＳ１３０は、システムカタログ１４０にアクセスして、プロシージャ「ｔｏｔａｌｃｏｍｐ」がスキーマＩＤ１に属するかどうかを決定する。ＤＢＭＳ１３０は、それが実際にスキーマ１に属していると決定することに基づいて、１）スキーマＩＤ１は、「ＨＲ」と名付けられたスキーマであり、２）スキーマＩＤ１は、アプリケーションバージョン２０４．７．２に一致するスキーマであることを検証する。この情報に基づいて、ＤＢＭＳ１３０は、データベース１５０にアクセスして、Ｊｏｈｎ Ｄｏｅに対する総報酬（給与＋賞与）の計算結果を取得する。

【0065】

クエリ１１０２は、Ｊｏｈｎ Ｄｏｅの給与及び賞与情報を取得するために、ｈｒ．ｅｍｐｌｏｙｅｅテーブル４１０にアクセスし、Ｈｒ．ｔｏｔａｌｃｏｍｐプロシージャ４４０にアクセスし、次いで、これらの値をプロシージャ４４０にプラグインすること、又はｈｒ．ｅｍｐ＿ｎａｍｅ＿ｃｏｍｐインデックス４３０（このインデックスがアプリケーションバージョン２０４．７．３でアクセス可能である場合、この場合は、アクセス可能である）にアクセスし、Ｊｏｈｎ Ｄｏｅに対する給与４１６列及び賞与４１８列の合計４３２を取得することのいずれかによって、満たされ得ることに留意する。ＤＢＭＳ１３０がｈｒ．ｅｍｐ＿ｎａｍｅ＿ｃｏｍｐインデックスを使用して、クエリ１１０２に応答する場合、このシステムは、最初にインデックスカタログテーブル２５０にアクセスして、アプリケーションバージョン２０４．７．３から開始するｈｒ．ｅｍｐ＿ｎａｍｅ＿ｃｏｍｐインデックスがアクセス可能であることを決定する。この例示的なシナリオでは、ＤＢＭＳ１３０は、次いで、ｈｒ．ｅｍｐｌｏｙｅｅテーブル４１０の給与列、賞与列、及び名前列が、バージョン２０４．７．３のアプリケーションに可視であることをチェックする。次いで、ＤＢＭＳは、ｅｍｐ＿ｎａｍｅインデックスとｅｍｐ＿ｎａｍｅ＿ｃｏｍｐインデックスが、バージョン２０４．７．３のアプリケーションに可視であることを決定する。この情報に基づいて、ＤＢＭＳ１３０は、次いで、データベースインデックス４３０にアクセスして、アプリケーション１２０によって要求されたデータを取得する。アプリケーションバージョン２０４．７．３ではなく、２０４．７．４においてｅｍｐ＿ｎａｍｅ＿ｃｏｍｐインデックスが追加されていると、ＤＢＭＳ１３０はこのインデックスを使用するのを控える必要がある。例示される実施形態では、ＤＢＭＳ１３０は、データベース１５０にアクセスしてＪｏｈｎ Ｄｏｅに対する総報酬を取得した後に、Ｊｏｈｎ Ｄｏｅに対する総報酬が＄２１０，０００であることを指定するクエリ結果１１０４をアプリケーション１２０に送信する。

【0066】

例示的な方法ここで、図１２を参照すると、異なるアプリケーションバージョンからのデータベースクエリを処理するための例示的な方法１２００を例示するフロー図である。図１２に示される方法は、他のデバイスの中でも、コンピュータ回路、システム、デバイス、要素、又は構成要素のいずれかと併せて使用され得る。様々な実施形態では、示されている方法要素のいくつかは、示されているものとは異なる順序で同時に実行され得るか、又は省略され得る。追加の方法要素もまた、所望に応じて実行され得る。

【0067】

１２１０において、例示される実施形態では、データベース管理システム（ＤＢＭＳ）を実行するコンピュータシステムは、データベースに対するデータベースクエリを受信し、データベースクエリは、複数のバージョンを有するアプリケーションの特定のバージョンから受信され、データベースクエリは、特定のバージョンを指定する。いくつかの実施形態では、コンピュータシステムは、データベースに対するデータベースクエリを受信する前に、アプリケーションの特定のバージョンから、アプリケーションに対する更新を受信し、更新は、特定のバージョンに関連付けられている。いくつかの実施形態では、コンピュータシステムは、受信した更新に基づいて、１つ以上のカタログテーブルを変更し、変更は、特定のバージョンでアクセス可能なデータベースに記憶された１つ以上のデータベースオブジェクトを指定するカタログテーブルに記憶されたメタデータを変更することを含む。いくつかの実施態様では、更新は、特定のバージョンでアクセス可能なデータベースオブジェクトと、アプリケーションの以前のバージョンでアクセス可能なデータベースオブジェクトとの間の１つ以上の差異を示す。

【0068】

いくつかの実施形では、ＤＢＭＳは、特定のアプリケーションバージョンを指定しないデータベースクエリを受信し得る。例えば、いくつかの状況では、現行のアプリケーションバージョンがＤＢＭＳに既知であり得、この既知のアプリケーションバージョンは、ＤＢＭＳが異なるアプリケーションバージョンを指定するＳＥＴコマンド（例えば、図５Ａ～図８及び図１０～図１１に示されるＳＥＴコマンド）を受信しない限り及び受信するまで、クエリを受信するために使用される。

【0069】

１２２０において、コンピュータシステムは、１つ以上のカタログテーブルを識別し、１つ以上のカタログテーブルは、バージョンアクセス情報を記憶する１つ以上のバージョン情報列を含む。いくつかの実施形態では、１つ以上のバージョン情報列は、データベースに記憶された１つ以上のデータベースオブジェクトがアクセス可能であるアプリケーションバージョンの範囲を指定する開始バージョン列及び停止バージョン列を含む。例えば、開始バージョン列は、データベースオブジェクトが利用可能になり始めたアプリケーションバージョンを示し得、停止バージョン列は、データベースオブジェクトがもはやアクセス不可能となったアプリケーションバージョンを示し得る。言い換えると、停止バージョン列は、データベースオブジェクトにアクセスできないアプリケーションバージョン（及び任意の以降のアプリケーションバージョン）を指定し得る。いくつかの実施形態では、バージョン情報列は、１つ以上のデータベースオブジェクトに対するバージョンアクセス情報を指定する。いくつかの実施形態では、１つ以上のデータベースオブジェクトは、以下のタイプのオブジェクト、すなわち、スキーマ、テーブル、列、インデックス、トリガ、プロシージャ、及び統計のうちの１つ以上を含む。１つ以上のデータベースオブジェクトは、このリストに含まれるオブジェクトタイプの様々な組み合わせの任意のもの、又は上記リストに明示的に規定されていない様々な他のタイプのデータベースオブジェクトの任意のものを含み得る。例えば、データベースに記憶されたデータベースオブジェクトは、スキーマオブジェクト及びデータベースオブジェクト、スキーマオブジェクト若しくはテーブルオブジェクトであるがその両方ではないもの、７つ全てのタイプのデータベースオブジェクト、又はそれらの任意の組み合わせを含み得る。いくつかの実施形態では、カタログテーブルのうちの１つは、少なくとも１つのアプリケーションに対して、その１つのアプリケーションに適用可能なスキーマを指定するスキーマカタログテーブルである。いくつかの実施形態では、スキーマカタログテーブルは、異なるアプリケーションに対応するスキーマ名を指定する。

【0070】

いくつかの実施形態では、データベースオブジェクトは、単一のアプリケーションバージョンでアクセス可能である。他の実施形態では、データベースオブジェクトは、アプリケーションの複数のバージョンにわたる存続期間を有し得る。データベースオブジェクトの存続期間は、開始バージョン列と停止バージョン列によって指定され得る。しかしながら、他の状況では、データベースオブジェクトの存続期間は、間隔データタイプを使用する単一の列によって指定され得る。この状況では、単一の列は、データベースオブジェクトへのアクセスを有するアプリケーションバージョンの範囲を指定する。

【0071】

いくつかの実施形態では、バージョン情報列は、データベースの少なくとも１つのスキーマオブジェクト及びデータベーステーブルオブジェクトに対するバージョンアクセス情報を指定し、スキーマオブジェクトは、テーブルの名付けられたコレクションであり、データベーステーブルオブジェクトは、複数のバージョンを有するアプリケーションに対するデータベースにデータを記憶する特定のタイプのテーブルである。いくつかの実施形態では、識別されたカタログテーブルは、バージョンアクセス情報を第１のフォーマットで定義する第１のカタログテーブルと、バージョンアクセス情報を第２のフォーマットで定義する第２のカタログテーブルを含む。いくつかの実施形態では、第１のフォーマットは、特定のアプリケーションバージョンとしてバージョンアクセス情報を指定し、第２のフォーマットは、アプリケーションバージョンの範囲としてバージョンアクセス情報を指定する。

【0072】

１２３０において、コンピュータシステムは、データベースクエリに対応する１つ以上のデータベースオブジェクトが、アプリケーションの特定のバージョンでアクセス可能であることをデータベースクエリに対するバージョンアクセス情報が示すことを決定する。

【0073】

１２４０において、コンピュータシステムは、決定に基づいて、データベースクエリに応答して、アプリケーションの特定のバージョンでアクセス可能な１つ以上のデータベースオブジェクトにアクセスする。いくつかの実施形態では、データベースクエリに対するバージョンアクセス情報は、アプリケーションの特定のバージョンに対して、１つ以上のデータベースオブジェクトに含まれるデータの第１の部分へのアクセスを許可する。例えば、ｈｒ．ｅｍｐｌｏｙｅｅテーブル４１０に含まれる給与列４１６に記憶された情報（データベースオブジェクトの一例）は、アプリケーションの特定のバージョンでアクセス可能であり得る。いくつかの実施形態では、アプリケーションの異なるバージョンから追加のデータベースクエリを受信することに応答して、コンピューティングシステムは、アプリケーションの異なるバージョンに対するバージョンアクセス情報に基づいて、１つ以上のデータベースオブジェクトに含まれるデータの第２の部分にアクセスする。例えば、給与列４１６及び賞与列４１８の両方に記憶された情報は、ｈｒ．ｅｍｐｌｏｙｅｅテーブルに含まれ、アプリケーションの異なるバージョンにアクセス可能であり得る。いくつかの実施形態では、アプリケーションの２つの異なるバージョンからのデータベースクエリ及びそれらのそれぞれのバージョンアクセス情報を受信することに基づいて、コンピュータシステムは、異なるデータベースオブジェクトにアクセスする。例えば、コンピューティングシステムは、ｈｒ．ｅｍｐｌｏｙｅｅテーブル４１０（１つの例示的なデータベースオブジェクト）が第１のアプリケーションバージョンでアクセス可能であるのに対し、クライアントテーブル（別の例示的なデータベースオブジェクト）が第２のアプリケーションバージョンでアクセス可能であると決定し得る。

【0074】

いくつかの実施形態では、コンピュータシステムは、インデックステーブルをデータベースに追加する。いくつかの実施形態では、インデックステーブルを追加することに基づいて、コンピュータシステムは、データベース内の１つ以上のインデックステーブルに対するメタデータを含むインデックスカタログテーブルに行を追加し、行は、データベースに記憶された１つ以上のデータベースオブジェクトがアクセス可能であるアプリケーションの１つ以上のバージョンを示す情報を指定する開始バージョン列及び停止バージョン列に対するそれぞれの値を含む。

【0075】

いくつかの実施形態では、アプリケーションの特定のバージョンは、データベースに対するデータベースクエリをＤＢＭＳに送信し、データベースクエリは、アプリケーションの特定のバージョンを指定する。いくつかの実施形態では、データベースは、１つ以上のカタログテーブルの１つ以上のバージョン情報列内にバージョンアクセス情報を維持する。いくつかの実施形態では、アプリケーションの特定のバージョンは、データベース照会に応答するデータをＤＢＭＳから受信する。いくつかの実施形態では、データは、データがアプリケーションの特定のバージョンでアクセス可能であることを指定するバージョンアクセス情報に基づいてデータベースから検索される。いくつかの実施形態では、アプリケーションの特定のバージョンは、１つ以上のデータベースオブジェクトに対する更新をＤＢＭＳに送信し、更新は、特定のバージョンに関連付けられている。いくつかの実施態様では、更新は、１つ以上のカタログテーブルに記憶されたメタデータに対する変更を含む。

【0076】

例示的なコンピューティングデバイスここで、図１３を参照すると、いくつかの実施形態によれば、コンピューティングデバイス（コンピューティングシステムとも称される）１３１０のブロック図が示される。コンピューティングデバイス１３１０は、本開示の様々な部分を実施するために使用され得る。コンピューティングデバイス１３１０は、本開示の一部分を実装するモバイルデバイス、サーバコンピュータシステム、クライアントコンピュータシステム、又は任意の他のコンピューティングシステムとして使用され得る装置の一例である。例えば、コンピューティングデバイス１３１０は、コンピューティングシステム１１０及び／又はＤＢＭＳ１３０を実装し得る。いくつかの状況では、コンピューティングデバイス１３１０はアプリケーション１３０を実行する。

【0077】

コンピューティングデバイス１３１０は、パーソナルコンピュータシステム、デスクトップコンピュータ、ラップトップコンピュータ又はノートブックコンピュータ、携帯電話、メインフレームコンピュータシステム、ウェブサーバ、ワークステーション、又はネットワークコンピュータを含むが、これらに限定されない、任意の好適なタイプのデバイスであり得る。示されるように、コンピューティングデバイス１３１０は、処理ユニット１３５０、記憶サブシステム１３１２、及び相互接続１３６０（例えば、システムバス）を介して結合された入出力（Ｉ／Ｏ）インターフェース１３３０を含む。入出力インターフェース１３３０は、１つ以上のＩ／Ｏデバイス１３４０に結合され得る。コンピューティングデバイス１３１０は、例えば他のコンピューティングデバイスと通信するためにネットワーク１３２０に結合され得るネットワークインターフェース１３３２をさらに含む。

【0078】

処理ユニット１３５０は、１つ以上のプロセッサを含み、いくつかの実施形態では、１つ以上のコプロセッサユニットを含む。いくつかの実施形態では、処理ユニット１３５０の複数のインスタンスは、相互接続１３６０に結合され得る。処理ユニット１３５０（又は処理ユニット１３５０内の各プロセッサ）は、キャッシュ又は他の形式のオンボードメモリを含み得る。いくつかの実施形態では、処理ユニット１３５０は、汎用処理ユニットとして実装され得、他の実施形態では、特殊目的処理ユニット（例えば、ＡＳＩＣ）として実装され得る。一般に、コンピューティングデバイス１３１０は、任意の特定のタイプの処理ユニット又はプロセッササブシステムに限定されない。

【0079】

本明細書で使用される場合、用語「処理ユニット」は、動作を実行するように構成されている回路を指す。したがって、処理ユニットは、様々な方法で実装されるハードウェア回路として実装され得る。ハードウェア回路は、例えば、カスタム超大規模集積（ＶＬＳＩ）回路又はゲートアレイ、論理チップ、トランジスタ、又は他のディスクリート構成要素などの市販の半導体を含み得る。処理ユニットはまた、フィールドプログラマブルゲートアレイ、プログラマブルアレイロジック、プログラマブルロジックデバイスなどのプログラマブルハードウェアデバイスに実装され得る。

【0080】

記憶サブシステム１３１２は、処理ユニット１３５０によって使用可能である（例えば、処理ユニット１３５０によって実行可能な命令及びこれによって使用されるデータを記憶する）。記憶サブシステム１３１２は、ハードディスク記憶装置、フロッピーディスク記憶装置、リムーバブルディスク記憶装置、フラッシュメモリ、ランダムアクセスメモリ（ＲＡＭ－ＳＲＡＭ、ＥＤＯ ＲＡＭ、ＳＤＲＡＭ、ＤＤＲ ＳＤＲＡＭ、ＲＤＲＡＭなど）、ＲＯＭ（ＰＲＯＭ、ＥＥＰＲＯＭなど）などを含む、任意の好適なタイプの物理メモリ媒体によって実装され得る。記憶サブシステム１３１２は、いくつかの実施形態では、揮発性メモリのみから構成され得る。記憶サブシステム１３１２は、処理装置１３５０を使用してコンピューティングデバイス１３１０によって実行可能なプログラム命令を記憶することができ、このプログラム命令は、コンピューティングデバイス１３１０に本明細書に開示されている様々な技術を実行させるように実行可能なプログラム命令を含む。

【0081】

Ｉ／Ｏインターフェース１３３０は、１つ以上のインターフェースを表し得、様々な実施形態に従って、他のデバイスに結合して通信するように構成されている様々なタイプのインターフェースのいずれであり得る。いくつかの実施形態では、Ｉ／Ｏインターフェース１３３０は、フロントサイドから１つ以上のバックサイドバスへのブリッジチップである。Ｉ／Ｏインターフェース１３３０は、１つ以上の対応するバス又は他のインターフェースを介して、１つ以上のＩ／Ｏデバイス１３４０に結合され得る。Ｉ／Ｏインターフェースの例は、記憶デバイス（ハードディスク、光学ドライブ、リムーバブルフラッシュドライブ、記憶アレイ、ＳＡＮ、又は関連付けられたコントローラ）、ネットワークインターフェースデバイス、ユーザインターフェースデバイス、又は他のデバイス（例えば、グラフィック、サウンドなど）を含む。

【0082】

図１３のコンピューティングデバイスは、開示された概念を実証するための一実施形態であることに留意する。他の実施形態では、コンピューティングデバイスの様々な態様が異なり得る。例えば、いくつかの実施形態では、例示された構成要素の追加の構成要素、又は複数のインスタンスが含まれ得る。

【0083】

出願の主題の実現は、以下の例１～２０を含むが、これらに限定されない。
（例１）
データベース管理システム（ＤＢＭＳ）を実行するコンピュータシステムによって、データベースに対するデータベースクエリを受信することであって、データベースクエリは、複数のバージョンを有するアプリケーションの特定のバージョンから受信され、データベースクエリは、特定のバージョンを指定する、受信することと、
コンピュータシステムによって、１つ以上のカタログテーブルを識別することであって、１つ以上のカタログテーブルは、バージョンアクセス情報を記憶する１つ以上のバージョン情報列を含む、識別することと、
コンピュータシステムによって、データベースクエリに対応する１つ以上のデータベースオブジェクトが、アプリケーションの特定のバージョンでアクセス可能であることをデータベースクエリに対するバージョンアクセス情報が示すことを決定することと、
コンピュータシステムによって、決定に基づいて、データベースクエリに応答して、アプリケーションの特定のバージョンでアクセス可能な１つ以上のデータベースオブジェクトにアクセスすることと、を含む、方法。
（例２）
１つ以上のバージョン情報列は、データベースに記憶された１つ以上のデータベースオブジェクトがアクセス可能であるアプリケーションバージョンの範囲を示す情報を指定するバージョン列を含む、例１に記載の方法。
（例３）
バージョン情報列は、１つ以上のデータベースオブジェクトに対するバージョンアクセス情報を指定し、１つ以上のデータベースオブジェクトは、スキーマ、テーブル、列、インデックス、トリガ、プロシージャ、及び統計のうちの１つ以上のタイプのオブジェクトを含む、例１に記載の方法。
（例４）
データベースに対するデータベースクエリを受信する前に、
コンピュータシステムによって、アプリケーションの特定のバージョンから、アプリケーションに対する更新を受信することであって、更新は、特定のバージョンに関連付けられている、受信することと、
コンピュータシステムによって、受信した更新に基づいて、１つ以上のカタログテーブルを変更することであって、変更は、特定のバージョンでアクセス可能なデータベースに記憶された１つ以上のデータベースオブジェクトを指定するカタログテーブルに記憶されたメタデータを変更することと、を更に含む、例１に記載の方法。
（例５）
更新は、特定のバージョンでアクセス可能なデータベースオブジェクトと、アプリケーションの以前のバージョンでアクセス可能なデータベースオブジェクトとの間の１つ以上の差異を示す、例４に記載の方法。
（例６）
カタログテーブルのうちの１つは、少なくとも１つのアプリケーションに対して、その１つのアプリケーションに適用可能なスキーマを指定するスキーマカタログテーブルである、例１に記載の方法。
（例７）
データベースクエリに対するバージョンアクセス情報は、アプリケーションの特定のバージョンに対して、１つ以上のデータベースオブジェクトに含まれるデータの第１の部分へのアクセスを許可し、方法は、
アプリケーションの異なるバージョンから追加のデータベースクエリを受信することに応答して、コンピュータシステムによって、アプリケーションの異なるバージョンに対するバージョンアクセス情報に基づいて、１つ以上のデータベースオブジェクトに含まれるデータの異なる第２の部分にアクセスすることを更に含む、例１に記載の方法。
（例８）
識別されたカタログテーブルは、第１のフォーマットでバージョンアクセス情報を定義する第１のカタログテーブルと、第２のフォーマットでバージョンアクセス情報を定義する第２のカタログテーブルとを含む、例１に記載の方法。
（例９）
第１のフォーマットは、特定のアプリケーションバージョンとしてバージョンアクセス情報を指定し、第２のフォーマットは、アプリケーションバージョンの範囲としてバージョンアクセス情報を指定する、例８に記載の方法。
（例１０）
データベース管理システム（ＤＢＭＳ）を実行するコンピューティングデバイスに動作を実行させることができる命令を記憶した非一時的なコンピュータ可読媒体であって、動作は、
データベースに対するデータベースクエリを受信し、データベースクエリは、複数のバージョンを有するアプリケーションの特定のバージョンから受信され、データベースクエリは、特定のバージョンを指定する、受信することと、
１つ以上のカタログテーブルを識別することであって、１つ以上のカタログテーブルは、バージョンアクセス情報を記憶する１つ以上のバージョン情報列を含む、識別することと、
データベースクエリに対応する１つ以上のデータベースオブジェクトが、アプリケーションの特定のバージョンでアクセス可能であることをデータベースクエリに対するバージョンアクセス情報が示すことを決定することと、
決定に基づいて、データベースクエリに応答して、アプリケーションの特定のバージョンでアクセス可能な１つ以上のデータベースオブジェクトにアクセスすることと、を含む、非一時的なコンピュータ可読媒体。
（例１１）
１つ以上のバージョン情報列は、データベースに記憶された１つ以上のデータベースオブジェクトがアクセス可能であるアプリケーションバージョンの範囲を指定する開始バージョン列及び停止バージョン列を含む、例１０に記載の非一時的なコンピュータ可読媒体。
（例１２）
バージョン情報列は、データベースの少なくとも１つのスキーマオブジェクト及びデータベーステーブルオブジェクトに対するバージョンアクセス情報を指定し、スキーマオブジェクトは、テーブルの名付けられたコレクションであり、データベーステーブルオブジェクトは、複数のバージョンを有するアプリケーションに対するデータベースにデータを記憶する特定のタイプのテーブルである、例１０に記載の非一時的なコンピュータ可読媒体。
（例１３）
データベースに対するデータベースクエリを受信する前に、
アプリケーションの特定のバージョンから、アプリケーションに対する更新を受信することであって、更新は、特定のバージョンに関連付けられている、受信することと、
受信した更新に基づいて、１つ以上のカタログテーブルを変更することであって、変更は、特定のバージョンでアクセス可能なデータベースに記憶された１つ以上のデータベースオブジェクトを指定するカタログテーブルに記憶されたメタデータを変更することと、を更に含む、例１０に記載の非一時的なコンピュータ可読媒体。
（例１４）
カタログテーブルのうちの１つは、少なくとも１つのアプリケーションに対して、その１つのアプリケーションに適用可能なスキーマを指定するスキーマカタログテーブルである、スキーマカタログテーブルは、異なるアプリケーションに対応するスキーマ名を指定する、例１０に記載の非一時的なコンピュータ可読媒体。
（例１５）
インデックステーブルをデータベースに追加することと、
インデックステーブルを追加することに基づいて、データベース内の１つ以上のインデックステーブルに対するメタデータを含むインデックスカタログテーブルに行を追加し、行は、データベースに記憶された１つ以上のデータベースオブジェクトがアクセス可能であるアプリケーションの１つ以上のバージョンを示す情報を指定する開始バージョン列及び停止バージョン列に対するそれぞれの値を含む、例１０に記載の非一時的なコンピュータ可読媒体。
（例１６）
データベースクエリに対するバージョンアクセス情報は、アプリケーションの特定のバージョンに対して、１つ以上のデータベースオブジェクトに含まれるデータの第１の部分へのアクセスを許可し、動作は、
アプリケーションの異なるバージョンから追加のデータベースクエリを受信することに応答して、アプリケーションの異なるバージョンに対するバージョンアクセス情報に基づいて、１つ以上のデータベースオブジェクトに含まれるデータの異なる第２の部分にアクセスすることを更に含む、例１０に記載の非一時的なコンピュータ可読媒体。
（例１７）
アプリケーションの特定のバージョンによって、データベース管理システム（ＤＢＭＳ）に、データベースに対するデータベースクエリを送信することであって、データベースクエリは、アプリケーションの特定のバージョンを指定し、データベースは、１つ以上のカタログテーブルの１つ以上のバージョン情報列にバージョンアクセス情報を維持する、送信することと、
アプリケーションの特定のバージョンによって、ＤＢＭＳから、データベースクエリに応答するデータを受信することであって、データは、１つ以上のデータベースオブジェクトが、アプリケーションの特定のバージョンにアクセス可能であることを示すバージョンアクセス情報に基づいて、データベースから検索される、受信することと、を含む、方法。
（例１８）
アプリケーションの特定のバージョンによって、ＤＢＭＳに、１つ以上のデータベースオブジェクトに対する更新を送信することであって、更新は、特定のバージョンに関連付けられており、更新は、１つ以上のカタログテーブルに記憶されたメタデータに対する変更を含む、送信することを更に含む、例１７に記載の方法。
（例１９）
カタログテーブルのうちの１つは、少なくとも１つのアプリケーションに対して、その１つのアプリケーションに適用可能なスキーマを指定するスキーマカタログテーブルである、例１７に記載の方法。
（例２０）
１つ以上のバージョン情報列は、データベースに記憶された１つ以上のデータベースオブジェクトがアクセス可能であるアプリケーションバージョンの範囲を示す情報を指定するバージョン列を含む、例１７に記載の方法。

【0084】

特定の実施形態が上述されたが、これらの実施形態は、たとえ単一の実施形態が特定の特徴に関して記載されている場合でも、本開示の範囲を限定することを意図するものではない。本開示において提供される特徴の例は、特に断らない限り、限定的ではなく例示的であることを意図している。上記の説明は、本開示の利益を有する当業者に明らかなような代替、修正、及び等価をカバーすることを意図している。

【0085】

本開示の範囲は、本明細書において対処された問題のうちのいずれか又は全部を緩和するか否かにかかわらず、本明細書に開示されている任意の特徴又は特徴の組み合わせ（明示的又は暗示的のいずれか）、又はその任意の一般化を含む。したがって、新たな請求項が、この出願（又はその優先権を主張する出願）のこのような特徴の組み合せに対するプロセキューション中に明確にされることがある。特に、添付の特許請求の範囲を参照すると、従属請求項からの特徴は、独立請求項の特徴と組み合わせてもよく、それぞれの独立請求項からの特徴は、添付の特許請求の範囲に列挙された特定の組み合わせのみでなく、任意の適切な様式で組み合わされ得る。

【図1】

【図2】

【図3】

【図4】

【図5A】

【図5B】

【図5C】

【図5D】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】