התאמה, מיזוג וכללי שרידות

🌐 זמין גם ב-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)

התמונה נוצרה בבינה מלאכותית

תורגם בבינה מלאכותית. הקהילה עוד לא בדקה את התרגום. לקריאה באנגלית

יחידה 3 מתוך 6 בפרק נתוני אב וזהות, הפרק השישי בקורס Data Architect. כל יחידה עומדת בפני עצמה. הקודם: ארבע הדרכים לנהל נתוני אב · הבא: מפה איננה החלטה

השאלה שהיחידה הזו עונה עליה: איך מוצאים כפילויות, ואיך מחליטים אילו ערכים שורדים?

ב-Salesforce יש שני אנשי קשר: Daniel Reyes, דאלאס, d.reyes@example.com, ו-Dan Reyes, דאלאס, d.reyes@example.com. אותו אדם? כנראה. האם למזג אותם? זו שאלה אחרת. ואם כן, איזה מספר טלפון, כתובת ותואר שורדים? שוב שאלה אחרת. ארכיטקטים צריכים להחזיק שלוש החלטות בנפרד:

• התאמה: האם הרשומות האלה מייצגות את אותו דבר?
• מיזוג: האם הן צריכות להפוך לרשומה אחת?
• כללי שרידות: אם משלבים נתונים, אילו ערכים מנצחים?

ההתאמה באה קודם

פרק 3 כיסה את כללי הכפילויות וכללי ההתאמה של Salesforce, אז לא אלמד שוב את המכניקה. השאלה הארכיטקטונית היא איזו ראיה חזקה מספיק כדי להגיד שאלה אולי אותו דבר? לאדם: אימייל, טלפון, שם ועוד כתובת, מספר לקוח, שילוב כלשהו. לחברה: שם משפטי, מספר עוסק, מזהה לקוח ב-ERP, כתובת, דומיין אינטרנט. לא “האם Salesforce יכול להשוות את השדות האלה?” אלא “איזה שילוב נותן לנו מספיק ביטחון כדי לפעול?”

ומדויק זה לא ודאי. אימייל משותף הוא אות חזק, לא הוכחה: משפחות חולקות כתובות, עסקים משתמשים ב-purchasing@company.com, מספרי טלפון שייכים למשקי בית, שמות וכתובות אינם ייחודיים, ואפילו מזהים חזקים עוברים שימוש חוזר, מוקלדים לא נכון או ממוחזרים. התאמה איננה השוואת מחרוזות. היא הצהרה על זהות.

המחיר של טעות

כשאני מלמד את זה, אני מחליף תחום. בנתוני שיווק של רכב, אנחנו מחליטים בטעות ששני Daniel Reyes הם אותו אדם, והלא נכון מקבל הצעה לרכב שטח. לא טוב, אבל סיכון נמוך. עכשיו תעשו את אותה התאמה שגויה בנתונים רפואיים: ההיסטוריה הרפואית של שני אנשים שונים משולבת. אותה טעות התאמה, תוצאה שונה לגמרי. בגלל זה אין סף התאמה “טוב” אוניברסלי. לפעמים הסיכון הגדול יותר הוא לפספס התאמה; לפעמים הוא לשלב שני אנשים שאינם אותו אדם. איפה שהתאמות שגויות עולות ביוקר, אני מתאים פחות מדי בכוונה.

קודם להאחיד, אחר כך להתאים, ואז לאחד

ההתאמה תלויה גם בצורה של הנתונים. AZ, Arizona, Ariz.; 6025550198, (602) 555-0198, +1 602 555 0198. האחדה (harmonization) הופכת ערכים לברי השוואה: פורמטים סטנדרטיים, קיצורים מנורמלים, קודים ממופים. ואז מתאימים. רק אחרי שיודעים שרשומות שייכות יחד, מאחדים (consolidate) את המידע שלהן לייצוג אחד. האחדה איננה התאמה, התאמה איננה מיזוג, ואיחוד הוא לא בהכרח ניהול נתוני אב.

Click to enlarge

החלטות זהות קורות בשלבים.

התאמה לא מחייבת מיזוג

