הבנת נתוני הארגון

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

An open sketchbook on a drafting table at dawn, a building sketched on one page and a data model on the other, with a pencil, an eraser, a cup and a lamp. — התמונה נוצרה בבינה מלאכותית

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

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

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

לקראת המבחן

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

של מי הנתונים (תומך ב-SDM-2, ב-SDM-3 ובפרק נתוני אב)

אני יודע לומר איזו מערכת היא מערכת הרשומה (system of record) לכל סוג נתונים, ואני משלים את המשפט: מערכת רשומה של מה? (Salesforce היא לעיתים קרובות לא מערכת הרשומה, אל תתחילו משם המוצר)
אני מכיר את הדפוס הנפוץ: לקוחות, מוצרים ומחירים נכנסים מה-ERP, הזמנות יוצאות, ושחץ ההזמנות תלוי באחרים; ואז אני שואל על הדרך חזרה. (האינטגרציה שאני רואה שוב ושוב, חצים חד-כיווניים מלחיצים אותי)
אני שואל שלוש שאלות על נתוני אב: איפה הם נוצרים, איפה הם נערכים, ואיפה מפנים אליהם? (ארבע השאלות שמאחורי הקטגוריות)
אני יודע שעותק הוא לא סמכות: נתונים שבבעלות ה-ERP נקראים מקומית ונכתבים בצורה מבוקרת, עם המזהה שלהם מה-ERP שנשמר כ-External ID. (ה-ERP: לבק-אופיס יש כוח משיכה, מפת המערכות משנה את מודל הנתונים)

סוגי הנתונים ועומסי העבודה שלהם (תומך ב-DM-1, ב-LDV-1 וב-MDM-4)

אני יודע להבחין בין נתוני אב, ייחוס, תנועות, מטא-דאטה, אנליטיים ולא מובנים, ומה כל אחד מהם אומר על המקום שבו הוא חי. (התחילו מהסוג, לא מהאובייקט)
אני יודע שנתוני ייחוס הם קטנים, אבל שם מסתתרות הנחות האינטגרציה (Delivered, Complete, D). (נתוני ייחוס)
אני יודע להבחין בין עומסי עבודה תפעוליים (OLTP), אנליטיים (OLAP) וזורמים: ה-org מפעיל את העסק, מחסני נתונים ואגמי נתונים מנתחים אותו. (הסוג הוא רק חצי מהשאלה)
אני מכיר סינכרוני (מחכים בדלת), אסינכרוני (ממשיכים הלאה ומטפלים בזה כשזה חוזר) ואצווה (כל שעה, כל כמה שעות, יומי), מתי אצווה מספיקה, ושלזמן אמת יש מחיר. (כמה מהר זה צריך לזוז?)
אני שואל את ארבע השאלות על כל מערך נתונים: של מי הוא, כמה מהר הוא משתנה, כמה גדול הוא נעשה, ומה מחזור החיים שלו. (ארבע השאלות שמאחורי הקטגוריות)

המערכות שמסביב ל-Salesforce (תומך ב-SDM-3, ב-LDV-3 ובפרקי האינטגרציה)

אני מכיר את ארבעת התפקידים של מערכות: רשומה, מעורבות, ייחוס ותובנות. (אל תתחילו משם המוצר)
אני יודע שהמקום שבו האנליטיקה חיה הולך אחרי המקום שבו הנתונים חיים: דוחות הליבה כשהכול ב-Salesforce; פלטפורמת אנליטיקה (Tableau, כולל Tableau Next, או CRM Analytics היכן שהוא בשימוש) או מחסן הנתונים כשמעורבים מאגרים אחרים. (האנליטיקה חיה איפה שהנתונים חיים)
אני יודע מה זה מחסן נתונים (warehouse), אגם נתונים (lake) ו-lakehouse, ומה התפקיד של MDM, של ESB או iPaaS, ושל אירועים. (מחסן הנתונים, אגם הנתונים וה-Lakehouse, שכבת האינטגרציה והאירועים)
אני שם את ספק הזהויות על מפת המערכות מהיום הראשון, ואני יודע שהגדרות SSO עוברות בפריסה אבל סודות ותעודות לא עוברים; על מפת המערכות זו תעודה משותפת (אמון), לא קריאה, כי הכניסה עוברת דרך הדפדפן. (המערכת שמפתחים שוכחים: זהות)
אני יודע ש-Data 360 הוא קרוב לליבה (near-core) (מנוהל על הליבה, מתארח מחוץ לליבה), ושה-zero copy שלו מאפשר לשאול נתונים בלי להעתיק אותם. (איפה Data 360 יושב?, ליבה, מחוץ לליבה ו-Hyperforce)

orgs ואירוח (תומך ב-SDM-4)

אני מתחיל מorg אחד ומחפש גבול אמיתי (מיקום הנתונים, רגולציה, הפרדה משפטית, מודל תפעול שונה, רכישה) לפני שאני מוסיף עוד אחד. (התחילו מ-org אחד, חפשו גבולות אמיתיים)
אני יודע מה עולים כמה orgs: דיווח גלובלי, נתוני אב, אינטגרציה, זהות ופריסות, כל אחד מהם מוכפל. (עברו שוב על החצים)
אני יודע ש-Hyperforce נותן בחירה של האזור שבו נמצאים הנתונים של org (לא של ספק הענן), אבל לא מבטיח שכל שירות יישאר שם; ושה-GDPR לא מחייב כשלעצמו org נפרד: הוא קובע כללים למידע אישי שיוצא מהאיחוד האירופי, וחברה יכולה לבחור ב-org אירופי כדי לעמוד בהם. (האירוח הוא חלק מהשרטוט, כשאירופה מקבלת org משלה)

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

