ทำความเข้าใจข้อมูลองค์กร

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

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

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

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

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

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

ใครเป็นเจ้าของข้อมูล (สนับสนุน SDM-2, SDM-3 และบทข้อมูลหลัก)

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

ประเภทของข้อมูลและภาระงาน (สนับสนุน DM-1, LDV-1 และ MDM-4)

• ฉันแยกข้อมูลหลัก ข้อมูลอ้างอิง ข้อมูลธุรกรรม เมทาดาทา ข้อมูลเชิงวิเคราะห์ และข้อมูลไม่มีโครงสร้างออกจากกันได้ และรู้ว่าแต่ละประเภทหมายถึงอะไรต่อที่ที่มันอยู่ (เริ่มจากประเภท ไม่ใช่ออบเจกต์)
• ฉันรู้ว่าข้อมูลอ้างอิงมีขนาดเล็ก แต่เป็นที่ที่สมมติฐานของการผสานรวมซ่อนอยู่ (Delivered, Complete, D) (ข้อมูลอ้างอิง)
• ฉันแยกภาระงานเชิงปฏิบัติการ (OLTP) เชิงวิเคราะห์ (OLAP) และสตรีมมิงออกจากกันได้: org ดำเนินธุรกิจ คลังข้อมูลและ data lake วิเคราะห์ธุรกิจ (ประเภทเป็นแค่ครึ่งหนึ่งของคำถาม)
• ฉันรู้จัก synchronous (รออยู่หน้าประตู) asynchronous (ทำงานต่อ แล้วจัดการเมื่อมันกลับมา) และ batch (รายชั่วโมง ทุกสองสามชั่วโมง รายวัน) รู้ว่าเมื่อไร batch ก็เพียงพอ และรู้ว่าเรียลไทม์มีต้นทุน (ต้องเคลื่อนที่เร็วแค่ไหน?)
• ฉันถามคำถามสี่ข้อกับทุกชุดข้อมูล: ใครเป็นเจ้าของ เปลี่ยนเร็วแค่ไหน ใหญ่แค่ไหน และวงจรชีวิตเป็นอย่างไร (คำถามสี่ข้อเบื้องหลังหมวดหมู่)

ระบบรอบ Salesforce (สนับสนุน SDM-3, LDV-3 และบทการผสานรวม)

• ฉันรู้บทบาทสี่แบบของระบบ: ระบบต้นทางหลัก ระบบปฏิสัมพันธ์ ระบบอ้างอิง และระบบเชิงวิเคราะห์ (อย่าเริ่มจากชื่อผลิตภัณฑ์)
• ฉันรู้ว่าการวิเคราะห์อยู่ที่ไหนขึ้นกับว่าข้อมูลอยู่ที่ไหน: รายงานบน core เมื่อทุกอย่างอยู่ใน Salesforce แพลตฟอร์มการวิเคราะห์ (Tableau รวมถึง Tableau Next หรือ CRM Analytics ในที่ที่ใช้อยู่) หรือคลังข้อมูล เมื่อมีที่เก็บข้อมูลอื่นเข้ามาเกี่ยว (การวิเคราะห์อยู่ที่ที่ข้อมูลอยู่)
• ฉันรู้ว่าคลังข้อมูล data lake และ lakehouse คืออะไร และรู้บทบาทของ MDM, ESB หรือ iPaaS และเหตุการณ์ (คลังข้อมูล Data Lake และ Lakehouse, ชั้นการผสานรวมและเหตุการณ์)
• ฉันใส่ผู้ให้บริการตัวตนไว้บนภาพรวมระบบตั้งแต่วันแรก และรู้ว่าการตั้งค่า SSO deploy ได้ แต่ secret และใบรับรองไม่ได้ติดไปด้วย บนภาพรวมระบบมันคือใบรับรองที่ใช้ร่วมกัน (ความไว้วางใจ) ไม่ใช่การเรียก เพราะการล็อกอินวิ่งผ่านเบราว์เซอร์ (ระบบที่นักพัฒนาลืม: ตัวตน)
• ฉันรู้ว่า Data 360 เป็น near-core (ใกล้ core) (จัดการบน core โฮสต์นอก core) และ zero copy ของมันทำให้ query ข้อมูลได้โดยไม่ต้องคัดลอก (Data 360 อยู่ตรงไหน?, Core, Off-Core และ Hyperforce)

