הפכו את המודל ל-Salesforce

🌐 זמין גם ב-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 מתוך 6 בפרק מידול נתונים למען המשמעות, הפרק השני בקורס Data Architect. כל יחידה עומדת בפני עצמה. הקודם: תכננו לצורה הנורמלית השלישית, ואז קחו צעד אחורה · הבא: מדריך הלימוד של הפרק, ואחריו הפרק הבא: ארכיטקטורת הנתונים של Salesforce

השאלה שהיחידה הזו עונה עליה: איך מודל נתונים לוגי הופך למודל נתונים פיזי ב-Salesforce?

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

שב, חכה, תמדל

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

מי העסקים ומי האנשים? המגדל הוא עסק, אז הוא הופך לחשבון (Account) עם סוג רשומה Breeder (מגדל). גם הבעלים הם חשבון, או חשבון אישי, עם סוג רשומה Owner (בעלים). שני סוגים של אותו אובייקט סטנדרטי, זה לצד זה בראש התרשים, בדיוק איפה שהם נמצאים מאז יחידה 1.

למה אין בית סטנדרטי? חיית מחמד, גזע, תרגיל, תרגיל של חיית מחמד והערכת תרגיל הופכים לאובייקטים מותאמים אישית. וזוכרים את המין שהעתקנו לחיית המחמד ביחידה 5? כאן הוא מקבל את התפקיד שלו: הוא הופך לסוג הרשומה של חיית המחמד, Dog (כלב) או Cat (חתול). אובייקט אחד עם שני סוגי רשומה, כל אחד עם פריסת עמוד וערכי רשימת בחירה משלו, במקום אובייקט כלב ואובייקט חתול.

אילו קשרים הם master-detail? אני משתמש ב-master-detail רק כשהילד לעולם לא יעבור להורה אחר. תרגיל של חיית מחמד שייך לחיית המחמד שלו לכל החיים, וכל הערכת תרגיל שייכת לתרגיל של חיית המחמד שלה, אז שניהם master-detail. זה משתלם מיד: master-detail הוא מה שמאפשר לחיית המחמד להחזיק שדה סיכום מצטבר (roll-up summary) של התרגילים שלה, כך שספירת התרגילים שנלמדו מיחידה 5 נשארת מתואמת מעצמה. אבל חיות מחמד כן מחליפות בית, אז הבעלים הם lookup.

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

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

Click to enlarge

כל החלטה בתרשים הזה מתחקה אחורה למשהו שהחלטנו קודם, וזו בדיוק הנקודה. עכשיו אותו שלב ל-Steve Trucking.

התחילו מהמודל הלוגי

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

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

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

ישות עסקית היא לא אוטומטית אובייקט מותאם אישית

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

מאפיינים הופכים לשדות פיזיים

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

Click to enlarge

קשרים הופכים להחלטות פלטפורמה

כל הזמן שהשקענו בקשרים משתלם כאן. אנחנו כבר יודעים אם כל קשר הוא אחד-לאחד, אחד-לרבים או רבים-לרבים, חובה או רשות, והאם ההיסטוריה שלו חשובה. עכשיו אנחנו מחליטים איך Salesforce מממשת אותו: lookup, master-detail, או אובייקט צומת של Salesforce (Salesforce Junction Object), ואולי אובייקט צומת עם מאפיינים משלו, כי, כמו שמצאנו, לקשר עצמו יכולה להיות משמעות עסקית.

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

עכשיו שרטטו את המודל הפיזי

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

Click to enlarge

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

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

המודל הפיזי צריך לכבד את הפלטפורמה

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

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

אל תתכננו מתוך Setup

יש הרגל שאני רוצה שתשברו אם יש לכם אותו: להתחיל את ארכיטקטורת הנתונים ב-Setup → Object Manager → New Custom Object ולהבין את המודל תוך כדי. Salesforce הופכת יצירה של דברים לקלה להפליא; זו אחת החוזקות שלה, ואחת הסיבות שמודלי נתונים חלשים נוצרים כל כך מהר. כמה קליקים ויש לכם אובייקט, עוד כמה ויש לכם שדות וקשר. ואז מגיעים נתונים, נבנים Flows, נוצרים דוחות, אינטגרציות תלויות בו, והאובייקט שיצרתם בחמש דקות הופך ליקר מאוד לשינוי. זה מבחן ההפיכות מפרק 1. אז לפני שאתם לוחצים על New Custom Object, שרטטו את המודל.

פיזי לא אומר קבוע

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

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

כשאני הופך מודל לוגי למודל פיזי ב-Salesforce, אני מחליט:

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

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

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

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

להרחבה

• Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab), Salesforce Developers, Winter ‘27 (באנגלית, נבדק ב-2026-10-02): “הגדירו קשרי הורה-ילד עם לא יותר מ-10,000 ילדים לרשומת הורה אחת.” זו הנחיה לגבי data skew, לא מגבלה קשיחה; פרק 7 מעמיק בזה.
• Roll-Up Summary Field (opens in a new tab), Salesforce Help (באנגלית, נבדק ב-2026-10-12): שדה סיכום מצטבר (roll-up summary) סופר או מסכם רשומות detail דרך קשר master-detail.