תאריכים קבועים ב FACT או במימד

בזמן האחרון קיימת בי התלבטות קשה היכן לשים תאיריכים קבועים כגון תאריך גיוס במודל של חיילים, האם מכיוון שתאריך גיוס הוא מאפיין ללא עומק היסטורי וללא שינוי יהיה במימד פרטי חייל או בטבלת ה FACT כמו שכתוב בספרים?
יתרונות וחסרונות שחשבתי עליהם.
אם זה במימד.
כל פילוח עם זמן גיוס, לדוגמא כמות החיילים שהתגייסו לצהל מתאריך כזה וכזה יהיה JOIN מוכרח לטבלת פרטי חייל. בעצם כל פילוח עם הזמן הזה ללא קשר לפילוחים אחרים יכריח JOIN לטבלת פרטי חייל יתרון בולט כתוב רק פעם אחת. (נ.ב אני מסתפק באטומט של ה BO שיצור לי היררכיה של רבעון חודש שנה ולא צריך קישור מיוחד למימד הזמן שאני בונה)
אם זה ב FACT
שליפות מעולות רק מה FACT בפילוח תארכים, פילוח עם מימדים אחרים לא מכריח אותי לפנות למימד פרטי חייל, חסרון גדול- כמות הנתונים (הנתון הספציפי הזה) חוזר על עצמו לכל כמות השורות..
עכשיו קחו בחשבון שיש לי 15 תאריכים קבועים למינהם.
מה היתם עושים?

הי,

חד וחלק במימד.

כל המודל של dim\fact בנוי על הרעיון שישנם פרטים שאינם משתנים ואין צורך לשמור עליהם הסטוריה. כגון שם לקוח, תאריך גיוס של חייל וכו'. אם היינו רוצים לחסוך join היינו למעשה מבטלים את המודל ויוצרים טבלה אחת ענקית. היינו חוסכים join אך, אך היינו מקבלים מבנה ממש מכוער במיוחד לאור העובדה שמימדים מסויימים חוזרים בין כמה fact tables. (מימדים משותפים).

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

תמיר

נכון.ולא נכון
לא בגלל שהטבלה תהיה מכוערת והמבנה מכוער אנו לא יוצרים טבלה ענקית
הסיבה העיקרית למודל ה STAR היא ביצועי השליפה הטובים ביותר במבנה הרלציוני ו
דבר נוסף שהמבנה מתאים עתידית ל OLPA.
טבלה ענקית אחת (עם הרבה רשומות)לא בהכרח תביא לביצועים טובים יותר.
בספרים כתוב לחלק את המודל ל מאפיינים ומדדים.
שמדדים מחולקים ל שלושה חלקים - סכימים,חצי סכימים,לא סכימים
סכימים- כמות חיים לדוגמא מ.א הכנסה חודשית של חייל.
חצי סכימים- ציון - שאפשר לעשות עליהם ממוצע ול סיכום
תאריכם- לא סכימים כלל.
אני הבנתי מזה שכל התאריכים יושבים ב FACT ? (האם זאת טעות פאטאלית לדעתך ?)

לדוגמך, אני לא הייתי עושה ככה, אני לא מערבב סוכנים עם לקוחות יש מימד סוכנים ויש מימד לקוחות. וגם פה הייתי רוצה לשמוע את דעתך , עד היום הייתי עושה DATAMART לכל נושא למשל DATAMAT לחיילים ו DATAMART לעסקי שכולל חשבוניות וכו' (שגם פה יש מ.א שחייל)
ובעתיד במידה וירצו לפלח זאת יחד יצטרכו לעשות JOIN בין עולמות, האם אתה היית עושה שני מודלים ביחד באותו עולם ??

התשובה פשוטה,
במידה ובונים OLAP אזי הגדרת ההיררכיה מתבצעת
על מימד הזמן ולכן חייב לשים את התארכים ב FACT ויצרים JOIN למימד הזמן
אנשי ה BO רגילים שהכלי מייצר מעיין היררכיה לבד (שנה רבעון חודש)
ולכן במידה וזה מספק (ולא רוצים למשל חודשים בעברית וכ')
אפשר לשים את התאריכים במימד. כמובן צריך להתחשב בכמות הפילוחים לפי
תאריך זה או אחר, במידה ויש התייחסות
רבה לתאריך מסויים כדאי ביצועית לשים אותו ב FACT

היררכיית הזמן שאתה מדבר עליה כמעט שלא מנוצלת ב designer בגלל מגבלותיה הרבות ובוודאי שאינה תחליף ראוי לטבלת זמן הכוללת את מגוון ההתייחסויות לזמן ויעילה יותר בביצועים ובנית היררכיה גבוהה ומשמעותית יותר מה-Designer.

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

לבנתים:

www.dwh.co.il/portal/component/option,co...temid,86/topic,236.0

יואב,

להבא בצע חיפוש 

www.dwh.co.il/portal/content/view/288/107/


תמיר

א.התכוונתי לדוגמא ברמת הדיזיינר
ב.זה לא מופיע בפורום אלא במאמרים...

בפעם הבאה אני אדאג להביא לך אנשים חולניים במיוחד לקורס...