ข้อมูลหลักและตัวตน

🌐 มีให้อ่านอีก 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 ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ

คู่มือทบทวนสำหรับบทที่ 6 ของหลักสูตร Data Architect อ่านหกโมดูลก่อน รวมถึงคำเฉลยของจุดตรวจสอบที่ 1 หน้านี้ช่วยให้คุณตรวจสอบว่าอะไรติดอยู่ในหัวบ้าง

เกี่ยวกับคู่มือทบทวนนี้ คู่มือนี้สร้างขึ้นจากเนื้อหาของหลักสูตรนี้และรายการวัตถุประสงค์ในคู่มือการสอบที่ Salesforce เผยแพร่เท่านั้น ไม่เคยอิงจากข้อสอบจริง และไม่ได้อ้างว่ารู้ว่าข้อสอบมีอะไร ถ้าคุณเคยสอบแล้ว ได้โปรดอย่าส่งข้อสอบมาให้ผม: ข้อตกลงการรับรองห้ามแชร์ข้อสอบ และการท่องจำคำตอบก็เป็นวิธีที่ผิดในการเป็นสถาปนิกอยู่ดี

บทนี้ครอบคลุมส่วน Master Data Management ของข้อสอบ (5%) และมุมมองเดียวของลูกค้าจาก Salesforce Data Management เป็นส่วนเล็กตามน้ำหนัก แต่ความคิดของมัน (อำนาจชี้ขาด การจับคู่ การคงค่า) ปรากฏอยู่ในสถานการณ์อื่นอีกมาก ตัวเลขของแพลตฟอร์มเปลี่ยนได้ จึงควรตรวจตัวเลขปัจจุบันก่อนพึ่งพามัน

สำหรับการสอบ

ทำเครื่องหมายไปทีละข้อ แต่ละข้อลิงก์ไปยังส่วนที่สอนเรื่องนั้น

MDM-2: golden record และระบบแห่งความจริง

• ฉันรู้ว่าอำนาจชี้ขาดถูกกำหนดต่อแอตทริบิวต์ ไม่ใช่ต่อเรกคอร์ด: บัญชีเดียวอาจมีฟิลด์ที่จัดการข้อมูลหลักใน ERP และฟิลด์ที่จัดการข้อมูลหลักใน Salesforce (ความจริงเป็นของแอตทริบิวต์)
• ฉันถามว่าแต่ละแอตทริบิวต์ถูกสร้าง แก้ไข และอ้างอิงที่ไหน และความหน่วงของการเปลี่ยนแปลงเป็นเท่าไร (สร้าง แก้ไข อ้างอิง และเร็วแค่ไหน?)
• ฉันสร้างแผนที่อำนาจชี้ขาดได้ และรู้ว่าเจ้าของธุรกิจกับระบบที่มีอำนาจชี้ขาดไม่ใช่สิ่งเดียวกัน (สร้างแผนที่อำนาจชี้ขาด)
• ฉันรู้ว่าอำนาจชี้ขาดเปลี่ยนไปตามวงจรชีวิตได้ (ลูกค้ามุ่งหวังใน Salesforce กลายเป็นลูกค้าที่ ERP กำกับดูแล) และสำเนาไม่ใช่อำนาจชี้ขาด (อำนาจชี้ขาดเปลี่ยนไปตามวงจรชีวิต, สำเนาไม่ใช่อำนาจชี้ขาด)

MDM-1: เทคนิค MDM

