このドキュメントでは、データモデルギャラリーで使用可能な商品データモデルを明確に解釈できるように、Salesforce ERD (エンティティリレーションダイアグラム) の表記法と規則の概要について説明します。

ERD は、データモデルとも呼ばれ、情報システムを視覚的に表現したものです。そのシステム内の人、オブジェクト、場所、概念、行動間のリレーションが表示されます。データの機能構造を伝える論理モデルです。Salesforce ERD では、エンティティは通常、Salesforce データベースのオブジェクトに対応付けられます。

エンティティとは、情報を把握または保持する必要がある、実際のものや概念的なものを指します。

図では、エンティティは角が丸みを帯びたボックスとして表されます。通常、各エンティティボックスには 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 のブランド色を使用して示されます。次に例を示します。

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

フォーカスクラウドの色のエンティティは、そのクラウドのライセンスに付属するオブジェクトを表します。

白い塗りつぶしと黒い境界線があるエンティティは、Focus Cloud とは異なるライセンスが付属し、Focus Cloud ライセンスで拡張されていないオブジェクトを表します。たとえば、Sales Cloud ERD または Service Cloud ERD に表示される取引先および取引先責任者エンティティは、プラットフォームライセンスで使用可能なため、白と黒の境界線で表示されます。

薄いグレーの塗りつぶしと黒の境界線があるエンティティは、フォーカスクラウドとは異なるライセンスが付属するオブジェクトを表しますが、フォーカスクラウドはそのオブジェクトを拡張します。たとえば、Commerce Cloud では、基本の Product2 オブジェクトに追加の項目が拡張されています。拡張には、追加の項目、リレーション、レコードタイプが含まれます。

境界のないエンティティは仮想です。これらのボックスをダイアグラムで使用すると、ドメインの論理モデルにエンティティが存在することが認識されますが、エンティティは Salesforce で物理オブジェクトとして実装されません。このエンティティのデータは、外部APIコールまたはリリース済みソリューションのSalesforce Connectを介してアクセスすることが期待されます。

破線で囲まれたエンティティは、Salesforce でレコードタイプとしてモデル化されます。次の例では、[法人取引先]、[請求取引先]、[個人取引先]、[サービス取引先] サブタイプは Communications Cloud 管理パッケージで提供されるレコードタイプに対応付けられるため、破線で囲まれています。

点線で囲まれたエンティティは仮想です。Salesforce ソリューションでは、レコードタイプも個別のオブジェクトもこれらのサブタイプを区別するために使用されません。これらのサブタイプは、データモデルの機能を説明するのに役立つドメインの概念を論理的に表します。

エンティティのサブ種別は、出現数のサブセットの定義です。サブ種別のセットがスーパー種別エンティティ内に追加されると、スーパー種別エンティティには共通の属性とリレーションが表示され、サブ種別エンティティにはサブ種別に固有の属性とリレーションが表示されます。図の表記では、サブタイプは相互に排他的です。つまり、1 つのレコードは 1 つのサブタイプである必要があります。

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

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

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

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

カーディナリティは、リレーションの両側の出現数の相対値を示します。この表記では、リレーション線の終端は、その終端のリレーションのカーディナリティを示します。端のカラスの足は、その端の多数のエンティティ出現が反対側の各出現に関連していることを示します。端にカラスの足がないということは、その端のエンティティ出現数が最大 1 つで、反対側の特定の出現数に関連付けられるということです。

Salesforce では、参照フィールドと親子 (主従関係) フィールドの 2 種類のリレーションフィールドがサポートされています。親子項目は必須の参照項目と似ていますが、関連エンティティ間の結合が追加されます。親レコードが削除されると、リレーションの多数の側のレコードがカスケード削除されます。また、詳細レコードの表示は、親レコードの表示によって制御されます。

子-親リレーションと参照リレーションの違いを説明するために、Salesforce ERD では UML からダイヤモンド表記を借りています。リレーションの 1 つの側にあるひし形とは、その側のエンティティがリレーションの主役割を果たすことを意味します。このようなリレーションの多くの側のエンティティは詳細エンティティまたは子エンティティであり、親エンティティ内に含まれると考えることができます。

