JP5380540B2 - データ層アプリケーションコンポーネント - Google Patents

Description

本発明は、データ層アプリケーションコンポーネントに関する。

アプリリケーションのオーサリング、インストールおよび実行時を含むアプリケーションのライフサイクル中、一般的に、多くの異なるオブジェクトが作成され、あるいは、アプリケーションに関連付けられる。例えば、プログラムコード、実行コード、ソフトウェアリソース、および、ハードウェアリソースが、アプリケーションに関連付けられ、また、このアイテムそれぞれが、種々のファイル名およびファイル型およびファイル形式に割り当てられる。データベースアプリケーションを、プログラムコード、実行コードおよびリソースに関連付ける他に、ログイン、テーブル、ストアドプロシージャおよびデータベースポリシー等の追加のオブジェクトに関連付けることができる。

トラッキングおよび維持の対象となるオブジェクトが多いと、データベースアプリケーションにそのライフサイクルを通して関連付けられる全てのアイテムを、データベース管理者が効果的に管理することは、難しくかつ時間がかかる場合が多い。例えば、データベース管理者が、データベースアプリケーションにより使用されるハードウェアまたは他のアイテムに変更を加えたい場合、または、データベースアプリケーションがインストールされるデータベースサーバインスタンスを追加または変更したい場合、所望の変更を加える処理は、時間がかかり、かつ高コストなものとなってしまう。オブジェクトは、コード化することができ、または、オブジェクトが常駐するハードウェアリソースもしくはそこで動作するハードウェアリソースに直接リンクさせることができる。また、そのようなオブジェクトを他の場所に移動させることは、多大な再プログラミングを伴うことになる。アプリケーションオブジェクトが複数の場所に記憶される場合、または、単一のデータベースが複数のアプリケーションにより使用されるオブジェクトを記憶する場合、オブジェクトの移動または追加のインストールに伴う労力が増大する。

データベースアプリケーションのライフサイクルの段階での高度な管理の生産性を達成するために、データベースアプリケーションを構成するアイテム、またはアプリケーションにより使用されるアイテムを関連付ける、グルーピング抽象化を有することは有益である。ソフトウェアのグルーピング抽象化が無いと、データベースアプリケーションの識別、概念化、移動、または複製、あるいは管理は非常に難しい。本明細書に開示される実施形態は、例えば、データベースアプリケーションを全体として移動または複製することを許可する、データベースオブジェクトのメタデータに関連するコンテナ内の、データベースアプリケーションの要素を関連付ける。コンテナは、ランタイムリソース識別子をデータベース要素に関連付け、このランタイムリソース識別子により、ハードウェアもしくは他のランタイムリソースの変更を可能にし、または、データベースアプリケーションの要素を選択して、要素を再コード化することなく異なるリソースを使用することを可能にする。

加えて、複数のデータベースアプリケーションコンテナは自身を、全体として移動、複製、または管理することを可能にする単一のグルーピングまたはファブリックに、関連付けることができる。ファブリックは、データベースアプリケーションの要素により使用されるリソース識別子を参照して、複数のデータベースアプリケーションの管理を可能にする。

特定の実施形態に従って、コンピュータ可読媒体が、データベースオブジェクトに関するメタデータをパッケージ化する管理の一単位を含む、ＤＡＣ（ｄａｔａ−ｔｉｅｒ ａｐｐｌｉｃａｔｉｏｎ ｃｏｍｐｏｎｅｎｔ：データ層アプリケーションコンポーネント）を記憶する。データベースオブジェクトに関するメタデータには、データベースオブジェクトの識別子、データベースオブジェクトを操作するよう動作可能なデータベースランタイムリソースのデータベースランタイムリソース識別子、および、データベースランタイムリソースの実行に関するポリシーが含まれる。

本概要は、以下の「発明を実施するための形態」でさらに説明される概念から選択したものを簡略化した形式で紹介するために提供するものである。本概要は、特許請求の範囲に記載されている主題の重要な特徴または本質的な特徴を特定することを意図するものでも、特許請求の範囲に記載されている主題の範囲を決定する際の一助として使用することを意図するものでもない。

ＤＡＣを使用するデータベース開発ツールを例示するブロック図である。 ＤＡＣおよびＤＡＣパッケージを使用してＤＡＣインスタンスをインストールする方法を例示するフロー図である。 ＤＡＣの特定の実施形態を例示する概略図である。 関連するＤＡＣ名を有するＤＡＣの第２の実施形態を例示するブロック図である。 一組のＤＡＣを含むサーバファブリックの特定の実施形態を例示するブロック図である。 一組のＤＡＣを含むサーバファブリックの第２の実施形態を例示するブロック図である。 サーバファブリックのエンティティにおいてデータベース管理アクションおよびポリシーを適用する方法を例示するフロー図である。 サーバファブリックのエンティティの関係を例示するフロー図である。 データベースアプリケーションを管理するシステムの実施形態のブロック図である。 サーバファブリック要素を処理する方法を例示するフロー図である。 ＳＱＬインスタンスを管理するためのシステムの第１の特定の実施形態を例示するブロック図である。 ＳＱＬインスタンスを管理するためのシステムの第２の特定の実施形態を例示するブロック図である。 ＳＱＬインスタンスを管理するためのシステムの第３の特定の実施形態を例示するブロック図である。 ＳＱＬインスタンスを管理するためのシステムの第４の特定の実施形態を例示するブロック図である。 ＳＱＬインスタンスを管理するためのシステムの第５の特定の実施形態を例示するブロック図である。 ＳＱＬインスタンスを管理するためのシステムの第６の特定の実施形態を例示するブロック図である。

特定の実施形態により、データベースアプリケーションの要素を識別し、かつ、データベースアプリケーションのための管理の一単位を提供する、ＤＡＣ（ｄａｔａ−ｔｉｅｒ ａｐｐｌｉｃａｔｉｏｎ ｃｏｍｐｏｎｅｎｔ：データ層アプリケーションコンポーネント）の使用について記載する。ＤＡＣにより識別されるデータベースアプリケーションは、データベースオブジェクト識別子および／またはデータベースオブジェクトのメタデータに関連付けられ、これらを介してデータベースアプリケーションを操作することが可能である。加えて、データベースランタイム識別子は、データベースアプリケーションの要素により使用されるランタイムリソースの内の１つまたは複数と関連付けられる。データベースランタイムリソースの実行に関する１つまたは複数のポリシーはまた、ＤＡＣにより識別される。その結果、データベースオブジェクト識別子によりＤＡＣを参照して、データベースアプリケーションを変更、移動または複製することが可能である。同様に、それぞれの要素に関連付けられるデータベースランタイム識別子を変更することにより、ランタイムリソースを変更することができ、かつ、データベースアプリケーションを複製することができる。その結果、データベース管理者は、データベースアプリケーションのインスタンスの編成の側面を管理することに時間と注意を費やすことなく、データベースアプリケーションのコンテンツの管理に集中することができる。

特定の実施形態では、コンピュータ可読媒体として実装することができるＤＡＣ（ｄａｔａ−ｔｉｅｒ ａｐｐｌｉｃａｔｉｏｎ ｃｏｍｐｏｎｅｎｔ：データ層アプリケーションコンポーネント）を開示する。ＤＡＣには、データベースオブジェクトに関するメタデータをパッケージ化する管理の一単位が含まれる。データベースオブジェクトに関するメタデータには、データベースオブジェクトの識別子が含まれる。メタデータにはまた、データベースオブジェクトを操作するよう動作可能なデータベースランタイムリソースのデータベースランタイムリソース識別子が含まれる。メタデータには、データベースランタイムリソースの実行に関するポリシーも含まれる。加えて、上述の管理の一単位が、複数のデータベースオブジェクト、複数のランタイムリソース、およびデータベースランタイムリソースの実行に関する複数のポリシーのメタデータを含むことができることを理解されたい。さらに、データベースオブジェクトのメタデータには、データベースオブジェクト識別子、データベースオブジェクトのスキーマ（例えば、テーブルの列スキーマ、ストアドプロシージャおよび／またはストアドファンクションのテキストボディ）、データベースオブジェクトに関する許可、および／または他のメタデータのエントリであって、データベースサーバ内のオブジェクトを作成または変更するために、および／または、データベースオブジェクトについてリーズニングするために使用することが可能な他のメタデータのエントリを含むことができる。

別の特定の実施形態では、データベース要素を一組の支援コンピュータリソースに関連付けるための、コンピュータ実装システムを開示する。システムには、１つまたは複数のデータベースオブジェクトに関するメタデータを含むデータベース要素のコレクションを含む、ＤＡＣ（ｄａｔａ−ｔｉｅｒ ａｐｐｌｉｃａｔｉｏｎ ｃｏｍｐｏｎｅｎｔ：データ層アプリケーションコンポーネント）が含まれる。データベース要素のコレクションにはまた、データベースオブジェクトを操作するよう動作可能なデータベースランタイムリソースのデータベースランタイムリソース識別子、および、データベースランタイムリソースの実行に関するポリシーが含まれる。ＤＡＣは、データベース要素のコレクションに関連付けられるＤＡＣ名を有する。ＤＡＣ名は、データベースアプリケーションによる使用のためにアクセス可能である。データベース要素のコレクションは、一組のユーザ選択可能な支援コンピュータリソースに、プログラム可能に関連付けられる。特定の実施形態では、ＤＡＣ名が不変のままとしながら、支援コンピュータリソースを変更することができる。

別の特定の実施形態では、ＤＡＣ（ｄａｔａ−ｔｉｅｒ ａｐｐｌｉｃａｔｉｏｎ ｃｏｍｐｏｎｅｎｔ：データ層アプリケーションコンポーネント）を配置する方法を開示する。方法は、ＤＡＣモデルを作成するステップを含む。ＤＡＣモデルには、１つまたは複数のデータベースオブジェクトに関するメタデータを含むデータベース要素のコレクションが含まれる。１つまたは複数のデータベースオブジェクトに関するメタデータには、各データベースオブジェクトの識別子、データベースオブジェクトを操作するよう動作可能なデータベースランタイムリソースのデータベースランタイムリソース識別子、および、データベースランタイムリソースの実行に関するポリシーが含まれる。方法は、ＤＡＣモデルに基づきＤＡＣパッケージをビルドするステップ、および、ＤＡＣ型をＤＡＣパッケージからサーバファブリックにインポートするステップを含む。方法はさらに、ＤＡＣ型を配置して、配置されるＤＡＣインスタンスを作成するステップを含む。

開示される主題には、データベースアプリケーションを構成するアイテムを関連付ける、ソフトウェアのグルーピング抽象化が含まれる。ソフトウェアのグルーピング抽象化により、データベースアプリケーションの識別、概念化、および管理が可能となる。本開示には、データベースアプリケーションに関連付けられるデータベースオブジェクト、ポリシー、およびランタイムリソースを効果的にモデル化する、ＤＡＣ（ｄａｔａ−ｔｉｅｒ ａｐｐｌｉｃａｔｉｏｎ ｃｏｍｐｏｎｅｎｔ：データ層アプリケーションコンポーネント）と呼ばれる抽象化が含まれる。

ＤＡＣは、バージョニングを含む、アプリケーションのライフサイクル全体の管理の一単位を形成する。例えば、ＨＲ（Ｈｕｍａｎ Ｒｅｓｏｕｒｃｅｓ：人的資源）ＤＡＣは、ＨＲ ＤＡＣが支援するＨＲアプリケーションコードと併せて開発することができる。ＨＲアプリケーション実行コードがアプリケーションサーバに配置されるため、ＨＲ ＤＡＣは、Ｍｉｃｒｏｓｏｆｔ（登録商標） ＳＱＬ Ｓｅｒｖｅｒのインスタンスに配置される。そして、ＨＲ ＤＡＣを監視および管理することが可能である。例えば、ＨＲ ＤＡＣへの予測される負荷が、ＨＲ ＤＡＣを保持するカレントサーバの容量を超える恐れがある場合、ＨＲ ＤＡＣを、新しいサーバに移動させることができる。移動は、ＤＡＣに関連付けられるデータベースオブジェクト識別子によってデータベースアプリケーションを参照することにより、かつ、データベース要素に関連付けられるデータベースランタイム識別子を変更して新しいサーバのランタイムリソースを参照することにより達成することができる。ＤＡＣは、一般には複数のタイプのデータベースランタイム環境に、および／または、特にはＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒランタイム環境にまで亘り、これらには、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒデータベース、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒデータベースエンジン、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ Ａｎａｌｙｓｉｓ Ｓｅｒｖｉｃｅｓ、 Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ Ｒｅｐｏｒｔｉｎｇ Ｓｅｒｖｉｃｅｓ、および、データベースサーバおよび／または異なるベンダおよびタイプのデータベースのインスタンスが含まれる。