• ความรู้ที่ออกสอบ: ฉันรู้จักรูปแบบการ implement MDM ทั้งสี่ ได้แก่ registry การรวบรวม การอยู่ร่วมกัน และแบบรวมศูนย์ รู้ว่าแต่ละแบบรวมศูนย์อะไร และส่งค่ากลับไปหรือไม่ (สี่แบบเทียบกัน)
• ฉันแยกสี่รูปแบบของ MDM ได้: registry การรวบรวม การอยู่ร่วมกัน และแบบรวมศูนย์ และเลือกแบบที่เบาที่สุดที่แก้ปัญหาได้ (สี่แบบเทียบกัน)
• ฉันรู้ว่าโมเดลข้อมูลมาตรฐานกลาง (canonical data model) ปรับโครงสร้างให้สอดคล้องกัน แต่ไม่ได้ตัดสินอำนาจชี้ขาด (โมเดลร่วมไม่ใช่ความจริงร่วม)
• ฉันรู้ลำดับ: ปรับให้สอดคล้อง แล้วจับคู่ แล้วรวบรวม (ปรับให้สอดคล้อง แล้วจับคู่ แล้วรวบรวม)
• ฉันรู้ว่าเกณฑ์สะท้อนระดับที่ยอมรับความผิดพลาดได้ และการเพิ่มคุณค่าข้อมูลต้องมีแหล่งที่มา (เกณฑ์ การตรวจทาน และการเพิ่มคุณค่าข้อมูล)
• ความรู้ที่ออกสอบ: ฉันรู้เรื่องการจัดการลำดับชั้น: Parent Account สร้างลำดับชั้น (มุมมองใน Lightning แสดงได้สูงสุด 2,000 บัญชี โดยไม่มีบัญชีบุคคล) ลำดับชั้นมักมีตัวหลักแบ่งกัน และบริษัทหนึ่งอาจมีลำดับชั้นที่ถูกต้องได้หลายแบบ (ลำดับชั้นก็เป็นข้อมูลหลัก, ลำดับชั้นเดียว หลายเจ้าของหลัก)

MDM-3: การเลือกแอตทริบิวต์ที่ชนะ

• ฉันแยกการจับคู่ การผสาน และการคงค่าออกจากกัน (การจับคู่ การผสาน และการคงค่า)
• ฉันรู้กฎการคงค่า: ล่าสุด พบบ่อยที่สุด ลำดับความสำคัญของแหล่ง และทุกกฎต้องมีเจ้าของ (การคงค่า: ค่าใดชนะ?)
• ฉันรู้ว่าการจับคู่ไม่ได้บังคับให้ต้องผสาน และฉันผสานเฉพาะเมื่อมีผู้ชนะที่ชัดเจน โดยตัดสินก่อนว่าจะเกิดอะไรขึ้นกับเรกคอร์ดลูก (การจับคู่ไม่ได้บังคับให้ต้องผสาน, กฎการผสานของผม: ผู้ชนะที่ชัดเจน)
• ความรู้ที่ออกสอบ: ฉันรู้ว่าการผสานบัญชีของ Salesforceทำอะไร: สูงสุดสามเรกคอร์ด ตัวหลักหนึ่งตัว เก็บ Created By และ Created Date ที่เก่าที่สุด ที่เหลือไปถังรีไซเคิล และออบเจกต์ contact point ไม่ถูกผสานสำหรับบัญชีบุคคล (สิ่งที่การผสานของ Salesforce ทำจริงๆ)

SDM-3: มุมมองเดียวของลูกค้า

• ฉันรู้ว่า identity resolution ของ Data 360 เชื่อมโปรไฟล์ต้นทางเป็นโปรไฟล์รวมและเก็บการเชื่อมโยงกลับไว้: ใกล้กับ registry มากที่สุด (Identity Resolution ตอบว่า “ใคร?”)
• ความรู้ที่ออกสอบ: ฉันรู้จักกฎการจับคู่ (match rules) ของ Data 360: เกณฑ์ทั้งหมดในกฎหนึ่งต้องตรงกัน กฎข้อใดก็ตรงได้ เกณฑ์มากขึ้นเพื่อความแม่นยำ น้อยลงเพื่อการรวม (กฎการจับคู่)
• ฉันรู้จักวิธีการจับคู่ (match methods) (Exact, Exact Normalized, Fuzzy ที่ความแม่นยำสามระดับ): วิธีที่แม่นยำน้อยกว่าเพิ่มการรวม และเพิ่มความเสี่ยงของการจับคู่ผิด (กฎการจับคู่)
• ความรู้ที่ออกสอบ: ฉันรู้ว่ากฎการกระทบยอด (Last Updated, Most Frequent, Source Priority) ตัดสินว่าโปรไฟล์รวมแสดงอะไร แต่ไม่เปลี่ยนแหล่งที่มา และจุดติดต่อไม่ถูกกระทบยอด (การกระทบยอดก็ยังไม่ใช่การจัดการข้อมูลหลัก)
• ฉันเลือกระหว่างการจัดการข้อมูลซ้ำ identity resolution และแพลตฟอร์ม MDM เฉพาะให้เหมาะกับงานได้ (สามเครื่องมือสำหรับสามงาน)