זו אחת ההבחנות הכי חשובות בפרק. אנחנו בטוחים ששתי רשומות לקוח משתי מערכות ישנות הן אותה חברה. אנחנו חייבים למזג אותן? לא. כל אחת אולי נושאת זהות של מערכת מקור; טרנזקציות היסטוריות אולי מצביעות על כל אחת מהן; המבקרים אולי צריכים את העקבות; אולי אנחנו עדיין באמצע הסבה; אולי נצטרך לדעת בדיוק מה המערכת הישנה אמרה. הידיעה ששתי רשומות הן אותו דבר לא מכריחה אותנו לכווץ אותן לאחת. אנחנו יכולים לקשר אותן, ולעיתים קרובות זו הארכיטקטורה הבטוחה יותר.

כלל המיזוג שלי: מנצח ברור

העמדה שלי: מזגו רק כשיש מנצח ברור והכפילות לא מוסיפה שום דבר שצריך לשמור. נציג יצר אתמול חשבון כפול; המקורי הוא בבירור הרשומה המבוססת. מועמד טוב למיזוג. עכשיו שנו את זה: ייבאנו לקוחות ממערכת ישנה, עם המזהים שלה, ערכים ישנים יותר, אולי טרנזקציות או דרישות ביקורת שקשורות אליהם. אני הרבה יותר זהיר. שמרו כפילויות מטעינות חיצוניות כשייתכן שתצטרכו להתחקות חזרה לערכים ישנים יותר, כי מיזוג הורס את ההיסטוריה הזו.

מה מיזוג ב-Salesforce באמת עושה

קישור אומר “אלה שייכים יחד.” מיזוג אומר “אלה עכשיו אחד”, וב-Salesforce זה שינוי אמיתי. בחשבונות, בוחרים עד שלוש רשומות ובוחרים אחת מהן כרשומה הראשית (principal); בוחרים אילו ערכי שדות של האחרות לשמור, בעוד ששדות מוסתרים ושדות לקריאה בלבד מגיעים מהרשומה הראשית. הרשומה הממוזגת שומרת את Created By ו-Created Date של הרשומה הוותיקה ביותר, לא משנה איזו מהן ראשית. הרשומות שאינן ראשיות עוברות לסל המיחזור (Recycle Bin). רשומות קשורות כמו פעילויות עוברות לרשומה הממוזגת, עם חריגים. ב-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 עושה: עד שלוש רשומות; רשומה ראשית אחת, שהשדות המוסתרים ושדות הקריאה בלבד שלה נשמרים; Created By ו-Created Date של הרשומה הוותיקה ביותר, לא משנה איזו ראשית; הרשומות האחרות עוברות לסל המיחזור; ובחשבונות אישיים, אובייקטי נקודות קשר לא ממוזגים.

לא צריך להכיר כל מקרה קצה כדי לקבל את ההחלטה. צריך להכיר את התוצאה: אחרי מיזוג, הרשומות העצמאיות שהתחלתם איתן נעלמו. מבחן ההפיכות של פרק 1 חל כאן: קל לבטל קישור; מיזוג לא. ולקוח כמעט אף פעם לא עומד לבד: אנשי קשר, פניות, הזדמנויות, קבצים, רשומות הסכמה, רשומות בת מותאמות אישית, מזהים חיצוניים, הפניות של אינטגרציה. לפני שממזגים את רשומת האב, הבינו מה קורה לכל מה שמחובר אליה. כשכפילויות נכנסות עם טעינה, אני נותן לצוותים שלוש אפשרויות לרשומות הבת: להעביר אותן לרשומה השורדת; לא לטעון אותן בכלל, אם אף אחד לא צריך אותן; או להשאיר אותן על הרשומה האחרת, מסומנת כלא פעילה, כדי שעדיין יופיעו בחיפוש. הראשונה היא מה שמיזוג עושה בשבילכם. שתי האחרות שומרות את העקבות, ולעיתים קרובות זה בדיוק העניין.

כללי שרידות: איזה ערך מנצח?

הרשומות שייכות יחד, אבל הן לא מסכימות: Salesforce והחיוב אומרים 602-555-0100, ה-ERP אומר 602-555-0188. כללי שרידות (survivorship) בוחרים את המנצח. הנפוצים: העדכני ביותר (העדכון האחרון), השכיח ביותר (הערך שרוב המקורות מסכימים עליו), ועדיפות מקור (לסמוך על המקור הזה יותר מאשר על ההוא), ועוד שילובים, ספים, משקלות וכללים ספציפיים לעסק. אף אחד מהם לא נכון מטבעו.

