テーブル構成

完了

テンプレートのテーブル構成セクションでは、データ モデルの全体的な品質に影響するデザイン上の決定に関する詳細を特定し、一般的なデータ モデル テーブルの構成の誤りを回避することができます。 テンプレート テーブルの構成のスライドで、次の質問に対して回答する必要があります。

質問	重要な理由
新しいテーブルを作成したときに、不要なオプションをすべて削除しましたか。	新しいテーブルを作成する場合は、不要なオプション (メモや接続など) をすべてクリアする必要があります。そうしないと、ユーザー エクスペリエンスに影響を与える可能性のある不要な属性やリレーションシップがこれらのオプションによって作成される場合があります。 これらのオプションは、後で追加できます。
新しい列 (たとえば、関係者一覧をサポートするための「メールの送信」や「活動テーブル」など) を作成する代わりに、すぐに利用できる機能を使用していますか。	出席者、宛先、差出人、およびスケジュールされた開始日などの列が必要な場合は、カスタム活動テーブルを使用する必要があります。 カスタム活動テーブルには、特定のシナリオで役に立つ既定の活動の列 (たとえば、宛先、差出人など) が多数含まれています。 カスタム テーブル レコードにメールを送信する必要がある場合は、列に [メールアドレス] 列が自動的に追加されるように、メールに対して有効にします。
N:N のリレーションシップを使用していますか。	多対多 (N:N) のリレーションシップは軽量ですが、拡張性が制限されており、2 つのレコード間のデータのアソシエーションをインポートすることは困難です。
N:N のリレーションシップの代わりに、ブリッジ カスタム テーブルを検討しましたか。	標準の N:N リレーションシップの代わりに、交差テープまたは手動の多対多のリレーションシップとも呼ばれるブリッジ テーブルを使用することができます。 標準の N:N のリレーションシップを使用する代わりに、リレーションシップの各辺を参照するルックアップ列を持つブリッジ テーブルを、2 つの関連するテーブル間に作成できます。 この方法により、リレーションシップについて記述した列をリレーションシップにさらに作成できます。 ユーザー エクスペリエンスは、通常の N:N リレーションシップより複雑であることを念頭に置いてください。
テーブル リレーションシップで列マッピングを活用していますか。	リレーションシップを作成する場合は、列マッピングを指定して、関連するテーブルの列に自動的にデータを入力することができます。 この方法は、親レコードと子レコードの共通の値を設定する必要がある場合 (親取引先企業から作成したときに取引先担当者の住所を自動的に入力する場合など) に便利です。 ただし、この方法を使用してクリティカルな列の重複データを作成しないでください。また、簡易表示フォームのような代替手段を使用して、子レコードのレコード フォームに親からの読み取り専用属性を表示することを検討してください。
カスタマイズとカスタム接頭辞に対して単一の発行元を使用していますか。	同じ技術名で GUID が異なる複数の発行元を使用しないでください。 プロジェクトの発行元を単一の環境で作成してから、アンマネージド ソリューションを使用して他の開発環境に配置します。 同じソリューション発行者 (名前とシステム名) を持つさまざまな環境でカスタマイズが行われた場合、展開に問題が生じないように、テーブルや列のようなコンポーネントも、完全に一意 (同じ GUID) にする必要があります。 2 つの環境で別々に作成された同じ列で同じスキーマ名が使用されている場合、その列を環境にインポートするときにソリューションのインポートが失敗します。

選択列、カスタム テーブル、およびローカライズ

選択列は、Dynamics 365 のデータ キャプチャを標準化し、レコードの検索をより便利にするためのドロップダウン リスト列です。 すべてがテキスト列で使用された場合、その後複数のレコード内の同じ値の綴りや略語に相違が生じ、レポートやユーザビリティが困難になります。 しかし、選択列を最適な方法で使用するには、事前に適切な計画を検討する必要があります。 テンプレート ドキュメントの選択列、カスタム テーブル、およびローカライズ セクションでは、次の質問に回答する必要があります。