加えて、本開示では、データベースサーバおよび／またはＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ環境を全体として管理することに効果をもたらすことができ、ＤＡＣの管理により重きをおき、個々のコンピュータ、データベースインスタンス、およびデータベースの管理にはそれほど着目しない。本開示は、このことに対して「サーバファブリック」の概念（「サーバファブリック」とも称する）を介して対処する。「サーバファブリック」の概念は、編成のＤＡＣ、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒランタイム、およびハードウェアリソースの全てをモデル化する。サーバファブリックは、ＤＡＣ、ランタイム、およびリソース層におけるエンティティおよびコンテナの統一されたビューを提供し、かつ、エンティティ間のより動的なマッピングを可能にする。サーバファブリックにはまた、管理アクションを宣言および起動するための中央管理ポイント、中央ポリシー管理者、および影響、ｗｈａｔ−ｉｆ（仮定）、もしくは配置の分析等の分析に使用されるモデルまたはデータを含有する中央リーズニング（動作推定）ポイントが含まれる。これらの宣言的、モデル駆動の特徴により、データベース管理者および開発者は、グローバルな管理アクションを定義することができる。グローバルな管理アクションは、編成の規則を実施し、ＤＡＣに必要な全ての特徴を有するランタイムに対してＤＡＣが配置されることを確実にし、および、サーバファブリック内のエンティティが、最小限の手動の介入で環境の変化に対応することを可能とする。

データベース管理者および開発者にとって、データ層アプリケーションコンポーネントの開発、配置および管理が著しく容易になるよう、サーバファブリック内のエンティティの状態についてのより深い知見により駆動されるこれらの自己管理能力が求められる。本開示は、データベース管理者および開発者が、そのライフサイクルを通して自分のアプリケーション管理において、より生産的であることを可能にする。これにより、データベース管理者および開発者は、追加のデータプラットフォーム技術およびストレージプラットフォーム技術をそのシステムに組み込むことに、より時間を費やすことができる。

本開示では、着目点を従来のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒのインスタンスおよびコンピュータから、データベースアプリケーションに移す。ＤＡＣは、データベースアプリケーションのインスタンスおよびデータベースコンテナの両方の上にある新しい高レベルの抽象化である。ＤＡＣには、従来の３層アプリケーションのデータレイヤサポートを形成する一組のデータベースエンティティが含まれる。現代のシステムでは、データベースアプリケーションは、複数のデータベースに及ぶことが多く、また、システムレベルのアプリケーション情報が「ｍａｓｔｅｒ」および「ｍｓｄｂ」等のシステムデータベース内に記憶される。

より具体的には、本開示では、ＤＡＣと呼ばれるコンテナ内にデータベースアプリケーションをモデル化する。ＤＡＣは、データベースアプリケーションのアーチファクト、関連するポリシー、および参照されるランタイムリソースの全てをアプリケーションに対してまとめる論理的表現である。各ＤＡＣは、管理の一単位として機能する。ポリシーを、ＤＡＣに対して適用することができ、ＤＡＣを、全体として移動することができる。ポリシーを使用して、必要とされるまたは好ましい、成果または検討事項の開発者または配置の意図を明らかにすることができる。例えば、開発者は、ＤＡＣが６４ビットランタイムで配置可能であるだけである、というポリシーを指定することにより必要な意図を宣言することができる。

サーバファブリックは、一組のＤＡＣをモデル化し、それらを、下層のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒランタイム（インスタンスまたはマトリクスなど）、および、ランタイムにより使用されるハードウェアリソースにマッピングする。サーバファブリックは、一組のＤＡＣが機能するのに必要とする全てのランタイムおよびハードウェアリソースのモデルを提供する。サーバファブリックはまた、他の技術を使用すると非常に複雑になるアクションを簡略化させる中央集中管理の特性を提供する。例えば、各ＤＡＣは、サーバファブリックにより管理される１つまたは複数の周知の名称（「エンドポイント名」）を有する。エンドポイント名は、ＤＡＣにより使用されているハードウェアリソースまたはインスタンスとは無関係である。その結果、アプリケーションは、コンピュータ名およびインスタンス名の代わりにエンドポイント名を使用して接続する。そのためアプリケーションの変更を要求せずに、ＤＡＣをインスタンス間で移動させることができる。

全ての利用可能なＤＡＣ、ランタイム、およびリソースのモデルを、サーバファブリック内の中央管理リーズニング能力と組み合わせることによって、いくつかのシナリオが可能になる。例えば、サーバファブリック内の全てのＤＡＣのリソースの使用を、監視することができる。別の例として、中央リーズニングエンジンは、ホストのランタイムに割り当てられるリソースに対するＤＡＣの将来の作業負荷を予測することができる。別の例として、予測されるリソースの不足に応じてアクションを起こすことができる。例えば、システムは、ランタイムに利用可能なリソースを動的に統括し、余剰能力を有するランタイムを発見し、アプリケーションの接続に影響が無いようにＤＡＣをそのライタイムに移動させる。ツールと能力の組は、サーバファブリックにおいてＤＡＣをそのライフサイクル（開発、配置および管理）を通して管理するものとして記載される。

特定の実施形態では、ＤＡＣは、データベースオブジェクト、データベースオブジェクトを操作するよう動作可能なデータベースランタイムリソースのデータベースランタイムリソース識別子、およびデータベースランタイムリソースの実行に関するポリシーのメタデータをパッケージ化する管理の一単位である。図１に例示するように、異なるアクションを、ライフサイクルの状態に応じてＤＡＣに適用することが可能である。

例えば、図１を参照すると、ユーザ１００（例えば、開発者）は、ＤＡＣモデル１０２を作成することができる。ＤＡＣモデル１０２には、ＤＡＣ（ｄａｔａ−ｔｉｅｒ ａｐｐｌｉｃａｔｉｏｎ ｃｏｍｐｏｎｅｎｔ：データ層アプリケーションコンポーネント）１０４が含まれる。ＤＡＣ１０４は、ＤＡＣコンテナ１０６に含むことができる。ＤＡＣ１０４には、データベース要素のコレクションが含まれる。図１に示すように、ＤＡＣ１０４には、第１の要素１０８、第２の要素１１０、および第３の要素１１２が含まれる。第１の要素１０８は、データベースオブジェクト識別子を含むデータベースオブジェクトのメタデータを含み得る。第２の要素１１０は、データベースオブジェクトを操作するよう動作可能なデータベースランタイムリソースを含み得る。第３の要素１１２は、データベースランタイムリソースの実行に関するポリシーを含み得る。ＤＡＣモデル１０２で表されるデータベースアプリケーションの開発中に、ユーザ１００は、ＤＡＣモデル１０２の作成、エディット、認証をすることができ、かつ、ＤＡＣモデル１０２を表現するものをＤＡＣプロジェクト１１４として保存することができる。ＤＡＣプロジェクト１１４には、１つまたは複数のファイル１１８を含むことができる。次にＤＡＣプロジェクト１１４を、データベースアプリケーションの開発中に、ソースコントロールシステムまたはソースコントロールデータベース１１６にチェックインおよびソースコントロールシステムまたはソースコントロールデータベース１１６からチェックアウトすることができる。

ユーザ１００（例えば、開発者）が、ＤＡＣモデル１０２で表されるデータベースアプリケーションの開発を完了すると、ＤＡＣモデル１０２は、ＤＡＣモデル１０２に基づいてコンパイル、またはビルドされ、完成したＤＡＣパッケージ１２０にまとめられる。ＤＡＣパッケージ１２０は、所望の通りに複製および配置することができるＤＡＣモデル１０２の概念化されたバージョンを表すＤＡＣ型１２２として、サーバファブリック（例えば、サーバファブリック１２６）にインポートすることができる。ＤＡＣ型１２２を配置して、配置されるＤＡＣインスタンス１２４を作成することができる。ＤＡＣインスタンス１２４は、ＤＡＣモデル１０２として開発されたデータベースアプリケーションの実用化インストールを表す。従って、開発者は、ＤＡＣモデル１０２を開発しつつ、データベースアプリケーションを再コード化せずに複製することができるポータブルなデータベースアプリケーションを作成したことになる。開発者はまた、ＤＡＣインスタンス１２４を配置する前にＤＡＣ型１２２を構成することができる。さらに、ＤＡＣインスタンス１２４は、特定の組の物理的コンピュータリソースに対してインストールすることができる。

図２を参照すると、データ層アプリケーションコンポーネントを配置する特定の方法のフロー図が例示される。方法は、２０２にて、１つまたは複数のデータベースオブジェクトのメタデータを含むデータベース要素のコレクションを含有するＤＡＣモデルを作成するステップを含む。ＤＡＣモデルにはさらに、データベースオブジェクトを操作するよう動作可能なデータベースランタイムリソースのデータベースランタイムリソース識別子が含まれる。ＤＡＣモデルにはさらに、データベースランタイムリソースの実行に関するポリシーが含まれる。特定の実施形態では、２０４にて、方法は、ＤＡＣモデルを表現するものをＤＡＣプロジェクトとして保存するステップ、および、選択的に、ＤＡＣプロジェクトをソースコントロールシステムまたはソースコントロールデータベースにチェックインしてＤＡＣプロジェクトを記憶するステップを含む。別の特定の実施形態では、２０６にて、方法は、ＤＡＣパッケージをビルドする前に、ＤＡＣモデルをエディットし、ＤＡＣモデルを認証するステップと、ＤＡＣインスタンスを配置する前にＤＡＣ型を構成するステップと、ＤＡＣインスタンスを特定の組の物理的コンピュータリソースに対してインストールするステップとを含む。２０８に移って、方法は、ＤＡＣモデルに基づきＤＡＣパッケージをビルドするステップを含む。２１０に移って、方法は、ＤＡＣ型をＤＡＣパッケージからサーバファブリックにインポートするステップを含む。２１２に移って、方法は、ＤＡＣ型を配置して、配置されるＤＡＣインスタンスを作成するステップを含む。

ＤＡＣが、サーバファブリック内にＤＡＣ型とＤＡＣインスタンスという２つの主要な細分割部を有することは強調すべきことである。ＤＡＣ型は、ＤＡＣがサーバファブリックにインポートされる時に構築される。ＤＡＣ型は、ＤＡＣにおいてテーブルおよびキューブ等のオブジェクトの論理的実装を定義し、どのようにＤＡＣが使用されることを開発者が意図するかを定義するポリシーを含む。ＤＡＣインスタンスは、サーバファブリックにおいて、１つまたは複数のデータベースサーバランタイム（例えば、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒランタイム）にＤＡＣ型が配置される時に、構築される。ＤＡＣインスタンスは、ＤＡＣ型のエンティティがそれらのサーバランタイム層におけるホストにどのようにマッピングされるかを記録する。ＤＡＣインスタンスには、どのようにＤＡＣがサーバファブリック内で動作することを管理者が意図するかを定義するポリシーを含む。

図３を参照すると、ＤＡＣ（ｄａｔａ−ｔｉｅｒ ａｐｐｌｉｃａｔｉｏｎ ｃｏｍｐｏｎｅｎｔ：データ層アプリケーションコンポーネント）のコンテンツの高レベルの図が例示される。この図は、開発者の意図（ＤＡＣ型）と配置の意図（ＤＡＣインスタンス）との概念的な分離を例示する。図３に示すように、ＤＡＣは、ＤＡＣ型３０４とＤＡＣインスタンス３０６とに概念的に分割することができる。ＤＡＣ型３０４には、構造、ロジック、ポリシーおよびＤＡＣ定義を備える他のエンティティが含まれる。ＤＡＣ型３０４により、開発者が、不変条件、要求、ならびに、意図されるＤＡＣ３０２の使用および解釈を正式に定義するための機構を提供することもできる。ＤＡＣ型３０４を備えるエンティティは、一単位として管理されることが意図される。情報は、ＤＡＣ３０２の特定のバージョンの全ての配置に対してグローバルである。従って、ＤＡＣ型３０４は、開発者の意図を表現すること、バージョニングすること、特定のバージョンに対して不変であることができ、また、一意的であることが保証される識別子を有する。編成の目的で、ＤＡＣ型３０４の３つの主要な部分は、プロパティ３０８、アプリケーションスキーマ３１０、開発者の意図とポリシー３１２として示される。

