--- schema_version: "1" id: b40886d06a0c5203f42023ede138deb61708c9c536d08289b5b795921125d8f1 title: Salesforce データモデル表記 collection: architect version: current locale: ja-jp portal_url: https://docs.salesforce.com/architect/current/ja-jp/reference-diagrams/guides/data-model-notation.md canonical_url: https://architect.salesforce.com/docs/architect/ja-jp/reference-diagrams/guide/data-model-notation.html source_site: architect.salesforce.com content_type: documentation content_hash: 08289d058a80f4ab851369f192893107135d99ebb81c9b8f4517469f696d9ecb 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 つだけ出現しなければならないことを意味します。 Salesforce の基盤となる物理的なリレーションは省略可能ですが、リレーションの省略可能は必須として表示される場合があります。たとえば、取引先責任者の AccountId 項目は物理的には省略可能なリレーションですが、非公開の取引先責任者を無視すると、取引先責任者と取引先の直接リレーションが論理的に必要になります。省略可能性インジケーターは慎重に使用されます。ほとんどの場合、ERD に表示される省略可能性は、リレーションの基盤となる省略可能性を反映します。 ### リレーションの意味 sample relationships meaning

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

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

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

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

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

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

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