MDM-4 และข้อมูลสองทาง

• ฉันรู้ว่าข้อมูลสองทางไม่ได้แปลว่ามีเจ้าของหลักสองราย: การแก้ไขฟิลด์ที่ ERP เป็นเจ้าของใน Salesforce คือคำขอ จึงออกแบบ ขอ → ตรวจสอบ → ยอมรับ → เผยแพร่ พร้อมสถานะรอดำเนินการ (ข้อมูลสองทางไม่ได้แปลว่ามีเจ้าของหลักสองราย, เมื่อตัวหลักบอกว่าไม่)
• ฉันรู้วิธีหลีกเลี่ยงลูปและการชนกัน: แยกการเปลี่ยนแปลงต้นทางออกจากเสียงสะท้อนของมัน และตัดสินว่าฟิลด์ใดเดินทางไปด้วยกันเป็นธุรกรรมเดียว (ลูปและการชนกัน)
• สำหรับลูกค้ารายเดียวใน ERP สองระบบ ฉันเลือกได้ระหว่างลำดับชั้น บัญชีระดับเดียวกัน หรือบัญชีเดียวที่มีลูกหนึ่งตัวต่อ ERP โดยดูจากว่าลูกค้าซิงก์ ERP ของตนได้ดีแค่ไหน (ลูกค้ารายเดียว ERP สองระบบ, ถามว่าพวกเขาซิงก์ ERP อย่างไร)

จุดตรวจสอบที่ 1: ประกอบส่วนที่ 1 เข้าด้วยกัน

• ความรู้ที่ออกสอบ: ฉันรู้ว่าไลเซนส์ภายนอกแบบไหนมาพร้อมการแชร์มาตรฐาน: Customer Community Plus และ Partner Community ซึ่งต้องมีบทบาทสำหรับผู้ใช้ภายนอก ส่วน Customer Community ใช้ sharing set (ใครเห็นอะไร และใครต้องมีไลเซนส์)

นอกเหนือจากการสอบ

การสอบคือพื้น ไม่ใช่เพดาน นี่คือนิสัยจากบทนี้ที่สถาปนิกต้องมี ไม่ว่าจะมีคำถามข้อใดถามถึงหรือไม่

• “แหล่งความจริงเดียว”: ความจริงข้อไหน? มันคือสถาปัตยกรรมของความจริง ไม่ใช่เรกคอร์ดเดียว
• ทำให้อำนาจชี้ขาดมองเห็นได้ในสคีมา: คำนำหน้าสำหรับฟิลด์ที่ระบบอื่นเป็นเจ้าของ
• ความน่าเชื่อถือต้องการมากกว่าค่า: แหล่งที่มา การยืนยันครั้งล่าสุด ใครเปลี่ยนมัน
• เริ่มจากปัญหา ไม่ใช่ผลิตภัณฑ์ MDM MDM คือการตัดสินใจทางธุรกิจเรื่องอำนาจชี้ขาด
• การเชื่อมโยงไม่ใช่การจัดการข้อมูลหลัก
• ในที่ที่การจับคู่ผิดมีราคาแพง ให้จับคู่น้อยไว้โดยตั้งใจ
• เก็บข้อมูลซ้ำจากการโหลดภายนอกไว้ เมื่อคุณอาจต้องสืบย้อน
• โปรไฟล์รวมคือแผนที่ golden record คือการตัดสินใจ
• การแสดงผลไม่ใช่อำนาจชี้ขาด
• การรวมตัวตนไม่ได้ลบขอบเขตความปลอดภัย
• สิ่งที่ยากที่สุดคือแบบสองทิศทาง อำนาจชี้ขาดที่ถูกแบ่งกันไม่ใช่ปัญหา อำนาจชี้ขาดที่คลุมเครือต่างหาก
• อย่าปล่อยให้คำขอที่ถูกปฏิเสธกลายเป็นความจริงคู่แข่ง
• ฟิลด์ที่บอกว่านี่คือข้อมูลหลัก เป็นตัวกำหนดว่าแก้ไขได้หรือไม่ ไม่ใช่ประเภทเรกคอร์ด
• เราไม่ได้ควบคุม ERP เราควบคุมวิธีที่เราแสดงมันใน Salesforce

