מודל הנתונים הוא השלד

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

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

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

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

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

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

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

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

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

התחילו מהעסק

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

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

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

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

לתמוך. לגדול. לבצע.

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

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

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

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

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

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

Click to enlarge

שטוח מדי, מסובך מדי, או פשוט שגוי

ראיתי מודלי נתונים משתבשים בשלוש דרכים.

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

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

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

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

Click to enlarge

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

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

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

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

להוסיף במקום לשנות. להוציא משימוש במקום להפתיע.

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

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

Click to enlarge

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

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

השלד קודם לכול

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

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

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

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

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

להרחבה

• Considerations for Converting the Field Type of a Custom Field (opens in a new tab), Salesforce Help (באנגלית, נבדק ב-2026-10-02; נבדק שוב ב-2026-10-12): אילו שינויי סוג עלולים לאבד נתונים, ולמה אי אפשר לשנות את הסוג של שדה ש-Apex, flows או processes מפנים אליו.
• Data Classification Metadata Fields (opens in a new tab), Salesforce Help (באנגלית, נבדק ב-2026-10-02; נבדק שוב ב-2026-10-12): ערכי Field Usage (Active, DeprecateCandidate, Hidden), ושאר שדות הסיווג.