डेटा मार्ट / वेयरहाउस में समय क्षेत्र को संभालना

Question

हम एक डेटा मार्ट / वेयरहाउस के निर्माण खंडों को डिजाइन करना शुरू कर रहे हैं और हमें हर समय क्षेत्र (हमारे ग्राहक दुनिया भर से हैं) का समर्थन करने में सक्षम होने की आवश्यकता है। ऑनलाइन (और किताबों में) चर्चा को पढ़ने से, एक सामान्य समाधान के लिए एक अलग दिनांक और समय के आयाम के साथ-साथ तथ्य तालिकाओं में टाइमस्टैम्प भी लगता है।

हालाँकि, इस प्रश्न का उत्तर देने में मुझे कठिन समय आ रहा है कि वास्तव में मेरे गतिशील समय क्षेत्र की आवश्यकताओं को देखते हुए तारीख और समय आयाम मेरे लिए क्या अच्छा है? एक समय आयाम थोड़ा अधिक समझ में आता है, लेकिन मैं तारीख आयाम के साथ कठिन समय बिता रहा हूं। दिनांक आयाम के लिए एक सामान्य डिज़ाइन दृष्टिकोण में आम तौर पर दिन का नाम, सप्ताह का दिन, महीने का नाम आदि जैसे गुण शामिल होते हैं। जो समस्या मुझे हो रही है वह यह है कि मंगलवार, 31 दिसंबर, 2013 को UTC में बुधवार 11:00 PM बुधवार है। UTC + 2 के बाद सभी समय क्षेत्रों में पहली जनवरी, 2014।

इसलिए अगर मुझे प्रत्येक और हर प्रश्न (और रिपोर्ट) पर इन सभी समय क्षेत्र रूपांतरणों को करना होगा तो इन गुणों को रखने और संग्रहीत करने का क्या मतलब है जो मैं शायद कभी उपयोग नहीं करूंगा (जैसा लगता है)? कुछ लोग प्रत्येक समय क्षेत्र के लिए तथ्य पंक्तियाँ रखने का सुझाव देते हैं लेकिन यह मुझे हास्यास्पद लगता है। हमें हर महीने लाखों रिकॉर्ड स्टोर करने में सक्षम होना चाहिए।

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

केवल एक चीज जिसके बारे में मैं सोच सकता हूं, वह है दिनांक और घंटे द्वारा समूहीकरण का आसान और संभवतया प्रदर्शन लेकिन डेटापीट द्वारा समूह के लिए कितना बुरा व्यवहार है (हम एमएस SQL ​​का उपयोग कर रहे हैं लेकिन हम लाखों पंक्तियों की क्वेरी करेंगे) या हमें विचार करना चाहिए अधिकांश भागों के लिए घंटे, दिन, महीने और साल की संख्या के साथ बहुत ही सरल तारीख और समय के आयाम, जैसे कि सोमवार को खेलने के लिए सबसे ज्यादा शाब्दिक अर्थ होता है जब समय क्षेत्र में नहीं आते हैं?

Comments

मुझे लगता है कि आप के बाद क्या कर रहे हैं datetimeoffset डेटाटाइप और फिर उनके UTC प्रतिनिधित्व में सभी तिथियों को संग्रहीत करें। फिर जब आपको डेटा निकालने की आवश्यकता होती है, तो आप डेटा को UTC मान में क्वेरी करते हैं और क्लाइंट को उसके स्थानीय समय में इसका प्रतिनिधित्व करते हैं।

— एलन एस। हैनसेन

मैं बिना किसी कारण के सोच सकता हूं कि मैं तारीख को स्वतंत्र रूप से संग्रहीत करना चाहता हूं। इसे UTC डेटाटाइम के रूप में संग्रहीत करें और प्रस्तुति परत को स्थानीयकरण के बारे में चिंता करने दें।

— बिलिन्क

मैं @billinkc से सहमत हूँ। मुझे यकीन नहीं है कि आपको अलग-अलग समय और समय के साथ जमा करने से क्या लाभ होगा जब आप लगातार समय क्षेत्र रूपांतरण करने के लिए उन्हें एक साथ वापस डालेंगे।

— mmarie

@billinkc: "मैं बिना किसी कारण के सोच सकता हूं कि मैं तारीख को स्वतंत्र रूप से संग्रहीत करना चाहता हूं।" - हाँ मैं। जब भी आप गोदाम से एक घन का निर्माण कर रहे हैं। अलग-अलग दिनांक और समय-अवधि के आयाम होना सामान्य और सर्वोत्तम अभ्यास है।