אני יודע לשרטט מפת מערכות: אנשים משמאל, Salesforce באמצע עם הקהילות שלו נוגעות מלמטה, זהות מעל, אינטגרציה ובק-אופיס מימין, Data 360 מתחת לשכבת האינטגרציה, ערוצים למטה, נתונים נכנסים ויוצאים בפינה הימנית התחתונה. (פריסת מפת המערכות של Steve)
על מפת מערכות, חץ מתחיל במערכת שפותחת את החיבור והתווית שלו אומרת מה זז ולאיזה כיוון; בתרשים זרימת נתונים, החצים הולכים אחרי הנתונים. שתי זרימות הן שני חצים. (עכשיו שרטטו את החצים)
לכל חץ אני יודע במה הלקוח מטפל ומה השרת מגדיר: לאן, אימות, פרוטוקול וחוזה, מטען, תזמון, מעקב, שגיאות. Named Credential וה-External Credential שלו כש-Salesforce קורא החוצה; External Client App ומשתמש אינטגרציה של API בלבד כשמשהו קורא ל-Salesforce. (לכל חץ צריך מנגנון)
אני סופר לפני שאני משרטט את החצים: הנפח נכנס למלאי ומכתיב את המנגנון, ויכול אפילו לשנות את הכיוון שאליו החץ מצביע. (מכניסים את האפסים למלאי)
אני משרטט תרשים מסלולים (swim lane) רק כשבתהליך יש יותר מחילופי דברים אחד או שניים הלוך ושוב. (חצים על מפת המערכות, שיחות בתרשים מסלולים)

מעבר למבחן

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

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

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

מונח	בשורה אחת
מפת המערכות	המערכות שמסביב ל-Salesforce, האנשים שמשתמשים בהן, והזרימות החשובות ביניהן
מערכת רשומה (system of record)	המקום שבו נשמרת הגרסה הסמכותית של סוג נתונים
מערכת מעורבות	המקום שבו אנשים עושים את העבודה
מערכת ייחוס	המקום שבו מערכת מחפשת מידע שהיא צריכה אבל לא מחזיקה בבעלותה
מערכת תובנות	המקום שבו נתונים מתכנסים כדי למדוד, לנתח ולחזות
ERP	מערכת הבק-אופיס לכספים, מוצרים, מלאי, רכש ואספקה
נתוני אב	הדברים היציבים שהעסק סובב סביבם: לקוחות, מוצרים, מיקומים
נתוני ייחוס	אוצר המילים המשותף שמסווג נתונים אחרים: קודים, סטטוסים, קטגוריות
נתוני תנועות	רשומות של מה שקרה: הזמנות, משלוחים, תשלומים, פניות
נתונים אנליטיים	נתונים שנגזרים מנתונים אחרים כדי למדוד ולהשוות
נתונים לא מובנים	מסמכים, תמונות, אודיו, וידאו, תמלולים
מחסן נתונים / אגם נתונים / lakehouse	מאגר אנליטי מובנה / מאגר גולמי בקנה מידה גדול / שילוב של השניים
ESB / iPaaS	שכבת אינטגרציה שמתווכת בין מערכות
OLTP / OLAP	עבודה תפעולית על מעט רשומות בכל פעם / ניתוח על פני רבות
קרוב לליבה (near-core)	מנוהל על הליבה, מתארח מחוץ לליבה: Data 360
Named Credential / External Credential	המקום שבו Salesforce שומר נקודת קצה יוצאת / את האימות שלה
External Client App	הדרך שבה מערכת חיצונית מקבלת הרשאה לקרוא ל-Salesforce
מצב נוכחי	מפת המערכות כפי שהיא היום, לפני התכנון; מסומנת במה שלא תקין
ספק זהויות (IdP)	המערכת שמאמתת משתמשים וקובעת את הזהות ש-Salesforce סומך עליה
סינכרוני / אסינכרוני / אצווה	מחכים לתשובה / ממשיכים הלאה ומטפלים בזה כשזה מגיע / מעבירים נתונים כקבוצה לפי לוח זמנים
Hyperforce	Salesforce על תשתית ענן ציבורי, עם בחירת אזור
Zero copy	שאילת נתונים במקום שבו הם חיים, בלי להעתיק אותם

בדקו את עצמכם

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

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

של מי הלקוח בכל שלב; המספר של ה-ERP כ-External ID על החשבון (Account); אילו שדות Salesforce רשאי לשנות; כמה מהר שינויים מה-ERP מגיעים; ומה חוזר אחרי שהזמנה נשלחת (התקבלה, נדחתה, נשלחה, חויבה). קראו שוב את מפת המערכות משנה את מודל הנתונים.

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

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

3. חברה פועלת ב-30 מדינות ומבקשת org אחד לכל מדינה. מה אתם שואלים?

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

4. המשאיות שולחות 200,000 קריאות GPS ביום. האם Salesforce צריך לשמור את כולן?

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

5. הצוותים עובדים על העצירות שלהם ב-Salesforce, אבל המסלולים נבנים בכלי שיבוץ ישן, ושום דבר לא מחבר בין השניים. איך משרטטים את היום?

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

6. מישהו אומר שחוק הפרטיות האירופי מחייב org נפרד. איך אתם מגיבים?

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

7. Salesforce שולח הזמנות ל-API של ה-ERP. איזה צד מטפל בניסיונות חוזרים, ואיפה Salesforce שומר את הסוד?

Salesforce הוא הלקוח: הוא פותח את החיבור, רואה את כל הסבב הלוך ושוב, והוא הצד היחיד שיכול לנסות שוב. Named Credential מחזיק את נקודת הקצה, וה-External Credential שלו את האימות. ה-ERP, השרת, מגדיר את החוזה ומאמת את מה שנכנס. קראו שוב את לכל חץ צריך מנגנון.

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

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

להרחבה

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