JP2007531941A - マルチテナント・データベース・システムにおけるカスタム・エンティティおよびフィールド - Google Patents

Abstract

動的テーブルや動的列などの可変スキーマ・データを固定物理データベース・スキーマに格納するシステムおよび方法。マルチテナント・データベース・システムにおける複数のテナントまたは組織によって使用される、テーブルなどの標準オブジェクトが設けられる。各組織は、標準オブジェクトに含められるカスタム・フィールドを追加または定義することができる。複数のテナントのカスタム・フィールドがオブジェクト・データ構造内の単一のフィールドに記憶され、この単一のフィールドは、各テナントのいくつかの異なるデータ・タイプを含んでよい。インデックス付け列も設けられ、テナントは、インデックス付けするフィールドを指定することができる。指定されたフィールドのデータ値はインデックス列にコピーされ、各インデックス列は複数のデータ・タイプを含んでよい。各組織は、カスタム・フィールドおよびインデックス付け列を含むカスタム・オブジェクトを定義することもできる。複数のテナント用のカスタム・オブジェクトが単一のカスタム・オブジェクト・データ構造に記憶される。単一のカスタム・オブジェクト・テーブルのプライマリ・キー値はグローバルに一意であるが、いくつかの異なるエンティティ間で再使用ことのできるオブジェクト固有の識別子を含んでもよい。

Description

発明の背景
本発明は、概してマルチテナント・データベースに関し、特に、マルチテナント・データベース・システムにおいてカスタム・エンティティなどのカスタム・オブジェクトを作成するシステムおよび方法に関する。

セールスフォースドットコム・サービスなどのマルチテナント・データベース・システムでは、顧客組織（すなわち、テナント）が1つの論理データベース内のデータベース・リソースを共用するマルチテナント・アーキテクチャが使用される。通常、データベース・テーブル自体が共用され、データ・モデル内の各エンティティは通常、各テナントの行を識別する組織_id列を含む。テナントのコンテクスト内のすべての問合せおよびデータ操作はこの（インデックス付けされた）組織_idでフィルタリングされ、適切なセキュリティが確保されると共に仮想個人データベースが確実に表示される。セールスフォースドットコム・システムでは、たとえば、この方式を使用して、得意先エンティティ、連絡先エンティティ、リード・エンティティ、機会エンティティのような標準エンティティを顧客に示す。

しかし、顧客は、標準アプリケーションに備えられた標準エンティティおよびフィールドだけでなく、顧客自身のカスタム・データもデータベース・システムに付加することを望む場合がある。顧客が自分自身の物理データベースを有する従来のクライアント／サーバ・アプリケーションでは、顧客データの付加は通常、DDL（データ定義言語）を介してそのデータベースに対して行われ、新しい物理スキーマ、すなわちテーブルおよび列が作成される。セールスフォースドットコム・サービスなどのオンライン・マルチテナント・データベース・システムでは、この手法は様々な理由で受け入れがたい。たとえば、多数のテナント（たとえば、1,000個または10,000個以上の規模のテナント）を有するデータベース・システムでは、すべての所望のスキーマの和集合が基本的なデータ・ディクショナリ・カタログ（たとえば、オラクル・ディクショナリ）を圧倒してしまう。さらに、すべてのこれらのスキーマ・オブジェクトを維持することは、DBA（データベース管理者）にとってほぼ不可能な負担となる。さらに、現在のリレーショナル・データベースは、各組織が論理的に独立したままでいられる程うまく（同時並行性の高いトランザクション・システムにおいて）オンラインDDLをサポートしない。具体的には、1つの組織によってスキーマを作成すると、他のすべてのアプリケーションがロックされ、許容できない遅延が生じる恐れがある。

したがって、上記およびその他の問題を解消するように可変スキーマ・データを固定物理スキーマに記憶する融通性に富んだ手法を実現するシステムおよび方法を提供することが望ましい。

発明の概要
本発明は、動的テーブルおよび列などの可変スキーマ・データを固定物理データベース・スキーマに格納する新規のシステムおよび方法を提供する。

本発明によれば、複数のテナントまたは組織によって使用されるテーブルなどの標準オブジェクトが設けられる。各組織は、標準オブジェクトに含められるカスタム・フィールドを付加または定義することができる。一局面では、複数のテナント用のカスタム・フィールドは、オブジェクト・データ構造内の単一のフィールドに記憶され、この単一のフィールドは、各テナントについて様々なデータ・タイプを含んでよい。インデックス付け列も設けられ、テナントはインデックス付けするフィールドを指定することができる。指定されたフィールドのデータ値はインデックス列にコピーされ、各インデックス列は複数のデータ・タイプを含んでよい。各組織は、カスタム・フィールドおよびインデックス付け列を含むカスタム・オブジェクトを定義することもできる。一局面では、複数のテナントに関するカスタム・オブジェクトが、単一のカスタム・オブジェクト・データ構造に記憶される。単一のカスタム・オブジェクトのプライマリ・キー値はグローバルに一意であるが、様々なエンティティの間で再使用することができるオブジェクト固有の識別子も含む。

本発明の一局面によれば、複数のテナント用の複数のフィールドを単一のマルチテナント・データ構造に記憶する、コンピュータによって実現される方法が実現される。この方法は通常、複数のデータ列および1つまたは複数のインデックス列を有するマルチテナント・データ構造を定義する段階、第1のデータ・タイプを有する第1のテナント用の第1のデータ・フィールドを定義する段階、および第2のデータ・タイプを有する第2のテナント用の第2のデータ・フィールドを定義する段階を含み、第2のデータ・タイプは第1のデータ・タイプと異なる。この方法は通常、第1および第2のテナントによって、第1および第2のフィールドにデータ値を有するレコードが作成されるときに、第1および第2のフィールドのデータ値を、それぞれの異なるテナント用のそれぞれの異なるデータ・タイプを有するデータ値を含むデータ構造内の単一の列に記憶する段階、および第1のデータ・フィールド内のデータにインデックス付けするため第１のテナントからの要求に応答して第1のフィールド用の単一のデータ列に記憶されたデータ値をインデックス列の第1の列にコピーする段階をさらに含む。

本発明の他の局面によれば、1つまたは複数の組織用の複数のテーブルを単一のマルチテナント・データ構造に格納する、コンピュータによって実現される方法が提供される。この方法は通常、プライマリ・キー列、組織id列、および複数の物理データ列を有するマルチテナント・データ構造を定義する段階、第1のテナントidを有する第1のテナント用の、第1のデータ・フィールドを有する第1のテーブルを定義する段階、第1のテーブルに第1のテーブルidを割り当てる段階、第2のテナントidを有する第2のテナント用の、第2のデータ・フィールドを有する第2のテーブルを定義する段階、第2のテーブルに第2のテーブルidを割り当てる段階を含む。第1のテナントによって第1のテーブル用のレコードが作成されるときに、この方法は通常、作成される各レコードごとに、第1のデータ・フィールドの値をデータ構造内の単一のデータ列に記憶する段階、第1のテナントidを組織id列に記憶する段階、および第1のテーブルidをプライマリ・キー列に記憶する段階を含む。第2のテナントによって第2のテーブル用のレコードが作成されるときに、この方法は通常、作成される各レコードごとに、第2のデータ・フィールドの値をデータ構造内の単一のデータ列に記憶する段階、第2のテナントidを組織id列に記憶する段階、および第2のテーブルidをプライマリ・キー列に記憶する段階を含み、第1および第2のテナントの第1および第2のテーブルはデータ構造に記憶される。

本発明の他の局面によれば、1つまたは複数のテナント用の複数のテーブルを単一のデータ構造に記憶する、コンピュータによって実現される方法が提供される。この方法は通常、プライマリ・キー列、組織id列、および複数のデータ列を有するデータ構造を定義する段階、第1のデータ・タイプを有する第1のデータ・フィールドを有する第1のテナント用の第1のテーブルを定義する段階、第1のテーブルに第1のテーブルidを割り当てる段階、第1のデータ・タイプとは異なる第2のデータ・タイプを有する第2のデータ・フィールドを有する第1のテナント用の第2のテーブルを定義する段階、第2のテーブルに第2のテーブルidを割り当てる段階を含む。第1のテーブル用のレコードが作成されるときに、この方法は通常、作成される各レコードごとに、第1のデータ・フィールドの値をデータ構造内の単一のデータ列に記憶する段階、第1のテナントidを組織id列に記憶する段階、および第1のテーブルidをプライマリ・キー列に記憶する段階を含む。第2のテーブル用のレコードが作成されるときに、この方法は通常、作成される各レコードごとに、第2のデータ・フィールドの値をデータ構造内の単一のデータ列に記憶する段階、第1のテナントidを組織id列に記憶する段階、および第2のテーブルidをプライマリ・キー列に記憶する段階を含み、第1のテナントの第1および第2のテーブルはデータ構造に記憶され、単一のデータ列は、第1および第2のデータ・タイプを有するデータ値を含む。

本発明の詳細な説明
図面および特許請求の範囲を含む本明細書の残りの部分を参照すれば、本発明の他の特徴および利点が認識されよう。本発明の他の特徴および利点と、本発明の様々な態様の構造および動作については、添付の図面に関して以下に詳しく記載される。図面では、同じ参照符号は、同一または機能的に同様の要素を示す。

