--- schema_version: "1" id: 811321486a9ce87d45ceff28d729b0bb597cee669e0c3de19bd9a46848ed4fcd title: Salesforce データモデル表記 collection: architect version: next locale: ja-jp portal_url: https://docs.salesforce.com/architect/next/ja-jp/reference-diagrams/guides/data-model-notation.md canonical_url: https://staging.architect.salesforce.com/docs/architect/ja-jp/reference-diagrams/guide/data-model-notation.html source_site: staging.architect.salesforce.com content_type: documentation content_hash: de96abfd8892fc4e04b70d0a412afac4e27582a60421648327d4184ebb039727 products: - 参照図 - Architect Site Content Repo updated_at: 2024-09-15T00:00:00Z --- ## はじめにこのドキュメントでは、[データモデルギャラリー](https://developer.salesforce.com/docs/platform/data-models/guide/get-started.html)で使用可能な商品データモデルを明確に解釈できるように、Salesforce ERD (エンティティリレーションダイアグラム) の表記法と規則の概要について説明します。 ERD は、データモデルとも呼ばれ、情報システムを視覚的に表現したものです。そのシステム内の人、オブジェクト、場所、概念、行動間のリレーションが表示されます。データの機能構造を伝える論理モデルです。Salesforce ERD では、エンティティは通常、Salesforce データベースのオブジェクトに対応付けられます。 ## エンティティエンティティとは、情報を把握または保持する必要がある、実際のものや概念的なものを指します。 sample data model entity

図では、エンティティは角が丸みを帯びたボックスとして表されます。通常、各エンティティボックスには 2 つの表示ラベル (該当する場合) があります。 - エンティティの論理名 (例:この例では「Salesforce エンティティ」)。これは、表される Salesforce オブジェクトの単一表示ラベルに対応する場合がありますが、常に対応するとは限りません。 - Salesforce 組織のオブジェクトの「物理」API 参照名または開発者名 (例:この例では「_API 参照名_」)。管理パッケージオブジェクトの場合、Salesforce または Industry Cloud で複数の管理パッケージが使用されていない限り、通常、図にリストされている API 参照名には管理パッケージ名前空間 (「vlocity_ins\*\*」など) は含まれません。管理パッケージオブジェクトの API 参照名の末尾は、使用されるカスタムオブジェクトの種別を示します (通常のカスタムオブジェクトとカスタム設定の場合は「\*\*c」、カスタムメタデータの場合は「**mdt」、外部オブジェクトの場合は「**x」)。エンティティボックスには、そのエンティティの属性を表す 1 つ以上の属性もリストされます。属性の先頭には「#」または「-」文字があります。 - 「#」は、エンティティの論理一意キーに含まれる属性を示します。図の例では、「ユーザーキー属性」がエンティティのユーザープライマリキーとみなされます。 - 「•」はキー以外の属性を示します。 ### エンティティの書式設定各エンティティリレーションダイアグラムは、Sales Cloud、Service Cloud、Marketing Cloud など、指定されたクラウドの観点から Salesforce データモデルを示しています。図の配色には、焦点が合った雲が反映されます。Financial Service Cloud、Health Cloud、Media Cloud など、すべての業種クラウドで同じ業種の配色が使用されます。図の特定のエンティティの色にも特定の意味があります。フォーカスクラウドの色は、Salesforce のブランド色を使用して示されます。次に例を示します。 sample data model clouds

次のセクションでは、以下の Sales Cloud の例の凡例を参照して、さまざまなエンティティ形式を確認します。 sample data model entities legend

### クラウドエンティティフォーカスクラウドの色のエンティティは、そのクラウドのライセンスに付属するオブジェクトを表します。 ### 関連エンティティ白い塗りつぶしと黒い境界線があるエンティティは、Focus Cloud とは異なるライセンスが付属し、Focus Cloud ライセンスで拡張されていないオブジェクトを表します。たとえば、Sales Cloud ERD または Service Cloud ERD に表示される取引先および取引先責任者エンティティは、プラットフォームライセンスで使用可能なため、白と黒の境界線で表示されます。 ### 拡張関連エンティティ薄いグレーの塗りつぶしと黒の境界線があるエンティティは、フォーカスクラウドとは異なるライセンスが付属するオブジェクトを表しますが、フォーカスクラウドはそのオブジェクトを拡張します。たとえば、Commerce Cloud では、基本の Product2 オブジェクトに追加の項目が拡張されています。拡張には、追加の項目、リレーション、レコードタイプが含まれます。 ### 外部エンティティ境界のないエンティティは仮想です。これらのボックスをダイアグラムで使用すると、ドメインの論理モデルにエンティティが存在することが認識されますが、エンティティは Salesforce で物理オブジェクトとして実装されません。このエンティティのデータは、外部APIコールまたはリリース済みソリューションのSalesforce Connectを介してアクセスすることが期待されます。 ### レコードタイプエンティティ破線で囲まれたエンティティは、Salesforce でレコードタイプとしてモデル化されます。次の例では、\[法人取引先]、\[請求取引先]、\[個人取引先]、\[サービス取引先] サブタイプは Communications Cloud 管理パッケージで提供されるレコードタイプに対応付けられるため、破線で囲まれています。 sample data model record type notation

