כיצד בנויה טבלת מימד הזמן?

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

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

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

הנימוקים לכך היו כדלקמן:
1. כך מקובל מבחינת כל המימדים (קוד ישוב, קוד מחלקה, קוד לקוח וכו').
2. זה מאפשר ליצור תאריכים פיקטיביים. למשל- אם טבלת הפאקט כוללת סיכומים חודשיים ולא יומיים אזי בשדה התאריך יופיע המספר 123 (למשל) שאינו מציין את 01/07/2008 וגם לא את 31/07/2008 אלא את 07/2008 (יולי 2008)..

פעם ראשונה שאני שומע על זה,
טענה 1 היא די צולעת,
וטענה 2 למרות שיש בה אמת - תפתור בעייה קטנה אחת (שניתן להתגבר עליה בדרכים אחרות) ותיצור הרבה בעיות גדולות אחרות, למשל - לכל טבלה הכוללת עמודת תאריך נצטרך לבצע כעת Join עם כל חוסר היעילות בדבר.
משל למה הדבר דומה? למישהו שיטען שצריכה להיות טבלת כמויות, וכשמישהו ירצה לכתוב כמות 3 בטבלת הפאקט הוא יכתוב את הקוד 178 שלפי טבלת הכמויות מייצג את הכמות 3..

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

אין לך מושג כמה אני שונא מימדי זמן עם מפתח שהוא מסוג DATETIME,
אני מעדיף להשתמש ב INT שהוא לא מספר רץ כמו שמיקרוסופט אוהבת להשתמש אלה
במספר שמייצג את התאריך כמו בכמה מערכות ERP
לדוגמה: 19/01/2008 -> 20081901
כפי שאתה רואה ההמרה פשוטה,לא צריך להשתמש בטבלאות המרה, המיון פשוט וכו...

ולשאלה המרכזית, למה לנו לעשות את זה?
התשובה שאני מכיר קשורה לעובדה שהרבה יותר קל לבצע פעולות כגון join ו where
על INT מאשר datetime או varchar מה שגורם לטבלת ה FACT להיות קטנה יוצר
וגם מאפשרת מענה מהיר יותר לשאילתות שמחייבות join לטבלת הזמן....


מידע נוסף תוכל למצוא ב: ( המלצה מספר 4)
sqlcat.com/top10lists/archive/2008/02/06...-data-warehouse.aspx

או חוק 12 (מ 30 ) ב:
www.ssas-info.com/VidasMatelisBlog/26_sq...est-on-ssas-database
חוק מספר

בכל מקרה- תודה!

גרי שלום,

באופן תיאורטי באמת עדיף שהמפתח יהיה int משום שזה יותר מהר מבחינת הjoins, אבל מנסיון שלי זה מוציא למפתחים את הנשמה משום שלכל פעולה שהם רוצים לבדוק הם צריכים להשתמש ב to_date, cast  וכו'.

בפרוייקטים שהשתמשו בdate כמפתח-לא ראיתי שזה היווה את אבן הנגף בפרוייקט.

שים לב שdate הוא לא char!!! ולמעשה מאחורי הקלעים הוא גם מספר.

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

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

www.dwh.co.il/portal/content/view/912/112/

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

מקווה שקיבלת התיחחסות רצינית לשאלתך,

תמיר

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

המחיר הוא הפיכת השדה ל int ושוב הדרך הכי קלה היא לא ע"י מספר קץ אלה
הפיכה חד חד ערכית ( 2008-04-01 הופך ל 20080401) לדעתי זה לא מסובך ואפילו חוסך
לך את כל הטיפול המעצבן בתאריכים בתצוגה ארופאית או אמריקאית.