Dataverse のベスト プラクティス
データ モデルは科学であり、データ モデルの専門家が存在し、データ モデルの標準が確立されています。 Dataverse データ モデルを効果的に行うために、専門的なデータ モデルを用意したり、特別なツールを使用したりする必要はありません。 Microsoft Visio などの一般的なツールを使用すると、テーブル間のデータのリレーションシップとフローを視覚化する基本的なエンティティ関係図 (ERD) を簡単に作成できます。
このユニットでは、次のように、Dataverse の展開に関するデータ モデルの一般的なベスト プラクティスに焦点を当てます。
データ モデルは、展開中に継続的に更新する必要があります。 プロジェクトの開始時にデータ モデルをデザインすることがよくありますが、デザイン プロセスがその時点で終わらないようにすることが重要です。 展開を実行すると、新しい列とテーブルが追加されます。 これらの新しい列やテーブルをデータ モデルに取り込んで、アクティブなデータ モデルにする必要があります。 さらに、顧客には、システムを強化するために引き続きデータ モデルの更新を行うことを推奨してください。
最初は確立されたツールを使用すると役立ちます。 XrmToolBox には、Dataverse 構成の一般的な ERD 図をすぐに作成できるコミュニティ ツールが用意されています。 これらのツールには、UML 図生成ツールとエンティティ関係図 (ERD) 作成ツールが含まれています。 構成の更新が完了したら、最新の ERD 図を生成できます。
すべてのテーブルを含めるのは避けてください。 一部のコア テーブル (活動、メモ、ユーザー (レコード所有者) など) は、Dataverse のほぼすべてのテーブルに関連付けられています。 これらのテーブルとのすべてのリレーションシップをデータ モデルに含めると、結果を読み取ることができなくなります。 ベスト プラクティスとしては、データ モデル図の構成で活用した主要なテーブルのみを含めることをお勧めします。また、ユーザーおよび活動テーブルとのカスタム リレーションシップだけを含めて、読みやすさを最大限に高めることをお勧めします。
データ モデルには、Dataverse の外部のテーブルが含まれている必要があります。 Dataverse データ コネクタまたは仮想テーブルを使用して他のシステムと統合する場合、または、統合を使用することで Dataverse 外のデータ フローと統合する場合、このデータは、データ モデル図に表示する必要があります。
標準テーブルを使用して単純なものを作成してから、ユーザー定義のテーブル リレーションシップをデータユーザー定義モデルに追加します。
エクスペリエンスは、データ モデルに影響を与えるはずです。 場合によっては、データを過剰に正規化することは簡単ですが、その過程で、アプリケーションがより使いにくくなることがあります。
すぐに必要なものから開始しますが、今後行うことをサポートするようにデータ モデルをデザインします。 たとえば、最終的に営業担当地域に関するより詳しい情報を保存する必要があることがわかっている場合は、担当地域のテキスト列を使用すると、担当地域テーブルのリレーションシップを使用する場合よりも、実装が困難になります。 今後の見通しについて計画を立てます。
組み込みのテーブルとカスタム テーブル
このトピックでは、構成で使用される標準の標準のテーブルと、それを使用するカスタム テーブルおよびその目的について説明します。 Microsoft Dataverse には多くの一般的なテーブルがあり、目的に対応する標準テーブルが既に存在する場合はカスタム テーブルを作成しないという原則を遵守するために、この情報が必要になります。 これは、多数の冗長テーブルを使用して構成をオーバーロードすると、システムのパフォーマンスに悪影響を与える可能性があるため、システムを使用するのが困難になります (高度な検索に類似する名前のテーブルが多い場合、ユーザーの混乱を招きます)。 各カスタム テーブルは、特定の目的に使用できます。
さらに、このトピックでは、最も使用されているテーブルを識別し、テーブルをオーバーロードするリスクがあるかどうかを確認するのにも役立ちます。
標準テーブルのカスタム テーブルへの置き換えの検討
作成者が標準機能をカスタム テーブルに置き換えることを検討することがあります。 この検討の背後には、作成者が営業案件を必要とするが、通常の営業案件フォームよりも簡単なフォームが必要な場合は、カスタム テーブルを作成した方が簡単であるという理由があります。 ただし、標準テーブルの代わりにカスタム テーブルを使用すると、何を使用できなくなるかを考慮する必要があります。 標準のテーブルを使用すると、コア プラットフォームの機能とのより優れた動作が保証されます。 標準テーブルには機能が定期的に追加されるため、新しい機能がリリースされたときに、その機能を簡単に利用できます。 たとえば、標準の営業案件テーブルをカスタム営業案件テーブルに置き換えることにした場合、Microsoft Dynamics 365 Sales の Sales Insights やその他の AI 機能を利用することはできません。
取引先企業と取引先担当者を再作成しない
Microsoft Power Platform ソリューションを配置する場合、システム内で会社、組織、および取引先担当者の複数のタイプを追跡することがよくあります。 それらのエンティティは、顧客/クライアント組織であったり、経理や法律関連会社などのサポートおよびアドバイス組織であったりします。 また、貿易関係など、さまざまなタイプの組織である場合もあります。
会社のリレーションシップの複数のカテゴリを管理する最も一般的な方法は、すべての組織タイプに対して "取引先企業" テーブルを使用し、列 (リレーションシップ タイプなど) やカスタム オプション セットを使用して、タイプまたはカテゴリ別に会社をフラグ設定することです。 ビューは会社のタイプに基づいてフィルター処理でき、ビジネス ルールでは、条件に応じて、列やフォームのコンポーネントをタイプに基づいて表示または非表示にすることができます。
二重書き込みインフラストラクチャを使用した Dynamics 365 財務と運用アプリとの標準統合からメリットを享受するには、Dataverse 環境に対する二重書き込みコア ソリューションによって追加された既定のテーブルと列を使用することをお勧めします。
もう 1 つの方法は、会社のタイプごとにカスタム テーブルを作成することです。 一般的な理由の 1 つとして挙げられるのは、「将来、別の理由で取引先企業を使用することが考えるため、取引先企業テーブルをカスタマイズする必要はない」ということです。
取引先企業テーブルをカスタム会社テーブルとして再作成する前に、カスタム テーブルを作成することによって失われる機能について、十分に検討してください。 次のような要素が考えられます。
- 複数の住所 - "取引先企業" テーブルには、複数の住所をサポートする固有の住所機能があります。 最初の 2 つの住所は、会社フォームに表示されますが、これらの住所レコードは関連する "顧客住所" テーブルに存在します。 カスタム会社テーブルに関連付けられたカスタム住所テーブルを作成することもできますが、関連するテーブルにアドレスが保存され、フォームおよびテーブルのビューに表示される一意のロジックを作り直すには、開発が必要になります。 複数の住所が必要な場合は、"取引先企業" テーブルを使用します。
- 取引先担当者の階層 - 取引先企業は取引先担当者の親です。 取引先担当者に関連する活動は、取引先企業の親会社のレコードにロールアップされます。 この階層は、カスタム会社レコードによって置き換えることはできません。 カスタム会社テーブル間で追加のリレーションシップを作成できますが、標準の取引先企業/取引先担当者のリレーションシップを置き換えることはできません。 会社にこのタイプの会社との主要な会社リレーションシップを持つ取引先担当者が存在する場合、または取引先担当者から会社に活動をロールアップする場合は、"取引先企業" テーブルを使用します。
- 標準マップ コントロール - モデル駆動型アプリでは、標準マップ コントロールによりカスタム会社テーブルはサポートされません。
- 階層リレーションシップ - 親/子取引先企業間の階層リレーションシップと、取引先企業の親会社に対する子取引先企業活動の標準階層のビジュアル化とロールアップは、標準の取引先企業テーブルに対してのみ使用できます。
- ポリモーフィックなルックアップ列 - Dataverse には、顧客列と呼ばれる特別なタイプのポリモーフィックなルックアップ列が含まれています。 この列を使用すると、行を会社/取引先企業または取引先担当者にリンクすることができます。
- Marketing は機能しません - マーケティング リストを使用できるのは、取引先担当者、取引先企業、およびリードのみです。カスタム テーブルは使用できません。 Microsoft Dynamics 365 Customer Insights - Journeys は、取引先企業および取引先担当者に送信できますが、カスタム会社テーブルには送信できません。
したがって、ほとんどすべての状況で、"取引先企業" テーブルは、すべてのタイプの会社レコードに使用する必要があります。ただし、次の例外があります。
- リレーショナルではなく、最小限の属性を持つ小規模な会社。 取引先担当者や住所がなく、ルックアップの目的でのみ存在する組織のタイプを考えてみてください。
- "取引先企業" テーブルを損なうべきでない、名刺や Web フォームからインポートされた未確定の会社または未検証の会社。 このような場合は、"リード" テーブルを使用できます。
システム テーブルの転用
営業案件と似ているが、実際には販売機会ではないビジネス要件があるシナリオを考えてみます。 この場合、システム テーブルの転送または新しいテーブルの作成を検討できます。
次のセクションでは、システム テーブルを転送する前に考慮する必要がある要素について説明します。
未来について検討する
Microsoft Power Platform の未来はこれまでよりも速く進行しているため、標準以外の方法でテーブルを使用すると、使用しているテーブルに Microsoft が変更を行った場合に問題が発生する可能性があります。 また、"契約" のようなめったに使用されないシステム テーブルを転用することにした場合、Microsoft はそのテーブルを将来廃止することを選択する可能性があります。 カスタム テーブルは廃止されません。 さらに、システム テーブルを転用する場合、後でそのエンティティを本来の目的に使用する必要が生じた場合はどうすればよいかを考慮してください。 顧客によっては、ケースを転用した後、最終的にケース マネジメントが必要となり、標準のケース テーブルは異なる目的で既に使用されていたために、カスタム テーブルを使用して対処する必要がありました。
オーバーヘッドについて検討する
多くのシステム テーブルには、フォームから削除できない特定の列が含まれています。 たとえば、営業案件ケースやキャンペーンなど、テーブルの一部の列は、フォームから削除することはできません。 これらの列を非表示にすることもできますが、フォーム上にロックされた列が複数存在すると、環境構成のオーバーヘッドが増える可能性があります。
ユーザー エクスペリエンスについて検討する
標準テーブル機能に沿ったユース ケースが 50% 未満の場合、カスタム テーブルを使用すると、通常、より複雑なシステム テーブルをスケーリング ダウンするよりもユーザー エクスペリエンスを簡素化できます。 また、カスタム テーブルを含む任意のテーブルにビジネス プロセス フローを追加することもできます。これにより、カスタム テーブルのユーザー エクスペリエンスを少なくとも同じくらいのものにするか、システム テーブルを転用するよりも優れたカスタム テーブルを作成できます。
よくある落とし穴の回避
データ モデリングの一般的な問題は次のとおりです。
- テーブルが多すぎる - テーブルを正規化しすぎであると思われます。
- テーブルの列が多すぎる - 同様に、別個のテーブルを作成する必要があります。
- ツールの使用 - 列を繰り返すのではなく簡易表示フォームを使用してください。
- はい/いいえのデータ型を避ける - 3 つ以上の値を追加する場合、値を「不明」として保存する必要があります。
- 形式の落とし穴 - データ型の形式を後で変えることはできません。
- 使用しないパーツ - 使用する予定がないデータ モデルのパーツは構築しないてください。
概念実証
Dataverse を使用すると、試用版の環境を簡単に作成し、テーブルとリレーションシップを簡単に作成できます。 概念実証を作成してデータ モデルを試行し、ユーザー エクスペリエンスがどのようなものになるかを確認することができます。