אובייקטים כמותיים תלויי מימד בBusiness Objects
האם רציתם ליצור ב Business Objects (או במחולל אחר) אובייקט כמותי התלוי במימד אחר, כגון מכירות לסוכן מסויים או למוצר נבחר?
במאמר זה, אנו מסבירים כיצד עושים זאת עם דוגמאות והסבר מה יכול להכשיל את התהליך. מומלץ לא רק למפתחי Business Objects.
הערה: לאחר פרסום המאמר, קיבלנו מספר תגובות שבהם הקוראים הציעו פתרונות לכאורה יותר אלגנטים לאותה בעיה. ואכן, רובם מתאימים לדוגמא הספציפית המובאת במאמר. יחד עם זאת, העקרונות המצוינים במאמר חשובים מאד ושימושים במקרים אחרים, בהם לא ניתן להשתמש בפתרון אחר. עקב כך, נשכתב בעתיד את המאמר עם דוגמא יותר טובה להמחשת היתרונות המובאים במאמר.
כדי להסביר מהו אובייקט תלוי מימד, נסתכל על הדוגמא הבאה:
ישנה טבלת מכירות ב DWH המכילה 3 שדות:
קוד מכירה-מפתח הטבלה.
קוד מוצר (יכולים להיות שני סוגי מוצרים A,B)
כמות מכירה
מטרתנו ליצור שני אובייקטים: כמות מכירות למוצר A וכמות מכירות למוצרB.
אם נלך בדרך הרגילה, כלומר, נבנה אובייקט מסוג כזה:
התוצאה שנקבל לאחר הרצת האובייקט תהיה ללא ספק נכונה. אם נמשיך ונבנה אובייקט נוסף למוצר B, לדוגמא:
גם נקבל אובייקט שייתן תשובה נכונה.
אבל...
מה קורה שנשתמש בשני האובייקטים בו זמנית. הSQL שיווצר יהיה:
(SELECT SUM(TABLE.KAMUT_MECHIRA
FROM TABLE
'WHERE TABLE.KOD_MUTZAR='A' AND TABLE.KOD_MUTZAR='B
ומשום שאין רשומות כאלה, נקבל:
No Data to Fetch
אז כיצד נצליח ליצור אובייקטים כאלה?
לצורך זה נשתמש בטכניקה אחרת. במקום select של שדה בטבלה, נשתמש בשאילתא מקוננת עם Alias. לדוגמא אובייקט של מוצר A:
כעת, אם ניצור עוד אובייקט כזה למוצר B ונריץ את שני האובייקטים ביחד , שני האובייקטים יחזירו תוצאות נכונות. יחד עם זאת עלינו לתת את הדעת למספר דברים:
אם נבחר אובייקטים אלו עם אובייקטים אחרים מטבלת TABLE, הSQL יהיה תקין לחלוטין, אבל אם נשתמש באובייקטים אלו לבד או עם אובייקטים מטבלאות אחרות ללא אובייקטים מטבלת TABLE. נהיה בבעיה, משום שהBO לא יכינס את טבלת TABLE למשפט הFrom ונקבל הודעה על שגיאת SQL. כדי להתגבר על בעיה זאת, יש להקיש על לחיץ Tables.
ושם לבחור את הטבלה הרלוונטית (במקרה שלנו TABLE)
נקודה מעניינת הראויה לתשומת לב הוא החיבור בין הטבלה הפנימית- הAlias שנקרא TABLE_AL לבין הטבלה החיצונית TABLE, החיבור צריך להתבצע לפי המפתח (במקרה זה קוד מכירה) . רק ליתר בטחון הוספנו SUM וזה כדי למנוע מצב שהמפתח הופר וישנם למשל שני רשומות עם אותו קוד מכירה.
לכאורה, מלאכתנו הסתיימה , אך יש פרט קטן שאנו צריכים לקחת בחשבון שעלול להרוס את הכל: רוב בסיסי הנתונים הרלציונים כגון אורקל, נכשלים כאשר ישנה שאילתא מקוננת תחת Group By. או במילים אחרות, אם נשים אובייקט זה יחד עם כל measure המכיל אגריגט (כגון sum,count) נקבל שגיאת SQL משום שהשאילתא עצמה איננה אגרגטיבית (הSUM הפנימי אינו נחשב) כדי למנוע זאת, אנו חייבים להכניס את כל המכלול לתוך SUM. האובייקט הסופי:
וכעת מלאכתנו הושלמה!
רק עוד הערה אחת לסיום: מכיוון שכל אובייקט כזה, הוא שאילתא בפני עצמה , שימוש באובייקטים כאלה הוא יותר איטי מאשר SQL "מסורתי" לכן יש לבנות ולהשתמש באובייקטים אלו בתבונה.
נשמח לקבל הערות , תגובות או שאלות לגבי מאמר זה ובכלל לכתובת