質問	重要な理由
カスタム テーブルを使用して選択列を置き換えていますか。	ユーザーが選択できるオプションの一覧を定義する場合は、選択列を使用する、またはレコードの一覧を保持するカスタム テーブルを定義して、選択列をルックアップ列で置き換えるという 2 つの方法があります。 選択列とルックアップ列のいずれかを選択する場合は、次の要因を考慮する必要があります。選択列の値は多数の翻訳の言語をサポートするため、ユーザーはそれぞれの言語で値を表示できます。 選択肢 (複数選択の選択列) では、1 つの列またはビューの行に複数の値を表示できます。 ルックアップ列を無効にして、履歴目的のために古いレコードの値を残しておくことができます。 選択列の値は、削除のみができます。 ルックアップ列オプションに使用されるカスタム テーブル レコードは、非管理者によって変更、追加、および削除できます。 選択列の値は、管理者によって追加または変更する必要があり、使用中のアプリケーション ライフサイクル管理 (ALM) プラクティスに含まれています。 選択列のオプション値は、ソリューションと共に移動します。ルックアップ列で使用されるカスタム テーブル レコードは、各環境で個別に作成および管理する必要があります。または、データ移行プロセスを確立して、カスタム テーブル データを環境間で同期させておく必要があります。 カスタム テーブルは、選択列よりも検索性能が高いため、大きなオプションの数量に適しています。
言語形式の整数属性を使用して、ユーザーの言語に基づいてレコードをフィルター処理していますか。	言語形式オプションを使用して整数列を作成すると、組織用にプロビジョニングされている言語の一覧が表示されます。 言語整数列を使用すると、現在のユーザーの言語に基づいてレコードをフィルター処理できます。 値は言語名のドロップダウンリストとして表示されますが、データは LCID コードを使用して数値として格納されます。 言語コードは 4 桁または 5 桁のロケール ID です。 有効なロケール ID の値については、Microsoft ロケール ID の値 ページを参照してください。

セキュリティ、リレーションシップ、およびパフォーマンス

セキュリティの詳細については、Dynamics 365 ソリューションのセキュリティ モデルの確認モジュールを参照してください。 このモジュールの目的のために、データ モデル設計がセキュリティ モデルに与える影響を評価します。 データ モデルのワークショップ テンプレートのセキュリティ、リレーションシップ、およびパフォーマンスのセクションにある次の質問に対して回答する必要があります。

質問	重要な理由
ユーザー/チームが所有しているテーブルと、組織が所有しているテーブルのどちらを使用するかを検討しましたか。	一般に、参照データは特定のユーザーまたはグループだけにレコードを表示する必要がない場合に、所有権を必要としません。 確信がない場合は、ユーザーに対してこれらのレコードへの組織レベルのアクセス許可を常に付与できるので、ユーザーまたはチーム所有権を持つテーブルを作成することをお勧めします。 組織の所有権の選択を変更することはできません。会社の成長に伴って、一部のレコードへのアクセスを後で制限する必要が生じる可能性があります。 この理由から、ユーザーまたはチーム オプションを選択してください。これは、将来の業務変更に対して最大限の柔軟性を提供するためです。
データ モデル内のリレーションシップおよびセキュリティに対する影響を確認しましたか。	セキュリティに影響を与えるリレーションシップの動作: 割り当て (カスケード – 親から子へ)、共有 (カスケード – 親から子へ)、共有解除 (カスケード – 親から子へ)、リペアレント (非カスケード – 子レコードが親に関連付けられている場合に発生し、暗黙の共有に重要)。
フィールドレベルのセキュリティを使用していますか。	フィールドレベルのセキュリティは、特定のフィールドのデータを保護するための適切なオプションです。 ただし、セキュリティで保護されたフィールドを乱用すると、パフォーマンスが低下して、管理が複雑になる可能性があります。
機密データを別のテーブルに移動することを検討しましたか。	フィールド レベルのセキュリティは、グローバル レベルで動作し、ユーザー/事業単位のコンテキストの影響を受けません (これらの列がレコード単位で共有されている場合を除きます)。機密性の高いデータに対してカスタム関連のテーブルを使用することで、事業単位間の機密データに対して異なるアクセス許可レベルを保持するという柔軟性を追加できます。
機密性の高い個人情報列の名前付け規則を追跡または使用していますか。	個人情報を含む列は、データ セキュリティ規制を使用したコンプライアンスを維持するために、特に注意する必要があります。 個人情報列を管理するための 1 つの方法は、個人情報列の名前付け規則を確立することです。個人情報列のスキーマ名の先頭に "個人" または "機密情報" を付けることができます。

