次の方法で共有

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という名前のGUID一意識別子列が1つ含まれます。

プライマリ名

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

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

注

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

エンティティ イメージ

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

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

注

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

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

テーブルの種類

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

テーブルの所有権

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

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

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

アクティビティ テーブル

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

アクティビティは、ビジネス データを格納する他の種類のテーブルとは異なる方法でモデル化されます。 アクティビティに関するデータは一覧に一緒に表示されることが多く、各種類のアクティビティには一意のプロパティが必要です。 可能なすべてのプロパティで 1 つのアクティビティ テーブルを使用する代わりに、個別の種類のアクティビティ テーブルを使用します。 これらの各テーブルは、基本 の 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はモデル駆動型アプリでは 状態の理由 として表示されます。

どちらのプロパティにも、有効な値を表示する一連の選択肢が含まれています。 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