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