คำศัพท์ที่ควรรู้

คำศัพท์	ในหนึ่งบรรทัด
การจัดการข้อมูลหลัก (MDM)	การสร้างและกำกับดูแลตัวตนและค่าที่มีอำนาจชี้ขาดของข้อมูลสำคัญข้ามระบบ
แผนที่อำนาจชี้ขาด	สำหรับแต่ละแอตทริบิวต์: ใครสร้าง ใครเป็นเจ้าของการตัดสินใจ ระบบใดมีอำนาจชี้ขาด ใครเปลี่ยนได้
Golden record	การตัดสินใจที่มีธรรมาภิบาลว่าค่าใดมีอำนาจชี้ขาด
Golden record แบบผสม	เรกคอร์ดที่บางแอตทริบิวต์จัดการข้อมูลหลักที่อื่นแล้วคัดลอกเข้ามา และบางแอตทริบิวต์เป็นของในเครื่อง
Registry	MDM ที่เชื่อมเรกคอร์ดว่าเป็นเอนทิตีเดียวกันโดยไม่เปลี่ยนแหล่งที่มา
การรวบรวม (consolidation)	MDM ที่รวมข้อมูลไว้ส่วนกลาง มักเพื่อการวิเคราะห์ โดยไม่ส่งกลับ
การอยู่ร่วมกัน (coexistence)	MDM ที่ตัดสินค่าหลักแล้วเผยแพร่กลับไปยังแหล่งที่มา
MDM แบบรวมศูนย์	MDM ที่ข้อมูลที่มีธรรมาภิบาลถูกสร้างในตัวหลักแล้วกระจายออกไป
โมเดลข้อมูลมาตรฐานกลาง (canonical data model)	รูปร่างระดับองค์กรที่ตกลงกันของแนวคิดหนึ่ง ใช้จับคู่ระบบเข้าหากัน
การปรับให้สอดคล้องกัน (harmonization)	การทำให้ค่าเปรียบเทียบกันได้: รูปแบบ รหัส และคำย่อที่เป็นมาตรฐาน
การจับคู่ (matching)	การตัดสินว่าเรกคอร์ดแทนสิ่งเดียวกันหรือไม่
การคงค่า (survivorship)	กฎว่าค่าใดชนะเมื่อแหล่งที่มาไม่ตรงกัน
เรกคอร์ดหลัก (principal record)	ในการผสานของ Salesforce เรกคอร์ดที่อยู่รอดและเก็บฟิลด์ที่ซ่อนและฟิลด์อ่านอย่างเดียวของตัวเองไว้
วิธีการจับคู่ (match method)	วิธีที่เกณฑ์การจับคู่ของ Data 360 เปรียบเทียบค่า: exact, exact normalized หรือ fuzzy
Identity resolution	การจับคู่โปรไฟล์ต้นทางเป็นโปรไฟล์รวมของ Data 360
โปรไฟล์รวม	ชุดของคีย์ที่เชื่อมเรกคอร์ดต้นทางซึ่งแทนบุคคลหรือบริษัทเดียว
กฎการกระทบยอด	กฎของ Data 360 ว่าโปรไฟล์รวมแสดงค่าใด
ลำดับชั้นที่จัดการข้อมูลหลักแบบแบ่งกัน	ลำดับชั้นที่แต่ละกิ่งมีระบบต่างกันเป็นเจ้าของ