### 概念エンティティ点線で囲まれたエンティティは仮想です。Salesforce ソリューションでは、レコードタイプも個別のオブジェクトもこれらのサブタイプを区別するために使用されません。これらのサブタイプは、データモデルの機能を説明するのに役立つドメインの概念を論理的に表します。 ### スーパータイプエンティティとサブタイプエンティティエンティティのサブ種別は、出現数のサブセットの定義です。サブ種別のセットがスーパー種別エンティティ内に追加されると、スーパー種別エンティティには共通の属性とリレーションが表示され、サブ種別エンティティにはサブ種別に固有の属性とリレーションが表示されます。図の表記では、サブタイプは相互に排他的です。つまり、1 つのレコードは 1 つのサブタイプである必要があります。 sample subtype relationships

サブ種別には、出現をさらに区別するネストされたサブ種別を含めることができます。図のサブタイプは論理的ですが、3 つの方法のいずれかで物理的な表現に対応付けることができます。サブ種別エンティティの境界線の固さによって、Salesforce データモデルでサブ種別を実装する方法が定義されます。 sample supertype

実線で囲まれたサブ種別エンティティには、そのサブ種別の出現を追跡する実際のオブジェクトがあります。ここに示す例では、外部ユーザーとして登録されている取引先責任者は User オブジェクトのレコードで追跡されるため、取引先責任者の \[外部ユーザー] サブ種別は実線で表示されます。 sample subtype contact object

## リレーションリレーションは、2 つのエンティティ間の名前付き重要な関連付けです。 sample relationships

線の上または周囲のマーキングとテキストは、カーディナリティ、省略可能、リレーションの意味を説明します。 ### リレーションカーディナリティ sample relationships legend

カーディナリティは、リレーションの両側の出現数の相対値を示します。この表記では、リレーション線の終端は、その終端のリレーションのカーディナリティを示します。端のカラスの足は、その端の多数のエンティティ出現が反対側の各出現に関連していることを示します。端にカラスの足がないということは、その端のエンティティ出現数が最大 1 つで、反対側の特定の出現数に関連付けられるということです。 ### 親子リレーション Salesforce では、参照フィールドと親子 (主従関係) フィールドの 2 種類の[リレーションフィールド](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/field_types.htm#i1435823)がサポートされています。親子項目は必須の参照項目と似ていますが、関連エンティティ間の結合が追加されます。親レコードが削除されると、リレーションの多数の側のレコードがカスケード削除されます。また、詳細レコードの表示は、親レコードの表示によって制御されます。子-親リレーションと参照リレーションの違いを説明するために、Salesforce ERD では UML からダイヤモンド表記を借りています。リレーションの 1 つの側にあるひし形とは、その側のエンティティがリレーションの主役割を果たすことを意味します。このようなリレーションの多くの側のエンティティは詳細エンティティまたは子エンティティであり、親エンティティ内に含まれると考えることができます。 ### リレーションの省略可能性省略可能は、両端の出現にリレーションが必要かどうかを示します。概念として、省略可能はカーディナリティと密接に関連しており、表記はその近さを反映しています。省略可能かどうかは、リレーションの反対側の線上の円または棒でリレーションの両端に示されます。どうして関係の反対側に？品目の同じ側にカーディナリティとして省略可能性マークアップを含める場合。リレーションの多くの側 (つまり、カラスの足) では、ほとんどの場合、線上に円があります。つまり、リレーションの多側では、リレーションの単数側の各出現数に対して 0 対多が発生する可能性があります。リレーションの単数側では、円と棒は、そのリレーションのカラス側のエンティティの省略可能なリレーションを示します。円と棒は、多角形の各リレーションの単数側で 0 または 1 回出現する可能性があることを意味します。または、リレーションの 1 つの側にある 2 本の棒は、リレーションの多数の側のエンティティに必要なリレーションを示します。二重棒は、リレーションの単数側に 1 つのみ出現し、多側に存在する各出現数に対応する必要があることを意味します。 Salesforce の基盤となる物理的なリレーションは省略可能ですが、リレーションの省略可能は必須として表示される場合があります。たとえば、取引先責任者の AccountId 項目は物理的には省略可能なリレーションですが、非公開の取引先責任者を無視すると、取引先責任者と取引先の直接リレーションが論理的に必要になります。省略可能性インジケーターは慎重に使用してください。ほとんどの場合、ERD に表示される省略可能性は、リレーションの基盤となる省略可能性を反映します。 ### リレーションの意味 sample relationships meaning

