קישור איננו ניהול נתוני אב

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

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

העמדות בפרק הזה

• אמת לכל מאפיין. שאלו איפה כל פיסת מידע נוצרת, נערכת ומשמשת כהפניה, וכמה מהר היא משתנה. הראו סמכות חיצונית בסכמה עם קידומת של מערכת, כמו sap_ או erp_.
• לקוחות פוטנציאליים הם סיפור אחר. הם חיים ב-Salesforce לפני שה-ERP מכיר אותם; הסמכות של ה-ERP חלה אחרי ההמרה.
• רישום (registry) הוא הנורמה בפרויקטים של Salesforce, אחריו איחוד (consolidation) ודו-קיום (coexistence); MDM מרכזי טהור הוא נדיר.
• מזגו רק כשיש מנצח ברור. שמרו כפילויות מטעינות חיצוניות כשייתכן שתצטרכו להתחקות אחורה; מיזוג הורס את ההיסטוריה הזו. והחליטו מה קורה לרשומות הבת: להעביר אותן, לא לטעון אותן, או להשאיר אותן על רשומה לא פעילה.
• פרופיל מאוחד הוא מפה; רשומת זהב היא החלטה. זה יכול לבלבל אנשים: זיהוי ישויות יוצר אדם מאוחד (unified individual), אבל לא רשומת זהב.
• הקפדנות של ההתאמה היא החלטת סיכון. איפה שערבוב עולה ביוקר, התאימו פחות מדי בכוונה.
• שלושה כלים לשלוש עבודות: מיזוג, זיהוי ישויות, MDM.
• היררכיות מנוהלות בסמכות מפוצלת. החליטו על הסמכות ענף אחרי ענף.
• “הדבר הכי קשה זה הדו-כיווניים.” אינטגרציה דו-כיוונית לא יוצרת שני מקורות אב. החליטו אילו שדות נוסעים יחד כטרנזקציה אחת לפני ההתנגשות הראשונה.
• הפכו את נתוני האב לגלויים. שדה שאומר שאלה נתוני אב (המפתח של ה-ERP או דגל) הוא שמניע את יכולת העריכה, לא סוג רשומה.
• אנחנו לא שולטים ב-ERPs. אנחנו שולטים באופן שבו אנחנו מייצגים אותם ב-Salesforce: לקוח אחד בשני ERPs הוא היררכיה, עמיתים, או חשבון אחד עם רשומת בת לכל ERP, לפי כמה טוב החברה שאתם עובדים איתה שומרת על ה-ERPs שלה מסונכרנים.

שלושה כלים לשלוש עבודות

העבודה	הכלי	מה הוא עושה למקורות
כפילויות בתוך org אחד, עם מנצח ברור	ניהול כפילויות ומיזוג	ממזג עד שלוש רשומות; האחרות עוברות לסל המיחזור (Recycle Bin)
זהות אחת ותמונה אחת על פני מקורות	זיהוי ישויות ב-Data 360	מקשר אותם; לא משנה אף אחד מהם (רישום)
ערך מנוהל אחד, שנדחף חזרה לכל מערכת	פלטפורמת MDM ייעודית	מכריעה בערך ומפיצה אותו (דו-קיום או מרכזי)

המסלול בפרק הזה

שש יחידות ואתגר, כל אחד עומד בפני עצמו.

1. מקור אמת אחד לכל מאפיין. מפת הסמכות, רשומת הזהב ההיברידית, ואותות אמון.
2. ארבע הדרכים לנהל נתוני אב. רישום, איחוד, דו-קיום ומרכזי, ולמה מודל משותף איננו אמת משותפת.
3. התאמה, מיזוג וכללי שרידות. המחיר של התאמה שגויה, מה מיזוג ב-Salesforce באמת עושה (ומה קורה לרשומות הבת), וכללי שרידות כהצהרה על אמון.
4. מפה איננה החלטה. כללי התאמה ושיטות התאמה, כללי יישוב (reconciliation), ולמה פרופיל מאוחד איננו רשומת זהב.
5. כשהסמכות משותפת. בקשות מול עדכונים, לולאות והתנגשויות, היררכיות בסמכות מפוצלת, ולקוח אחד בשני ERPs.
6. אתגר נקודת הביקורת 1, ואחריו נקודת ביקורת 1: Steve Trucking, איך אני הייתי מתכנן. נסו קודם את האתגר: שרטטו והגנו על התכנון של חלק 1, ואז השוו אותו לשלי, וראו מה משתנה ממפת המערכות של פרק 4.

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

מה הארכיטקט מחליט כאן

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

מעבר למבחן: סוכנים צריכים זהות אחת לפעול עליה, וזה מעלה את ההימור לשני הכיוונים. התאמת יתר הופכת לאירוע פרטיות, וסוכן ש”מעדכן את הלקוח” צריך לכתוב למערכת הרשומה (system of record) של כל מאפיין, לא לפרופיל המאוחד. כל יחידה מסתיימת במה שה-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).