複数のデータ列および1つまたは複数のインデックス列を有するマルチテナントデータ構造を定義する段階と、第1のテナント用の、第1のデータタイプを有する第1のデータフィールドを定義する段階と、第2のテナント用の、該第1のデータタイプと異なる第2のデータタイプを有する第2のデータフィールドを定義する段階と、第1および第2のフィールドにデータ値を有するレコードが第1および第2のテナントによって作成されるときに、第1および第2のフィールドのデータ値をデータ構造内の、異なるテナント用の異なるデータタイプを有するデータ値を含む単一の列に記憶する段階と、第1のデータフィールド内のデータにインデックス付けするため第1のテナントからの要求に応答して第1のフィールド用の単一のデータ列に記憶されたデータ値をインデックス列の第1の列にコピーする段階とを含む、複数のテナント用の複数のフィールドを単一のマルチテナントデータ構造に記憶する、コンピュータによって実現される方法。1つまたは複数の列を有する別個のデータ構造を定義する段階と、第1のデータフィールドまたは第2のデータフィールド内のデータがそれぞれ一意である、第1のテナントおよび第2のテナントの一方からの表示に応答して、それぞれ第1のデータフィールドまたは第2のデータフィールドに対応する単一のデータ列に記憶されているデータ値を別個のデータ構造内の列にコピーする段階とをさらに含む、請求項1記載の方法。コピーする段階が、コピーされたデータ値を修正されたフォーマットに変換する段階を含む、請求項1記載の方法。変換する段階が、ケースフォールディングアルゴリズムcasefoldingalgorithmをデータ値に適用する段階を含む、請求項3記載の方法。プライマリキー列、組織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のテーブルがデータ構造に記憶される、コンピュータによって実現される方法。データ構造が1つまたは複数のインデックス列を含み、第1のデータフィールド内のデータにインデックス付けするため第1のテナントからの要求に応答して、第1のテーブル用の単一のデータ列に記憶されているデータ値をインデックス列の第1の列にコピーする段階をさらに含む、請求項5記載の方法。コピーする段階が、第1のテナントid、第1のテーブルid、および第1のデータフィールドに基づいてコピーすべきデータ値を識別する段階を含む、請求項6記載の方法。単一のデータ列が該第1および第2のデータタイプを有するデータ値を含むよう、第1のデータフィールドが第1のデータタイプを有し、第2のデータフィールドが第1のデータタイプとは異なる第2のデータタイプを有する、請求項5記載の方法。プライマリキー列、組織id列、および複数のデータ列を有するデータ構造を定義する段階と、第1のテナントidを有する第1のテナント用の、第1のデータタイプを有する第1のデータフィールドを有する第1のテーブルを定義する段階と、第1のテーブルに第1のテーブルidを割り当てる段階と、第1のテナント用の、第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のデータタイプを有するデータ値を含む、コンピュータによって実現される方法。第2のテナントidを有する第2のテナント用の、第3のデータタイプを有する第3のデータフィールドを有する第3のテーブルを定義する段階と、第3のテーブルに第3のテーブルidを割り当てる段階とをさらに含み、第3のテーブル用のレコードが作成されるときに、作成される各レコードごとに、第3のデータフィールドの値をデータ構造内の該単一のデータ列に記憶し、第2のテナントidを組織id列に記憶し、第3のテーブルidをプライマリキー列に記憶し、第1、第2および第3のテーブルがデータ構造に記憶され、該単一のデータ列が該第1と第2のデータタイプおよび第3のデータタイプを有するデータ値を含む、請求項9記載の方法。第1と第2のテーブルidが異なる、請求項9記載の方法。第1と第2のテーブルidが異なり、第3のテーブルidが第1および第2のテーブルidのうちの一方と同じである、請求項10記載の方法。データ構造が1つまたは複数のインデックス列を含み、第1のデータフィールド内のデータにインデックス付けするため第1のテナントからの要求に応答して、第1のテーブル用の単一のデータ列に記憶されているデータ値をインデックス列の第1の列にコピーする段階をさらに含む、請求項9記載の方法。コピーする段階がコピーされたデータ値を修正されたフォーマットに変換する段階を含む、請求項13記載の方法。変換する段階がケースフォールディングアルゴリズムをデータ値に適用する段階を含む、請求項14記載の方法。第3のデータタイプが、該第1のデータタイプ、該第2のデータタイプ、および第1および第2のデータタイプとは異なるデータタイプから成る群から選択される、請求項9記載の方法。第1のテナントが第1のテーブル用のレコードを作成したときに、そのレコード用の第1のデータフィールド内のデータ値がしきい値基準を満たすかどうかを判定するプロセスを実行し、データ値がしきい値基準を満たす場合、アクションルールを処理する、請求項9記載の方法。アクションルールが通知の受信を示し、通知メッセージを自動的に受信側に送信する段階をさらに含む、請求項17記載の方法。第1のデータテーブル用の所有者フィールドを定義する段階をさらに含み、所有者フィールドに記憶されている各データ値が関連するレコードに関する階層ユーザアクセスレベルを示す、請求項9記載の方法。コードが、複数のデータ列および1つまたは複数のインデックス列を有するマルチテナントデータ構造を定義する指示と、第1のテナント用の、第1のデータタイプを有する第1のデータフィールドを定義する指示と、第2のテナント用の、該第1のデータタイプと異なる第2のデータタイプを有する第2のデータフィールドを定義する指示と、第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のテーブル用のレコードが作成されるときに、作成される各レコードごとに、a第1のデータフィールドの値をデータ構造内の単一のデータ列に記憶し、b第1のテナントidを組織id列に記憶し、c第1のテーブルidをプライマリキー列に記憶し、第2のテナントによって第2のテーブル用のレコードが作成されるときに、作成される各レコードごとに、a第2のデータフィールドの値をデータ構造内の単一のデータ列に記憶し、b第2のテナントidを組織id列に記憶し、a第2のテーブルidをプライマリキー列に記憶し、第1および第2のテナントの第1および第2のテーブルがデータ構造に記憶される、コンピュータ可読媒体。マルチテナントデータオブジェクトを記憶するデータベースと、複数のデータ列および1つまたは複数のインデックス列を有するマルチテナントデータ構造をデータベースにおいて定義し、第1のテナント用の、第1のデータタイプを有する第1のデータフィールドを定義し、第2のテナント用の、第1のデータタイプと異なる第2のデータタイプを有する第2のデータフィールドを定義し、第1および第2のフィールドにデータ値を有するレコードが第1および第2のテナントによって作成されるときに、第1および第2のフィールドのデータ値をデータ構造内の、異なるテナント用の異なるデータタイプを有するデータ値を含む単一の列に記憶し、第1のデータフィールド内のデータにインデックス付けするため第1のテナントからの要求に応答して第1のフィールド用の単一のデータ列に記憶されたデータ値をインデックス列の第1の列にコピーするよう構成された、データベース管理プロセスとを含む、マルチテナントデータベースシステム。マルチテナントデータオブジェクトを記憶するデータベースと、プライマリキー列、組織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のテーブルがデータ構造に記憶される、マルチテナントデータベースシステム。本発明の詳細な説明図面および特許請求の範囲を含む本明細書の残りの部分を参照すれば、本発明の他の特徴および利点が認識されよう。本発明の他の特徴および利点と、本発明の様々な態様の構造および動作については、添付の図面に関して以下に詳しく記載される。図面では、同じ参照符号は、同一または機能的に同様の要素を示す。図1は、マルチテナントデータベースシステムを使用できる環境を示している。図1に示されかつ図2により詳しく示されているように、あらゆるユーザシステム12が、ネットワーク14を介してマルチテナントデータベースシステムMTS16と対話することができる。このようなユーザシステム12のユーザは、様々な能力のユーザであってよく、特定のユーザシステム12の能力は、現在のユーザによって全体的に決定することができる。たとえば、セールスマンが特定のユーザシステム12を使用してMTS16と対話する場合、そのユーザシステムは、そのセールスマンに割り当てられた能力を有する。しかし、管理者がそのユーザシステムを使用してMTS16と対話している間、そのユーザシステムは、その管理者に割り当てられた能力を有する。ネットワーク14は、LANローカルエリアネットワーク、WANワイドエリアネットワーク、無線網、ポイントツーポイントネットワーク、スターネットワーク、トークンリングネットワーク、ハブネットワーク、またはその他の構成であってよい。現在使用されているネットワークの最も一般的な種類のネットワークが、本明細書の多数の例で使用される頭文字Iを有するインターネットと呼ばれることの多いネットワークのグローバルネットワークなどのTCPIP伝送制御プロトコルおよびインターネットプロトコルネットワークであるが、本発明が使用することのできるネットワークがそのように限定されないことを理解されない。ただし、TCPIPは現在好ましいプロトコルである。ユーザシステム12は、TCPIPを使用してMTS16と通信することができ、より高いネットワークレベルでは、HTTP、FTP、AFS、WAPのような、他の一般的なインターネットプロトコルを使用して通信することができる。一例として、HTTPを使用する場合、ユーザシステム12は、MTS16のHTTPサーバにHTTPメッセージを送信しかつこのHTTPサーバからHTTPメッセージを受信する一般にブラウザと呼ばれるHTTPクライアントを含んでよい。このようなHTTPは、MTS16とネットワーク14との間の単一のネットワークインターフェースとして実現することができるが、他の技術も同様に、またはHTTPの代わりに使用することができる。いくつかの実現態様では、MTS16とネットワーク14との間のインターフェースは、負荷の釣り合いをとり、着信HTTP要求を複数のサーバを介して均等に分配するランドロビンHTTP要求ディストリビュータなどの負荷共有機能を含んでいる。好ましくは、複数のサーバはそれぞれ、少なくともサーバにアクセスしているユーザに関して、MTSのデータにアクセスすることができる。好ましい局面では、図1に示されているシステムは、ウェブベースの顧客関係管理CRMシステムを実現する。たとえば、一局面では、MTS16は、CRMソフトウェアアプリケーションを実現し実行すると共に、ユーザシステム12との間で関連するデータ、コード、フォーム、ウェブページ、およびその他の情報をやり取りし、関連するデータ、オブジェクト、およびウェブページコンテントをデータベースシステムに記憶し、データベースシステムから検索するように構成されたアプリケーションサーバを含んでよい。マルチテナントシステムでは、テナントデータは好ましくは、あるテナントのデータが他のテナントのデータから分離され、したがって、あるテナントが他のテナントのデータに、このようなデータが明示的に共用されないかぎりアクセスできなくなるように構成される。MTS16の要素のある構成が図1に示されており、ネットワークインターフェース20と、テナントデータ用のストレージ22と、MTS16および場合によっては複数のテナントにアクセス可能であるシステムデータ用のストレージ24と、MTS16の様々な機能を実現するプログラムコード26と、MTSシステムプロセス、およびアプリケーションをアプリケーションサービスの一部として実行することなどテナント固有のプロセスを実行するためのプロセス空間28とを含んでいる。図1に示されているシステムのいくつかの要素には、本明細書では詳しく説明する必要のない従来の公知の要素が含まれる。たとえば、ユーザシステム12は、インターネットまたは他のネットワーク接続に直接または間接的に接続することのできるデスクトップパーソナルコンピュータ、ワークステーション、ラップトップ、PDA、携帯電話、あるいは任意のWAPイネーブルデバイスまたはその他の任意のコンピューティングデバイスを含んでよい。ユーザシステム12は通常、ユーザシステム12のユーザたとえば、CRMシステムの加入者が利用可能な情報およびページをMTS16からネットワーク14を介してアクセスし、処理し、表示するのを可能にするマイクロソフトのInternetExplorer商標ブラウザ、ネットスケープのNavigator商標ブラウザ、オペラのブラウザ、または携帯電話、PDA、他の無線装置などの場合のWAPイネーブルブラウザなどのブラウジングプログラムを実行する。各ユーザシステム12は通常、MTS16または他のシステムもしくはサーバから与えられるページ、フォーム、およびその他の情報と一緒にブラウザによってディスプレイたとえば、モニタ画面、LCDディスプレイなど上に表示されるグラフィカルユーザインターフェースGUIと対話する、キーボード、マウス、タッチスクリーン、ペンのような1つまたは複数のユーザインターフェース装置も含んでいる。上述のように、本発明は、複数のネットワークの特定のグローバルインターネットワークを指すインターネットと共に使用するのに適している。しかし、イントラネット、エクストラネット、仮想プライベートネットワークVPN、非TCPIPベースネットワーク、任意のLANまたはWANなどをインターネットの代わりに使用できることを理解されたい。一態様によれば、各ユーザシステム12およびそのすべての構成要素は、インテルペンティアム登録商標プロセッサなどの中央演算処理装置を使用して実行されるコンピュータコードを含むブラウザなどのアプリケーションを使用して、オペレータによって構成可能である。同様に、MTS16および複数のMTSが存在するMTSの他のインスタンスおよびそのすべての構成要素は、インテルペンティアム登録商標プロセッサなどの中央演算処理装置、または複数のプロセッサユニットを使用して実行されるコンピュータコードを含むブラウザなどのアプリケーションを使用して、オペレータによって構成可能である。相互に通信し、本明細書に記載されるようにウェブページならびにその他のデータおよび媒体コンテントを処理するようにMTS16を操作し構成するコンピュータコードは好ましくは、ダウンロードされハードディスク上に記憶されるが、プログラムコード全体またはその一部を、ROMやRAMのような公知の他の任意の揮発性または非揮発性メモリ媒体または装置に記憶するか、あるいはコンパクトディスクCD媒体、デジタルバーサトルディスクDVD媒体、フロッピィディスクのような、プログラムコードを記憶できる任意の媒体上に供給することもできる。さらに、プログラムコード全体またはその一部を、公知のように、たとえばインターネットを介してソフトウェアソースから伝送しダウンロードするか、または他のサーバから送信しダウンロードするか、あるいは任意の通信媒体およびプロトコルたとえば、TCPIP、HTTP、HTTPS、イーサネット登録商標などを使用して公知のように他の任意の従来のネットワーク接続たとえば、エクストラネット、VPN、LANなど上で送信することができる。本発明の各局面を実現するコンピュータコードを、たとえばC、C、HTML、Java登録商標、Java登録商標Script、VBScriptや公知の他の多数のプログラミング言語のような他の任意のスプリプト言語など、サーバまたはサーバシステム上で実行できる任意のプログラミング言語で実施できることも理解されよう。一態様によれば、各MTS16は、ウェブページ、フォーム、データ、および媒体コンテントをユーザシステム12に供給して、MTS16のテナントとしてのユーザシステム12によるアクセスをサポートするように構成される。このため、MTS16は、各テナントのデータを、そのデータが共用されないかぎり分離しておくためのセキュリティ機構を実現する。複数のMTSを使用する場合、それらを互いに近接させてたとえば、単一の建物またはキャンパス内に配置されたサーバファーム内に配置することも、互いに遠い位置に分散させるたとえば、都市Aに1つまたは複数のサーバを配置し、都市Bに1つまたは複数のサーバを配置することもできる。本明細書では、各MTSは、ローカルにまたは1つまたは複数の地理的位置にわたって分散された1つまたは複数の論理的および/または物理的に接続されたサーバを含んでよい。さらに、語サーバは、処理ハードウェアおよび処理空間を含むコンピュータシステム、ならびに当技術分野で公知の関連する記憶システムおよびデータベースアプリケーションたとえば、RDBMSを含むことを意味する。本明細書ではサーバシステムとサーバが相互交換可能に使用されることが多いことも理解されたい。同様に、本明細書で説明するデータベースは、単一のデータベース、分散データベース、分散データベースの集合、冗長オンラインもしくはオフラインバックアップまたは他の冗長性などを有するデータベースとして実現することができ、かつ分散データベースまたは記憶ネットワークおよび関連する処理インテリジェンスを含んでよい。図2は、MTS16の各要素および様々な相互接続部を詳しく示している。この例では、ネットワークインターフェースは、1つまたは複数のHTTPアプリケーションサーバ100として実現される。個別テナント処理空間104を含む処理空間102と、システムデータベース106と、テナントデータベース108と、テナント管理処理空間110も示されている。テナントデータベース108は、物理的構成であっても論理構成であってもよい個別テナントストレージエリア112に分割することができる。各テナントストレージエリア112内で、ユーザストレージ114を各ユーザごとに同様に割り当てることができる。各アプリケーションサーバ100をそれぞれの異なるネットワーク接続を介してデータベースシステム、たとえばシステムデータベース106およびテナントデータベースに通信可能に結合できることも理解されたい。たとえば、あるサーバ1001をインターネット14を介して結合することができ、他のサーバ100N1を直接ネットワークリンクを介して結合することができ、他のサーバ100Nをさらに異なるネットワーク接続によって結合することができる。伝送制御プロトコルおよびインターネットプロトコルTCPIPは、サーバ100とデータベースシステムとの通信に好ましいプロトコルであるが、使用されるネットワーク相互接続に応じて他の転送プロトコルを使用してシステムを最適化できることが当業者には明らかであろう。好ましい局面では、各アプリケーションサーバ100は、任意のユーザ/組織に対する要求を処理するように構成される。任意の時間に任意の理由でアプリケーションサーバをサーバプールに追加し、サーバプールから削除することができることが望ましいので、好ましくは、ユーザおよび/または組織には特定のアプリケーションサーバ100に対するサーバアフィニティがない。したがって、一態様では、負荷釣り合わせ機能たとえば、F5BigIP負荷分散装置を実現するインターフェースシステム図示せずはサーバ100とユーザシステム12との間に通信可能に結合され、要求を各サーバ100に分散させる。一局面では、負荷分散装置は最小接続アルゴリズムを使用してユーザ要求をサーバ100に送る。ラウンドロビンや観測応答時間のような負荷釣り合わせアルゴリズムの他の例を使用してもよい。たとえば、ある局面では、同じユーザからの3つの連続する要求が3つの異なるサーバにヒットし、それぞれの異なるユーザからの3つの要求が同じサーバにヒットすることができる。このように、MTS16はマルチテナントであり、MTS16は、それぞれの異なるユーザおよび組織間のそれぞれの異なるオブジェクトおよびデータの記憶を処理する。記憶の一例として、あるテナントは、各セールスマンがMTS16を使用してその販売プロセスを管理する、販売員を雇用する会社であってよい。したがって、ユーザは、すべてたとえば、テナントデータベース108内のユーザの個人販売プロセスに適用することのできる連絡先データ、リードデータ、顧客追跡データ、業績データ、目標および進捗データなどを維持することができる。好ましいMTS構成では、すべてのこのデータおよびアクセス、表示、修正、報告、送信、計算などのアプリケーションを、ネットワークアクセスしかできないユーザシステムによって維持しアクセスすることができ、ユーザは自分の販売努力およびサイクルを多数の異なるユーザシステムから管理することができる。たとえば、セールスマンが顧客を訪れ、顧客がそのロビーでインターネットにアクセスできる場合、セールスマンは顧客がロビーで到着するのを待つ間にその顧客に関する重要な更新を行うことができる。各ユーザの販売データを各ユーザの雇用者とは無関係に他のユーザの販売データから分離することができるが、一部のデータは、テナントである所与の組織に関する複数のユーザまたはすべての販売員によって組織全体で共有されるかまたはアクセス可能なデータであってよい。したがって、テナントレベルで割り当てられるMTS16によって管理されるいくつかのデータ構造があってよく、一方、他のデータ構造をユーザレベルで管理することができる。MTSは、考えられる競合相手を含む複数のテナントをサポートできるので、MTSは、データ、アプリケーション、およびアプリケーション用途を別々に維持するセキュリティプロトコルを有するべきである。さらに、多数のテナントがそれ自体のシステムを維持するのではなくMTSへのアクセスを選択するので、冗長性、アップ時間、およびバックアップがより重大な機能であり、これらをMTSで実現する必要がある。MTS16は、ユーザ固有のデータおよびテナント固有のデータだけでなく、複数のテナントによって使用できるシステムレベルデータまたはその他のデータを維持することもできる。このようなシステムレベルデータは、各テナント間で共用できる業界レポート、ニュース、通知などを含んでよい。ある局面では、クライアントシステム12は、アプリケーションサーバ100と通信して、データベースシステム106および/またはデータベースシステム108への1つまたは複数の問合せを必要とすることがあるMTS16にシステムレベルデータおよびテナントレベルデータを要求し更新する。MTS16たとえば、MTS16内のアプリケーションサーバ100は、所望の情報にアクセスするように設計された1つまたは複数のSQL文SQL問合せを自動的に生成する。各データベースは一般に、定義済みの範疇に適合するデータを含む1組の論理テーブルのようなオブジェクトの集合とみなすことができる。テーブルは、データオブジェクトの一表現であり、本明細書では、本発明によるオブジェクトおよびカスタムオブジェクトの概念的な記述を簡略化するために使用される。本明細書ではテーブルおよびオブジェクトを相互交換可能に使用できることを理解されたい。各テーブルは一般に、表示可能なスキーマにおいて列またはフィールドとして論理的に構成された1つまたは複数のデータ範疇を含んでいる。テーブルの各行またはレコードは、フィールドによって定義される各範疇のデータのインスタンスを含んでいる。たとえば、CRMデータベースは、名前、住所、電話番号、ファックス番号のような基本的な連絡先情報用のフィールドで顧客を記述するテーブルを含んでよい。他のテーブルは、顧客、製品、販売価格、日付などの情報用のフィールドを含む購買注文を記述することができる。いくつかのマルチテナントデータベースシステムでは、標準エンティティテーブルを設けることができる。CRMデータベースアプリケーションでは、このような標準エンティティには、各テーブルが定義済みのフィールドを含む得意先データ、連絡先データ、リードデータ、および機会データのテーブルを含んでよい。カスタムフィールド一態様によれば、標準エンティティ用のテーブルなどのテーブルについては、追加的な1組の1つまたは複数の列、たとえば10列、100列、または250列のテキストデータが物理スキーマに定義される。これらの追加的な列は、本明細書ではカスタムデータ列、カスタムフィールド列、またはカスタムフィールドとも呼ばれ、システム管理者がそのエンティティ用の定義済み標準フィールドに含まれていない他のフィールドを定義するのを可能にする。このようなカスタムフィールドは好ましくは、VARCHAER可変長文字というデータタイプを有する。一局面では、これらのカスタムフィールドは好ましくは、メインエンティティテーブルから行の外でoutofrowで記憶される。ただし、これらのフィールドはメインテーブルに記憶することができる。たとえば、メインテーブルがセールスアカウントsalesacountという名称を有する場合、カスタムフィールドデータはセールスアカウントcfデータsalesacountcfdataというテーブルに記憶することができる。ここで、cfとはカスタムフィールドcustomfieldの略である。これらのテーブルはどちらも、好ましくは、各テナント行を区別する組織id列を含むと共に、データベース全体にわたってこれらの行を識別する同じインデックス付けされたプライマリキーたとえば、この場合は得意先idとを含む。さらに、どちらのテーブルも好ましくは、たとえば、メンテナンスのためにテーブル全体に作用し、より浅いインデックスを維持する必要があるときに、並列化を推進するようにDBたとえば、オラクルDB上で物理的に区画されている。図3は、メインテーブル200および関連するカスタムフィールドテーブル210として表されるオブジェクトの例を示している。図3に示されている特定の例では、メインテーブル200得意先は、標準得意先エンティティを表しており、カスタムフィールドテーブル210得意先cfデータは、メインテーブル200を使用して様々な組織テナントによって定義されるカスタムフィールドを含んでいる。図示のように、メインテーブル200は、組織IDorgid列201、およびテーブル200用のプライマリキーとして働くテーブルIDたとえば、得意先idを表すaccidを含んでいる。データテーブル200は、複数のデータ列203も含んでいる。図3の特定の例では、テーブルは標準エンティティを表し、データ列203は、テーブルを使用することのできる様々な組織に供給される定義済みデータ列または標準フィールドである。標準得意先エンティティの例では、このような標準フィールドは、名前列、サイト列、従業員数列、および得意先関連情報を記憶するうえで有用な他のフィールドを含んでよい。各データ列203は好ましくは、1列当たりに単一のデータタイプを記憶するように定義される。組織id列201は、マルチテナント得意先テーブル200を使用して組織同士を区別するために設けられている。図示のように、N個の異なる組織が、テーブル200に記憶されたデータを有している。列201の組織idは好ましくはCharであるが、他のデータタイプを含んでよい。一局面では、組織idの最初の3文字は、00dのような定義済みのプレフィックスに設定される。ただし、必要に応じて組織id内の文字の他の部分集合を使用してこのようなプレフィックスを保持することができる。カスタムフィールドテーブル210は同様に、組織id列211、テーブルid列212、および複数のデータ列213を含んでいる。上述のように、テーブルid列212は、テーブル210用のプライマリキーとして働き、好ましくはテーブル200のテーブルid列202と同じ値を含む。図示の特定の例では、val0、val1val249と示されている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というデータタイプが使用される。たとえば、この局面では、日付は、TODATE、YYYYMMDD関数を介した変換を可能にすると共に変換を行わずに適切な記憶を可能にするYYYYMMDDフォーマットで記憶される。番号については、通常の10進フォーマットが使用され、オラクル関数TONUMBERを使用して、ソート、演算、フィルタリングなどに関する数値に変換することができる。データベースがマルチテナントであるため、所与の物理カスタムフィールド列は、複数の組織にわたるデータを含んでよい。たとえば、組織は特定のデータタイプに限定されないため、ある組織が日付のようなあるデータタイプを定義し、別の組織が文字列や番号のような異なるデータタイプを定義することができる。したがって、文字列、番号、および日付はすべて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つの物理列が複数のフォーマットのデータを含んでいることを理解しないからである。たとえば、上記のTODATEまたはTONUMBER表現に関するインデックスを作成しようとした場合、その物理列内の他のテキスト値が所望のフォーマットに合致しないためエラーが生じるからである。同様に、文字列データを探索する際、ユーザは、大文字と小文字を区別しない探索を想定する。すなわち、carを探索した場合、CARまたはCaRが見つかるべきである。しかし、大文字と小文字を区別しないことの定義は言語によって異なり、そのようなマルチテナントデータベース構造を使用するサービスたとえば、CRMサービスは多言語イネーブル型である場合がある。多言語データを適切に探索するには、オラクルの様々なNLS自然言語標準関数を使用して構築された関数インデックスを使用する必要がある。所与の物理列は複数の言語のデータを含むため、サポートされる各言語についてN個の異なるインデックスを構築する必要があり、スケーリング不能な方法となる。上述の理由で、一態様では、別個の1組のインデックス付けされた列にデータを記憶することによって、このようなインデックス付きカスタムフィールドが実現される。本発明の一態様によれば、カスタムフィールドのインデックス付けを可能にする複数の追加的なインデックス列が設けられる。データベース管理者によってカスタムフィールドにインデックス付けのフラグが立てられると、そのフラグの立った列に複数のインデックス列のうちの1つが割り当てられる。フラグの立った列からのデータは、割り当てられたインデックス列にコピーされる。データは、たとえば日付および文字列の探索を容易にするフォーマットでインデックス列に記憶される。たとえば、YYYYMMDDはそれ自体が探索可能なフォーマットである。というのは、このフォーマットの文字列は、通常の文字列比較を使用して語彙を比較することができるからである。図4は、一態様による物理インデックス列320を含むカスタムフィールドテーブル310として表されたカスタムオブジェクトの一例を示している。一局面では、各カスタムフィールドデータテーブルは、たとえば標準オラクルBTreeインデックスを使用する、物理的にインデックス付けされた複数のたとえば、10個、100個、250個などの列320を含む。したがって、10個のインデックス付けされた列の例では、管理者は、インデックス付けすべきフィールドとして、文字列または日付タイプの最大10個のカスタムフィールドを指定することができる。カスタムフィールドにインデックス付けのフラグが立っている際、最初の列依然として、必要に応じて未修正フォーマットをユーザに表示するように維持されているのデータがこれらのインデックス付けされた列のうちの1つにコピーされる。たとえば、図4に示されているように、カスタムデータフィールドval0は、組織1のシステム管理者によってインデックス付きカスタム列としてフラグが立てられている。このフラグの立った列からのデータはインデックス列ival0にコピーされる。同様に、カスタムデータフィールドval1は、組織2のシステム管理者によってインデックス付きカスタム列としてフラグが立てられ、このフラグの立った列からのデータはインデックス列ival0にコピーされる。その後ある時点で、組織2のシステム管理者は、フラグの立った他のカスタムフィールド列を有することができ、この列のデータは他のインデックス列にコピーされるたとえば、図4に示されているように列val0データは列ival1にコピーされる。一局面では、カスタムフィールドと同様に、好ましくは最小番号のインデックス列が最初に使用されるかまたは充填される。一局面では、複数の言語にわたる探索の問題を解消するために、各文字列カスタムフィールド値を、大文字と小文字を区別しない汎用フォーマットに変換するケースフォールディングアルゴリズムがたとえば、アプリケーションサーバで実施される。このようなケースフォールディングアルゴリズムの1つは、参照として本明細書に組み入れられるユニコード40標準におけるユニコードコンソーシウム、第313節-大文字と小文字を区別しない一致httpwwwunicodeorgversionsUnicode400ch03pdfによって定義されたアルゴリズムである。これは、大文字と小文字の概念を有するすべての言語について大文字と小文字の区別とは無関係に2進比較可能な形式に文字を変換する図表探索関数である。最初のカスタムフィールド列の値を探索するときはいつでも、その代わりにSQLが、探索中の直定数に同じケースフォールディング動作を実行した後で対応するケースフォールディングされたインデックス付き列でフィルタリングする。日付は、そのYYYYMMDDフォーマットから修正する必要はなく、YYYYMMDDフォーマットもテキストとしてインデックス未修正に含まれている。インデックス付きカスタムフィールドを使用しない組織は、これらのフィールドにヌル値を有し、ヌルはインデックスにおける空間を占有しない。このように、データベース内の空間を使い果たすのは、カスタム列が実際にインデックス付けされるときだけである。さらに、インデックス列320は、好ましくは、対応するカスタムフィールドテーブルに記憶されるが、アウトオブロウで記憶することができ、その場合、組織id311列およびテーブルid312列をインデックス付けされた別個の列テーブルにコピーして探索を容易にすることが好ましい。カスタムフィールドの一意性他の所望のスキーマ特性は一意性制約の概念である。この場合も、一意のインデックスをカスタムフィールド物理列上に配置することはできない。なぜなら、これらの値は、1つの組織については一意であるが、その物理列を共用する他のいくつかの組織には一意でないからである。たとえば、2つの異なる組織の2つのレコードに関して、同じカスタムフィールドにまったく同じデータ値が記憶されることがある。この一意性を実現するために、一局面では、一意性を必要とする顧客のデータ値のみを含む別個のテーブルが設けられる。組織の管理者が一意性に関するカスタムフィールドをイネーブルすると、その組織に関するすべての値がこの一意インデックステーブルに挿入され、このカスタムフィールド列へのその後の変更は一意のインデックステーブル後述に同期して更新される。これらの動作のいずれかによってオラクルDBの一意インデックス違反が起こった場合、エンドユーザにエラーが返され、管理者は、フィールド内のデータを一意であると宣言する前にクリーンナップしておく必要がある。一意インデックスメンテナンステーブルの一スキーマは以下のとおりである。1組織id2カスタムフィールド定義id3カスタムフィールド値このスキーマは、同じ組織およびエンティティの複数のカスタムフィールドにインデックス付けするのを可能にする。最初の2列は好ましくは、オラクルDB一意インデックスに圧縮される。というのは、これによって物理インデックスがより小さくなるからである。このテーブルはインデックスによって構成することができる。これは、このテーブルのテーブルとしての目的が一意インデックスとして使用されることだけであるからである。カスタムテーブル基本アプリケーションを拡張するかまたは他のシステムと統合するために新しい論理エンティティテーブルエンティティ全体を作成することも望ましい。たとえば、システムによって実現される標準エンティティを使用する組織は、1つまたは複数の新しいエンティティを作成して、その組織の特定のビジネスモデルに特定的に対処し、このビジネスモデルに関するデータ記憶および検索を容易にすることを望む場合がある。したがって、本発明の一態様は、カスタムエンティティテーブルまたはカスタムエンティティを作成する機能を実現する。カスタムフィールド用の手法に関しては、一態様ではすべてのカスタムデータエンティティデータ行が単一のマルチテナント物理テーブルに記憶される。しかし、標準カスタムフィールドテーブルとは異なり、一局面におけるカスタムエンティティデータテーブルは、1組織当たり複数の論理テーブルを含んでいる。顧客には、顧客の複数のテーブルが実際に1つの大きなテーブルに記憶されているように見える。図5は、一態様によるカスタムエンティティテーブルとして表されたカスタムオブジェクトの一例を示している。テーブル400は、組織id列401、カスタムエンティティid列402、および複数のカスタムフィールド列403val0val1と示されている。複数の任意のインデックス列420ival0ival1と示されているを設けてもよい。組織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が、すべてのカスタムエンティティプライマリキー、たとえばa01a02a03aMNの最初の文字として選択される。図示のように、すべての組織にわたって同じ3文字プレフィックスを再使用することができる。たとえば、複数の組織のプレフィックスとしてa01が再使用されている。しかし、カスタムエンティティidの残りの部分によってグローバル一意性が確保されるかついくつかの異なる組織のデータが混じることはなくなる。一局面では、これらの3文字idはbase62で符号化され、したがって、各々の最初の文字によって、1組織当たり62623844個の異なるカスタムエンティティタイプが可能になる。これは、実質的にすべてのユーザに十分な数である。しかし、この異なる符号化ベースを使用して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つの組織内の複数の論理エンティティタイプのデータが混合されないようにする必要があることである。たとえば、プライマリキーインデックスたとえば、a01aMNの先頭の3文字部分をこの効率的なフィルタリングに使用することができる。したがって、組織idおよび3文字プレフィックスでフィルタリングすると、組織の特定のエンティティタイプを判定することができる。同様に、挿入PLSQL呼には、新しいプライマリキーおよびカスタムエンティティ行を挿入する際にどの3文字プレフィックスを使用する各を指定すべきである。図3のカスタムフィールド列213と同様に、カスタムフィールド列403は、複数のデータタイプを含んでよい。たとえば、組織1がカスタムエンティティテーブル1テーブル400内の組織100d1のa01によって識別されるを定義する際、図示のように、データタイプ1を有するカスタムフィールド列定義をval0に割り当てることができる。同様に、図示のように、データタイプ2を有する第2のカスタムエンティティテーブル組織1のa02によって識別されるのカスタムフィールド列定義を同じval0に割り当てることができる。データタイプ1および2は同じであっても異なっていてもよい。このように、様々な組織によって定義された様々なカスタムエンティティのカスタムエンティティテーブル400内の任意の所与のカスタムフィールド列403に多数のデータタイプを記憶することが可能である。したがって、組織は、任意のインデックスフィールド420を使用して、上述のように、インデックス付けすべきそのカスタムエンティティにおける1つまたは複数の列にフラグを立てることが可能である。フィルタリングも上述のフィルタリングと同様に進行する。一態様では、外部キーは、カスタムエンティティを作成する際にデータタイプとして定義することができる。このように、標準エンティティまたは他のカスタムエンティティとの関係を確立してデータの記憶および検索を容易にするたとえば、冗長なデータ記憶を低減させることができる。たとえば、カスタムエンティティを定義する際、システム管理者は、カスタムフィールドを外部キーデータタイプとして定義し、1つまたは複数の他のエンティティとの関係を確立することができる。関連するエンティティ用のプライマリキーは、そのカスタムフィールドにコピーされ記憶される。一局面では、タイプ外部キーのカスタムフィールドを記憶する複数の列が設けられる。これらの別個の列にインデックス付けすることができる。具体的な例図7は、標準列703およびカスタムフィールド列713を含む標準エンティティテーブル700の例と、複数の組織に関する実際のデータ値の例とを示している。図示のように、標準テーブル700は、標準名前フィールドおよびその他の標準フィールド703を有する得意先エンティティを表している。この例では、ABCCorp組織idフィールド701内の00d1によって識別されるは、val0列に割り当てられた得意先ウェブアドレスのカスタム列を定義している。このカスタムフィールドのデータタイプはテキストとして定義されている。さらに、ABCCorpは、val1列に割り当てられた得意先株価用の第2のカスタムフィールドおよび他の列に割り当てられた得意先ティッカー記号用の第3のカスタムフィールドを定義している。これらの列のデータタイプは、それぞれ番号およびテキストである。同様に、123Corp組織idフィールド701内の00d2によって識別されるおよびXYZCorp組織idフィールド701内の00dNによって識別されるの各々は、それぞれ得意先次回年次会議日付および得意先会計年度用のカスタムフィールドを定義している。これらのカスタムフィールドのデータタイプは、それぞれ日付およびピックリストである。これらのカスタムフィールドは、そのデータタイプが異なるにもかかわらず、どちらもval0列に割り当てられている。これらのカスタムフィールドの定義は、上述のようにメタデータ、たとえばメタデータテーブル500に記憶される。図示のように、テーブル700は、図示のようにIBM、デル、およびアップルの特定得意先データを含むABCCorpに関する得意先データを保持する。同様に、テーブル700は、123CorpおよびXYZCorpに関する得意先データも保持する。図示のように、123CorpとXYZCorpはどちらもそれぞれ、ディズニーという同じ名前を有する得意先用の特定のエントリを有している。しかし、これらのエントリは、グローバルに一意のプライマリキー702または712に基づいて区別される。たとえば、XYZCorpでは、ディズニーの得意先エントリは001932のプライマリキー値を有し、一方、123Corpのディズニー得意先エントリは00187のプライマリキー値を有している。上述のように、val0カスタム列内のデータ値は混合データタイプを有する。たとえば、ABCCorpでは、ウェブアドレスはテキストであり、一方、123Corpの次回年次会議日付は日付データタイプを有し、XYZCorpの会計年度フィールドはピックリストデータタイプを有する。図8は、ABCCorpのカスタムテーブル810を含むカスタムエントリオブジェクト800の一例を示している。図示のように、ABCCorp組織id列801内の00d1によってしきされるは、資産を表すカスタムオブジェクト810を定義している。資産オブジェクト810の定義は、たとえばテーブル600図6b内のメタデータに記憶される。資産オブジェクト810は、カスタムエンティティid用のプレフィックスa02を割り当てている。さらに、図示のように、ABCCorpは、たとえば、カスタムエンティティid列802内のプレフィックスa01によって識別される、他のカスタムオブジェクトを定義している。テーブル800に記憶される様々なオブジェクトのプレフィックスたとえば、a01を記憶する別個の列をテーブル800に設けることができる。資産オブジェクト810は、カスタム外部キー列および様々なデータ列によって定義されている。カスタム外部キーFK列はval0列に割り当てられ、一方、資産名、資産価値、資産減価償却タイプ、および資産交換日付の各データフィールドはそれぞれ、列Val1からVal4に割り当てられている。この例では、これらのフィールドのデータタイプはそれぞれ、テキスト、番号、ピックリスト、および日付である。資産オブジェクト810は、得意先オブジェクト700の子カスタムオブジェクトである。カスタム外部キー列は、オブジェクト810の各行をその親得意先に接続するこれらの例では、得意先オブジェクト700にそのテーブルidのプレフィックス001が割り当てられている。たとえば、外部キー値0019は、テーブル700内の得意先名デルの行に接続されている。同様に、外部キー値0018および00110は、それぞれ、テーブル700内の得意先名IBMおよびアップルの行に接続されている。さらに、図示のように、XYZCorp組織id列801内の00dNによって識別されるは、そのビジネスニーズに適したカスタムオブジェクトを定義しており、このカスタムオブジェクトもテーブル800に記憶されている。このため、任意の所与のデータ列803は、テーブル800に記憶されている様々なカスタムオブジェクトの定義に応じて混合データタイプを含んでよい。再使用可能なサービスカスタムエンティティの1つの目標は、データのグリッドたとえば、組織/顧客によって構成された行および列をサポートするだけでなく、標準エンティティに対して示される同じ1組のアプリケーションハイレベル意味サービスもサポートすることである。これによって、オンラインデータプロバイダを超えるだけでなく、豊富な再使用可能サービスを有するアプリケーション構築インフラストラクチャでもあるシステムが実現される。セールスフォースドットコムサービスを参考にして、このような再使用可能サービスのいくつかの例と、それがどのようにカスタムエンティティに適用されるかについて以下に説明する。履歴追跡セールスフォースドットコムにおける標準エンティティ事例エンティティや機会エンティティなどは、レコードに対するデータ変更の自動監査をサポートする。この監査は通常、すべてのデータがデータベースに書き込まれるアプリケーションサーバにおいて低レベルで行われる。この同じコードパスが好ましくはカスタムエンティティに使用される。標準エンティティに使用されるのと同じ一般化されたスキーマがカスタムエンティティにも作用する。これは好ましくは、1行当たり1つのフィールドデルタを有するピボットスキーマである。1組織id2カスタムエンティティデータid3カスタムフィールド定義id4古い値5新しい値しかし、これは非ピボットスキーマであってもよい。非ピボットスキーマは、各々の別個の情報用の列を有する。このスキーマはエクセルのスプレッドシートに似ている。ピボットスキーマは以下のような汎用列名を使用する。ピボットスキーマはより多くの行を有するが、これらの行は幅がより狭くなる50列のデータがあると仮定されたい。これは、ピボットスキーマでは50行になるが、ピボットスキーマ自体は同じ列を有する。したがって、通常のスキーマは高さが低くて幅が広く、一方、ピボットスキーマは高さが高く幅が狭い。ピボットスキーマは、たとえば事例履歴関連リストを示すことなどの監査目的に有用であり、この場合、ユーザには、あらゆるフィールド値変化がグリッド内の1つの行として示される。しかし、ピボットスキーマは通常、ある人のすべての情報を有する詳細画面と同様に通常のデータディスプレイに使用するのは困難である。管理者がカスタムエンティティおよびカスタムフィールドの定義においてこの特性をオンにした場合、この動作が自動的に行われる変更はこの1つのマルチテナント監査テーブルに記録される。この汎用履歴テーブル内のデータは、オンラインアプリケーションにおける表示またはAPI問合せを介した表示に利用可能である。一例として、事例などの標準エンティティに変更を加える場合を考える。システムは、事例の編集が保存されるときに以下の履歴行を記録することができる。上記のデータは、2つの編集動作、すなわち、2004年3月4日に行われた事例5001の編集動作と2004年3月5日に行われた事例5002の編集動作を記録したものである。いくつかのフィールドは毎回編集されている。他の例として、図8の資産カスタムオブジェクト810に変更を加える場合を考える。2004年3月4日に行われた単一の編集動作の履歴追跡行は以下のように表示される。この情報はすべてシステムによって自動的に記録される。ユーザインターフェースUIは、上記に示されたのと同様の情報、または他の任意の好都合なフォーマットの情報を示すことができる。許可ベースのセキュリティ共用モデル管理者は、編集得意先などの標準エンティティが許可を有するのと同様に特定のユーザプロファイルから特定のエンティティタイプへのアクセスを制限することを望む場合がある。管理者は、所与のエンティティタイプが明白な読取り許可または編集許可を必要とすることを定義する。汎用プロファイルカスタムエンティティメタデータモデルAPIによる編集に利用可能は、プロファイル読取りアクセスをカスタムエンティティタイプに関連付ける関係行を作成するのを可能にし、任意に、そのプロファイルのユーザがそのエンティティタイプの行を編集できるかどうかを宣言する。カスタムエンティティデータを検索し編集する共通のアプリケーションサーバPLSQLコードは、このメタデータを現在のユーザについて検査し、ユーザが適切な許可を有さない場合、動作を拒絶することができる。一態様では、共用モデルは、上記の許可検査だけでなく各行へのアクセスのずっと細かい粒度を可能にする。管理者は、カスタムエンティティタイプを定義する際、そのエンティティタイプが、すべてのユーザによって編集可能であるかパブリック読取り/書込み、すべてのユーザに対して読取り専用であるかパブリック読取り/専用、それともレコードの所有者またはレコードへの明白な共用アクセスを許可されているユーザのみが専用に利用可能であるかを選択することができるプライベート。後者の共用モデルをサポートするために、一態様では、標準所有者フィールドがカスタムエンティティデータテーブルに付加され、APIで利用可能になっている。他の標準エンティティの所有者フィールドに付加されているのと同じ意味が適用される。たとえば、役割階層における責任者は、部下によって所有されているすべてのレコードにアクセスすることができる。さらに、汎用共用エンティティ、たとえばカスタムエンティティ共用は、一態様では、得意先共用エンティティをAPIおよびUIで使用して明白な得意先アクセスを許可するのと同様に、特定のカスタムエンティティ行に対する手動の明白な共用アクセスをユーザまたはグループに入力する際に使用される。通貨タイプカスタムエンティティにおける標準フィールドには、その行内のすべての数値通貨慣習フィールドの通貨を制御する単一の通貨タイプがある。この機能は、すべての標準エンティティに整合し、アプリケーション内の他のあらゆる場所と同じ通貨換算が可能になる。エンティティタイプ当たり複数のビジネスプロセス標準エンティティは、複数のレコードタイプまたはビジネスプロセスの定義を可能にする。たとえば、機会エンティティは電話販売機会と直接販売機会の両方を有することができる。個々の機会行のレコードタイプに応じて、ピックリストフィールドに利用可能な値は、構成管理者による構成に応じて変化する。カスタムエンティティは、管理者によって同じメタデータを指定するのも可能にする。このエンティティにおけるピックリストカスタムフィールドは、好ましくは標準エンティティの場合と同様の影響を受ける。ワークフロー一態様では、本発明は、特定のエンティティタイプのトリガ条件および処置の定義を可能にする。たとえば、機会量が特定の値を超えた場合トリガ条件、eメールなどの通知が、すでに指定されている個人またはグループ、たとえば、その組織の販売のVPに送信される処置。この場合も、これらの規則を定義するために内部で使用されるメタデータは、好ましくは標準エンティティの場合と同様にカスタムエンティティにも働く。たとえばアプリケーションサーバまたはデータベースサーバで実行され、行の編集のたびにこれらの条件を評価するコードは、標準エンティティとカスタムエンティティの両方がこの機能を活用できる低レベルで出現する。本発明を一例として特定の態様に関して説明したが、本発明が開示された態様に限定されないことを理解されたい。逆に、本発明は、当業者に明らかな様々な修正態様および同様の構成を対象とするものである。したがって、添付の特許請求の範囲の範囲については、すべてのそのような修正態様および同様の構成を包含するように最も広い解釈を施すべきである。