בנו את המודל הלוגי

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

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

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

שב, חכה, תמדל

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

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

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

איזה כלב הוא איזה? נסו קודם את השם. יש הרבה כלבים בשם Max, אז השם לא ייחודי. מספר הטלפון של הבעלים? ל-Marcus יש שני כלבים על אותו טלפון, אנשים מחליפים מספרים, וזה מידע אישי של מישהו, שהיה מועתק לכל מערכת שאי פעם מצביעה על כלב. מספר השבב נראה טוב יותר: הוא ייחודי, והוא לא משתנה. אבל לגור חדש אולי עוד אין שבב, ומפתח לא יכול להיות ריק. אז השבב נשאר, כמשהו שהכלב מוכר גם לפיו, והכלב מקבל מזהה כלב (Dog ID) משלו: מספר שעושה עבודה משעממת אחת, להבדיל בין כלב אחד לאחר.

Click to enlarge

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

המושגי אומר לי מה קיים; הלוגי אומר לי מה זה אומר כנתונים

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

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

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

Click to enlarge

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

מאפיינים צריכים לתאר את הישות

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

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

ואז צריך לדבר על מזהים ייחודיים

מאפיינים מתארים דברים. אבל יש עוד בעיה לפתור: איך אני יודע איזה דבר הוא איזה?

שני נמענים נקראים John Smith. האם זה אותו אדם? אולי; ואולי לא. שם לא מספיק. כתובת? אנשים עוברים דירה. מספרי טלפון משתנים. כתובות אימייל משתנות. אפילו השם של שותף קמעונאי יכול להשתנות.

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

ייחודי. לא משתנה. חסר משמעות. לעולם לא PII.

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

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

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

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

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

אז הכלל שלי הוא: ייחודי, לא משתנה, חסר משמעות, לעולם לא PII.

מפתחות טבעיים ומפתחות חלופיים

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

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

לדבר אחד יכולים להיות כמה מזהים שימושיים

מזהה הרשומה הפנימי הוא לא בהכרח המזהה שכל מערכת אחרת משתמשת בו. Steve Trucking עשויה לזהות משלוח באופן פנימי עם מזהה שנוצר אוטומטית. כל שותף קמעונאי מכיר את אותו משלוח לפי מספר ההזמנה שלו: Keystone במניפסט ה-CSV שלה, Redrock ב-API שלה, Brightwave בהודעות ה-EDI שלה. ושמונה השנים של ההיסטוריה ב-RouteDesk, כלי השיבוץ הישן, משתמשות במזהי המשלוח של RouteDesk עצמו.

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

קשרים תלויים במזהים ייחודיים

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

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

Click to enlarge

בשלב הזה אולי אתם חושבים: “Salesforce נותנת מזהה לכל רשומה.” נכון, ונגיע לזה. אם הנתונים חיים ב-Salesforce, כל רשומה מקבלת מזהה ש-Salesforce יוצרת. הוא מוצפן למראה וקשה לקריאה, אז בדרך כלל אנחנו גם חושפים שדה מזהה שאנשים יכולים להשתמש בו, כמו מספר משלוח D-000184227, שדה Auto Number. אנשים חושבים הרבה פעמים שהמספר הזה הוא המזהה של הרשומה, אבל הוא לא: המזהה של Salesforce עדיין נמצא שם מתחת. למערכת חיצונית או למסד נתונים, Oracle או SQL Server, יש גם מזהים ייחודיים משלהם. אבל הארכיטקטורה עשויה לכלול בסוף את Salesforce, את ה-ERP הפיננסי, את Snowflake, את Data 360, את המערכות של השותפים ומערכות שעוד לא קיימות. המודל הלוגי מתאר את הנתונים העסקיים בלי לגרום לכל החלטה להיות תלויה בטכנולוגיה אחת. איך Salesforce מממשת אותו פיזית זה שלב מאוחר יותר.

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

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

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

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

להרחבה

• Custom Field Types (opens in a new tab), Salesforce Help (באנגלית, נבדק ב-2026-10-09): Auto Number מקצה לכל רשומה מספר ייחודי עם פורמט תצוגה, כמו קידומת ואפסים מובילים; הוא לא מזהה ה-Salesforce של הרשומה. ראו גם Auto-Number Fields Are Not Always Sequential (opens in a new tab) (באנגלית, נבדק ב-2026-10-09).