ＤＡＣ型３０４のプロパティ３０８は、ＤＡＣ型３０４に特有の特徴または属性である。例えば、プロパティ３０８は、人が読める名称および記述を含むことができる。更なる例として、プロパティ３０８は、最大バージョン番号および最小バージョン番号等の１つまたは複数のバージョン識別子を含むことができる。更なる例として、プロパティ３０８は、ＤＡＣ型３０４に対して一意的であることが保証される識別子を含むことができる。更なる例として、プロパティ３０８は、周知のエンドポイント名を含むことができる。更なる例として、プロパティ３０８は、他のＤＡＣ型への依存関係を含むことができる。

ＤＡＣ型３０４のアプリケーションスキーマ３１０は、ＤＡＣ３０２を備えるＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒオブジェクトを定義する。ＤＡＣ型３０４のこの部分におけるオブジェクト定義は、ＤＡＣ３０２に固有のものであり、任意の変更によりＤＡＣ型の新しいバージョンを生成することができる。アプリケーションスキーマ３１０は、本質的には、ＤＡＣ３０２が「何」から成るのかを定義する。例えば、アプリケーションスキーマ３１０は、テーブル、キューブおよびデータマイニングモデル等のアプリケーション構造を含むことができる。さらなる例として、アプリケーションスキーマ３１０は、ストアドプロシージャ、ユーザ定義の関数、およびトリガ等のアプリケーションロジックを含むことができる。さらなる例として、アプリケーションスキーマ３１０は、アプリケーション定義の一部としてみなされる参照データを含むことができる。例えば、米国の郵便番号および他の郵便番号、または国番号および州番号等のルックアップデータが参照され得る。

ＤＡＣ型３０４の開発者の意図とポリシー３１２により、どのようにＤＡＣ３０２が使用または解釈されるよう意図されているかについての追加の情報が提供される。例えば、開発者の意図とポリシー３１２は、ＤＡＣ３０２を配置するために利用可能でなければならないサーバファブリックリソース要求を含むことができる。例えば、ＤＡＣ３０２は、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ ２００８に要求して、空間データ型とＣＬＲ統合、および８０ＧＢのディスク空き容量のサポートを可能にすることができる。更なる例として、開発者の意図とポリシー３１２は、ＤＡＣ３０２内に組み込まれるコンフィギュアビリティ（設定可能性）を定義する構成の意図（パラメータ化）を含むことができる。これにより、ＤＡＣのバージョンに影響を与えない、配置に特有の構成が可能にされ、この構成には配置時に提供可能なまたは提供しなければならない情報が含まれる。例えば、構成のパラメータは、配置の処理が、ファイルグループおよびＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒのインスタンスの名称など、サーバファブリックリソースの特定の型へのマッピングを提供しなければならないことを示すことができる。さらなる例として、開発者の意図とポリシー３１２は、ＤＡＣ３０２のどの部分を外部に公開するかを指定するインターフェース定義を含むことができる。これにより、公のインターフェースとＤＡＣ３０２の内部の実装の詳細とを分離することができる。例えば、インターフェース定義では、どのエンティティがクライアントアプリケーションまたは別のＤＡＣにより参照可能であるかを指定する。さらなる例として、開発者の意図とポリシー３１２は、このＤＡＣ３０２に対して実行されるクエリ等の作業負荷のプロファイル情報を含むことができる。

開発者の意図とポリシーの例には、ＤＡＣを配置するために利用可能でなければならないサーバファブリックリソース要求が含まれる。例えば、ＤＡＣは、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ ２００８に要求して、空間データ型とＣＬＲ統合および８０ＧＢのディスク空き容量のサポートを可能にすることができる。開発者の意図とポリシーの別の例には、ＤＡＣ内に組み込まれるコンフィギュアビリティを定義する構成の意図（パラメータ化）が含まれる。これにより、ＤＡＣのバージョンに影響を与えない、配置に特有の構成が可能にされ、この構成には配置時に提供可能なまたは提供しなければならない情報が含まれる。例えば、構成のパラメータは、配置の処理が、ファイルグループおよびＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒのインスタンスの名称など、サーバファブリックリソースの特定の型へのマッピングを提供しなければならないことを示すことができる。開発者の意図とポリシーの別の例には、ＤＡＣのどの部分を外部に公開するかを指定するインターフェース定義が含まれ得る。これにより、公のインターフェースとＤＡＣの内部の実装の詳細とを分離することができる。例えば、インターフェース定義では、どのエンティティがクライアントアプリケーションまたは別のＤＡＣにより参照可能であるかを指定する。開発者の意図とポリシーの別の例には、ＤＡＣに対して実行されるクエリ等の作業負荷のプロファイル情報が含まれ得る。

図３に示すように、ＤＡＣインスタンス３０６は、実際のインスタンスまたは配置に特有の情報を保存する。この情報は、特定の配置に対して一意的である。ＤＡＣインスタンス３０６は、配置の意図を表現する。ＤＡＣインスタンス３０６は、ＤＡＣ型３０４に関連付けられる。複数のＤＡＣインスタンスが、各ＤＡＣ型３０４に対して存在することが可能である。ＤＡＣインスタンス３０６は、サーバファブリック内において一意的であることが保証される識別子を有する。ＤＡＣインスタンス３０６は、サーバファブリックマッピングを含有する。

ＤＡＣインスタンス３０６のプロパティ３１４は、ＤＡＣ３０２の配置インスタンスに特有の特徴または属性である。プロパティ３１４には、ＤＡＣインスタンス３０６識別子および配置の名称等のアイテムが含まれる。

ＤＡＣインスタンス３０６の配置スキーマ３１６は、特定の配置に対して特有のＳＱＬオブジェクトを定義するＤＡＣインスタンス３０６の一部である。配置スキーマ３１６には、プリンシパルおよびインデックス等のオブジェクトが含まれる。

ＤＡＣインスタンス３０６の配置の意図とポリシー３１８は、ＤＡＣ３０２が「どのように」配置または解釈されることが意図されるかについての情報を提供する。配置の意図とポリシー３１８には、特定の配置に対して特有の意図されるサーバファブリックマッピングおよび意図されるポリシー等のアイテムが含まれる。

ファブリックマッピング３２０は、ＤＡＣインスタンス３０６と下層のリソースとの間のマッピングを定義するＤＡＣインスタンス３０６の一部である。ファブリックマッピング３２０のコンテンツの例には、インスタンスまたはマトリクス等のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒランタイムマッピング、および、ディスクストレージおよびコンピュータ等のハードウェアリソースが含まれる。

データ３２２は、特定のＤＡＣインスタンスに関連するデータを表すＤＡＣインスタンス３０６の一部である。データ３２２には、アプリケーションのユーザにより作成されるアプリケーションデータと、ＤＡＣインスタンス３０６またはアプリケーションに対して特有の性能データ等の実用的データとの両方が含まれる。

図４を参照すると、４００にて、ＤＡＣ（ｄａｔａ−ｔｉｅｒ ａｐｐｌｉｃａｔｉｏｎ ｃｏｍｐｏｎｅｎｔ：データ層アプリケーションコンポーネント）の特定の実施形態が例示される。ＤＡＣ４０２には、データベース要素のコレクション４０４が含まれる。データベース要素のコレクション４０４には、データベースオブジェクトのデータベースオブジェクト識別子４０６が含まれる。データベース要素のコレクション４０４にはまた、データベースオブジェクトを操作するよう動作可能なデータベースランタイムリソースのデータベースランタイムリソース識別子４０８が含まれる。データベース要素のコレクション４０４にはまた、データベースランタイムリソースの実行に関するポリシー４１０が含まれる。ＤＡＣ４０２にはまた、データベース要素のコレクション４０４に関連付けられるＤＡＣ名４１２が含まれる。ＤＡＣ名４１２は、データベースアプリケーション４１４による使用のためにアクセス可能である。データベース要素のコレクション４０４は、４１６にて示すように、一組のユーザ選択可能な支援コンピュータリソース４１８に、プログラム可能に関連付けられる。

ＤＡＣ名４１２（例えば、エンドポイント名）は、ドメイン名サーバ（ＤＮＳ）名に若干類似して動作する。アプリケーション実行ファイルは、ＤＡＣ名に接続し、ＤＡＣ４０２をホストする特定のコンピュータまたはインスタンスには接続しない。ＤＡＣ４０２の特定のコンピュータまたはインスタンスへの関連付けは、ＤＡＣ４０２をコンピュータおよびインスタンスにマッピングすることにより、サーバファブリック内に確立される。ＤＡＣ４０２は、アプリケーションがデータベースサーバに接続する方法に影響を与えることなく（例えば、接続文字列に影響を与えることなく）、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒの新しいインスタンスにＤＡＣ４０２を単に再マッピングすることにより、新しいインスタンスに移動させることが可能である。変更の必要があるアプリケーションは無く、全て同じＤＡＣ名に接続している。例えば、給与というＤＡＣ名のＤＡＣを、コンピュータ１上のデフォルトのインスタンスからコンピュータ２上の別のインスタンスに移動することができる。全てのアプリケーションは、周知のＤＡＣ名である給与を参照するため、同じＤＡＣ４０２に接続している。

特定の実施形態では、一組のユーザ選択可能な支援コンピュータリソース４１８は、自動化ツール（例えば、ソフトウェアアプリケーション、ユーザ制御のアプリケーションなどであり、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ Ｍａｎａｇｅｍｅｎｔ Ｓｔｕｄｉｏ、Ｖｉｓｕａｌ Ｓｔｕｄｉｏ、ラインコマンド、Ｐｏｗｅｒｓｈｅｌｌ、等がある）を使用して変更することが可能である。別の特定の実施形態では、コレクションに関連付けられるＤＡＣ名４１２は、複数のデータベースアプリケーションからアクセス可能である。

別の特定の実施形態では、一組のユーザ選択可能な支援コンピュータリソース４１８は修正されるが、ＤＡＣ名４１２は不変である。

別の特定の実施形態では、データベース要素のコレクション４０４内のデータベース要素は修正されるが、ＤＡＣ名４１２は不変である。

別の特定の実施形態では、データベースランタイムリソースは、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒのインスタンスであり、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒのインスタンスが第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンスから第２のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンスに修正されるが、ＤＡＣ名４１２は不変である。

別の特定の実施形態では、データベース要素のコレクション４０４は変更することができ、または、一組のユーザ選択可能な支援コンピュータリソース４１８は変更することができ、かつ、ＤＡＣ名４１２は不変であるため、データベース要素のコレクション４０４が変更される時、または、一組のユーザ選択可能な支援コンピュータリソース４１８が変更される時は、１つまたは複数のデータベースアプリケーション（例えば、データベースアプリケーション４１４）のアプリケーションの接続文字列を、記録（例えば、変更、更新、アプリケーションの再コンパイルの要求、アプリケーションのバイナリおよび／または実行ファイルの再作成の要求）する必要が無い。

別の特定の実施形態では、ＤＡＣ名４１２を使用するデータベースアプリケーションは、異なるネットワークコンピュータ上に置かれる。

別の特定の実施形態では、データベースランタイムリソースの実行に関するポリシー４１０が、ＤＡＣ名４１２に適用され、データベース要素のコレクション４０４が変更される時、または、一組のユーザ選択可能な支援コンピュータリソース４１８が変更される時、ポリシー４１０は、適用が継続される。

別の特定の実施形態では、ＤＡＣ４０２は、データベース要素のコレクション４０４とインターフェースをとるＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍ ｉｎｔｅｒｆａｃｅ：アプリケーションプログラムインターフェース）をさらに備える。例えば、ＡＰＩは、データベース要素のコレクションの要素の利用を測定することができる。例えば、ＡＰＩにより、開発者は図１のようなデータベース要素のコレクション４０４とインターフェースをとることができる。

特定の実施形態では、ＤＡＣ４０２は、コンピュータ可読媒体に記憶される。コンピュータ可読媒体は、データベースオブジェクト、データベースオブジェクトを操作するよう動作可能なデータベースランタイムリソースのデータベースランタイムリソース識別子、およびデータベースランタイムリソースの実行に関するポリシーのメタデータをパッケージ化する管理の一単位を含むことができる。一度に１つずつであるように記載したが、管理の一単位が、複数のデータベースオブジェクト、データベースオブジェクトを操作するよう動作可能なデータベースランタイムリソースの複数のデータベースランタイムリソース識別子、およびデータベースランタイムリソースの実行に関する複数のポリシーのメタデータをパッケージ化することが可能であることを理解されたい。加えて、複数のデータベースオブジェクトは、スキーマ、テーブル、ビュー、ストアドプロシージャ、関数、トリガ、データ型、インデックス、ログイン、ユーザ、許可、ポリシー、統計値、主キー、外部キー、デフォルト、チェックの制約、および／または、データベースサーバまたはデータベースにおいて作成可能な任意の他のオブジェクトを含むことができる。

