คิดแบบสถาปนิกข้อมูล

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

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

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

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

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

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

อ่านสถานการณ์แบบสถาปนิก (สนับสนุนทุกวัตถุประสงค์)

• ฉันแยกความต้องการที่แท้จริงออกจากการออกแบบที่มันห่อมา (“เราต้องการฟิลด์ Approver 2 และ Approver 3” กับ “เราต้องติดตามทุกการอนุมัติ”) (อย่าแค่รับความต้องการมา)
• ฉันมองหาความต้องการที่แฝงอยู่ที่ไม่มีใครพูด: ความเป็นเจ้าของ ความสดใหม่ ความล้มเหลว การเก็บรักษา การเข้าถึง (มองหาความต้องการที่แฝงอยู่)
• ฉันใส่ตัวเลข: ปริมาณต่อวัน ต่อปี พร้อมการเติบโต และสังเกตได้เมื่อเลขศูนย์เพิ่มอีกตัวเปลี่ยนคำตอบ (รู้จักตัวเลขของคุณ)
• เมื่อมีหลายคำตอบที่ใช้ได้ ฉันเปรียบเทียบว่าแต่ละข้อได้อะไรและเสียอะไรกับความต้องการและข้อจำกัดที่ระบุไว้ (รู้ว่าคุณกำลังแลกอะไรไป, ข้อจำกัดเปลี่ยนคำตอบ)
• ฉันถือว่าต้นทุน สิทธิ์การใช้งาน และข้อจำกัดเป็นส่วนหนึ่งของการพิจารณาว่าเครื่องมือเหมาะหรือไม่ ไม่ใช่เรื่องที่คิดทีหลัง (คำถามเก้าข้อ)

โมเดลข้อมูล (สนับสนุน DM-1)

• ฉันประเมินโมเดลได้จากว่ามันสนับสนุนธุรกิจ เติบโตไปพร้อมธุรกิจได้ และทำผลงานได้ดีหรือไม่ (สนับสนุน เติบโต ทำผลงาน)
• ฉันมองออกเมื่อโมเดลแบนเกินไป (Field 1, Field 2, Field 3) แยกย่อยเกินไป หรือสร้างบนออบเจกต์มาตรฐานที่ผิด (แบนเกินไป ซับซ้อนเกินไป หรือผิดไปเลย)
• ฉันรู้ว่าทำไม picklist จึงเหมาะกับรายการสั้นที่คงที่ และ lookup เหมาะกับรายการที่เติบโตต่อไปหรือมาจากการผสานรวม (ปัญหาหนึ่งแก้ได้หลายวิธี)
• ฉันรู้ว่าคีย์ที่มีความหมายในตัว (เช่น ส่วนหนึ่งของชื่อ) จะพังเมื่อความหมายนั้นเปลี่ยน (การตัดสินใจบางอย่างเปลี่ยนได้ในราคาถูก)

การเปลี่ยนสิ่งที่มีอยู่แล้ว (สนับสนุน DM-1 และ SDM-2)

• ฉันรู้ว่าทำไมการเปลี่ยนประเภทของฟิลด์ หรือการทำให้ฟิลด์ที่มีอยู่เป็น Required จึงทำให้ระบบพังในภายหลังได้ และทำไมแพลตฟอร์มจึงบล็อกการเปลี่ยนประเภทขณะที่โค้ดหรือ Flow อ้างถึงฟิลด์อยู่ (ระวังการเปลี่ยนโครงกระดูก)
• ฉันรู้รูปแบบ เพิ่มแทนการแก้ไข เลิกใช้แทนการทำให้ตกใจ และรู้ว่า Field Usage ทำเครื่องหมายฟิลด์ว่าเป็นผู้สมัครเลิกใช้ได้ (ระวังการเปลี่ยนโครงกระดูก)
• ฉันรู้ข้อเท็จจริงของ master-detail ที่อยู่เบื้องหลังการทดสอบความย้อนกลับได้: การเข้าถึงและความเป็นเจ้าของของ detail ตาม master การลบ master จะลบ detail ของมัน ฟิลด์สรุปยอดต้องใช้ master-detail และ lookup จะแปลงเป็น master-detail ได้ก็ต่อเมื่อทุกเรกคอร์ดมีค่า (การทดสอบความย้อนกลับได้ ศึกษาเพิ่มเติม)

