עקרונות מודל הדומיין

---

1. ממשל

עקרונות ליבה

1. כל משאב חייב להיות בבעלות דומיין. טבלאות, תצוגות, וקשרים הם כולם נכסי דומיין. אין משאבים צפים לא-ממושלים. הדומיין הוא יחידת האחריותיות.
2. לכל דומיין חייב להיות סטיוארד. דומיין עשוי להתקיים במצב ממתין עד שסטיוארד מוקצה, אך הוא אינו יכול לשרת נתונים ממושלים בלעדיו.
3. ה-admin הוא הבעלים של המקורות. מקורות הם תשתית, לא משאבי דומיין. ה-admin רושם ומנהל חיבורים למערכות נתונים חיצוניות.
4. סטיוארדים יכולים לתבוע טבלאות עבור דומיין. תביעה היא בלעדית — טבלה שייכת לדומיין אחד בדיוק. זהו המעשה הממושל המגשר בין תשתית לשכבה הסמנטית.
5. סטיוארדים יכולים ליצור תצוגות תוך-דומייניות מנכסי דומיין. תצוגות מבטאות לוגיקה עסקית — joins, אגרגציות, מטריקות נגזרות — על נכסים שהסטיוארד הוא בעליהם באותו הדומיין. תצוגות יוצרות משמעות סמנטית חדשה ודורשות אישור סטיוארד.
6. אנליסטים יכולים ליצור שאילתות חוצות-דומיין מקשרים מאושרים. שאילתות הן תצוגות בין-דומייניות המבוטאות בכל שפת שאילתה נתמכת. הן אינן יוצרות סמנטיקה חדשה — הן חוצות נתיבי קשר מאושרים. אין צורך באישור נוסף: הממשל מטופל בשלב מוקדם יותר בשכבות הקשר ונראות העמודה. הקטלוג הוא מנגנון האכיפה: הקומפיילר דוחה חציות שאינן בקטלוג הקשרים המאושר.
7. כל אחד יכול לבקש גישה למשאב דומיין. גישה מוענקת ברמת המשאב, לא ברמת השאילתה. אם יש לכם גישה למשאב, אתם יכולים לשאול אותו. הממשל נאכף בזמן ביצוע דרך הצינור.

משאבים: טבלאות ותצוגות כעמיתות (Peers)

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

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

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

הרכבת תצוגה (View Composition)

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

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

תצוגה יכולה להפנות אל:

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

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

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

• חלק מהחפץ (artifact) הממושל — סטיוארדים מאשרים בידיעה למה התצוגה מיועדת
• מוזכר בבקשות גישה תחת עקרון 7 כך שהסטיוארד יכול להעריך התאמה
• נוסע מיצירת התצוגה דרך תהליך הממשל המלא

שאילתות (Queries)

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

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

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

הבחנה מתצוגות:

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

ביטוי דומיין לפי שפת שאילתה:

כל שפה נתמכת חושפת את הדומיין כ-namespace מבני ילידי לאותה שפה:

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

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

קשרים (Relationships)

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

אישור:

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

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

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

מענקי גישת שדה (Field Access Grants)

מענק גישת שדה הוא הרשאה דומיין-לדומיין — דומיין A רשאי להשתמש בשדות ספציפיים מדומיין B בתצוגות שלו.

מחזור חיי מענק:

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

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

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

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

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

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

שלב 1 — עיצוב (Shaping) (גילוי SQL, מעמוד הקשרים):

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

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

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

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

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

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

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

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

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

---

2. יכולת גילוי (Discoverability)

שכבות גילוי

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

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

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

אילוצי FK

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

בתוך מקור:

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

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

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

הצעות המתחזקות על ידי סוגי ראיה מרובים צוברות ביטחון.

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

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

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

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

גילוי בסיוע LLM

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

מה ה-LLM מציג:

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

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

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

קלט:

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

דוגמה:

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

תהליך ה-LLM:

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

פלט:

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

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

גילוי קשרים מבוסס-SQL-תחילה (כלי Modeling):

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

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

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

---

3. שימוש

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

כל שאילתה הנוגעת בנכס דומיין נרשמת ב-query_audit_log בעל-הוספה-בלבד. כל רשומה לוכדת:

• 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).

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

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

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