מילון, שושלת וסיווג

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

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

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

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

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

ירשתם org. ל-Account יש 900 שדות, וביניהם Customer_Type__c, Customer_Class__c, Customer_Category__c, Customer_Status__c, ERP_Status__c ו-Account_Status__c. איזה מהם אומר לכם אם מישהו באמת לקוח? אתם פותחים את התיאורים. שלושה ריקים. אחד אומר “Customer Type”. תודה רבה. אחד אומר שהוא הגיע מה-ERP; אחר נוצר לפני שש שנים בידי מישהו שעזב מזמן. עכשיו דמיינו שאתם לא הארכיטקט אלא אינטגרציה, צוות דיווח, או סוכן. לארגון יש הרבה נתונים. זה לא אומר שהוא יודע מה הנתונים אומרים.

כאן המטא-דאטה הופך לארכיטקטורה, דרך שלוש שאלות שקשורות זו לזו אבל אינן זהות:

• מילון: מה הנתונים האלה אומרים?
• שושלת: מאיפה הם הגיעו?
• סיווג: איך צריך לטפל בהם?

שני סוגים של מטא-דאטה

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

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

מתחילים מהמשמעות

פרק 3 קבע את הכלל: לכל שדה יש תיאור. לא “Customer Status” לשדה שנקרא Customer Status, אלא משהו כמו “הקשר המסחרי הנוכחי של השותף עם Steve Trucking. נקבע מה-ERP אחרי ההפעלה. לא להשתמש בו לסינון לקוחות פוטנציאליים.” עכשיו אני יודע מה הוא אומר, מאיפה הוא מגיע ולמה לא להשתמש בו. זו ההתחלה של מילון עסקי: הגדרות משותפות לנתונים שחשובים. מה זה לקוח? לקוח פעיל? מה פירוש Delivered? מה נחשב בזמן? זה נשמע מובן מאליו עד ששמים חמש מחלקות בחדר אחד: לכספים יש הגדרה אחת, למכירות אחרת, לתפעול שלישית, למחסן הנתונים רביעית, ומישהו בנה לוח מחוונים על חמישית. הבעיה היא לא שאף אחד לא מדבר אותה שפה. הבעיה היא שהארגון לא הסכים על המשמעות.

מילון יכול לחיות בגיליון אלקטרוני או בכלי תיעוד, אבל ההגדרות החשובות שבו צריכות לשבת קרוב למקום שבו אנשים משתמשים בנתונים. בפלטפורמה, אלה תיאורי השדות, טקסט העזרה ומטא-דאטה הסיווג. באנליטיקה זה חשוב אפילו יותר: “הכנסות” לא יכולות להיות דבר אחד בלוח המחוונים של ההנהלה ודבר אחר בשאילתה של אנליסט. בשביל זה יש שכבה סמנטית, והמודלים הסמנטיים של Data 360 מחזיקים הגדרות מנוהלות כמו מדדים, ממדים וקשרים מעל הנתונים הפיזיים (Create a Semantic Model in Data 360 (opens in a new tab)). הטכנולוגיה משתנה; הדרישה לא: לנתונים חשובים צריכה להיות משמעות מוסכמת.

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

מונח עסקי	משמעות	איפה הוא מיוצג
שותף קמעונאי (Retail Partner)	קמעונאי ש-Steve Trucking מבצעת עבורו משלוחים, לפי חוזה	חשבון ב-Salesforce; לקוח ב-ERP של הכספים
משלוח (Delivery)	משלוח אחד לנמען אחד, בכתובת אחת, ביום אחד	ב-RouteDesk היום; הזמנת עבודה ברגע שהמשלוחים עוברים ל-Salesforce
נמען (Recipient)	האדם שמקבל משלוח	פרטי הנמען על המשלוח
Delivered (נמסר)	הושלם לפי ההגדרה התפעולית המוסכמת	סטטוס המשלוח
משלוח בזמן	הושלם בתוך חלון המשלוח המוסכם	מדד נגזר

Click to enlarge

משמעות אחת, ייצוגים טכניים רבים.

ואז שואלים מאיפה זה הגיע

ברגע שאני יודע מה ערך אומר, אני רוצה לדעת מאיפה הוא הגיע. זו שושלת הנתונים. שם משפטי של שותף ב-Salesforce: איש מכירות הקליד אותו, ה-ERP שלח אותו, אינטגרציה שינתה אותו, Data 360 איחד אותו, הוא חושב, AI יצר אותו? כל אלה משפיעים על כמה אני סומך עליו ומה מותר לי לעשות איתו. זכרו את הרשומות הזמניות מיחידה 2: שני חשבונות יכולים שניהם להגיד “Keystone”, אחד שאיש מכירות יצר אתמול, השני מה-ERP עם מזהה סמכותי. אותו טקסט, שושלת שונה, טיפול שונה.

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

