Salesforce 데이터 아키텍처

🌐 28개 언어로도 제공

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI로 생성한 이미지

AI로 번역했습니다. 아직 커뮤니티의 검토를 거치지 않았습니다. 영어로 읽기

Data Architect 과정 3장의 학습 가이드입니다. 먼저 열 개 모듈을 읽으십시오. 이 페이지는 무엇이 남았는지 점검하도록 돕습니다.

이 학습 가이드에 대해. 이 과정 자체의 내용과 Salesforce가 공개한 시험 가이드의 목표 목록만으로 만들었습니다. 실제 시험 문제를 바탕으로 한 적은 결코 없으며, 시험에 무엇이 나오는지 안다고 주장하지도 않습니다. 시험을 치렀다면 문제를 보내지 말아 주십시오. 자격 인증 계약이 공유를 금지하며, 어차피 답을 외우는 것은 아키텍트가 되는 잘못된 방법입니다.

모델이 플랫폼을 만나는 장이고, 시험의 상당 부분을 짊어집니다. 가장 큰 두 영역, Data Modeling and Database Design과 Salesforce Data Management를 모두 뒷받침하며, 각각 시험의 4분의 1입니다. 플랫폼 숫자는 바뀝니다. 체크리스트는 모듈이 인용한 숫자를 확인 날짜와 함께 제시합니다. 각 한계가 무엇을 위한 것인지 배우고, 기대기 전에 현재 숫자를 확인하십시오.

시험 대비

하나씩 체크하십시오. 각 항목은 그것을 가르치는 곳으로 연결됩니다.

DM-1: 플랫폼 위에서 데이터 모델 설계하기