図1は、マルチテナント・データベース・システムを使用できる環境を示している。図1に示され（かつ図2により詳しく示され）ているように、あらゆるユーザ・システム12が、ネットワーク14を介してマルチテナント・データベース・システム（MTS）16と対話することができる。このようなユーザ・システム12のユーザは、様々な能力のユーザであってよく、特定のユーザ・システム12の能力は、現在のユーザによって全体的に決定することができる。たとえば、セールスマンが特定のユーザ・システム12を使用してMTS 16と対話する場合、そのユーザ・システムは、そのセールスマンに割り当てられた能力を有する。しかし、管理者がそのユーザ・システムを使用してMTS 16と対話している間、そのユーザ・システムは、その管理者に割り当てられた能力を有する。

ネットワーク14は、LAN（ローカル・エリア・ネットワーク）、WAN（ワイド・エリア・ネットワーク）、無線網、ポイント・ツー・ポイント・ネットワーク、スター・ネットワーク、トークン・リング・ネットワーク、ハブ・ネットワーク、またはその他の構成であってよい。現在使用されているネットワークの最も一般的な種類のネットワークが、本明細書の多数の例で使用される頭文字「I」を有する「インターネット」と呼ばれることの多いネットワークのグローバル・ネットワークなどのTCP/IP（伝送制御プロトコルおよびインターネット・プロトコル）ネットワークであるが、本発明が使用することのできるネットワークがそのように限定されないことを理解されない。ただし、TCP/IPは現在好ましいプロトコルである。

ユーザ・システム12は、TCP/IPを使用してMTS 16と通信することができ、より高いネットワーク・レベルでは、HTTP、FTP、AFS、WAPのような、他の一般的なインターネット・プロトコルを使用して通信することができる。一例として、HTTPを使用する場合、ユーザ・システム12は、MTS 16のHTTPサーバにHTTPメッセージを送信しかつこのHTTPサーバからHTTPメッセージを受信する一般に「ブラウザ」と呼ばれるHTTPクライアントを含んでよい。このようなHTTPは、MTS 16とネットワーク14との間の単一のネットワーク・インターフェースとして実現することができるが、他の技術も同様に、またはHTTPの代わりに使用することができる。いくつかの実現態様では、MTS 16とネットワーク14との間のインターフェースは、負荷の釣り合いをとり、着信HTTP要求を複数のサーバを介して均等に分配するランド・ロビンHTTP要求ディストリビュータなどの負荷共有機能を含んでいる。好ましくは、複数のサーバはそれぞれ、少なくともサーバにアクセスしているユーザに関して、MTSのデータにアクセスすることができる。

好ましい局面では、図1に示されているシステムは、ウェブ・ベースの顧客関係管理（CRM）システムを実現する。たとえば、一局面では、MTS 16は、CRMソフトウェア・アプリケーションを実現し実行すると共に、ユーザ・システム12との間で関連するデータ、コード、フォーム、ウェブ・ページ、およびその他の情報をやり取りし、関連するデータ、オブジェクト、およびウェブ・ページ・コンテントをデータベース・システムに記憶し、データベース・システムから検索するように構成されたアプリケーション・サーバを含んでよい。マルチテナント・システムでは、テナント・データは好ましくは、あるテナントのデータが他のテナントのデータから分離され、したがって、あるテナントが他のテナントのデータに、このようなデータが明示的に共用されないかぎりアクセスできなくなるように構成される。

MTS 16の要素のある構成が図1に示されており、ネットワーク・インターフェース20と、テナント・データ用のストレージ22と、MTS 16および場合によっては複数のテナントにアクセス可能であるシステム・データ用のストレージ24と、MTS 16の様々な機能を実現するプログラム・コード26と、MTSシステム・プロセス、およびアプリケーションをアプリケーション・サービスの一部として実行することなどテナント固有のプロセスを実行するためのプロセス空間28とを含んでいる。

図1に示されているシステムのいくつかの要素には、本明細書では詳しく説明する必要のない従来の公知の要素が含まれる。たとえば、ユーザ・システム12は、インターネットまたは他のネットワーク接続に直接または間接的に接続することのできるデスクトップ・パーソナル・コンピュータ、ワークステーション、ラップトップ、PDA、携帯電話、あるいは任意のWAPイネーブル・デバイスまたはその他の任意のコンピューティング・デバイスを含んでよい。ユーザ・システム12は通常、ユーザ・システム12のユーザ（たとえば、CRMシステムの加入者）が利用可能な情報およびページをMTS 16からネットワーク14を介してアクセスし、処理し、表示するのを可能にするマイクロソフトのInternet Explorer（商標）ブラウザ、ネットスケープのNavigator（商標）ブラウザ、オペラのブラウザ、または携帯電話、PDA、他の無線装置などの場合のWAPイネーブル・ブラウザなどのブラウジング・プログラムを実行する。各ユーザ・システム12は通常、MTS 16または他のシステムもしくはサーバから与えられるページ、フォーム、およびその他の情報と一緒にブラウザによってディスプレイ（たとえば、モニタ画面、LCDディスプレイなど）上に表示されるグラフィカル・ユーザ・インターフェース（GUI）と対話する、キーボード、マウス、タッチスクリーン、ペンのような1つまたは複数のユーザ・インターフェース装置も含んでいる。上述のように、本発明は、複数のネットワークの特定のグローバル・インターネットワークを指すインターネットと共に使用するのに適している。しかし、イントラネット、エクストラネット、仮想プライベート・ネットワーク（VPN）、非TCP/IPベース・ネットワーク、任意のLANまたはWANなどをインターネットの代わりに使用できることを理解されたい。

一態様によれば、各ユーザ・システム12およびそのすべての構成要素は、インテル・ペンティアム・プロセッサ（登録商標）などの中央演算処理装置を使用して実行されるコンピュータ・コードを含むブラウザなどのアプリケーションを使用して、オペレータによって構成可能である。同様に、MTS 16（および複数のMTSが存在するMTSの他のインスタンス）およびそのすべての構成要素は、インテル・ペンティアム・プロセッサ（登録商標）などの中央演算処理装置、または複数のプロセッサ・ユニットを使用して実行されるコンピュータ・コードを含むブラウザなどのアプリケーションを使用して、オペレータによって構成可能である。相互に通信し、本明細書に記載されるようにウェブ・ページならびにその他のデータおよび媒体コンテントを処理するようにMTS 16を操作し構成するコンピュータ・コードは好ましくは、ダウンロードされハード・ディスク上に記憶されるが、プログラム・コード全体またはその一部を、ROMやRAMのような公知の他の任意の揮発性または非揮発性メモリ媒体または装置に記憶するか、あるいはコンパクト・ディスク（CD）媒体、デジタル・バーサトル・ディスク（DVD）媒体、フロッピィ・ディスクのような、プログラム・コードを記憶できる任意の媒体上に供給することもできる。さらに、プログラム・コード全体またはその一部を、公知のように、たとえばインターネットを介してソフトウェア・ソースから伝送しダウンロードするか、または他のサーバから送信しダウンロードするか、あるいは任意の通信媒体およびプロトコル（たとえば、TCP/IP、HTTP、HTTPS、イーサネット（登録商標）など）を使用して公知のように他の任意の従来のネットワーク接続（たとえば、エクストラネット、VPN、LANなど）上で送信することができる。本発明の各局面を実現するコンピュータ・コードを、たとえばC、C++、HTML、Java（登録商標）、JavaScript、VBScriptや公知の他の多数のプログラミング言語のような他の任意のスプリプト言語など、サーバまたはサーバ・システム上で実行できる任意のプログラミング言語で実施できることも理解されよう。

一態様によれば、各MTS 16は、ウェブ・ページ、フォーム、データ、および媒体コンテントをユーザ・システム12に供給して、MTS 16のテナントとしてのユーザ・システム12によるアクセスをサポートするように構成される。このため、MTS 16は、各テナントのデータを、そのデータが共用されないかぎり分離しておくためのセキュリティ機構を実現する。複数のMTSを使用する場合、それらを互いに近接させて（たとえば、単一の建物またはキャンパス内に配置されたサーバ・ファーム内に）配置することも、互いに遠い位置に分散させる（たとえば、都市Aに1つまたは複数のサーバを配置し、都市Bに1つまたは複数のサーバを配置する）こともできる。本明細書では、各MTSは、ローカルにまたは1つまたは複数の地理的位置にわたって分散された1つまたは複数の論理的および／または物理的に接続されたサーバを含んでよい。さらに、語「サーバ」は、処理ハードウェアおよび処理空間を含むコンピュータ・システム、ならびに当技術分野で公知の関連する記憶システムおよびデータベース・アプリケーション（たとえば、RDBMS）を含むことを意味する。本明細書では「サーバ・システム」と「サーバ」が相互交換可能に使用されることが多いことも理解されたい。同様に、本明細書で説明するデータベースは、単一のデータベース、分散データベース、分散データベースの集合、冗長オンラインもしくはオフライン・バックアップまたは他の冗長性などを有するデータベースとして実現することができ、かつ分散データベースまたは記憶ネットワークおよび関連する処理インテリジェンスを含んでよい。

図2は、MTS 16の各要素および様々な相互接続部を詳しく示している。この例では、ネットワーク・インターフェースは、1つまたは複数のHTTPアプリケーション・サーバ100として実現される。個別テナント処理空間104を含む処理空間102と、システム・データベース106と、テナント・データベース108と、テナント管理処理空間110も示されている。テナント・データベース108は、物理的構成であっても論理構成であってもよい個別テナントストレージエリア112に分割することができる。各テナントストレージエリア112内で、ユーザストレージ114を各ユーザごとに同様に割り当てることができる。

