สถาปัตยกรรมข้อมูล 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 ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ

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

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

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

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

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

DM-1: การออกแบบโมเดลข้อมูลบนแพลตฟอร์ม

• ฉันรู้ว่า Salesforce เป็นแพลตฟอร์ม ที่ขับเคลื่อนด้วยเมทาดาทาและเป็นแบบ multitenant: ออบเจกต์คือเมทาดาทา ไม่ใช่ตารางใหม่ และทุกออบเจกต์ได้ API ของมันทันทีที่มันมีอยู่ (เมทาดาทาคือพิมพ์เขียว, API ของคุณมาพร้อมกับออบเจกต์)
• ฉันรู้ว่า governor limits มีไว้เพื่อไม่ให้ผู้เช่ารายเดียวยึดทรัพยากรที่ใช้ร่วมกัน (คุณยึดลิฟต์ไม่ได้)
• ฉันอ่านโมเดลข้อมูลมาตรฐานได้: การแปลงลูกค้าเป้าหมายเป็นบัญชี ผู้ติดต่อ และโอกาสทางการขาย Opportunity Product ชี้ไปที่ Price Book Entry ซึ่งชี้ไปที่ Product2 และเคส สินทรัพย์ และ Entitlement ในฝั่งบริการ (โมเดลการขาย, โมเดลการบริการ)
• ฉันรู้ว่าหน้าจอ New Custom Object ตัดสินอะไรบ้าง: ชื่อเรกคอร์ดแบบ Text หรือ Auto Number, Object Classification (เปิด sharing, Bulk API และ Streaming API คือออบเจกต์ Enterprise Application ปิดคือออบเจกต์ Light Application) และ Allow Search ซึ่งปิดไว้โดยค่าเริ่มต้น (หน้าจอ New Custom Object)
• ฉันอ่าน API name ได้: ออบเจกต์และฟิลด์มาตรฐานไม่มีคำนำหน้าหรือคำต่อท้าย ออบเจกต์และฟิลด์ที่กำหนดเองลงท้ายด้วย __c แพ็กเกจแบบ managed เพิ่มคำนำหน้า namespace (abc__) และฟิลด์ที่คุณเพิ่มให้ออบเจกต์ของแพ็กเกจจะได้ __c แต่ไม่มีวันได้คำนำหน้าของผู้ขาย (คำนำหน้าและคำต่อท้าย)
• ฉันใช้บททดสอบความเข้ากันอย่างพอดีกับออบเจกต์มาตรฐานได้ และรู้ว่าเมื่อไรความหมายหรือน้ำหนักชี้ไปที่ออบเจกต์ที่กำหนดเอง (บททดสอบความเข้ากันอย่างพอดี)
• ฉันรู้ว่าสินทรัพย์ (Asset) และบัญชีบุคคลมีไว้เพื่ออะไร บัญชีบุคคลใช้พื้นที่จัดเก็บราวสองเท่าของบัญชีธุรกิจ และเมื่อเปิดใช้บัญชีบุคคลแล้วปิดไม่ได้ (สินทรัพย์เป็นตัวอย่างที่ดี, บัญชีบุคคล, เมื่อไรที่คนคือบัญชี?)
• ฉันเลือกประเภทฟิลด์ตามพฤติกรรมที่ต้องการ (หมายเลขรถไม่ใช่ Number) และรู้ว่า date/time ถูกเก็บเป็น GMT และแสดงตามเขตเวลาของผู้อ่านแต่ละคน จึงต้องเปรียบเทียบด้วยช่วง ไม่ใช่ด้วยการเท่ากัน (ตัวเลขไม่ได้เป็นตัวเลขเสมอไป, Date, Date/Time และ Time)
• ฉันรู้ว่าข้อความมีสองแบบ: ไม่เกิน 255 อักขระอยู่บนเรกคอร์ด (ทำดัชนีได้ ใช้เป็นค่าไม่ซ้ำหรือ External ID ได้) และ Long หรือ Rich text ที่เกินกว่านั้น ซึ่งไม่มีดัชนี กรองด้วย WHERE ไม่ได้ และใช้ในสูตรไม่ได้ (ตระกูลข้อความ)
• ฉันรู้ว่าเมื่อไรควรใช้ Name แบบ auto number และมันไม่ใช่ ID ของเรกคอร์ด (คนต้องระบุมันไหม?)
• ฉันรู้ว่า External ID ช่วยให้การผสานรวม upsert ได้อย่างไร และโหลดลูกด้วย External ID ของแม่ได้ (External ID)
• ฉันรู้ว่าเมื่อไรค่าหนึ่งควรคำนวณด้วยสูตร และเมื่อไรมันเป็นข้อเท็จจริงในอดีตที่ต้องเก็บไว้ (เก็บไว้หรือคำนวณ?)
• ฉันรู้ความต่างระหว่างออบเจกต์เชื่อมเชิงตรรกะ (logical junction object) (แนวคิดการสร้างโมเดล: ออบเจกต์ที่เชื่อมอีกสองตัวในความสัมพันธ์หลายต่อหลาย และมีแอตทริบิวต์ของตัวเอง) กับ Junction Object ของ Salesforce (ออบเจกต์ที่กำหนดเองที่มีความสัมพันธ์ master-detail สองชุด) และรู้ว่า Salesforce หมายถึงแบบหลัง (กว้างสองแม่)
• ฉันรู้จักความสัมพันธ์แบบ hierarchical: lookup แบบพิเศษที่มีเฉพาะบนออบเจกต์ User เช่นฟิลด์มาตรฐาน Manager ซึ่งวนกลับมาที่ผู้ใช้คนเดิมไม่ได้ทั้งโดยตรงและโดยอ้อม และไม่ใช่ลำดับชั้นบทบาท (Hierarchical)
• ฉันรู้ความต่างระหว่าง lookup กับ master-detail: ความเป็นเจ้าของ การแชร์ แม่ที่บังคับ การลบแบบต่อเนื่อง ฟิลด์สรุปยอด (Lookup, Master-Detail)
• ฉันรู้ว่า master-detail สร้างบนออบเจกต์ที่มีข้อมูลอยู่แล้วไม่ได้ (สร้าง lookup เติมค่า แล้วแปลง) จะกลับไปเป็น lookup ได้เมื่อไม่มี roll-up บน master เท่านั้น และต้องเปิด Allow reparenting เพื่อย้ายลูก (ลูกเปลี่ยนแม่ได้ไหม?)
• ฉันรู้รูปร่างของแพลตฟอร์มสำหรับ master-detail: ลึกได้ถึงสามชั้น detail ที่กำหนดเอง (lookup ตัดสายโซ่ได้ทุกจุด) และกว้างสองแม่แบบ master-detail ใน Junction Object ของ Salesforce master-detail ที่สร้างก่อนคือตัวหลัก (เจ้าของ หน้าตา division) ตัวที่สองคือตัวรอง และสิทธิ์เข้าถึงต้องผ่านแม่ทั้งสอง: ตัวที่เข้มงวดที่สุดชนะ (ลึกสามชั้น, กว้างสองแม่)
• ฉันรู้ทางเลือกสามทางของ lookup เมื่อแม่ถูกลบ: ล้างค่าฟิลด์ (ค่าเริ่มต้น) ห้ามลบ หรือลบแบบต่อเนื่อง ซึ่งปิดไว้จนกว่า Salesforce จะเปิดให้ และข้ามการแชร์ (Lookup)
• ฉันรู้ว่าความสัมพันธ์กับตัวเองต้องเป็น lookup และรู้จักสองแบบที่มีมาในตัว: Parent Account ของบัญชี และ Parent Case ของเคส (ความสัมพันธ์กับตัวเอง)
• ฉันรู้ว่าการคำนวณ roll-up ใหม่อาจใช้เวลา roll-up ใช้สูตรที่มี NOW(), TODAY() หรือการอ้างอิงข้ามออบเจกต์ไม่ได้ และไม่ควรเลือก master-detail เพียงเพื่อให้ได้ roll-up: ทางเลือกคือฟิลด์ที่เก็บค่าไว้และมี flow หรือ trigger คอยทำให้เป็นปัจจุบัน (roll-up มีประโยชน์ แต่ไม่ได้ฟรี)
• ฉันรู้ขีดจำกัดความสัมพันธ์ที่โมดูลอ้างถึง: master-detail สองตัวต่อออบเจกต์ ฟิลด์ความสัมพันธ์ 40 ฟิลด์โดยค่าเริ่มต้น (สูงสุด 50) roll-up 25 ฟิลด์โดยค่าเริ่มต้น (สูงสุด 40) (ความสัมพันธ์ก็มีข้อจำกัด)