ทดสอบตัวเอง

สถานการณ์สั้นๆ ในแบบของหลักสูตร ตัดสินคำตอบของคุณก่อนเปิดดู

1. “Salesforce คือแหล่งความจริงเดียวของเราสำหรับลูกค้า” คุณถามอะไร?

ความจริงข้อไหน? อำนาจชี้ขาดเป็นรายแอตทริบิวต์: ERP อาจเป็นเจ้าของชื่อตามกฎหมาย ที่อยู่เรียกเก็บเงิน และวงเงินเครดิต ขณะที่ Salesforce เป็นเจ้าของผู้บริหารดูแลลูกค้าและระดับความสำเร็จ สร้างแผนที่อำนาจชี้ขาด อ่านทวน ความจริงเป็นของแอตทริบิวต์

2. เจ้าหน้าที่บริการต้องเห็นว่าผู้ติดต่อใน Salesforce คือคนเดียวกับที่ซื้อของออนไลน์ ไม่มีใครต้องการให้ระบบเปลี่ยน ใช้ MDM รูปแบบไหน?

Registry: เชื่อมเรกคอร์ดเป็นตัวตนเดียวโดยไม่เปลี่ยนแหล่งที่มา ซึ่งคือสิ่งที่ identity resolution ของ Data 360 ทำ เลือกรูปแบบที่เบาที่สุดที่แก้ปัญหาได้ อ่านทวน Registry: บอกผมว่าใครคือใคร

3. การคงค่าตั้งเป็น “ล่าสุดชนะ” สำหรับทุกฟิลด์ มีคนเปลี่ยนสำเนาใน Salesforce ของชื่อตามกฎหมายที่ ERP เป็นเจ้าของ จะเกิดอะไรขึ้น และอะไรผิด?

ค่าที่ใหม่ที่สุดชนะ และสำเนาก็ทับผู้มีอำนาจชี้ขาด “ล่าสุด” คือข้อความเกี่ยวกับความไว้วางใจที่เหมาะกับบางแอตทริบิวต์ (เบอร์มือถือ) และไม่เหมาะกับบางแอตทริบิวต์ ในที่ที่แผนที่อำนาจชี้ขาดบอกว่า ERP เป็นเจ้าของฟิลด์ ERP ชนะ อ่านทวน การคงค่า: ค่าใดชนะ?

4. เรกคอร์ดลูกค้าจากระบบเก่าถูกนำเข้าและตรงกับบัญชีที่มีอยู่ ผสานไหม?

ระวัง การจับคู่ไม่ได้บังคับให้ต้องผสาน และการผสานทำลาย ID เก่าและค่าที่เก่ากว่าที่คุณอาจต้องสืบย้อน เชื่อมโยงมัน เว้นแต่มีผู้ชนะชัดเจนและเรกคอร์ดซ้ำไม่ได้เพิ่มอะไรที่คุณต้องการ อ่านทวน กฎการผสานของผม: ผู้ชนะที่ชัดเจน

5. โปรไฟล์รวมใน Data 360 แสดง Dallas ทีมบอกว่า Dallas คือค่าทองคำสำหรับทุกระบบแล้ว จริงไหม?

ไม่ การกระทบยอดตัดสินว่าโปรไฟล์รวมแสดงอะไร มันไม่เปลี่ยนแหล่งที่มาหรือตัดสินใจเรื่องการจัดการข้อมูลหลัก ถ้าทุกระบบต้องใช้ค่าที่มีธรรมาภิบาลค่าเดียว นั่นคือการอยู่ร่วมกันหรือ MDM แบบรวมศูนย์ ที่มีเจ้าของ อ่านทวน การกระทบยอดก็ยังไม่ใช่การจัดการข้อมูลหลัก

6. การจับคู่เวชระเบียนเทียบกับเรกคอร์ดการตลาด: ใช้กฎเดียวกันไหม?

