การจับคู่ การผสาน และการคงค่า

🌐 มีให้อ่านอีก 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 จาก 6 ในบท ข้อมูลหลักและตัวตน บทที่ 6 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: สี่วิธีในการจัดการข้อมูลหลัก · ถัดไป: แผนที่ไม่ใช่การตัดสินใจ

คำถามที่โมดูลนี้ตอบ: คุณหาข้อมูลซ้ำ และตัดสินว่าค่าใดคงอยู่ได้อย่างไร?

Salesforce มีผู้ติดต่อสองราย: Daniel Reyes, Dallas, d.reyes@example.com และ Dan Reyes, Dallas, d.reyes@example.com คนเดียวกันไหม? น่าจะใช่ เราควรผสานไหม? นั่นเป็นอีกคำถาม และถ้าผสาน เบอร์โทร ที่อยู่ และตำแหน่งงานไหนคงอยู่? ต่างออกไปอีก สถาปนิกต้องแยกการตัดสินใจสามข้อออกจากกัน:

• การจับคู่ (matching): เรกคอร์ดเหล่านี้แทนสิ่งเดียวกันไหม?
• การผสาน (merging): ควรกลายเป็นเรกคอร์ดเดียวไหม?
• การคงค่า (survivorship): ถ้าเรารวมข้อมูล ค่าใดชนะ?

การจับคู่มาก่อน

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

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

ต้นทุนของการผิด

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

ปรับให้สอดคล้อง แล้วจับคู่ แล้วรวบรวม

การจับคู่ยังขึ้นอยู่กับรูปร่างของข้อมูล AZ, Arizona, Ariz.; 6025550198, (602) 555-0198, +1 602 555 0198 การปรับให้สอดคล้องกัน (harmonization) ทำให้ค่าเปรียบเทียบกันได้: รูปแบบมาตรฐาน คำย่อที่เป็นมาตรฐาน รหัสที่จับคู่แล้ว แล้วคุณจึงจับคู่ หลังจากรู้แล้วว่าเรกคอร์ดเป็นของเดียวกันเท่านั้น คุณจึงรวบรวมข้อมูลของมันเป็นตัวแทนเดียว การปรับให้สอดคล้องไม่ใช่การจับคู่ การจับคู่ไม่ใช่การผสาน และการรวบรวมก็ไม่จำเป็นต้องเป็นการจัดการข้อมูลหลัก

Click to enlarge

การตัดสินใจเรื่องตัวตนเกิดขึ้นเป็นขั้นๆ

การจับคู่ไม่ได้บังคับให้ต้องผสาน

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

กฎการผสานของผม: ผู้ชนะที่ชัดเจน

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

สิ่งที่การผสานของ Salesforce ทำจริงๆ

การเชื่อมโยงบอกว่า “สิ่งเหล่านี้เป็นของเดียวกัน” การผสานบอกว่า “สิ่งเหล่านี้เป็นหนึ่งเดียวแล้ว” และบน Salesforce มันคือการเปลี่ยนแปลงจริง สำหรับบัญชี คุณเลือกได้สูงสุดสามเรกคอร์ดและเลือกหนึ่งเป็นตัวหลัก (principal) คุณเลือกว่าจะเก็บค่าฟิลด์ใดจากตัวอื่น ขณะที่ฟิลด์ที่ซ่อนและอ่านอย่างเดียวมาจากตัวหลัก เรกคอร์ดที่ผสานแล้วเก็บ Created By และ Created Date ของเรกคอร์ดที่เก่าที่สุด ไม่ว่าตัวไหนจะเป็นตัวหลัก เรกคอร์ดที่ไม่ใช่ตัวหลักไปอยู่ในถังรีไซเคิล เรกคอร์ดที่เกี่ยวข้องเช่นกิจกรรมย้ายไปที่เรกคอร์ดที่ผสานแล้ว โดยมีข้อยกเว้น ใน Lightning การผสานทำงานกับข้อมูลซ้ำที่กฎข้อมูลซ้ำของคุณตรวจพบ และสำหรับบัญชีบุคคล ออบเจกต์ contact point ไม่รองรับการผสาน: ความสัมพันธ์ของมันจะหายไป (Considerations for Merging Duplicate Accounts (opens in a new tab); Merge Duplicate Accounts in Lightning Experience (opens in a new tab) ภาษาอังกฤษ)