חלק מהשושלת מגיע בחינם: מזהה ה-ERP על החשבון, Created By ו-Last Modified By, לוגים של אינטגרציה, מסמכי מיפוי. Data 360 מוסיף לאובייקטי הנתונים שלו שדות שושלת שרושמים את מקור הנתונים ואת אובייקט המקור של כל רשומה (Data Lineage Fields (opens in a new tab)). אבל אל תניחו ששושלת מופיעה כי המערכות משולבות. לפעמים השושלת הכי שימושית היא שדה אחד: Source System = Keystone. ואם המקור חשוב לממשל הנתונים, הפכו אותו לאמין באופן מכני, שנקבע בידי האינטגרציה ולא מוקלד בידי אדם.

נתונים נגזרים צריכים שושלת יותר מכול. נניח ש-Steve Trucking מחשבת סיכון לאיחור במשלוח ממיקום המשאית, מחלון המשלוח ומהיסטוריית המסלול, והשיבוץ משתמש בזה כדי לתעדף. מאיפה הגיע ה”גבוה”? הוסיפו סוכן שאומר לנמען “המשלוח שלכם מתעכב”, ואתם צריכים לדעת על מה זה התבסס, וכמה עדכני זה היה. ככל שמתרחקים מערכים שמורים לערכים מחושבים, מאוחדים, חזויים ונוצרים, השושלת חשובה יותר.

הסיווג עונה על שאלה אחרת

עכשיו: איך צריך לטפל בזה? שם הנמען, כתובת המשלוח, מספר הטלפון, הערות המשלוח, סטטוס המשלוח, מספר המשאית, מרכז ההפצה, השותף הקמעונאי, התמונה: הם לא רגישים באותה מידה. “יצא למשלוח” הוא לא מספר טלפון, וקוד של מרכז הפצה הוא לא תמונה של פנים הבית של מישהו. Salesforce מאפשר לכם לרשום את זה על כל שדה, סטנדרטי או מותאם אישית: Data Owner, Field Usage, Data Sensitivity Level ו-Compliance Categorization (Data Classification Metadata Fields (opens in a new tab)). פרק 3 קרא להם שדות הטקסונומיה, והסביר למה הם חשובים: סמנו שדה כ-PII או GDPR ותהליכים יכולים למצוא אותו, מכלי מיסוך ועד שכבת האמון של ה-AI של Salesforce, שיכולה למנוע מערכים מסומנים להגיע למודל שפה גדול. אזהרה אחת מפרק 3: Salesforce משביתה עכשיו את מיסוך ה-LLM הזה לסוכנים, כי הוא יכול להסיר את ההקשר שסוכן צריך (סווגו את מה שחשוב: שדות הטקסונומיה). אז הסיווג עדיין צריך להניע את הבקרות האחרות.

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

טקסונומיה שאנשים יכולים להשתמש בה

לסיווג צריך אוצר מילים, טקסונומיה. ברירות המחדל של Salesforce הן Public, Internal, Confidential, Restricted ו-MissionCritical; ייתכן שהארגון שלכם ירצה תוויות משלו. אני לא מכתיב אותן. שמרו עליהן מובנות: אם יש 47 קטגוריות ואף אחד מחוץ לצוות הפרטיות לא יודע להבדיל בין קטגוריה 31 ל-32, זה לא עוזר. טקסונומיה טובה מחברת תווית להתנהגות. אם שדה הוא מידע אישי רגיש, מי יכול לראות אותו, האם הוא יכול לעבור ל-sandbox, לצאת מהאזור, להופיע באנליטיקה, כמה זמן שומרים אותו, האם מותר לסוכן להשתמש בו? עכשיו הסיווג עושה עבודה.

סיווג בלי אכיפה הוא קישוט

סמנו את מספר הטלפון של הנמען כרגיש ואל תשנו שום דבר אחר, וכתבתם תיעוד. שימושי, אבל ממשל נתונים הולך רחוק יותר: הסיווג צריך להניע הרשאות, מיסוך, הצפנה, שמירה, הסכמה, תנועת נתונים, שימוש ב-sandbox, ביקורת וגישה של AI. חלק מזה הוא החלטת תכנון של הארכיטקט; חלק מהפלטפורמות כבר מחילות תגיות וסיווגים ישירות במדיניות, כמו שממשל הנתונים של Data 360 עושה (Data Governance in Data 360 (opens in a new tab)). וסימון שדה כ-Restricted לא עוצר אף אחד מלקרוא אותו. הסיווג אומר איך צריך לטפל בשדה; האבטחה גורמת לזה לקרות. הרצף הוא: לזהות את הנתונים, להבין אותם, לסווג את מה שחשוב, ואז להחיל את הבקרות שהסיווג דורש.

Click to enlarge

שלוש שאלות על הנתונים שלכם, והשלישית חייבת להניע משהו.

גם נתוני ייחוס צריכים מטא-דאטה

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

שלושתם יחד

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

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

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

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

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

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

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

להרחבה

• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).
• Salesforce Help, Data 360: Data Lineage Fields (opens in a new tab), Data Governance in Data 360 (opens in a new tab) ו-Create a Semantic Model in Data 360 (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).