各アプリケーション・サーバ100をそれぞれの異なるネットワーク接続を介してデータベース・システム、たとえばシステム・データベース106およびテナント・データベースに通信可能に結合できることも理解されたい。たとえば、あるサーバ100₁をインターネット14を介して結合することができ、他のサーバ100_N-1を直接ネットワーク・リンクを介して結合することができ、他のサーバ100_Nをさらに異なるネットワーク接続によって結合することができる。伝送制御プロトコルおよびインターネット・プロトコル（TCP/IP）は、サーバ100とデータベース・システムとの通信に好ましいプロトコルであるが、使用されるネットワーク相互接続に応じて他の転送プロトコルを使用してシステムを最適化できることが当業者には明らかであろう。

好ましい局面では、各アプリケーション・サーバ100は、任意のユーザ／組織に対する要求を処理するように構成される。任意の時間に任意の理由でアプリケーション・サーバをサーバ・プールに追加し、サーバ・プールから削除することができることが望ましいので、好ましくは、ユーザおよび／または組織には特定のアプリケーション・サーバ100に対するサーバ・アフィニティがない。したがって、一態様では、負荷釣り合わせ機能（たとえば、F5 Big-IP負荷分散装置）を実現するインターフェース・システム（図示せず）はサーバ100とユーザ・システム12との間に通信可能に結合され、要求を各サーバ100に分散させる。一局面では、負荷分散装置は最小接続アルゴリズムを使用してユーザ要求をサーバ100に送る。ラウンド・ロビンや観測応答時間のような負荷釣り合わせアルゴリズムの他の例を使用してもよい。たとえば、ある局面では、同じユーザからの3つの連続する要求が3つの異なるサーバにヒットし、それぞれの異なるユーザからの3つの要求が同じサーバにヒットすることができる。このように、MTS 16はマルチテナントであり、MTS 16は、それぞれの異なるユーザおよび組織間のそれぞれの異なるオブジェクトおよびデータの記憶を処理する。

記憶の一例として、あるテナントは、各セールスマンがMTS 16を使用してその販売プロセスを管理する、販売員を雇用する会社であってよい。したがって、ユーザは、すべて（たとえば、テナント・データベース108内の）ユーザの個人販売プロセスに適用することのできる連絡先データ、リード・データ、顧客追跡データ、業績データ、目標および進捗データなどを維持することができる。好ましいMTS構成では、すべてのこのデータおよびアクセス、表示、修正、報告、送信、計算などのアプリケーションを、ネットワーク・アクセスしかできないユーザ・システムによって維持しアクセスすることができ、ユーザは自分の販売努力およびサイクルを多数の異なるユーザ・システムから管理することができる。たとえば、セールスマンが顧客を訪れ、顧客がそのロビーでインターネットにアクセスできる場合、セールスマンは顧客がロビーで到着するのを待つ間にその顧客に関する重要な更新を行うことができる。

各ユーザの販売データを各ユーザの雇用者とは無関係に他のユーザの販売データから分離することができるが、一部のデータは、テナントである所与の組織に関する複数のユーザまたはすべての販売員によって組織全体で共有されるかまたはアクセス可能なデータであってよい。したがって、テナント・レベルで割り当てられるMTS 16によって管理されるいくつかのデータ構造があってよく、一方、他のデータ構造をユーザ・レベルで管理することができる。MTSは、考えられる競合相手を含む複数のテナントをサポートできるので、MTSは、データ、アプリケーション、およびアプリケーション用途を別々に維持するセキュリティ・プロトコルを有するべきである。さらに、多数のテナントがそれ自体のシステムを維持するのではなくMTSへのアクセスを選択するので、冗長性、アップ時間、およびバックアップがより重大な機能であり、これらをMTSで実現する必要がある。

MTS 16は、ユーザ固有のデータおよびテナント固有のデータだけでなく、複数のテナントによって使用できるシステム・レベル・データまたはその他のデータを維持することもできる。このようなシステム・レベル・データは、各テナント間で共用できる業界レポート、ニュース、通知などを含んでよい。

ある局面では、クライアント・システム12は、アプリケーション・サーバ100と通信して、データベース・システム106および／またはデータベース・システム108への1つまたは複数の問合せを必要とすることがあるMTS 16にシステム・レベル・データおよびテナント・レベル・データを要求し更新する。MTS 16（たとえば、MTS 16内のアプリケーション・サーバ100）は、所望の情報にアクセスするように設計された1つまたは複数のSQL文（SQL問合せ）を自動的に生成する。

各データベースは一般に、定義済みの範疇に適合するデータを含む1組の論理テーブルのようなオブジェクトの集合とみなすことができる。「テーブル」は、データ・オブジェクトの一表現であり、本明細書では、本発明によるオブジェクトおよびカスタム・オブジェクトの概念的な記述を簡略化するために使用される。本明細書では「テーブル」および「オブジェクト」を相互交換可能に使用できることを理解されたい。各テーブルは一般に、表示可能なスキーマにおいて列またはフィールドとして論理的に構成された1つまたは複数のデータ範疇を含んでいる。テーブルの各行またはレコードは、フィールドによって定義される各範疇のデータのインスタンスを含んでいる。たとえば、CRMデータベースは、名前、住所、電話番号、ファックス番号のような基本的な連絡先情報用のフィールドで顧客を記述するテーブルを含んでよい。他のテーブルは、顧客、製品、販売価格、日付などの情報用のフィールドを含む購買注文を記述することができる。いくつかのマルチテナント・データベース・システムでは、標準エンティティ・テーブルを設けることができる。CRMデータベース・アプリケーションでは、このような標準エンティティには、各テーブルが定義済みのフィールドを含む得意先データ、連絡先データ、リード・データ、および機会データのテーブルを含んでよい。

カスタム・フィールド
一態様によれば、標準エンティティ用のテーブルなどのテーブルについては、追加的な1組の1つまたは複数の列、たとえば10列、100列、または250列のテキスト・データが物理スキーマに定義される。これらの追加的な列は、本明細書ではカスタム・データ列、カスタム・フィールド列、またはカスタム・フィールドとも呼ばれ、システム管理者がそのエンティティ用の定義済み標準フィールドに含まれていない他のフィールドを定義するのを可能にする。このようなカスタム・フィールドは好ましくは、VARCHAER（可変長文字）というデータ・タイプを有する。一局面では、これらのカスタム・フィールドは好ましくは、メイン・エンティティ・テーブルから行の外で（out of row）で記憶される。ただし、これらのフィールドはメイン・テーブルに記憶することができる。たとえば、メイン・テーブルが「セールス.アカウント（sales.acount)」という名称を有する場合、カスタム・フィールド・データは「セールス.アカウント_cfデータ（sales.acount_cfdata)」というテーブルに記憶することができる。ここで、「ｃｆ」とは「カスタムフィールド（custom field)」の略である。これらのテーブルはどちらも、好ましくは、各テナント行を区別する組織_id列を含むと共に、データベース全体にわたってこれらの行を識別する同じインデックス付けされたプライマリ・キー（たとえば、この場合は得意先id）とを含む。さらに、どちらのテーブルも好ましくは、たとえば、メンテナンスのためにテーブル全体に作用し、より浅いインデックスを維持する必要があるときに、並列化を推進するようにDB（たとえば、オラクルDB）上で物理的に区画されている。

図3は、メイン・テーブル200および関連するカスタム・フィールド・テーブル210として表されるオブジェクトの例を示している。図3に示されている特定の例では、メイン・テーブル200（.得意先）は、標準得意先エンティティを表しており、カスタム・フィールド・テーブル210（.得意先_cfデータ）は、メイン・テーブル200を使用して様々な組織（テナント）によって定義されるカスタム・フィールドを含んでいる。図示のように、メイン・テーブル200は、組織ID（「org id」）列201、およびテーブル200用のプライマリ・キーとして働くテーブルID（たとえば、.得意先idを表す「acc id」）を含んでいる。データ・テーブル200は、複数のデータ列203も含んでいる。図3の特定の例では、テーブルは標準エンティティを表し、データ列203は、テーブルを使用することのできる様々な組織に供給される定義済みデータ列または標準フィールドである。標準得意先エンティティの例では、このような標準フィールドは、名前列、サイト列、従業員数列、および得意先関連情報を記憶するうえで有用な他のフィールドを含んでよい。各データ列203は好ましくは、1列当たりに単一のデータ・タイプを記憶するように定義される。組織id列201は、マルチテナント得意先テーブル200を使用して組織同士を区別するために設けられている。図示のように、N個の異なる組織が、テーブル200に記憶されたデータを有している。列201の組織idは好ましくはChar(15)であるが、他のデータ・タイプを含んでよい。一局面では、組織idの最初の3文字は、「00d」のような定義済みのプレフィックスに設定される。ただし、必要に応じて組織id内の文字の他の部分集合を使用してこのようなプレフィックスを保持することができる。

カスタム・フィールド・テーブル210は同様に、組織id列211、テーブルid列212、および複数のデータ列213を含んでいる。上述のように、テーブルid列212は、テーブル210用のプライマリ・キーとして働き、好ましくはテーブル200のテーブルid列202と同じ値を含む。図示の特定の例では、val0、val1 ... val249と示されている250個のデータ列213がある。必要に応じて、たとえば10個や100個のような他の任意の数を使用できることを理解されたい。

最初に組織が作成され、データベース・テーブル200に関連付けられる際、カスタム・フィールド列213はその組織については空である。しかし、メイン・テーブル（たとえば、.得意先）にレコードまたは行が作成されるたびに、カスタム・フィールド・テーブルに対応する行が作成される。すべてのカスタム・フィールド列はヌルであり、したがって使用されるまで空間を占有することはない。