管理の一単位を、第１の物理的コンピュータリソースに対してマッピングすることができる。管理の一単位を、第１の物理的コンピュータリソースから第２の物理的コンピュータリソースに再マッピングすることができる。第１の物理的コンピュータリソースの例には、プロセッサまたはメモリストレージデバイスがある。特定の実施形態では、管理の一単位は、関連するＤＡＣ名により識別される。ここで、ＤＡＣ名はデータベースアプリケーションによる使用のためにアクセス可能である。

データベースオブジェクトを操作するよう動作可能なデータベースランタイムリソースは、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）サーバのインスタンスである。Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒのインスタンスには、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒデータベースエンジンのインスタンス、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ Ａｎａｌｙｓｉｓ Ｓｅｒｖｉｃｅｓのインスタンス、もしくは、ＳＱＬ Ｒｅｐｏｒｔｉｎｇ Ｓｅｒｖｉｃｅｓのインスタンス、または、他のデータベースのサーバタイプおよびベンダのインスタンスを含むことができる。

ポリシーは、リソース制限ポリシー、または、ソフトウェアリソースもしくはハードウェアリソースの要求に関するプロシージャを含むデータベースランタイムリソースの実行に関するものとすることができる。

図５を参照すると、５００にて、システムの特定の実施形態が例示される。システム５００には、一組のＤＡＣ５０２が含まれる。図５に示す実施形態では、第１のＤＡＣ５０４、第２のＤＡＣ５０６、および第３のＤＡＣ５０８が、一組のＤＡＣ５０２に含まれる。あるいは、一組のＤＡＣ５０２には、任意の数のＤＡＣを含むことができる。ＤＡＣ５０４、５０６、および５０８のそれぞれには、データベース要素のコレクション５１０、５１２、および５１４の論理的表現が含まれる。

システム５００には、一組のＤＡＣ５０２をホストする一組のデータベースランタイムリソース５１６がさらに含まれる。図５に示す実施形態では、一組のデータベースランタイムリソース５１６には、第１のデータベースランタイムリソース５１８、第２のデータベースランタイムリソース５２０、および第３のデータベースランタイムリソース５２２が含まれる。あるいは、一組のデータベースランタイムリソース５１６には、任意の数のデータベースランタイムリソースを含むことができる。

システム５００には、一組のデータベースランタイムリソース５１６により使用されて一組のＤＡＣ５０２をホストするコンピュータリソース５２４がさらに含まれる。図５に示す実施形態では、コンピュータリソース５２４には、第１のコンピュータリソース５２６、第２のコンピュータリソース５２８、および第３のコンピュータリソース５３０が含まれる。あるいは、コンピュータリソース５２４には、任意の数のコンピュータリソースを含むことができる。

コンピュータリソース５２４は、１つまたは複数のコンピュータサーバリソース、１つまたは複数のコンピュータデータストレージリソース、または、１つまたは複数の仮想マシンリソースを含むことができる。１つまたは複数のコンピュータサーバリソースのそれぞれは、プロセッサ、メモリ、またはネットワーク要素を含むことができる。１つまたは複数のコンピュータデータストレージリソースの少なくとも１つを、複数のファイルを含む記憶ボリュームとすることができる。１つまたは複数のコンピュータサーバリソースの少なくとも１つを、最初に第１のＳＡＮ（ｓｔｏｒａｇｅ ａｒｅａ ｎｅｔｗｏｒｋ：ストレージエリアネットワーク）にマッピングし、続いて、第２のＳＡＮにマッピングすることができる。

一実施形態では、一組のＤＡＣ５０２内のＤＡＣ５０４、５０６、および５０８のそれぞれには、ＤＡＣコンテナが含まれる。各ＤＡＣコンテナは、データベースオブジェクト、データベースオブジェクトを操作するよう動作可能なデータベースランタイムリソースのデータベースランタイムリソース識別子、および、データベースランタイムリソースの実行に関するポリシーのメタデータをパッケージ化する管理の一単位を含むことができる。

一組のＤＡＣ５０２内の第１のＤＡＣ５０４は、一組のＤＡＣ５０２内の第２のＤＡＣ５０６に依存することとしても良い。

一組のＤＡＣ５０２内のＤＡＣ５０４、５０６、および５０８のそれぞれは、サーバファブリック５０１のＤＡＣ層により表すことができる。コンピュータリソース５２６、５２８、および５３０を含むコンピュータリソース５２４は、サーバファブリック５０１のハードウェアリソース層により表すことができる。一組のデータベースランタイムリソース５１６内のデータベースランタイムリソース５１８、５２０、および５２２のそれぞれは、サーバファブリック５０１のＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）サーバランタイム層により表すことができる。

一組のデータベースランタイムリソース５１６は、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒサービスを提供する１つまたは複数のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒランタイムインスタンスを含むことができる。１つまたは複数のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒランタイムインスタンスは、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ Ａｎａｌｙｓｉｓ Ｓｅｒｖｉｃｅｓ、およびＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ Ｒｅｐｏｒｔｉｎｇ Ｓｅｒｖｉｃｅｓの１つまたは複数のインスタンスを含むことができる。さらに、１つまたは複数のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒランタイムインスタンスは、スキーマおよびビューを含むことができる。

ＤＡＣ５０４、５０６、および５０８のそれぞれを、データベースランタイムリソース５１８、５２０、および５２２の１つにマッピングすることができ、かつ、各データベースランタイムリソース５１８、５２０、および５２２を、１つまたは複数の物理的コンピュータリソース５２６、５２８、および５３０にマッピングすることができる。データベースランタイムリソースを、第１のコンピュータから第２のコンピュータに再マッピングすることができる。

ＤＡＣ５０４、５０６、および５０８のそれぞれは、関連するＤＡＣ名を含むことができる。ＤＡＣ名は、データベースアプリケーションによる使用のためにアクセス可能である。

図６を参照すると、一組のＤＡＣを含むサーバファブリックの第２の実施形態を例示するブロック図が、６００にて示される。サーバファブリック６０８は、一組のＤＡＣ（複数のＤＡＣ）、ＤＡＣをホストするＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒランタイム、および、それらのランタイムに使用されてＤＡＣをホストするリソースのモデルに基づく表現である。サーバファブリックのモデルは、図６に示すような３つの層を有し、すなわち、ＤＡＣ層６１０、サーバランタイム層６１２、およびホストリソース層６１４である。モデル内のオブジェクトの全ては、一組の一般的モデル化概念（ｎｏｕｎ）を使用して記述され、かつ、それらのオブジェクトに対して実行される一連のアクション（ｖｅｒｂ）を有する。

ＤＡＣ層６１０は、ＤＡＣのサーバファブリック定義をホストする。示される実施形態では、ＤＡＣ層６１０には、第１のＤＡＣ６２２、第２のＤＡＣ６２４、および第３のＤＡＣ６２６が含まれる。あるいは、ＤＡＣ層６１０には、任意の数のＤＡＣを含むことができる。サーバランタイム層６１２は、サーバファブリック６０８内にデータベースランタイムリソースのビュー（例えば、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒサービス）を提供する。示される実施形態では、サーバランタイム層６１２には、第１のデータベースランタイムリソース６１６、第２のデータベースランタイムリソース６１８、および第３のデータベースランタイムリソース６２０が含まれる。あるいは、サーバランタイム層６１２には、任意の数のデータベースランタイムリソースを含むことができる。ホストリソース層６１４は、サーバファブリック６０８内の要素により使用されるコンピューティングとストレージの容量を表す。示される実施形態では、ホストリソース層６１４には、第１のサーバ６３６および第２のサーバ６３８を含むサーバリソース６３０が含まれる。さらに、ホストリソース層６１４には、第１のストレージリソース６４０および第２のストレージリソース６４２を含むデータリソース６３２が含まれる。さらに、ホストリソース層６１４には、第１の仮想リソース６４４および第２の仮想リソース６４６を含む仮想リソース６３４が含まれる。あるいは、ホストリソース層６１４は、任意の数のサーバリソース、データリソース、または仮想リソースを含むことができる。

サーバファブリック６０８は、ＤＡＣ、一組のＤＡＣをホストするデータベースランタイムリソース、および、データベースランタイムリソースにより使用されＤＡＣをホストするコンピュータリソースを識別する。各ＤＡＣ６１０には、データベース要素のコレクションの論理的表現が含まれる。中央リーズニングポイント６０４は、サーバファブリック６０８のエンティティを監視する。中央ポリシー６０６は、サーバファブリック６０８により識別された影響を受けるエンティティにおいて、受け取ったデータベース管理アクションおよびポリシーを自動的に適用するために使用される。

サーバファブリック６０８内の各層は、４つのタイプのエンティティ、すなわち、コンテナ、要素、リソース、およびマッピングを含有する。コンテナは、サーバファブリック６０８の所与の層内の最高レベルのエンティティであり、管理および識別の直観的な一単位を提供する。コンテナの例には、ＤＡＣ、コンピュータ、仮想マシン、ストレージ、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒのインスタンス、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ Ａｎａｌｙｓｉｓ Ｓｅｒｖｉｃｅｓ、およびＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ Ｒｅｐｏｒｔｉｎｇ Ｓｅｒｖｉｃｅｓが含まれる。要素は、コンテナ内に存在するサーバファブリック６０８内の一単位である。例えば、テーブルおよびストアドプロシージャは、ＤＡＣ内に存在する要素である。リソースは、有限の容量を有する特定のタイプの要素であり、かつ、その容量を決めるプロパティを有する。プロセッサデバイスは、粒度の細かいリソースの例であり、そのクロック速度は、容量を決めるプロパティの一例である。ストレージデバイスは、物理ディスク等のより粒度の細かいリソースを含有するリソースの一例である。ストレージデバイスの容量は、ストレージデバイスが含有する物理的ディスクのプロパティのみにより決められるのではなく、ＲＡＩＤレベル等の構成のプロパティによっても決められる。マッピングは、サーバファブリック６０８の２つの部分の間の関係を表す。マッピングは、サーバファブリック６０８をＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ環境の実際のモデルに形成する、一般的モデル化概念である。マッピングは、コンテナとコンテナ、コンテナと要素、コンテナとリソース、要素と要素、要素とリソース、およびリソースとリソース間で行うことができる。

サーバファブリック６０８における各層６１０、６１２、および６１４の構成は、上述の一般的モデル化概念を適用することにより定義することができる。各層は、１つまたは複数のコンテナ、それらのコンテナ内の要素およびリソース、ならびに、サーバファブリック６０８の近接する層内のコンテナ間または要素間のマッピングから成る。

ＤＡＣ層６１０は、ＤＡＣのサーバファブリック定義をホストする。各ＤＡＣは、ＤＡＣコンテナを使用して定義される。各ＤＡＣコンテナは、構造、コード、バージョン、およびポリシー等のアプリケーションエンティティを表す多数の要素で構成される。

ＤＡＣ層６１０におけるマッピングにより、ＤＡＣとＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒランタイム（例えば、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒのインスタンス）との間の関係を記述する。例えば、ＤＡＣ層６１０内のＤＡＣを、サーバランタイム層６１２内のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒのインスタンスにマッピングすることが可能である。そして、ＤＡＣをインスタンス間に再マッピングすることにより、１つのインスタンスから別のインスタンスにＤＡＣを移動させることができる。例として、第１のＤＡＣ６２２は、第１のデータベースランタイムリソース６１６（例えば、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒの第１のインスタンス）にマッピングされ、また、次に第１のＤＡＣ６２２を第２のデータベースランタイムリソース６１８に再マッピングすることにより、第１のＤＡＣ６２２を、第２のデータベースランタイムリソース６１８（例えば、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒの第２のインスタンス）に移動させることができる。

マッピングではまた、ＤＡＣ間の関係について記述することもできる。ＤＡＣは、共通の要素の再利用を可能にするために別のＤＡＣへの依存関係を表現することができる。例えば、消耗品の注文のための企業のポリシーを実施する一組のストアドプロシージャ等の、いくつかのアプリケーションにより共有される要素を有する「ベースの」ＤＡＣを、定義することが可能である。それらの要素を必要とする任意の他のＤＡＣは、「ベースの」ＤＡＣにマッピングすることによりそれらを参照することができる。例えば、第１のＤＡＣ６２２は、第２のＤＡＣ６２４に依存することとしても良い。