• 나는 Salesforce가 메타데이터 기반 멀티테넌트 플랫폼이라는 것을 안다. 개체는 새 테이블이 아니라 메타데이터이며, 모든 개체는 존재하는 순간 API를 얻는다. (메타데이터는 설계도다, API는 개체와 함께 왔다)
• 나는 거버너 제한이 한 테넌트가 공유 자원을 독차지하지 못하게 하려고 존재한다는 것을 안다. (엘리베이터를 독차지할 수 없다)
• 나는 표준 데이터 모델을 읽을 수 있다: 리드가 계정, 연락처, 기회로 전환되고, 기회 제품은 가격 목록 항목을 가리키며 가격 목록 항목은 Product2를 가리킨다. 그리고 서비스 쪽의 케이스, 자산, 자격(Entitlement). (Sales 모델, Service 모델)
• 나는 새 사용자 정의 개체 화면이 무엇을 정하는지 안다: 텍스트 또는 자동 번호 레코드 이름, 개체 분류(공유, Bulk API, Streaming API를 켜면 Enterprise Application 개체, 끄면 Light Application 개체), 그리고 기본적으로 꺼져 있는 검색 허용. (새 사용자 정의 개체 화면)
• 나는 API 이름을 읽을 수 있다: 표준 개체와 필드에는 접두사도 접미사도 없고, 사용자 정의 개체와 필드는 __c로 끝나며, 관리 패키지는 네임스페이스 접두사(abc__)를 더하고, 패키지의 개체에 내가 추가한 필드는 __c를 얻지만 공급업체의 접두사는 결코 얻지 않는다. (접두사와 접미사: 무엇을 보고 있는가)
• 나는 표준 개체에 대해 깔끔한 적합 테스트를 적용할 수 있고, 의미나 무게가 사용자 정의 개체를 가리키는 때를 안다. (깔끔한 적합 테스트)
• 나는 자산과 개인 계정의 용도를 알고, 개인 계정이 비즈니스 계정의 약 두 배 스토리지를 쓰며, 개인 계정은 한번 활성화하면 비활성화할 수 없다는 것을 안다. (자산은 좋은 예다, 개인 계정, 언제 사람이 계정인가?)
• 나는 필요한 동작에 맞춰 필드 유형을 고르고(차량 번호는 숫자가 아니다), 날짜/시간이 GMT로 저장되고 읽는 사람마다 자기 시간대로 표시되므로 같음이 아니라 범위로 비교한다는 것을 안다. (숫자가 늘 숫자는 아니다, 날짜, 날짜/시간, 시간)
• 나는 텍스트에 두 종류가 있다는 것을 안다: 레코드에 담기는 최대 255자(인덱싱 가능, 고유나 외부 ID로 사용 가능), 그리고 그보다 긴 긴 텍스트 영역이나 서식 있는 텍스트 영역(인덱스 없음, WHERE 필터링 불가, 수식 불가). (텍스트 계열)
• 나는 자동 번호 Name을 쓸 때를 알고, 그것이 레코드의 ID가 아니라는 것을 안다. (사람이 그것을 식별해야 하는가?)
• 나는 외부 ID로 연동이 upsert할 수 있고, 하위를 상위의 외부 ID로 적재할 수 있다는 것을 안다. (외부 ID)
• 나는 값을 수식으로 파생해야 할 때와, 저장해야 하는 과거의 사실일 때를 안다. (저장인가, 파생인가?)
• 나는 논리적 연결 개체(모델링 개념: 다대다에서 두 개체를 잇고 자기 속성을 가진 개체)와 Salesforce 연결 개체(Salesforce Junction Object)(마스터-세부 사항 관계 두 개를 가진 사용자 정의 개체)의 차이를 알고, Salesforce가 말하는 것은 후자라는 것을 안다. (두 상위 너비)
• 나는 계층 관계를 안다: 표준 관리자(Manager) 필드처럼 사용자 개체에만 있는 특별한 조회로, 직접이든 간접이든 같은 사용자로 되돌아올 수 없고, 역할 계층과는 다르다. (계층)
• 나는 조회와 마스터-세부 사항의 차이를 안다: 소유권, 공유, 필수 상위, 연쇄 삭제, 롤업 요약. (조회, 마스터-세부 사항)
• 나는 이미 데이터가 있는 개체에는 마스터-세부 사항을 만들 수 없고(조회를 만들고, 채우고, 변환), 마스터에 롤업이 없을 때만 조회로 되돌릴 수 있으며, 하위를 옮기려면 상위 레코드 재지정 허용이 필요하다는 것을 안다. (하위가 상위를 바꿀 수 있는가?)
• 나는 마스터-세부 사항에 대한 플랫폼의 형태를 안다: 깊이로는 사용자 정의 세부 사항 세 단계까지(조회가 어디서든 사슬을 끊을 수 있다), 너비로는 마스터-세부 사항 상위 둘. Salesforce 연결 개체에서는 먼저 만든 마스터-세부 사항이 기본(소유자, 모양, 디비전)이고 두 번째가 보조이며, 접근에는 두 상위가 모두 필요하다: 가장 제한적인 쪽이 이긴다. (세 단계 깊이, 두 상위 너비)
• 나는 상위가 삭제될 때 조회의 세 가지 선택지를 안다: 필드 지우기(기본값), 삭제 차단, 또는 연쇄 삭제. 연쇄 삭제는 Salesforce가 활성화해 주기 전까지 꺼져 있고 공유를 우회한다. (조회)
• 나는 자기 관계는 조회여야 한다는 것, 그리고 기본 제공되는 두 가지, 계정의 상위 계정과 케이스의 상위 케이스를 안다. (자기 관계)
• 나는 롤업 재계산에 시간이 걸릴 수 있다는 것, 롤업은 NOW(), TODAY(), 개체 간 참조가 있는 수식을 쓸 수 없다는 것, 그리고 롤업 하나를 얻으려고 마스터-세부 사항을 고르지 않는다는 것을 안다. Flow나 트리거로 최신 상태를 유지하는 저장 필드가 대안이다. (롤업은 유용하지만 공짜가 아니다)
• 나는 모듈이 인용한 관계 한계를 안다: 개체당 마스터-세부 사항 2개, 관계 필드 기본 40개(최대 50개), 롤업 기본 25개(최대 40개). (관계에도 한계가 있다)

DM-2: 공유를 존중하고 확장되는 모델