一局面では、これらのカスタム・フィールドにデータを入力することができるのは、その組織の管理者によってその組織用の新しい「列」が定義されるときだけである。たとえば、得意先エンティティの例では、特定の組織が標準フィールド203だけでなく1つまたは複数の他のカスタム・フィールドも作成し、定義済みの標準フィールドでは対処できない特定の種類のデータを記憶することが望ましい場合がある。物理列（オラクルでは、物理列の定義はオラクル・ディクショナリ・カタログに配置される）を定義する代わりに、この定義が、メタデータ、たとえば、1つまたは複数のメタデータ・テーブルを含んでよいメタデータ・カタログに記憶される。物理列の定義は同様に、XMLまたは他の何らかのフォーマットで記憶することができる。

図6aは、本発明の一態様によるカスタム・フィールド定義メタデータ・テーブル500（「カスタム_フィールド_定義」）の一例を示している。カスタム_フィールド_定義メタデータ・テーブル500は、各組織およびテーブル（たとえば、以下に詳しく説明する標準テーブルやカスタム・テーブル）について定義された各カスタム・フィールド列の名前、データ・タイプ、およびその他の情報を記録するのに使用される。図示のように、メタデータ・テーブル500は、カスタム_フィールド_定義_id列510、組織_id列520、テーブル名またはid列530、フィールド名列540、フィールド・データタイプ列550、インデックス付け_有無列560、および列_番号列570を含んでいる。組織_id列520は、カスタム・フィールドが作成される組織の組織idを記憶しおり、カスタム_フィールド_定義_id列はテーブル500用のプライマリ・キーである。テーブル名列530は、得意先のような標準エンティティ・テーブルの名前、または組織に関して作成されたカスタム・エンティティ・テーブルのidを記憶する。フィールド名列540は、カスタム・フィールドのテキスト名を記憶し、フィールド・データタイプ列550は、カスタム・フィールドのデータ・タイプを記憶する。データ・タイプの例にはテキスト、番号、日付、ピックリストなどが含まれる。ピックリスト・データ・タイプは、値の列挙リストから値が選択されるテキスト・フィールドである。ピックリストは通常、UIにおけるドロップダウンとして表示される。インデックス付き列560は、このフィールドについて、以下に詳しく説明するインデックス付けのフラグが立っているかどうかを示す値を記憶する。一局面では、列560は、ブール値を記憶する。列_番号列570は、カスタム・フィールド・テーブル210（図3）内のカスタム・フィールドに割り当てられた列番号（たとえば、"val0"）を記憶する。

アプリケーションにおいて新しいカスタム・フィールドを作成すると、データを保持する1つのカスタム・フィールド列213が割り当てられる。好ましい局面では、最小番号の列が最初に充填される。たとえば、図3に示されているように、"val0"列が最初に充填され、次に"val1"列が充填され、以下同様に各組織の各列が充填される。したがって、組織によって定義されるカスタム列の数に応じて、各カスタム・フィールド213は組織用のデータを含んでも含まなくてもよい。ここで、組織内のアプリケーションのユーザがそのテーブル用の行を編集する際、他のすべての標準フィールドと同じに見える新しいカスタム・フィールドが画面上に（またはAPIを介して）表示される。しかし、このデータがデータベース内に持続すると、カスタム・フィールドの値は、標準メイン・テーブル200ではなく別個のカスタム・フィールド・テーブル210内の指定されたカスタム・フィールド列に記憶される。

一局面では、基本的な物理ストレージは文字ベースであるにもかかわらず、これらのカスタム・フィールドには様々な仮想データ・タイプが許容される。組織のシステム管理者が、たとえば数値または日付カスタム・フィールド・タイプを定義すると、これらの値は、論理データ・タイプへの容易な再変換を可能にするフォーマットのテキストとして記憶される。前述のように、一局面では、好ましくはVARCHARというデータ・タイプが使用される。たとえば、この局面では、日付は、TO_DATE（<列>、'YYYYMMDD'）関数を介した変換を可能にすると共に変換を行わずに適切な記憶を可能にするYYYYMMDDフォーマットで記憶される。番号については、通常の10進フォーマットが使用され、オラクル関数TO_NUMBER()を使用して、ソート、演算、フィルタリングなどに関する数値に変換することができる。

データベースがマルチテナントであるため、所与の物理カスタム・フィールド列は、複数の組織にわたるデータを含んでよい。たとえば、組織は特定のデータ・タイプに限定されないため、ある組織が日付のようなあるデータ・タイプを定義し、別の組織が文字列や番号のような異なるデータ・タイプを定義することができる。したがって、文字列、番号、および日付はすべて1つの物理カスタム・フィールド列に入力される可能性が高い。図3は、いくつかの異なるデータ・タイプを含むカスタム・フィールド列の一例を示している。たとえば、"val0"カスタム列に示されているように、組織1によって定義されるカスタム列データ・タイプはデータ・タイプ1であり、組織2によって定義されるカスタム列データ・タイプはデータ・タイプ2であり、組織Nによって定義されるカスタム列データ・タイプはデータ・タイプ3である。データ・タイプ1、2、および3は同じであっても、異なっていてもよい。たとえば、データ・タイプ1がテキストであり、データ・タイプ2が日付であり、データ・タイプ3が番号であってよい。図7および以下の関連する議論は、様々なデータ・タイプがカスタム・フィールド列に混合される例を示している。一局面では、いくつかの異なるデータ・タイプのカスタム・フィールドに対して列の別個のプールが設けられ、すなわち、別個のプール内の各カスタム・フィールド列は単一のデータ・タイプを含んでいる。

一態様では、メタデータを使用して所与のカスタム・フィールド列のデータ・タイプが判定される。すなわち、メタデータを使用して各カスタム列内の各組織の論理データ・タイプが追跡される。一局面では、メタデータからマッピング関数が作成される。たとえば、組織が標準エンティティ用のカスタム・フィールドを定義すると、その組織の組織id、テーブル名（たとえば、得意先_cfデータ）、およびカスタム・テーブルに割り当てられた列番号（たとえば、val0）を含むカスタム・フィールド定義がメタデータ・テーブル500に記憶される。このように、列番号、テーブル名、および組織idが与えられたと仮定すると、任意のカスタム列のデータ・タイプを求めてデータを効率的に検索することができる。

カスタム・フィールド・インデックス付け
次に、これらのカスタム・フィールド列（たとえば、列213）のデータにインデックス付けして高速検索を可能にする問題について考える。たとえば、ユーザは、日付としての日付値および番号としての数値でフィルタリングを行おうとする。しかし、これらのフィルタが効率的に働くためには、それらの値を変換するために使用される上記の表現が与えられたと仮定すると、所与のカスタム・フィールド列のデータの各組織のスライス上に関数インデックス（たとえば、オラクルDB関数インデックス）を入力する必要がある。これは、オラクルDBの視点からは不可能である。なぜなら、オラクルDBは、1つの物理列が複数のフォーマットのデータを含んでいることを理解しないからである。たとえば、上記のTO_DATEまたはTO_NUMBER表現に関するインデックスを作成しようとした場合、その物理列内の他のテキスト値が所望のフォーマットに合致しないためエラーが生じるからである。

同様に、文字列データを探索する際、ユーザは、大文字と小文字を区別しない探索を想定する。すなわち、"car"を探索した場合、"CAR"または"CaR"が見つかるべきである。しかし、大文字と小文字を区別しないことの定義は言語によって異なり、そのようなマルチテナント・データベース構造を使用するサービス（たとえば、CRMサービス）は多言語イネーブル型である場合がある。多言語データを適切に探索するには、オラクルの様々なNLS（自然言語標準）関数を使用して構築された関数インデックスを使用する必要がある。所与の物理列は複数の言語のデータを含むため、サポートされる各言語についてN個の異なるインデックスを構築する必要があり、スケーリング不能な方法となる。

上述の理由で、一態様では、別個の1組のインデックス付けされた列にデータを記憶することによって、このような「インデックス付きカスタム・フィールド」が実現される。本発明の一態様によれば、カスタム・フィールドのインデックス付けを可能にする複数の追加的なインデックス列が設けられる。データベース管理者によってカスタム・フィールドにインデックス付けのフラグが立てられると、そのフラグの立った列に複数のインデックス列のうちの1つが割り当てられる。フラグの立った列からのデータは、割り当てられたインデックス列にコピーされる。データは、たとえば日付および文字列の探索を容易にするフォーマットでインデックス列に記憶される。たとえば、YYYYMMDDはそれ自体が探索可能なフォーマットである。というのは、このフォーマットの文字列は、通常の文字列比較を使用して語彙を比較することができるからである。

図4は、一態様による物理インデックス列320を含むカスタム・フィールド・テーブル310として表されたカスタム・オブジェクトの一例を示している。一局面では、各カスタム・フィールド・データ・テーブルは、たとえば標準オラクルB*Treeインデックスを使用する、物理的にインデックス付けされた複数の（たとえば、10個、100個、250個などの）列320を含む。したがって、10個のインデックス付けされた列の例では、管理者は、インデックス付けすべきフィールドとして、文字列または日付タイプの最大10個のカスタム・フィールドを指定することができる。カスタム・フィールドにインデックス付けのフラグが立っている際、最初の列（依然として、必要に応じて未修正フォーマットをユーザに表示するように維持されている）のデータがこれらのインデックス付けされた列のうちの1つにコピーされる。たとえば、図4に示されているように、カスタム・データ・フィールド"val0"は、組織1のシステム管理者によってインデックス付きカスタム列としてフラグが立てられている。このフラグの立った列からのデータはインデックス列"ival0"にコピーされる。同様に、カスタム・データ・フィールド"val1"は、組織2のシステム管理者によってインデックス付きカスタム列としてフラグが立てられ、このフラグの立った列からのデータはインデックス列"ival0"にコピーされる。その後ある時点で、組織2のシステム管理者は、フラグの立った他のカスタム・フィールド列を有することができ、この列のデータは他のインデックス列にコピーされる（たとえば、図4に示されているように列"val0"データは列"ival1"にコピーされる）。一局面では、カスタム・フィールドと同様に、好ましくは最小番号のインデックス列が最初に使用されるかまたは充填される。