列 - 代替キー、計算済み、およびロールアップ

このセクションでは、次の質問に回答して、その他の列タイプについての詳細を取得できます。

質問	重要な理由
代替キーを使用していますか。	代替キーを使用すると、管理者はテーブルの複数の列を含めた複合キーを定義できます。 代替キーは、レコードの一意性を適用します。 キー値にインデックスが設定されているため、検索速度が向上します。また、代替キーの値に基づいたレコードの更新の一致を有効にすることで、データのインポートがより効率的になります。 一意の値を指定していないレコード作成ロジックを停止する可能性がある既存のシステムに追加する場合は、注意してください。 代替キーは、アップサート機能のメリットを得る必要がある統合シナリオに役立ちます。代替キーを使用すると、レコードの作成または既存のレコードの更新が可能かどうかをシステムが把握します。
計算列を使用していますか。	過剰な JavaScript、ビジネス ルール、プラグインによりシステムのパフォーマンスが低下する可能性があります。 計算列は、データが表示されるリアルタイムを計算し、効率を高めることができます。 値は取得後にのみ更新されるため、計算されたソースの値の変更としてリアルタイムの更新を行う必要はありません。
ロールアップ列を使用していますか。	子レコードの値を親レコードにロールアップする場合、多くの顧客は同期プラグインを使用します。この方法では、過剰に使用するとパフォーマンスのオーバーヘッドが増加します。 標準ロールアップ列を使用することにより、不要なプラグインを回避し、将来のアップグレードを簡略化して、システム パフォーマンスを向上できます。 ロールアップ列は、既定で 12 時間ごとにのみ計算されるので、データをすばやく変更する場合は、標準のロールアップ列で最新の情報が提供されない場合があります。そのため、プラグインを使用する必要があります。 ただし、変更の遅いデータにロールアップ列を使用すると、パフォーマンスが向上します。
各列の最小/最大の長さまたは値が、ビジネス要件、さらにデータ統合やデータ マッピングと一致していることを確認しましたか。	顧客が Dynamics 365 データを他のシステムと移行または統合する場合は、構成された列の長さが他のシステムのデータ列の長さと一致していることを確認する必要があります。
日付のみの列またはタイムゾーンに依存しない日付列を使用することを検討しましたか。	既定の日付列の動作はユーザー ローカルです。 このオプションを選択すると、レコードを表示しているユーザーのタイムゾーンで日時の値が表示されます。 このオプションは、特定の時間が重要となる日付にとって役立ちますが、その他の日付のタイプでは問題が発生する場合があります。 誕生日がユーザー ローカル形式であることを検討してください。 誕生日が 1 月 5 日の午前 12 時の場合、レコードの作成者の西側のタイムゾーン内のユーザーには、日付が前日の午後 11 時として表示されます。 日付のみの形式では、日付の値のみが保存され、タイムゾーンに依存しない形式には時刻が格納されますが、すべてのユーザーに正しい日付値が表示されます。

監査