DM-2: โมเดลที่เคารพการแชร์และขยายขนาดได้

• ฉันรู้ว่าลูกแบบ master-detail ไม่มีเจ้าของและไม่มี share tableของตัวเอง: การเข้าถึงตาม master (ความเป็นเจ้าของติดมาด้วย)
• ฉันรู้จัก parent-child skew: แนวทางของ Salesforce คือไม่เกินราว 10,000 ลูกต่อแม่หนึ่งรายการ (คำถามเรื่องลูก 10,000 รายการ)
• ฉันรู้จัก ownership skew (ผู้ใช้คนเดียวเป็นเจ้าของเกิน 10,000 เรกคอร์ดของออบเจกต์หนึ่ง) และแนวทาง: กระจายความเป็นเจ้าของ หรือเก็บผู้ใช้นั้นไว้นอกลำดับชั้นบทบาทหรืออยู่ลำพังที่ด้านบนสุด และนอกกลุ่มสาธารณะที่กฎการแชร์ใช้ (ความเป็นเจ้าของกลายเป็นปัญหาด้านขนาดได้)
• ฉันรู้จัก share table: share object ของออบเจกต์ที่กำหนดเองคือ Object__Share ออบเจกต์ detail ไม่มี สิทธิ์เข้าถึงของมันมาจาก master และการเปลี่ยนเจ้าของจะลบการแชร์ด้วยตนเอง แต่เก็บการแชร์ด้วย Apex ที่มีเหตุผลของตัวเองไว้ (Share Table)
• ฉันตัดสินได้ว่าใครเป็นเจ้าของเรกคอร์ดที่การผสานรวมและเอเจนต์สร้าง โดยดูว่าความเป็นเจ้าของขับเคลื่อนการแชร์หรือไม่ (ใครเป็นเจ้าของเรกคอร์ดที่ระบบสร้าง?)