ไม่ การจับคู่ผิดในการตลาดส่งข้อเสนอผิดคน ในข้อมูลทางการแพทย์มันรวมประวัติของคนสองคน กำหนดความเข้มงวดตามต้นทุนของการผิด และจับคู่น้อยไว้ในที่ที่การรวมผิดมีราคาแพง อ่านทวน ต้นทุนของการผิด

7. พนักงานขายต้องการอัปเดตที่อยู่เรียกเก็บเงินที่ ERP เป็นเจ้าของจาก Salesforce คุณออกแบบอย่างไร?

เป็นคำขอ ไม่ใช่การแก้ไข: Salesforce ส่งค่าที่เสนอไป ERP ตรวจสอบและยอมรับ แล้วเผยแพร่ค่าที่มีอำนาจชี้ขาดกลับมา ระหว่างนั้นถือสถานะรอดำเนินการไว้ และจัดการการปฏิเสธ การชนกัน และเสียงสะท้อน อ่านทวน ข้อมูลสองทางไม่ได้แปลว่ามีเจ้าของหลักสองราย

8. ที่ Steve Trucking John Smith คนเดียวกันปรากฏในใบรายการสินค้าของพันธมิตรค้าปลีกสองราย รวมเขาไหม?

ไม่ และตั้งใจไม่รวม พันธมิตรแต่ละรายต้องไม่เห็นผู้รับของอีกรายเด็ดขาด และตัวตนรวมคือสะพานที่ทำให้ข้อมูลรั่ว จับคู่น้อยไว้ในที่ที่การรวมผิดมีราคาแพง ถ้าพันธมิตรต้องการจำผู้รับที่กลับมาซ้ำ ให้จำกัดขอบเขตไว้ที่พันธมิตรรายนั้นเท่านั้น อ่านทวน ผมจะรวมผู้รับข้ามพันธมิตรไหม?

9. พนักงานขายส่งถนนใหม่สำหรับที่อยู่ที่ ERP เป็นเจ้าของ ขณะที่ในนาทีเดียวกัน ใครบางคนใน ERP เปลี่ยนเมือง คุณตัดสินอะไร?

ว่าที่อยู่เดินทางไปเป็นธุรกรรมเดียวหรือไม่ ถ้าใช่ ฟิลด์ทั้งหมดไปด้วยกันหรือไม่ไปเลย และคำขอถูกปฏิเสธเพราะที่อยู่เปลี่ยนไปในระหว่างนั้น ตัดสินเรื่องนี้ก่อนการชนกันครั้งแรก และจำไว้ว่าคำขอนั้นกำลังขอเปลี่ยนค่าของ ERP ไม่ใช่กำลังเปลี่ยนมัน อ่านทวน ลูปและการชนกัน

10. ลูกค้ารายหนึ่งมีลูกค้ารายเดียวกันอยู่ใน ERP สองระบบ และไม่มีใครดูแลให้สองเรกคอร์ดนั้นซิงก์กัน ฝ่ายขายอยากได้บัญชีเดียว คุณแนะนำอะไร?

ไม่ใช่บัญชีเดียว ถ้าพวกเขาซิงก์เรกคอร์ดใน ERP ของตัวเองไม่ได้ Salesforce ก็ทำแทนไม่ได้: แสดงเป็นบัญชีระดับเดียวกันหรือลำดับชั้น และแสดงโครงสร้างที่ฝ่ายขายรู้จักอยู่แล้ว บัญชีเดียวที่มีลูกหนึ่งตัวต่อ ERP ต้องการลูกค้าที่ดูแลให้ค่าที่ใช้ร่วมกันซิงก์กัน อ่านทวน ถามว่าพวกเขาซิงก์ ERP อย่างไร

ศึกษาเพิ่มเติม

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-09-25): รายการวัตถุประสงค์อย่างเป็นทางการและน้ำหนักของแต่ละข้อ ตรวจสอบฉบับล่าสุดเสมอก่อนจองสอบ
• ส่วนศึกษาเพิ่มเติมของแต่ละโมดูลแสดงรายการเอกสาร Salesforce ที่อยู่เบื้องหลังข้อเท็จจริงในโมดูลนั้น พร้อมวันที่ตรวจสอบ