Org และการโฮสต์ (สนับสนุน SDM-4)

• ฉันเริ่มจาก org เดียว และมองหาขอบเขตที่แท้จริง (ถิ่นที่อยู่ของข้อมูล กฎระเบียบ การแยกทางกฎหมาย รูปแบบการดำเนินงานที่ต่างกัน การควบรวมกิจการ) ก่อนเพิ่มอีกตัว (เริ่มจาก org เดียว, มองหาขอบเขตที่แท้จริง)
• ฉันรู้ว่าหลาย org มีต้นทุนอะไร: การรายงานระดับโลก ข้อมูลหลัก การผสานรวม ตัวตน และการ deploy แต่ละอย่างทวีคูณ (เดินตามลูกศรอีกครั้ง)
• ฉันรู้ว่า Hyperforce ให้เลือกภูมิภาคที่ข้อมูลของ org อยู่ได้ (ไม่ใช่ผู้ให้บริการคลาวด์) แต่ไม่ได้สัญญาว่าทุกบริการจะอยู่ที่นั่น และรู้ว่า GDPR โดยตัวมันเองไม่ได้บังคับให้มี org แยก: มันวางกฎสำหรับข้อมูลส่วนบุคคลที่ออกนอก EU และบริษัทอาจเลือกมี org ในยุโรปเพื่อทำตามกฎนั้น (การโฮสต์เป็นส่วนหนึ่งของภาพ, เมื่อยุโรปมี org ของตัวเอง)

การวาดและอ่านภาพรวมระบบ (สนับสนุนทุกสถานการณ์)

• ฉันวาดภาพรวมระบบได้: คนอยู่ทางซ้าย Salesforce อยู่ตรงกลางโดยมีคอมมูนิตี้ติดอยู่ด้านล่าง ตัวตนอยู่ด้านบน การผสานรวมและระบบหลังบ้านอยู่ทางขวา Data 360 อยู่ใต้ชั้นการผสานรวม ช่องทางอยู่ด้านล่าง ข้อมูลเข้าออกอยู่ที่มุมขวาล่าง (รูปแบบภาพรวมระบบของ Steve)
• บนภาพรวมระบบ ลูกศรเริ่มที่ระบบที่เปิดการเชื่อมต่อ และป้ายกำกับบอกว่าอะไรเคลื่อนย้ายและไปทางไหน บนไดอะแกรมการไหลของข้อมูล ลูกศรตามข้อมูลไป สองโฟลว์คือลูกศรสองเส้น (ทีนี้วาดลูกศร)
• สำหรับทุกลูกศร ฉันรู้ว่าclient จัดการอะไรและ server กำหนดอะไร: ที่ไหน การยืนยันตัวตน โปรโตคอลและสัญญา payload จังหวะเวลา การติดตาม ข้อผิดพลาด Named Credential และ External Credential ของมันเมื่อ Salesforce เรียกออกไป External Client App และผู้ใช้สำหรับการผสานรวมแบบ API-only เมื่อมีบางอย่างเรียก Salesforce (ทุกลูกศรต้องมีกลไก)
• ฉันนับก่อนวาดลูกศร: ปริมาณอยู่ในบัญชีรายการและเป็นตัวกำหนดกลไก และเปลี่ยนทิศที่ลูกศรชี้ได้ด้วยซ้ำ (ใส่เลขศูนย์ลงในบัญชีรายการ)
• ฉันวาด swim lane ก็ต่อเมื่อกระบวนการมีการโต้ตอบไปกลับมากกว่าหนึ่งหรือสองครั้ง (ลูกศรบนภาพรวมระบบ บทสนทนาใน swim lane)

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

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

