מילון עסקי

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

אוצר המילים המשותף הזה הוא הגשר בין שפה עסקית לנתונים פיזיים. סוכן AI היודע ש"customer" נוקב בשם כל עמודה הנושאת מזהה לקוח אינו צריך לנחש מי מבין cust_id, customerId ו-CUSTOMER_KEY היא הנכונה — כולן מתפענחות לאותו מונח, והמונח נושא את ההגדרה.

כיצד מונחים נגזרים

Provisa גוזרת מונח מכל שם עמודה באופן אוטומטי, באמצעות כלל נורמליזציה דטרמיניסטי (REQ-1387): קיפול רישיות, טוקניזציה של מפרידים ושל camelCase, הרחבת קיצורים, וקיצוץ של אסימוני proxy נגררים.

הרחבת קיצורים ממפה קיצורים ארגוניים נפוצים לצורתם המלאה: cust → customer, txn → transaction, qty → quantity, וכן הלאה. גם id וגם key מתרחבים ל- identifier. הטבלה קבועה ושמרנית — קיצורים דו-משמעיים כמו st, min ו- no נשארים ככתבם במקום לנחש שגוי.

קיצוץ אסימוני proxy מסיר אסימון נגרר של identifier, code, index או reference. עמודה בשם cust_id אינה נוקבת בשם המזהה עצמו; היא נוקבת בשם לקוח דרך ערך חלופי. קיצוץ ה-proxy מנחית הן את cust_id והן את customerId על המונח customer. רק אסימונים נגררים מקוצצים, ולעולם לא האסימון האחרון שנותר: עמודת id חשופה מתרחבת ל- identifier ונשארת שם.

דה-דופליקציה היא כל העניין. כלל הנורמליזציה דטרמיניסטי, ולכן cust_id, ‏customerId ו-CUSTOMER_KEY כולם מייצרים customer. כל עמודה מקבלת ref על המונח היחיד שנוצר במקום שלושה מונחים נפרדים. לאצירה יש אז מקום אחד להוסיף בו את ההגדרה, לא שלושה.

ביטויים גנריים

חלק מהביטויים המנורמלים גנריים מכדי להיות מושג בפני עצמו. עמודת name, date או identifier חשופה נוקבת בשם תכונה של המושג של הטבלה שלה, לא מושג בלתי תלוי באותה טבלה. לעובדים יש שמות; למוצרים יש שמות; אלה אינם אותו דבר.

כשביטוי נופל בקבוצה הגנרית והקשר טבלה זמין, המונח מסויג ל- <מושג הטבלה> <ביטוי>: employees.first_name מתנרמל ל-employee first name, ו- orders.id מתנרמל ל-order, משום שקיצוץ ה-proxy מקריס אז את הביטוי המסויג על המושג שהוא מזהה. המקרה האחרון הזה חשוב: המפתח הראשי של orders וכל מפתח זר order_id בטבלאות אחרות נוחתים כולם על order, ללא כל אצירה נוספת.

הקבוצה הגנרית מכסה שמות עצם של תכונות (name, date, status, type, amount, quantity), ביטויי מסלול ביקורת (created_at, modified_by, submitted_timestamp), וקומץ אחרים המופיעים כמעט בכל טבלה.

השם העסקי, לא השם הפיזי

מונח נגזר עוקב אחר השם העסקי של העמודה — הכינוי שלה כשהמודלר קבע כזה, השם הפיזי שלה כשלא (REQ-1581). כש-usr_nm מקבל כינוי user name, המונח הנגזר הוא user name, לא user number או הרחבה כלשהי של usr_nm.

מתן כינוי לעמודה הוא התיקון החזק יותר. כינוי נודד לכל משטח שקורא את העמודה — SQL, ‏GraphQL, סוכני AI, הקטלוג — כך שהמודל מתאר את עצמו נכון בכל מקום. שינוי שם מונח מתקן רשומת קטלוג אחת ומשאיר את העמודה קוראת usr_nm לקורא הבא. באנר המונח המוצע בממשק המשתמש אומר זאת ישירות: תנו כינוי לעמודה תחילה; שנו את שם המונח רק כשׁשם העמודה נכון ואוצר המילים אינו.

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