• 나는 마스터-세부 사항의 하위에 자기 소유자도, 자기 공유 테이블도 없으며 접근이 마스터를 따른다는 것을 안다. (소유권이 따라온다)
• 나는 상위-하위 스큐를 안다: Salesforce의 권장은 상위 하나에 하위 약 10,000건을 넘지 않는 것이다. (하위 10,000건의 질문)
• 나는 소유권 스큐(사용자 한 명이 한 개체의 레코드를 10,000건 넘게 소유)와 권장 사항을 안다: 소유권을 분산하거나, 그 사용자를 역할 계층 밖이나 맨 위에 혼자 두고, 공유 규칙이 쓰는 공개 그룹에서 빼라. (소유권은 규모 문제가 될 수 있다)
• 나는 공유 테이블을 안다: 사용자 정의 개체의 공유 개체는 Object__Share이고, 세부 사항 개체에는 공유 개체가 없어 접근이 마스터에서 오며, 소유자가 바뀌면 수동 공유는 제거되지만 자기 이유를 가진 Apex 공유는 유지된다. (공유 테이블)
• 나는 연동과 에이전트가 만든 레코드를 누가 소유할지, 소유권이 공유를 결정하는지에 따라 정할 수 있다. (시스템이 만든 레코드는 누가 소유하는가?)

DM-4: 빅 개체와 표준·사용자 정의 개체

• 나는 데이터의 세 가지 집을 안다: 코어 내(sObject, 매일 작업하는 것), 참조(다른 시스템이 진실의 원천: Salesforce Connect의 외부 개체 __x, 또는 사용자 정의 호출), 보관(코어 내의 빅 개체 __b, 또는 오프코어의 웨어하우스). (코어 내와 오프코어)
• 나는 외부 개체가 건드릴 때마다 콜아웃을 하므로 지연과 원천 시스템의 가용성이 중요하다는 것을 안다. (참조)
• 나는 빅 개체를 안다: 막대한 볼륨, 정확히 일치하거나 범위로 인덱스를 통해 조회, 표준 UI나 보고 없음, 개체와 필드 권한만, 자동화 없음. (보관)
• 나는 대부분의 레코드가 필드 수와 상관없이 데이터 스토리지 약 2KB로 계산되고, 파일은 파일 스토리지에서 따로 측정된다는 것을 안다. (열 두 개든 이백 개든, 파일과 첨부 파일)

SDM-1: 라이선스와 사람들이 쓸 수 있는 개체

• 나는 세 가지 내부 라이선스, Sales Cloud, Service Cloud, Platform과 각각이 무엇을 쓸 수 있는지 안다. (내부 라이선스 세 가지)
• 나는 라이선스가 데이터 모델의 일부라는 것을 안다: Salesforce Platform 사용자는 리드, 캠페인, 기회, 예측을 받지 못하고, Customer Community 사용자는 기회를 쓸 수 없다. (이제 모든 걸 복잡하게 만들겠다: 라이선스)
• 나는 외부 라이선스 등급을 안다: Customer Community, Customer Community Plus(보고서, 대시보드, 표준 공유), Partner Community(영업 개체). 그리고 Partner Community는 개인 계정과 함께 쓸 수 없다. (경기장)
• 나는 회원 기반과 로그인 기반 라이선스, 그리고 각각이 어떤 사용자 집단에 맞는지 안다. (비용을 내는 방식이 설계를 바꾼다)
• 나는 일부 플랫폼 라이선스가 사용자를 사용자 정의 개체 최대 10개짜리 앱 하나로 제한한다는 것, 그리고 그 안에서 일하는 레코드 유형 패턴을 안다. (라이선스가 모델을 형성할 때)
• 나는 Salesforce Integration 라이선스가 시스템 간 API 전용 사용자를 위한 것임을 안다. (사람만 사용자인 시대는 지났다)
• 나는 SLA 보고에 자격과 마일스톤이 필요하고, 그것에 Service 라이선스가 필요하다는 것을 안다. (이제 모든 걸 복잡하게 만들겠다: 라이선스)

SDM-2: 데이터를 일관되게 유지하기