• วาดภาพรวมระบบก่อนออกแบบ org เริ่มจากผ้าใบว่างเปล่า
• ถอยกล้องออกมา Salesforce เป็นหนึ่งในหลายระบบ
• ระลอกใหม่แทบไม่เคยทำให้ระลอกเก่าหายไป ออกแบบสถาปัตยกรรมให้องค์กรที่มีอยู่จริง ไม่ใช่โบรชัวร์
• อ่านภาพรวมระบบเป็นความรับผิดชอบ ไม่ใช่โลโก้
• ลูกศรทางเดียวทำให้ผมกังวล โฟลว์นี้พึ่งพาอะไร และอะไรส่งกลับมา?
• ทุกลูกศรต้องมีกลไก “ยิงแล้วลืม” ไม่ใช่คำตอบ
• ลูกศรบนภาพรวมระบบ บทสนทนาใน swim lane
• นับก่อนวาดลูกศร เลขศูนย์อยู่ในบัญชีรายการ และมันเป็นตัวเลือกกลไก
• วาดสถานะปัจจุบันก่อนแก้มัน: สเปรดชีต ไฟล์ที่วางบน SFTP ระบบที่ “เรากำลังจะเลิกใช้”
• ทำเครื่องหมายสถานะปัจจุบันอย่างตรงไปตรงมา: สีแดงสำหรับกระบวนการที่ไม่ดี เส้นประสำหรับงานที่ทำด้วยมือ จุดสีแดงสำหรับสิ่งที่ขาดหายไป เส้นสีแดงทุกเส้นคือความต้องการที่รอการเขียนขึ้นมา
• สองโฟลว์ ลูกศรสองเส้น ลูกศรสองหัวใช้กับ connector เท่านั้น
• อย่าเล่นเป็นทนาย ถามว่าคุณกำลังตอบความต้องการข้อใดโดยเฉพาะ และแปลมันร่วมกับคนที่เป็นเจ้าของ
• การแยกไม่ใช่สิ่งเดียวกับความเรียบง่าย

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

คำศัพท์	ในหนึ่งบรรทัด
ภาพรวมระบบ (system landscape)	ระบบรอบ Salesforce คนที่ใช้มัน และโฟลว์สำคัญระหว่างกัน
ระบบต้นทางหลัก (system of record)	ที่ที่เวอร์ชันที่มีอำนาจชี้ขาดของข้อมูลประเภทหนึ่งถูกเก็บ
ระบบปฏิสัมพันธ์ (system of engagement)	ที่ที่คนทำงาน
ระบบอ้างอิง (system of reference)	ที่ที่ระบบหนึ่งไปค้นข้อมูลที่ต้องใช้แต่ไม่ได้เป็นเจ้าของ
ระบบเชิงวิเคราะห์ (system of insight)	ที่ที่ข้อมูลมารวมกันเพื่อวัด วิเคราะห์ และคาดการณ์
ERP	ระบบหลังบ้านสำหรับการเงิน สินค้า สินค้าคงคลัง การจัดซื้อ และการส่งมอบ
ข้อมูลหลัก	สิ่งที่คงทนที่ธุรกิจดำเนินไปรอบๆ: ลูกค้า สินค้า สถานที่
ข้อมูลอ้างอิง	คำศัพท์ร่วมที่ใช้จัดประเภทข้อมูลอื่น: รหัส สถานะ หมวดหมู่
ข้อมูลธุรกรรม	บันทึกสิ่งที่เกิดขึ้น: คำสั่งซื้อ การจัดส่ง การชำระเงิน เคส
ข้อมูลเชิงวิเคราะห์	ข้อมูลที่สร้างจากข้อมูลอื่นเพื่อวัดและเปรียบเทียบ
ข้อมูลไม่มีโครงสร้าง	เอกสาร รูปภาพ เสียง วิดีโอ บทถอดความ
คลังข้อมูล / data lake / lakehouse	ที่เก็บเชิงวิเคราะห์แบบมีโครงสร้าง / ที่เก็บข้อมูลดิบขนาดใหญ่ / ผสมทั้งสองอย่าง
ESB / iPaaS	ชั้นการผสานรวมที่เป็นตัวกลางระหว่างระบบ
OLTP / OLAP	งานเชิงปฏิบัติการกับเรกคอร์ดทีละไม่กี่รายการ / การวิเคราะห์ข้ามเรกคอร์ดจำนวนมาก
Near-core (ใกล้ core)	จัดการบน core โฮสต์นอก core: Data 360
Named Credential / External Credential	ที่ที่ Salesforce เก็บ endpoint ขาออก / การยืนยันตัวตนของ endpoint นั้น
External Client App	วิธีที่ระบบภายนอกได้รับอนุญาตให้เรียก Salesforce
สถานะปัจจุบัน (current state)	ภาพรวมระบบตามที่เป็นอยู่วันนี้ ก่อนการออกแบบ โดยทำเครื่องหมายสิ่งที่ผิด
ผู้ให้บริการตัวตน (IdP)	ระบบที่ยืนยันตัวตนผู้ใช้และกำหนดตัวตนที่ Salesforce ไว้วางใจ
Synchronous / asynchronous / batch	รอคำตอบ / ทำงานต่อแล้วจัดการเมื่อมันมา / เคลื่อนย้ายข้อมูลเป็นกลุ่มตามกำหนดเวลา
Hyperforce	Salesforce บนโครงสร้างพื้นฐานคลาวด์สาธารณะ เลือกภูมิภาคได้
Zero copy	query ข้อมูลตรงที่มันอยู่ โดยไม่ต้องคัดลอก

