לפניכם מאמר ב ביזנס אובג'קטס\business objects:מדוע נוצר Synchronization וכיצד מטפלים בו?

 

כאשר הBO יוצר יותר ממשפט SQL אחד, יכולים להיווצר שני מצבים:

Join: הBO יודע כיצד לחבר את התוצאות של SQL`s לכדי שאילתא אחת.(נקרא בגרסא 4 fullouter join)

Synchronization: הBO אינו יודע או אינו יכול לחבר את הSQL`s לכדי שאילתא אחת. (נקרא בגרסא 4 multiflows)

מיוצר לציין שברוב המקרים נשאף למצב של join.

נמחיש את הנושא באמצעות הדוגמא הבאה:

לפניכם עולם, המורכב מ:

2 טבלאות Fact:  Fact_Arizot_Sales(מכירות אריזות) Fact_Wine_Sales (מכירות יין)

2 מימדים משותפים: Dim_Customer(לקוחות)  Dim_Time_Hour (מימד זמן)

מימד נוסף המשויך לFact_Wine_Sales בלבד, dim_wine_type (מימד יין)

הסכמה נראית כך:

article003-1

 

כמובן שנגדיר 2 Contexts:

Dim_Customers-> Fact_Arizot_Sales->Dim_time_Hour

Dim_customers->Fact_wine_sales->dim_Time_hour->Dim_Wine_Type

הערה: לצורך הקיצור רשמנו את הטבלאות ולא את הJoins.

כמו כן, יצרו אובייקטים בהתאם לטבלאות:

זמנים: dim_time_hour

לקוחות: dim_customers

סוגי יין: dim_wine_type (המימד המשויך רק לfact אחד)

מדדים: מכירות יין משוייך לטבלת Fact_wine_sales וכן מכירות אריזות המשויכות לטבלת Fact_Arizot_Sales.

article003-2

 

בואו נסקור את הדינאמיקה של הBO במקרה זה:

אם ניקח אובייקטים מהמימדים המשותפים (זמנים, לקוחות) וכן מדדים משני הFacts (מכירות יין, מכירות אריזות), יווצרו 2sql`s והBO יחבר את התוצאות לפי המימדים המשותפים:

article003-3  

במקרה זה , החיבור הוא פשוט וקל, לכן יסתיים בJoin:

 

 article003-4

 

article003-5

הבעיה מתחילה , כאשר אנו ננסה להכניס לתוך השאילתא אובייקט נוסף מהמימד המשויך לטבלה אחת בלבד (מימד יין), לדוגמא: שם יין. מבחינה עסקית , אין קשר למימד זה לטבלת הFact  השניה: Fact_Arizot_Sales.

במלים אחרות: הBO לא יכול לתאר בשאילתא אחת את מכירות האריזות יחד עם שם היין.

article003-6

 

במצב כזה: הBO ייצור 2 Sql`s , אחד לכל Fact, ולא יצליח לחבר אותם, במלים של BO: יצור Synchronization  בין השאילתות:

 

 article003-7

 

 article003-8

הדרך שבה הדבר יבוא לידי ביטוי משתנה בין הDeski לבין הWebi:

 

בDeski: השאילתא תשבר לשתי שאילתות משנה:

 

 article003-9

 אשר ימרחו על המסך:

 article003-10

 

בWeb, תיווצר שאילתא אחת, אך יוצגו כברירת מחדל 2 טבלאות , אחת מתחת לשנייה: (לצורך ההדגמה העלנו את הטבלה התחתונה לימין הטבלה העליונה)

 

 article003-11

 

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

לפניכם טיפ, כיצד ניתן להימנע ממצב Synchronization ולבצע חיווי יפה יותר למשתמשים:

נשתמש בחבר ותיק: Aggregate_Aware.

נגדיר את טבלת הFact_Arizot_Sales כincompatible כלפי האובייקטים של המימד "האחר" (dim_wine_type), כלומר האובייקטים תחת ספריית "סוגי יין".