ความรู้ที่ออกสอบ รู้ว่าการผสานบัญชีของ Salesforce ทำอะไร: ได้สูงสุดสามเรกคอร์ด มีเรกคอร์ดหลัก (principal) หนึ่งเรกคอร์ด ซึ่งฟิลด์ที่ซ่อนและฟิลด์อ่านอย่างเดียวของมันถูกเก็บไว้ Created By และ Created Date ของเรกคอร์ดที่เก่าที่สุด ถูกเก็บไว้ ไม่ว่าเรกคอร์ดไหนจะเป็นเรกคอร์ดหลัก เรกคอร์ดอื่นไปอยู่ในถังรีไซเคิล และสำหรับบัญชีบุคคล ออบเจกต์จุดติดต่อ (contact point) ไม่ถูกผสาน

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

การคงค่า: ค่าใดชนะ?

เรกคอร์ดเป็นของเดียวกัน แต่ไม่ตรงกัน: Salesforce และระบบเรียกเก็บเงินบอก 602-555-0100, ERP บอก 602-555-0188 กฎการคงค่า (survivorship) เลือกผู้ชนะ กฎที่พบบ่อย: ล่าสุด (การอัปเดตล่าสุด) พบบ่อยที่สุด (ค่าที่แหล่งส่วนใหญ่เห็นตรงกัน) และลำดับความสำคัญของแหล่ง (เชื่อแหล่งนี้มากกว่าแหล่งนั้น) บวกการผสมกัน เกณฑ์ น้ำหนัก และกฎเฉพาะทางธุรกิจ ไม่มีกฎไหนถูกต้องโดยธรรมชาติ

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

ถ้าแผนที่อำนาจชี้ขาดของโมดูลที่ 1 บอกไว้แล้วว่า ERP เป็นเจ้าของวงเงินเครดิต การคงค่าก็ง่าย: ERP ชนะ ไม่ต้องให้คะแนนฉลาดๆ กรณียากคือแอตทริบิวต์ที่อำนาจชี้ขาดถูกแบ่งกัน ไม่ชัดเจน หรืออิงหลักฐานแทนที่จะเป็นตัวหลักเดียว นั่นคือที่ที่กฎการคงค่าคุ้มค่า

Click to enlarge

กฎการคงค่าคือข้อความเกี่ยวกับความไว้วางใจ

เกณฑ์ การตรวจทาน และการเพิ่มคุณค่าข้อมูล

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

การเพิ่มคุณค่าข้อมูล (enrichment) เพิ่มคำถามเรื่องแหล่งที่มาอีกข้อ ข้อมูลอ้างอิงไปรษณีย์ รหัสอุตสาหกรรม ข้อมูลบริษัท คะแนนความเสี่ยงภายนอก ปรับปรุงข้อมูลหลักได้ แต่แต่ละค่ามาจากไหน น่าเชื่อถือและใหม่แค่ไหน เราใช้มันเพื่อจุดประสงค์นี้ได้ไหม มันมีข้อมูลส่วนบุคคลไหม? “Industry = Transportation” จากผู้ให้บริการข้อมูลไม่เหมือนกับที่ลูกค้าบอกคุณเอง เก็บความแตกต่างนั้นไว้

Steve Trucking: คล้ายกันไม่ใช่เหมือนกัน

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

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

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

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

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

จับคู่อย่างระมัดระวัง ผสานอย่างตั้งใจ เลือกกฎการคงค่าอย่างจงใจ เรกคอร์ดลูกค้าที่สะอาดไม่มีค่าเท่าไรถ้าคุณได้มันมาด้วยการรวมลูกค้าผิดคน

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

• Salesforce Help, Considerations for Merging Duplicate Accounts (opens in a new tab) และ Merge Duplicate Accounts in Lightning Experience (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)