フィードバック

Microsoft Dataverse のテーブル定義

  • [アーティクル]

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

注意

エンティティとテーブルの違いがわかりませんか？ Microsoft Dataverse で「開発者: 用語を理解する」を参照してください。

テーブル名

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

名前プロパティ 説明
SchemaName 通常は、論理名の Pascal 形式バージョンです 例 Account
CollectionSchemaName スキーマ名の複数形。 例 Accounts
LogicalName 小文字のスキーマ名のすべてのバージョン。 例 account
LogicalCollectionName 小文字のコレクション スキーマ名のすべてのバージョン。 例 accounts
EntitySetName Web API を使用してコレクションを識別するために使用されます。 既定では、論理コレクション名と同じです。
プログラムによって定義を更新することにより、エンティティ設定名を変更することができます。 ただし、この変更は、テーブルの Web API コードを記述する前に完了しておく必要があります。 詳細: Web API のタイプおよび操作 > エンティティ セットの名前の変更。

注意

EntitySetName は、EntityName を変更すると自動的にその名前の複数形に生成されます。 例: EntityName: Car EntitySetName: Cars. 新しいテーブルを手動で作成する場合、EntitySetName は変更可能です。 EntitySetName を作成したシステムは、常に EntityName の複数形になり、これらはクライアント インターフェイスか API を介して変更することはできません。 これには、システム テーブルと、多対多の関連付けの交差に対して作成されたテーブルが含まれます。

カスタム テーブルを作成すると、選択した名前の前に、テーブルが作成されたソリューションに関連付けられているソリューション発行者のカスタマイズの接頭辞値が付加されます。 エンティティ設定名以外に、テーブルの名前は、作成後に変更できません。 ソリューション内の定義アイテムの名前に一貫性を持たせたい場合は、目的のカスタマイズ接頭辞を含むソリューション発行者に関連付けて作成したソリューションのコンテキストでそれらを作成する必要があります。 詳細 : ソリューション発行者

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

Name 説明
DisplayName 通常、スキーマ名と同じですが、スペースを含めることができます。 例 Account
DisplayCollectionName 表示名の複数形。 例 Accounts
Description テーブルを説明する短い短い文章 (顧客または潜在顧客を表す会社です。この会社には、業務取引で請求が行われます。)

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

主キー

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

既定では、すべてのテーブルに 1 つの GUID 一意識別子列があります。 これは、通常、< テーブルの論理名 >+ Id と呼ばれます。

プライマリ名

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

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

注意

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

エンティティ イメージ

PrimaryImageAttribute プロパティの値は、テーブル レコードの画像データが格納される列の論理名となります。 各テーブルは画像列を 1 つだけ持つことができ、その列の論理名は常に entityimage となります。

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

パフォーマンス上の理由から、明示的に要求されない限り、エンティティ イメージは検索操作に含まれません。

エンティティ画像をサポートする各テーブルには、3 つのサポート列があります。

スキーマ名 型 内容
EntityImage_Timestamp BigIntType 値は、イメージが最後に更新されときに表され、イメージの最新版がクライアントでダウンロードされ、キャッシュされることが確実にできるように使用されます。
EntityImage_URL StringType クライアントでエンティティ イメージを表示する絶対 URL。
EntityImageId UniqueIdentifierType 画像の一意識別子。

詳細情報: 画像列、サンプル: エンティティ イメージを設定および取得する

注意

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

テーブルの種類

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

テーブルの所有権

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

所有権の種類 説明
業務 データは部署に属します。 データへのアクセスは、部署レベルで管理できます。
いいえ​​ データは別のテーブルによって所有されません。
組織全体 データは、組織に属します。 データへのアクセスは組織レベルで管理されます。
[ユーザーまたはチーム] データは、ユーザーまたはチームに属します。 これらのレコードで実行できる操作は、ユーザー レベルで管理できます。

新しいテーブルを作成する場合、所有権オプションは、組織、または ユーザーまたはチーム に限られます。 このオプションを選択すると、そのオプションを変更することはできません。 レコードの操作を表示または実行できるユーザーを最も詳細に制御するには、ユーザーまたはチーム を選択します 。 このレベルの制御が不要な場合は、組織 を選択します。

アクティビティ テーブル

活動は、ユーザによって実行される、または実行されるタスクです。 活動は、カレンダーにエントリを作成できる任意のアクションです。

活動は、ビジネス データを格納する他の種類のテーブルとは異なる方法でモデル化されます。 活動に関するデータは頻繁に一覧にまとめて表示されますが、活動の種類ごとに固有のプロパティが必要です。 可能なプロパティをすべて持つ単一の活動テーブルではなく、異なる種類の活動テーブルがあり、それぞれ、基本となる ActivityPointer テーブル からプロパティを継承します。 これらのテーブルでは、IsActivity プロパティが true に設定されます。

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

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

同様に動作するカスタム活動テーブルを作成することができます。

ActivityParty テーブル

このテーブルは、他のテーブルへの参照が含まれている活動テーブル PartyListType の列に構造体を追加するために使用されます。 このテーブルは、Email.to や PhoneCall.from などの活動テーブルの列の値を設定する場合に使用します。 ActivityParty テーブル 内では、ParticipationTypeMask 列を設定することで、参照によって実行されるロールを定義します。 ロールには、Sender、ToRecipient、Organizer などがあります。

ActivityParty テーブルをクエリすることはできますが、それが関連付けられた活動以外で活動関係者を作成、取得、更新、または削除することはできません。 詳細:

Child テーブル

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

たとえば、PostComment、PostLike、PostRole はそれぞれ Post テーブルの子となります。

キー

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

詳細:

テーブルの状態

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

両方の列には、有効な値を表示する選択肢のセットが含まれます。 StateCode 列値と StatusCode 列値は、指定された StateCode に対して特定の StatusCode 選択肢のみが有効になるようにリンクされます。

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

StateCode 選択肢 StatusCode 選択肢
0 : アクティブ 1 : アクティブ
1 : 非アクティブ 2 : 非アクティブ

一部のテーブルには、異なる選択肢のセットがあります。

例: PhoneCall テーブル StateCode および StatusCode 選択肢

StateCode StatusCode
0 : 開く 1 : 開く
1 : 完了 2 : 実行
4 : 受信
2 : 取り消し済み 3 : 取り消し済み

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

カスタム テーブルの場合、状態間の遷移を有効にするために追加の条件を定義できます。 詳細:

関連項目

Dataverse テーブル

注意

ドキュメントの言語設定についてお聞かせください。 簡単な調査を行います。 (この調査は英語です)

この調査には約 7 分かかります。 個人データは収集されません (プライバシー ステートメント)。