サーバランタイム層６１２は、サーバファブリック内にＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒサービスを提供する。Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒランタイムコンテナには、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒのインスタンス、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ Ａｎａｌｙｓｉｓ Ｓｅｒｖｉｃｅｓ、およびＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ Ｒｅｐｏｒｔｉｎｇ Ｓｅｒｖｉｃｅｓのインスタンスが含まれる。各ランタイムコンテナは、１つまたは複数のデータベース要素を有することができる。データベース要素は、スキーマ、テーブル、ビュー、ストアドプロシージャ、関数、データ型、インデックス、ログイン、ユーザ、ポリシー、統計値、主キー、外部キー、デフォルト、チェックの制約、および／または、データベースサーバまたはデータベースにおいて作成可能な任意の他のオブジェクトを含むことができる。

サーバランタイム層６１２におけるマッピングにより、特定のＳＱＬランタイム（例えば、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒのインスタンス）と、そこに割り当てられる物理的リソースとの関係を記述する。例えば、サーバランタイム層６１２に存在するインスタンスが、ハードウェアリソース層６１４内の物理的コンピュータにマッピングされる。インスタンスは、インスタンスをコンピュータ間で再マッピングすることにより、物理的コンピュータ間で移動させることができる。例として、第１のデータベースリソース６１６を、第１のサーバ６３６にマッピングすることができ、かつ、第１のデータベースリソース６１６は、第１のデータベースリソース６１６を第１のサーバ６３６から第２のサーバ６３８に再マッピングすることにより、第２のサーバ６３８に移動させることができる。

ホストリソース層６１４は、サーバファブリック６０８内の要素により使用されるコンピューティングとストレージの容量を表す。ホストリソース層６１４におけるコンテナは、物理的コンピュータ、仮想マシン、および記憶ボリュームが含まれる。リソースコンテナはまた、サブ要素を含有することができる。例えば、物理的サーバは、プロセッサ、メモリ、およびネットワーク要素を含有する。記憶ボリュームは、ファイル要素とともに、言及したアーチファクトの記憶に関する他の要素を含有することができる。

ホストリソース層６１４におけるマッピングにより、物理的リソース間の関係を記述する。例えば、ホストリソース層のマッピングは、どのＳＡＮ ＬＵＮ（Ｌｏｇｉｃａｌ Ｕｎｉｔ Ｎｕｍｂｅｒ：論理ユニット番号））が、各物理的サーバからアクセス可能であるのかを表現する。物理的サーバとＳＡＮ ＬＵＮとの間のマッピングを変更することにより、ＳＡＮ ＬＵＮは、物理的サーバ間で移動させることができる。

サーバファブリック６０８は、サーバファブリック６０８全体に亘ってエンティティに適用することが可能な管理アクションおよびポリシーの中央宣言を支援する。サーバファブリック６０８の中央管理ポイント６０２は、データベース管理アクションおよびポリシーを受け取ることができる。サーバファブリック６０８はまた、サーバファブリックのエンティティを監視すること、かつ、管理アクションおよびポリシーを自動的に適用することが可能であるリーズニングエンジンを提供する。サーバファブリック６０８の中央管理機構が図６に例示される。

中央管理機構は全て、コンテナの関連する詳細、関係、および制約をサーバファブリック６０８に記録するモデルを参照する。

サーバファブリック６０８内のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒのインスタンスの１つは、中央管理ポイント６０２として指名され、中央集中管理の能力（ディスカバリ（発見）、ポリシー定義および監視等）を全てのサーバファブリック層に提供する。中央管理ポイント６０２は、全てのコンテナのアクションがトリガ（例えば、インポート、移動、作成、および配置）される場所である。中央管理ポイント６０２を、サーバファブリック６０８により識別されるデータベースランタイムリソースの１つにおいて、ホストすることができる。例えば、中央管理ポイント６０２を、第１のデータベースランタイムリソース６１６、第２のデータベースランタイムリソース６１８、または第３のデータベースランタイムリソース６２０においてホストすることができる。中央管理ポイント６０２は、サーバファブリック層６１０、６１２、および６１４に対してディスカバリ、ポリシー定義、および監視を提供することができる。

中央リーズニングポイント６０４は、サーバファブリック６０８内の要素のデータモデルを供給する。モデルは、リソース使用の傾向およびサーバファブリック６０８全体に亘る可能性のあるアクションの影響を予測するために、分析エンジンにより使用される。中央リーズニングポイント６０４を使用して、ＳＱＬサーバファブリック６０８により識別されるエンティティに対して中央リーズニングアクションを行うことができる。中央リーズニングアクションには、例えば、他のＤＡＣが第１のＤＡＣに依存しているような場合に、第１のＤＡＣをアンインストールすることの影響を推定する、第１のアクションを含むことができる。中央リーズニングアクションにはまた、例えば、コンピュータリソースの内の１つのメモリリソースを修正することの１つまたは複数のＤＡＣへの影響を推定する第２のアクションを含むことができる。中央リーズニングアクションにはまた、例えば、ＳＱＬサーバファブリック内のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒのインスタンスであって、配置対象のＤＡＣをホストするよう構成されるインスタンスのリストを提示する、第３のアクションを含むことができる。

中央ポリシー６０６には、挙動またはアクションを導くよう定義される正式な原則であるポリシーを含むことができる。ここで、ポリシーは、ＳＱＬサーバファブリック６０８により識別される一組のエンティティに適用することができる一組の条件を指定する。例えば、一組のエンティティは、１つまたは複数のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒランタイムインスタンスを含むことができ、かつ、ポリシーは、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒのソフトウェアバージョンに基づき、１つまたは複数のＭｉｃｒｏｓｏｆｔ ＳＱＬ ＳｅｒｖｅｒランタイムインスタンスのＳＱＬサーバファブリック６０８への組み込みを制限することができる。例として、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ２００８のインスタンスのみを、サーバランタイム層６１２に組み込むことができる。更なる例として、一組のエンティティは、１つまたは複数のコンピュータリソースを含むことができ、かつ、ポリシーは、オペレーティングシステムまたはメモリ容量に基づき、１つまたは複数のコンピュータリソースのＳＱＬサーバファブリック６０８への組み込みを制限することができる。例として、６４ビットバージョンのＷｉｎｄｏｗｓ Ｓｅｒｖｅｒ ２００８で、少なくとも４ギガバイト（４ＧＢ）のメモリを有するサーバのみを、ホストリソース層６１４に組み込むことができる。

中央管理ポイント６０２は、ＳＱＬサーバファブリックのアクションをトリガすることができる。例えば、ＳＱＬサーバファブリックのアクションは、インポートアクション、エクスポートアクション、配置アクション、コピーアクション、認証アクション、インストールアクション、アンインストールアクション、追加アクション、削除アクション、入手アクション、設定アクション、列挙アクション、移動アクション、作成アクション、保存アクション、アップグレードアクション、開始アクション、終了アクション、再起動アクション、実行アクション、一時停止アクション、再開アクション、無効化アクション、有効化アクション、測定アクション、監視アクション、予測アクション、統括アクション、マップアクション、アンマップアクション、ディスカバアクション、比較アクション、マージアクション、ブロックアクション、アンブロックアクション、承諾アクション、または、取り消しアクションを含むことができる。

ライフサイクルの一連のアクションにより、エンティティを、作成またはサーバファブリック６０８へのインポートの時間から、サーバファブリック６０８からの削除の時間まで管理するための一組のアクションを記述する。例えば、ライフサイクルの一連のアクションは、所与のエンティティの作成、修正、および消去のようなアクションを対象とする。いくつかのライフサイクルの一連のアクションは、１つまたは複数の層６１０、６１２、および６１４に適用することができる。ライフサイクルの一連のアクションには、インポートアクション、エクスポートアクション、配置アクション、コピーアクション、認証アクション、インストールアクション、アンインストールアクション、追加アクション、削除アクション、入手アクション、設定アクション、列挙アクション、移動アクション、作成アクション、保存アクション、およびアップグレードアクションが含まれる。

インポートアクションでは、新しいコンテナおよび関連する要素を、外部の永続的なデータストアから作成する。インポートアクションは、ＤＡＣ層６１０に適用することができる。例えば、インポートアクションにより、ＤＡＣをＤＡＣパッケージファイルからサーバファブリック６０８にインポートすることができる。エクスポートアクションは、永続的な外部のデータストア（例えば、ファイル）を、コンテナおよびそれに含まれる要素から作成する。エクスポートアクションは、ＤＡＣ層６１０に適用することができる。例えば、エクスポートアクションは、ＤＡＣをファイルにエクスポートすることができる。

配置アクションでは、コンテナおよびそのオブジェクトを意図される場所に置く。配置アクションは、ＤＡＣ層６１０に適用することができる。例えば、配置アクションは、第１のＤＡＣ６２２をサーバランタイム層６１２（例えば、第１のインスタンス６１６）内のインスタンスに配置することができる。

コピーアクションでは、一組の要素を１つのコンテナから別のコンテナにコピーする。コピーアクションは、ＤＡＣ層６１０およびサーバランタイム層６１２に適用することができる。例えば、コピーアクションにより、データベースをＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒの１つのインスタンスからサーバランタイム層６１２の別のインスタンスに（例えば、第１のインスタンス６１６から第２のインスタンス６１８に）コピーすることができる。

認証アクションでは、対象のコンテナ、要素、リソース、またはマッピングが指定された基準でコンパイルしているかどうかをチェックする。認証アクションは、ＤＡＣ層６１０、サーバランタイム層６１２、およびホストリソース層６１４に適用することができる。例えば、認証アクションにより、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ ＳｅｒｖｅｒのインスタンスがＣＬＲ統合を有効にしたことを認証することができる。

インストールアクションでは、サーバファブリック６０８においてＤＡＣを動作可能に構成する。インストールアクションは、ＤＡＣ層６１０およびサーバランタイム層６１２に適用することができる。例えば、インストールアクションにより、ＤＡＣを第１のインスタンス６１６にインストールすることができる。アンインストールアクションでは、コンテナおよびその要素を指定される場所から削除する。アンインストールアクションは、ＤＡＣ層６１０およびサーバランタイム層６１２に適用することができる。例えば、アンインストールアクションにより、ＤＡＣを第１のインスタンス６１６からアンインストールすることができる。

追加アクションでは、外部で作成されたコンテナ、要素、またはリソース、を表現するものをサーバファブリックに組み込む。追加のアクションは、サーバランタイム層６１２およびホストリソース層６１４に適用することができる。例えば、追加アクションにより、第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス６１６をサーバランタイム層６１２に追加することができる。削除アクションでは、外部で作成されたコンテナ、要素、またはリソースをサーバファブリック６０８との関連から切り離す。削除アクションは、サーバランタイム層６１２およびホストリソース層６１４に適用することができる。例えば、削除アクションにより、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス６１６をサーバランタイム層６１２から削除することができる。

入手アクションでは、コンテナ、要素、リソース、またはマッピング、の現在の構成を取り出す。入手アクションは、ＤＡＣ層６１０、サーバランタイム層６１２、およびホストリソース層６１４に適用することができる。例えば、入手アクションにより、第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス６１６にインストールされたＤＡＣのバージョン番号を入手することができる。

設定アクションでは、コンテナ、要素、リソース、またはマッピング、の現在の構成を更新する。設定アクションは、ＤＡＣ層６１０、サーバランタイム層６１２、およびホストリソース層６１４に適用することができる。例えば、設定アクションにより、第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス６１６にインストールされたＤＡＣのバージョン番号を設定することができる。

列挙アクションでは、コンテナ内の一組の要素またはリソースを入手する。列挙アクションは、ＤＡＣ層６１０、サーバランタイム層６１２、およびホストリソース層６１４に適用することができる。例えば、列挙アクションにより、第１のサーバ６３６にリソースを列挙することができる。

移動アクションでは、一組の要素またはリソースを１つのコンテナ、要素、またはリソースから、別のコンテナ、要素、またはリソースに移動させる。移動アクションは、ＤＡＣ層６１０、サーバランタイム層６１２、およびホストリソース層６１４に適用することができる。例えば、移動アクションにより、データベースをＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒの１つインスタンスからサーバランタイム層６１２内の別のインスタンスに移動させることができる。

