נתוני אב וזהות

🌐 זמין גם ב-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; הדף הזה עוזר לכם לבדוק מה נקלט.

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

הפרק הזה נושא את סעיף Master Data Management במבחן (5%) ואת התמונה האחת של הלקוח מתוך Salesforce Data Management. זה סעיף קטן לפי המשקל, אבל הרעיונות שלו (סמכות, התאמה, כללי שרידות) מופיעים בתוך הרבה תרחישים אחרים. המספרים של הפלטפורמה משתנים, אז בדקו את המספרים העדכניים לפני שאתם סומכים עליהם.

לקראת המבחן

סמנו אותן תוך כדי. כל אחת מקשרת למקום שבו היא נלמדת.

MDM-2: רשומת זהב ומערכת אמת

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

MDM-1: טכניקות MDM

• ידע למבחן: אני מכיר את ארבעת סגנונות היישום של MDM, רישום, איחוד, דו-קיום ומרכזי: מה כל אחד מרכז והאם הוא דוחף ערכים חזרה. (הארבעה זה לצד זה)
• אני יודע להבחין בין ארבעת סגנונות ה-MDM: רישום, איחוד, דו-קיום ומרכזי, ולבחור את הקל ביותר שפותר את הבעיה. (הארבעה זה לצד זה)
• אני יודע שמודל נתונים קנוני מאחיד מבנה, אבל לא מכריע בסמכות. (מודל משותף איננו אמת משותפת)
• אני מכיר את הסדר: קודם להאחיד, אחר כך להתאים, ואז לאחד. (קודם להאחיד, אחר כך להתאים, ואז לאחד)
• אני יודע שספים משקפים סובלנות לטעות, ושההעשרה צריכה מקור מתועד. (ספים, בדיקה אנושית והעשרה)
• ידע למבחן: אני מכיר ניהול היררכיות: Parent Account בונה את ההיררכיה (התצוגה ב-Lightning מציגה עד 2,000 חשבונות, בלי חשבונות אישיים), היררכיות מנוהלות לעיתים קרובות בסמכות מפוצלת, ולחברה יכולות להיות כמה היררכיות תקפות. (גם היררכיות הן נתוני אב, היררכיה אחת, כמה מקורות אב)

MDM-3: בחירת המאפיינים המנצחים

• אני מחזיק בנפרד את ההתאמה, המיזוג וכללי השרידות. (התאמה, מיזוג וכללי שרידות)
• אני מכיר את כללי השרידות: העדכני ביותר, השכיח ביותר, עדיפות מקור, ויודע שלכל כלל צריכים להיות בעלים. (כללי שרידות: איזה ערך מנצח?)
• אני יודע שהתאמה לא מחייבת מיזוג, ואני ממזג רק כשיש מנצח ברור, אחרי שהחלטתי קודם מה קורה לרשומות הבת. (התאמה לא מחייבת מיזוג, כלל המיזוג שלי: מנצח ברור)
• ידע למבחן: אני יודע מה מיזוג חשבונות ב-Salesforce עושה: עד שלוש רשומות, רשומה ראשית אחת, Created By ו-Created Date של הוותיקה ביותר נשמרים, האחרות עוברות לסל המיחזור, ואובייקטי נקודות קשר לא ממוזגים בחשבונות אישיים. (מה מיזוג ב-Salesforce באמת עושה)

SDM-3: תמונה אחת של הלקוח

• אני יודע שזיהוי הישויות של Data 360 מקשר פרופילי מקור לפרופיל מאוחד ושומר את הקישורים חזרה: הכי קרוב לרישום. (זיהוי ישויות עונה על “מי?”)
• ידע למבחן: אני מכיר את כללי ההתאמה של Data 360: כל הקריטריונים בכלל חייבים להתאים, כל כלל יכול להתאים; יותר קריטריונים לדיוק, פחות לאיחוד. (כללי התאמה)
• אני מכיר את שיטות ההתאמה (Exact, Exact Normalized, Fuzzy בשלוש רמות דיוק): שיטה פחות מדויקת מעלה את האיחוד, ואת הסיכון להתאמות שגויות. (כללי התאמה)
• ידע למבחן: אני יודע שכללי יישוב (Last Updated, Most Frequent, Source Priority) מחליטים מה הפרופיל המאוחד מציג, אבל לא משנים את המקורות; נקודות קשר לא עוברות יישוב. (גם יישוב איננו ניהול נתוני אב)
• אני יודע לבחור בין ניהול כפילויות, זיהוי ישויות ופלטפורמת MDM ייעודית לפי העבודה. (שלושה כלים לשלוש עבודות)

MDM-4 ונתונים דו-כיווניים

• אני יודע שנתונים דו-כיווניים לא אומרים שני מקורות אב: עריכה ב-Salesforce של שדה שבבעלות ה-ERP היא בקשה, אז מתכננים בקשה ← אימות ← קבלה ← פרסום, עם מצב של המתנה. (נתונים דו-כיווניים לא אומרים שני מקורות אב, כשמקור האב אומר לא)
• אני יודע איך להימנע מלולאות והתנגשויות: להבחין בין שינוי מקורי להד שלו, ולהחליט אילו שדות נוסעים יחד כטרנזקציה אחת. (לולאות והתנגשויות)
• ללקוח אחד בשני ERPs, אני יודע לבחור בין היררכיה, חשבונות עמיתים או חשבון אחד עם רשומת בת לכל ERP, לפי כמה טוב החברה שאתם עובדים איתה שומרת על ה-ERPs שלה מסונכרנים. (לקוח אחד, שני ERPs, שאלו איך הם שומרים את ה-ERPs מסונכרנים)