• 나는 규칙을 일관성 사다리의 올바른 칸에 둘 수 있다: 필드 유형과 어휘, 필수와 고유, 유효성 규칙, 중복 규칙, 자동화. (데이터를 일관되게 유지하기)
• 나는 제한된 선택 목록이 API를 통해서도 목록에 없는 값을 거부하고, 글로벌 값 세트가 목록 하나를 여러 필드에서 공유한다는 것(최대 1,000개 값)을 안다. (첫 번째 칸)
• 나는 페이지 레이아웃의 필수 지정이 데이터가 아니라 그 화면만 보호하고, 유효성 규칙은 모든 저장에서 실행된다는 것을 안다. (UI 유효성 검사는 데이터 유효성 검사가 아니다, 세 번째 칸)
• 나는 **ISNEW()**와 ISCHANGED(), 사용자 정의 권한, 또는 시행 시작일로 유효성 규칙의 범위를 정할 수 있고, 각 선택이 어떤 저장을(배치 소유자 변경이나 롤업처럼 내가 통제하지 않는 저장까지) 여전히 확인하는지 안다. (옛 레코드 문제)
• 나는 일치 규칙과 중복 규칙, 모듈이 인용한 한계(개체당 활성 중복 규칙 5개, 각각 일치 규칙 3개), 그리고 그것들이 시스템 사이의 정체성은 해결하지 않는다는 것을 안다. (네 번째 칸: 중복 규칙)
• 나는 중복 규칙이 같은 순간에 저장된 레코드끼리 비교하지 않는다는 것, API와 가져오기 저장은 경고 없이 차단된다는 것, 그리고 저장과 그것이 일으키는 모든 것이 하나의 트랜잭션으로 롤백된다는 것을 안다. (네 번째 칸, 전부 아니면 전무)
• 나는 Workflow Rule과 Process Builder가 지원 종료되었고, 자동화는 Flow나 Apex를 뜻한다는 것을 안다. (다섯 번째 칸: 자동화)

시험 너머

시험은 바닥이지 천장이 아닙니다. 이것들은 시험 문제가 묻든 말든 아키텍트에게 필요한, 이 장의 습관입니다.

• 플랫폼에는 형태가 있다. 범용 데이터베이스가 아니라 지금 쓰는 플랫폼을 위해 설계하라.
• 모선을 보라. 개념을 발명하기 전에 Salesforce가 그것을 어떻게 모델링하는지 보라.
• 모든 개체는 약속이다: 스토리지, 한계, 공유 모델, 라이선스, 의존성.
• 개체를 고르기 전에 데이터가 어디에 있는지 물어라: 코어 내, 참조, 보관.
• API 이름을 읽으면 누가 만들었는지 안다, 그리고 무엇을 바꿀 수 있는지도.
• 오늘 보관하지 않는다면, 언젠가 보관하긴 할 건가요?
• 빅 개체는 제안하기 전에 프로토타입을 만들어 보라.
• 비즈니스 이름이 다르다고 자동으로 개체가 달라지지는 않는다.
• 어떤 정체성에 데이터가 필요한지 물어라: 사람, 고객, 파트너, 연동, 에이전트.
• 모든 필드에 설명을 달고, 중요한 곳에는 분류를 달아라.
• 먼저 관계의 동작을 기술하라. 구성은 그것을 구현한다. 기능을 얻으려고 모델을 비틀지 마라.
• 삭제 질문: 누군가 상위를 삭제하면 하위는 어떻게 되어야 하는가?
• 어느 고리가 사슬을 끊을지 골라라: 하위가 정말 자기 생애를 가진 곳에 조회를 두어라.
• 소유권은 기본 상위에서, 접근은 둘 다에서: 가장 제한적인 쪽이 이긴다.
• 비활성과 사라짐을 구분하고, 보존을 비즈니스 규칙으로 만들어라.
• 규칙을 그것이 올바르게 속하는 곳까지 아래로 내리고, 정당한 이력은 다시 쓰지 말고 우회를 주어라.
• 다이어그램은 아키텍처가 아니다. 모든 구조를 비즈니스 이유까지 거슬러 추적할 수 있어야 한다.

알아야 할 용어