作成アクションでは、新しいコンテナまたは要素を作成する。作成アクションは、ＤＡＣ層６１０およびサーバランタイム層６１２に適用することができる。例えば、作成アクションにより、ＤＡＣがＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ２００８を要求することを指定する新しいポリシーの制約を作成することができる。

保存アクションでは、コンテナ、要素、リソース、またはマッピングの現在の構成を存続させる。保存アクションは、ＤＡＣ層６１０、サーバランタイム層６１２、およびホストリソース層６１４に適用することができる。例えば、保存アクションにより、第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス６１６にインストールされたＤＡＣのバージョン番号を保存することができる。

アップグレードアクションでは、コンテナまたは要素の既存の構成を新しい定義に変換する。アップグレードアクションは、ＤＡＣ層６１０およびサーバランタイム層６１２に適用することができる。例えば、アップグレードアクションにより、第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス６１６にインストールされたＯｒｄｅｒｓテーブルの定義を第１のバージョンから第２のバージョンにアップグレードすることができる。

サーバファブリック６０８は、監視性能、照合変更、およびポリシー順守の認証等のアクションを実行するいくつかの処理を有する。以下の一組の一連のアクションを使用して、処理を管理することができる。その他の一連のアクションの全てが、サーバファブリック６０８の全ての層（例えば、ＤＡＣ層６１０、サーバランタイム層６１２、およびホストリソース層６１４）に適用される。処理制御の一連のアクションには、開始アクション、終了アクション、再起動アクション、実行アクション、一時停止アクション、再開アクション、無効化アクション、および有効化アクションが含まれる。

開始アクションでは、処理を開始し、処理は終了されるまで継続される。例えば、開始アクションは、第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス６１６の照合を開始する。終了アクションでは、処理の実行を中止する。例えば、終了アクションにより、第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス６１６の照合を終了することができる。再起動アクションでは、実行中の処理を終了させ、それを再度開始させる。例えば、再起動アクションにより、第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス６１６の照合を再起動することができる。実行アクションでは、実行されて完了時に自動的に終了する処理を、開始する。例えば、実行アクションにより、第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス６１６上でディスカバリを実行することができる。一時停止アクションでは、処理を中断し、処理は再開されるまで中断されたままにされる。例えば、一時停止アクションにより、第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス６１６上でディスカバリを一時停止させることができる。再開アクションでは、一時停止された処理を継続させる。例えば、再開アクションにより、第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス６１６上のディスカバリを再開することができる。無効化アクションでは、処理を利用できないように構成し、処理の開始を不可能にする。処理は、有効にされるまで無効のままになる。例えば、無効化アクションにより、第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス６１６の照合を無効にすることができる。有効化アクションでは、無効にされた処理が開始されるように構成する。例えば、有効化アクションにより、第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス６１６の照合を有効にすることができる。

性能管理の一連のアクションを使用して、サーバファブリックリソースの現在の利用について、現在のまたは予測されるサーバファブリック６０８の健全性を分析する。これらのｖｅｒｂはまた、サーバファブリック６０８内の種々のコンテナおよび要素によるリソースの使用を統括する手段も提供する。性能管理の一連のアクションは、測定アクション、監視アクション、予測アクション、および統括アクションを含むことができる。

測定アクションでは、リソース、要素、またはコンテナに関する性能統計値を収集する。例えば、測定アクションにより、第１のサーバ６３６のボリュームＥ上のデータベースファイルＦｉｎａｎｃｅ．ｍｄｂにより使用されるスペースを測定することができる。監視アクションでは、リソース、要素、またはコンテナに関する性能統計値を、ポリシーに対して評価する。例えば、監視アクションにより、容量の８０％を超える利用の発生時について、第１のサーバ６３６のボリュームＥ上のデータベースファイルＦｉｎａｎｃｅ．ｍｄｂにより使用されるスペースを監視することができる。予測アクションでは、履歴データ、リソース変更、または、配置もしくは作成等のサーバファブリックアクションの関数として、コンテナ、要素、またはリソースの性能統計値を予想する。例えば、予測アクションにより、増大した会計のＤＡＣを収容するために追加のストレージがいつ必要になるかを予測することができる。更なる例として、予測アクションは、全体的に増大したサーバファブリックを収容するために追加のリソースがいつ必要になるかを予測する。統括アクションでは、コンテナまたは要素に割り当てられるリソースの最小量または最大量を指定する。例えば、統括アクションにより、第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス６１６のＣＰＵの利用を、第２のサーバ６３８のＣＰＵの容量の５０％に制限することができる。

マッピングの一連のアクションでは、サーバファブリック６０８内の層の間の関係を管理する簡素な手段を提供する。マッピングの一連のアクションは、主として、近接する２つの層の間の関係を確立するために使用される。一連のアクションを使用して全ての関係が管理されるわけではない。例えば、コンピュータとそのストレージとの関係は、コンピュータを物理的に操作することにより制御される。マッピングの一連のアクションは、マップアクションおよびアンマップアクションを含むことができる。概念的には、これらの一連のアクションは、サーバファブリック６０８に対して行うことが可能な最高レベルのアクションであるとして考えることができ、このアクションの結果、一連の他のライフサイクルアクションが実行されることになる。例えば、ＤＡＣをＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒのインスタンスにマッピングすることで、ＤＡＣがそのインスタンス上で利用可能であることをシステムに知らせることになる。これにより、そのＤＡＣを、指定されるインスタンス上で利用可能にすることが求められる、配置またはインストール等の全ての一連のアクションが呼び出される。

マップアクションでは、コンテナ、要素、またはリソースの間の関係を作成する。例えば、マップアクションにより、第１のＤＡＣ６２２を第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス６１６に結びつけることができる。アンマップアクションでは、コンテナ、要素、またはリソースの間のマッピングを削除する。例えば、アンマップアクションにより、第１のＤＡＣ６２２を第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス６１６から分離させることができる。

照合は、サーバファブリック内の、所定の定義から外れたエンティティを識別するための処理である。例えば、照合により、プロダクションサーバ内のテーブルの定義が、ＤＡＣにおいて定義されたものから変更されているかどうかを検出する。３つのサーバファブリックの一連のアクションが、照合を実装する。照合の一連のアクションは、ディスカバアクション、比較アクション、およびマージアクションを含むことができる。

ディスカバアクションでは、新しいアイテムを見つけ、かつ、新しいアイテムに生産的な見識を与える動作が定義される。例えば、ディスカバアクションにより、第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス６１６内のＥｍｐｌｏｙｅｅテーブル内に新しい列を発見することができる。比較アクションでは、コンテナ、要素、またはリソースの現在の構成を、予め定義された構成とマッチさせ、任意の相違を報告する。例えば、比較アクションにより、第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス６１６に存在するＥｍｐｌｏｙｅｅテーブルを、ＤＡＣ内のテーブル定義比較することができ、かつ、ＤＡＣ内に定義されていない列を有する、第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス６１６内のテーブルのバージョンを見つける。マージアクションでは、複数のインスタンスから、コンテナ、要素、またはリソースの単一の構成を作成する。例えば、マージアクションにより、Ｅｍｐｌｏｙｅｅテーブル内の新しい列の定義をＤＡＣ定義にマージすることができる。

アクセスの一連のアクションでは、サーバファブリックモデルの一部へのアクセスを制御する手段を提供して、長期間実行される処理を支援する。例えば、ファイルを１つのボリュームから別のボリュームに移動させる処理は、移動先のボリュームへのアクセスを制御して、複数の処理が相容れないスペースの割り当てを行わないようにしなければならない。セキュリティの一連のアクションでは、サーバファブリック６０８内のコンテナおよび要素へのアクセスを、認可されたユーザに限定する。本開示では、新しい認可の基礎構造を提供しないが、むしろ、これらの一連のアクションにより、サーバファブリック６０８全体に亘る認可の構成についての統一されたインターフェースを表す。従って、本開示では、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒには既に整っている種々の下層にある認可の機構を活用する。アクセスおよびセキュリティの一連のアクションは、ブロックアクション、アンブロックアクション、承諾アクション、および、取り消しアクションを含むことができる。

ブロックアクションでは、コンテナ、要素、またはリソースの構成への発行処理排他的アクセスを提供し、他の処理がその構成にアクセスすることを阻止する。この一連のアクションは、実際のエンティティ自体にではなく、サーバファブリック６０８のモデル内のデータに作用する。例えば、ブロックアクションにより、第１のサーバ６３６の記憶ボリュームＥへのアクセスをブロックすることができ、ファイル移動を実行するためにスペースを確保する。アンブロックアクションは、コンテナ、要素、またはリソースの構成への排他的アクセスを解除する。この一連のアクションは、実際のエンティティ自体にではなく、サーバファブリック６０８のモデル内のデータに作用する。例えば、ファイル移動が完了した後、アンブロックアクションにより、第１のサーバ６３６の記憶ボリュームＥへのアクセスをアンブロックすることができる。承諾アクションでは、コンテナ、要素、またはリソースにアクセスするための主要な許可を与える。例えば、承諾アクションにより、ＤＡＣへの主要なＪａｎｅｔ書き込みアクセスを承諾することができる。取り消しアクションでは、コンテナまたは要素にアクセスするための主要な許可を拒否する。例えば、取り消しアクションにより、主要なＪａｎｅｔからＤＡＣへの書き込みアクセスを取り消すことができる。

図７を参照すると、データベース管理アクションおよびポリシーを自動的に適用する方法の特定の実施形態が例示される。７０２にて、方法は、ＳＱＬサーバファブリック（例えば、図６のサーバファブリック６０８の中央管理ポイント６０２）の中央管理ポイントにおいて、データベース管理アクションおよびポリシーを受け取るステップを含む。ＳＱＬサーバファブリックは、ＤＡＣ、一組のＤＡＣをホストするデータベースランタイムリソース、およびＤＡＣをホストするためにデータベースランタイムリソースにより使用されるコンピュータリソースを識別する。ＤＡＣのそれぞれには、データベース要素のコレクションの論理的表現が含まれる。７０４に移ると、方法はまた、中央リーズニングポイント（例えば、図６のサーバファブリック６０８の中央リーズニングポイント６０４）において、ＳＱＬサーバファブリックのエンティティを監視するステップを含む。７０６に移ると、方法はまた、ＳＱＬサーバファブリックにより（例えば、図６の中央ポリシー６０６を使用して）識別される影響を受けるエンティティにおいて、受け取ったデータベース管理アクションおよびポリシーを自動的に適用するステップを含む。

図８を参照すると、ＥＲＤ（ｅｎｔｉｔｙ ｒｅｌａｔｉｏｎｓｈｉｐ ｄｉａｇｒａｍ：エンティティ関係図）により、サーバファブリックがデータ層のコンポーネントを記述するモデルをどのように表すかについて、および、そのコンポーネントがどのように関係するかを例示する。図８のＥＲＤでは、このモデルがどのような形になってサーバファブリックの３つの層の構造とセマンティック（意味）を支援するのかを例示する。

各層は、コンテナ、要素、およびリソースと同様にモデル内の正規のエンティティとして表される。モデルはまた、これらのエンティティ間の関係セマンティックを定義し、その結果サーバファブリックの構造が定義される。この構造では、本開示の実施形態によるサーバファブリックに対するリーズニングおよびアクションを起こすことを可能にすることにより、次のセクションで説明する機構が容易にされる。

図９を参照すると、９００にて、システムの特定の例示の実施形態が例示される。ＣＭＳ（Ｃｅｎｔｒａｌ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｅｒ：中央管理サーバ）９０２により、サーバファブリックに中央集中管理ポイントが提供される。ＣＭＳ９０２は、ＣＭＲ（Ｃｅｎｔｒａｌ Ｍａｎａｇｅｍｅｎｔ Ｒｅｐｏｓｉｔｏｒｙ：中央管理リポジトリ）９０４に接続する。サーバファブリック内のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒの管理されるインスタンスは、ＣＭＳ９０２に接続し、情報をＣＭＲ９０４にアップロードする。ＣＭＳ９０２は、ネットワーク上のＳＱＬサービスのインスタンスをディスカバリするアクション、ＤＡＣをプロビジョンするアクション、ＤＡＣ要素を所望の場所に置くアクション、ＤＡＣを基準に対してチェックするアクション、および、サーバファブリック内の要素間の相違を照合するアクションを提供する。