監査は、セキュリティ追跡機能やデータの問題のトラブルシューティングにとって重要です。 データ モデルのワークショップ テンプレートの [監査] セクションで、顧客の環境の監査設定について次の詳細を取得します。

質問	重要な理由
監査を構成しましたか。	監査が構成されていると見なしている顧客の多くは、真の包括的な監査戦略を持っていません。 既定では、監査はテーブルに対して有効になっていません。 追跡する特定の列に対してのみ監査を有効にすることをお勧めします。テーブルを追加すると、テーブルの監査をオンにすることを忘れやすくなります。 その後、データが後で削除された場合、管理者は監査ログが存在しないことに気づき、データを削除したユーザーを知ることができなくなります。
監査ログを定期的に削除していますか。	監査ログ データの構築は長期にわたって行われ、大量になるため、監査ログストレージを節約するために、定期的に削除する必要があります。
定期的にログ データを消去するためのプロセスを実行していますか。	監査ログ データの構築は長期にわたって行われ、大量になるため、監査ログ ストレージを節約するために、定期的に削除する必要があります。
定期的にトランザクション データをアーカイブするためのプロセスを用意していますか。	数か月にわたってインポートされるトランザクション データは大量になることがあるため、システムのパフォーマンスに影響を与えるほか、ストレージの容量のコストが増加します。 すべてのアクション不可能なトランザクション データに対してデータ保持ポリシーを設定し、保持期間外のデータをシステムからアーカイブまたは削除する必要があります。 システム一括削除ジョブを使用して、スケジュールに基づいてレコードを自動的に削除することができます。

外部データの表示または統合

Dynamics 365 の多くの展開には他のシステムとの統合が含まれており、Dataverse の外部にあるデータ モデルを拡張しています。 多くのデータ移行は、より柔軟なオプションに置き換えて、データベースのサイズを小さくし、システムのパフォーマンスを向上させることができます。 データ モデルのワークショップ テンプレートのこのセクションでは、次の質問に回答してください。

質問	重要な理由
Dynamics 365 のテーブルに外部データをコピーしますか。	データ統合によって、データが Dataverse に取り込まれ、Dynamics 365 ユーザーが外部システム データにアクセスできるようになります。 ただし、物理的なデータ統合には問題が発生する可能性があります。大規模なデータ移行と統合によって、システムのサイズとストレージ容量のコストが大幅に増加します。 大規模なデータの移行は時間がかかり、アプリケーションの展開を遅らせる可能性があります。 大規模なデータの移行と統合は、機密性の高いシステム データの複製を作成しますが、セキュリティおよびコンプライアンス担当者はこれを承認しない可能性があります。 頻繁に実行される大規模なデータ統合により、システムのパフォーマンスが低下する場合があります。
外部データを表示するために、Microsoft Power Apps のキャンバス アプリを使用することを検討しましたか。	Power Apps のキャンバス アプリは、300 を超える標準コネクタを使用して Dynamics 365 モデル駆動型アプリ フォームに簡単に埋め込むことができ、一般的なユーザー タスクを簡略化するための便利なウィザードを提供します。 また、キャンバス アプリは、コネクタを使用して他のシステムでレコードを作成することもできます。これにより、データを物理的にコピーせず、アプリケーション間で最適なブリッジにすることができます。
外部データを表示するために、Power Apps component framework を使用することを検討しましたか。	Power Apps component framework コントロールを使用して、管理者はシステム コントロールをカスタム コントロールに置き換えたり、外部データを表示したりできます。
外部データを表示するために、Microsoft Power BI タイルを埋め込むことを検討しましたか。	Power BI タイルを Dynamics 365 モデル駆動型アプリ フォームに埋め込むことにより、データを Dynamics 365 にコピーせずに、他のシステムに格納されているデータを表示する機能を有効にし、それをフィルター処理してレコードの文脈に関連させることができます。
仮想テーブルを使用していますか。	仮想テーブルにはデータは含まれません。外部データソースに接続し、Dataverse で作業しているかのように、ユーザーにデータを表示します。 このデータは、ビュー、サブグリッド、および高度な検索のクエリで使用できます。 現在、仮想テーブルではデータの読み取りのみをサポートしており、すべての仮想テーブル データはすべてのシステム ユーザーに表示されます。 詳細なセキュリティが必要な場合は、代替オプションを検討してください。
外部のビジネス インテリジェンス目的のために Dynamics データが必要な場合、Azure Data Lake へのエクスポートまたはデータ エクスポート サービスを使用することを検討しましたか。	Data Lake へのエクスポート サービスは、データを Dataverse から、Microsoft Azure Data Lake Storage Gen2 に継続的にエクスポートするパイプラインです。 Data Lake へのエクスポート サービスは、スケーラブルな高可用性を災害復旧機能を提供することにより、エンタープライズ規模のビッグデータを分析するために設計されています。 データは Common Data Model 形式で保存されます。これにより、アプリと展開の間にセマンティクスの整合性が提供されます。 Dynamics エクスポート サービスでは、Dynamics 365 データを Azure SQL データベースと同期します。Dynamics 365 に直接接続する際に Power BI から直接クエリを実行してレポートできるレコード数には制限が課されているため、これは Dynamics からの大規模なデータセットのレポートに最適です。 外部データベースからのレポートは、パフォーマンスの観点からも推奨されます。

