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

---

1. ממשל

עקרונות יסוד

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

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

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

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

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

הרכב Views (View Composition)

View שייך תמיד לתחום יחיד — קיים סוג View אחד בלבד, תמיד תוך-תחומי. View קיים לאחת משתי מטרות:

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

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

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

עומק ההרכב אינו נאכף טכנית — שיקול דעת Steward במהלך בדיקת HITL הוא מנגנון בקרת האיכות.

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

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

שאילתות (Queries)

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

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

לא נדרש אישור: הממשל קורה במעלה הזרם — בשכבות ה-Relationship ונראות העמודות. אם למשתמש יש גישה לעמודות ונתיב המעבר מאושר, השאילתה היא שימוש תקף. אין שער נוסף.

הבחנה מ-Views:

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

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

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

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

המהדר פותר את שיוך התחום מתוך המיקומים המבניים הללו — אין צורך בהערה (annotation) או ברמז.

קשרים (Relationships)

קשר (Relationship) הוא נתיב מעבר מאושר בין שני נכסים. גבולות תחום אינם רלוונטיים למהות הקשר — הם קובעים רק מי מאשר אותו.

אישור:

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

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

תוצאת אופטימיזציה: הצהרת קשר אינה רק חפץ ממשל — היא גם תיאור מבני של צורת Join. שתי הטבלאות, שתי העמודות, וסוג ה-Join המגדירים קשר הם בדיוק מה שמאיץ השאילתות (Query Optimizer) זקוק לו כדי לבצע Pre-Materialize מראש ל-Join הזה. קשרים בין-מקורות (Cross-Source) מייצרים אוטומטית טבלאות Join מְמוּטְרְיָלוֹת מראש; קשרים באותו מקור יכולים לבחור בכך דרך materialize: true. Stewards שחושבים על קשרים תקפים ומאשרים אותם מקבלים האצת שאילתות כתוצר ישיר — עבודת הממשל ועבודת האופטימיזציה הן אותה פעולה.

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

הרשאת גישה לשדה היא הרשאה מתחום לתחום — תחום A רשאי להשתמש בשדות ספציפיים מתחום B ב-Views שלו.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כללים טכניים מטפלים במה שאובייקטיבי — מעקב מקור שדה (Field Provenance), אכיפת גבולות תחום, אימות מהדר. שיקול דעת קונטקסטואלי נשאר עם ה-Steward. אילוצים כגון עומק הרכב View, דרישות מטרה לכל שאילתה, והחלטות אישור קשר הם עניינים של 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 (כלי המידול):

נגיש כמודל (Modal) מדף Relationships. הכוונה היא לבנות את המודל הסמנטי — זיהוי נתיבי Join מבניים לפני הפיכתם רשמית לקשרים מְמוּשְלים.

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

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

---

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 — היסטוריית שאילתות עבור דפוסי שימוש בזמן ריצה