ＣＭＲ９０４は、サーバファブリックのモデル（例えば、全ての関連する詳細、関係、および制約）を含有する。ＣＭＳ９０２は、配置分析、影響分析、およびｗｈａｔ−ｉｆ分析のための中央リーズニングポイントであり、コアデータ型、詳細データ型、およびリンクデータ型を含有する。この型の内の２つにより、ＩＭＲ（例えば、ＩＭＲ９１０および９１４）からＣＭＲ９０４への複製の頻度に基づく分類を用いて、ＣＭＲ９０４に含有されるデータを表す。頻繁に複製されるデータをコアデータと称する。それほど頻繁に複製されないデータを詳細データと称する。リンクデータ型は、ＣＭＲ９０４に記憶されないデータに対するインデックスまたはポインタとして機能する。

ＣＭＤＷ(Ｃｅｎｔｒａｌ Ｍａｎａｇｅｍｅｎｔ Ｄａｔａ Ｗａｒｅｈｏｕｓｅ：中央管理データウェアハウス）９０６により、一組の物理的サーバおよびインスタンス全体に亘る性能統計値履歴を中央に集中してレポートすることを可能にする。各管理されるＳＱＬサーバランタイムインスタンス上に存在するデータは、収集されて、監視およびレポートの目的でＣＭＤＷ９０６のデータベースの配置場所にアップロードされる。

ＣＦＳ（Ｃｅｎｔｒａｌ Ｆａｂｒｉｃ Ｓｅｒｖｉｃｅ：中央ファブリックサービス）９０８は、コアのＣＭＳ９０２のアクションのためのＡＰＩを提供する。これらのアクションには、ネットワーク上のＳＱＬサービスのインスタンスをディスカバリするアクション、ＤＡＣをプロビジョンするアクション、ＤＡＣ要素を所望の場所に置くアクション、ＤＡＣを基準に対してチェックするアクション、および、サーバファブリック内の要素間の相違を照合するアクションが含まれる。

ＩＭＲ（Ｉｎｓｔａｎｃｅ Ｍａｎａｇｅｍｅｎｔ Ｒｅｐｏｓｉｔｏｒｙ：インスタンス管理リポジトリ）は、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒの各インスタンス内に存在するデータベースである。例えば、第１のＩＭＲ９１０は、第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス９１２内に存在する。第２のＩＭＲ９１４は、第２のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス９１６内に存在する。ＩＭＲは、全ての配置またはサーバファブリックの修正の最初の対象である。「コレクションセット」として既知の機構により、ＩＭＲ情報をコピーし、ＣＭＲ９０４内にアップロードしてサーバファブリックの集約レベルのビューを提供する。

ＩＭＤＷ（Ｉｎｓｔａｎｃｅ Ｍａｎａｇｅｍｅｎｔ Ｄａｔａ Ｗａｒｅｈｏｕｓｅ：インスタンス管理データウェアハウス）は、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒの各インスタンス内に存在する管理データウェアハウスである。例えば、第１のＩＭＤＷ９１８は、第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス９１２内に存在する。第２のＩＭＤＷ９２０は、第２のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス９１６内に存在する。ＩＭＤＷは、インスタンスのデータの性能（例えば、レポートおよび／または監視）の最初の対象であり、後で、ＣＭＤＷ９０６内にアップロードされてサーバファブリックの集約的なビューを提供する。

ＩＦＳ（Ｉｎｓｔａｎｃｅ Ｆａｂｒｉｃ Ｓｅｒｖｅｒ：インスタンスファブリックサーバ）は、コアの管理アクションのためのＡＰＩを提供する。例えば、第１のＩＦＳ９２２は、第１のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス９１２内に存在する。第２のＩＦＳ９２４は、第２のＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒインスタンス９１６内に存在する。これらのアクションには、ローカルなインスタンス上にＤＡＣインスタンスを認証してインストールするアクション、外れたインストールをディスカバリするアクション、および照合動作を提供するアクションが含まれる。ＩＦＳはまた、インスタンスの性能を測定することができ、ＣＭＳ９０２から送られるアクションを実行する。

図１０を参照すると、１０００にて、エンド・ツー・エンド管理の処理の例示の図が例示される。本開示は、開発から配置までの完全なソフトウェアライフサイクル全体に亘ってＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒデータベースアプリケーションを管理するための、ツールおよび基礎構造を動作に提供する。このセクションでは、本開示のいくつかの標準的なワークフローを前のセクションで説明された主要なアーキテクチャのコンポーネントに対して用いて、核となる設計の原則に見識を提供する。

１００２にて、システムがインストールされ、サーバファブリックが構成される。１００４にて、ＤＡＣが、既存の配置から作成され、サーバファブリックにインポートされる。１００６にて、サーバファブリックの利用が監視および予測される。監視と予測に基づき、サーバファブリックリソースを調節することができる。例えば、１００８にて、サーバファブリックリソースが統括される。１０１０にて、サーバファブリック要素が移動される。

図１１を参照すると、インストール処理例示が示される。インストールパッケージは、３つのコンポーネントで構成される。すなわち、ツール拡張機能、サーバファブリックサービス、および管理リポジトリスキーマである。ツール拡張機能は、Ｖｉｓｕａｌ ＳｔｕｄｉｏおよびＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ Ｍａｎａｇｅｍｅｎｔ Ｓｔｕｄｉｏに適用される。サーバファブリックサービスおよび管理リポジトリスキーマは、中央管理サーバおよび管理されるインスタンス内にインストールされる。

１１０２にて、インストールパッケージが取得される。１１０４にて、ツール拡張機能（Ｖｉｓｕａｌ ＳｔｕｄｉｏおよびＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ Ｍａｎａｇｅｍｅｎｔ Ｓｔｕｄｉｏ）がインストールされる。１１０６にて、中央管理サーバ（ＣＭＳ）および中央ファブリックサービス（ＣＦＳ）が、インストールされ構成される。１１０８にて、中央管理リポジトリ（ＣＭＲ）スキーマおよび中央管理データウェアハウス（ＣＭＤＷ）スキーマがインストールされる。１１１０にて、全てのランタイムインスタンスがディスカバリされ、サーバファブリックにおいて管理されるインスタンスとなるインスタンスがディスカバリされる。１１１２にて、サーバファブリックインストールのジョブが、各管理されるインスタンス内に作成される。１１１４にて、インスタンス管理リポジトリ（ＩＭＲ）スキーマおよびインスタンス管理データウェアハウス（ＩＭＤＷ）スキーマが、各管理されるインスタンス内に作成される。１１１６にて、サーバファブリックＩＭＤＷのＣＭＤＷへのデータアップロード機構がインストールされ、１１１８にて開始される。

図１２を参照すると、既存の配置からＤＡＣを作成し、サーバファブリック内にインポートする説明に役立つ実例が示される。ＤＡＣは、サーバファブリック内のコアの論理的な管理の単位である。サーバファブリックはＤＡＣを管理して、最適なリソース利用を確実にする。ＤＡＣは、新しいＤＡＣプロジェクトを作成することにより、Ｖｉｓｕａｌ ＳｔｕｄｉｏまたはＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ Ｍａｎａｇｅｍｅｎｔ Ｓｔｕｄｉｏのどちらかにおいて認可される。加えて、アプリケーションデータベースオブジェクトを選択することにより、新しいＤＡＣを、以前のデータベースの配置からリバースエンジニアすることが可能である。

１２０２にて、ＤＡＣが作成される。１２０４にて、インスタンスオブジェクトが、ＤＡＣに追加される。１２０６にて、インスタンスの設定およびポリシーがＤＡＣに追加される。１２０８にて、配置の設定およびポリシーがＤＡＣに追加される。１２１０にて、ＤＡＣの設定およびポリシーが、ＩＭＲに対して認証される。１２１２にて、ＤＡＣはＩＭＲに保存される。１２１４にて、ＤＡＣはＩＭＲからＣＭＲにコピーされる。選択的に、１２１６にて、ＤＡＣパッケージバイナリファイルが、Ｖｉｓｕａｌ Ｓｔｕｄｉｏにおける後の開発での使用のために作成される。

図１３を参照すると、サーバファブリックの利用を監視および予測する説明に役立つ実例が示される。リソース利用のポリシーにより、サーバファブリックおよびＤＡＣ全体に亘って設定および評価が可能であり、リソース利用の過不足を防ぐことができる。

１３０２にて、グローバルリソースの監視ポリシーがＣＭＲにおいて設定される。１３０４にて、統計値がＩＭＤＷに追加される。１３０６にて、データベースリソースの監視ポリシーがＩＭＲにおいて設定される。１３０８にて、リソースの利用の統計値がＩＭＤＷにおいて監視される。１３１０にて、ＩＭＤＷリソースの利用の統計値がＣＭＤＷにエクスポートされる。１３１２にて、現在のリソースの利用がＣＭＤＷにおいて監視される。１３１４にて、予測されるリソースの利用がＣＭＤＷにおいて監視される。

図１４を参照すると、サーバファブリックリソースを調節する説明に役立つ実例が示される。リソース割り当てのポリシーにより、サーバファブリックおよびＤＡＣ全体に亘って設定および評価が可能であり、ＤＡＣが利用可能なリソースのバランスを保つことができる。リソースの調節は、配置済みのリソースの統括、および、ボリューム間でのファイルの移動またはサーバ間のデータベースアプリケーションの移動といったサーバファブリック要素の移動、等のアクションを介して達成することが可能である。サーバファブリックリソースは、ポリシーを統括する新しいリソースを実装することにより調節することができる。

１４０２にて、リソースのバランスを保つオプションが、対象のＤＡＣに関するＤＡＣに対して予測される。１４０４にて、新しいリソースのポリシーがＣＭＲにおいて設定される。１４０６にて、新しいリソースのポリシーは、各ＩＭＲにコピーされる。１４０８にて、リソース統括の規則が各ＩＭＲに実装される。

図１５を参照すると、サーバファブリックリソースを調節する別の説明に役立つ実例が示される。図１５において、ＤＡＣを１つのファイルから別のファイルに移動させる処理が例示される。

１５０２にて、ＤＡＣがＣＭＲから取得される。１５０４にて、可能性のある対象ボリュームが予測される。１５０６にて、ＤＡＣが別のボリューム（ボリューム２）にマッピングされる。１５０８にて、ＤＡＣはＣＭＲからＩＭＲにコピーされる。１５１０にて、ＤＡＣは、ＩＭＲにおいて認証される。１５１２にて、ＤＡＣはインストールされる（データベースを変更、ファイルをコピー、．．．）。１５１４にて、ＤＡＣはＣＭＲにおいて認証される。

図１６を参照すると、サーバファブリックリソースを調節する別の説明に役立つ実例が示される。図１６において、ＤＡＣをＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒの１つのインスタンスから別のそれに移動させる処理が例示される。

１６０２にて、ＤＡＣがＣＭＲから取得される。１６０４にて、可能性のある対象インスタンスが予測される。１６０６にて、ＤＡＣはランタイムインスタンス２にマッピングされる。１６０８にて、ＤＡＣは、ＣＭＲからインスタンス２ＩＭＲにコピーされる。１６１０にて、ＤＡＣは、インスタンス２ＩＭＲにおいて認証される。１６１２にて、ＤＡＣは、インスタンス２ＩＭＲにインストールされる。１６１４にて、ＤＡＣのエンドポイント名が、ＣＭＲにおいて移動される。１６１６にて、ＤＡＣはＣＭＲにおいて認証される。

本明細書に記載される実施形態の例示では、種々の実施形態の構造についての全体的な理解を提供すことが意図される。例示では、本明細書に記載される構造または方法を利用する装置およびシステムの要素および特徴の全てを完全に説明することは意図されない。本開示を精査すれば、多くの他の実施形態が当業者には明らかであろう。本開示から、他の実施形態が利用されかつ導かれ、構造的および論理的な置き換えおよび変更が、本開示の範囲から逸脱することなくなされ得るであろう。従って、本開示および図面は、制限するものではなく例示として見なされるべきである。

当業者はさらに理解するであろうが、本明細書に開示される実施形態と併せて記載される、種々の例示の論理的なブロック、構成、モジュール、回路、およびアルゴリズムステップは、電子機器、コンピュータソフトウェア、またはその組み合わせとして実装できる。ハードウェアとソフトウェアのこの互換性を明確に例示するために、種々の例示のコンポーネント、ブロック、構想、モジュール、回路、またはステップが、その機能性の観点から概して記載された。そのような機能性がハードウェアまたはソフトウェアとして実装されるかどうかは、特定のアプリケーション、およびシステム全体に課される設計上の制約に依存する。当業者は、記載される機能性を、各特定のアプリケーションに対して色々な方法で実装することができるが、そのような実装の決定を、本開示の範囲から逸脱する原因として解釈すべきではない。

本明細書に開示される実施形態と併せて記載される方法のステップは、直接ハードウェアにおいて、プロセッサにより実行されるソフトウェアモジュールにおいて、または、その２つの組み合わせにおいて、具現化することができる。ソフトウェアモジュールは、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、フラッシュメモリ、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、レジスタ、ハードディスク、着脱可能ディスク、ＣＤ−ＲＯＭ、または従来技術において既知の任意の他の形式の記憶媒体、等のコンピュータ可読媒体に存在させることができる。例示の記憶媒体は、プロセッサに連結され、プロセッサが記憶媒体から情報を読み書きできるようにされる。代替えとして、記憶媒体はプロセッサに統合することができ、または、プロセッサと記憶媒体を、コンピュータデバイスまたはコンピュータシステム内で離散したコンポーネントとして存在させることができる。

本明細書において特定の実施形態が例示されかつ記載されたが、同一または同様の目的を達成するために設計される、任意の後に続く構成は、示される特定の実施形態と置き換えることができることを理解されたい。本開示では、種々の実施形態の、任意のおよび全ての後に続く適合または変動を対象とすることが意図される。

本開示の要約書は、３７Ｃ．Ｆ．Ｒ．§１．７２（ｂ）に従って提供され、かつ、請求項の範囲または意味を解釈または制限するために使用されないという理解のもとに提出される。加えて、前述の「発明を実施するための形態」において、本開示を簡素化する目的で、種々の特徴が単一の実施形態でまとめられ、または、単一の実施形態で記載される。本開示は、請求される実施形態が、各請求項に明示的に列挙されるものより多くの特徴を要求するという意図を反映するものとして解釈されるべきではない。むしろ、以下の請求項が反映するように、発明の主題は、開示される実施形態の内のいずれかの全て特徴のより少ないものを対象とする。

開示される実施形態の上述の記載が提供されて、任意の当業者が開示される実施形態を形成または使用することが可能にされる。これらの実施形態に対する種々の修正が、当業者には容易に明らかにされるであろう、また、本明細書に定義される一般的原理が、本開示の範囲から逸脱することなく他の実施形態に適用される。従って、本開示は、本明細書に示される実施形態に限定されることは意図されず、以下の請求項に定義される原理および新規の特徴に整合する可能性のある一番広い範囲に一致することが意図される。

Claims (22)

1. コンピュータに、データ層アプリケーションコンポーネント（ＤＡＣ）を配置するための方法を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体であって、前記方法は、
   コンパイル可能なＤＡＣモデルに基づいてＤＡＣパッケージをビルドするステップであって、前記ＤＡＣパッケージをビルドすることは、前記ＤＡＣモデルをコンパイルすることを含む、ステップと、
   前記ＤＡＣパッケージからサーバファブリックに複数のＤＡＣ型をインポートするステップであって、前記複数のＤＡＣ型のそれぞれは、前記ＤＡＣの論理的実装を定義し、前記サーバファブリックは、少なくとも１つのＤＡＣ、１または複数のデータベースサーバランタイム、および少なくとも１つのハードウェアリソースをモデル化する、ステップと、
   前記サーバファブリックにおいて、前記複数のＤＡＣ型のうち１つのＤＡＣ型を、前記１または複数のデータベースサーバランタイムに配置して、ＤＡＣインスタンスを作成するステップであって、前記ＤＡＣインスタンスの作成は、少なくとも前記ＤＡＣインスタンスの２以上のプロパティおよび配置に対して特有のオブジェクトを定義する配置スキーマを含む情報を保存することを含み、前記２以上のプロパティは、一意な識別子プロパティおよび配置名称プロパティを含む、ステップと
   を含むことを特徴とするコンピュータ読み取り可能な記録媒体。
2. 前記ＤＡＣ型は、少なくともプロパティ、アプリケーションスキーマおよび配置ポリシーを含むことを特徴とする請求項１に記載のコンピュータ読み取り可能な記録媒体。
3. 前記ＤＡＣ型は、ユーザが、不変条件、要求、および意図される前記ＤＡＣの使用を定義するための機構を提供することを特徴とする請求項２に記載のンピュータ読み取り可能な記録媒体。
4. 前記ＤＡＣインスタンスが、配置ポリシー、ファブリックマッピング、およびデータをさらに含むことを特徴とする請求項１に記載のコンピュータ読み取り可能な記録媒体。
5. データベース要素を一組の支援コンピュータリソースに関連付けるためのコンピュータ実装システムであって、少なくとも１つのプロセッサ、および前記プロセッサにデータ層アプリケーションコンポーネント（ＤＡＣ）を配置するための方法を実行させるためのプログラムを記録したメモリを備え、前記方法は、
   データベース要素のコレクションを含むコンパイル可能なＤＡＣモデルを作成するステップであって、前記データベース要素のコレクションは、
   １または複数のデータベースオブジェクトに関するメタデータであって、前記メタデータは、各前記データベースオブジェクトの識別子を含む、メタデータと、
   前記データベースオブジェクトを操作するよう動作可能なデータベースランタイムリソースのデータベースランタイムリソース識別子と、
   前記データベースランタイムリソースの実行に関するポリシー
   を含む、ステップと、
   前記ＤＡＣモデルに基づいてＤＡＣパッケージをビルドするステップであって、前記ＤＡＣパッケージをビルドすることは、前記ＤＡＣモデルをコンパイルすることを含む、ステップと、
   前記ＤＡＣパッケージからサーバファブリックに複数のＤＡＣ型をインポートするステップであって、前記複数のＤＡＣ型のそれぞれは、前記ＤＡＣの論理的実装を定義し、前記サーバファブリックは、少なくとも１つのＤＡＣ、１または複数のデータベースサーバランタイム、および少なくとも１つのハードウェアリソースをモデル化する、ステップと、
   前記サーバファブリックにおいて、前記複数のＤＡＣ型のうち１つのＤＡＣ型を、前記１または複数のデータベースサーバランタイムに配置して、ＤＡＣインスタンスを作成するステップであって、前記ＤＡＣインスタンスの作成は、少なくとも前記ＤＡＣインスタンスの２以上のプロパティおよび配置に対して特有のオブジェクトを定義する配置スキーマを含む情報を保存することを含み、前記２以上のプロパティは、一意な識別子プロパティおよび配置名称プロパティを含む、ステップと
   を含むことを特徴とするシステム。
6. 前記データベース要素のコレクション内の１または複数のデータベース要素は修正されるが、ＤＡＣ名は不変であることを特徴とする請求項５に記載のシステム。
7. 前記データベース要素のコレクション、または、１もしくは複数のランタイムリソースが変更可能であり、前記データベース要素のコレクションに関連付けられるＤＡＣ名は不変であり、１または複数のデータベースアプリケーションのアプリケーションの接続文字列を、前記データベース要素のコレクションに対する変更に応答して記録する必要が無いことを特徴とする請求項５に記載のシステム。
8. 前記ＤＡＣ名を使用する前記データベースアプリケーションが、異なるネットワークコンピュータ上に置かれることを特徴とする請求項７に記載のシステム。
9. 前記データベースランタイムリソースの実行に関するポリシーが、前記データベース要素のコレクションに関連付けられるＤＡＣ名に適用され、および、前記データベース要素のコレクション、または、１もしくは複数のランタイムリソースが変更される場合に、前記ポリシーは継続して適用されることを特徴とする請求項５に記載のシステム。
10. 前記データベース要素のコレクションとインターフェースをとるＡＰＩをさらに備え、前記ＡＰＩは、前記データベース要素のコレクション内の１または複数の要素の利用を測定することができることを特徴とする請求項５に記載のシステム。
11. データ層アプリケーションコンポーネント（ＤＡＣ）を配置するための方法であって、
    データベース要素のコレクションを含むコンパイル可能なＤＡＣモデルを作成するステップであって、前記データベース要素のコレクションは、
    １または複数のデータベースオブジェクトに関するメタデータであって、前記メタデータは、各前記データベースオブジェクトの識別子を含む、メタデータと、
    前記データベースオブジェクトを操作するよう動作可能なデータベースランタイムリソースのデータベースランタイムリソース識別子と、
    前記データベースランタイムリソースの実行に関するポリシー
    を含む、ステップと、
    前記ＤＡＣモデルに基づいてＤＡＣパッケージをビルドするステップであって、前記ＤＡＣパッケージをビルドすることは、前記ＤＡＣモデルをコンパイルすることを含む、ステップと、
    前記ＤＡＣパッケージからサーバファブリックに複数のＤＡＣ型をインポートするステップであって、前記複数のＤＡＣ型のそれぞれは、前記ＤＡＣの論理的実装を定義し、前記サーバファブリックは、少なくとも１つのＤＡＣ、１または複数のデータベースサーバランタイム、および少なくとも１つのハードウェアリソースをモデル化する、ステップと、
    前記サーバファブリックにおいて、前記複数のＤＡＣ型のうち１つのＤＡＣ型を、前記１または複数のデータベースサーバランタイムに配置して、ＤＡＣインスタンスを作成するステップであって、前記ＤＡＣインスタンスの作成は、少なくとも前記ＤＡＣインスタンスの２以上のプロパティおよび配置に対して特有のオブジェクトを定義する配置スキーマを含む情報を保存することを含み、前記２以上のプロパティは、一意な識別子プロパティおよび配置名称プロパティを含む、ステップと
    を含むことを特徴とする方法。
12. 前記ＤＡＣモデルを表現するものをＤＡＣプロジェクトとして保存するステップと、
    前記ＤＡＣプロジェクトをソースコントロールシステムまたはソースコントロールデータベースにチェックインして、前記ＤＡＣプロジェクトを記憶するステップと
    をさらに含むことを特徴とする請求項１１に記載の方法。
13. 前記ＤＡＣパッケージをビルドする前に、前記ＤＡＣモデルをエディットし、前記ＤＡＣモデルを認証するステップと、
    前記ＤＡＣインスタンスを配置する前に前記ＤＡＣ型を構成するステップと、
    前記ＤＡＣインスタンスを特定の組の物理的コンピュータリソースに対してインストールするステップと
    をさらに含むことを特徴とする請求項１１に記載の方法。
14. データベースオブジェクトに関するメタデータをパッケージ化する、前記ＤＡＣの管理の一単位が、第１の物理的コンピュータリソースに対してマッピングされることを特徴とする請求項１１に記載の方法。
15. 前記第１の物理的コンピュータリソースが、プロセッサ、メモリストレージデバイス、物理的ストレージデバイス、ハードディスク、コンパクトディスク、ハードドライブ、およびレジスタの内の１つまたは複数を含むことを特徴とする請求項１４に記載の方法。
16. 前記管理の一単位が、前記第１の物理的コンピュータリソースから第２の物理的コンピュータリソースに再マッピングされることを特徴とする請求項１４に記載の方法。
17. 前記データベースランタイムリソースの実行に関するポリシーは、リソース制限ポリシー、または、ソフトウェアリソースもしくはハードウェアリソースの要求に関するプロシージャであることを特徴とする請求項１１に記載の方法。
18. 前記管理の一単位は、関連するＤＡＣ名により識別され、前記ＤＡＣ名はデータベースアプリケーションによる使用のためにアクセス可能であることを特徴とする請求項１４に記載の方法。
19. 前記データベースオブジェクトが、スキーマ、テーブル、ビュー、ストアドプロシージャ、関数、トリガ、データ型、インデックス、ログイン、ユーザ、許可、ポリシー、統計値、主キー、外部キー、デフォルト、およびチェックの制約の内の１つまたは複数を含むことを特徴とする請求項１１に記載の方法。
20. 前記管理の一単位は、ＤＡＣ型、ＤＡＣインスタンスを含み、前記ＤＡＣ型は、少なくともプロパティ、アプリケーションスキーマ、および配置ポリシーを含むことを特徴とする請求項１４に記載の方法。
21. 前記ＤＡＣ型は、ユーザが、不変条件、要求、および意図される前記ＤＡＣの使用を定義するための機構を提供することを特徴とする請求項２０に記載の方法。
22. 前記ＤＡＣインスタンスが、プロパティ、配置スキーマ、配置ポリシー、ファブリックマッピング、およびデータを含むことを特徴とする請求項２０に記載の方法。

Images