מידול נתונים למען המשמעות
זמין גם ב-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 בקורס Data Architect. קראו קודם את שש היחידות; העמוד הזה עוזר לכם לבדוק מה נקלט.
על מדריך הלימוד הזה. הוא בנוי רק מהתוכן של הקורס הזה ומרשימת היעדים במדריך המבחן הרשמי של Salesforce. הוא אף פעם לא מבוסס על שאלות מבחן אמיתיות, והוא לא מתיימר לדעת מה יש במבחן. אם ניגשתם למבחן, בבקשה אל תשלחו לי שאלות ממנו: הסכם ההסמכה אוסר לשתף אותן, ושינון תשובות הוא בכל מקרה הדרך הלא נכונה להפוך לארכיטקט.
הפרק הזה הוא הבסיס לחלק Data Modeling and Database Design במבחן, שהוא רבע מהמבחן. הוא מכסה את החשיבה; הפרק הבא, ארכיטקטורת הנתונים של Salesforce, מכסה איך הפלטפורמה בונה אותה. לכן רוב מה שנבחן על אובייקטים, שדות וקשרים דורש את שני הפרקים.
לקראת המבחן
Section titled “לקראת המבחן ”הנקודות מהפרק הזה שהכי סביר שיהיו חשובות במבחן. כל אחת קשורה ליעד המבחן שלה ומקשרת למקום שבו היא נלמדת. סמנו אותן תוך כדי.
DM-1: השוואת טכניקות לתכנון מודל נתונים ב-Salesforce
- אני יכול להסביר את ההבדל בין מודל נתונים מושגי, לוגי ופיזי, ולמה כל אחד מהם משמש. (הפכו את המודל ל-Salesforce)
- אני יכול למצוא ישויות מועמדות בדרישה, ולהבחין בין אדם שעושה תפקיד לבין פיסת נתונים. (שמות עצם נותנים לכם ישויות מועמדות)
- אני יכול לקרוא ולשרטט סימון רגל העורב (crow’s foot): אחד, רבים, והסימן השני לרשות או לחובה. (לקרוא את הקווים, גם חובה או רשות חשובים)
- אני יכול לקבוע את הקרדינליות של קשר: אחד-לאחד, אחד-לרבים, רבים-לרבים. (שאלו “אחד או רבים?”)
- אני יודע שקשר של רבים-לרבים הופך לישות משלו, וב-Salesforce בדרך כלל לאובייקט צומת (junction object) עם שני הורים. (קשרים יכולים להפוך לדברים)
- אני יודע מתי קשר צריך היסטוריה (רשומה עם תאריכי התחלה וסיום) במקום שדה שנדרס. (הזמן משנה קשרים)
- אני יכול לבחור מזהה ייחודי טוב, ואני יודע למה מפתח טבעי או כל דבר עם מידע אישי הוא בחירה מסוכנת. (ואז צריך לדבר על מזהים ייחודיים)
- אני יודע את ההבדל בין מפתח טבעי למפתח חלופי (surrogate), ושרשומה אחת יכולה לשאת כמה מזהים חיצוניים. (מפתחות טבעיים ומפתחות חלופיים)
- אני יודע ששדה Auto Number הוא מספר קריא, לא מזהה ה-Salesforce של הרשומה. (קשרים תלויים במזהים ייחודיים)
- אני יכול ליישם את הצורה הנורמלית הראשונה, השנייה והשלישית, ולזהות שדה שמחזיק כמה ערכים או חוזר על עובדה על משהו אחר. (דרך פשוטה לחשוב על 1NF, 2NF ו-3NF)
- אני יכול להסביר מתי לבצע דה-נרמול בכוונה (משתמשים, דיווח, קנה מידה), ומה זה עולה. (תכננו לצורה הנורמלית השלישית, ואז קחו צעד אחורה)
- אני יכול להחליט בין רשימת בחירה לבין lookup לאובייקט עבור רשימת ערכים. (lookup או רשימת בחירה?)
- אני יודע שסוג דוח מותאם אישית מאפשר לכל היותר ארבעה קשרי אובייקטים, ולמה זה חשוב במודלים עמוקים. (lookup או רשימת בחירה?)
- אני יודע מתי master-detail מתאים (הילד לעולם לא עובר להורה אחר) ומתי lookup בטוח יותר, כולל ההנחיה של Salesforce של לא יותר מ-10,000 ילדים להורה אחד. (קשרים הופכים להחלטות פלטפורמה)
- אני יודע למה כדאי להימנע מקשרים פולימורפיים איפה שאפשר. (קשרים הופכים להחלטות פלטפורמה)
- אני יודע שישות עסקית היא לא אוטומטית אובייקט מותאם אישית: היא יכולה להיות אובייקט סטנדרטי, שדה, הגדרה, או נתונים שחיים מחוץ ל-Salesforce. (ישות עסקית היא לא אוטומטית אובייקט מותאם אישית)
מעבר למבחן
Section titled “מעבר למבחן ”המבחן הוא הרצפה, לא התקרה. אלה ההרגלים מהפרק הזה שארכיטקט צריך, בין אם שאלה אי פעם תשאל עליהם ובין אם לא.
- שכחו מ-Salesforce לרגע. מדלו את העסק לפני שאתם ממפים אותו לחשבון ולאיש קשר.
- הקשיבו למילה שמסתירה שני דברים. ב-Steve Trucking, “לקוח” היה שותף קמעונאי ונמען.
- המודל הוא חלק מהשיחה. המודל הראשון שלכם לא אמור להיות נכון; הוא אמור להראות לכם איפה אתם טועים.
- תנו שמות לקווים. שני מודלים עם אותן קופסאות יכולים לומר דברים שונים.
- שאלו “עכשיו, או לאורך זמן?” על כל קשר.
- ייחודי, לא משתנה, חסר משמעות, לעולם לא PII.
- שימו עובדה במקום שבו היא שייכת, ואז קחו צעד אחורה בכוונה, ותעדו למה.
- דה-נרמול לא מסיר מורכבות; הוא מזיז אותה. דעו למי שייכת האמת.
- מקור אמת אחד, הרבה צורות: מסכים, דוחות, מחסן הנתונים ובינה מלאכותית.
- אל תתכננו מתוך Setup. שרטטו את המודל לפני שאתם לוחצים על New Custom Object.
- התחקו אחורה אחרי כל החלטה פיזית עד למשהו שהעסק צריך.
מונחים שכדאי להכיר
Section titled “מונחים שכדאי להכיר ”| מונח | בשורה אחת |
|---|---|
| ישות | דבר שאכפת לעסק ממנו ושומרים עליו נתונים |
| ישות מועמדת | שם עצם שעשוי להפוך לישות, אחרי ששאלתם עליו |
| מאפיין | עובדה שמתארת ישות |
| קשר | האופן שבו שתי ישויות מחוברות, עם שם בשפה של העסק |
| קרדינליות | כמה מאחד קשורים לכמה מהשני |
| אופציונליות (חובה או רשות) | האם הקשר הוא חובה, או שיכול להיות אפס |
| רגל עורב (crow’s foot) | הסימן ל”רבים” בקצה של קו |
| אובייקט צומת (junction object) | הדרך של Salesforce לבנות קשר של רבים-לרבים: ילד של שני ההורים |
| מודל מושגי | מה קיים בעסק ואיך זה קשור; בלי Salesforce |
| מודל לוגי | הנתונים: מאפיינים, מזהים ייחודיים וקשרים, עדיין לא קשורים לפלטפורמה |
| מודל פיזי | איך הפלטפורמה תבנה את זה: אובייקטים, שדות וסוגי קשרים |
| מפתח טבעי | מזהה שכבר קיים בעסק, כמו מספר השלדה (VIN) של משאית |
| מפתח חלופי (surrogate) | מזהה שנוצר רק כדי לזהות את הרשומה |
| מזהה חיצוני | המזהה של מערכת אחרת לאותה רשומה, נשמר וממופה |
| נרמול (1NF, 2NF, 3NF) | לשים כל עובדה במקום שבו היא שייכת: ערך אחד בכל שדה, עובדות על המפתח כולו, בלי עובדות על עובדות אחרות |
| דה-נרמול | העתקה או שיטוח של נתונים בכוונה, מסיבה שאפשר לנקוב בה |
| אנומליית עדכון | אותה עובדה שמורה בהרבה מקומות, כך ששינוי אחד משאיר חלק מהעותקים שגויים |
בדקו את עצמכם
Section titled “בדקו את עצמכם ”תרחישים קצרים בסגנון הקורס. החליטו על התשובה שלכם לפני שאתם פותחים אותה.
1. עסק אומר לכם שצוות נוהג במשאית. שישה שבועות אחר כך, מישהו שואל איזה צוות היה עם משאית 117 ביום מסוים. מה המודל היה צריך לכלול?
שיבוץ צוות (Crew Assignment): הקשר בין צוות למשאית כרשומה משלו, עם תאריך התחלה, תאריך סיום והמסלול. צוותים ומשאיות הם רבים-לרבים לאורך זמן, ולעסק אכפת מההיסטוריה. שדה על המשאית היה נדרס. קראו שוב את הזמן משנה קשרים.
2. צוות מציע להשתמש במספר הטלפון של כל נמען כמזהה הייחודי, "כי הוא ייחודי." מה אתם אומרים?
הוא נכשל במבחנים: מספרי טלפון משתנים ומשותפים, אז הוא לא קבוע ולא ייחודי באופן אמין, והוא מידע אישי שהיה מועתק לכל מערכת שמקשרת לרשומה. השתמשו במזהה חסר משמעות שנוצר אוטומטית, ושמרו את מספר הטלפון כמאפיין. קראו שוב את ואז צריך לדבר על מזהים ייחודיים.
3. למשלוח יש שדות Item 1, Item 2 ו-Item 3. מגיע משלוח עם ארבעה פריטים. מה הבעיה האמיתית, ומה התיקון?
המודל הסתיר מבנה שחוזר על עצמו בתוך שדות (בעיה של צורה נורמלית ראשונה). התיקון הוא לא שדה Item 4; הוא ישות פריט משלוח, ילד של המשלוח, כך שכל פריט הוא רשומה. קראו שוב את צורה נורמלית ראשונה.
4. כל משלוח שומר את שם המנהל של מרכז ההפצה. המנהל מתחלף. מה השתבש?
עובדה על משהו אחר (מרכז ההפצה) נשמרה על המשלוח: בעיה של צורה נורמלית שלישית, ועכשיו אנומליית עדכון במאות רשומות. המנהל שייך למרכז ההפצה; המשלוח מצביע על מרכז ההפצה. קראו שוב את צורה נורמלית שלישית.
5. סוג העצירה (משלוח בלבד, עם התקנה, עם פינוי) צריך משך זמן, מיומנויות צוות ורשימת בדיקה. רשימת בחירה או אובייקט?
אובייקט. יש לו יותר מעמודה אחת של מידע, העסק מנהל אותו, והוא משתנה בקצב משלו. הסטטוס של משלוח, רשימה קצרה ויציבה של תוויות, נשאר רשימת בחירה. קראו שוב את lookup או רשימת בחירה?.
6. השותפים רוצים כרטיס ציון של עמידה בזמנים לפי אזור, והאזור חי על מרכז ההפצה. אתם מעתיקים את האזור לכל משלוח. מה אתם חייבים להחליט?
למי שייכת האמת, איך העותק נשאר מסונכרן, והאם משלוחים ישנים צריכים לשמור את האזור שהיה נכון כשהם קרו או לעקוב אחרי מרכז ההפצה אם הוא עובר. הדה-נרמול הזיז את המורכבות; הוא לא הסיר אותה. קראו שוב את לפעמים הדיווח מנצח.
7. תרגיל כמו שב יכול להיות מקושר למאות אלפי חיות מחמד. master-detail או lookup מתרגיל של חיית מחמד לתרגיל?
lookup. ההנחיה של Salesforce היא לא יותר מ-10,000 ילדים להורה אחד, ותרגיל פופולרי יעבור אותה. master-detail מתאים מתרגיל של חיית מחמד לחיית המחמד, כי תרגיל של חיית מחמד לעולם לא עובר להורה אחר וחיית מחמד אחת יודעת רק כמה תרגילים; זה גם מה שמאפשר לחיית המחמד לסכם את ספירת התרגילים שנלמדו שלה. קראו שוב את שב, חכה, תמדל.
להרחבה
Section titled “להרחבה ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (באנגלית, נבדק ב-2026-09-25): הרשימה הרשמית של היעדים והמשקלים שלהם. תמיד בדקו את הגרסה העדכנית לפני שאתם קובעים מועד למבחן.