כידוע, כל הגדרה של incompatible ,באה יחד עם @aggregate_aware. השאלה היא מה לשים בתוך הפונקציה. מסתבר שהטבלה עליה מבוססת מכירות אריזות  FACT_ARIZOT_SALES לבדה, תספיק. כך שהאובייקט מכירות אריזות במקום

sum(FACT_ARIZOT_SALES.QUANTITY)

יוגדר:

@aggregate_aware(sum(FACT_ARIZOT_SALES.QUANTITY))

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

article003-12

 

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

בואו נשכלל את הרעיון:

אנו רוצים שבמקרה שילקח measure אשר לא תואם למימד בשאילתא, תופיע הודעה אחרת למשתמש.לדוגמא -9999999 במקום הערך של הMeasure הבעייתי.

היינו רוצים\מצפים במקום:

@aggregate_aware(sum(FACT_ARIZOT_SALES.QUANTITY))

 

להשתמש ב:

@aggregate_aware(sum(FACT_ARIZOT_SALES.QUANTITY),-9999999)

לצערנו זה לא יעבוד, מאחר והBO דורש שבכל חלק של ה@aggregate_aware תופיע טבלה.

לכן, אנו נאלצים להתחכם:

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

למשל:

@aggregate_aware(sum(FACT_ARIZOT_SALES.QUANTITY),FACT_WINE_SALES.QUANTITY*0-9999999)

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

כלומר,

article003-13

 

יציג תוצאות רגילות:

article003-14

 

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

 

 article003-15

יגרום להצגת -999999

 

 article003-16

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

בעיה זאת נפתור בדרך אחרת:

אם נוסיף למספר כלשהו את הערך NULL התוצאה תהיה NULL.

נבצע זאת באובייקט:

@aggregate_aware(sum(FACT_ARIZOT_SALES.QUANTITY),FACT_WINE_SALES.QUANTITY*0-9999999+null(

המשמעות היא שבכל פעם שניקח את הmeasure מאריזות יחד עם אובייקט ממימד יינות הBO יחזיר NULL. כעת, כל שנותר לנו לעשות הוא ללכוד NULL  זה.

לצורך העניין, נשתמש במנגנון object format. (קליק ימני על אובייקט, object format)

בלשונית number, בחלק של Undefined נכניס את ערך שיופיע כאשר הערך שיוחזר מהDB יהיה NULL.

  article003-17

 

בואו ננסה להריץ את אותה שאילתא:

article003-18

 

 article003-19

 

רק ליתר בטחון, נריץ את אותה שאילתא ללא שם יין:

article003-20

 

ונקבל

 

 article003-21

שימו לב שגם במקרה זה בחלק מהערכים במכירות אריזות יש "לא ידוע". דבר זה נובע מהעובדה שהקשר בין שני הSQL`s הוא למעשה חיבור outer join ברמת הBO. מכאן היכן שיש צירוף של תאריך ושם לקוח , אשר קיים לו ערך  במכירות יין ולא קיים לו ערך במכירות אריזות, יופיע כnull, אשר יתורגם ללא ידוע.

ובא לציון גואל!!

 

חדשות dwh.co.il

BI&BigData

07 אפריל 2020

bi\dwh in israel

רשימת קורסים

קורס ה Bo Designer Master הוא קורס ייחודי שפותח בא ...
קורס ה SQL Wiz הוא קורס מיוחד המלמד חסר נסיון בSQL ...
בקורס זה אנו נלמד כיצד לפתח דוחות באמצעות הWebinte ...
בקורס זה אנו נלמד כיצד לפתח דוחות באמצעות הWebinte ...
הSDK של הקליינט של הBusiness Objects מרחיב את האפש ...
קורס ה Deski\Client-Business Objects, נועד לאפשר פ ...
בסדנא זאת, אנו נלמד על כלים מיוחדים עבור הDesigner ...
תנו לנו לייק לקבלת עדכונים שוטפים