— मिच गेहूं

@ मिच क्या आप मुझे यह समझने में मदद कर सकते हैं कि (शायद आप एक जवाब लिख रहे हैं)? मैं वैश्विक बिक्री के साथ एक वयस्क कंपनी हूं और 2300 जीएमटी में, मेरी बिक्री में मजबूत वृद्धि है। मैं अपने स्लाइसर को रिपोर्ट में खींचता हूं और सुनिश्चित करता हूं कि अमेरिकी पूर्वी और मध्य समय क्षेत्रों में, मेरी कुछ बिक्री हो सकती है क्योंकि लोग घर पर रास्ते में कुछ पैक किए गए पेय लेते हैं, लेकिन भारत में यह 0330 है, किसी को भी उस समय किंगफिशर नहीं मिल रहा है और पर्थ के 6 am Y'all के नीचे शक्तिशाली हैं, लेकिन कौन VB के साथ अपने दाँत ब्रश कर रहा है? इसके बजाय, लोग 1700 के काम के बाद शराब खरीदते हैं, लेकिन मुझे फिर तारीख सीमाओं के बारे में चिंता करने की ज़रूरत है

— बिलिंक

Answer 1

पहले तो...

को अलग Datime/Timeएक में Dateआयाम और एक Timeआयाम निश्चित रूप से जाने के लिए रास्ता है।

कई समय क्षेत्रों का प्रबंधन करने के लिए, आपको डुप्लिकेट करने की आवश्यकता है DateKeyऔर TimeKeyताकि आपके पास निम्नलिखित हों:

• LocalDateKey
• LocalTimeKey
• UtcDateKey
• UtcTimeKey

तुम कहो...

मुझे जो समस्या हो रही है, वह यह है कि UTC + 2 के बाद के सभी समय क्षेत्रों में बुधवार, 1 जनवरी, 2014 को UTC में मंगलवार, 31 दिसंबर, 2013 को 11:00 PM है।

आपके द्वारा ऊपर सूचीबद्ध 4 कॉलम होने से, आप टेबल एलेसेस (किमबॉल शब्दावली में इन अलियासिड डायमेंशन टेबल को "रोल प्लेइंग डायमेंशन" के रूप में जाना जाता है) का उपयोग करके फैक्ट टेबल को डेट और / या टाइम डायमेंशन में शामिल कर पाएंगे। आपके पास कुछ इस तरह होगा:

/*
    Assumes the following:
        - [DateLongName] has the format of this example "Tuesday, December 31, 2013"
        - [TimeShortName] has the format of this example "11:00 PM"
        - Both [DateLongName] & [TimeShortName] are strings
*/
select
    -- Returns a string matching this example  "11:00 PM Tuesday, December 31, 2013"
    localTime.TimeShortName + ' ' + localDate.DateLongName
    ,utcTime.TimeShortName + ' ' + utcDate.DateLongName
    ,f.*
from
    FactTableName  AS f

    -- Local Date and Local Time joins          
    inner join dbo.Date  AS localDate
        on localDate.DateKey = f.LocalDateKey

    inner join dbo.Time  AS localTime
        on localTime.TimeKey = f.LocalTimeKey 

    -- Utc Date and Utc Time joins    
    inner join dbo.Date  AS utcDate
        on utcDate.DateKey = f.UtcDateKey

    inner join dbo.Time  AS utcTime
        on utcTime.TimeKey = f.UtcTimeKey 

बंद होने को...

जैसा कि आप एक डेटा मार्ट का निर्माण कर रहे हैं, और एक ओएलटीपी डेटाबेस नहीं, स्थानीय और यूटीसी समय की पीढ़ी को आपके ईटीएल में प्रदर्शन किया जाना चाहिए , न कि निम्नलिखित कारणों से किसी भी क्लाइंट साइड एप्लिकेशन में (यूटीसी समय के स्थानीयकरण के अलावा) पाठक के दृष्टिकोण की रिपोर्ट करें:

• किसी भी क्वेरी में निवास की गणना होने से उन पर एक अतिरिक्त प्रदर्शन का बोझ पड़ता है, जितनी बार आपको चलना है, उतनी क्वेरी आपके द्वारा बताई गई किसी भी रिपोर्ट के लिए गुणा होती है (यह लाखों पंक्तियों को पढ़ते समय मायने रखती है)
• गणना को सुनिश्चित करने का अतिरिक्त बोझ प्रत्येक प्रश्न में सही ढंग से रखा गया है (विशेषकर जब आप दिन के समय की बचत खाते में लेते हैं)
• किसी भी अनुक्रमणिका की स्कैनिंग को रोकने की सीमा स्तंभ का हिस्सा है, जैसा कि आप स्तंभ पर एक गणना कर रहे हैं, जो प्रश्नों को अनुक्रमित करने के बजाय अनुक्रम स्कैन करने के लिए मजबूर करता है (जो आमतौर पर अधिक महंगे होते हैं क्योंकि प्रत्येक डेटा पृष्ठ को पढ़ने की आवश्यकता होती है); यह गैर- सारगर्भित होने के रूप में जाना जाता है ।
  • टिप्पणियों के कारण संपादित करें: यह लागू होता है यदि आप रूपांतरण को वास्तविक क्वेरी में नीचे धकेलते हैं ।
• अतिरिक्त UTC दिनांक और समय उपलब्ध होने की अवधारणा का उपयोग करते हुए, आपको इस अवधारणा को लेने और इसे कॉल करके विस्तारित करने से कुछ भी नहीं रोक रहा है StandardisedDateKey, या CorporateHQDateKey, जहाँ UTC दिनांक तालिका के बजाय आप किसी अन्य व्यवसाय के आधार पर मानकीकृत करते हैं, सहमत मानक
• दो अलग-अलग कॉलम प्रकार (स्थानीय और UTC) होने से भौगोलिक दूरी के पार-साइड तुलना की अनुमति मिलती है। सोचो -> ऑस्ट्रेलिया में कोई व्यक्ति एक रिकॉर्ड में प्रवेश करता है जो स्थानीय और यूटीसी दोनों के साथ समयावधि में है, न्यूयॉर्क में कोई व्यक्ति स्थानीय (ऑस्ट्रेलिया) तारीख और समय के साथ रिपोर्ट पढ़ता है और यूटीसी तिथि और समय का न्यूयॉर्क प्रतिनिधित्व करता है, जिससे कुछ दिखाई देता है उनके ऑस्ट्रेलियाई समकक्ष ने दिन के मध्य में किया था (ऑस्ट्रेलिया समय) रात के मध्य में उनके समय (न्यूयॉर्क समय) में हुआ था। बहु-राष्ट्रीय व्यवसायों में समय की यह तुलना अपरिहार्य है।

Comments

एकल के बजाय अलग Dateऔर Timeआयामों का उपयोग क्यों करें DateTime? एक तथ्य तालिका में कई तिथियां हो सकती हैं, और प्रत्येक के लिए एक के बजाय दो INTs का भंडारण कर सकते हैं।

— जॉन ऑफ ऑल ट्रेड्स

सभी ट्रेडों के @Jon: अलग दिनांक और समय Dimesions एक आम सर्वोत्तम अभ्यास है। यह समग्र आयाम कार्डिनैलिटी को कम करता है, और व्यवहार में हम अक्सर तारीख और समय दोनों से स्लाइस करते हैं, या तारीख से फ़िल्टर करते हैं और फिर समय से स्लाइस करते हैं।

— मिच गेहूं

Answer 2

मैं इस जवाब की संक्षिप्तता के लिए समय से पहले माफी मांगता हूं और काम पर नहीं होने पर विस्तार से बताने की योजना बनाता हूं।

आपके डेटा के आसान एकत्रीकरण के लिए अनुमति देने के लिए निश्चित रूप से तारीख और समय सारणी होने के सबसे अधिक फायदे हैं। बहुत सारे मामलों में यह उस प्रकृति की चीजों को महीने या व्यावसायिक दिनों के अनुसार क्रमबद्ध करने का सबसे सरल तरीका है। हालाँकि यह आवश्यक रूप से टाइमस्टैम्प की उपयोगिता को प्रतिस्थापित नहीं करता है। आपके विशेष मामले में एक यूटीसी टाइमस्टैम्प। एक बार आपके पास वह टाइमस्टैम्प है, जो आपको करना है वह है कि रिपोर्ट या प्रस्तुति परत में स्थानीय समय में परिवर्तन करें। रेंज स्कैन से बचने के लिए सुनिश्चित करें कि आप अपनी अनुरोध सीमा को यूटीसी समय में भी परिवर्तित कर रहे हैं।

यदि कोई अन्य प्रश्न या टिप्पणी बेझिझक पूछी जाए।

Comments

इस सवाल का जवाब नहीं है।

— मिच गेहूं