Dataverse でのデータ モデリング
データをアプリで保存または表示する場合、設計で重要なのがデータ構造です。 データが特定のアプリまたは画面でどのように使用されるかに加えて、他のユーザーがどのようにデータを使用するかも考慮してください。 ペルソナ、タスク、業務プロセス、目標を参照することで、どういったデータを格納するのか、また格納したデータをどう構造化するのかを定義するのに役立ちます。
テーブルの種類
Dataverseには、次の 3 種類のテーブルがあります。
- 標準 - テーブルは、データを格納し、モデル駆動型アプリのナビゲーションに追加できます。 作成するテーブルの大半が標準になります。 いくつかの標準テーブルは、Dataverse 環境の Common Data Model のスキーマから作成されます。
- アクティビティ: これらのテーブルは、電話、タスク、予定などの対話を格納するために使用されます。 一連のアクティビティ テーブルは Dataverse データベースにあります。
- 仮想 - これらのテーブルを使用すると、Dataverse でテーブルと列を作成し、外部データ ソースを使用してデータを格納できます。 ユーザーには、データがアプリで他のデータと同様に表示されます。
カスタム標準テーブルを作成する場合は、その所有権を指定する必要があります。
- ユーザー/チーム - 既定のオプション。
- 組織 - 参照データに使用されます。
カスタム アクティビティ テーブル
アクティビティ テーブルは、対話の格納に使用されます。 アクティビティ テーブルは、テーブル メタデータでアクティビティに対して有効にするが設定されているすべてのテーブルとリレーションシップがあります。 アクティビティ テーブルには、同じセットの列と同じセキュリティ特権があります。 アクティビティ テーブルの行は、モデル駆動型アプリ フォームのタイムラインに表示されます。 この例では、"贈与" というカスタム活動テーブルが作成されています。
カスタム アクティビティ テーブルを使用する利点は次のとおりです。
- 他のアクティビティとともにリストに表示される。
- 他のアクティビティとともにロールアップできる。
- アクティビティをサポートするあらゆるテーブルに寄付を作成できる。
カスタム アクティビティ テーブルを使用する重要な欠点は次のとおりです。
- 他のアクティビティと異なるセキュリティを構成できない。
- どのテーブルが寄付に関連するかを管理できない。
列のデータ型
列のデータ型は適切に選択する必要があります。 この表記は特に、数値データ型の場合に重要です。数値列は別のデータ型と比較することができず、計算列およびロールアップ列のデータ型には制限が課されるためです。 型を選択した後は変更できません。
| データ型 | コメント |
|---|---|
| はい/いいえ | 2 つより多い選択肢が必要にならないことを確認してください。 |
| ファイルおよび画像 | ファイルと画像を Dataverse にインラインで格納できます。 |
| 顧客 | 取引先担当者または取引先企業です。 |
| 検索/選択肢 | 最適なものを選択するようにしてください。 |
| 日付/時刻 | 適切な動作を選択するようにしてください。 |
| 数値 | 選択肢が多いため、よく考えて選択します。 |
選択テーブルとルックアップ テーブルの比較
ルックアップ テーブルと選択テーブルのどちらを使用するかを決める方法は、状況に応じて異なります。
次のようなテーブルが必要な場合は、選択テーブルを使用します。
- ラベルと値をキー/値ペアとしてのみ格納する。
- ローカライズが組み込まれている。
- ソリューション コンポーネントとして扱われる。
- 値を削除する機能が組み込まれていない。
- 約 200 個の項目まで機能する UX がある。
- JavaScript を使ってフィルター処理できる。
- 行に整数として保存される。
次のようなテーブルが必要な場合は、ルックアップ テーブルを使用します。
- 行の列に他のデータを保存できる。
- 新しいプロジェクトを作成する必要がある。
- 参照データとして扱われる。
- 非アクティブ状態がサポートされる。
- 多数の項目に合わせて拡張される UX がある。
- ビューとセキュリティでフィルター処理できる。
- エンティティ参照として格納される。
ルックアップ テーブルに他のデータを格納すると、ワークフローや、データを参照するその他のカスタマイズを実行する場合にアクセスできます。 たとえば、関連するプロパティをチェック条件で使用できます。
オプションはソリューション コンポーネントである場合、差し込み解決には接頭語が付き、選択テーブルは接頭語が付く値を処理します。
選択テーブルに値を追加するには、管理者またはカスタム担当者レベルのアクセス権が必要ですが、セキュリティ ロールを通じてアクセス許可を与えられている場合は、ユーザーがルックアップ値を変更できます。
選択肢のユーザー エクスペリエンス (UX) は、選択肢が少ない場合に最適ですが、数が多い場合にはうまく機能しません。 ルックアップは、選択肢で使用できない検索タイプの機能を提供します。
互いに依存する複数の選択列がある場合、このタスクはフォーム ベースのスクリプトでのみ対処できますが、ルックアップでは、構成を使用して他のルックアップでフィルター処理できます。
ファイル データおよび画像データの格納
ファイルと画像を格納する場所については、いくつかのオプションがあります。
- Dataverse - ファイルおよび画像データ型を使用して、ファイルと画像を格納します。
- SharePoint - 共同作業に使用しますが、セキュリティに問題があります。 ファイルのセキュリティは SharePoint のアクセス許可に従い、Dataverse 行のアクセス許可と同期されません。
- Azure Storage - アーカイブと外部アクセスに使用します。 この選択にはスタンドアロンのセキュリティがありますが、使用のために生成されたリンク (バレット パターン) に基づいて短期間付与できます。 Azure Storage は、大きなファイルも処理できます。
ファイルおよび画像データ型の特性は次のとおりです。
- アップロードと参照に適している。
- セキュリティはレコードのアクセス許可に従う。
- サイズによって制限がある。
計算列
計算列を使用すると、行のデータに対して単純な計算を実行できます。さらに、次のような特性があります。
- レコード取得時に計算される。
- 読み取り専用の値がある。
- 同じ行の列および多対一のリレーションシップの列を含めることができる。
- 計算にロールアップ フィールドを含めることができる。
- ワークフロー、プラグイン、または Power Automate のイベントをトリガーできない。
ロールアップ列
ロールアップ列を使用すると、一対多のリレーションシップの関連する行を集計できます。さらに、次のような特性があります。
- スケジュールを基に計算され (最小 1 時間)、ユーザーがオンデマンドで更新できる。
- 読み取り専用の値がある。
- 計算列をロール アップできる。
- 関連レコードの階層を使用できる。
- 関連テーブル間でフィルター処理が可能。
- ワークフロー、プラグイン、または Power Automate のイベントをトリガーできない。
簡単な計算列はロールアップできる (非決定的関数を含む計算列はロールアップできない)。
リレーションシップ
リレーションシップは、Dataverse で行がどのように互いに関連付けられるかを定義するものです。 Dataverse の各テーブルには、テーブル内の行に対する一意の参照を提供する主キーがあります。 Dataverse では、主キーは行が作成されると自動的に Dataverse によって生成されるグローバル一意識別子 (GUID) です。 リレーションシップは、主キーへの参照を追加することで作成されます。これは、外部キーと呼ばれます。 Dataverse では、あるテーブルの列を使用して外部キー値を保持することでリレーションシップが作成されます。 この外部キーは、他のテーブルの主キーへのポインターです。
Dataverse では、次の 2 種類のリレーションシップがサポートされています。
- 一対多 (1:N)
- 多対多 (N:N)
一対多のリレーションシップ
次の経費精算書は、一対多 (1:N) のリレーションの例を示しています。
前のスクリーンショットでは、経費精算書のメイン部分に、従業員名と部門の詳細が表示されています。 メイン部分の下には、購入品目ごとに複数の行の説明が表示されています。 この例では、これらの説明を品目と呼びます。 品目の構造は経費精算書のメイン部分と異なります。 したがって、すべての経費精算書には複数の品目があります。
経費精算書と品目間のリレーションシップは、一対多 (1:N) のリレーションシップの例です。 経費精算書のメイン部分は、複数の品目にリンクされています。 また、品目の視点からリレーションシップを考慮した場合、各品目は 1 つの経費精算書にのみリンクできます。これは、多対一 (N:1) のリレーションシップです。
多対多のリレーションシップ
複数対複数のデータ構造は特殊な型であり、複数のレコードを他の複数のレコードに関連付けられる場合に使用します。 複数対複数のデータ構造の良い例として、ビジネス パートナーのネットワークがあります。 自分に複数の取引先 (顧客や仕入先) があり、取引先も自分の同僚 (複数) と取引しています。
以降のセクションでは、さまざまな型の複数対複数のデータ構造の例を示します。
例 1: 休暇申請
次の例は、従業員を表すデータと、休暇申請を表すデータの 2 つのデータ セットを示しています。 各従業員が複数の申請を出すため、このシナリオでのリレーションシップは一対多 (「一」が従業員、「多」が申請) です。 従業員データと休暇申請データは、従業員番号を共通の列 (キーとも呼びます) として関連付けられています。
例: 発注書の承認
この例では、データ構造は複雑に見えますが、この記事の冒頭で説明した経費精算書の例に似ています。 各仕入先または発注先が、複数の発注書に関連付けられています。 各従業員が複数の発注書を担当します。 したがって、データ セットはどちらも一対多のデータ構造を持っています。
従業員が常に同じ仕入先または発注先を使用するとは限らないため、仕入先は複数の従業員によって使用され、各従業員は複数の仕入先と取引を行います。 したがって、従業員と仕入先のリレーションシップは多対多です。
例 3: 経費精算
次の例は、経費精算書ソリューションの複数のテーブルを含むエンティティ関係図 (ERD) を示しています。
例 4: VIP がどの 2 つの特典を選択したか追跡する
この例には、John と Mary という 2 人の VIP がいます。 John は WiFi と洗濯サービスの特典を選び、Mary は WiFi とミニバーの特典を選びました。 このシナリオは、さまざまな方法でモデル化できます。 1 つ目の方法では、シナリオを 1:N のリレーションシップとしてモデル化します。
この構成には、次のような特性があります。
- 特典レコードは連絡先ごとに固有。
- 特定の特典を選んだすべての連絡先を確認することはできない。
- 連絡先の所有者に基づいて特典レコードのセキュリティを実行できる。
- 連絡先固有の追加データを特典レコードに保存できる。
- リレーションシップは特典の親であり、そうでない場合は特典レコードが孤立する。
2 つ目の方法では、シナリオを N:N のリレーションシップとしてモデル化します。
この構成には、次のような特性があります。
- 特典から関連付けられたレコードを確認すると、その特典を選んだすべての連絡先が表示される。
- 特典のセキュリティはすべての連絡先で共有されるため、連絡先ごとにカスタマイズはできない。
- 特典の属性はすべての連絡先で共有されるため、連絡先固有のデータは保存できない。
- 参照リレーションシップを使用する必要がある (使用しない場合は他の連絡先から特典を削除することになる)。
どちらの構成も理想的ではありません。
次の例では、VIP の特定を保持するカスタム (インターセット) テーブルの作成を示します。
この構成には、次の特性があります。
- 連絡先に固有の特典テーブルにさらにデータを格納する機能が追加される。
- レコードの接続に追加の作業が必要となる (交差行を手動で作成しなければならなくなる)。
- 特典は個別にセキュリティ保護される。
- 特典テーブルの属性に直接アクセスできないため、クエリの実行がより困難になる。
次の例は、連絡先テーブルの列の使用を示しています。
この構成には、次の特性があります。
- 第 1 特典と第 2 特典ではうまく機能しますが、多数の特典を追跡するために拡張することはできない。
- クエリ実行、セルフサービス Power BI などの使用がユーザーにとって簡単になる。
- 連絡先レコードと同じセキュリティに従う。
- 第 1 特典を選んだすべてのユーザーをクエリする場合、第 1 特典と第 2 特典をクエリ スキャンするクエリを作成する必要がある。
この構成は、コンプライアンスや統計の目的で特典を記録する必要があるが、業務や処理に影響がない場合に適した例です。
リレーションシップ動作
リレーションシップ動作は、一対多のリレーションシップを利用して、特定のアクションが主エンティティのテーブル行に関連する行にどのように伝播するかを制御します。 動作は参照整合性を維持し、孤立したレコードが取り残されるのを防ぐことができます。
重要
リレーションシップ動作の定義が重要なのは、割り当てレコードの伝播によって関連レコードが割り当てられることがあるためです。 判断に迷う場合は、動作を参照および制限に設定します。
代替キー
代替キーは、統合において、レコードを検索するためのクエリ実行の必要性を減らすために使用されます。 代替キーを使用することで、GUID が不明でも行を更新できます。
代替キー:
- 取得、更新での使用に適している。
- 小数、整数、テキスト フィールド、日付、ルックアップ フィールドを含めることができる。
- 各テーブルの代替キーは 5 つまでである。
- キーの一意性を適用するために、null 値を許可する一意のインデックスをバックグラウンドで作成する。
キーが作成されると、そのキーがプラットフォームでサポートできることが検証されます。
図の作成に関するベスト プラクティス
Dataverse の ER 図を作成する場合、次の点に注意してください。
- データの重複を回避します。 すべてのデータのホームは 1 つのみにする必要があります。 複数のテーブル間で同じデータを複製するのではなく、簡易表示フォームのような機能を使用し、ビューの関連するテーブル データを表示する必要があります。
- 実体関連図のリレーションシップを使用して、ビジネス ロジックに影響を与える可能性のあるカスケード動作を確認し、特定します。 たとえば、上位関係を使用すると、割り当て、共有、共有の解除、リペアレント、削除、およびマージなどのアクセス許可は、親レコードの更新時に関連レコードに対して自動的に発生します。