ทดสอบตัวเอง

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

1. พนักงานขายดูแลบัญชีใน Salesforce แต่ ERP ออกหมายเลขลูกค้าอย่างเป็นทางการเมื่อเขาซื้อ Salesforce ส่งคำสั่งซื้อไปยัง ERP คุณต้องออกแบบอะไรบ้าง?

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

2. ผู้บริหารต้องการผลงานการจัดส่งตรงเวลาห้าปีตามภูมิภาค เชื่อมกับข้อมูลการเงิน สร้างเป็นรายงาน Salesforce ไหม?

น่าจะไม่ มันคือภาระงานเชิงวิเคราะห์ข้ามที่เก็บหลายแห่ง จึงควรอยู่ที่ที่ข้อมูลมารวมกัน: คลังข้อมูล โดยมี CRM Analytics หรือ Tableau อยู่ด้านบน การวิเคราะห์อยู่ที่ไหนขึ้นกับว่าข้อมูลอยู่ที่ไหน อ่านทวน การวิเคราะห์อยู่ที่ที่ข้อมูลอยู่

3. บริษัทหนึ่งดำเนินงานใน 30 ประเทศ และขอ org หนึ่งตัวต่อประเทศ คุณถามอะไร?

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

4. รถบรรทุกส่งค่า GPS 200,000 ค่าต่อวัน Salesforce ควรเก็บทั้งหมดไหม?

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

5. ทีมจัดส่งทำงานตามจุดแวะใน Salesforce แต่เส้นทางถูกสร้างในเครื่องมือจัดส่งรุ่นเก่า และไม่มีอะไรเชื่อมทั้งสองเข้าด้วยกัน คุณจะวาดวันนี้อย่างไร?

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

6. มีคนบอกว่ากฎหมายความเป็นส่วนตัวของยุโรปกำหนดให้ต้องมี org แยก คุณตอบอย่างไร?

ไม่ยอมรับแบบมืดบอด และไม่ปัดตก GDPR โดยตัวมันเองไม่ได้บังคับให้มี org แยก มันวางกฎสำหรับข้อมูลส่วนบุคคล รวมถึงการโอนออกนอก EU ถามว่ามันตอบความต้องการข้อใดโดยเฉพาะ (การจัดเก็บ การประมวลผล การโอน การเข้าถึงเพื่อการสนับสนุน สัญญา นโยบาย) แล้วทำงานร่วมกับฝ่ายความเป็นส่วนตัว กฎหมาย และความปลอดภัย เพื่อเปลี่ยนมันเป็นสถาปัตยกรรม อ่านทวน อย่าเล่นเป็นทนาย และ เมื่อยุโรปมี org ของตัวเอง

7. Salesforce ส่งคำสั่งซื้อไปยัง API ของ ERP ฝั่งไหนจัดการการลองใหม่ (retry) และ Salesforce เก็บ secret ไว้ที่ไหน?

Salesforce คือ client: มันเปิดการเชื่อมต่อ เห็นการเดินทางไปกลับทั้งหมด และเป็นฝั่งเดียวที่ลองใหม่ได้ Named Credential เก็บ endpoint และ External Credential ของมันเก็บการยืนยันตัวตน ERP ซึ่งเป็น server กำหนดสัญญาและตรวจสอบสิ่งที่เข้ามา อ่านทวน ทุกลูกศรต้องมีกลไก

8. การผสานรวมหนึ่งส่งเรกคอร์ดสองสามรายการต่อนาทีในวันนี้ และธุรกิจคาดว่าปีหน้าจะเป็นหลายหมื่นรายการต่อชั่วโมง ลูกศรเปลี่ยนไหม?

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

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

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