ユーザー エクスペリエンス

データ モデルの重要な点は、テーブルの関連付けとシステムにおけるデータ フローについて理解することですが、ユーザーがシステムを最大限に使用できるように、データ モデルは適切なユーザー エクスペリエンスによる影響を考慮する必要があります。 Dynamics 365 でデータをモデル化する方法は、ユーザー エクスペリエンスと、アプリケーションがユーザーにとってどのくらい使いにくいか、または使いやすいかに大きく影響します。 列およびテーブル データを "クリーン" にして、ユーザーが使用するデータと混同しないようにします。 データ モデルのワークショップのユーザー エクスペリエンス セクションで、次の質問に答えてください。

質問	重要な理由
検索から不要な列やリレーションシップを除外しましたか。	列を検索不可に設定すると、これらの列とリレーションシップが高度な検索フィルター デザイナーから除外され、ユーザーが簡単に情報を検索できるようになります。 クイック検索の [検索] 列を最も重要な列のみに制限すると、クイック検索を高速化できます。
未使用の列 ("ZZ 列" など) にプレフィックスを付けて、必ずリストの末尾に表示されるようにしましたか。	列を検索不可能しても、ビューのレイアウト デザインから列は除外されません。 ビューの作成を簡単に行う方法としては、列の表示名の先頭に "ZZ" などの標準的な表記を付けてアルファベットの最後に表示することで、ユーザーがデータの量に圧倒される可能性が低くなります。
UX を容易にするために一貫性のあるメタデータの名前付け規則を採用していますか。	データ モデルを設計する際には、一貫性のある、理解しやすいラベルを提供するために、一貫性のある名前付け規則を作成する必要があります。 この規則は、API を介して (たとえば Power BI を使用して) データにアクセスする開発者やユーザーに対して表示される列スキーマ名にも適用されます。
競合と重複を回避するために、メタデータを管理するための一貫した手順 (新しい列の追加など) を採用していますか。	複数のチームまたはプロジェクト ストリームが 1 つの実装で機能する場合、データ モデルの一貫性を保ち、潜在的な列の重複を回避するために、メタデータを管理するためのガバナンスを実施することが特に重要です。

ワークショップの終了時に、ソリューション アーキテクトは、次のステップと、顧客およびパートナーが行う必要のあるアクションについて説明する必要があります。 調査結果とレコメンデーションが送信されることを説明し、顧客は、必要に応じて、フォローアップ品目の状態を確認するためにフォローアップ ミーティングをスケジュールします。