נקודת ביקורת 1: לחבר את חלק 1 יחד

• ידע למבחן: אני יודע אילו רישיונות חיצוניים כוללים שיתוף סטנדרטי: Customer Community Plus ו-Partner Community, שצריכים תפקידים למשתמשים החיצוניים; Customer Community משתמש ב-sharing sets. (מי רואה מה, ולמי צריך רישיון)

מעבר למבחן

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

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

מונחים שכדאי להכיר

מונח	בשורה אחת
ניהול נתוני אב (MDM)	ביסוס וניהול של הזהות והערכים הסמכותיים של נתוני מפתח על פני מערכות
מפת סמכות (authority map)	לכל מאפיין: מי יוצר אותו, מי הבעלים של ההחלטה, איזו מערכת סמכותית, מי רשאי לשנות אותו
רשומת זהב	החלטה מנוהלת על אילו ערכים סמכותיים
רשומת זהב היברידית	רשומה שחלק מהמאפיינים שלה מנוהלים כנתוני אב במקום אחר ומועתקים פנימה, וחלק בבעלות מקומית
רישום (registry)	MDM שמקשר רשומות כאותה ישות בלי לשנות את המקורות
איחוד (consolidation)	MDM שמשלב נתונים באופן מרכזי, בדרך כלל לאנליטיקה, בלי לדחוף חזרה
דו-קיום (coexistence)	MDM שמחליט על הערך המנוהל ומפרסם אותו חזרה למקורות
MDM מרכזי	MDM שבו נתונים מנוהלים נוצרים במקור האב ומופצים
מודל נתונים קנוני	צורה ארגונית מוסכמת למושג, שמשמשת למיפוי מערכות זו לזו
האחדה (harmonization)	הפיכת ערכים לברי השוואה: פורמטים, קודים וקיצורים סטנדרטיים
התאמה	ההחלטה אם רשומות מייצגות את אותו דבר
כללי שרידות (survivorship)	כללים שקובעים איזה ערך מנצח כשמקורות לא מסכימים
רשומה ראשית (principal)	במיזוג ב-Salesforce, הרשומה ששורדת ושומרת את השדות המוסתרים ושדות הקריאה בלבד שלה
שיטת התאמה (match method)	האופן שבו קריטריון התאמה ב-Data 360 משווה ערכים: exact, exact normalized או fuzzy
זיהוי ישויות (identity resolution)	ההתאמה של Data 360 בין פרופילי מקור לפרופילים מאוחדים
פרופיל מאוחד	אוסף של מפתחות שמקשר רשומות מקור שמייצגות אדם אחד או חברה אחת
כללי יישוב (reconciliation rules)	כללים של Data 360 שקובעים איזה ערך פרופיל מאוחד מציג
היררכיה בסמכות מפוצלת	היררכיה שהענפים שלה בבעלות מערכות שונות

בדקו את עצמכם

תרחישים קצרים בסגנון הקורס. החליטו על התשובה שלכם לפני שאתם פותחים אותה.

1. "Salesforce הוא מקור האמת היחיד שלנו ללקוח." מה אתם שואלים?

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

2. נציגי שירות צריכים לראות שאיש קשר ב-Salesforce הוא אותו אדם שקנה באונליין. אף אחד לא צריך שהמערכות ישתנו. איזה סגנון MDM?

רישום: לקשר את הרשומות כזהות אחת בלי לשנות את המקורות, וזה מה שזיהוי הישויות של Data 360 עושה. בחרו את הדפוס הכי קל שפותר את הבעיה. קראו שוב את רישום: תגידו לי מי זה מי.

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

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

4. רשומות לקוח ממערכת ישנה מיובאות ומתאימות לחשבונות קיימים. למזג אותן?

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

5. הפרופיל המאוחד ב-Data 360 מציג דאלאס. הצוות אומר שדאלאס הוא עכשיו ערך הזהב לכל מערכת. נכון?

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

6. התאמה של רשומות רפואיות מול רשומות שיווק: אותם כללים?

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

7. נציגים רוצים לעדכן מ-Salesforce כתובת חיוב שבבעלות ה-ERP. איך אתם מתכננים את זה?

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

8. ב-Steve Trucking, אותו John Smith מופיע במניפסטים של שני שותפים קמעונאיים. לאחד אותו?

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

9. נציג שולח רחוב חדש לכתובת שבבעלות ה-ERP בזמן שבאותה דקה מישהו ב-ERP משנה את העיר. מה אתם מחליטים?

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

10. לחברה שאתם עובדים איתה יש לקוח אחד בשני ERPs, ואף אחד לא שומר את שתי הרשומות מסונכרנות. המכירות רוצות חשבון אחד. מה אתם ממליצים?

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

להרחבה

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (באנגלית, נבדק ב-2026-09-25): הרשימה הרשמית של היעדים והמשקלים שלהם. תמיד בדקו את הגרסה העדכנית לפני שאתם קובעים מועד למבחן.
• בקטע “להרחבה” של כל יחידה מפורט התיעוד של Salesforce שמאחורי העובדות שלה, עם תאריך הבדיקה.