DM-4: big object เทียบกับออบเจกต์มาตรฐานและที่กำหนดเอง

• ฉันรู้จักบ้านสามแห่งของข้อมูล: บน core (sObject ใช้งานทุกวัน) อ้างอิง (ระบบอื่นเป็นแหล่งความจริง: ออบเจกต์ภายนอกของ Salesforce Connect __x หรือการเรียกแบบกำหนดเอง) และเก็บถาวร (บน core ใน big object __b หรือนอก core ในคลังข้อมูล) (บน core และนอก core)
• ฉันรู้ว่าออบเจกต์ภายนอกทำ callout ทุกครั้งที่ถูกแตะ ความหน่วงและความพร้อมใช้งานของระบบต้นทางจึงสำคัญ (อ้างอิง)
• ฉันรู้จัก big object: ปริมาณมหาศาล query ผ่านดัชนีด้วยการจับคู่ตรงตัวหรือช่วง ไม่มี UI หรือรายงานมาตรฐาน สิทธิ์ระดับออบเจกต์และฟิลด์เท่านั้น ไม่มีระบบอัตโนมัติ (เก็บถาวร)
• ฉันรู้ว่าเรกคอร์ดส่วนใหญ่นับเป็นพื้นที่จัดเก็บข้อมูลราว 2 KB ไม่ว่าจะมีฟิลด์เท่าไร และไฟล์คิดแยกในพื้นที่จัดเก็บไฟล์ (สองคอลัมน์หรือสองร้อย, ไฟล์และไฟล์แนบ)

SDM-1: ไลเซนส์และออบเจกต์ที่คนใช้ได้