一局面では、複数の言語にわたる探索の問題を解消するために、各文字列カスタム・フィールド値を、大文字と小文字を区別しない汎用フォーマットに変換する「ケース・フォールディング」アルゴリズムが（たとえば、アプリケーション・サーバで）実施される。このようなケース・フォールディング・アルゴリズムの1つは、参照として本明細書に組み入れられるユニコード4.0標準におけるユニコード・コンソーシウム、第3.13節−大文字と小文字を区別しない一致（http://www.unicode.org/versions/Unicode4.0.0/ch03.pdf）によって定義されたアルゴリズムである。これは、大文字と小文字の概念を有するすべての言語について大文字と小文字の区別とは無関係に2進比較可能な形式に文字を変換する図表探索関数である。最初のカスタム・フィールド列の値を探索するときはいつでも、その代わりにSQLが、探索中の直定数に同じケース・フォールディング動作を実行した後で対応するケース・フォールディングされたインデックス付き列でフィルタリングする。日付は、そのYYYYMMDDフォーマットから修正する必要はなく、YYYYMMDDフォーマットもテキストとしてインデックス（未修正）に含まれている。

インデックス付きカスタム・フィールドを使用しない組織は、これらのフィールドにヌル値を有し、ヌルはインデックスにおける空間を占有しない。このように、データベース内の空間を使い果たすのは、カスタム列が実際にインデックス付けされるときだけである。さらに、インデックス列320は、好ましくは、対応するカスタム・フィールド・テーブルに記憶されるが、アウト・オブ・ロウで記憶することができ、その場合、組織id 311列およびテーブルid 312列をインデックス付けされた別個の列テーブルにコピーして探索を容易にすることが好ましい。

カスタム・フィールドの一意性
他の所望のスキーマ特性は一意性制約の概念である。この場合も、一意のインデックスをカスタム・フィールド物理列上に配置することはできない。なぜなら、これらの値は、1つの組織については一意であるが、その物理列を共用する他のいくつかの組織には一意でないからである。たとえば、2つの異なる組織の2つのレコードに関して、同じカスタム・フィールドにまったく同じデータ値が記憶されることがある。

この一意性を実現するために、一局面では、一意性を必要とする顧客のデータ値のみを含む別個のテーブルが設けられる。組織の管理者が一意性に関するカスタム・フィールドをイネーブルすると、その組織に関するすべての値がこの一意インデックス・テーブルに挿入され、このカスタム・フィールド列へのその後の変更は一意のインデックス・テーブル（後述）に同期して更新される。これらの動作のいずれかによってオラクルDBの一意インデックス違反が起こった場合、エンド・ユーザにエラーが返され、管理者は、フィールド内のデータを一意であると宣言する前に「クリーンナップ」しておく必要がある。

一意インデックス・メンテナンス・テーブルの一スキーマは以下のとおりである。
1. 組織_id
2. カスタム・フィールド定義id
3. カスタム・フィールド値

このスキーマは、同じ組織（およびエンティティ）の複数のカスタム・フィールドにインデックス付けするのを可能にする。最初の2列は好ましくは、オラクルDB一意インデックスに圧縮される。というのは、これによって物理インデックスがより小さくなるからである。このテーブルはインデックスによって構成することができる。これは、このテーブルのテーブルとしての目的が一意インデックスとして使用されることだけであるからである。

カスタム・テーブル
基本アプリケーションを拡張するかまたは他のシステムと統合するために新しい論理エンティティ・テーブル（エンティティ）全体を作成することも望ましい。たとえば、システムによって実現される標準エンティティを使用する組織は、1つまたは複数の新しいエンティティを作成して、その組織の特定のビジネス・モデルに特定的に対処し、このビジネス・モデルに関するデータ記憶および検索を容易にすることを望む場合がある。したがって、本発明の一態様は、カスタム・エンティティ・テーブルまたはカスタム・エンティティを作成する機能を実現する。

カスタム・フィールド用の手法に関しては、一態様ではすべてのカスタム・データ・エンティティ・データ行が単一のマルチテナント物理テーブルに記憶される。しかし、標準カスタム・フィールド・テーブルとは異なり、一局面におけるカスタム・エンティティ・データ・テーブルは、1組織当たり複数の論理テーブルを含んでいる。顧客には、顧客の複数の「テーブル」が実際に1つの大きなテーブルに記憶されているように見える。

図5は、一態様によるカスタム・エンティティ・テーブルとして表されたカスタム・オブジェクトの一例を示している。テーブル400は、組織id列401、カスタム・エンティティid列402、および複数のカスタム・フィールド列403（"val0", "val1",...と示されている）。複数の任意のインデックス列420（"ival0", "ival1",...と示されている）を設けてもよい。組織idは、テーブル400に示されている様々な組織同士を区別するのに使用される。たとえば、複数の組織が、一局面ではすべてがテーブル400に記憶されるカスタム・エンティティを作成することができる。カスタム・エンティティid列402は、テーブル400に記憶されている様々なカスタム・エンティティ・テーブル同士を区別するのに使用される。カスタム・エンティティid列402は、テーブル400用のプライマリ・キー列としても働く。カスタム・フィールド列403は、様々な組織によって定義される様々なカスタム・エンティティに関するデータを記憶するのに使用される。具体的には、カスタム・フィールド列403は、テーブル400に示されている様々な組織によって定義される様々なカスタム・エンティティの各々について定義された列を記憶する。インデックス列420は、上記に図4を参照して説明したカスタム・フィールド・インデックス付き列320と同様に実現される。

一態様によれば、グローバルに一意のプライマリ・キー・フィールド402の最初の3文字は、特定のエンティティ・タイプを識別するのに使用される。この技術は有利なことに、後述のように1つの組織の複数のカスタム・エンティティ・タイプをこの1つのカスタム・エンティティ・テーブル400で区別するのを可能にする。しかし、エンティティを識別するために使用されるプライマリ・キーの文字が最初の3文字よりも少なくても多くてもよく、あるいはプライマリ・キーの文字の任意の部分組合せを使用してよいことが理解されよう。

組織の管理者が新しいカスタム・エンティティを定義すると、その定義は基礎データ・ディクショナリではなくメタデータに記憶される。図6bは、本発明の一態様によるカスタム・エンティティ定義メタデータ・ディクショナリ600（「カスタム_エンティティ_定義」）の一例を示している。新しいカスタム・エンティティが定義されると、データベース・システムは、そのエンティティ・タイプの行用の（その組織内で）一意の3文字プレフィックスを割り当てる。一局面では、テーブル400の列402に示されているように、文字'a'が、すべてのカスタム・エンティティ・プライマリ・キー、たとえばa01 ... a02 ... a03 ... aMN ...の最初の文字として選択される。図示のように、すべての組織にわたって同じ3文字プレフィックスを再使用することができる。たとえば、複数の組織のプレフィックスとして"a01"が再使用されている。しかし、カスタム・エンティティidの残りの部分によってグローバル一意性が確保される（かついくつかの異なる組織のデータが混じることはなくなる）。一局面では、これらの3文字idはbase62で符号化され、したがって、各々の最初の文字によって、1組織当たり62*62=3844個の異なるカスタム・エンティティ・タイプが可能になる。これは、実質的にすべてのユーザに十分な数である。しかし、この異なる符号化ベースを使用して1組織当たりのカスタム・エンティティ・タイプの数を少なくすることも多くすることもできることを理解されたい。カスタム・エンティティidフィールドが、たとえば2つ以上の列、すなわち、プレフィックス用の1つの列およびカスタム・エンティティidの残りの部分用の他の列にわたる複合プライマリ・キーであってよいことも理解されたい。説明を簡略化するために、行区画はテーブル400に示されていないが、組織区画450およびエンティティ区画460は示されている。

図6bを参照すると、カスタム_エンティティ_定義メタデータ・テーブル600を使用して、各組織について定義されたカスタム・エンティティ・オブジェクトの名前およびその他の情報が記録されている。図示のように、メタデータ・テーブル600は、カスタム_エンティティ_定義_id列610、組織_id列620、エンティティ_名列630、およびキー・プレフィックス列540を含んでいる。組織_id列620は、カスタム・エンティティが作成される組織の組織idを記憶し、カスタム_エンティティ_定義_id列610はテーブル600用のプライマリ・キーである。エンティティ名列630は、カスタム・エンティティ・テーブルの名前を、たとえばテキスト・データ・タイプとして記憶する。キー・プレフィックス列640は、エンティティ・タイプの行用に割り当てられた3文字プレフィックス（たとえば、"a01"、"a02"など）を記憶する。

カスタム・エンティティ・テーブルが作成されると、組織の管理者は、カスタム・エンティティの（組織内で）一意の開発者名を指定する。これは、API呼に関するその特定のエンティティおよびシステムに対する他の開発者エントリ・ポイントを識別するのに使用される。この名前は、テーブル600のエンティティ名列630に記憶される。カスタム・エンティティについてカスタム・フィールドを定義することもでき、かつ必要に応じて、上述のようにカスタム・フィールドにフラグを立てることができる。カスタム・エンティティについてカスタム・フィールドが定義されると、組織は、そのカスタム・エンティティを他の任意の標準エンティティと同様に使用し始めることができる。たとえば、すべてのAPI動作（たとえば、記述、挿入、更新、削除、問合せ、探索）が利用可能になり、組織は、そのカスタム・エンティティをオンライン・アプリケーションで編集するユーザ・インターフェースを定義することができる。しかし、ユーザおよび組織には、カスタム・エンティティ・テーブルが、その組織と他の組織によって定義された他のカスタム・エンティティ・テーブルと一緒に単一のカスタム・エンティティ・テーブル400に記憶されるように見える。

