導入

完了 100 XP

このモジュールでは、Microsoft Dynamics 365 および Microsoft Dataverse におけるデータ モデル戦略について説明し、構成開始前に完全なデータ モデルが存在することを検証する際にデータ モデルのワークショップがどのように役立つかを説明します。 次のセクションでは、データ モデリングのベスト プラクティスの基本的な概要と Dynamics 365 プロジェクトとの関連について説明します。

データ モデリングの概要

データ モデルは、システム内でデータがどのように流れるか、そして異なるエンティティがどのように関係しているかを示すビジュアル モデルです。 データ モデルでは、テーブル間のリレーションシップ タイプを定義し、データベースをわかりやすい視覚的な表現に抽象化します。

データ モデリングには、統一モデリング言語 (UML)、IDEF1X、その他を含むさまざまなタイプや標準があります。 特定のデータ モデルの標準についてはこのモジュールでは扱いませんが、Dynamics 365 データ構造のデータ モデルは、通常 2 つの一般的なカテゴリ (論理および物理) に分類されます。

論理データ モデル

論理データ モデルは、システム内でデータがどのように流れるかを示すハイレベル図です。 これらのデータ モデルは、検出時およびすべての列が定義される前のプロジェクトの開始時に一緒に配置されます。 通常、論理データ モデルの図では、スキーマまたはデータベース名ではなく、テーブルのビジネス名を使用します。

論理データ モデルの例のスクリーンショット。

物理データ モデル

物理データ モデルは、論理データ モデルよりも下位レベルです。 これには一般的に、列レベルの詳細および詳細に設計されたリレーションシップが含まれます。 物理データ モデルは、ハイレベルの論理デザインが物理テーブルに変換される際に作成されます。 物理データ モデルの一般的なタイプは、エンティティ関係図 (ERD) です。

物理データ モデルの例のスクリーンショット。

データ モデルのベスト プラクティス

データ モデルは科学であり、そこにはデータ モデルの専門家が存在し、データ モデルの標準が確立されています。 Dynamics 365 のデータ モデリングを効果的に行うために、専門的なデータ モデラーを用意したり、特別なツールを使用したりする必要はありません。 Microsoft Visio などの一般的なツールを使用して、テーブル間のデータ リレーションシップとフローをビジュアル化する基本的な ERD を簡単に作成することができます。 このトピックでは、Dynamics 365 の展開に関するデータ モデリングの一般的なベスト プラクティスについて検証します。

ベスト プラクティスは次のとおりです。

  • データ モデルは、展開中に継続的に更新する必要があります。 一般的に、データ モデルはプロジェクトの開始時にデザインしますが、その後も継続することが重要です。 展開を実行すると、新しい列とテーブルが追加されます。 そのため、これらの新しい列やテーブルをデータ モデルに取り込んで、アクティブなデータ モデルにする必要があります。 システムを強化するためにデータ モデルを継続的に更新することを顧客に勧めます。

  • XrmToolBox には、Dynamics 365 および Dataverse 構成の一般的な ERD をすぐに作成できるコミュニティ ツールが用意されています。 これらのツールには、UML ジェネレーターとエンティティ関係図 (ERD) ジェネレーターが含まれています。 構成の更新が完了したら、最新の ERD を生成します。

  • すべてのテーブルを含めるのは避けてください。 アクティビティ、メモ、ユーザー (レコード所有者) などの一部のコア テーブルは、Dynamics 365 のほぼすべてのテーブルに関連付けられています。 これらのテーブルとのすべてのリレーションシップをデータ モデルに含めると、結果を読み取ることができなくなります。 ベスト プラクティスとしては、データ モデル図の構成で活用した主要なテーブルのみを含めることをお勧めします。また、ユーザーとアクティビティ テーブルを含むユーザー定義のリレーションシップだけを含め、読みやすいものにすることをお勧めします。

  • データ モデルには、Dataverse の外部のテーブルが含まれている必要があります。 Dataverse データ コネクタまたは仮想テーブルを使用して他のシステムと統合する場合、または、統合を使用してデータが Dataverse の外に流れている場合、このデータをデータ モデル図に表示する必要があります。

  • 標準テーブルを使用して単純なものを作成してから、カスタム テーブル リレーションシップをデータ モデルに追加します。

  • ユーザー エクスペリエンスは、データ モデルに影響を与えます。 データを過剰に正規化することは簡単ですが、その過程でアプリケーションがより使いにくくなることがあります。

  • すぐに必要なものから開始しますが、将来実行予定の計画をサポートするようにデータ モデルをデザインします。 たとえば、今後、営業担当地域に関する追加の詳細を保存する必要があることが分かっている場合、担当地域のテキスト フィールドを使用すると、担当地域のエンティティ リレーションシップを使用する場合よりも、実装が困難になります。 今後の見通しについて計画を立てましょう。

データ モデルのワークショップ

データ モデルのワークショップは約 1 時間に制限し、全員がオンサイトで参加できない場合、Microsoft Teams ミーティングの一環としてしばしば実施されます。 参加者には、顧客およびパートナー チームからの主要な関係者を含める必要があります。 通常、ソリューション アーキテクト、機能リーダー、および技術リーダーの参加は必須です。 このワークショップは、後で必要に応じてコースを修正するだけの時間と機会があるときに実施してください。

次のユニットでは、データ モデルのワークショップを行う際に推奨されるトピックについて説明します。


次のユニット: エンティティ関係図

次へ