• ฉันรู้จักไลเซนส์ภายในสามแบบ Sales Cloud, Service Cloud และ Platform และแต่ละแบบใช้อะไรได้บ้าง (สิทธิ์การใช้งานภายในสามแบบ)
• ฉันรู้ว่าไลเซนส์เป็นส่วนหนึ่งของโมเดลข้อมูล: ผู้ใช้ Salesforce Platform ไม่ได้ Leads, Campaigns, Opportunities หรือ Forecasts และผู้ใช้ Customer Community ใช้ Opportunity ไม่ได้ (ทีนี้ขอทำให้ทุกอย่างซับซ้อนขึ้น: สิทธิ์การใช้งาน)
• ฉันรู้ระดับไลเซนส์ภายนอก: Customer Community, Customer Community Plus (รายงาน แดชบอร์ด การแชร์มาตรฐาน), Partner Community (ออบเจกต์ด้านการขาย) และ Partner Community ใช้กับบัญชีบุคคลไม่ได้ (สนามกีฬา)
• ฉันรู้ความต่างระหว่างไลเซนส์แบบ member-based กับ login-based และแต่ละแบบเหมาะกับกลุ่มผู้ใช้แบบไหน (วิธีที่พวกเขาจ่ายเงินเปลี่ยนการออกแบบ)
• ฉันรู้ว่าไลเซนส์แพลตฟอร์มบางตัวจำกัดผู้ใช้ไว้ที่แอปเดียวที่มีออบเจกต์ที่กำหนดเองไม่เกินสิบตัว และรู้รูปแบบการใช้ประเภทเรกคอร์ดเพื่อทำงานภายในข้อจำกัดนั้น (เมื่อสิทธิ์การใช้งานกำหนดรูปโมเดล)
• ฉันรู้ว่าไลเซนส์ Salesforce Integration มีไว้สำหรับผู้ใช้แบบระบบต่อระบบที่ใช้ API เท่านั้น (คนไม่ใช่ผู้ใช้เพียงกลุ่มเดียวอีกต่อไป)
• ฉันรู้ว่าการรายงาน SLA ต้องใช้ entitlements และ milestones ซึ่งต้องใช้ไลเซนส์ Service (ทีนี้ขอทำให้ทุกอย่างซับซ้อนขึ้น: สิทธิ์การใช้งาน)

SDM-2: การรักษาข้อมูลให้สอดคล้องกัน

• ฉันวางกฎบนขั้นที่ถูกต้องของบันไดความสอดคล้องได้: ประเภทฟิลด์และคำศัพท์ Required และ Unique กฎการตรวจสอบความถูกต้อง กฎข้อมูลซ้ำ ระบบอัตโนมัติ (รักษาข้อมูลให้สอดคล้องกัน)
• ฉันรู้ว่า picklist แบบจำกัดค่าปฏิเสธค่าที่ไม่อยู่ในรายการ แม้ผ่าน API และชุดค่าส่วนกลาง (global value set) แชร์รายการเดียวข้ามฟิลด์ (สูงสุด 1,000 ค่า) (ขั้นที่หนึ่ง)
• ฉันรู้ว่าข้อกำหนดบน page layout ปกป้องแค่หน้าจอนั้น ไม่ใช่ข้อมูล และกฎการตรวจสอบความถูกต้องทำงานทุกครั้งที่บันทึก (การตรวจสอบใน UI ไม่ใช่การตรวจสอบข้อมูล, ขั้นที่สาม)
• ฉันจำกัดขอบเขตกฎการตรวจสอบความถูกต้องด้วย ISNEW() และ ISCHANGED() custom permission หรือวันที่เริ่มใช้งานได้ โดยรู้ว่าแต่ละทางเลือกยังตรวจการบันทึกแบบไหนบ้าง (รวมถึงการบันทึกที่ฉันไม่ได้ควบคุม เช่นการเปลี่ยนเจ้าของแบบ batch หรือ roll-up) (ปัญหาเรกคอร์ดเก่า)
• ฉันรู้จักกฎการจับคู่และกฎข้อมูลซ้ำ ขีดจำกัดที่โมดูลอ้างถึง (กฎข้อมูลซ้ำที่ใช้งานได้ห้ากฎต่อออบเจกต์ กฎการจับคู่สามกฎในแต่ละกฎ) และรู้ว่ามันไม่ได้แก้ปัญหาตัวตนข้ามระบบ (ขั้นที่สี่: กฎข้อมูลซ้ำ)
• ฉันรู้ว่ากฎข้อมูลซ้ำไม่เปรียบเทียบเรกคอร์ดที่บันทึกในจังหวะเดียวกัน การบันทึกผ่าน API และการนำเข้าถูกบล็อกโดยไม่มีการแจ้งเตือน และการบันทึกกับทุกอย่างที่มันกระตุ้นย้อนกลับเป็นธุรกรรมเดียว (ขั้นที่สี่, ทั้งหมดหรือไม่มีเลย)
• ฉันรู้ว่า Workflow Rules และ Process Builder หมดการสนับสนุนแล้ว ระบบอัตโนมัติหมายถึง Flow หรือ Apex (ขั้นที่ห้า: ระบบอัตโนมัติ)

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

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

