データ エンティティに関する設計原則とベスト プラクティス
重要
Human Resources を使用している顧客の場合、この記事で説明した機能は、現在、スタンドアロン Dynamics 365 Human Resources とマージした Finance インフラストラクチャの両方で利用できます。 更新中は、記載されたナビゲーションと異なる場合があります。 特定のページを検索する場合は、検索を使用できます。
この記事では、データ エンティティの設計原則について説明します。 また、データ エンティティ、フィールド、関係のロール、ロールの名前、OData EntityType および EntitySet のガイドラインも含まれています。
エンティティ デザインの原則
データ エンティティは、1 つの消耗契約に関連するビジネス ロジックをカプセル化する総合的なオブジェクトを提供する必要があります。 契約は、OData、インポートとエクスポート、統合、プログラミング モデルなどのアプリケーション インターフェイス (API) を通じて公開されます。 各データ エンティティでは、以下の目標を達成するように設計する必要があります。
カプセル化
- 各エンティティは、物理データ モデルとエンティティのコンシューマー間の抽象化を提供する必要があります。 エンティティは、ビジネスにおいて特定の目的を持つオブジェクトをまとめて定義できる、基になるテーブルをカプセル化する必要があります。 エンティティの消費者は、クライアント、サービス、および統合を形成する場合があります。
- 各エンティティは、ドメイン オブジェクトを表す複数の関連するテーブルをカプセル化する必要があります。 場合によっては、1 つのテーブルのエンティティが許容されます。
1 つのパブリック契約
- エンティティのパブリック契約は、すべての統合エンドポイントで同じである必要があります。 たとえば、顧客エンティティは、同じフィールドまたは OData およびインポート/エクスポートの両方への API を公開する必要があります。 この原則は、エンティティの公開されたスキーマが、消費者のインタラクションの仕組みにかかわらず一貫していることを保証します。
- エンティティが使用されるとき、CRUD 操作時にエンティティ内で実行されるビジネス ロジックは消費者のタイプによって変化することはできません。
シンプルさ
- エンティティのコンシューマーは、エンティティの受け入れられた業種またはドメイン定義に基づいてエンティティと対話することができる必要があります。 エンティティの動作の詳細は、表示されないままにし、相互作用に影響しないようにする必要があります。
- エンティティのコンシューマーは、エンティティのナチュラル キーを使用してエンティティと対話できる必要があります。 コンシューマーは、生成する代理キーなど、実装固有のキーを使用する必要はありません。
名前付けのガイドライン
データ エンティティ名
| 実行 | 実行しない |
|---|---|
| 名前空間がないため、名前の先頭に標準の接頭語を付けます。 | 名前にアンダースコアを含めないでください。 |
| 名前に接尾語「エンティティ」を追加して、同じ接頭語を持つテーブルとクラスとの競合を避けます。 | 概念の名前に省略形を使用しないでください。 |
| エンティティに、en-us UI の名前と合致している概念の名前を付けます。 たとえば、InventTable テーブルからレコードを公開するエンティティ概念の名前は ReleasedProduct と呼ばれ、エンティティの正式名称は EcoResReleasedProductEntity となります。 |
結果:< 接頭語 >< ConceptualName > エンティティ
データ エンティティ フィールド名
| 実行 | 実行しない |
|---|---|
| フィールド名に、en-us UI の名前と合致している概念の名前を付けます。 たとえば、ItemID の代わりに ItemNumber を UI に対応するフィールド名として使用し、ラベルは品目番号になります。 | フィールド名に接頭語を含めないでください。 たとえば、フィールドには InventLocationId という名前を付ける必要がありません。 |
| 外部キーの一部であるフィールドの名前に接尾語「ID」、「番号」などを追加して、ナビゲーション プロパティとの競合を防ぎます。 たとえば、倉庫の代わりに WarehouseID をフィールド名として使用します。それは倉庫が、倉庫エンティティへのナビゲーション メソッドであるからです。 | フィールド名に国または地域固有の接尾語を含めないでください。 たとえば、フィールドに InventoryProfileID_RU という名前を付ける必要がありません。 |
| フィールド名にアンダースコアを含めないでください。 | |
| フィールドの名前に省略形を使用しないでください。 |
データ エンティティ リレーションのロール名
| 実行 | 実行しない |
|---|---|
| 1 より大きいカーディナリティを持つロールに名前を付けるときは、複数形を使用します。 たとえば、関係者への顧客の外部キーには、顧客のロール名が必要で、それは顧客への関係者からの基数が 0...N であるためです。 | リレーション ロール名に接頭語を含めないでください。 たとえば、参照されるエンティティに接頭語「WMS」が含まれていても、WMSWarehouseLocation の名前は使用しないでください。 |
| カーディナリティが 0 (ゼロ) または 1 のロールに名前を付ける場合は、単数形を使用します。 たとえば、個人への作業者の外部キーには、作業者のロール名が必要で、それは作業者への個人からの基数が 0..1 であるためです。 | 関係ロール名に接尾語「エンティティ」を追加しないでください。 たとえば、参照されるエンティティが「エンティティ」の名前を含んでいても、関係でロール名 WarehouseEntity を使用しないでください。代わりに、倉庫という名前を使用します。 |
| 関係の役割を接頭語として追加することを検討してください。 たとえば、関係のロールを明確に説明するには、LegalEntity の代わりに、関係の BuyingLegalEntity に名前を付けます。 | 国または地域固有の接尾語を関係ロール名に追加しないでください。 たとえば、RU 国/地域の形式にのみ関係が適用される場合でも、ロール名 InventoryProfile_RU を使用しないでください。 |
| リレーション ロール名にアンダースコアを含めないでください。 |
データ エンティティのリレーション名
実行
- リレーション名に、単一のフォームで関連するロール名として同じ名前を付けます。 たとえば、顧客から関係者への外部キーを説明する関係は、関係者と呼ばれる必要があります。
OData EntityType 名
実行
- EntityType に概念の名前を付けます。 名前は、データ エンティティの概念の名前と同じでなければなりませんが、接頭語はなく、「エンティティ」接尾語はありません。 たとえば、EcoResReleasedProductEntity は ReleasedProduct になります。
- 単一フォームで EntityType の名前を付けます。
OData EntitySet (エンティティ コレクション) 名
実行
- 複数フォームで EntitySet の名前を付けます。 たとえば、ReleasedProduct EntityType の EntitySet は ReleasedProducts です。
データ エンティティ内の列の数
Microsoft Excel ベースのインポート/エクスポートでは、最大 255 列までサポートされることに注意してください。 エンティティが 255 列以上をエクスポート/インポートできる場合、非 Excel 形式を計画するか、エンティティの列数が 255 列以下である必要があります。