Salesforce 데이터 모델 표기

소개

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

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

엔티티

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

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

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

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

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

엔티티 서식

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

다이어그램에서 지정된 엔티티의 색상도 특정한 의미를 가집니다. 포커스 클라우드 색상은 Salesforce 브랜드 색상으로 표시되며, 아래에 몇 가지 예시가 포함되어 있습니다.

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

클라우드 엔티티

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

확장된 관련 엔티티

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

외부 엔티티

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

레코드 유형 엔티티

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

개념 엔티티

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

상위 유형 및 하위 유형 엔티티

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

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

고정 테두리가 있는 하위 유형 엔티티에는 해당 하위 유형의 발생을 추적하는 실제 개체가 있습니다. 여기 예시에서, 연락처의 외부 사용자 하위 유형은 실선 테두리로 표시됩니다. 이는 외부 사용자로 등록된 연락처가 사용자 오브젝트의 레코드로 추적되기 때문입니다.

관계

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

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

관계 카디널리티

카디널리티는 관계의 각 측에서 발생하는 항목의 상대적인 수를 나타냅니다. 표기법에서 관계선의 끝은 해당 끝의 관계의 카디널리티를 나타냅니다. 한 끝에 갈래 기호(갈퀴발)가 있으면, 해당 끝의 여러 엔티티 항목이 반대 끝의 각 항목과 연결될 수 있음을 나타냅니다. 한 끝에 갈래 기호가 없으면, 해당 끝에는 최대 하나의 엔티티 항목만이 다른 끝의 주어진 항목과 연결될 수 있음을 나타냅니다.

부모-자녀 관계

Salesforce는 관계 필드의 두 가지 종류, 즉 조회 필드와 상위-하위(마스터-디테일) 필드를 지원합니다. 상위-하위 필드는 필수 조회와 비슷하지만 관련 엔티티 간에 추가 커플링이 적용됩니다. 상위 레코드가 삭제되면, 관계의 다수 측(하위)에 있는 레코드들이 함께(계단식으로) 삭제됩니다. 또한 디테일 레코드의 보기 권한은 상위 레코드의 보기 권한에 의해 제어됩니다.

하위-상위 관계와 조회 관계의 차이를 설명하기 위해 Salesforce ERDs는 UML의 다이아몬드 표기법을 차용합니다. 관계의 단수 측에 있는 다이아몬드는 관계에서 해당 측의 엔티티가 마스터 역할을 수행함을 의미합니다. 이러한 관계의 다수 쪽에 있는 엔티티는 디테일 또는 하위 엔티티이며, 상위 엔티티에 포함된 것으로 볼 수 있습니다.

관계의 옵셔널리티

옵셔널리티는 각 끝의 항목에 대해 관계가 필수인지 여부를 나타냅니다. 개념으로서 옵셔널리티는 카디널리티와 긴밀하게 관련이 있으며, 표기법은 그 근접성을 반영합니다. 관계의 각 끝에 있는 선을 가로지르는 원 또는 막대는, 반대쪽 끝의 옵셔널리티를 나타냅니다. 관계의 다른 끝에 있는 이유는 무엇입니까? 카디널리티와 동일한 선의 쪽에 옵셔널리티 표기를 포함하기 위함입니다.

관계의 다수(즉, 갈래 기호) 쪽에는 거의 항상 선 위에 원이 있습니다. 즉, 관계의 단수 쪽에 있는 각 항목에 대해, 다수 쪽에는 0개 이상의 항목이 있을 수 있습니다.

관계의 단수 측에서 원과 막대는 갈래 기호가 있는 쪽의 엔티티에 대한 관계가 선택적임을 나타냅니다. 원과 막대는 관계의 단수 쪽에는 0개 또는 1개의 항목만 있을 수 있음을 의미합니다.

관계의 단수 쪽에서 이중 막대는 다수 쪽 엔티티에 대한 필수 관계를 나타냅니다. 이중 막대는 관계의 단수 쪽에는 다수 쪽의 각 항목마다 반드시 하나의 항목이 있어야 함을 의미합니다.

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

관계 의미

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

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

왼쪽에서 오른쪽으로: 각 는 (일 수 있음/반드시 해야 함) <end name 1> (한 개만 있음/하나 이상) 입니다.

오른쪽에서 왼쪽으로: 각 는 (일 수 있음/반드시 해야 함) <end name 2> (한 개만 있음/하나 이상) 입니다.

예를 들어,

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

관계 색상 구분

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

반복 관계

관계는 동일한 엔티티의 두 인스턴스 사이일 수 있습니다. 이를 반복 관계라고 합니다. 반복 관계를 나타내기 위해 곡선 형태의 관계선이 사용됩니다.

상호 배타적 관계

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

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

레이아웃 규칙

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

관계 선은 항상 직선이어야 합니다.
관계 선은 세로 또는 가로로 그려야 합니다. 불가능한 경우가 드물지만 대각선에 직선을 사용합니다.
관계선을 직선으로 유지하기 위해 엔티티 상자의 크기를 (더 높거나 넓게) 조정하여 두 엔티티 간의 관계선이 잘 연결될 수 있는 위치를 제공할 수 있습니다. 더 많은 관계가 있는 더 중요한 엔티티가 다이어그램에 더 크게 표시되어 중요도가 강화됩니다.
단일 ERD 전반에서 관계선의 갈매기발은 관계선의 왼쪽 및/또는 위쪽(거꾸로 레이아웃) 또는 관계선의 오른쪽 및/또는 아래쪽(정방향 레이아웃)에 일관되게 배치되어야 합니다. 이 규칙은 다이어그램의 동일한 영역에 유사한 엔티티가 모여 있기 때문에 명확성을 제공하며, 엔티티를 이해하는 데 도움이 됩니다. 거꾸로 레이아웃을 사용하면 하위 엔티티가 상위 엔티티 위나 왼쪽에 위치하여 다이어그램이 거꾸로 보일 수 있지만, 이렇게 하면 다이어그램에서 가장 구체적인 엔티티가 왼쪽 상단에 배치되어 다이어그램을 서로 더 쉽게 구분하고 인식할 수 있습니다. 오른쪽 위 레이아웃 규칙을 사용하면 동일한 공통 엔티티가 모든 다이어그램의 왼쪽 상단에 속하지만 하위 엔티티는 상위 엔티티의 오른쪽 또는 아래에 있습니다.

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

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