שמות טבלה של נתיב גישה

חלק משמות הטבלאות מתארים נתיב גישה ולא מושג: user_by_name הוא משתמש שמגיעים אליו דרך חיפוש שם, לא סוג נבדל של ישות. כש-Provisa גוזרת את מושג הטבלה עבור סיוג ביטויים גנריים, היא חותכת את השם במילת הקישור (REQ-1582). ‏user_by_name הופך ל- user; orders_by_customer הופך ל-order.

בלי החיתוך, המפתח החלופי על user_by_name היה מתנרמל ל-user name ומתנגש עם תכונת users.name האמיתית — מונח אחד המחזיק דבר ואחד משדותיו שלו. החיתוך חל על מושגי טבלה בלבד. בשם עמודה, by הוא חלק משם העצם המורכב: ‏pet_by_name ו-pet_name מתנרמלים לאותו מונח, pet name.

מה הופך מונח לאצור

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

• הגדרה נשמרה.
• קשת קשר נוספה.
• מומחה תוכן הוקצה.
• אוצר הוציא אותו ידנית מכלל שירות.

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

סנכרון מחדש מטבלאות

בכל פעם שטבלה נשמרת או נטענת מחדש, sync_table_refs מיישב את עמודות הטבלה הזו מול ה-refs הקיימים. עמודות חדשות יוצרות-או-מקשרות מונחים; עמודות שעזבו מפילות את ה-refs שלהן; וכלל ההסרה-או-ההוצאה-משימוש מסדיר כל מונח שמאבד את ה-ref האחרון שלו.

גזירה מחדש מתרחשת עבור מונחים לא אצורים בלבד. אם נתתם כינוי לעמודה והמונח המוצע כעת שונה, ה-ref עובר למונח החדש. אם המונח אצור, הקישור נשאר — עריכת הכינוי לא עקפה את בחירת המונח של האוצר.

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

קשרים

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

סוג	משמעות
KIND_OF	מונח המקור הוא סוג של מונח היעד.
PART_OF	מונח המקור הוא רכיב של מונח היעד.
SYNONYM_OF	שני המונחים ניתנים להחלפה זה בזה בדומיין הזה.
RELATED_TO	אסוציאציה רופפת — שום טענה חזקה יותר אינה מתאימה.
VALID_VALUE_OF	המקור הוא ערך מותר של מניית או דומיין היעד.
DERIVED_FROM	המקור מחושב מתוך היעד או נשאב ממנו.
REPLACES	המקור מחליף את היעד שהוצא משימוש.
PREFERRED_TERM_FOR	המקור הוא המונח המועדף על פני היעד שאינו מעודד.
TRANSLATION_OF	המקור הוא תרגום לוקאל או שפה של היעד.
ANTONYM_OF	המקור הוא ההיפך הסמנטי של היעד.

הקשרים כיווניים. ממשק המשתמש מציג הן קשתות יוצאות (המונח הזה ← מונח אחר) והן קשתות נכנסות (מונח אחר ← המונח הזה), ומתייג כל כיוון בביטוי בשפה פשוטה משלו.

הקשתות נמצאות ב-glossary_term_edges, טבלת שיוך (associative) המוצהרת כקשר junction (REQ-1586): העמודה rel_type שלה היא המבחין (discriminator), כך שכל אחד מהטיפוסים שלמעלה הוא סוג קשר Cypher נפרד בין שני צמתי GlossaryTerm, ולא מאפיין על צומת מוחצן (reified). הטבלה מסופקת יחד עם שאר סכמת המטא-דאטה ואינה מוצגת כצומת בלקוחות גרף — היא הקשת. שום דבר בה אינו ייחודי לגלוסר: היא מוצהרת באותו אופן שבו הייתם מצהירים על junction מעל הטבלאות שלכם, והיא נקראת על ידי אותו קוד. [tool-verified: provisa/cypher/label_map.py:378-397, provisa/api/startup_seed.py:508-550]

