עקרונות מודל התחומים

---

1. ממשל

עקרונות יסוד

1. כל משאב חייב להיות בבעלות תחום. טבלאות, Views וקשרים הם כולם נכסי תחום. אין משאבים צפים ללא ממשל. התחום הוא יחידת האחריותיות.
2. לכל תחום חייב להיות Steward. תחום יכול להתקיים במצב ממתין עד שיוקצה לו Steward, אך הוא אינו יכול לשרת נתונים מְמוּשְלים בלעדיו.
3. המנהל (admin) הוא בעל המקורות (Sources). מקורות הם תשתית, לא נכסי תחום. המנהל רושם ומנהל חיבורים למערכות נתונים חיצוניות.
4. Stewards יכולים לתבוע טבלאות עבור תחום. תביעה היא בלעדית: טבלה שייכת לתחום אחד בדיוק. התביעה היא הפעולה המנוהלת שמחברת את התשתית למודל.
5. Stewards יכולים ליצור תצוגות פנים-תחומיות מנכסי התחום. תצוגות מבטאות לוגיקה עסקית, כמו joins, צבירות ומדדים נגזרים, מעל נכסים שה-Steward מחזיק באותו תחום. תצוגה יוצרת משמעות סמנטית חדשה ודורשת את אישור ה-Steward.
6. אנליסטים יכולים ליצור שאילתות חוצות תחומים מקשרים מאושרים. שאילתות הן תצוגות בין-תחומיות שנכתבות בכל שפת שאילתה נתמכת. הן לא יוצרות סמנטיקה חדשה; הן עוברות על נתיבי קשר מאושרים. אין צורך באישור נוסף, כי הממשל פועל מוקדם יותר, בשכבות הקשרים ונראות העמודות. הקטלוג הוא שאוכף: המהדר דוחה כל מעבר שאינו בקטלוג הקשרים המאושרים.
7. כל אחד יכול לבקש גישה למשאב של תחום. גישה ניתנת לפי משאב, לעולם לא לפי שאילתה: אם יש לכם גישה למשאב, אתם יכולים לשאול עליו. הממשל נאכף בזמן הביצוע דרך הצינור.

משאבים: טבלאות ו-Views כשווים

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

• שניהם נכסי תחום בפני עצמם, נראים בקטלוג
• שניהם יכולים להיות היעד של קשר (Relationship)
• שניהם יכולים להיות מוענקים תחת עקרון 6
• שניהם כפופים לאותו Pipeline ממשל

Steward יכול לתבוע טבלאות באופן פרטי ולחשוף רק Views אצורים כמוצרי נתונים פונים-פנימה (public-facing).

הרכב Views (View Composition)

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

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

View רשאי להפנות אל:

• טבלאות נתבעות (Claimed) בתוך אותו תחום
• שדות מיובאים מתחום אחר תחת הרשאת גישה לשדה
• View אחד נוסף בתוך אותו תחום, כאשר השינוי מכוון: הגבלת שדות, אגרגציה, או העשרה באמצעות Join נוסף

שום דבר טכני לא מגביל עד כמה עמוק תצוגות נבנות זו על זו. בקרת האיכות היא שיקול הדעת של ה-Steward בסקירת ה-HITL.

לכל View יש מטרה עסקית מוצהרת, הנקבעת בעת היצירה:

• חלק מהחפץ המְמוּשְל, כך ש-Stewards מאשרים בידיעה מה מטרת ה-View
• מוזכרת בבקשות גישה תחת עקרון 7 כך שה-Steward יכול להעריך התאמה
• מלווה את ה-View מיצירתו ולאורך כל תהליך הממשל

שאילתות (Queries)

שאילתה עוברת על נתיבי קשר מאושרים מעל נכסי תחום. בניגוד לתצוגה, היא לא יוצרת משמעות סמנטית חדשה; היא הולכת לפי המבנה המאושר של המודל. אפשר לכתוב שאילתה בכל שפת שאילתה נתמכת (SQL, GraphQL, Cypher).

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

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

הבחנה מ-Views:

• Views: תוך-תחומיים, מציגים משמעות סמנטית חדשה, אצורים על-ידי Steward
• שאילתות: חוצות קשרים מאושרים, ללא סמנטיקה חדשה, ללא שער אישור

ביטוי תחום לפי שפת שאילתה:

כל שפה נתמכת חושפת את התחום כמרחב שמות מבני, טבעי לאותה שפה:

שפה	ביטוי התחום	דוגמה
GraphQL	קידומת שם Type ושם שדה	type sales__Order { ... }, query { sales__orders { ... } }
SQL	שם Schema	SELECT * FROM sales.orders
Cypher	תווית Node נוספת (התחום נדרש רק כאשר שם ה-Type אינו חד-משמעי)	MATCH (o:Sales:Order)

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

קשרים (Relationships)

קשר הוא נתיב מעבר מאושר בין שני נכסים. גבולות התחום לא משנים מהו קשר; הם רק קובעים מי מאשר אותו.

אישור:

• על בקשת קשר מחליטים התחומים שהיא נוגעת בהם: התחום של טבלת המקור שלה והתחום של טבלת היעד שלה
• אישור נספר רק ממשתמש שזכותו ליצור קשרים מגיעה לאחד מהתחומים האלה; כל משתמש כזה יכול לדחות
• הבקשה מבוצעת לאחר ששני משתמשים שונים, שאף אחד מהם אינו מגיש הבקשה, אישרו אותה ולכל תחום מעורב יש מאשר: קשר בין שני תחומים צריך הסכמה מכל צד, וקשר בתוך תחום אחד צריך שני מאשרים מאותו תחום
• אישור קשר בונה את גרף התלויות של כל Steward, כך שה-Stewards שומעים על שינויי Schema לפני שהם נכנסים לתוקף

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

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

הרשאות גישה לשדה (Field Access Grants)

הרשאת גישה לשדה היא הרשאה מתחום אחד לתחום אחר: תחום A רשאי להשתמש בשדות מסוימים מתחום B בתצוגות שלו.

מחזור חיים של הרשאה:

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

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

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

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

תהליך יצירת שאילתה

שלושה שלבים, בסדר הזה.

שלב 1 — עיצוב (Shaping) (גילוי SQL, מדף Relationships):

• האנליסט פותח את כלי ה-Shaping מדף Relationships כדי לנסות נתיבי Join ב-SQL גולמי
• ה-SQL רץ מול נתונים נגישים, בכפוף לאבטחה ברמת השורה ומיסוך עמודות קיימים
• JOINs ב-SQL מנותחים ומוצגים כהצעות Relationship מועמדות
• מועמדים המוצעים על-ידי מכונה (הסקת FK, הסקה סמנטית) מוצגים לצד ה-SQL של האנליסט באותה תצוגה
• האנליסט בוחר מועמדים לקידום לבקשת Relationship רשמית

שלב 2 — אישור קשר (משמעותי — מבני וקבוע):

• מוכרע על ידי התחומים שהקשר נוגע בהם, כמתואר תחת קשרים
• האם זה נתיב מעבר לגיטימי? האם ה-join תקף סמנטית?
• שני משתמשים שונים, שאף אחד מהם אינו המבקש, חייבים לאשר, ולכל תחום מעורב חייב להיות מאשר; אחר כך הקשר הופך לרשומה קבועה בקטלוג

שלב 3 — יצירת שאילתה:

• האנליסט בונה את השאילתה בכל שפה נתמכת (SQL, GraphQL, Cypher), חוצה נתיבי קשר מאושרים
• ניתן לחצות רק קשרי קטלוג מאושרים, והמהדר אוכף זאת באופן מבני
• לא נדרש אישור: נראות עמודות ואישור קשר הם השערים היחידים

HITL כבקרה הראשית

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

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

• שיקול גבוה בהחלטת חציית הגבול
• מודעות קלה לאחר מכן דרך התראות והיסטוריית שאילתות

---

2. ניתנוּת לגילוי (Discoverability)

דרגות גילוי

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

דרגה	תיאור	מצב ממשל
1 — Schema מקור רשום	כל טבלה, עמודה וסוג ממקור רשום. נראות ברמת המנהל.	ללא — מלאי גולמי
2 — טבלאות לא נתבעות	טבלאות שנחקרו (introspected) ממקורות רשומים ללא בעלים תחום. נראות ל-Stewards עם גישת מקור.	זמין אך לא מְמוּשְל
3 — נכסי תחום	טבלאות נתבעות ו-Views שהוגדרו על-ידי Steward. מְמוּשְל במלואו, בבעלות, נראה בקטלוג.	מְמוּשְל במלואו
4 — קשרים	נתיבי מעבר מאושרים בין נכסי דרגה 3. תנאי מוקדם ליצירת View בין-תחומי.	מאושר על-ידי שני Stewards
5 — הרשאות שדה	הרשאות גישה לשדה מתחום לתחום. הגישה המְמוּשְלת הספציפית והמכוונת ביותר.	מאושר על-ידי Steward המקור