“העדכני ביותר” הוא לא הגדרה טכנית. הוא הצהרה על אמון: כשמערכות לא מסכימות, הערך החדש ביותר נכון יותר בסבירות גבוהה. סביר למספר נייד. נורא לשם משפטי: אם ה-ERP הוא הבעלים שלו, לא אכפת לי שמישהו שינה את העותק ב-Salesforce לפני חמש דקות. “השכיח ביותר” מניח שהסכמה היא ראיה, אבל שלושה עותקים מיושנים במורד הזרם לא גוברים בהצבעה על מקור הרשומה. “עדיפות מקור” אומרת את זה במפורש: אנחנו סומכים יותר על המקור הזה. אז כללי שרידות שייכים לארכיטקטורה ולממשל הנתונים, ולכל כלל צריכים להיות בעלים. מי החליט שהכתובת החדשה ביותר מנצחת, או שה-ERP גובר על Salesforce?

אם מפת הסמכות של יחידה 1 כבר אומרת שה-ERP הוא הבעלים של מסגרת האשראי, כללי השרידות קלים: ה-ERP מנצח, בלי צורך בניקוד מתוחכם. המקרים הקשים הם מאפיינים שבהם הסמכות משותפת, לא ברורה או מבוססת על ראיות ולא על מקור אב אחד. שם כללי השרידות מצדיקים את קיומם.

Click to enlarge

כללי שרידות הם הצהרות על אמון.

ספים, בדיקה אנושית והעשרה

חלק מההתאמות שוקלות את הראיות: התאמה של מזהה לקוח חזקה מאוד, אימייל חזק, טלפון בינוני, שם דומה חלש, כתובת דומה תומכת. מעל ציון אחד, התאמה; מתחת לציון אחר, שונים; ביניהם, אדם בודק. האלגוריתם הוא לא הלקח. הסף הוא הסובלנות שלכם לטעות, והוא צריך לנבוע מהסיכון העסקי. וכשהראיות מעלות את השאלה בלי להכריע אותה, אל תעמידו פנים שהמערכת יודעת. נתבו את זה לבדיקה. איטי יותר, וזה בסדר: אוטומציה לא שווה הרבה כשהיא ממזגת בביטחון שני לקוחות שונים.

העשרה (enrichment) מוסיפה עוד שאלה של מקור. נתוני ייחוס של דואר, קודי ענף, נתונים על חברות (firmographics), ציוני סיכון חיצוניים משפרים את נתוני האב, אבל מאיפה הגיע כל ערך, כמה הוא אמין ועדכני, מותר לנו להשתמש בו למטרה הזו, האם יש בו מידע אישי? “ענף = תחבורה” מספק נתונים זה לא אותו דבר כמו שהלקוח אומר לכם. שמרו על ההבחנה הזו.

Steve Trucking: דומה זה לא אותו דבר

שני שותפים קמעונאיים שולחים משלוחים ל-John Smith, רחוב הראשי 123, קולומבוס, עם אותו מספר טלפון. אותו אדם? כנראה. האם Steve Trucking צריכה לאחד אותם? זכרו של מי הם: הנמענים האלה הם הלקוחות של השותפים, ושותף אחד לעולם לא יראה את של אחר. התאמה שגויה תערבב נתונים מעבר לגבול הזה. פתאום זו לא שאלה של איכות נתונים אלא שאלה של פרטיות ובידוד, וזו בדיוק הסיבה שספים תלויים בתוצאות. נקודת הביקורת מכריעה. בינתיים: אל תתנו לנוחות של ההתאמה לקבל את ההחלטה העסקית.

לפעמים דווקא הבלגן מספר לכם משהו. הרשומה הזו הגיעה מהמערכת הישנה, ההיא מ-Salesforce, וזו מהחברה שנרכשה; המזהים שלהן, ההיסטוריה שלהן והעובדה שהן לא הסכימו יכולים כולם להיות חשובים. נתונים נקיים הם בעלי ערך. גם יכולת התחקות. הארכיטקט מחליט מה חשוב יותר לשימוש.

מעבר למבחן: מה ה-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).