Microsoft Dataverseのテーブル定義

Microsoft Dataverseのテーブル定義では、構造化データを格納する各テーブルの構造と動作を定義します。 この記事では、テーブル名、キー、所有権、状態など、テーブル定義をプログラムで操作する方法について説明します。 開発者の場合、テーブルは、Microsoft Dataverse でデータを操作するときに使用するクラスに対応します。

SDK for .NET EntityMetadata クラスと Web API EntityMetadata エンティティ型には、テーブルを定義するプロパティが含まれています。

Note

Web API を使用してテーブル定義を取得する場合、応答内のデータは ComplexEntityMetadata 複合型を使用します。 違いは、 Attributes、 Keys、 ManyToManyRelationships、 ManyToOneRelationships、および OneToManyRelationships がコレクション値ナビゲーション プロパティではなくコレクション (配列) であるという点です。 Web API を使用してテーブルを作成または更新するときは、 EntityMetadata エンティティ型 を使用します。

テーブル名

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

Name プロパティ 説明 Example
SchemaName 通常は、論理名の Pascal ケース版です。 Account
CollectionSchemaName スキーマ名の複数形。 Accounts
LogicalName スキーマ名のすべての小文字のバージョン。 account
LogicalCollectionName コレクション スキーマ名をすべて小文字で表記したバージョン。 accounts
EntitySetName Web API でコレクションを識別するために使用されます。 既定では、論理コレクション名と同じです。
テーブル定義をプログラムで更新することで、エンティティ セット名を変更できます。 この変更は、テーブルの Web API コードを記述する前にのみ行ってください。 詳細については、「 エンティティ セット名」を参照してください。		 accounts

Note

コードを使用してカスタム テーブルを作成する場合は、ソリューション パブリッシャーのカスタマイズ プレフィックスをSchemaNameの前に追加する必要があります。 Dataverse では、それが正しいカスタマイズ プレフィックスであることを確認しません。カスタマイズ プレフィックスがあることを確認するだけです。 後で変更できないため、正しいプレフィックスを使用してください。

CollectionSchemaName、 LogicalName、 LogicalCollectionName、および EntitySetName の値は、 SchemaName 値を使用して生成されます。

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

Name 説明 Example
DisplayName 通常、スキーマ名と同じですが、スペースを含めることができます。 取引先企業
DisplayCollectionName 表示名の複数形。 アカウント
Description テーブルを説明する短い文。 顧客または潜在顧客を代表する企業。 取引で請求される会社です。

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

主キー

PrimaryIdAttributeプロパティ値は、テーブルの主キーとして機能する列の論理名です。

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

プライマリ名

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

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

Note

すべてのテーブルに PrimaryNameAttribute プロパティ値があるわけではありません。 一部のテーブルは UI に表示されることを意図していません。

表の画像

PrimaryImageAttributeプロパティ値は、エンティティ レコードを表すために選択したイメージ列の論理名です。 アプリケーションはこのイメージを表示できます。

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

Note

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

詳細については、以下を参照してください:

テーブルの種類

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

テーブル所有権

テーブル内のデータの所有方法に応じてテーブルを分類できます。 この概念は、テーブルにセキュリティを適用する方法を理解するために重要です。 OwnershipType プロパティは、この情報を保持します。 次の表では、さまざまな所有権の種類について説明します。

所有権の種類 説明
BusinessOwned データは部署に属します。 ビジネスユニット レベルでデータへのアクセスを制御できます。
None データは別のテーブルによって所有されていません。
OrganizationOwned データは組織に属します。 組織レベルでデータへのアクセスを制御できます。
UserOwned データはユーザーまたはチームに属します。 これらのレコードに対してユーザー レベルで実行できるアクションを制御できます。
Filtered (プレビュー) レコードには所有者がありません。 列の値を評価するフィルターに基づいて、セキュリティ ロールの権限を使用してアクセスを制御できます。

新しいテーブルを作成する場合の所有権オプションは、 OrganizationOwned、 UserOwned、または Filtered (プレビュー) のみです。 選択後にこのオプションを変更することはできません。

