การเชื่อมโยงไม่ใช่การจัดการข้อมูลหลัก
มีให้อ่านอีก 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)
บทที่ 6 ของ Data Architect ส่วนที่ 1: การเป็นสถาปนิกข้อมูล ก่อนหน้า: คุณภาพและธรรมาภิบาลข้อมูล
“เราต้องการแหล่งความจริงเดียว” เป็นหนึ่งในวลีที่ถูกพูดซ้ำมากที่สุดในงานสถาปัตยกรรม และถูกตรวจสอบน้อยที่สุด สำหรับอะไร? ลองดูบัญชีหนึ่ง ERP อาจเป็นเจ้าของชื่อตามกฎหมาย ที่อยู่เรียกเก็บเงิน และวงเงินเครดิต Salesforce เป็นเจ้าของผู้บริหารดูแลลูกค้าและระดับการสนับสนุน แพลตฟอร์มความยินยอมเป็นเจ้าของความต้องการด้านการตลาด ผู้มีอำนาจชี้ขาดสามรายบนเรกคอร์ดเดียว และนั่นเป็นเรื่องปกติ ดังนั้นเมื่อมีคนพูดว่า “Salesforce คือแหล่งความจริงเดียวของเราสำหรับลูกค้า” คำถามถัดไปของผมคือเสมอ: ความจริงข้อไหน?
บทนี้เกี่ยวกับการตอบคำถามนั้นอย่างตั้งใจ อำนาจชี้ขาดถูกกำหนดทีละแอตทริบิวต์ การเชื่อมโยงเรกคอร์ดไม่ใช่การจัดการข้อมูลหลักของมัน และ Salesforce ให้เครื่องมือต่างกันสำหรับงานต่างกัน: การจัดการข้อมูลซ้ำและการผสานภายใน org เดียว การระบุตัวตนเดียวกัน (identity resolution) ของ Data 360 สำหรับมุมมองเดียวข้ามแหล่ง แพลตฟอร์ม MDM เฉพาะเมื่อค่าต้องถูกตัดสินครั้งเดียวแล้วส่งกลับไปทุกที่ บทนี้จบด้วยจุดตรวจสอบที่ 1 ที่ส่วนที่ 1 มารวมกันบน Steve Trucking
ภาพสร้างด้วย AI
จุดยืนในบทนี้
หัวข้อที่มีชื่อว่า “จุดยืนในบทนี้ ”- ความจริงรายแอตทริบิวต์ ถามว่าข้อมูลแต่ละชิ้นถูกสร้าง แก้ไข และอ้างอิงที่ไหน และเปลี่ยนเร็วแค่ไหน แสดงอำนาจชี้ขาดภายนอกในสคีมาด้วยคำนำหน้าของระบบ เช่น
sap_หรือerp_ - ลูกค้ามุ่งหวังต่างออกไป มันอยู่ใน Salesforce ก่อนที่ ERP จะรู้จัก อำนาจชี้ขาดของ ERP มีผลหลังการแปลง
- Registry คือบรรทัดฐานในโปรเจกต์ Salesforce ตามด้วยการรวบรวม (consolidation) และการอยู่ร่วมกัน (coexistence) MDM แบบรวมศูนย์ล้วนๆ หายาก
- ผสานเฉพาะเมื่อมีผู้ชนะชัดเจน เก็บข้อมูลซ้ำจากการโหลดภายนอกไว้เมื่อคุณอาจต้องสืบย้อน การผสานทำลายประวัตินั้น และตัดสินว่าจะเกิดอะไรขึ้นกับเรกคอร์ดลูก: ย้ายมัน ไม่โหลดมัน หรือเก็บไว้บนเรกคอร์ดที่ไม่ใช้งาน
- โปรไฟล์รวมคือแผนที่ golden record คือการตัดสินใจ เรื่องนี้อาจทำให้คนสับสน: identity resolution สร้างบุคคลที่รวมกันแล้ว (unified individual) แต่ไม่ได้สร้าง golden record
- ความเข้มงวดของการจับคู่คือการตัดสินใจเรื่องความเสี่ยง ในที่ที่การรวมผิดมีราคาแพง ให้จับคู่น้อยไว้โดยตั้งใจ
- สามเครื่องมือสำหรับสามงาน: การผสาน identity resolution และ MDM
- ลำดับชั้นถูกจัดการข้อมูลหลักแบบแบ่งกัน ตัดสินอำนาจชี้ขาดทีละกิ่ง
- “สิ่งที่ยากที่สุดคือแบบสองทิศทาง” การผสานรวมแบบสองทางไม่ได้ทำให้มีเจ้าของหลักสองราย ตัดสินว่าฟิลด์ใดเดินทางไปด้วยกันเป็นธุรกรรมเดียว ก่อนการชนกันครั้งแรก
- ทำให้ข้อมูลหลักมองเห็นได้ ฟิลด์ที่บอกว่านี่คือข้อมูลหลัก (คีย์ของ ERP หรือแฟล็ก) เป็นตัวกำหนดว่าแก้ไขได้หรือไม่ ไม่ใช่ประเภทเรกคอร์ด
- เราไม่ได้ควบคุม ERP เราควบคุมวิธีที่เราแสดงมันใน Salesforce: ลูกค้ารายเดียวใน ERP สองระบบเป็นลำดับชั้น เป็นเรกคอร์ดระดับเดียวกัน หรือเป็นบัญชีเดียวที่มีลูกหนึ่งตัวต่อ ERP หนึ่งระบบ ซึ่งตัดสินจากว่าลูกค้าซิงก์ ERP ของตนได้ดีแค่ไหน
สามเครื่องมือสำหรับสามงาน
หัวข้อที่มีชื่อว่า “สามเครื่องมือสำหรับสามงาน ”| งาน | เครื่องมือ | ทำอะไรกับแหล่งข้อมูล |
|---|---|---|
| ข้อมูลซ้ำภายใน org เดียว ที่มีผู้ชนะชัดเจน | การจัดการข้อมูลซ้ำและการผสาน | ผสานได้สูงสุดสามเรกคอร์ด ที่เหลือไปอยู่ในถังรีไซเคิล |
| ตัวตนเดียวและมุมมองเดียวข้ามแหล่ง | identity resolution ของ Data 360 | เชื่อมโยงมัน ไม่เปลี่ยนแหล่งใดเลย (registry) |
| ค่าที่มีธรรมาภิบาลค่าเดียว ส่งกลับไปทุกระบบ | แพลตฟอร์ม MDM เฉพาะ | ตัดสินค่าและกระจายมัน (การอยู่ร่วมกันหรือแบบรวมศูนย์) |
เส้นทางผ่านบทนี้
หัวข้อที่มีชื่อว่า “เส้นทางผ่านบทนี้ ”หกโมดูลและหนึ่งโจทย์ท้าทาย แต่ละอย่างอ่านแยกกันได้
- แหล่งความจริงเดียวต่อหนึ่งแอตทริบิวต์ แผนที่อำนาจชี้ขาด golden record แบบผสม และสัญญาณความน่าเชื่อถือ
- สี่วิธีในการจัดการข้อมูลหลัก registry การรวบรวม การอยู่ร่วมกัน และแบบรวมศูนย์ และทำไมโมเดลร่วมจึงไม่ใช่ความจริงร่วม
- การจับคู่ การผสาน และการคงค่า ต้นทุนของการจับคู่ผิด สิ่งที่การผสานของ Salesforce ทำจริงๆ (และจะเกิดอะไรขึ้นกับเรกคอร์ดลูก) และการคงค่าในฐานะข้อความเกี่ยวกับความไว้วางใจ
- แผนที่ไม่ใช่การตัดสินใจ กฎการจับคู่และวิธีการจับคู่ กฎการกระทบยอด และทำไมโปรไฟล์รวมจึงไม่ใช่ golden record
- เมื่ออำนาจชี้ขาดถูกแบ่งกัน คำขอเทียบกับการอัปเดต ลูปและการชนกัน ลำดับชั้นที่จัดการข้อมูลหลักแบบแบ่งกัน และลูกค้ารายเดียวใน ERP สองระบบ
- โจทย์ท้าทายจุดตรวจสอบที่ 1 แล้วจึง จุดตรวจสอบที่ 1: Steve Trucking ผมจะออกแบบอย่างไร ลองทำโจทย์ก่อน: วาดและปกป้องการออกแบบของส่วนที่ 1 แล้วเปรียบเทียบกับของผม และดูว่าอะไรเปลี่ยนไปจากภาพรวมระบบของบทที่ 4
เมื่อเรียนจบแล้ว ให้ทดสอบตัวเองด้วยคู่มือทบทวนประจำบท: รายการตรวจสอบสำหรับการสอบ นิสัยที่ไปไกลกว่าการสอบ คำศัพท์ที่ควรรู้ และคำถามอีกจำนวนหนึ่ง มันปิดส่วนที่ 1 และคู่มือทบทวนส่วนที่ 1 รวมทั้งหกบทเข้าด้วยกัน
สิ่งที่สถาปนิกต้องตัดสินใจในเรื่องนี้
หัวข้อที่มีชื่อว่า “สิ่งที่สถาปนิกต้องตัดสินใจในเรื่องนี้ ”- ระบบใดมีอำนาจชี้ขาดสำหรับแอตทริบิวต์สำคัญแต่ละตัว และนั่นแสดงในโมเดลอย่างไร
- รูปแบบการจัดการข้อมูลหลักแบบใดเหมาะกับโดเมนข้อมูลแต่ละโดเมน และชั้นการจัดการข้อมูลหลักได้อำนาจชี้ขาดแค่ไหน
- เมื่อไรควรผสาน เมื่อไรควรเชื่อมโยง และใครเป็นเจ้าของกฎการคงค่าแต่ละข้อ
- การจับคู่ควรเข้มงวดแค่ไหน ตามต้นทุนของการจับคู่ผิด
- ข้อมูลสองทางและลำดับชั้นที่ใช้ร่วมกันต้องมีขอบเขตที่ชัดเจนที่ไหน
นอกเหนือจากการสอบ: เอเจนต์ต้องการตัวตนเดียวเพื่อลงมือ และนั่นเพิ่มเดิมพันทั้งสองทาง การจับคู่มากเกินไปกลายเป็นเหตุการณ์ด้านความเป็นส่วนตัว และเอเจนต์ที่ “อัปเดตลูกค้า” ต้องเขียนไปที่ระบบต้นทางหลักของแต่ละแอตทริบิวต์ ไม่ใช่โปรไฟล์รวม แต่ละโมดูลจบด้วยสิ่งที่ AI เปลี่ยน
ศึกษาเพิ่มเติม
หัวข้อที่มีชื่อว่า “ศึกษาเพิ่มเติม ”- Salesforce Architects, Data 360 Architecture (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)
- Salesforce Help, Considerations for Merging Duplicate Accounts (opens in a new tab), Identity Resolution Match Methods (opens in a new tab) และ Identity Resolution Reconciliation Rules (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)
ถัดไป: ส่วนที่ 2 เริ่มด้วย การออกแบบเพื่อรองรับขนาด (coming soon)