의미를 위한 데이터 모델링
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)
Data Architect 과정 2장의 학습 가이드입니다. 먼저 여섯 개 모듈을 읽으십시오. 이 페이지는 무엇이 남았는지 점검하도록 돕습니다.
이 학습 가이드에 대해. 이 과정 자체의 내용과 Salesforce가 공개한 시험 가이드의 목표 목록만으로 만들었습니다. 실제 시험 문제를 바탕으로 한 적은 결코 없으며, 시험에 무엇이 나오는지 안다고 주장하지도 않습니다. 시험을 치렀다면 문제를 보내지 말아 주십시오. 자격 인증 계약이 공유를 금지하며, 어차피 답을 외우는 것은 아키텍트가 되는 잘못된 방법입니다.
이 장은 시험의 Data Modeling and Database Design 영역의 기반이며, 이 영역은 시험의 4분의 1입니다. 이 장은 사고방식을 다루고, 다음 장인 Salesforce 데이터 아키텍처는 플랫폼이 그것을 어떻게 구현하는지 다룹니다. 그래서 개체, 필드, 관계에 대해 출제되는 내용 대부분은 두 장이 모두 필요합니다.
시험 대비
섹션 제목: “시험 대비 ”이 장에서 시험에 가장 중요할 만한 항목들입니다. 각각 시험 목표에 연결되어 있고 그것을 가르치는 곳으로 이어집니다. 하나씩 체크하십시오.
DM-1: Salesforce 데이터 모델 설계 기법 비교
- 나는 개념, 논리, 물리 데이터 모델의 차이와 각각의 용도를 설명할 수 있다. (모델을 Salesforce로 옮겨라)
- 나는 요구사항에서 후보 엔터티를 찾고, 일을 하는 사람과 데이터를 구분할 수 있다. (명사는 후보 엔터티를 준다)
- 나는 까마귀 발 표기법을 읽고 그릴 수 있다: 하나, 여럿, 그리고 선택 또는 필수를 나타내는 두 번째 표시. (선을 읽어라, 선택성도 중요하다)
- 나는 관계의 카디널리티를 말할 수 있다: 일대일, 일대다, 다대다. (“하나인가 여럿인가?”를 물어라)
- 나는 다대다 관계가 독립된 엔터티가 되며, Salesforce에서는 보통 상위가 둘인 연결 개체가 된다는 것을 안다. (관계도 실체가 될 수 있다)
- 나는 관계에 덮어써지는 필드가 아니라 이력(시작일과 종료일을 가진 레코드)이 필요한 때를 안다. (시간은 관계를 바꾼다)
- 나는 좋은 고유 ID를 고를 수 있고, 자연 키나 개인정보를 담은 것이 왜 위험한지 안다. (그다음 고유 ID 이야기를 해야 한다)
- 나는 자연 키와 대리 키의 차이를 알고, 레코드 하나가 여러 외부 식별자를 가질 수 있다는 것을 안다. (자연 키와 대리 키)
- 나는 자동 번호 필드가 읽기 쉬운 번호일 뿐 레코드의 Salesforce ID가 아니라는 것을 안다. (관계는 고유 ID에 의존한다)
- 나는 제1, 제2, 제3정규형을 적용하고, 여러 값을 담거나 다른 대상에 관한 사실을 반복하는 필드를 알아볼 수 있다. (1NF, 2NF, 3NF를 생각하는 간단한 방법)
- 나는 언제 의도적으로 비정규화할지(사용자, 보고, 규모)와 그 비용을 설명할 수 있다. (제3정규형까지 설계하고, 한 발 물러서라)
- 나는 값 목록에 대해 선택 목록과 개체로의 조회 중 하나를 고를 수 있다. (조회인가, 선택 목록인가?)
- 나는 사용자 정의 보고서 유형이 개체 관계를 최대 네 개까지 허용하며, 그것이 깊은 모델에서 왜 중요한지 안다. (조회인가, 선택 목록인가?)
- 나는 마스터-세부 사항이 맞는 때(하위 레코드의 상위가 절대 바뀌지 않음)와 조회가 더 안전한 때를 알고, 상위 하나에 하위 10,000건을 넘지 않도록 한 Salesforce의 권장도 안다. (관계는 플랫폼 결정이 된다)
- 나는 가능하면 다형성 관계를 피해야 하는 이유를 안다. (관계는 플랫폼 결정이 된다)
- 나는 비즈니스 엔터티가 자동으로 사용자 정의 개체를 뜻하지 않는다는 것을 안다. 표준 개체, 필드, 구성, 또는 Salesforce 밖의 데이터가 될 수 있다. (비즈니스 엔터티가 자동으로 사용자 정의 개체를 뜻하지는 않는다)
시험 너머
섹션 제목: “시험 너머 ”시험은 바닥이지 천장이 아닙니다. 이것들은 시험 문제가 묻든 말든 아키텍트에게 필요한, 이 장의 습관입니다.
- 잠시 Salesforce를 잊어라. 계정과 연락처에 매핑하기 전에 비즈니스를 모델링하라.
- 두 가지를 숨긴 단어를 들어라. Steve Trucking에서 “고객”은 리테일 파트너이자 수령인이었다.
- 모델은 대화의 일부다. 첫 모델은 맞으려고 있는 게 아니라, 어디서 틀렸는지 보여 주려고 있다.
- 선에 이름을 붙여라. 같은 상자를 가진 두 모델이 다른 것을 뜻할 수 있다.
- 모든 관계에 **“지금인가, 시간에 걸쳐서인가?”**를 물어라.
- 고유하고, 변하지 않고, 의미가 없고, 절대 개인정보가 아니어야 한다.
- 사실을 제자리에 두고, 그다음 의도적으로 물러서며 이유를 기록하라.
- 비정규화는 복잡성을 없애지 않는다. 옮길 뿐이다. 진실을 누가 소유하는지 알라.
- 하나의 진실의 원천, 여러 모양: 화면, 보고서, 웨어하우스, AI.
- 설정 화면에서 설계하지 마라. 새 사용자 정의 개체를 클릭하기 전에 모델을 그려라.
- 모든 물리적 결정을 비즈니스가 필요로 하는 무언가까지 거슬러 추적하라.
알아야 할 용어
섹션 제목: “알아야 할 용어 ”| 용어 | 한 줄 설명 |
|---|---|
| 엔터티 | 비즈니스가 중요하게 여기고 데이터를 보관하는 대상 |
| 후보 엔터티 | 질문을 거쳐 엔터티가 될 수도 있는 명사 |
| 속성 | 엔터티를 기술하는 사실 |
| 관계 | 비즈니스 언어로 이름 붙인, 두 엔터티가 연결된 방식 |
| 카디널리티 | 한쪽 몇 개가 다른 쪽 몇 개와 연결되는지 |
| 선택성 | 관계가 필수인지, 0일 수 있는지 |
| 까마귀 발(crow’s foot) | 선 끝에서 “여럿”을 나타내는 표시 |
| 연결 개체 | 다대다 관계를 만드는 Salesforce의 방식: 두 상위 모두의 하위 |
| 개념 모델 | 비즈니스에 무엇이 있고 어떻게 연결되는지. Salesforce는 없다 |
| 논리 모델 | 데이터: 속성, 고유 ID, 관계. 아직 플랫폼에 묶이지 않는다 |
| 물리 모델 | 플랫폼이 그것을 어떻게 구현할지: 개체, 필드, 관계 유형 |
| 자연 키 | 트럭의 VIN처럼 비즈니스에 이미 존재하는 식별자 |
| 대리 키 | 레코드를 식별하기 위해서만 만든 식별자 |
| 외부 식별자 | 같은 레코드에 대한 다른 시스템의 ID. 보관하고 매핑한다 |
| 정규화(1NF, 2NF, 3NF) | 각 사실을 제자리에 두기: 필드당 값 하나, 키 전체에 관한 사실, 다른 사실에 관한 사실은 없음 |
| 비정규화 | 이유를 댈 수 있는 목적을 위해 의도적으로 데이터를 복사하거나 평평하게 만들기 |
| 갱신 이상 | 같은 사실이 여러 곳에 저장되어, 한 번 바꾸면 일부 사본이 틀린 채 남는 것 |
스스로 점검하기
섹션 제목: “스스로 점검하기 ”과정의 스타일로 쓴 짧은 시나리오입니다. 열어 보기 전에 답을 정하십시오.
1. 비즈니스가 배송팀이 트럭을 운행한다고 말합니다. 6주 뒤 누군가 특정한 날 117번 트럭을 어느 배송팀이 몰았는지 묻습니다. 모델에는 무엇이 있었어야 할까요?
배송팀 배정입니다. 배송팀과 트럭 사이의 관계를 시작일, 종료일, 경로를 가진 별도의 레코드로 둔 것입니다. 배송팀과 트럭은 시간에 걸쳐 다대다이고, 비즈니스는 이력을 신경 씁니다. 트럭의 필드였다면 덮어써졌을 것입니다. 시간은 관계를 바꾼다를 다시 읽으십시오.
2. 한 팀이 “고유하니까” 각 수령인의 전화번호를 고유 ID로 쓰자고 제안합니다. 뭐라고 답하겠습니까?
시험을 통과하지 못합니다. 전화번호는 바뀌고 공유되므로 변하지 않지도, 믿을 만하게 고유하지도 않으며, 레코드와 연결되는 모든 시스템에 복사될 개인정보입니다. 의미 없는 생성 ID를 쓰고 전화번호는 속성으로 두십시오. 그다음 고유 ID 이야기를 해야 한다를 다시 읽으십시오.
3. 배송에 품목 1, 품목 2, 품목 3 필드가 있습니다. 품목이 네 개인 배송이 들어옵니다. 진짜 문제는 무엇이고, 해결책은요?
모델이 반복되는 구조를 필드 안에 숨겼습니다(제1정규형 문제). 해결책은 품목 4 필드가 아니라 배송의 하위인 배송 품목 엔터티로, 모든 품목이 레코드가 되게 하는 것입니다. 제1정규형을 다시 읽으십시오.
4. 모든 배송이 물류 센터장의 이름을 저장합니다. 센터장이 바뀝니다. 무엇이 잘못됐을까요?
다른 대상(물류 센터)에 관한 사실이 배송에 저장되었습니다. 제3정규형 문제이고, 이제 수백 건의 레코드에 걸친 갱신 이상입니다. 센터장은 물류 센터에 속하고, 배송은 물류 센터를 가리킵니다. 제3정규형을 다시 읽으십시오.
5. 정차지 유형(배송만, 설치 포함, 수거 포함)에 소요 시간, 배송팀 기술, 체크리스트가 필요합니다. 선택 목록일까요, 개체일까요?
개체입니다. 정보 열이 둘 이상이고, 비즈니스가 관리하며, 자기 일정대로 바뀝니다. 짧고 안정적인 레이블 목록인 배송 상태는 선택 목록으로 남습니다. 조회인가, 선택 목록인가?를 다시 읽으십시오.
6. 파트너들이 지역별 정시 배송 성과표를 원하는데, 지역은 물류 센터에 있습니다. 지역을 각 배송에 복사합니다. 무엇을 결정해야 할까요?
진실을 누가 소유하는지, 사본이 어떻게 동기화되는지, 그리고 과거 배송이 일어났을 때 참이었던 지역을 유지할지 아니면 물류 센터가 옮겨 가면 따라갈지. 비정규화는 복잡성을 옮겼을 뿐 없애지 않았습니다. 때로는 보고가 이긴다를 다시 읽으십시오.
7. “앉아” 같은 재주는 수십만 마리의 반려동물과 연결될 수 있습니다. 반려동물 재주에서 재주로 가는 관계는 마스터-세부 사항일까요, 조회일까요?
조회입니다. Salesforce는 상위 하나에 하위 10,000건을 넘지 않도록 권장하고, 인기 있는 재주는 그것을 넘길 것입니다. 반려동물 재주에서 반려동물로는 마스터-세부 사항이 맞습니다. 반려동물의 재주는 상위가 바뀌지 않고 반려동물 한 마리가 아는 재주는 몇 개뿐이니까요. 그리고 그 덕분에 반려동물이 아는 재주 수(Tricks Known)를 롤업할 수 있습니다. 앉아, 기다려, 모델링을 다시 읽으십시오.
더 알아보기
섹션 제목: “더 알아보기 ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce 도움말(영어, 확인일 2026-09-25): 공식 목표 목록과 그 비중. 시험을 예약하기 전에 항상 최신 버전을 확인하십시오.