カーディナリティと省略可能性に加えて、2 つのエンティティ間の各リレーションは、同じ 2 つのエンティティ間の他のリレーションと区別する特定の意味を表します。上記の図の「part of」や「made of」などのリレーションの終了名によって、リレーションの性質が定義されます。 sample relationships meaning

リレーションのカーディナリティ、省略可能名、終了名を組み合わせると、リレーションを説明する文を形成するために使用できます。左から右へ:各はにすることができます (必須にすることもできます)。右から左へ:各はにすることができます (必須にすることもできます)。次に例を示します。 sample relationships meaning

左から右へ:「各取引先責任者は主に 1 つの取引先の取引先責任者である必要があります。」右から左へ:「各取引先は主に 1 人以上の取引先責任者で表されます。」 ### リレーションの色分けリレーション線は色分けされています。図のフォーカスがクラウドによって追加されたリレーションは色で描画されます。黒い線は、フォーカスクラウドとは異なるライセンスで提供されるリレーションを表します。 sample relationships color

### 再帰リレーションリレーションは、同じエンティティの 2 つの出現の間にあります。これを再帰関係といいます。曲線リレーション線は、再帰的なリレーションを示すために使用されます。 sample recursive relationships

### 相互に排他的なリレーション sample mutual exclusive relationships

通常、Salesforce ERD では、データモデルの構造に焦点を絞るためにほとんどのビジネスルールが除外されますが、相互排他的なリレーションは、構造に情報を与えるビジネスルールの 1 つです。相互排他的なリレーションは、円弧に含まれる複数のリレーションのうち 1 つだけが特定の発生に使用されることを示します。2 つ、3 つ以上のリレーションが同じ相互排他的なリレーションに含まれる場合があります。ここに示されている相互排他的な関係を説明する文は、次のようになります。「各エンティティは、1 つの 1 つの最初の他のエンティティのみ、または 1 つの 2 番目の他のエンティティのみのインスタンスにすることができます。」 sample mutual exclusive relationships

Salesforce ERD では、円弧を通過する切断されたリレーション線は相互排他的リレーションに含まれません。 ## レイアウト規則 Salesforce の公式製品 ERD は、読みやすさを改善するためにレイアウト規則に従います。次のレイアウト規則があります。 - リレーション線は常に直線である必要があります。 - リレーション線は縦方向または横方向に描画する必要があります。まれに、これができない場合、対角線上の直線を使用します。 - リレーションの直線を維持するには、エンティティボックスのサイズを変更して (より長く)、2 つのエンティティ間のリレーションのランディングプレイスを提供できます。より重要なエンティティ (リレーションが多いエンティティ) は、その重要性を強化するダイアグラムで大きく表示されます。 - 1 つの ERD を通して、カラスのリレーションに対する足の位置は、一貫してリレーションラインの左側または上部 (上下逆レイアウト) であるか、一貫してリレーションラインの右側または下部 (または右側上下レイアウト) である必要があります。この規則により、類似するエンティティが図の同じ領域に集められるため、エンティティを理解するのに役立ちます。上下反転レイアウトを使用すると、図が上下逆に表示され、子エンティティが親エンティティの上または左に配置されます。ただし、これにより、図の最も具体的なエンティティが図の左上隅に配置され、図が互いに区別され、認識しやすくなります。右側のレイアウト規則を使用すると、すべての図の左上に同じ共通エンティティが表示されますが、子エンティティは親エンティティの下または右側に配置されます。これらのレイアウト規則に厳密に準拠することで、すっきりと読みやすい図が作成されます。 [データモデルギャラリー](https://developer.salesforce.com/docs/platform/data-models/guide)で、この標準に準拠する最新の Salesforce データモデルを確認してください。