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

โมดูลที่ 6 จาก 6 ในบท การสร้างโมเดลข้อมูลเพื่อความหมาย บทที่ 2 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: ออกแบบถึงรูปแบบบรรทัดฐานที่สาม แล้วถอยออกมา · ถัดไป: คู่มือทบทวนประจำบท แล้วต่อด้วยบทถัดไป: สถาปัตยกรรมข้อมูล Salesforce

คำถามที่โมดูลนี้ตอบ: โมเดลข้อมูลเชิงตรรกะกลายเป็นโมเดลข้อมูล Salesforce เชิงกายภาพได้อย่างไร?

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

นั่ง คอย โมเดล

ขั้นเชิงกายภาพเห็นได้ง่ายที่สุดกับสิ่งเล็กๆ สัตว์เลี้ยงจึงมาก่อน

ใครคือธุรกิจ และใครคือคน? ผู้เพาะพันธุ์เป็นธุรกิจ จึงกลายเป็นบัญชี (Account) ที่มีประเภทเรกคอร์ด Breeder (ผู้เพาะพันธุ์) เจ้าของก็เป็นบัญชีด้วย หรือเป็นบัญชีบุคคล ที่มีประเภทเรกคอร์ด Owner (เจ้าของ) ออบเจกต์มาตรฐานเดียวกันสองประเภท อยู่เคียงกันที่ด้านบนของไดอะแกรม ตรงที่พวกมันอยู่มาตั้งแต่โมดูลที่ 1

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

ความสัมพันธ์ใดเป็น master-detail? ผมใช้ master-detail เฉพาะเมื่อลูกจะไม่มีวันถูกย้ายไปอยู่กับแม่ตัวอื่น ท่าของสัตว์เลี้ยงเป็นของสัตว์เลี้ยงของมันไปตลอดชีวิต และการประเมินท่าแต่ละครั้งเป็นของท่าของสัตว์เลี้ยงนั้น ทั้งสองจึงเป็น master-detail ซึ่งให้ผลตอบแทนทันที: master-detail คือสิ่งที่ทำให้สัตว์เลี้ยงเก็บฟิลด์สรุปยอด (roll-up summary) ของท่าของสัตว์เลี้ยงได้ จำนวนท่าที่ทำได้จากโมดูลที่ 5 จึงตรงกันอยู่เสมอได้เอง แต่สัตว์เลี้ยงย้ายบ้านได้ เจ้าของจึงเป็น lookup

อะไรเป็น lookup? Salesforce ไม่แนะนำให้มีลูกเกิน 10,000 รายการบนแม่ตัวเดียว ท่ายอดนิยมอย่างนั่ง สายพันธุ์ที่พบบ่อย หรือผู้เพาะพันธุ์รายใหญ่ อาจเกินจำนวนนั้นได้ง่ายๆ ท่าของสัตว์เลี้ยงจึงชี้ไปที่ท่าด้วย lookup และสัตว์เลี้ยงชี้ไปที่สายพันธุ์และผู้เพาะพันธุ์แบบเดียวกัน และหลีกเลี่ยงความสัมพันธ์แบบ polymorphic เมื่อทำได้ คือแบบที่ฟิลด์เดียวชี้ไปได้หลายประเภทออบเจกต์ มันสะดวกในวันแรก แต่ยากขึ้นสำหรับทุกอย่างที่ต้องอ่านมันในภายหลัง: รายงาน การผสานรวม และตอนนี้ก็เอเจนต์

อะไรอยู่นอกแพลตฟอร์ม? ถ้าสัตว์เลี้ยงสวมปลอกคอ GPS ที่รายงานตำแหน่งของมัน ตำแหน่งนั้นไม่จำเป็นต้องถูกคัดลอกเข้ามาเลย มันเป็นออบเจกต์ภายนอกได้ อ่านสดจากระบบติดตามของปลอกคอ

Click to enlarge

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

เริ่มจากโมเดลเชิงตรรกะ

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

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

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

เอนทิตีทางธุรกิจไม่ได้แปลว่าออบเจกต์ที่กำหนดเองโดยอัตโนมัติ

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

แอตทริบิวต์กลายเป็นฟิลด์เชิงกายภาพ

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

Click to enlarge

ความสัมพันธ์กลายเป็นการตัดสินใจเรื่องแพลตฟอร์ม

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

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

ทีนี้วาดโมเดลเชิงกายภาพ

ไดอะแกรมเปลี่ยนอีกครั้ง โมเดลเชิงแนวคิดแสดงแนวคิดทางธุรกิจและเส้นง่ายๆ โมเดลเชิงตรรกะเพิ่มแอตทริบิวต์ คีย์ cardinality และเอนทิตีที่ซ่อนอยู่ในความสัมพันธ์ ตอนนี้โมเดลเชิงกายภาพเริ่มดูเหมือน Salesforce: ออบเจกต์มาตรฐาน ออบเจกต์ที่กำหนดเอง ฟิลด์ ประเภทความสัมพันธ์ และสิ่งที่อยู่นอกแพลตฟอร์ม

Click to enlarge

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

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

โมเดลเชิงกายภาพต้องเคารพแพลตฟอร์ม

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

บางครั้งโมเดลเชิงกายภาพจะตั้งใจต่างจากโมเดลเชิงตรรกะที่สะอาดด้วย เพราะการตัดสินใจเรื่อง denormalization ที่เราทำในโมดูลที่ 5 นั่นไม่เป็นไร ตราบใดที่เราอธิบายได้ว่าทำไม

อย่าออกแบบจาก Setup

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

เชิงกายภาพไม่ได้แปลว่าถาวร

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

สิ่งที่สถาปนิกต้องตัดสินใจในเรื่องนี้

เมื่อผมเปลี่ยนโมเดลเชิงตรรกะให้เป็นโมเดล Salesforce เชิงกายภาพ ผมกำลังตัดสินใจว่า:

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

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

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

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

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

• Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab), Salesforce Developers, Winter ‘27 (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-02): “กำหนดความสัมพันธ์แม่ลูกให้มีลูกไม่เกิน 10,000 รายการต่อเรกคอร์ดแม่หนึ่งรายการ” เป็นแนวทางเรื่องข้อมูลกระจุกตัว (data skew) ไม่ใช่ขีดจำกัดตายตัว บทที่ 7 จะลงลึกกว่านี้
• Roll-Up Summary Field (opens in a new tab), Salesforce Help (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-12): ฟิลด์สรุปยอดนับหรือรวมยอดเรกคอร์ด detail ผ่านความสัมพันธ์แบบ master-detail