용어	한 줄 설명
메타데이터 기반	개체와 필드는 새 물리 테이블이 아니라 플랫폼이 런타임에 읽는 정의다
멀티테넌시	여러 org가 인프라를 공유하면서 각자 격리된다. 한 건물의 아파트처럼
거버너 제한	한 테넌트가 공유 자원을 독점하지 못하게 하는 제한
외부 개체	Salesforce Connect로 Salesforce에 보여 주는 데이터. 건드릴 때마다 원천에서 가져온다
빅 개체	아주 크고 거의 쓰지 않는 데이터를 위한 저장소. 인덱스로 조회한다
개인 계정	기업 대 소비자 모델을 위해 개인을 계정으로 표현한 것
깔끔한 적합	비즈니스 개념이 표준 개체의 의도된 용도와 맞는 것
외부 ID	다른 시스템의 식별자를 담는 필드. upsert와 매칭에 쓴다
Upsert	레코드가 있으면 갱신하고, 없으면 만든다
조회	하위가 자기 소유자와 생애를 유지하는 관계
마스터-세부 사항	하위가 상위에 속하는 관계: 소유자와 공유를 물려받고, 연쇄 삭제되며, 롤업이 있다
논리적 연결 개체	모델링 개념: 다대다에서 두 개체를 잇고 자기 속성을 지닌 개체. 어떻게 구현하든 상관없다
Salesforce 연결 개체(Salesforce Junction Object)	Salesforce가 말하는 “연결 개체”: 마스터-세부 사항 관계 두 개를 가진 사용자 정의 개체
기본 마스터와 보조 마스터	Salesforce 연결 개체에서 먼저 만든 마스터-세부 사항(소유자, 모양, 디비전)과 두 번째 것(보고서 범위. 첫 번째가 제거되면 기본이 된다)
계층 관계	관리자(Manager)처럼 사용자 개체에만 있는 특별한 조회. 같은 사용자로 되돌아올 수 없다
네임스페이스 접두사	관리 패키지의 개체와 필드에 붙는 공급업체의 접두사. 예: abc__Inspection__c
공유 테이블	레코드 공유 대부분을 담는 공유 개체(AccountShare, Truck__Share). 사용자나 그룹마다 한 행, 그 이유와 함께
롤업 요약	마스터에 있으며 세부 사항을 세거나, 합하거나, 최솟값이나 최댓값을 찾는 필드
데이터 스큐	상위 하나나 소유자 하나 아래 레코드가 너무 많아 잠금과 긴 공유 재계산을 일으키는 것
회원 기반 / 로그인 기반	외부 사용자당 비용을 내거나, 월별 로그인당 비용을 내는 방식
일관성 사다리	필드 유형에서 자동화까지, 데이터 규칙을 시행하는 층들
제한된 선택 목록	어떤 출처에서든 목록에 없는 값을 거부하는 선택 목록
데이터 분류	소유자, 사용, 민감도, 규정 준수 범주를 위한 필드 메타데이터

스스로 점검하기

과정의 스타일로 쓴 짧은 시나리오입니다. 열어 보기 전에 답을 정하십시오.

1. 사용자들이 ERP가 소유하고 하루 종일 갱신하는 주문 상세를 봐야 합니다. Salesforce에서 편집하지는 않습니다. 복사해 올까요, 말까요?

참조하십시오. Salesforce Connect를 통한 외부 개체는 동기화할 사본 없이 ERP를 진실의 원천으로 유지합니다. 볼 때마다 콜아웃이 일어나므로 지연과 ERP의 가용성이 중요하다는 것, 그리고 대량 편집이나 보고보다 읽기 접근에 더 맞는다는 것을 받아들이십시오. 참조를 다시 읽으십시오.

2. 비즈니스가 대리점, 공급업체, 리테일 파트너를 추적하고 싶어 합니다. 사용자 정의 개체 세 개일까요?

아닙니다. 모두 회사이니 계정에 깔끔하게 맞습니다. 다른 이름은 역할이고, 유형, 레코드 유형, 관계가 그것을 담습니다. 깔끔한 적합 테스트를 다시 읽으십시오.

3. 설계가 기회를 쓰는데, 데이터가 필요한 사람 대부분이 Salesforce Platform이나 Customer Community 라이선스입니다. 이제 어떻게 할까요?

그 라이선스로는 기회를 쓸 수 없으니 라이선스가 아키텍처 제약입니다. 다른 라이선스를 사거나, 경험을 옮기거나, 다시 설계하십시오. 보통 사용자 정의 개체 쪽으로 갑니다. 이제 모든 걸 복잡하게 만들겠다: 라이선스를 다시 읽으십시오.

4. ERP가 매일 밤 계정 갱신을 보냅니다. 연동이 Salesforce ID를 조회하지 않고 올바른 레코드를 어떻게 찾아야 할까요?

ERP의 고객 번호를 외부 ID 필드에 저장하고 그것으로 upsert하십시오. 찾으면 갱신하고, 없으면 만듭니다. 하위 레코드도 상위를 그 외부 ID로 가리킬 수 있습니다. 외부 ID를 다시 읽으십시오.

