次の方法で共有

Microsoft Dataverse のテーブル定義

各テーブルには、構造化データを格納する機能が用意されています。 開発者向けのテーブルは、Microsoft Dataverse でデータを操作するときに使用するクラスに対応しています。

テーブル名

各テーブルには、作成時に一意の名前が定義されています。 この名前は、いくつかの方法で表示されます。

名前プロパティ Description
SchemaName 通常、PascalCaseで表記された論理名のバージョンです。 たとえば、アカウント
CollectionSchemaName スキーマ名の複数形。 たとえば、アカウント
LogicalName スキーマ名のすべての小文字のバージョン。 たとえば、アカウント
LogicalCollectionName コレクション スキーマ名をすべて小文字で表記したバージョン。 たとえば、アカウント
EntitySetName Web API でコレクションを識別するために使用されます。 既定では、論理コレクション名と同じです。
定義をプログラムで更新することで、エンティティ セット名を変更できます。 ただし、これを行う必要があるのは、テーブルに対して Web API コードが記述される前だけです。 詳細情報: エンティティ セット名

注

EntitySetName は、 EntityName をその名前の複数形に変更することで自動的に生成されます。 例: EntityName (エンティティ名): Car EntitySetName (エンティティセット名): Cars。 新しいテーブルを手動で作成すると、 EntitySetName を変更できます。 EntitySetName作成されるシステムは常にEntityNameの複数形であり、クライアント インターフェイスを介して変更することはできません。 これには、システム テーブルと、多対多リレーションシップが交差するために作成されたテーブルが含まれます。

カスタム テーブルを作成すると、選択した名前の前に、テーブルが作成されたソリューションに関連付けられているソリューション発行元のカスタマイズ プレフィックス値が付加されます。 エンティティ セット名以外は、作成後にテーブルの名前を変更することはできません。 ソリューション内の定義項目の一貫性のある名前が必要な場合は、使用するカスタマイズ プレフィックスを含むソリューション発行元に関連付けられているソリューションのコンテキストで作成する必要があります。 詳細情報: ソリューションの発行元

各テーブルには、ローカライズされた値を表示できる 3 つのプロパティもあります。

名前 Description
DisplayName 通常、スキーマ名と同じですが、スペースを含めることができます。 たとえば、アカウント
DisplayCollectionName 表示名の複数形。 たとえば、アカウント
Description テーブルを説明する短い説明は次の通りです。顧客または潜在顧客を表す会社です。この会社には、業務取引で請求が行われます。

これらは、アプリ内のテーブルを参照するために使用されるローカライズ可能な値です。 これらの値はいつでも変更できます。 ローカライズされた値を追加または編集するには、「 カスタマイズされたテーブル、フォーム、列のテキストを他の言語に翻訳する」を参照してください。

プライマリキー

PrimaryIdAttribute プロパティの値は、テーブルの主キーである列の論理名です。

既定では、すべてのテーブルには、 <table logical name>Idという名前の 1 つの GUID 一意識別子列があります。

プライマリ名

PrimaryNameAttribute プロパティ値は、テーブル レコードを識別する文字列値を格納する列の論理名です。 これは、UI でレコードを開くためにリンクに表示される値です。

例: Contact テーブルでは、プライマリ名列として fullname 列が使用されます。

注

すべてのテーブルにプライマリ名があるわけではありません。 一部のテーブルは UI に表示されることを意図していません。

エンティティ イメージ

PrimaryImageAttribute プロパティの値は、エンティティ レコードを表すために選択されたイメージ列の論理名です。 この画像は、アプリケーションに表示される場合があります。

例: 連絡先テーブルEntityImage 列には、連絡先の画像を格納できます。

注

これは、モデル駆動型アプリのテーブルに表示されるアイコンとは異なります。 IconVectorName プロパティには、これを設定する SVG Web リソースの名前が含まれています。

詳細情報:

テーブルの種類

テーブルの機能と動作は、複数のテーブル プロパティによって異なります。 これらのプロパティのほとんどは比較的単純で、わかりやすい名前が付けられます。 さらに説明が必要な 4 つのプロパティの中には、所有権、アクティビティ テーブル、Activityparty テーブル、および子テーブルがあります。

テーブルの所有権

テーブルは、テーブル内のデータの所有方法によって分類できます。 これは、テーブルにセキュリティを適用する方法に関連する重要な概念です。 この情報は、 OwnershipType プロパティにあります。 次の表では、さまざまな所有権の種類について説明します。

所有権の種類 Description
ビジネス データは部署に属します。 データへのアクセスは、部署レベルで制御できます。
None 別のテーブルが所有していないデータ。
組織 データは組織に属します。 データへのアクセスは、組織レベルで制御されます。
[ユーザーまたはチーム] データはユーザーまたはチームに属します。 これらのレコードに対して実行できるアクションは、ユーザー レベルで制御できます。

新しいテーブルを作成する場合、所有権オプションは組織またはユーザーまたはチームだけです。 このオプションを選択した後は、変更できません。 レコードに対してアクションを表示または実行できるユーザーを最も細かく制御するには、[ ユーザー] または [チーム ] を選択します。 このレベルの制御が必要ない場合は、[ 組織 ] を選択します。