• แพลตฟอร์มมีรูปร่างของมัน ออกแบบสำหรับแพลตฟอร์มที่คุณใช้อยู่ ไม่ใช่ฐานข้อมูลทั่วไป
• มองไปที่ยานแม่ ดูว่า Salesforce สร้างโมเดลของแนวคิดหนึ่งอย่างไรก่อนคุณจะประดิษฐ์ขึ้นเอง
• ทุกออบเจกต์คือพันธะ: พื้นที่จัดเก็บ ขีดจำกัด โมเดลการแชร์ ไลเซนส์ และการพึ่งพา
• ถามว่าข้อมูลอยู่ที่ไหนก่อนเลือกออบเจกต์: บน core อ้างอิง หรือเก็บถาวร
• อ่าน API name ใดก็ได้แล้วคุณจะรู้ว่าใครสร้างมัน และคุณเปลี่ยนอะไรได้บ้าง
• ถ้าคุณไม่เก็บถาวรวันนี้ คุณจะได้เก็บถาวรไหม?
• ทำต้นแบบ big object ก่อนเสนอมัน
• ชื่อทางธุรกิจที่ต่างกันไม่ได้แปลว่าต้องเป็นออบเจกต์ที่ต่างกันโดยอัตโนมัติ
• ถามว่าตัวตนใดบ้างที่ต้องใช้ข้อมูล: คน ลูกค้า พันธมิตร การผสานรวม และเอเจนต์
• ทุกฟิลด์ต้องมีคำอธิบาย และการจัดประเภทในที่ที่สำคัญ
• อธิบายพฤติกรรมของความสัมพันธ์ก่อน แล้วการตั้งค่าค่อย implement มัน อย่าบิดโมเดลเพื่อให้ได้ฟีเจอร์
• คำถามเรื่องการลบ: ลูกควรเป็นอย่างไรถ้ามีคนลบแม่?
• เลือกว่าลิงก์ไหนจะตัดสายโซ่: ให้ lookup อยู่ตรงที่ลูกมีชีวิตของตัวเองจริงๆ
• ความเป็นเจ้าของมาจากตัวหลัก สิทธิ์เข้าถึงมาจากทั้งสองตัว: ตัวที่เข้มงวดที่สุดชนะ
• แยกไม่ใช้งานออกจากหายไป และทำให้การเก็บรักษาเป็นกฎทางธุรกิจ
• ดันกฎลงไปให้ต่ำเท่าที่มันควรอยู่อย่างถูกต้อง และให้ประวัติที่ถูกต้องมีทางเลี่ยงแทนการเขียนใหม่
• ไดอะแกรมไม่ใช่สถาปัตยกรรม ต้องสืบทุกโครงสร้างย้อนกลับไปหาเหตุผลทางธุรกิจได้

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

คำศัพท์	ในหนึ่งบรรทัด
ขับเคลื่อนด้วยเมทาดาทา (metadata-driven)	ออบเจกต์และฟิลด์คือคำนิยามที่แพลตฟอร์มอ่านขณะทำงาน ไม่ใช่ตารางกายภาพใหม่
Multitenancy	หลาย org ใช้โครงสร้างพื้นฐานร่วมกัน แต่ละ org แยกจากกัน เหมือนห้องในอาคารอพาร์ตเมนต์เดียวกัน
Governor limits	ขีดจำกัดที่กันไม่ให้ผู้เช่ารายเดียวผูกขาดทรัพยากรที่ใช้ร่วมกัน
External object	ข้อมูลที่แสดงใน Salesforce ผ่าน Salesforce Connect ดึงจากต้นทางทุกครั้งที่ถูกแตะ
Big object	ที่เก็บข้อมูลขนาดใหญ่มากที่ใช้ไม่บ่อย query ผ่านดัชนีของมัน
บัญชีบุคคล (person account)	บุคคลที่แทนด้วยบัญชี สำหรับโมเดลธุรกิจกับผู้บริโภค
ความเข้ากันอย่างพอดี (clean fit)	แนวคิดทางธุรกิจที่ตรงกับจุดประสงค์ของออบเจกต์มาตรฐาน
External ID	ฟิลด์ที่เก็บตัวระบุของระบบอื่น ใช้สำหรับ upsert และการจับคู่
Upsert	อัปเดตเรกคอร์ดถ้ามีอยู่ สร้างใหม่ถ้ายังไม่มี
Lookup	ความสัมพันธ์ที่ลูกมีเจ้าของและชีวิตของตัวเอง
Master-detail	ความสัมพันธ์ที่ลูกเป็นของแม่: สืบทอดเจ้าของและการแชร์ ลบต่อเนื่อง roll-up
ออบเจกต์เชื่อมเชิงตรรกะ (logical junction object)	แนวคิดการสร้างโมเดล: ออบเจกต์ที่เชื่อมอีกสองตัวในความสัมพันธ์หลายต่อหลายและมีแอตทริบิวต์ของตัวเอง ไม่ว่าจะสร้างแบบไหน
Junction Object ของ Salesforce	สิ่งที่ Salesforce หมายถึงเมื่อพูดว่า “junction object”: ออบเจกต์ที่กำหนดเองที่มีความสัมพันธ์ master-detail สองชุด
master ตัวหลักและตัวรอง (primary / secondary master)	master-detail ที่สร้างก่อนของ Junction Object ของ Salesforce (เจ้าของ หน้าตา division) และตัวที่สอง (ขอบเขตรายงาน กลายเป็นตัวหลักถ้าตัวแรกถูกลบ)
ความสัมพันธ์แบบ hierarchical	lookup แบบพิเศษที่มีเฉพาะบนออบเจกต์ User เช่น Manager ซึ่งวนกลับมาที่ผู้ใช้คนเดิมไม่ได้
คำนำหน้า namespace (namespace prefix)	คำนำหน้าของผู้ขายบนออบเจกต์และฟิลด์ของแพ็กเกจแบบ managed เช่น abc__Inspection__c
Share table	share object (AccountShare, Truck__Share) ที่เก็บการแชร์ส่วนใหญ่ของเรกคอร์ด หนึ่งแถวต่อผู้ใช้หรือกลุ่ม พร้อมเหตุผล
ฟิลด์สรุปยอด (roll-up summary)	ฟิลด์บน master ที่นับ รวม หรือหาค่าต่ำสุดหรือสูงสุดของ detail
ข้อมูลกระจุกตัว (data skew)	เรกคอร์ดมากเกินไปภายใต้แม่เดียวหรือเจ้าของคนเดียว ทำให้เกิดการล็อกและการคำนวณการแชร์ใหม่ที่ใช้เวลานาน
Member-based / login-based	จ่ายต่อผู้ใช้ภายนอก หรือต่อการล็อกอินในแต่ละเดือน
บันไดความสอดคล้อง	ชั้นที่บังคับใช้กฎข้อมูล ตั้งแต่ประเภทฟิลด์ขึ้นไปจนถึงระบบอัตโนมัติ
picklist แบบจำกัดค่า (restricted picklist)	picklist ที่ปฏิเสธค่าใดก็ตามที่ไม่อยู่ในรายการ จากทุกแหล่ง
การจัดประเภทข้อมูล	เมทาดาทาของฟิลด์สำหรับเจ้าของ การใช้งาน ระดับความอ่อนไหว และหมวดการปฏิบัติตามกฎ

ทดสอบตัวเอง

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

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

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

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

ไม่ ทั้งหมดเป็นบริษัท บัญชีจึงเข้ากันพอดี ชื่อที่ต่างกันคือบทบาท ซึ่งแสดงด้วยประเภท ประเภทเรกคอร์ด หรือความสัมพันธ์ อ่านทวน บททดสอบความเข้ากันอย่างพอดี

3. การออกแบบใช้ Opportunity แต่คนส่วนใหญ่ที่ต้องใช้ข้อมูลมีไลเซนส์ Salesforce Platform หรือ Customer Community แล้วยังไงต่อ?

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