省略可能は、両端の出現にリレーションが必要かどうかを示します。概念として、省略可能はカーディナリティと密接に関連しており、表記はその近さを反映しています。省略可能かどうかは、リレーションの反対側の線上の円または棒でリレーションの両端に示されます。どうして関係の反対側に？品目の同じ側にカーディナリティとして省略可能性マークアップを含める場合。

リレーションの多くの側 (つまり、カラスの足) では、ほとんどの場合、線上に円があります。つまり、リレーションの多側では、リレーションの単数側の各出現数に対して 0 対多が発生する可能性があります。

リレーションの単数側では、円と棒は、そのリレーションのカラス側のエンティティの省略可能なリレーションを示します。円と棒は、多角形の各リレーションの単数側で 0 または 1 回出現する可能性があることを意味します。

または、リレーションの 1 つの側にある 2 本の棒は、リレーションの多数の側のエンティティに必要なリレーションを示します。二重棒は、リレーションの単数側に 1 つのみ出現し、多側に存在する各出現数に対応する必要があることを意味します。

Salesforce の基盤となる物理的なリレーションは省略可能ですが、リレーションの省略可能は必須として表示される場合があります。たとえば、取引先責任者の AccountId 項目は物理的には省略可能なリレーションですが、非公開の取引先責任者を無視すると、取引先責任者と取引先の直接リレーションが論理的に必要になります。省略可能性インジケーターは慎重に使用してください。ほとんどの場合、ERD に表示される省略可能性は、リレーションの基盤となる省略可能性を反映します。

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

リレーションのカーディナリティ、省略可能名、終了名を組み合わせると、リレーションを説明する文を形成するために使用できます。

左から右へ:各は <end name 1＞ (1 つだけまたは 1 つ以上) にすることができます (必須にすることもできます)。

右から左へ:各は <end name 2＞ (1 つだけまたは 1 つ以上) にすることができます (必須にすることもできます)。

次に例を示します。

左から右へ:「各取引先責任者は主に 1 つの取引先の取引先責任者である必要があります。」右から左へ:「各取引先は主に 1 人以上の取引先責任者で表されます。」

リレーション線は色分けされています。図のフォーカスがクラウドによって追加されたリレーションは色で描画されます。黒い線は、フォーカスクラウドとは異なるライセンスで提供されるリレーションを表します。

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

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

Salesforce ERD では、円弧を通過する切断されたリレーション線は相互排他的リレーションに含まれません。

Salesforce の公式製品 ERD は、読みやすさを改善するためにレイアウト規則に従います。次のレイアウト規則があります。

• リレーション線は常に直線である必要があります。
• リレーション線は縦方向または横方向に描画する必要があります。まれに、これができない場合、対角線上の直線を使用します。
• リレーションの直線を維持するには、エンティティボックスのサイズを変更して (より長く)、2 つのエンティティ間のリレーションのランディング プレイスを提供できます。より重要なエンティティ (リレーションが多いエンティティ) は、その重要性を強化するダイアグラムで大きく表示されます。
• 1 つの ERD を通して、カラスのリレーションに対する足の位置は、一貫してリレーションラインの左側または上部 (上下逆レイアウト) であるか、一貫してリレーションラインの右側または下部 (または右側上下レイアウト) である必要があります。この規則により、類似するエンティティが図の同じ領域に集められるため、エンティティを理解するのに役立ちます。上下反転レイアウトを使用すると、図が上下逆に表示され、子エンティティが親エンティティの上または左に配置されます。ただし、これにより、図の最も具体的なエンティティが図の左上隅に配置され、図が互いに区別され、認識しやすくなります。右側のレイアウト規則を使用すると、すべての図の左上に同じ共通エンティティが表示されますが、子エンティティは親エンティティの下または右側に配置されます。

これらのレイアウト規則に厳密に準拠することで、すっきりと読みやすい図が作成されます。

データモデルギャラリーで、この標準に準拠する最新の Salesforce データモデルを確認してください。