โมเดลข้อมูลคือโครงกระดูก

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

โมดูลที่ 2 จาก 7 ในบท คิดแบบสถาปนิกข้อมูล ซึ่งเป็นบทแรกของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: คิดแบบสถาปนิก · ถัดไป: การทดสอบความย้อนกลับได้

คำถามที่โมดูลนี้ตอบ: ทำไมโมเดลข้อมูลจึงสำคัญกว่าทุกสิ่งที่สร้างอยู่บนมัน และจะประเมินโมเดลหนึ่งอย่างไร?

เวลาผมสอนสถาปัตยกรรมข้อมูล มีวลีหนึ่งที่ผมกลับมาพูดซ้ำแล้วซ้ำอีก: โมเดลข้อมูลคือโครงกระดูก

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

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

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

เริ่มจากธุรกิจ

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

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

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

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

สนับสนุน เติบโต ทำผลงาน

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

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

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

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

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

สนับสนุน เติบโต ทำผลงาน เราจะกลับมาที่บททดสอบสามข้อนี้ตลอดหลักสูตร

Click to enlarge

แบนเกินไป ซับซ้อนเกินไป หรือผิดไปเลย

ผมเคยเห็นโมเดลข้อมูลผิดพลาดได้สามแบบ

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

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

แบบที่สามคือความผิดพลาดในทางตรงข้าม: เราแยกย่อยมากเกินไป (over-normalize) เราสร้างไดอะแกรมสวยงามที่มีออบเจกต์ต่อกันไปเรื่อยๆ ทุกแนวคิดถูกแยกอย่างสมบูรณ์แบบ สวยในทางเทคนิค แต่ทรมานในทางปฏิบัติ ผู้ใช้เข้าใจยาก และเลย์เอาต์หน้ากับหน้า Lightning ที่มี related list ต่อกันไปเรื่อยๆ อาจรู้สึกลึกไม่มีที่สิ้นสุด คิวรีซับซ้อนขึ้น ระบบอัตโนมัติข้ามความสัมพันธ์มากขึ้น การทำรายงานยากขึ้น และแพลตฟอร์มต้องทำงานหนักขึ้นเพื่อตอบคำถามทางธุรกิจธรรมดาๆ

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

Click to enlarge

ระวังการเปลี่ยนโครงกระดูก

เมื่อระบบใช้งานจริงแล้ว ผมจะระมัดระวังมากกับการเปลี่ยนแปลงพื้นฐานของโมเดลข้อมูล

สมมติว่ามีฟิลด์ข้อความที่อยู่มาหลายปี แล้วมีคนพูดว่า “เราไม่ได้ใช้มันแบบนั้นแล้ว เปลี่ยนเป็นตัวเลขเถอะ” ฟังดูเหมือนแค่เปลี่ยนฟิลด์ แต่มีอะไรพึ่งพาฟิลด์นั้นอยู่บ้าง? Flow, Apex, รายงาน, การผสานรวม, data pipeline, แอปพลิเคชันภายนอก, เอเจนต์ AI และข้อมูลในอดีตจะเป็นอย่างไร? ตัวแพลตฟอร์มเองไม่ยอมให้คุณเปลี่ยนประเภทของฟิลด์ขณะที่โค้ดหรือ Flow ยังอ้างถึงอยู่ ซึ่งบอกคุณว่าการเปลี่ยนนี้ส่งผลกว้างแค่ไหน

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

เพิ่มแทนการแก้ไข เลิกใช้แทนการทำให้ตกใจ

Salesforce ยังให้วิธีบอกเรื่องนี้ในเมทาดาทาด้วย: Field Usage ของฟิลด์สามารถตั้งเป็น DeprecateCandidate หรือ “มีแผนจะเลิกใช้และไม่ได้ใช้งานแล้ว” ค่านี้ทำเครื่องหมายฟิลด์ให้ทุกคนที่อ่านออบเจกต์เห็น แต่ไม่ได้ซ่อนฟิลด์ ดังนั้นการปลดระวางมันยังเป็นการตัดสินใจที่คุณต้องลงมือเอง

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

Click to enlarge

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

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

โครงกระดูกมาก่อน

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

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

โมเดลข้อมูลคือโครงกระดูก สถาปนิกควรระมัดระวังอย่างมากเมื่อออกแบบโครงกระดูก การเปลี่ยนแปลงโครงสร้างที่มีอยู่แล้วอาจส่งผลกระทบต่อเนื่องเป็นทอดๆ

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

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

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

• Considerations for Converting the Field Type of a Custom Field (opens in a new tab), Salesforce Help (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-02 และตรวจสอบอีกครั้งเมื่อ 2026-10-12): การเปลี่ยนประเภทแบบใดอาจทำให้ข้อมูลสูญหาย และทำไมคุณจึงเปลี่ยนประเภทของฟิลด์ที่ Apex, Flow หรือ process อ้างถึงไม่ได้
• Data Classification Metadata Fields (opens in a new tab), Salesforce Help (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-02 และตรวจสอบอีกครั้งเมื่อ 2026-10-12): ค่าของ Field Usage (Active, DeprecateCandidate, Hidden) และฟิลด์การจัดประเภทอื่นๆ