איכות נתונים וממשל נתונים
זמין גם ב-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)
מדריך הלימוד לפרק 5 בקורס Data Architect. קראו קודם את שש היחידות; הדף הזה עוזר לכם לבדוק מה נקלט.
על מדריך הלימוד הזה. הוא בנוי רק מהתוכן של הקורס הזה ומרשימת היעדים במדריך המבחן שפרסמה Salesforce. הוא אף פעם לא מבוסס על שאלות מבחן אמיתיות, והוא לא מתיימר לדעת מה יש במבחן. אם ניגשתם למבחן, בבקשה אל תשלחו לי שאלות ממנו: הסכם ההסמכה אוסר לשתף אותן, ושינון תשובות הוא בכל מקרה הדרך הלא נכונה להפוך לארכיטקט.
הפרק הזה נושא את סעיף Data Governance במבחן (10%) וחלקים מ-Data Modeling (מטא-דאטה) ומ-Salesforce Data Management (עקביות). זה גם המקום שבו חוקי הפרטיות פוגשים את מודל הנתונים. זו ארכיטקטורה, לא ייעוץ משפטי: המחלקה המשפטית מחליטה מה חל, והארכיטקט הופך את זה לאכיף. המספרים של הפלטפורמה משתנים, אז בדקו את המספרים העדכניים לפני שאתם סומכים עליהם.
לקראת המבחן
Section titled “לקראת המבחן ”סמנו אותן תוך כדי. כל אחת מקשרת למקום שבו היא נלמדת.
GOV-2: תכנון תוכנית ממשל נתונים
- אני יודע שבעלי הרשומה (מנגנון גישה של הפלטפורמה) הם לא בעלי הנתונים (שאחראים לנתונים כנכס עסקי), ושבכל שדה אפשר לרשום Data Owner. (בעלי הרשומה הם לא בעלי הנתונים)
- אני יודע להבחין בין בעלי הנתונים (קובעים מדיניות), נאמן הנתונים (שומר שזה יעבוד) והאפוטרופוס (מפעיל את המערכת). (בעלים, נאמן, אפוטרופוס)
- ידע למבחן: אני מכיר את שלוש הדרכים להפעיל תוכנית ממשל נתונים, ריכוזית, פדרטיבית (מבוזרת) והיברידית, ומה כל אחת אומרת על מי קובע מדיניות ואיפה ההגדרות המשותפות חיות. (איך התוכנית פועלת)
- אני יודע להשתמש ב-RACI כדי לענות איפה נתונים נוצרים, נערכים ומופנים. (שה-RACI יצדיק את מקומו)
- אני יודע לציין נקודת אכיפה למדיניות ממשל (הרשאות, אימות, שדות לאינטגרציה בלבד, היסטוריית שדות), ולא רק הדרכה. (ממשל הנתונים צריך להפוך למכני)
- אני יודע שאותות האיכות ששווה למדוד הם אלה שמישהו יפעל לפיהם. (מודדים את מה שמישהו יפעל לפיו)
SDM-2 ו-MDM-4: לא להכניס נתונים גרועים
- אני יודע להחליט אם יצירת חשבונות צריכה להיות פתוחה או נעולה, ואני מכיר את מסלול סוג הרשומה הזמני לחשבונות שמקור האב שלהם הוא ERP. (פתוח או נעול?, הדרך האמצעית)
- אני יודע להגן על מאפיינים מנוהלים (מזהה ERP, שם משפטי) ולהשאיר את השדות של Salesforce עצמו ניתנים לעריכה: רשומת זהב היברידית. ואני יודע ששדה לקריאה בלבד בדף Dynamic Forms הוא לא אכיפה; אבטחה ברמת השדה או כלל אימות הם כן. (מגינים על הרשומה המנוהלת, סוג רשומה לכל זרימה)
- אני יודע שזרימות דו-כיווניות הן הקשות ביותר: אם מקור האב של שדה הוא ה-ERP, Salesforce מבקש לשנות אותו, והתנגשות צריכה כלל (ה-ERP מנצח, דחייה אם הערך השתנה, או שאדם מכריע). (מגינים על הרשומה המנוהלת)
- אני יודע ששדות חובה יכולים לייצר נתונים מזויפים (
N/A,999999), ומה החלופות. (אל תתנו לשדות חובה לייצר נתונים מזויפים) - אני יודע להחליט מה קורה לנתונים נכנסים שנכשלים בבדיקות: לקבל, לדחות או להעביר להסגר, ומי הבעלים של החריגה. (כל גבול של נתונים צריך החלטת איכות)
- אני יודע שגם נתוני ייחוס צריכים מטא-דאטה: הגדרות, בעלים, מקור ומיפויים בין מערכות. (גם נתוני ייחוס צריכים מטא-דאטה)
DM-3: מטא-דאטה עסקי וטכני
- ידע למבחן: אני מבחין בין מטא-דאטה עסקי (משמעות, הגדרות, בעלים, כללים, רגישות) לבין מטא-דאטה טכני (אובייקטים, שדות, סוגים, שמות API, סכמות, מיפויים, שושלת). (שני סוגים של מטא-דאטה)
- אני מכיר את ההבדל בין מילון עסקי (מה זה אומר), שושלת (מאיפה זה הגיע) וסיווג (איך צריך לטפל בזה). (הכירו את הנתונים שלכם)
- אני מכיר את שדות הסיווג של Salesforce: Data Owner, Field Usage, Data Sensitivity Level, Compliance Categorization, בשדות סטנדרטיים ובשדות מותאמים אישית. (הסיווג עונה על שאלה אחרת)
- אני יודע לסווג את השדות הרגישים, לא כל שדה, ושסיווג בלי אכיפה הוא קישוט. (סיווג בלי אכיפה הוא קישוט)
GOV-1: מידע אישי ורגיש
- אני מזהה את החוקים העיקריים (GDPR, CCPA/CPRA, PIPEDA, LGPD, ה-Privacy Act של אוסטרליה, HIPAA, PCI DSS, SOX, COPPA), ואני יודע ש-GDPR יכול לחול על ארגונים מחוץ לאיחוד האירופי, ומה משותף לחוקים: זכויות, העברות, הודעה על פריצת אבטחה ואחריותיות. (הרגולציות שכדאי לזהות, חוקים לא עוצרים בגבול)
- אני מכיר את ההבדל בין הצפנה, מיסוך, פסאודונימיזציה ואנונימיזציה, ושמידע שעבר פסאודונימיזציה הוא עדיין מידע אישי. (מאונמז, מפוסאודונם, מוצפן, ממוסך)
- אני יודע שלאסוף פחות זו בקרת פרטיות, ושהשמירה מתוכננת מראש. (לאסוף פחות זו החלטה ארכיטקטונית, השמירה היא חלק מהמודל)
- אני מכיר את מודל נתוני ההסכמה: הסכמה גלובלית על ה-Individual, הסכמה לערוץ התקשרות, הסכמה לנקודת קשר, ומטרת השימוש בנתונים. (השתמשו במודל ש-Salesforce כבר בנתה)
- אני יודע שלבקשות יש מועדים (GDPR: חודש, עם אפשרות להארכה בעוד חודשיים), ולכן מפת העותקים צריכה להתקיים קודם. (השעון מתקתק)
- אני יודע שהזכות להישכח פירושה למצוא כל עותק (היסטוריה, ארכיונים, אנליטיקה, לוגים, קבצים, טקסט חופשי), ושמדיניות Privacy Center רצה לכל אובייקט מול רשומת לקוח. (עכשיו האדם אומר: תשכחו אותי, Privacy Center הוא כלי)
- אני מכיר את הפשרות של Shield Platform Encryption: אי אפשר לסנן, לקבץ או למיין שדות הסתברותיים ב-SOQL; הצפנה דטרמיניסטית מאפשרת סינון; שדות מוצפנים לא יכולים להניע שיתוף מבוסס קריטריונים. (הצפנה היא בקרה, לא ציות)
- אני יודע לא להעתיק נתונים רגישים מסביבת הייצור לסביבות sandbox, ושאת Data Mask מחליף Data Mask & Seed. (אל תעתיקו את הסיכון של סביבת הייצור ל-sandbox)
- אני מכיר את מעקב היסטוריית השדות (עד 20 שדות לכל אובייקט; 18 חודשים, 24 רק דרך ה-API; בטקסט ארוך נרשמת רק העריכה) לעומת Field Audit Trail (עד 200 שדות, נשמר עד שמוחקים אותו). (גם היסטוריה היא נתונים)
- אני מכיר את תקופת השמירה של לוגים ב-Event Monitoring (יום אחד בלי התוסף לחלק מהאירועים, 30 יום כברירת מחדל איתו, עד 365 בהארכה), ושצריך לייצא אירועים ל-SIEM לפני שצריך אותם: אי אפשר לשלוף לוגים בתשלום מלפני תחילת החוזה. (ביקורת וניטור הם לא אותו דבר)
מעבר למבחן
Section titled “מעבר למבחן ”המבחן הוא הרצפה, לא התקרה. אלה ההרגלים מהפרק הזה שארכיטקט צריך, בין אם שאלה תשאל עליהם ובין אם לא.
- מדיניות בלי נקודת אכיפה היא בעיקר משאלה.
- הבעלים קובעים מדיניות; הארכיטקטים אוכפים אותה. אל תמציאו את המדיניות, ואל תשחקו עורכי דין.
- ממשל נתונים אף פעם לא נגמר. הוא עובד בגאות ובשפל; תכננו את המשוב.
- אל תסמכו על התנהגות טובה. בנו את הבקרה: אנשים, אינטגרציות וסוכנים, כולם טועים.
- לנהל מספיק, לא הכול.
- מנעו קודם את הטעויות היקרות. כפילות עם שנתיים של היסטוריה היא בעיה גדולה.
- הבחינו בין מה שאנשים קוראים לבין מה שמכונות מחליטות על פיו.
- תעדו בהרחבה; סווגו במכוון.
- המידע הרגיש הכי זול לנהל הוא המידע שמעולם לא העתקתם.
- הסכמה היא נתונים, וההרשאה להשתמש בנתונים חייבת להיות ניתנת לייצוג כנתונים.
- שלטו קודם כול לאן מידע אישי הולך, כי מחיקה היא נדירה וקשה.
- ציות הוא לא מוצר.
- איסוף ← סיווג ← הגנה ← שימוש ← שמירה ← מחיקה ← ביקורת.
- אספו את הראיות לפני שמישהו מבקש אותן.
מונחים שכדאי להכיר
Section titled “מונחים שכדאי להכיר ”| מונח | בשורה אחת |
|---|---|
| ממשל נתונים (governance) | המדיניות לגבי נתונים, והארכיטקטורה שהופכת אותה לנכונה |
| בעלי הנתונים | האדם או הפונקציה שאחראים לסוג נתונים |
| נאמן נתונים (data steward) | האדם ששומר על בריאות הנתונים מיום ליום |
| אפוטרופוס נתונים (custodian) | הצוות שמפעיל את המערכות שמחזיקות את הנתונים |
| RACI | Responsible (אחראי לביצוע), Accountable (נושא באחריות), Consulted (מתייעצים איתו), Informed (מעדכנים אותו) |
| רשומה זמנית | רשומה שנוצרה לפני שהמערכת הסמכותית קיבלה אותה |
| מילון עסקי | הגדרות מוסכמות למונחים החשובים של העסק |
| שושלת נתונים (lineage) | מאיפה ערך הגיע ומה קרה לו בדרך |
| סיווג נתונים | תיוג נתונים לפי רגישות וקטגוריית ציות כדי שיקבלו את הבקרות הנכונות |
| טקסונומיה | סט התוויות שארגון משתמש בו כדי לסווג נתונים |
| מידע אישי | מידע שמזהה אדם, או שאפשר לקשר אותו בחזרה לאדם |
| פסאודונימיזציה | החלפת מזהים כשעדיין קיימת דרך חזרה; עדיין מידע אישי |
| אנונימיזציה | הסרת היכולת הסבירה לזהות את האדם |
| מודל נתוני ההסכמה | האובייקטים של Salesforce להסכמה לפי אדם, ערוץ, נקודת קשר ומטרה |
| הזכות להישכח | הזכות של אדם, היכן שהחוק מעניק אותה, שהמידע האישי שלו יימחק |
| רשומת זהב היברידית | רשומה אחת עם השדות של מערכת האב והשדות של Salesforce עצמו, לכל אחד מקור אחד |
| מטא-דאטה עסקי / טכני | מה הנתונים אומרים ומי הבעלים שלהם / איך הם בנויים ואיך הם זזים |
| Field Audit Trail | היסטוריית שדות ארוכה יותר: עד 200 שדות לכל אובייקט, נשמרת עד שמוחקים אותה |
| Event Monitoring | לוגים של התחברויות, ייצואים, קריאות API וצפיות, שנשמרים לזמן מוגבל |
| SIEM | מאגר אבטחה שבו יומני אירועים נשמרים ומנותחים |
בדקו את עצמכם
Section titled “בדקו את עצמכם ”תרחישים קצרים בסגנון הקורס. החליטו על התשובה שלכם לפני שאתם פותחים.
1. המדיניות אומרת שרק הכספים רשאים לשנות את השם המשפטי של לקוח. הצוות מתכנן לכסות את זה בהדרכה. מה חסר?
נקודת אכיפה. הדרכה היא לא בקרה: השתמשו בגישה ברמת השדה, בשדה שרק האינטגרציה כותבת אליו, בכלל אימות, או בתהליך מבוקר. הבעלים קובעים את המדיניות; הארכיטקט הופך אותה לנכונה באופן מכני. קראו שוב את ממשל הנתונים צריך להפוך למכני.
2. מקור האב של הלקוחות הוא ה-ERP. אנשי המכירות צריכים להתחיל למכור ללקוחות פוטנציאליים חדשים מיד. איך מאפשרים להם, בלי ששתי מערכות ייצרו את רשומת האב?
תנו לאנשי המכירות ליצור את החשבון כסוג רשומה זמני, ואז המירו אותו בתהליך מבוקר: הכספים מאשרים, או שהאינטגרציה מגישה אותו ל-ERP, שמתאים או יוצר את הלקוח ומחזיר את המזהה הסמכותי. קראו שוב את הדרך האמצעית.
3. שדה חובה חדש מתמלא ב-"N/A" וב-"999999". מה קרה, ומה הייתם עושים במקום?
המשתמשים נאלצו לענות לפני שידעו. דרשו את זה מאוחר יותר בתהליך, תנו למערכת אחרת לספק את זה, השתמשו במצב זמני, או אפשרו Unknown מפורש כשזו תשובה אמיתית. קראו שוב את אל תתנו לשדות חובה לייצר נתונים מזויפים.
4. הצוות החליף שמות באסימונים (tokens) ואומר שהנתונים עברו אנונימיזציה, אז בקשת המחיקה טופלה. נכון?
לא, אם אפשר לקשר את האסימונים בחזרה לאדם: זו פסאודונימיזציה, והנתונים עדיין אישיים. אמרו בדיוק מה המערכת עושה, איפה המיפוי נמצא, ותנו למחלקה המשפטית להחליט אם זה עומד בדרישה. קראו שוב את מאונמז, מפוסאודונם, מוצפן, ממוסך.
5. נמען מסכים להודעות טקסט על משלוחים אבל לא לשיווק. איך המודל צריך להחזיק את זה?
עם מודל נתוני ההסכמה, לא עם תיבת סימון אחת: האדם, הערוץ (SMS), המספר הספציפי, ומטרת השימוש בנתונים (התראות משלוח, לא שיווק). והחליטו איזו מערכת סמכותית להסכמה, כדי שמשיכת הסכמה תגיע לכל מערכת שפועלת על פיה. קראו שוב את השתמשו במודל ש-Salesforce כבר בנתה.
6. צוות הציות צריך לסנן דוחות לפי שדה Social Security מוצפן. השדה משתמש בסכמת ההצפנה של ברירת המחדל. מה הבעיה?
הצפנה הסתברותית לא מאפשרת סינון בסעיפי WHERE של SOQL או במסננים של ניהול נתונים. הצפנה דטרמיניסטית מאפשרת סינון במחיר קטן בחוזק. הצפנה היא החלטת תכנון עם פשרות, לא תיבת סימון בסוף. קראו שוב את הצפנה היא בקרה, לא ציות.
7. שישה חודשים אחרי אירוע, מישהו שואל מי ייצא קבוצה של רשומות. אף אחד לא הגדיר אחסון ל-Event Monitoring. מה אפשר להגיד לו?
כנראה כלום: יומני אירועים נשמרים לזמן מוגבל (לכל היותר שנה, גם בהארכה), אז כל מה שישן יותר נעלם אלא אם ייצאו אותו. הגדירו Event Monitoring ושלחו את האירועים ל-SIEM לפני שאתם צריכים אותם. קראו שוב את ביקורת וניטור הם לא אותו דבר.
8. איש מכירות מבקש מ-Salesforce לשנות את השם המשפטי של לקוח, שמקור האב שלו הוא ה-ERP. באותן דקות מישהו משנה אותו ב-ERP. מה התכנון צריך לקבוע?
ש-Salesforce ביקש, לא שינה: מקור האב של השדה הוא ה-ERP. החליטו מראש על כלל ההתנגשות (ה-ERP מנצח, דחייה אם הערך השתנה, או שאדם מכריע) והאם שדות קשורים עוברים יחד. קראו שוב את מגינים על הרשומה המנוהלת.
9. מגיעה בקשת מחיקה של אדם. הצוות מתכנן להתחיל למפות איפה הנתונים שלו חיים. מה הבעיה?
השעון כבר מתקתק: לפי GDPR, חודש, עם אפשרות להארכה בעוד חודשיים לבקשות מורכבות. מפת העותקים צריכה להתקיים לפני שהבקשה מגיעה. קראו שוב את השעון מתקתק.
להרחבה
Section titled “להרחבה ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (באנגלית, נבדק ב-2026-09-25): הרשימה הרשמית של היעדים והמשקלים שלהם. תמיד בדקו את הגרסה העדכנית לפני שאתם קובעים מועד למבחן.
- בקטע “להרחבה” של כל יחידה מפורטים התיעוד של Salesforce והחוקים שמאחורי העובדות שלה, עם תאריך הבדיקה.