アクティビティ テーブル

アクティビティとは、ユーザーが実行するタスクまたは実行されるタスクです。 アクティビティとは、予定表でエントリを作成できる任意のアクションです。

アクティビティは、ビジネス データを格納する他の種類のテーブルとは異なる方法でモデル化されます。 アクティビティに関するデータは一覧に一緒に表示されることが多く、各種類のアクティビティには一意のプロパティが必要です。 可能なすべてのプロパティを持つ 1 つの Activity テーブルではなく、アクティビティ テーブルの種類が異なり、それぞれのアクティビティ テーブルは基本 の ActivityPointer テーブルからプロパティを継承します。 これらのテーブルでは、 IsActivity プロパティが true に設定されます。

表 Description
予定 開始時刻、終了時刻および期間により時間間隔を定めた約束です。
電子メール メール プロトコルを使用して提供される活動。
FAX FAX の通話結果やページ数を追跡する活動です。ドキュメントの電子コピーを保存することもできます。
レター レターの配送を追跡する活動です。 この活動にはレターの電子コピーを使用できます。
電話通話 通話を追跡する活動です。
RecurringAppointmentMaster 定期的な予定の系列のマスター予定です。
SocialActivity 内部でのみ使用します。
タスク 処理する必要がある作業を表す全般的な活動です。

だれかがこのようなアクティビティ テーブル レコードのいずれかを作成するたびに、対応する ActivityPointer テーブル レコードが同じ ActivityId の識別子列の値を用いて作成されます。 ActivityPointer テーブルのインスタンスを作成、更新、または削除することはできませんが、取得することはできます。 これにより、すべての種類のアクティビティを一覧にまとめて表示できます。

同じように動作するカスタム アクティビティ テーブルを作成できます。

ActivityParty テーブル

このテーブルは、他のテーブルへの参照を含む列 PartyListType アクティビティ テーブルに構造を追加するために使用されます。 このテーブルは、 Email.to や PhoneCall.fromなどのアクティビティ テーブル列の値を設定するときに使用します。 ActivityParty テーブル内の ParticipationTypeMask 列を設定して、参照が果たす役割を定義します。 ロールには、 Sender、 ToRecipient、 Organizer などが含まれます。

ActivityParty テーブルに対してクエリを実行することはできますが、関連するアクティビティの外部でアクティビティ パーティを作成、取得、更新、または削除することはできません。 詳細情報:

子テーブル

IsChildEntity プロパティが true のテーブルには、権限が定義されておらず、ユーザーまたはチームが所有することはありません。 子テーブルに対して実行できる操作は、多対一リレーションシップを介して関連付けられているテーブルにバインドされます。 ユーザーは、関連するテーブルに対して同じ操作を実行できる場合にのみ、子テーブルに対して操作を実行できます。 子テーブルは、依存しているテーブル レコードが削除されると自動的に削除されます。

たとえば、 PostComment、 PostLike、 PostRole は、 Post テーブルの各子です。

Keys

各代替キー定義は、テーブルを一意に識別する 1 つ以上の列を組み合わせて記述します。 代替キーは通常、外部システムとの統合にのみ適用されます。 レコードを一意に識別するための代替キーを定義できます。 これは、GUID 一意識別子キーをサポートしていないシステムとデータを統合する場合に重要です。 1 つの列値または列値の組み合わせを定義して、テーブルを一意に識別できます。 代替キーを追加すると、これらの列に一意性制約が適用されます。 同じ値を持つ別のテーブル レコードを作成または更新することはできません。

詳細情報:

テーブルの状態

ほとんどのテーブルには、レコードの状態を追跡するための 2 つのプロパティがあります。 これらは StateCodeであり、モデル駆動型アプリの 状態 と StatusCodeと呼ばれ、モデル駆動型アプリでは Status Reason と呼ばれます。

両方の列には、有効な値を表示する一連の選択肢が含まれています。 StateCode列とStatusCode列の値はリンクされるため、特定のStatusCodeの選択肢のみが特定のStateCodeに対して有効になります。

これはテーブルによって異なる場合がありますが、多くのテーブルの共通パターンであり、カスタム テーブルの既定値は次のとおりです。

StateCode の選択肢 StatusCode のオプション
0: アクティブ 1: アクティブ
1: 非アクティブ 2: 非アクティブ

一部のテーブルには、さまざまな選択肢があります。

例: PhoneCall テーブル StateCode と選択肢StatusCode

StateCode ステータスコード
0: 開く 1: 開く
1: 完了 2 : 実行
4: 受信済み
2: キャンセル済み 3: キャンセル済み

テーブルの有効な状態コードのセットはカスタマイズできませんが、状態コードはカスタマイズ可能です。 対応するStatusCodeに対して、さらにStateCodeの選択肢を追加できます。

カスタム テーブルの場合は、状態間の有効な遷移に関するより多くの条件を定義できます。

詳細情報:

こちらも参照ください

Dataverse テーブル

  • Last updated on