カスタム・エンティティ・テーブルに対して動作するときのSQLに関する1つの違いは、組織idだけでなくカスタム・エンティティidでもフィルタリングして、1つの組織内の複数の論理エンティティ・タイプのデータが混合されないようにする必要があることである。たとえば、プライマリ・キー・インデックス（たとえば、a01 ... aMN）の先頭の3文字部分をこの効率的なフィルタリングに使用することができる。したがって、組織idおよび3文字プレフィックスでフィルタリングすると、組織の特定のエンティティ・タイプを判定することができる。同様に、挿入PL/SQL呼には、新しいプライマリ・キーおよびカスタム・エンティティ行を挿入する際にどの3文字プレフィックスを使用する各を指定すべきである。

図3のカスタム・フィールド列213と同様に、カスタム・フィールド列403は、複数のデータ・タイプを含んでよい。たとえば、組織#1がカスタム・エンティティ・テーブル1（テーブル400内の組織1"00d1"の"a01"によって識別される）を定義する際、図示のように、データ・タイプ1を有するカスタム・フィールド列定義を"val0"に割り当てることができる。同様に、図示のように、データ・タイプ2を有する第2のカスタム・エンティティ・テーブル（組織1の"a02"によって識別される）のカスタム・フィールド列定義を同じ"val0"に割り当てることができる。データ・タイプ1および2は同じであっても異なっていてもよい。このように、様々な組織によって定義された様々なカスタム・エンティティのカスタム・エンティティ・テーブル400内の任意の所与のカスタム・フィールド列403に多数のデータ・タイプを記憶することが可能である。したがって、組織は、任意のインデックス・フィールド420を使用して、上述のように、インデックス付けすべきそのカスタム・エンティティにおける1つまたは複数の列にフラグを立てることが可能である。フィルタリングも上述のフィルタリングと同様に進行する。

一態様では、外部キーは、カスタム・エンティティを作成する際にデータ・タイプとして定義することができる。このように、標準エンティティまたは他のカスタム・エンティティとの関係を確立してデータの記憶および検索を容易にする（たとえば、冗長なデータ記憶を低減させる）ことができる。たとえば、カスタム・エンティティを定義する際、システム管理者は、カスタム・フィールドを外部キー・データ・タイプとして定義し、1つまたは複数の他のエンティティとの関係を確立することができる。関連するエンティティ用のプライマリ・キーは、そのカスタム・フィールドにコピーされ記憶される。一局面では、タイプ外部キーのカスタム・フィールドを記憶する複数の列が設けられる。これらの別個の列にインデックス付けすることができる。

具体的な例
図7は、標準列703およびカスタム・フィールド列713を含む標準エンティティ・テーブル700の例と、複数の組織に関する実際のデータ値の例とを示している。図示のように、標準テーブル700は、標準名前フィールドおよびその他の標準フィールド703を有する得意先エンティティを表している。この例では、ABC Corp.（組織idフィールド701内の"00d1"によって識別される）は、val0列に割り当てられた「得意先ウェブ・アドレス」のカスタム列を定義している。このカスタム・フィールドのデータ・タイプはテキストとして定義されている。さらに、ABC Corp.は、val1列に割り当てられた「得意先株価」用の第2のカスタム・フィールドおよび他の列に割り当てられた「得意先ティッカー記号」用の第3のカスタム・フィールドを定義している。これらの列のデータ・タイプは、それぞれ番号およびテキストである。同様に、123 Corp.（組織idフィールド701内の"00d2"によって識別される）およびXYZ Corp.（組織idフィールド701内の"00dN"によって識別される）の各々は、それぞれ「得意先次回年次会議日付」および「得意先会計年度」用のカスタム・フィールドを定義している。これらのカスタム・フィールドのデータ・タイプは、それぞれ日付およびピックリストである。これらのカスタム・フィールドは、そのデータ・タイプが異なるにもかかわらず、どちらもval0列に割り当てられている。これらのカスタム・フィールドの定義は、上述のようにメタデータ、たとえばメタデータ・テーブル500に記憶される。

図示のように、テーブル700は、図示のように「IBM」、「デル」、および「アップル」の特定得意先データを含むABC Corp.に関する得意先データを保持する。同様に、テーブル700は、123 Corp.およびXYZ Corp.に関する得意先データも保持する。図示のように、123 Corp.とXYZ Corp.はどちらもそれぞれ、「ディズニー」という同じ名前を有する得意先用の特定のエントリを有している。しかし、これらのエントリは、グローバルに一意のプライマリ・キー702（または712）に基づいて区別される。たとえば、XYZ Corp.では、「ディズニー」の得意先エントリは"001...932"のプライマリ・キー値を有し、一方、123 Corp.の「ディズニー」得意先エントリは"001...87"のプライマリ・キー値を有している。上述のように、val0カスタム列内のデータ値は混合データ・タイプを有する。たとえば、ABC Corp.では、「ウェブ・アドレス」はテキストであり、一方、123 Corp.の「次回年次会議日付」は日付データ・タイプを有し、XYZ Corp.の「会計年度」フィールドはピックリスト・データ・タイプを有する。

図8は、ABC Corp.のカスタム・テーブル810を含むカスタム・エントリ・オブジェクト800の一例を示している。図示のように、ABC Corp.（組織id列801内の"00d1"によってしきされる）は、資産を表すカスタム・オブジェクト810を定義している。資産オブジェクト810の定義は、たとえばテーブル600（図6b）内のメタデータに記憶される。資産オブジェクト810は、カスタム・エンティティid用のプレフィックス"a02"を割り当てている。さらに、図示のように、 ABC Corp.は、たとえば、カスタム・エンティティid列802内のプレフィックス"a01"によって識別される、他のカスタム・オブジェクトを定義している。テーブル800に記憶される様々なオブジェクトのプレフィックス（たとえば、"a01"）を記憶する別個の列をテーブル800に設けることができる。資産オブジェクト810は、カスタム外部キー列および様々なデータ列によって定義されている。カスタム外部キー（FK）列は"val0"列に割り当てられ、一方、「資産名」、「資産価値」、「資産減価償却タイプ」、および「資産交換日付」の各データ・フィールドはそれぞれ、列"Val1"から"Val4"に割り当てられている。この例では、これらのフィールドのデータ・タイプはそれぞれ、テキスト、番号、ピックリスト、および日付である。

資産オブジェクト810は、得意先オブジェクト700の子カスタム・オブジェクトである。カスタム外部キー列は、オブジェクト810の各行をその親得意先に接続する（これらの例では、得意先オブジェクト700にそのテーブルidのプレフィックス"001"が割り当てられている）。たとえば、外部キー値"001...9"は、テーブル700内の得意先名「デル」の行に接続されている。同様に、外部キー値"001...8"および"001...10"は、それぞれ、テーブル700内の得意先名「IBM」および「アップル」の行に接続されている。さらに、図示のように、XYZ Corp.（組織id列801内の"00dN"によって識別される）は、そのビジネス・ニーズに適したカスタム・オブジェクトを定義しており、このカスタム・オブジェクトもテーブル800に記憶されている。このため、任意の所与のデータ列803は、テーブル800に記憶されている様々なカスタム・オブジェクトの定義に応じて混合データ・タイプを含んでよい。

再使用可能なサービス
カスタム・エンティティの1つの目標は、データのグリッド（たとえば、組織／顧客によって構成された行および列）をサポートするだけでなく、標準エンティティに対して示される同じ1組のアプリケーション・ハイレベル意味サービスもサポートすることである。これによって、オンライン・データ・プロバイダを超えるだけでなく、豊富な再使用可能サービスを有するアプリケーション構築インフラストラクチャでもあるシステムが実現される。

セールスフォースドットコム・サービスを参考にして、このような再使用可能サービスのいくつかの例と、それがどのようにカスタム・エンティティに適用されるかについて以下に説明する。

履歴追跡
セールスフォースドットコムにおける標準エンティティ（事例エンティティや機会エンティティなど）は、レコードに対するデータ変更の自動監査をサポートする。この監査は通常、すべてのデータがデータベースに書き込まれるアプリケーション・サーバにおいて低レベルで行われる。この同じコード・パスが好ましくはカスタム・エンティティに使用される。

標準エンティティに使用されるのと同じ一般化されたスキーマがカスタム・エンティティにも作用する。これは好ましくは、1行当たり1つのフィールド・デルタを有するピボット・スキーマである。
1. 組織_id
2. カスタム・エンティティ・データid
3. カスタム・フィールド定義id
4. 古い値
5. 新しい値
しかし、これは非ピボット・スキーマであってもよい。非ピボット・スキーマは、各々の別個の情報用の列を有する。このスキーマはエクセルのスプレッドシートに似ている。

ピボット・スキーマは以下のような汎用列名を使用する。