สิทธิ์การใช้งานและการแชร์ (สนับสนุน SDM-1)

• ฉันรู้ว่าผู้ใช้ community แบบปริมาณสูง (รวมถึง Customer Community) ไม่มีบทบาทและไม่ใช้โมเดลการแชร์ การเข้าถึงจึงมาจาก sharing set และ share group และ Apex sharing เข้าไม่ถึงพวกเขา (ตัวอย่างจริง: Apex sharing)

ความล้มเหลว (สนับสนุน MIG-1 และบทเรื่องการผสานรวม)

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

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

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

• ต้องมีใครสักคนถือพิมพ์เขียว สถาปัตยกรรมคือการตัดสินใจที่ดีด้วยข้อมูลที่ไม่ครบถ้วน และรู้ผลที่ตามมา
• โมเดลข้อมูลคือโครงกระดูก ทุกอย่างสร้างอยู่บนมัน
• การทดสอบความย้อนกลับได้: สิ่งนี้ย้อนกลับยากแค่ไหน และจะมีสิ่งต่างๆ พึ่งพามันมากเพียงใด?
• สถาปัตยกรรมสร้างแรงโน้มถ่วง การพึ่งพาทำให้การเปลี่ยนแปลงมีราคาแพง ไม่ใช่ตัวการเปลี่ยนแปลงเอง
• คิดถึงรัศมีผลกระทบ ทั้งภายใน Salesforce และทั่วทั้งองค์กร สถาปัตยกรรมคือการจราจรสองทาง
• จดบันทึกว่าทำไม: บริบท ทางเลือก การตัดสินใจ ผลที่ตามมา เจ้าของ การทบทวน แทนที่ อย่าลบ
• ดีที่สุดในเรื่องอะไร? การตัดสินใจที่ไม่ดีที่สุดอาจเป็นส่วนหนึ่งของสถาปัตยกรรมที่ดีที่สุด ถ้าคุณรู้ว่ากำลังทำมัน
• มีภาพของความเหมาะที่สุดไว้ในหัว เพื่อให้รู้ว่ากำลังขยับออกจากมันไปทางไหน และทำไม
• Think Correct. Think Fast. ความเร็วมาจากการคิดที่ทำไว้ก่อนช่วงเวลานั้น
• สร้างเพื่อวันนี้ วางแผนเพื่อพรุ่งนี้ วางแผนรับความล้มเหลว และใช้การเติบโต 30 เปอร์เซ็นต์เมื่อไม่มีใครให้ตัวเลขคุณ
• เรียนรู้คำถามเก้าข้อ ไม่ใช่แค่คำตอบ
• AI คือจรวดเสริมแรงขับ การสร้างไม่ใช่วิจารณญาณ สิ่งที่ย้อนกลับไม่ได้ก็ยังย้อนกลับไม่ได้ และการรีวิวโดยมนุษย์ไม่ใช่พิธีกรรม เชื่อใจแต่ตรวจสอบ

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