レコードにユーザーまたはチームの所有権、割り当て、共有が必要な場合は、 UserOwned を選択します。 組織レベルのアクセスで十分な場合は、 OrganizationOwned を選択します。 列の値に基づいて行レベルのアクセス権が必要な場合は、 Filtered (プレビュー) を選択し、セキュリティ ロール フィルターを使用してアクセス許可を付与します。 Filtered テーブル内のレコードには所有者がなく、割り当ても共有もできません。

また、UserOwned テーブルや OrganizationOwned テーブルの OwnershipType を変更せずに、列の値に基づいて行レベルのアクセスを制御するために、これらのテーブルにレコード フィルターを適用することもできます。 これらのテーブルは、既存の所有権モデルを保持します。

フィルター処理されたレコードの所有権の詳細

アクティビティ テーブル

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

アクティビティは、ビジネス データを格納する他の種類のテーブルとは異なる方法でモデル化されます。 アクティビティに関するデータは一覧に一緒に表示されることが多く、各種類のアクティビティには一意のプロパティが必要です。 可能なすべてのプロパティで 1 つのアクティビティ テーブルを使用する代わりに、個別の種類のアクティビティ テーブルを使用します。

これらの各テーブルは、基本 の ActivityPointer テーブル (Web API activitypointer エンティティ型) からプロパティを継承します。 これらのテーブルには、 IsActivity プロパティが true に設定されています。

Table /
エンティティタイプ		 表示名 説明
adx_inviteredemption /
adx_inviteredemption		 招待の利用 招待の受諾に関する情報を保持します。
adx_portalcomment /
adx_portalcomment		 ポータルコメント ポータル上のユーザーと顧客の間で情報を共有するために使用されるアクティビティ。
予定 /
予定		 Appointment コミットメントは、開始/終了時刻と期間を含む時間間隔を表します。
chat /
チャット		 Teams チャット 内部使用のみ。 Microsoft Teams チャットとの Dynamics 365 レコードの関連付けデータを格納するエンティティ。
電子メール /
email		 電子メール メール プロトコルを使用して提供される活動。
FAX /
fax		 ファックス FAX の通話結果やページ数を追跡する活動です。ドキュメントの電子コピーを保存することもできます。
レター /
手紙		 レター レターの配送を追跡する活動です。 この活動にはレターの電子コピーを使用できます。
PhoneCall /
電話		 電話 通話を追跡する活動です。
RecurringAppointmentMaster /
recurringappointmentmaster		 定期的な予定 定期的な予定の系列のマスター予定です。
SocialActivity /
socialactivity		 ソーシャルアクティビティ 内部使用のみ。
タスク​​ /
タスク		 タスク 処理する必要がある作業を表す全般的な活動です。

ユーザーがこれらの種類のアクティビティ テーブル レコードのいずれかを作成すると、同じActivityPointer 一意識別子列の値を持つ対応するActivityId テーブル レコードをシステムが作成します。 ActivityPointer テーブルのインスタンスを作成、更新、または削除することはできませんが、取得することはできます。 この設計により、すべての種類のアクティビティを一覧にまとめて表示できます。

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

ActivityParty テーブル

ActivityParty テーブル (Web API activityparty エンティティ型) を使用して、他のテーブルへの参照を含む列PartyListTypeアクティビティ テーブルに構造を追加します。 このテーブルは、 Email.to や PhoneCall.fromなどのアクティビティ テーブル列の値を設定する場合に使用します。 participationtypemask列を設定して、参照が果たすロールを定義します。 ロールには、 Sender、 ToRecipient、 Organizerなどが含まれます。

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

子テーブル

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

たとえば、 コメント (PostComment)、Like (PostLike) は Post テーブルの子です。

代替キー

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

詳細については、以下を参照してください:

テーブルの状態

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

どちらのプロパティにも、有効な値を表示する一連の選択肢が含まれています。 StateCodeとStatusCodeの値はリンクされているため、特定のStatusCodeの選択肢のみが特定のStateCodeに対して有効になります。

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

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

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

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

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

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

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

詳細については、以下を参照してください:

参照

Dataverse テーブル

  • 最終更新: