การสร้างโมเดลข้อมูลเพื่อความหมาย
มีให้อ่านอีก 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)

คู่มือทบทวนสำหรับบทที่ 2 ของหลักสูตร Data Architect อ่านหกโมดูลก่อน หน้านี้ช่วยให้คุณตรวจสอบว่าอะไรติดอยู่ในหัวบ้าง
เกี่ยวกับคู่มือทบทวนนี้ คู่มือนี้สร้างขึ้นจากเนื้อหาของหลักสูตรนี้และรายการวัตถุประสงค์ในคู่มือการสอบที่ Salesforce เผยแพร่เท่านั้น ไม่เคยอิงจากข้อสอบจริง และไม่ได้อ้างว่ารู้ว่าข้อสอบมีอะไร ถ้าคุณเคยสอบแล้ว ได้โปรดอย่าส่งข้อสอบมาให้ผม: ข้อตกลงการรับรองห้ามแชร์ข้อสอบ และการท่องจำคำตอบก็เป็นวิธีที่ผิดในการเป็นสถาปนิกอยู่ดี
บทนี้เป็นรากฐานของส่วน Data Modeling and Database Design ในการสอบ ซึ่งคิดเป็นหนึ่งในสี่ของข้อสอบ บทนี้ครอบคลุมวิธีคิด ส่วนบทถัดไป สถาปัตยกรรมข้อมูล Salesforce ครอบคลุมวิธีที่แพลตฟอร์มสร้างมัน ดังนั้นสิ่งที่ถูกทดสอบเรื่องออบเจกต์ ฟิลด์ และความสัมพันธ์ส่วนใหญ่ต้องใช้ทั้งสองบท
สำหรับการสอบ
หัวข้อที่มีชื่อว่า “สำหรับการสอบ ”ประเด็นจากบทนี้ที่น่าจะสำคัญที่สุดในการสอบ แต่ละข้อผูกกับวัตถุประสงค์การสอบและลิงก์ไปยังส่วนที่สอนเรื่องนั้น ทำเครื่องหมายไปทีละข้อ
DM-1: เปรียบเทียบเทคนิคการออกแบบโมเดลข้อมูล Salesforce
- ฉันอธิบายความแตกต่างระหว่างโมเดลข้อมูลเชิงแนวคิด เชิงตรรกะ และเชิงกายภาพ และแต่ละแบบมีไว้เพื่ออะไรได้ (เปลี่ยนโมเดลให้เป็น Salesforce)
- ฉันหาเอนทิตีที่เป็นไปได้ในความต้องการได้ และแยกคนที่ทำงานหนึ่งออกจากชิ้นข้อมูลได้ (คำนามให้เอนทิตีที่เป็นไปได้)
- ฉันอ่านและวาดสัญลักษณ์ตีนกาได้: หนึ่ง หลาย และเครื่องหมายตัวที่สองสำหรับเป็นทางเลือกหรือบังคับ (อ่านเส้น, ความเป็นทางเลือกก็สำคัญ)
- ฉันระบุ cardinality ของความสัมพันธ์ได้: หนึ่งต่อหนึ่ง หนึ่งต่อหลาย หลายต่อหลาย (ถามว่า “หนึ่งหรือหลาย?”)
- ฉันรู้ว่าความสัมพันธ์แบบหลายต่อหลายกลายเป็นเอนทิตีของตัวเอง และใน Salesforce มักเป็น junction object ที่มีแม่สองตัว (ความสัมพันธ์กลายเป็นสิ่งหนึ่งได้)
- ฉันรู้ว่าเมื่อไรความสัมพันธ์ต้องมีประวัติ (เรกคอร์ดที่มีวันที่เริ่มต้นและสิ้นสุด) แทนที่จะเป็นฟิลด์ที่ถูกเขียนทับ (เวลาเปลี่ยนความสัมพันธ์)
- ฉันเลือก ID ที่ไม่ซ้ำที่ดีได้ และรู้ว่าทำไมคีย์ธรรมชาติหรือสิ่งใดที่มีข้อมูลส่วนบุคคลจึงมีความเสี่ยง (แล้วเราก็ต้องคุยเรื่อง ID ที่ไม่ซ้ำ)
- ฉันรู้ความแตกต่างระหว่างคีย์ธรรมชาติและคีย์ตัวแทน และรู้ว่าเรกคอร์ดหนึ่งมีตัวระบุภายนอกได้หลายตัว (คีย์ธรรมชาติและคีย์ตัวแทน)
- ฉันรู้ว่าฟิลด์ Auto Number เป็นหมายเลขที่อ่านง่าย ไม่ใช่ Salesforce ID ของเรกคอร์ด (ความสัมพันธ์พึ่งพา ID ที่ไม่ซ้ำ)
- ฉันใช้รูปแบบบรรทัดฐานที่หนึ่ง ที่สอง และที่สามได้ และมองออกเมื่อฟิลด์หนึ่งเก็บหลายค่าหรือเก็บข้อเท็จจริงซ้ำเกี่ยวกับสิ่งอื่น (วิธีง่ายๆ ในการคิดเรื่อง 1NF, 2NF และ 3NF)
- ฉันอธิบายได้ว่าเมื่อไรควรตั้งใจทำ denormalization (ผู้ใช้ การทำรายงาน ขนาด) และมันมีราคาเท่าไร (ออกแบบถึงรูปแบบบรรทัดฐานที่สาม แล้วถอยออกมา)
- ฉันตัดสินใจได้ระหว่าง picklist กับ lookup ไปยังออบเจกต์สำหรับรายการค่า (lookup หรือ picklist?)
- ฉันรู้ว่า custom report type รองรับความสัมพันธ์ระหว่างออบเจกต์ได้สูงสุดสี่ทอด และทำไมเรื่องนั้นจึงสำคัญกับโมเดลที่ลึก (lookup หรือ picklist?)
- ฉันรู้ว่าเมื่อไร master-detail เหมาะ (ลูกไม่มีวันถูกย้ายแม่) และเมื่อไร lookup ปลอดภัยกว่า รวมถึงแนวทางของ Salesforce ที่ไม่ให้มีลูกเกิน 10,000 รายการต่อแม่หนึ่งตัว (ความสัมพันธ์กลายเป็นการตัดสินใจเรื่องแพลตฟอร์ม)
- ฉันรู้ว่าทำไมควรหลีกเลี่ยงความสัมพันธ์แบบ polymorphic เมื่อทำได้ (ความสัมพันธ์กลายเป็นการตัดสินใจเรื่องแพลตฟอร์ม)
- ฉันรู้ว่าเอนทิตีทางธุรกิจไม่ได้แปลว่าออบเจกต์ที่กำหนดเองโดยอัตโนมัติ: มันอาจเป็นออบเจกต์มาตรฐาน ฟิลด์ การตั้งค่า หรือข้อมูลที่อยู่นอก Salesforce (เอนทิตีทางธุรกิจไม่ได้แปลว่าออบเจกต์ที่กำหนดเองโดยอัตโนมัติ)
นอกเหนือจากการสอบ
หัวข้อที่มีชื่อว่า “นอกเหนือจากการสอบ ”การสอบคือพื้น ไม่ใช่เพดาน นี่คือนิสัยจากบทนี้ที่สถาปนิกต้องมี ไม่ว่าจะมีคำถามข้อใดถามถึงหรือไม่
- ลืม Salesforce ไปสักครู่ สร้างโมเดลของธุรกิจก่อนแมปไปยังบัญชีและผู้ติดต่อ
- ฟังหาคำที่ซ่อนสองสิ่งไว้ ที่ Steve Trucking “ลูกค้า” คือพันธมิตรค้าปลีกและผู้รับ
- โมเดลเป็นส่วนหนึ่งของบทสนทนา โมเดลแรกของคุณไม่ได้มีไว้ให้ถูก แต่มีไว้ให้คุณเห็นว่าผิดตรงไหน
- ตั้งชื่อเส้น สองโมเดลที่มีกล่องเหมือนกันอาจหมายถึงต่างกัน
- ถามว่า “ตอนนี้ หรือตลอดช่วงเวลา?” กับทุกความสัมพันธ์
- ไม่ซ้ำ ไม่เปลี่ยน ไม่มีความหมาย ไม่ใช่ข้อมูลส่วนบุคคล
- วางข้อเท็จจริงในที่ที่ควรอยู่ แล้วตั้งใจถอยออกมา และจดบันทึกว่าทำไม
- denormalization ไม่ได้กำจัดความซับซ้อน แต่ย้ายมัน รู้ว่าใครเป็นเจ้าของความจริง
- ความจริงหนึ่งแหล่ง หลายรูป: หน้าจอ รายงาน คลังข้อมูล และ AI
- อย่าออกแบบจาก Setup วาดโมเดลก่อนคลิก New Custom Object
- สืบย้อนทุกการตัดสินใจเชิงกายภาพ กลับไปหาสิ่งที่ธุรกิจต้องการ
คำศัพท์ที่ควรรู้
หัวข้อที่มีชื่อว่า “คำศัพท์ที่ควรรู้ ”| คำศัพท์ | ในหนึ่งบรรทัด |
|---|---|
| เอนทิตี | สิ่งที่ธุรกิจใส่ใจและเก็บข้อมูลไว้ |
| เอนทิตีที่เป็นไปได้ | คำนามที่อาจกลายเป็นเอนทิตี เมื่อคุณถามถึงมันแล้ว |
| แอตทริบิวต์ | ข้อเท็จจริงที่อธิบายเอนทิตี |
| ความสัมพันธ์ | การที่สองเอนทิตีเชื่อมกัน ตั้งชื่อด้วยภาษาของธุรกิจ |
| Cardinality | สิ่งหนึ่งกี่อันสัมพันธ์กับอีกสิ่งกี่อัน |
| ความเป็นทางเลือก | ความสัมพันธ์บังคับ หรือเป็นศูนย์ได้ |
| ตีนกา (crow’s foot) | เครื่องหมายแทน “หลาย” ที่ปลายเส้น |
| Junction object | วิธีของ Salesforce ในการสร้างความสัมพันธ์แบบหลายต่อหลาย: ลูกของแม่ทั้งสอง |
| โมเดลเชิงแนวคิด | อะไรมีอยู่ในธุรกิจและสัมพันธ์กันอย่างไร ไม่มี Salesforce |
| โมเดลเชิงตรรกะ | ข้อมูล: แอตทริบิวต์ ID ที่ไม่ซ้ำ และความสัมพันธ์ ยังไม่ผูกกับแพลตฟอร์ม |
| โมเดลเชิงกายภาพ | แพลตฟอร์มจะสร้างมันอย่างไร: ออบเจกต์ ฟิลด์ และประเภทความสัมพันธ์ |
| คีย์ธรรมชาติ | ตัวระบุที่มีอยู่แล้วในธุรกิจ เช่น VIN ของรถบรรทุก |
| คีย์ตัวแทน | ตัวระบุที่สร้างขึ้นเพื่อระบุเรกคอร์ดเท่านั้น |
| ตัวระบุภายนอก | ID ของระบบอื่นสำหรับเรกคอร์ดเดียวกัน ที่เก็บและแมปไว้ |
| Normalization (1NF, 2NF, 3NF) | วางข้อเท็จจริงแต่ละข้อในที่ที่ควรอยู่: หนึ่งค่าต่อฟิลด์ ข้อเท็จจริงเกี่ยวกับคีย์ทั้งหมด ไม่มีข้อเท็จจริงเกี่ยวกับข้อเท็จจริงอื่น |
| Denormalization | ตั้งใจคัดลอกหรือทำให้ข้อมูลแบน ด้วยเหตุผลที่คุณระบุได้ |
| ความผิดปกติจากการอัปเดต | ข้อเท็จจริงเดียวกันถูกเก็บไว้หลายที่ การเปลี่ยนครั้งเดียวจึงทำให้บางสำเนาผิด |
ทดสอบตัวเอง
หัวข้อที่มีชื่อว่า “ทดสอบตัวเอง ”สถานการณ์สั้นๆ ในแบบของหลักสูตร ตัดสินคำตอบของคุณก่อนเปิดดู
1. ธุรกิจบอกคุณว่าทีมจัดส่งขับรถบรรทุก หกสัปดาห์ต่อมา มีคนถามว่าทีมไหนใช้รถคันที่ 117 ในวันหนึ่ง โมเดลควรมีอะไร?
การมอบหมายทีม: ความสัมพันธ์ระหว่างทีมกับรถบรรทุกเป็นเรกคอร์ดของตัวเอง พร้อมวันที่เริ่มต้น วันที่สิ้นสุด และเส้นทาง ทีมกับรถบรรทุกเป็นหลายต่อหลายเมื่อดูตลอดช่วงเวลา และธุรกิจสนใจประวัติ ฟิลด์บนรถบรรทุกจะถูกเขียนทับ อ่านทวน เวลาเปลี่ยนความสัมพันธ์
2. ทีมหนึ่งเสนอให้ใช้หมายเลขโทรศัพท์ของผู้รับแต่ละคนเป็น ID ที่ไม่ซ้ำ “เพราะมันไม่ซ้ำ” คุณจะพูดว่าอะไร?
มันไม่ผ่านบททดสอบ: หมายเลขโทรศัพท์เปลี่ยนและใช้ร่วมกันได้ จึงไม่คงที่และไม่ไม่ซ้ำอย่างเชื่อถือได้ และเป็นข้อมูลส่วนบุคคลที่จะถูกคัดลอกไปทุกระบบที่เชื่อมกับเรกคอร์ด ให้ใช้ ID ที่สร้างขึ้นและไม่มีความหมาย แล้วเก็บหมายเลขโทรศัพท์เป็นแอตทริบิวต์ อ่านทวน แล้วเราก็ต้องคุยเรื่อง ID ที่ไม่ซ้ำ
3. การจัดส่งมีฟิลด์ Item 1, Item 2 และ Item 3 แล้วมีการจัดส่งที่มีสินค้าสี่ชิ้นเข้ามา ปัญหาที่แท้จริงคืออะไร และแก้อย่างไร?
โมเดลซ่อนโครงสร้างที่ซ้ำไว้ในฟิลด์ (ปัญหารูปแบบบรรทัดฐานที่หนึ่ง) การแก้ไม่ใช่การเพิ่มฟิลด์ Item 4 แต่คือเอนทิตีรายการจัดส่ง ซึ่งเป็นลูกของการจัดส่ง เพื่อให้สินค้าทุกชิ้นเป็นเรกคอร์ด อ่านทวน รูปแบบบรรทัดฐานที่หนึ่ง
4. ทุกการจัดส่งเก็บชื่อผู้จัดการศูนย์กระจายสินค้าไว้ แล้วผู้จัดการเปลี่ยน อะไรผิดพลาด?
ข้อเท็จจริงเกี่ยวกับสิ่งอื่น (ศูนย์กระจายสินค้า) ถูกเก็บไว้บนการจัดส่ง: ปัญหารูปแบบบรรทัดฐานที่สาม และตอนนี้เป็นความผิดปกติจากการอัปเดตในเรกคอร์ดหลายร้อยรายการ ผู้จัดการควรอยู่กับศูนย์กระจายสินค้า และการจัดส่งชี้ไปที่ศูนย์กระจายสินค้า อ่านทวน รูปแบบบรรทัดฐานที่สาม
5. ประเภทของจุดแวะ (จัดส่งอย่างเดียว พร้อมติดตั้ง พร้อมขนของเก่าทิ้ง) ต้องมีระยะเวลา ทักษะของทีม และเช็กลิสต์ picklist หรือออบเจกต์?
ออบเจกต์ มันมีข้อมูลมากกว่าหนึ่งคอลัมน์ ธุรกิจเป็นผู้ดูแล และเปลี่ยนตามจังหวะของมันเอง สถานะของการจัดส่ง ซึ่งเป็นรายการป้ายชื่อสั้นๆ ที่คงที่ ยังคงเป็น picklist อ่านทวน lookup หรือ picklist?
6. พันธมิตรต้องการ scorecard การจัดส่งตรงเวลาแยกตามภูมิภาค และภูมิภาคอยู่บนศูนย์กระจายสินค้า คุณคัดลอกภูมิภาคไว้บนแต่ละการจัดส่ง คุณต้องตัดสินใจอะไร?
ใครเป็นเจ้าของความจริง สำเนาจะซิงก์อยู่ได้อย่างไร และการจัดส่งเก่าควรเก็บภูมิภาคที่เป็นจริงตอนที่มันเกิดขึ้น หรือตามศูนย์กระจายสินค้าถ้ามันย้าย denormalization ย้ายความซับซ้อน ไม่ได้กำจัดมัน อ่านทวน บางครั้งการทำรายงานชนะ
7. ท่าอย่างนั่งอาจเชื่อมกับสัตว์เลี้ยงหลายแสนตัว จากท่าของสัตว์เลี้ยงไปยังท่า ควรเป็น master-detail หรือ lookup?
lookup แนวทางของ Salesforce คือไม่ให้มีลูกเกิน 10,000 รายการต่อแม่หนึ่งตัว และท่ายอดนิยมจะเกินจำนวนนั้น master-detail เหมาะกับท่าของสัตว์เลี้ยงไปยังสัตว์เลี้ยง เพราะท่าของสัตว์เลี้ยงไม่มีวันถูกย้ายแม่ และสัตว์เลี้ยงหนึ่งตัวทำได้แค่ไม่กี่ท่า มันยังเป็นสิ่งที่ทำให้สัตว์เลี้ยง roll-up จำนวนท่าที่ทำได้ของมันได้ด้วย อ่านทวน นั่ง คอย โมเดล
ศึกษาเพิ่มเติม
หัวข้อที่มีชื่อว่า “ศึกษาเพิ่มเติม ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-09-25): รายการวัตถุประสงค์อย่างเป็นทางการและน้ำหนักของแต่ละข้อ ตรวจสอบฉบับล่าสุดเสมอก่อนจองสอบ