5. 배송 품목은 배송 없이 존재할 수 없고, 옮겨 가지 않으며, 자기 소유자가 필요 없습니다. 배송은 경로에 배정되기 전에 존재하고 다른 경로로 옮겨 갈 수 있습니다. 각각 어떤 관계일까요?

배송 품목에서 배송으로: 마스터-세부 사항(평생 상위에 속하고, 접근을 물려받고, 삭제가 연쇄됨). 배송에서 경로로: 조회(자기 생애가 있고, 처음엔 선택적이며, 옮길 수 있고, 경로를 삭제해도 배송이 삭제되어서는 절대 안 됨). 비즈니스 관계에서 시작하라를 다시 읽으십시오.

6. 연동이 하루에 배송 3,300건을 만들고, 모두 계층 중간에 역할이 있는 연동 사용자 소유입니다. 위험과 해결책은 무엇일까요?

소유권 스큐입니다. 10,000건을 넘으면 그 사용자를 옮기거나 그룹을 바꿀 때 긴 공유 재계산이 일어납니다. 접근에 중요하다면 소유권을 분산하고, 아니라면 연동 사용자를 역할 계층 밖이나 맨 위의 전용 역할에 두고, 공유 규칙이 쓰는 그룹에서 빼십시오. 소유권은 규모 문제가 될 수 있다를 다시 읽으십시오.

7. 유효성 규칙을 추가했더니 옛 레코드 2만 건이 그것을 위반합니다. 사용자가 그중 하나의 전화번호를 고치자 저장이 실패합니다. 규칙은 어떻게 했어야 할까요?

무엇이 참이어야 하는지만이 아니라 언제 시행할지를 말했어야 합니다. 관련 필드에 ISNEW()나 ISCHANGED()로 범위를 정하고, 규칙보다 먼저 존재한 레코드에는 이력을 다시 쓰는 대신 의도적 우회를 주십시오. 옛 레코드 문제를 다시 읽으십시오.

8. 비즈니스가 모든 배송 사진을 “Salesforce에” 두고 싶어 합니다. 1년에 400만~500만 장, 30퍼센트씩 증가. 무엇을 제안하겠습니까?

접근과 저장을 분리하십시오. 파일은 그 볼륨을 위해 만든 코어 org 밖의 스토리지에 두고, 사용자가 찾고 볼 수 있도록 Salesforce에 참조, 개수, 또는 인덱스 레코드를 두십시오. 사진을 다시 읽으십시오.

9. 배송팀 배정(Crew Assignment)은 배송팀(먼저 생성)과 트럭에 대해 마스터-세부 사항 관계를 가집니다. 배차 담당자가 배송팀은 볼 수 있지만 트럭은 볼 수 없습니다. 이 사람은 배송팀 배정을 볼 수 있을까요?

아닙니다. 배송팀이 기본 상위이므로 배정에 소유자와 모양을 주지만, 접근에는 두 상위가 모두 필요합니다. 배차 담당자는 각 마스터-세부 사항 필드의 공유 설정(Sharing Setting)이 요구하는 수준으로 배송팀과 트럭 둘 다에 접근할 수 있어야 합니다. 가장 제한적인 쪽이 이깁니다. 두 상위 너비를 다시 읽으십시오.

10. 파트너가 배송 목록 파일을 다시 보냈는데, 그 안에 같은 고객이 두 번 나옵니다. 계정에는 차단으로 설정한 중복 규칙이 있습니다. 안전할까요?

중복 규칙만으로는 안전하지 않습니다. 같은 순간에 저장된 레코드끼리는 서로 비교되지 않고 이미 Salesforce에 있는 레코드와만 비교되므로, 두 행 모두 통과할 수 있습니다. 고유성을 필드까지 내리십시오. 플랫폼이 모든 저장에서 확인하는 고유 외부 ID라면 하나만 이깁니다. 네 번째 칸: 중복 규칙과 전부 아니면 전무를 다시 읽으십시오.

더 알아보기

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce 도움말(영어, 확인일 2026-09-25): 공식 목표 목록과 그 비중. 시험을 예약하기 전에 항상 최신 버전을 확인하십시오.
• 각 모듈의 더 알아보기 섹션에는 플랫폼 사실의 근거가 된 Salesforce 문서가 확인 날짜와 함께 나와 있습니다.