כפי שראינו השימוש המקורי של Aggregate aware היה בטבלאות אגריגטיביות. עם הזמן, הDesigners נוכחו לדעת שניתן להשתמש במנגון יפה זה גם לבנייתDimesnions.
נסתכל בדוגמא הבאה:
במודל זה ישנם 3 טבלאות:
Sales- טבלת המכירות שבו נרשמים הפרטים הכללים של מכירה, כגון קוד הסוכן ההאחראי למכירה תאריך מכירה, שם לקוח, קוד לקוח ועוד'.
Sales_line – שורת מכירה. מתארת את פריטי המכירה ומכילה קוד סוכן שמכר את המוצר,קוד מוצר, תאריך הוספת המוצר ועוד'.
Dim_Agents- טבלת סוכנים. טבלה זאת "מפענחת" את קוד הסוכן בטבלת Sales וAlias שלה, Dim_Agents_SL מפענח את קוד הסוכן בSales_line.
כדי למנוע בלבול מצד המשתמשים, הdesigner רוצה ליצור רק "סט" אחד של אובייקטי סוכן (המבוססים על טבלת Dim_Agents) , לפי הלוגיקה הבאה:
- אם ילקחו אובייקטים מטבלת Sales בלבד ו"שם סוכן". הBO ישתמש בטבלה ,Dim_Agents כדי לתאר את שם הסוכן.
- אם ילקחו אובייקטים מטבלת Sales_line בלבד ו"שם סוכן", הBO ישתמש בAlias ,Dim_Agents_SL כדי לתאר את שם הסוכן.
- אם ילקחו אובייקטים גם מטבלת Sales וטבלת Sales_line, ו"שם סוכן" הBO ישתמש בDim_Agents כדי לתאר את שם הסוכן.
במילים אחרות: בצע את השאילתא תמיד, דרך dim_agents אלא אם בשאילתא אין אובייקטים מsales.
נבצע את הפעולות הבאות:
נגדיר imcompatible בהתאם לטבלה הבאה:
|
אובייקטים של Sales_line |
אובייקטים של Sales |
אובייקט\טבלה |
|
|
|
Dim_Agents |
|
|
X |
Dim_Agents_SL |
לאחר מכן, נגדיר את האובייקט "שם סוכן".
@Aggregate_aware(dim_agents_sl.name, dim_agents.name)
הערה: dim_agents_sl מוגדר ראשון וזאת משום שהוא בריית המחדל שתבחר תמיד אלא אם יש בשאילתא גם אובייקטים מsales. במקרה זה הImcompatible "יסיט" את השאילתא לעבר Dim_Agents.