ピボット・スキーマはより多くの行を有するが、これらの行は幅がより狭くなる（50列のデータがあると仮定されたい。これは、ピボット・スキーマでは50行になるが、ピボット・スキーマ自体は同じ列を有する）。したがって、通常のスキーマは高さが低くて幅が広く、一方、ピボット・スキーマは高さが高く幅が狭い。ピボット・スキーマは、たとえば事例履歴関連リストを示すことなどの監査目的に有用であり、この場合、ユーザには、あらゆるフィールド値変化がグリッド内の1つの行として示される。しかし、ピボット・スキーマは通常、ある人のすべての情報を有する詳細画面と同様に通常のデータ・ディスプレイに使用するのは困難である。

管理者がカスタム・エンティティおよびカスタム・フィールドの定義においてこの特性を「オンにした」場合、この動作が自動的に行われる（変更はこの1つのマルチテナント監査テーブルに記録される）。この汎用履歴テーブル内のデータは、オンライン・アプリケーションにおける表示またはAPI問合せを介した表示に利用可能である。

一例として、事例などの標準エンティティに変更を加える場合を考える。システムは、事例の編集が保存されるときに以下の履歴行を記録することができる。

上記のデータは、2つの編集動作、すなわち、2004年3月4日に行われた事例5001の編集動作と2004年3月5日に行われた事例5002の編集動作を記録したものである。いくつかのフィールドは毎回編集されている。

他の例として、図8の資産カスタム・オブジェクト810に変更を加える場合を考える。2004年3月4日に行われた単一の編集動作の履歴追跡行は以下のように表示される。

この情報はすべてシステムによって自動的に記録される。ユーザ・インターフェース（UI）は、上記に示されたのと同様の情報、または他の任意の好都合なフォーマットの情報を示すことができる。

許可ベースのセキュリティ・共用モデル
管理者は、編集_得意先などの標準エンティティが許可を有するのと同様に特定のユーザ・プロファイルから特定のエンティティ・タイプへのアクセスを制限することを望む場合がある。

管理者は、所与のエンティティ・タイプが明白な読取り許可または編集許可を必要とすることを定義する。汎用プロファイル・カスタム・エンティティ・メタデータ・モデル（APIによる編集に利用可能）は、プロファイル（読取りアクセス）をカスタム・エンティティ・タイプに関連付ける関係行を作成するのを可能にし、任意に、そのプロファイルのユーザがそのエンティティ・タイプの行を編集できるかどうかを宣言する。

カスタム・エンティティ・データを検索し編集する共通のアプリケーション・サーバ・PL/SQLコードは、このメタデータを現在のユーザについて検査し、ユーザが適切な許可を有さない場合、動作を拒絶することができる。

一態様では、共用モデルは、上記の許可検査だけでなく各行へのアクセスのずっと細かい粒度を可能にする。管理者は、カスタム・エンティティ・タイプを定義する際、そのエンティティ・タイプが、すべてのユーザによって編集可能であるか（パブリック読取り／書込み）、すべてのユーザに対して読取り専用であるか（パブリック読取り／専用）、それともレコードの所有者またはレコードへの明白な共用アクセスを許可されているユーザのみが専用に利用可能であるかを選択することができる（プライベート）。

後者の共用モデルをサポートするために、一態様では、標準所有者フィールドがカスタム・エンティティ・データ・テーブルに付加され、APIで利用可能になっている。他の標準エンティティの所有者フィールドに付加されているのと同じ意味が適用される。たとえば、役割階層における責任者は、部下によって所有されているすべてのレコードにアクセスすることができる。さらに、汎用共用エンティティ、たとえばカスタム・エンティティ共用は、一態様では、得意先共用エンティティをAPI（およびUI）で使用して明白な得意先アクセスを許可するのと同様に、特定のカスタム・エンティティ行に対する手動の明白な共用アクセスをユーザまたはグループに入力する際に使用される。

通貨タイプ
カスタム・エンティティにおける標準フィールドには、その行内のすべての数値通貨慣習フィールドの通貨を制御する単一の通貨タイプがある。この機能は、すべての標準エンティティに整合し、アプリケーション内の他のあらゆる場所と同じ通貨換算が可能になる。

エンティティ・タイプ当たり複数のビジネス・プロセス
標準エンティティは、複数の「レコード・タイプ」またはビジネス・プロセスの定義を可能にする。たとえば、機会エンティティは電話販売機会と直接販売機会の両方を有することができる。個々の機会行のレコード・タイプに応じて、ピックリスト・フィールドに利用可能な値は、構成管理者による構成に応じて変化する。

カスタム・エンティティは、管理者によって同じメタデータを指定するのも可能にする。このエンティティにおけるピックリスト・カスタム・フィールドは、好ましくは標準エンティティの場合と同様の影響を受ける。

ワークフロー
一態様では、本発明は、特定のエンティティ・タイプのトリガ条件および処置の定義を可能にする。たとえば、機会量が特定の値を超えた場合（トリガ条件）、eメールなどの通知が、すでに指定されている個人またはグループ、たとえば、その組織の販売のVPに送信される（処置）。

この場合も、これらの規則を定義するために内部で使用されるメタデータは、好ましくは標準エンティティの場合と同様にカスタム・エンティティにも働く。たとえばアプリケーション・サーバまたはデータベース・サーバで実行され、行の編集のたびにこれらの条件を評価するコードは、標準エンティティとカスタム・エンティティの両方がこの機能を活用できる低レベルで出現する。

本発明を一例として特定の態様に関して説明したが、本発明が開示された態様に限定されないことを理解されたい。逆に、本発明は、当業者に明らかな様々な修正態様および同様の構成を対象とするものである。したがって、添付の特許請求の範囲の範囲については、すべてのそのような修正態様および同様の構成を包含するように最も広い解釈を施すべきである。

一態様による、マルチテナント・データベース・システム（MTS）を使用することのできる環境を示す。 一態様による、MTSの素子およびMTS内の相互接続を詳しく示す。 本発明の一態様による標準メイン・テーブルおよび関連するカスタム・フィールド・テーブルとして表されたオブジェクトの例を示す。 一態様による物理インデックス列320を含むカスタム・フィールド・テーブル310として表されたカスタム・オブジェクトを示す。 一態様によるカスタム・エンティティ・テーブルとして表されたカスタム・オブジェクトの一例を示す。 本発明の一態様によるカスタム・フィールド定義メタデータ・テーブルを示す。 本発明の一態様による各組織について定義された各カスタム・エンティティ・オブジェクトの名前およびその他の情報を記憶するのに使用されるメタデータ・テーブルを示す。 標準列およびカスタム・フィールド列を含む標準エンティティ・テーブルの例と、複数の擬似組織の実際のデータ値の例とを示す。 擬似組織のデータ値を有するカスタム・テーブルを含むカスタム・エンティティ・オブジェクトの一例を示す。

Claims (23)

1. 複数のデータ列および1つまたは複数のインデックス列を有するマルチテナント・データ構造を定義する段階と、
   第1のテナント用の、第1のデータ・タイプを有する第1のデータ・フィールドを定義する段階と、
   第2のテナント用の、該第1のデータ・タイプと異なる第2のデータ・タイプを有する第2のデータ・フィールドを定義する段階と、
   第1および第2のフィールドにデータ値を有するレコードが第1および第2のテナントによって作成されるときに、第1および第2のフィールドのデータ値をデータ構造内の、異なるテナント用の異なるデータ・タイプを有するデータ値を含む単一の列に記憶する段階と、
   第1のデータ・フィールド内のデータにインデックス付けするため第１のテナントからの要求に応答して第1のフィールド用の単一のデータ列に記憶されたデータ値をインデックス列の第1の列にコピーする段階とを含む、
   複数のテナント用の複数のフィールドを単一のマルチテナント・データ構造に記憶する、コンピュータによって実現される方法。
2. 1つまたは複数の列を有する別個のデータ構造を定義する段階と、
   第1のデータ・フィールドまたは第2のデータ・フィールド内のデータがそれぞれ一意である、第1のテナントおよび第2のテナントの一方からの表示に応答して、それぞれ第1のデータ・フィールドまたは第2のデータ・フィールドに対応する単一のデータ列に記憶されているデータ値を別個のデータ構造内の列にコピーする段階とをさらに含む、
   請求項1記載の方法。
3. コピーする段階が、コピーされたデータ値を修正されたフォーマットに変換する段階を含む、請求項1記載の方法。
4. 変換する段階が、ケース・フォールディング・アルゴリズム（case folding algorithm)をデータ値に適用する段階を含む、請求項3記載の方法。
5. プライマリ・キー列、組織id列、および複数のデータ列を有するマルチテナント・データ構造を定義する段階と、
   第1のテナントidを有する第1のテナント用の、第1のデータ・フィールドを有する第1のテーブルを定義する段階と、
   第1のテーブルに第1のテーブルidを割り当てる段階と、
   第2のテナントidを有する第2のテナント用の、第2のデータ・フィールドを有する第2のテーブルを定義する段階と、
   第2のテーブルに第2のテーブルidを割り当てる段階とを含む、
   1つまたは複数の組織用の複数のテーブルを単一のマルチテナント・データ構造に格納する、コンピュータによって実現される方法であって、
   第1のテナントによって第1のテーブル用のレコードが作成されるときに、作成される各レコードごとに、
   a)第1のデータ・フィールドの値をデータ構造内の単一のデータ列に記憶し、
   b)第1のテナントidを組織id列に記憶し、
   c)第1のテーブルidをプライマリ・キー列に記憶し、
   第2のテナントによって第2のテーブル用のレコードが作成されるときに、作成される各レコードごとに、
   a)第2のデータ・フィールドの値をデータ構造内の単一のデータ列に記憶し、
   b)第2のテナントidを組織id列に記憶し、
   c)第2のテーブルidをプライマリ・キー列に記憶し、
   第1および第2のテナントの第1および第2のテーブルがデータ構造に記憶される、コンピュータによって実現される方法。