4. ERP ส่งการอัปเดตบัญชีทุกคืน การผสานรวมควรหาเรกคอร์ดที่ถูกต้องอย่างไรโดยไม่ต้อง query หา Salesforce ID?

เก็บหมายเลขลูกค้าของ ERP ไว้ในฟิลด์ External ID แล้ว upsert ด้วยมัน: อัปเดตถ้าพบ สร้างถ้าไม่พบ เรกคอร์ดลูกก็ชี้ไปที่แม่ด้วย External ID ของแม่ได้เช่นกัน อ่านทวน External ID

5. รายการจัดส่งอยู่ไม่ได้ถ้าไม่มีการจัดส่งของมัน ไม่เคยย้าย และไม่ต้องมีเจ้าของของตัวเอง การจัดส่งมีอยู่ก่อนถูกจัดเส้นทาง และย้ายไปเส้นทางอื่นได้ แต่ละคู่ควรใช้ความสัมพันธ์แบบไหน?

รายการจัดส่งกับการจัดส่ง: master-detail (เป็นของแม่ตลอดชีวิต สืบทอดการเข้าถึง ลบแบบต่อเนื่อง) การจัดส่งกับเส้นทาง: lookup (มีชีวิตของตัวเอง ไม่บังคับในตอนแรก ย้ายได้ และการลบเส้นทางต้องไม่ลบการจัดส่งเด็ดขาด) อ่านทวน เริ่มจากความสัมพันธ์ทางธุรกิจ

6. การผสานรวมสร้างการจัดส่ง 3,300 รายการต่อวัน ทั้งหมดเป็นของผู้ใช้การผสานรวม ซึ่งมีบทบาทอยู่กลางลำดับชั้น ความเสี่ยงคืออะไร และแก้อย่างไร?

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

7. คุณเพิ่มกฎการตรวจสอบความถูกต้อง และเรกคอร์ดเก่า 20,000 รายการฝ่าฝืนมัน ผู้ใช้แก้เบอร์โทรศัพท์ในเรกคอร์ดหนึ่งแล้วบันทึกไม่ผ่าน กฎควรทำอย่างไร?

บอกว่าเมื่อไรจะบังคับใช้ ไม่ใช่แค่อะไรต้องเป็นจริง: จำกัดขอบเขตด้วย ISNEW() หรือ ISCHANGED() บนฟิลด์ที่เกี่ยวข้อง และให้เรกคอร์ดที่มีอยู่ก่อนกฎมีทางเลี่ยงที่ตั้งใจ แทนการเขียนประวัติของมันใหม่ อ่านทวน ปัญหาเรกคอร์ดเก่า

8. ธุรกิจต้องการรูปถ่ายการจัดส่งทุกรูป “ใน Salesforce”: สี่ถึงห้าล้านรูปต่อปี เติบโต 30 เปอร์เซ็นต์ คุณเสนออะไร?

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

9. การมอบหมายทีมมีความสัมพันธ์ master-detail กับทีมจัดส่ง (สร้างก่อน) และรถบรรทุก ผู้จัดการเดินรถคนหนึ่งเห็นทีมจัดส่งได้แต่ไม่เห็นรถบรรทุก เขาเห็นการมอบหมายทีมได้ไหม?

ไม่ได้ ทีมจัดส่งเป็นตัวหลัก จึงให้เจ้าของและหน้าตาแก่การมอบหมาย แต่สิทธิ์เข้าถึงต้องผ่านแม่ทั้งสอง: ผู้จัดการเดินรถต้องมีสิทธิ์เข้าถึงทีมจัดส่งและรถบรรทุก ในระดับที่ Sharing Setting ของฟิลด์ master-detail แต่ละฟิลด์กำหนด ตัวที่เข้มงวดที่สุดชนะ อ่านทวน กว้างสองแม่

10. พันธมิตรส่งไฟล์ใบรายการสินค้าซ้ำ และลูกค้าคนเดียวกันปรากฏในไฟล์สองครั้ง คุณมีกฎข้อมูลซ้ำบนบัญชีที่ตั้งให้บล็อก คุณปลอดภัยไหม?

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

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

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