이 문서에서는 데이터 모델 갤러리에서 사용할 수 있는 제품 데이터 모델을 명확하게 해석할 수 있도록 Salesforce 엔티티 관계 다이어그램(ERD) 표기법 및 규칙에 대한 개요를 제공합니다.

데이터 모델이라고도 하는 ERD는 정보 시스템의 그래픽 표현입니다. 해당 시스템의 사람, 개체, 장소, 개념, 이벤트 간 관계를 표시합니다. 데이터의 기능적 구조를 전달하는 논리 모델입니다. Salesforce ERD에서는 일반적으로 엔티티가 Salesforce 데이터베이스의 개체에 매핑됩니다.

엔티티는 알거나 보유해야 하는 정보에 대해 실제 또는 개념적인 의미가 있는 물건 또는 개체입니다.

엔티티는 다이어그램에 둥근 모서리가 있는 상자로 표시됩니다. 각 엔티티 상자는 일반적으로 두 개의 레이블을 제공합니다(해당되는 경우).

• 엔티티의 논리 이름(예: 여기에 표시된 예에서는 "Salesforce 엔티티"입니다. 이는 표시되는 Salesforce 개체의 단수 레이블에 해당할 수 있지만, 항상 그렇지는 않습니다.
• Salesforce 조직의 개체(예: "API 이름" 이 예). 관리 패키지 개체의 경우 일반적으로 Salesforce 또는 Industry Cloud에서 여러 관리 패키지를 사용하지 않는 한 다이어그램에 나열된 API 이름에 관리 패키지 네임스페이스(예: "vlocity_ins**")가 포함되지 않습니다. 관리 패키지 개체의 API 이름 끝에는 일반 사용자 정의 개체 및 사용자 정의 설정의 경우 “**c”, 사용자 정의 메타데이터의 경우 “**mdt”, 외부 개체의 경우 “**x”과 같은 사용자 정의 개체 유형이 사용됩니다.

엔티티 상자에는 해당 엔티티의 특성을 나타내는 하나 이상의 특성이 나열될 수도 있습니다. 특성 앞에 "#" 또는 "-" 문자가 붙습니다.

• “#”는 엔티티의 논리적 고유 키에 속하는 특성을 나타냅니다. 예제 다이어그램에서 "사용자 키 특성"은 엔티티의 사용자 기본 키로 간주됩니다.
• “•”은 키가 아닌 특성을 나타냅니다.

각 엔티티 관계 다이어그램은 Sales Cloud, Service Cloud 또는 Marketing Cloud와 같은 지정된 클라우드의 관점에서 Salesforce 데이터 모델을 보여줍니다. 다이어그램의 색 구성표는 포커스가 맞춰진 클라우드를 반영합니다. Financial Service Cloud, Health Cloud 및 Media Cloud와 같은 모든 업계 클라우드는 동일한 Industry 색 구성표를 사용합니다.

다이어그램에서 지정된 엔티티의 색상도 특정한 의미를 가집니다. 포커스 클라우드 색상은 아래의 몇 가지 예를 포함하여 Salesforce 브랜드 색상을 사용하여 표시됩니다.

다음 섹션에서는 아래의 Sales Cloud 예제 범례를 참조하는 다양한 엔티티 형식을 검토합니다.

포커스 클라우드 색상이 있는 엔티티는 해당 클라우드에 대한 라이센스가 포함된 개체를 나타냅니다.

흰색 채우기 및 검은색 테두리가 있는 엔티티는 포커스 클라우드와 다른 라이센스가 있으며 포커스 클라우드 라이센스로 확장되지 않은 개체를 나타냅니다. 예를 들어 Sales 또는 Service Cloud ERD에 표시된 계정 및 연락처 엔티티는 플랫폼 라이센스로 사용할 수 있으므로 검은색 테두리와 함께 흰색으로 표시됩니다.

밝은 회색 채우기 및 검은색 테두리가 있는 엔티티는 포커스 클라우드와 다른 라이센스로 제공되는 개체를 나타내지만, 포커스 클라우드는 해당 개체를 확장합니다. 예를 들어 Commerce Cloud는 기본 Product2 개체를 추가 필드로 확장합니다. 확장에는 추가 필드, 관계, 레코드 유형이 포함됩니다.

경계가 없는 엔티티는 가상입니다. 다이어그램에서 사용되는 경우 해당 상자는 도메인의 논리 모델에 엔티티가 있는지 확인하지만, 해당 엔티티는 Salesforce에서 물리적 개체로 구현되지 않습니다. 이 엔티티에 대한 데이터는 배포된 솔루션에서 외부 API 호출 또는 Salesforce Connect 통해 액세스할 수 있습니다.

테두리가 파선된 엔티티는 Salesforce에서 레코드 유형으로 모델링됩니다. 여기에 표시된 예에서 비즈니스 계정, 청구 계정, 소비자 계정 및 서비스 계정 하위 유형은 Communications Cloud 관리형 패키지로 전달되는 레코드 유형에 매핑되므로 파선이 파선됩니다.

도트 테두리가 있는 엔티티는 가상입니다. 레코드 유형이나 별도의 개체는 Salesforce 솔루션에서 이러한 하위 유형을 구분하는 데 사용되지 않습니다. 이러한 하위 유형은 데이터 모델의 기능을 설명하는 데 도움이 되는 도메인의 개념을 논리적으로 설명합니다.

엔티티의 하위 유형은 해당 발생의 하위 집합의 정의입니다. 하위 유형 엔티티 내에 하위 유형 집합이 추가되면 하위 유형 엔티티가 공통 특성 및 관계를 표시하고 하위 유형 엔티티는 하위 유형에 고유한 특성 및 관계를 표시합니다. 다이어그램 표기법에서는 하위 유형이 상호 배타적이므로 단일 레코드가 단일 하위 유형이어야 합니다.

하위 유형에는 발생을 추가로 구분하는 중첩된 하위 유형이 있을 수 있습니다. 다이어그램의 하위 유형은 논리적이지만 세 가지 방법 중 하나로 물리적 표현에 매핑할 수 있습니다. 하위 유형 엔티티 테두리의 견고성이 Salesforce 데이터 모델에서 하위 유형이 구현되는 방식을 정의합니다.

고정 테두리가 있는 하위 유형 엔티티에는 해당 하위 유형의 발생을 추적하는 실제 개체가 있습니다. 여기에 표시된 예에서는 외부 사용자로 등록된 연락처가 사용자 개체의 레코드와 함께 추적되므로 연락처의 외부 사용자 하위 유형에 견고한 테두리가 있습니다.

관계는 두 개의 엔티티 간의 명명된 의미 있는 연결입니다.

선 위 또는 주변의 표시와 텍스트는 관계의 카디널리티, 옵션, 의미를 설명합니다.

카디널리티는 관계의 각 측면에서 발생한 상대적인 수를 나타냅니다. 표기법에서 관계 행의 끝은 해당 끝의 관계의 카디널리티를 나타냅니다. 한 끝에 있는 수탉의 바닥글은 해당 끝에 있는 여러 엔티티 항목이 반대 끝의 각 항목과 연결될 수 있음을 나타냅니다. 한 끝에 코끼리 바닥이 없으면 해당 끝에 있는 항목이 한 개 이상 다른 끝에 있는 주어진 항목과 연결될 수 있음을 나타냅니다.

Salesforce는 조회 필드와 상위-하위(마스터-세부 사항) 필드의 두 가지 종류의 관계 필드를 지원합니다. 상위-하위 필드는 필수 조회와 비슷하지만 관련 엔티티 간에 추가 커플링이 적용됩니다. 상위 레코드가 삭제되면 관계의 여러 측면에 있는 레코드가 계단식 삭제됩니다. 또한 세부 사항 레코드의 가시성은 상위 레코드의 가시성에 의해 제어됩니다.

하위-상위 관계와 조회 관계 간의 차이점을 설명하기 위해 Salesforce ERD는 UML에서 다이아몬드 표기를 빌립니다. 관계의 단수 측에 있는 다이아몬드는 관계에서 해당 측의 엔티티가 마스터 역할을 수행함을 의미합니다. 이러한 관계의 여러 측면에 있는 엔티티는 세부 사항 또는 하위 엔티티이며 상위 엔티티 내에 포함된 것으로 간주할 수 있습니다.

옵션은 각 끝에서 발생하는 경우 관계가 필수인지 아닌지를 나타냅니다. 개념으로서 옵션은 카디널리티와 긴밀하게 관련이 있으며 표기법은 해당 근접성을 반영합니다. 옵션은 관계의 다른 끝에 있는 선의 원 또는 막대를 통해 관계의 각 끝에 표시됩니다. 관계의 다른 끝에 있는 이유는 무엇입니까? 카디널리티와 같은 행의 옵션 표시를 포함합니다.

관계의 다중(즉, 수탉의 발) 측면에는 거의 항상 원이 있습니다. 즉, 관계의 단일 측에 있는 각 발생에 대해 관계의 여러 측에 0대다 발생이 있을 수 있습니다.

관계의 단면에서 원과 막대는 관계의 바늘에서 엔티티에 대한 옵션 관계를 나타냅니다. 원 및 막대는 관계의 단일 측면에서 0 또는 하나의 발생이 있을 수 있음을 의미합니다.

또는 관계의 단수 측에서 이중 막대는 관계의 여러 측면에서 엔티티에 대한 필수 관계를 나타냅니다. 이중 막대는 관계의 단일 측면에 여러 측면의 각 항목에 대해 하나의 발생만 있어야 함을 의미합니다.

Salesforce의 기본 물리적 관계가 옵션인 경우에도 관계의 옵션성이 필수 항목으로 표시될 수 있습니다. 예를 들어, 연락처의 AccountId 필드는 물리적으로 옵션 관계이지만, 비공개 연락처를 무시하는 경우 계정에 대한 연락처의 직접 관계가 논리적으로 필요합니다. 옵션성 표시기는 거의 사용되지 않습니다. 대부분의 경우 ERD에 표시된 옵션에 관계의 기본 옵션이 반영됩니다.

카디널리티 및 옵션성 외에도 두 엔티티 간의 각 관계는 동일한 두 엔티티 간의 다른 관계와 해당 관계를 구분하는 특정 의미를 표현합니다. 위의 다이어그램에서 "part of" 및 "made of"와 같은 관계 끝 이름은 관계의 특성을 정의합니다.

관계의 카디널리티, 옵션 및 끝 이름을 결합하면 해당 이름을 사용하여 관계를 설명하는 문구를 만들 수 있습니다.

왼쪽에서 오른쪽으로: 각 (해당 가능/해당 가능)은 <end name 1>(한 개만 있음/하나 이상) 입니다.

오른쪽에서 왼쪽으로: 각 (해당 가능/필수)는 <end name 2>(한 개만 해당) 입니다.

예를 들어,

왼쪽에서 오른쪽으로: "각 연락처는 기본적으로 하나의 계정에 대한 연락처여야 합니다." 오른쪽에서 왼쪽으로: "각 계정은 기본적으로 하나 이상의 연락처로 표시될 수 있습니다."

관계 선은 색상으로 구분됩니다. 다이어그램에 대한 포커스에 클라우드가 추가한 관계는 색으로 표시됩니다. 검은색 선은 포커스 클라우드와 다른 라이센스로 제공되는 관계를 나타냅니다.

관계는 동일한 엔티티의 두 항목 사이일 수 있습니다. 이를 반복 관계라고 합니다. 곡선 관계는 반복 관계를 나타내는 데 사용됩니다.

Salesforce ERD는 일반적으로 데이터 모델의 구조에 초점을 맞추기 위해 대부분의 비즈니스 규칙을 제외하지만, 상호 배타적 관계는 구조에 정보를 제공하는 비즈니스 규칙이므로 명시됩니다. 상호 배타적 관계는 아크에 포함된 여러 관계 중 하나만 주어진 발생에 사용됨을 나타냅니다. 둘 이상의 관계는 동일한 상호 배타적 관계에 참여할 수 있습니다. 여기에 표시된 상호 배타적 관계를 설명하는 문구는 다음과 같습니다. "각 엔티티는 하나의 첫 번째 기타 엔티티 또는 하나의 두 번째 기타 엔티티의 인스턴스일 수 있습니다."

Salesforce ERD에서 아크를 통과하는 끊어진 관계선은 상호 배타적 관계의 일부가 아닙니다.

공식 Salesforce 제품 ERD는 레이아웃 규칙을 따라 가독성을 향상합니다. 이러한 레이아웃 규칙에는 다음이 포함됩니다.

• 관계 선은 항상 직선이어야 합니다.
• 관계 선은 세로 또는 가로로 그려야 합니다. 불가능한 경우가 드물지만 대각선에 직선을 사용합니다.
• 관계 행을 직관적으로 유지하기 위해 엔티티 상자의 크기를 조정할 수 있습니다(더 크거나 넓음) 두 엔티티 간의 관계에 대한 랜딩 위치를 제공합니다. 더 많은 관계가 있는 더 중요한 엔티티가 다이어그램에 더 크게 표시되어 중요도가 강화됩니다.
• 단일 ERD 전반에서 관계의 바닥글은 관계 행의 왼쪽 및/또는 상단(위쪽-아래 레이아웃) 또는 관계 행의 오른쪽 및/또는 하단(오른쪽-아래 레이아웃)에 일관되게 있어야 합니다. 이 규칙은 다이어그램의 동일한 영역에 유사한 엔티티가 수집되므로 명확성을 제공하므로 엔티티를 이해하는 데 유용합니다. 위쪽 아래 레이아웃을 사용하면 하위 엔티티가 상위 엔티티 위 또는 왼쪽에 속하는 경우 위쪽 아래로 표시되는 다이어그램이 나타나지만, 이렇게 하면 다이어그램의 가장 구체적인 엔티티가 다이어그램의 왼쪽 상단에 속하므로 다이어그램이 서로 구분되고 인식할 수 있습니다. 오른쪽 위 레이아웃 규칙을 사용하면 동일한 공통 엔티티가 모든 다이어그램의 왼쪽 상단에 속하지만 하위 엔티티는 상위 엔티티의 오른쪽 또는 아래에 있습니다.

이러한 레이아웃 규칙을 엄격하게 준수하면 깔끔하고 쉽게 읽을 수 있는 다이어그램이 생성됩니다.

이 표준을 따르는 최신 Salesforce 데이터 모델은 데이터 모델 갤러리에서 확인하십시오.