לחשוב כמו ארכיטקט נתונים

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

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

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

מדריך הלימוד לפרק 1 בקורס Data Architect. קראו קודם את שבע היחידות; העמוד הזה עוזר לכם לבדוק מה נקלט.

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

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

לקראת המבחן

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

לקרוא תרחיש כמו ארכיטקט (תומך בכל היעדים)

• אני מפריד בין הדרישה האמיתית לבין התכנון שבו היא הגיעה (“אנחנו צריכים שדות Approver 2 ו-Approver 3” לעומת “אנחנו צריכים לעקוב אחרי כל אישור”). (אל תקבלו את הדרישה כמו שהיא)
• אני מחפש את הדרישות המשתמעות שאף אחד לא אמר: בעלות, עדכניות, כישלון, שמירה, גישה. (חפשו את הדרישות המשתמעות)
• אני שם על זה מספרים: נפח ליום, לשנה, עם צמיחה, ושם לב מתי עוד אפס אחד משנה את התשובה. (הכירו את המספרים שלכם)
• מבין כמה תשובות שעובדות, אני משווה מה כל אחת מרוויחה ועל מה היא מוותרת מול הדרישות והמגבלות שנאמרו. (דעו על מה אתם מוותרים, מגבלות משנות את התשובה)
• אני מתייחס לעלות, רישוי ומגבלות כחלק מהשאלה אם כלי מתאים, לא כמחשבה שנייה. (תשע השאלות)

מודל הנתונים (תומך ב-DM-1)

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

שינוי של מה שכבר קיים (תומך ב-DM-1 וב-SDM-2)

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

רישיונות ושיתוף (תומך ב-SDM-1)

• אני יודע שלמשתמשי קהילה בנפח גבוה (ביניהם Customer Community) אין תפקידים והם לא משתמשים במודל השיתוף, ולכן הגישה מגיעה מ-sharing sets ו-share groups, ו-Apex sharing לא יכול להגיע אליהם. (דוגמה מלאה: Apex sharing)

כישלון (תומך ב-MIG-1 ובפרקי האינטגרציה)

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

מעבר למבחן

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

• מישהו צריך להחזיק את התוכנית. ארכיטקטורה היא קבלת החלטות טובות עם מידע חלקי, והכרת ההשלכות שלהן.
• מודל הנתונים הוא השלד. כל השאר נבנה עליו.
• מבחן ההפיכות: כמה קשה להפוך את זה, וכמה דברים יהיו תלויים בזה?
• ארכיטקטורה יוצרת כוח משיכה. התלויות הן שהופכות שינוי ליקר, לא השינוי עצמו.
• חשבו על רדיוס הפגיעה, בתוך Salesforce וברמת הארגון כולו. ארכיטקטורה היא תנועה דו-סטרית.
• כתבו למה: הקשר, אפשרויות, החלטה, השלכות, בעלים, סקירה. החליפו בהחלטה חדשה; אל תמחקו.
• הכי טוב במה? החלטה לא אופטימלית יכולה להיות חלק מארכיטקטורה אופטימלית, אם אתם יודעים שאתם מקבלים אותה.
• החזיקו תמונה של אופטימלי, כדי שתדעו לאיזה כיוון אתם מתרחקים ממנו, ולמה.
• Think Correct. Think Fast. המהירות באה מחשיבה שנעשתה לפני הרגע.
• לבנות להיום. לתכנן למחר. לתכנן לכישלון. והשתמשו ב-30 אחוז צמיחה כשאף אחד לא נותן לכם מספר.
• למדו את תשע השאלות, לא רק את התשובות.
• בינה מלאכותית היא מאיץ רקטה. יצירה היא לא שיקול דעת, מה שבלתי הפיך נשאר בלתי הפיך, וסקירה אנושית היא לא טקס. סמכו אבל אמתו.

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

מונח	בשורה אחת
החלטה ארכיטקטונית	החלטה שקשה להפוך, והרבה תלוי בה
מבחן ההפיכות (Reversibility Test)	כמה קשה להפוך את זה, וכמה דברים יהיו תלויים בזה?
כוח משיכה	התלויות שמצטברות סביב החלטה לאורך זמן
רדיוס הפגיעה (blast radius)	כל מה שזז כשהחלטה משתנה
רשומת החלטה	הקשר, אפשרויות, החלטה, השלכות, בעלים ונקודת סקירה, בקיצור
פשרה (trade-off)	מה אפשרות מרוויחה, ועל מה היא מוותרת כדי להשיג את זה
דרישה משתמעת	משהו שהעסק מצפה לו בלי לבקש, כמו התאוששות כשטעינה נכשלת
“מספר האפסים” של Steve (Steve’s Number of Zeros)	עוד אפס אחד בנפח יכול לשנות את כל הארכיטקטורה
התאמה (reconciliation)	השוואה בין מה שהיה אמור לקרות לבין מה שקרה, רשומה אחר רשומה
הוצאה משימוש (deprecate)	לסמן משהו כנמצא בדרך החוצה, ואז להוציא אותו משימוש באופן מכוון, במקום לשנות אותו במקום
משתמש בנפח גבוה (high-volume user)	משתמש קהילה (Customer Community הוא אחד הרישיונות) בלי תפקיד, מחוץ למודל השיתוף
התפשטות סכמה (schema sprawl)	אובייקטים ושדות שנערמים כי היה זול ליצור אותם, עד שאף אחד לא תכנן את המודל

בדקו את עצמכם

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

1. צוות מכירות מבקש שדות Approver 2 ו-Approver 3, כל אחד עם תאריך, בהזדמנות (Opportunity). מה אתם שואלים, ומה אולי תבנו?

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

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

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

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

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

4. 1,200 סניפים, 100 תורים לסניף ביום, בערך 305 ימים בשנה, שתי רשומות לכל תור, חמש שנים נשמרות, 30 אחוז צמיחה. בערך כמה רשומות, ולמה זה חשוב?

בערך 73 מיליון רשומות בשנה הראשונה (36.6 מיליון תורים, שתי רשומות לכל אחד), ויותר מ-650 מיליון לאורך חמש שנים עם צמיחה. אותו פיצ’ר, עוד כמה אפסים, ארכיטקטורה שונה לגמרי. קראו שוב את הכירו את המספרים שלכם.

5. טעינה לילית מדווחת "הסתיימה" על מיליון רשומות. איך אתם יודעים שהיא עבדה?

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

6. קהילה של 15 מיליון משתמשי Customer Community צריכה גישה מורכבת לרשומות. מישהו מציע Apex sharing. מה הבעיה?

אלה משתמשים בנפח גבוה: בלי תפקידים, מחוץ למודל השיתוף, ולכן אין רשומת שיתוף ש-Apex יכול לכתוב. הגישה מגיעה מ-sharing sets ו-share groups. הרישיון קבע אילו כלי שיתוף קיימים. קראו שוב את דוגמה מלאה: Apex sharing.

7. כלי בינה מלאכותית מייצר עשרים אובייקטים לאפליקציה חדשה בתוך דקות. מה התפקיד של הארכיטקט עכשיו?

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

להרחבה

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