दिनांक/समय आयाम

Question

मैं एक डेटा वेयरहाउस डिजाइन कर रहा हूं और मेरे पास समय के साथ चिपचिपा मुद्दा है। मुझे जिस अनाज की आवश्यकता है वह प्रति घंटा है (प्रति घंटा घटनाओं की कुल गणना की गणना करने के लिए) और मुझे एक शिफ्ट पैटर्न को भी समायोजित करना होगा जो 24 घंटे की अवधि के भीतर आसानी से फिट न हो (वास्तव में यह संभव है कि 'नीली' शिफ्ट एक ही कवर न हो कई दिनों के लिए दिन का समय)।

इस मन में मैं 3 में से एक पर विचार कर रहा हूँ के साथ

दृष्टिकोण

1. एक ही समय आयाम उस में 175K पंक्तियों के साथ।
2. कैलेंडर आयाम में 7300 पंक्तियों के साथ एक हिमपात का समय आयाम और समय आयाम में 175k पंक्तियों
3. अलग आयाम ताकि तथ्य तालिका घटना की तारीख और घटना के समय के लिए विदेशी कुंजी हो।

मैं दृष्टिकोण 3 की तरफ बढ़ रहा हूं क्योंकि यह छोटे कैलेंडर आयाम को शामिल होने में अलग से संदर्भित करने की अनुमति देता है, लेकिन मैं किसी भी विचार की सराहना करता हूं।

Answer 1

क्या इसके लायक है के लिए मेरे £ 0.02:

मानते हुए बदलाव के विचार (@Andriy एम के सवाल) से उत्पन्न होने वाली कोई अतिरिक्त मुद्दा है कि वहाँ:

मैं विकल्प 2 छूट जाते हैं जाएगा जब तक कि वहाँ एक विशिष्ट लाभ (प्रदर्शन, वर्ग की एक वर्ग का प्रदर्शन, इत्यादि) है जिसे आप इसे अपनाने से देख सकते हैं। आप इस तरह के किसी भी लाभ का वर्णन नहीं करते हैं, इसलिए ऐसा लगता है कि आप अपनी खातिर जटिलता जोड़ रहे हैं।

मेरी निजी वरीयता विकल्प 1 के लिए होगी - अवधारणात्मक रूप से सबसे सरल, सबसे प्रत्यक्ष, और (आईएमओ) डाटा वेयरहाउस दृष्टिकोणों के लिए सबसे उपयुक्त है।

विकल्प 3 में आपके द्वारा उल्लेख किए जाने वाले फायदे हैं, लेकिन मुझे संदेह है कि इसमें दो विकल्प शामिल हैं: कैलेंडर आयाम दोनों में वर्णित है, लेकिन समय आयाम के लिए विकल्प 175k पंक्तियां या 24 हैं। वर्तमान में इन विकल्पों में से किसी एक के लिए तर्क प्रदान नहीं कर सकते हैं, केवल एक आंत महसूस कर रहे हैं कि ऐसे दो विकल्प हैं। यदि शिफ्ट मुद्दा यहां प्रासंगिक है, तो यह इन विकल्पों के बीच चुनाव को प्रभावित कर सकता है (यदि वे वास्तविक विकल्प हैं)।

यदि आप विकल्प 2 आगे लेना चाहते हैं, तो विकल्प 3 के लिए निर्धारित विकल्प भी प्रासंगिक हैं।

Answer 2

हाँ, विनिर्माण बदलाव मुश्किल कर रहे हैं और समय के साथ बदल रहा है, अक्सर एक पारी से पहले दिन शुरू होता है, आदि

ध्यान रखें दो कैलेंडर यहाँ देखते हैं कि। एक मानक कैलेंडर और दूसरा उत्पादन कैलेंडर - शिफ्ट उत्पादन कैलेंडर से संबंधित है। आम तौर पर, उत्पादन कैलेंडर में एक दिन 24 घंटे से अधिक (या कम) हो सकता है।

उदाहरण के लिए:

भाग सोमवार को उत्पादन किया, 2011-02-07 23:45 तरह

TimeOfProduction = '2011-02-07 23:45' 
DateKey = 20110207 
TimeKey = 2345 
ProductionDateKey = 20110208 (the first shift of the next day started at 22:00) 
ProductionTimeKey = 145 (1 hour and 45 minutes of the current production date)  
ShiftKey = 1 
ShiftTimeKey = 145 (1 hour and 45 minutes of the current shift) 

लग सकता है तो, मेरा सुझाव है:

1. सादा Date Dimension (एक पंक्ति प्रति तिथि)
2. सादा Time Dimension (24 घंटे के लिए एक पंक्ति प्रति मिनट = 1440 पंक्तियां + नीचे नोट देखें)
3. Shift Dimension - प्रकार के साथ 2 आयाम rw_ValidFrom, (rw_ValidTo) , rw_IsCurrent
4. भूमिका निभाते हैं एक ProductionTimeKey और ShiftTimeKey में भूमिका निभाते हैं DateKeyProductionDateKey में
5. TimeKey।
6. तथ्य तालिका में भी TimeOfProduction (datetime) रखें।
7. ईटीएल प्रक्रिया के दौरान factPart तालिका की प्रत्येक पंक्ति में ProductionDateKey, ProductionTimeKey, ShiftKey, ShiftTimeKey संलग्न करने के लिए वर्तमान शिफ्ट तर्क लागू करें।

नोट कि आप Time Dimension करने के लिए अतिरिक्त पंक्तियां जोड़ने के लिए है, तो एक उत्पादन दिन 24 घंटे से अधिक पिछले कर सकते हैं पड़ सकता है। आमतौर पर यह एक स्थानीय समय का उपयोग किया जा सकता है और डेलाइट बचत समय कूद है। अलग आयाम -

तो, स्टार इस

Answer 3

मैं विकल्प 3. का चयन करेंगे की तरह कुछ लग सकता है। लाभ:

• सादगी - दो अपेक्षाकृत छोटे टेबल - समय आयाम के साथ केवल एक बार वहाँ के रूप में एक दिन में मिनट की निश्चित संख्या भरी हुई।

• पुन: उपयोग - दो separete आयाम अधिक अन्य तथ्य तालिकाओं एक तथ्य तालिका में दिनांक आयाम के लिए अलग विशेषता होने से केवल तिथि या समय आयाम

• आसान विभाजन हो सकता है के साथ साझा करने की संभावना है

• एक्सटेंसिबिलिटी - उन गुणों के बारे में सोचें जिन्हें आप दिनांक और समय आयाम में जोड़ सकते हैं क्योंकि आपकी रिपोर्टिंग की आवश्यकता बढ़ती है। दिनांक आयाम के लिए यह हो सकता है (प्रत्येक जानकारी को तिथि से हर बार निकालने से बचने के लिए): वर्ष, तिमाही, महीना, दिन, सप्ताह, दिनांक लेबल (जैसे "12 सितंबर 2011"), महीने का नाम, सप्ताह का नाम, विभिन्न संकेतक (अवकाश संकेतक, तिमाही के अंत, महीने के अंत, आदि)। एक समय आयाम (जो सटीकता के लिए - एक दिन के प्रत्येक दूसरे को शामिल कर सकता है) के लिए हो सकता है: यह हो सकता है: घंटा, मिनट, दूसरा, दिन भाग लेबल (जैसे "सुबह", "शाम"), कार्य समय संकेतक (8 से सेकंड: 00:00 से 17:00:00), इत्यादि। लेकिन इसे सिर्फ एक आयाम में रखने से बहुत सारी अनावश्यकता होगी।

परिवर्तन उस दिन प्रारंभ/समाप्ति देखो के साथ मेरे लिए एक अच्छे उम्मीदवार के रूप में एक अलग तथ्य कल्पित कहानी रिकॉर्डिंग शुरू करने और प्रत्येक पारी के लिए अंत टाइमस्टैम्प के लिए गठबंधन नहीं कर रहे हैं - मेरा मतलब है (factless) तथ्य तालिका निम्नलिखित विदेशी कुंजी के साथ : id_date_start, id_time_start, id_date_end, id_time_end।फिर आप प्रत्येक शिफ्ट के लिए कुल परिणाम प्राप्त करने के लिए घटनाओं तथ्य तालिका से शिफ्ट तालिका में "ड्रिल-पार" कर सकते हैं।

संपादित करें: या मॉडल एक और आयाम के रूप में बदलाव करता है - यह तथ्य इस बात पर निर्भर करता है कि यदि आपके लिए शिफ्ट एक महत्वपूर्ण व्यावसायिक प्रक्रिया है जिसे आप अपने गुणों के साथ स्वतंत्र रूप से ट्रैक करना चाहते हैं (लेकिन इस समय मैं नहीं सोच सकता कोई अन्य विशेषताएँ तो दिनांक & समय ... स्थान, शायद?) या यदि यह केवल एक घटना का संदर्भ है (और इसलिए केवल एक आयाम होना चाहिए)।