คำศัพท์	ในหนึ่งบรรทัด
การตัดสินใจเชิงสถาปัตยกรรม	การตัดสินใจที่ย้อนกลับได้ยาก และมีสิ่งต่างๆ พึ่งพามันมาก
การทดสอบความย้อนกลับได้	สิ่งนี้ย้อนกลับยากแค่ไหน และจะมีสิ่งต่างๆ พึ่งพามันมากเพียงใด?
แรงโน้มถ่วง	การพึ่งพาที่สะสมรอบการตัดสินใจหนึ่งเมื่อเวลาผ่านไป
รัศมีผลกระทบ	ทุกสิ่งอื่นที่ขยับตามเมื่อการตัดสินใจหนึ่งเปลี่ยน
บันทึกการตัดสินใจ	บริบท ทางเลือก การตัดสินใจ ผลที่ตามมา เจ้าของ และจุดทบทวน ทำให้สั้นกระชับ
การแลกเปลี่ยนได้เสีย	สิ่งที่ทางเลือกหนึ่งได้ และสิ่งที่มันต้องสละไปเพื่อให้ได้มา
ความต้องการที่แฝงอยู่	สิ่งที่ธุรกิจคาดหวังโดยไม่ต้องขอ เช่น การกู้คืนเมื่อการโหลดล้มเหลว
จำนวนเลขศูนย์ของ Steve	เลขศูนย์เพิ่มอีกตัวในปริมาณข้อมูลเปลี่ยนสถาปัตยกรรมทั้งหมดได้
การกระทบยอด	การเปรียบเทียบสิ่งที่ควรเกิดขึ้นกับสิ่งที่เกิดขึ้นจริง ทีละเรกคอร์ด
การเลิกใช้ (deprecate)	ทำเครื่องหมายว่าสิ่งหนึ่งกำลังจะถูกปลดออก แล้วปลดระวางอย่างตั้งใจ แทนการเปลี่ยนในที่เดิม
ผู้ใช้ปริมาณสูง	ผู้ใช้ community (รวมถึงสิทธิ์ Customer Community) ที่ไม่มีบทบาท และอยู่นอกโมเดลการแชร์
สคีมาแผ่ขยาย	ออบเจกต์และฟิลด์ที่พอกพูนขึ้นเพราะสร้างได้ง่าย จนไม่มีใครออกแบบโมเดลอีกต่อไป

ทดสอบตัวเอง

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

1. ทีมขายขอฟิลด์ Approver 2 และ Approver 3 พร้อมวันที่บนโอกาสทางการขาย คุณจะถามอะไร และอาจสร้างอะไร?

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

2. คนหนึ่งอยากเปลี่ยนป้ายชื่อฟิลด์ อีกคนอยากเปลี่ยนรูปแบบของตัวระบุลูกค้าที่ห้าระบบเก็บไว้แล้ว เรื่องไหนควรได้รับความใส่ใจจากคุณมากกว่า และทำไม?

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

3. ฟิลด์ข้อความถูกใช้งานมาหลายปี ตอนนี้ฝ่ายธุรกิจอยากให้มันเก็บตัวเลข คุณจะทำอย่างไร?

อย่าแก้ไขมันในที่เดิม หาว่าอะไรพึ่งพามันอยู่ (Flow, Apex, รายงาน, การผสานรวม, เอเจนต์) และข้อมูลเก่าจะเป็นอย่างไร ปกติคือ: เพิ่มฟิลด์ใหม่ ย้ายข้อมูลอย่างตั้งใจ และเลิกใช้ฟิลด์เดิม อ่านทวน ระวังการเปลี่ยนโครงกระดูก

4. สถานที่ 1,200 แห่ง แห่งละ 100 นัดหมายต่อวัน ประมาณ 305 วันต่อปี สองเรกคอร์ดต่อนัดหมาย เก็บห้าปี เติบโต 30 เปอร์เซ็นต์ ประมาณกี่เรกคอร์ด และทำไมจึงสำคัญ?

ราว 73 ล้านเรกคอร์ดในปีแรก (36.6 ล้านนัดหมาย นัดหมายละสองเรกคอร์ด) และเกิน 650 ล้านในห้าปีเมื่อรวมการเติบโต ฟีเจอร์เดิม เลขศูนย์เพิ่มอีกสองสามตัว สถาปัตยกรรมที่ต่างไปมาก อ่านทวน รู้จักตัวเลขของคุณ

5. การโหลดตอนกลางคืนรายงานว่า “เสร็จสมบูรณ์” สำหรับหนึ่งล้านเรกคอร์ด คุณจะรู้ได้อย่างไรว่ามันได้ผล?

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

6. community ที่มีผู้ใช้ Customer Community 15 ล้านคนต้องการการเข้าถึงเรกคอร์ดที่ซับซ้อน มีคนเสนอ Apex sharing ปัญหาคืออะไร?

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

7. เครื่องมือ AI สร้างออบเจกต์ยี่สิบตัวสำหรับแอปใหม่ภายในไม่กี่นาที ตอนนี้งานของสถาปนิกคืออะไร?

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

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

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