מונחים מופשטים

למונח מופשט אין refs לעמודות פיזיות משלו. השתמשו בכזה עבור מושג עסקי הפרוש על פני כמה מונחים קונקרטיים — מטרייה שאותה אתם מחווטים אחר כך למונחים הספציפיים שכן מחזיקים עמודות. ‏revenue, למשל, יכול להיות מופשט, עם קשתות PART_OF מ-order amount, adjustment amount ו-refund amount המצביעות אליו.

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

כלל הקבילות למשטחים צורכים

מונח שמשטח צורך רשאי להציע חייב לקיים שלושה תנאים (REQ-1387):

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

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

ייצוא מטא-דאטה

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

קשתות קשר מתפרסמות רק כששני מונחי הקצה מתפרסמים.

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

הוצאת מונח מהייצוא

חלק מהעמודות נושאות אינסטלציה ולא נתונים עסקיים: מזהי אצווה של ETL, גרסאות שורה, חותמות זמן של הזרמה. מונח הנגזר מעמודה כזו עשוי להחזיק הגדרה מדויקת לחלוטין שפשוט אינה אוצר מילים עסקי (REQ-1583). הפקד Exclude from metadata export מונע את המונח וכל קשת קשר המסתיימת עליו מהקטלוגים ש-Provisa מפרסמת אליהם, בעוד שהעמודות עצמן עדיין מתייצאות כנכסים.

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

עבודה עם המילון

פתחו Admin ← Glossary בממשק המשתמש. הפאנל השמאלי מונה כל מונח; לחצו על אחד כדי לפתוח את תצוגת הפירוט שלו. משם:

• שינוי שם של המונח כדי לשנות את ניסוחו מבלי להזיז את עמודותיו.
• הוספת הגדרה על ידי הקלדתה או לחיצה על כפתור טיוטת ה-AI כדי לייצר נקודת פתיחה משם המונח, מעמודותיו הפיזיות ומקשריו. הטיוטה אינה נשמרת עד שתאשרו אותה.
• הזזת ref כדי לאחד שני מונחים: בחרו את מונח היעד מהתפריט הנפתח שליד כל ref פיזי. אם מונח המקור מאבד את ה-ref האחרון שלו, הוא מוסדר תחת כלל ההסרה-או-ההוצאה-משימוש אוטומטית.
• הוספת קשר בין המונח הזה לאחר, ובחירת הסוג מתוך הקבוצה הסגורה. הקלידו מחדש קשת קיימת במקומה במקום למחוק ולהוסיף אותה מחדש.
• הקצאת מומחים לפי מזהה משתמש, עם סוג של expert או author.
• הוצאה מכלל שירות של מונח כדי להוציאו מהשירות. הוא שומר על עמודותיו ונשאר ניתן לעריכה כאן, אבל חיפוש מונחים של סוכנים וייצוא מטא-דאטה מדלגים עליו שניהם. שחזרו אותו מאוחר יותר אם המושג חוזר.
• ייצור הגדרות בכמות כדי למלא כל הגדרה ריקה בפעולה אחת. רק הגדרות ריקות נכתבות; טקסט אנושי לעולם אינו נדרס.
• ייצור קשרים בכמות כדי להציע קשתות מוקלדות על פני רשימת המונחים המלאה. הצעות פגומות — שמות מונחים לא מוכרים, קשתות עצמיות, סוגים בלתי מזוהים — נופלות אוטומטית.

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

ראו גם

• ייצוא מטא-דאטה — כיצד מונחים וקשרים מתפרסמים לקטלוגי נתונים חיצוניים, כולל אילו מונחים כלל קבילות הייצוא מקבל.
• Column-Level Lineage — סייר ה-Data Lineage וכיצד columnDependents מדווח על קישורי מילון כתלויים של עמודה פיזית.