טבלה שלא נתבעה מצביעה על פער. אם הנתונים שאתם צריכים קיימים רק ברמה 2, Steward צריך לתבוע אותם לפני שהממשל יכול להתקדם. כשאין מועמד באף רמה, העבירו את העניין למנהל.

אילוצי FK

אילוצי FK שייכים למקור יחיד, ולכן הם לא יכולים לחצות מקורות. נתיבי join חוצי מקורות נגזרים כולם מקשרים מאושרים בקטלוג (רמה 4), שהם ראיה חזקה יותר כי שני ה-Stewards אימתו אותם.

בתוך מקור:

• אילוצי FK מוצגים אוטומטית כקשרים מועמדים בעת רישום מקור
• הם מייצגים כוונת מידול מפורשת: לא נאכפים ברוב מערכות ה-SQL האנליטיות אך מוצהרים בכוונה
• אימות Steward עדיין נדרש לפני שמועמד הופך לקשר מאושר

היררכיית ביטחון קשרים

ראייה	ביטחון
קשר קטלוג מאושר — בין-מקורות, אומת על-ידי שני Stewards	הגבוה ביותר
אילוץ FK תוך-מקורי — כוונת מידול מפורשת, לא נאכף אך מכוון	גבוה
הסקה סמנטית תוך-מקורית — דמיון שם/סוג עמודה בתוך Schema עקבי	בינוני
הסקה סמנטית בין-מקורית — מוסכמות שמות מתפצלות בין מערכות; סיכון False Positive גבוה	נמוך

הצעות המאושרות על-ידי מספר סוגי ראייה צוברות ביטחון.

בדיקת נתונים ומתאם (Data Probing and Correlation)

עבור מועמדים שהוסקו סמנטית, בדיקת נתונים מספקת שלב אימות:

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

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

גילוי בסיוע LLM

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

מה ה-LLM חושף:

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

עיצוב View מתיאור עסקי:

האנליסט מספק תיאור בשפה טבעית ואילוצים אופציונליים. ה-LLM מפיק מבנה View מוצע.

קלט:

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

דוגמה:

"נפחי מסחר יומיים לפי צד נגדי (Counterparty) ל-30 הימים האחרונים, צדדים נגדיים פעילים בלבד, המציגים שם משפטי של הצד הנגדי ודירוג אשראי. ללא מידע מזהה אישי (PII)."

תהליך ה-LLM:

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

פלט:

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

התיאור העסקי הופך למטרה העסקית המוצהרת של ה-View ברגע שה-View נוצר רשמית.

גילוי קשרים מונחה-SQL (כלי המידול):

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

1. האנליסט כותב SQL חופשי מול טבלאות נגישות (אבטחה ברמת שורה ומיסוך עדיין חלים)
2. עץ תחביר (AST) ה-SQL מנותח, וכל תנאי JOIN הופך להצעת Relationship מועמדת
3. רשימת המועמדים מוצגת לצד מועמדים מוצעים על-ידי מכונה (הסקת FK, הסקה סמנטית) לבדיקה מאוחדת
4. האנליסט מקדם מועמדים נבחרים לבקשות Relationship רשמיות
5. קשרים מאושרים מתווספים לקטלוג והופכים לניתנים לחציה בשאילתות

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

---

3. שימוש

שובל ביקורת שאילתות (Query Audit Trail)

כל שאילתה הנוגעת בנכס תחום נרשמת ביומן query_audit_log בעל-הוספה-בלבד (Append-Only). כל רשומה כוללת:

• tenant_id, user_id, role_id — הקשר הזהות
• Hash מסוג SHA-256 של השאילתה; טקסט השאילתה המילולי לעולם אינו נשמר
• table_ids — נכסי התחום שהשאילתה נגעה בהם
• source, status_code, duration_ms
• logged_at — חותמת הזמן

היומן הוא בעל-הוספה-בלבד (DELETE ו-UPDATE חסומים ברמת מסד הנתונים) ומאונדקס לפי (tenant_id, logged_at) ו-(user_id, logged_at).

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

שני מנגנוני נראות:

• Push — התראות לאחר-שימוש עבור פעולות מבניות (View חדש נוצר באמצעות השדות שלך)
• Pull — היסטוריית שאילתות עבור דפוסי שימוש בזמן ריצה