6. データ構造が1つまたは複数のインデックス列を含み、
   第1のデータ・フィールド内のデータにインデックス付けするため第1のテナントからの要求に応答して、第1のテーブル用の単一のデータ列に記憶されているデータ値をインデックス列の第1の列にコピーする段階をさらに含む、
   請求項5記載の方法。
7. コピーする段階が、第1のテナントid、第1のテーブルid、および第1のデータ・フィールドに基づいてコピーすべきデータ値を識別する段階を含む、請求項6記載の方法。
8. 単一のデータ列が該第1および第2のデータ・タイプを有するデータ値を含むよう、第1のデータ・フィールドが第1のデータ・タイプを有し、第2のデータ・フィールドが第1のデータ・タイプとは異なる第2のデータ・タイプを有する、請求項5記載の方法。
9. プライマリ・キー列、組織id列、および複数のデータ列を有するデータ構造を定義する段階と、
   第1のテナントidを有する第1のテナント用の、第1のデータタイプを有する第1のデータ・フィールドを有する第1のテーブルを定義する段階と、
   第1のテーブルに第1のテーブルidを割り当てる段階と、
   第１のテナント用の、第1のデータ・タイプとは異なる第2のデータ・タイプを有する第2のデータ・フィールドを有する第2のテーブルを定義する段階と、
   第2のテーブルに第2のテーブルidを割り当てる段階とを含む、
   1つまたは複数のテナント用の複数のテーブルを単一のデータ構造に記憶する、コンピュータによって実現される方法であって、
   第1のテーブル用のレコードが作成されるときに、作成される各レコードごとに、
   a)第1のデータ・フィールドの値をデータ構造内の単一のデータ列に記憶し、
   b)第1のテナントidを組織id列に記憶し、
   c)第1のテーブルidをプライマリ・キー列に記憶し、
   第2のテーブル用のレコードが作成されるときに、作成される各レコードごとに、
   a)第2のデータ・フィールドの値を該単一のデータ列に記憶し、
   b)第1のテナントidを組織id列に記憶し、
   c)第2のテーブルidをプライマリ・キー列に記憶し、
   第1のテナントの第1および第2のテーブルがデータ構造に記憶され、該単一のデータ列が、該第1および第2のデータ・タイプを有するデータ値を含む、コンピュータによって実現される方法。
10. 第2のテナントidを有する第2のテナント用の、第3のデータ・タイプを有する第3のデータ・フィールドを有する第3のテーブルを定義する段階と、
    第3のテーブルに第3のテーブルidを割り当てる段階とをさらに含み、
    第3のテーブル用のレコードが作成されるときに、作成される各レコードごとに、
    第3のデータ・フィールドの値をデータ構造内の該単一のデータ列に記憶し、
    第2のテナントidを組織id列に記憶し、
    第3のテーブルidをプライマリ・キー列に記憶し、
    第1、第２および第３のテーブルがデータ構造に記憶され、該単一のデータ列が該第1と第2のデータ・タイプおよび第3のデータ・タイプを有するデータ値を含む、請求項9記載の方法。
11. 第1と第2のテーブルidが異なる、請求項9記載の方法。
12. 第1と第2のテーブルidが異なり、第3のテーブルidが第1および第2のテーブルidのうちの一方と同じである、請求項10記載の方法。
13. データ構造が1つまたは複数のインデックス列を含み、
    第1のデータ・フィールド内のデータにインデックス付けするため第1のテナントからの要求に応答して、第1のテーブル用の単一のデータ列に記憶されているデータ値をインデックス列の第1の列にコピーする段階をさらに含む、
    請求項9記載の方法。
14. コピーする段階がコピーされたデータ値を修正されたフォーマットに変換する段階を含む、請求項13記載の方法。
15. 変換する段階がケース・フォールディング・アルゴリズムをデータ値に適用する段階を含む、請求項14記載の方法。
16. 第3のデータ・タイプが、該第1のデータ・タイプ、該第2のデータ・タイプ、および第1および第2のデータ・タイプとは異なるデータ・タイプから成る群から選択される、請求項9記載の方法。
17. 第1のテナントが第1のテーブル用のレコードを作成したときに、そのレコード用の第1のデータ・フィールド内のデータ値がしきい値基準を満たすかどうかを判定するプロセスを実行し、データ値がしきい値基準を満たす場合、アクションルールを処理する、請求項9記載の方法。
18. アクションルールが通知の受信を示し、通知メッセージを自動的に受信側に送信する段階をさらに含む、請求項17記載の方法。
19. 第1のデータ・テーブル用の所有者フィールドを定義する段階をさらに含み、所有者フィールドに記憶されている各データ値が関連するレコードに関する階層ユーザ・アクセス・レベルを示す、請求項9記載の方法。
20. コードが、
    複数のデータ列および1つまたは複数のインデックス列を有するマルチテナント・データ構造を定義する指示と、
    第1のテナント用の、第1のデータ・タイプを有する第1のデータ・フィールドを定義する指示と、
    第2のテナント用の、該第1のデータ・タイプと異なる第2のデータ・タイプを有する第2のデータ・フィールドを定義する指示と、
    第1および第2のフィールドにデータ値を有するレコードが第1および第2のテナントによって作成されるときに、第1および第2のフィールドのデータ値をデータ構造内の、異なるテナント用の異なるデータ・タイプを有するデータ値を含む単一の列に記憶する指示と、
    第1のデータ・フィールド内のデータにインデックス付けするため第１のテナントからの要求に応答して第1のフィールド用の単一のデータ列に記憶されたデータ値をインデックス列の第1の列にコピーする指示とを含む、
    複数のテナント用の複数のフィールドを単一のマルチテナント・データ構造に記憶するようにデータベース・システムを制御するコードを記憶する、コンピュータ可読媒体。
21. コードが、
    プライマリ・キー列、組織id列、および複数のデータ列を有するマルチテナント・データ構造を定義する指示と、
    第1のテナントidを有する第1のテナント用の、第1のデータ・フィールドを有する第1のテーブルを定義する指示と、
    第1のテーブルに第1のテーブルidを割り当てる指示と、
    第2のテナントidを有する第2のテナント用の、第2のデータ・フィールドを有する第2のテーブルを定義する指示と、
    第2のテーブルに第2のテーブルidを割り当てる指示とを含む、
    複数のテナント用の複数のフィールドを単一のマルチテナント・データ構造に記憶するようにデータベース・システムを制御するコードを記憶する、コンピュータ可読媒体であって、
    第1のテナントによって第1のテーブル用のレコードが作成されるときに、作成される各レコードごとに、
    a)第1のデータ・フィールドの値をデータ構造内の単一のデータ列に記憶し、
    b)第1のテナントidを組織id列に記憶し、
    c)第1のテーブルidをプライマリ・キー列に記憶し、
    第2のテナントによって第2のテーブル用のレコードが作成されるときに、作成される各レコードごとに、
    a)第2のデータ・フィールドの値をデータ構造内の単一のデータ列に記憶し、
    b)第2のテナントidを組織id列に記憶し、
    a)第2のテーブルidをプライマリ・キー列に記憶し、
    第1および第2のテナントの第1および第2のテーブルがデータ構造に記憶される、コンピュータ可読媒体。
22. マルチテナント・データ・オブジェクトを記憶するデータベースと、
    複数のデータ列および1つまたは複数のインデックス列を有するマルチテナント・データ構造をデータベースにおいて定義し、
    第1のテナント用の、第1のデータ・タイプを有する第1のデータ・フィールドを定義し、
    第2のテナント用の、第1のデータ・タイプと異なる第2のデータ・タイプを有する第2のデータ・フィールドを定義し、
    第1および第2のフィールドにデータ値を有するレコードが第1および第2のテナントによって作成されるときに、第1および第2のフィールドのデータ値をデータ構造内の、異なるテナント用の異なるデータ・タイプを有するデータ値を含む単一の列に記憶し、
    第1のデータ・フィールド内のデータにインデックス付けするため第１のテナントからの要求に応答して第1のフィールド用の単一のデータ列に記憶されたデータ値をインデックス列の第1の列にコピーするよう構成された、データベース管理プロセスとを含む、
    マルチテナント・データベース・システム。
23. マルチテナント・データ・オブジェクトを記憶するデータベースと、
    プライマリ・キー列、組織id列、および複数のデータ列を有するマルチテナント・データ構造をデータベースで定義し、
    テナントidを有する第1のテナント用の、第1のデータ・フィールドを有する第1のテーブルを定義し、
    第1のテーブルに第1のテーブルidを割り当て、
    第2のテナントidを有する第2のテナント用の、第2のデータ・フィールドを有する第2のテーブルを定義し、
    第2のテーブルに第2のテーブルidを割り当てるように構成されたデータベース管理プロセスとを含む、
    マルチテナント・データベース・システムであって、
    第1のテナントによって第1のテーブル用のレコードが作成されるときに、作成される各レコードごとに、
    a)第1のデータ・フィールドの値をデータ構造内の単一のデータ列に記憶し、
    b)第1のテナントidを組織id列に記憶し、
    c)第1のテーブルidをプライマリ・キー列に記憶し、
    第2のテナントによって第2のテーブル用のレコードが作成されるときに、作成される各レコードごとに、
    a)第2のデータ・フィールドの値をデータ構造内の単一のデータ列に記憶し、
    b)第2のテナントidを組織id列に記憶し、
    c)第2のテーブルidをプライマリ・キー列に記憶し、
    第1および第2のテナントの第1および第2のテーブルがデータ構造に記憶される、マルチテナント・データベース・システム。

Images