डेटवेयरहाउस डिज़ाइन: संयुक्त दिनांक समय आयाम बनाम अलग दिन और समय आयाम और समय क्षेत्र

हम एक नए डेटा वेयरहाउस के लिए डिज़ाइन शुरू कर रहे हैं और हम यह डिज़ाइन करने की कोशिश कर रहे हैं कि हमारी तारीख और समय के आयाम कैसे काम करेंगे। हमें कई टाइमज़ोन (शायद कम से कम GMT, IST, PST और EST) का समर्थन करने में सक्षम होना चाहिए। हम शुरू में सोच रहे थे कि शायद हमारे पास 15 मिनट की ग्रैन्युलैरिटी के लिए एक व्यापक संयुक्त तिथि समय आयाम होगा, इस तरह से हमारे तथ्य तालिकाओं में एक कुंजी है और सभी समर्थित टाइमज़ोन के लिए सभी अलग-अलग तिथि डेटा एक आयाम तालिका में हैं। (यानी दिनांक कुंजी, GMT दिनांक, GMT समय, IST दिनांक, IST समय, आदि ...)

किमबॉल तालिका को बहुत बड़े होने से रोकने के लिए दिन के आयाम के समय से एक अलग दिन आयाम होने का सुझाव देता है (डेटा वेयरहाउस टूलकिट पी। 240) जो ठीक लगता है लेकिन इसका मतलब है कि हमारे तथ्य तालिकाओं में दो कुंजी प्रत्येक समय क्षेत्र के लिए होगी। हमें समर्थन करने की आवश्यकता है (तारीख के लिए एक और दिन के समय के लिए एक)।

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

यदि हम 15 मिनट का अनाज करते हैं, तो हमारे पास हमारी तारीख समय आयाम तालिका में प्रति वर्ष 131,400 (24 * 15 * 365) पंक्तियां होंगी जो प्रदर्शन के लिए बहुत डरावनी नहीं लगती हैं, लेकिन जब तक हम कुछ परीक्षण नहीं करते, हमें यकीन नहीं होगा प्रोटोटाइप प्रश्न। तथ्य तालिका में अलग-अलग टाइम ज़ोन कीज़ होने के साथ दूसरी चिंता यह है कि क्वेरी को आयाम तालिका में वांछित टाइमज़ोन के आधार पर एक अलग कॉलम में शामिल होना है, शायद यह कुछ ऐसा है जो SSAS आपके लिए ध्यान रखता है, मुझे यकीन नहीं है ।

किसी भी विचार के लिए धन्यवाद, -मैट

— मैट पामरली
स्रोत

यह सवाल स्टैक ओवरफ्लो में भी मौजूद है: stackoverflow.com/questions/2507289/… ।

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

जवाबों:

दिनांक और समय अलग-अलग होने से आप बहुत आसानी से समुच्चय कर पाएंगे। उदाहरण के लिए: यदि आप यह जानना चाहते हैं कि दिन की समयावधि कितनी व्यस्त है, तो आप एक क्वेरी चलाना चाहते हैं। यह बहुत आसानी से एक अलग समय आयाम का उपयोग करके किया जाता है।

इसके अलावा, आपके पास बस एक टाइमकीप होना चाहिए। GMT / EST के समय पर निर्णय लें - फिर इस तथ्य तालिका में उपयोग करें। यदि आपको अन्य टाइमज़ोन के आधार पर रिपोर्ट चलाने की आवश्यकता है, तो बस इसे अपने एप्लिकेशन या क्वेरी में परिवर्तित करें।

— धर्मेंद्र कुमार 'डीके'
स्रोत

ठीक है, इसका मतलब यह है कि उपयोगकर्ता डेटा को अपने टाइमज़ोन के आधार पर समूहित नहीं कर सकते हैं, लेकिन यह संभवत: कुछ ऐसा है जिसे हम डिजाइन को सरल बनाने के लिए बिना रह सकते हैं।

— मैट पामरली

@MattPalmerlee: उपयोगकर्ता समय क्षेत्र द्वारा समूह कर सकते हैं यदि आप उन्हें देते हैं। मैं आमतौर पर इसे Geographyतालिका में शामिल करता हूं , लेकिन यदि कोई भी लागू नहीं करता है तो आप इसे अपने तथ्य तालिका की विशेषता के रूप में जोड़ सकते हैं।

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

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

time_zone_bridge
---------------
date_key_utc
time_key_utc
timezone_id
date_key_local
time_key_local

इस तरह हम अपनी सामान्य तिथि और समय आयाम तालिकाओं को छोटा रख सकते हैं, हमारे सभी तथ्य UTC तिथि / समय कुंजियों से जुड़ सकते हैं, फिर अगर हमें किसी भिन्न समय क्षेत्र द्वारा रिपोर्ट / समूह की आवश्यकता है तो हमें समय क्षेत्र पुल तालिका के माध्यम से जुड़ना होगा और स्थानीय दिनांक / समय कुंजियों को दिनांक और समय आयाम तालिकाओं पर वापस लिंक करें। हम SSIS से प्राप्त C # कोड का उपयोग करके अपने टाइम ज़ोन ब्रिज टेबल को पॉप्युलेट करते हैं क्योंकि यह SqlServer से सीधे TZ सामान करने की तुलना में बहुत कम जटिल था।

— मैट पामरली
स्रोत

मैं यह भी सोचता हूं कि आपका समाधान शायद सबसे अधिक समझ में आता है, बिना किसी चीज के बहुत अधिक जटिल। मैं अपने DW का परीक्षण कर रहा हूँ एक टाइमज़ोन तालिका और TimeZoneBridge के समान। इसमें TimeDimension और DateDimension टेबल भी हैं। मैंने date_key_local, time_key_local, और timezone_id पर एक क्लस्टर इंडेक्स बनाया है, ताकि TimeZoneBridge का उपयोग करके UTC समय के लिए स्थानीय समय का अनुवाद तेजी से हो।

— dsum

पुल तालिका के लिए हमारी प्राथमिक संकुल कुंजी utc तिथि / समय कॉलम + टाइमज़ोन आईडी पर है (यदि मुझे सही याद है), चूंकि सभी तथ्य तालिका समय कुंजियाँ utc में होंगी, आप utc के माध्यम से पुल से जुड़ेंगे कुंजियाँ + tz id, यह उन पर क्लस्टर किए गए इंडेक्स के लिए बेहतर काम कर सकता है। यद्यपि आपकी आवश्यकताओं के लिए क्या मायने रखता है। मुझे खुशी है कि मेरे उत्तर ने किसी की मदद की, मुझे लगता है कि यह एक अच्छा दृष्टिकोण है और हमारे सभी परीक्षण से, यह अभी भी काफी तेजी से है, बस जब यह हो जाए तो सावधान रहना चाहिए: जब आप जितनी जल्दी चाहते हैं उतनी तारीखों को फ़िल्टर करें आपके प्रश्नों में संभव है।

— मैट पामरली

क्या इसमें केवल संपूर्ण तिथियां शामिल हैं? या यदि आपके पास अपनी तथ्य तालिका में 86000 "दिनांक / समय कुंजी" मान है, तो पुल तालिका में 86000 पंक्तियाँ * n समर्थित समय क्षेत्र होंगे, और यह सिर्फ एक दिन के लिए है?

— हारून बर्ट्रेंड

शायद आप अपने पास सटीक तालिका परिभाषा जोड़ सकते हैं, इसलिए पाठक प्राथमिक, अद्वितीय बाधाओं को देख सकते हैं।

— ypercube y

@AaronBertrand यह आपके डेटा को ट्रैक करने के लिए अनाज (या आपके द्वारा चुने गए दानेदारता) पर निर्भर करता है, हमारे मामले में हमें केवल हमारे तथ्य तालिकाओं में 15 मिनट की ग्रैन्युलैरिटी की आवश्यकता थी, इसलिए यह केवल 4 * 24 = 96 रिकॉर्ड प्रति दिन प्रति समय का समर्थन करना चाहता था, जो पूरी तरह से उचित है।

— मैट पामरली

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

Transactions
(
...
CreatedDateTimeSK         INT NOT NULL,  -- Four bytes per date...
AuthorizedDateTimeSK      INT NOT NULL,
BatchSubmittedDateTimeSK  INT NOT NULL,
BatchApprovedDateTimeSK   INT NOT NULL,
SettlementDateTimeSK      INT NOT NULL,
LocalTimeZoneSK           TINYINT NOT NULL  -- ...plus one byte for the time zone
)

DateTimeखेतों दिनांक समय तालिका में शामिल होने:

DateTimes
(
DateTimeSK   INT NOT NULL PRIMARY KEY,
SQLDate      DATE NOT NULL,
SQLDateTime  DATETIME2(0) NOT NULL,
Year         SMALLINT NOT NULL,
Month        TINYINT NOT NULL,
Day          TINYINT NOT NULL,
Hour         TINYINT NOT NULL,
Minute       TINYINT NOT NULL CHECK (Minute IN (0, 30)),
...
)

यह आधे घंटे के एक संकल्प पर है, इसलिए प्रति दिन 48 रिकॉर्ड हैं, 20 वर्षों में 350,400 - काफी प्रबंधनीय हैं।

संग्रहीत होने पर इवेंट दिनांक / समय UTC में अनुवादित किया जाता है, लेकिन LocalTimeZoneSKफ़ील्ड और एक पुल तालिका के साथ हम आसानी से स्थानीय समय प्राप्त करने के लिए शामिल हो सकते हैं:

TimeZoneBridge
(
DateTimeSK       INT NOT NULL,
TimeZoneSK       TINYINT NOT NULL,
PRIMARY KEY (DateTimeSK, TimeZoneSK),
LocalDateTimeSK  INT NOT NULL
)

आज किए गए लेनदेन को प्राप्त करने के लिए, यूटीसी समय:

SELECT COUNT(*)
FROM Transactions AS T
  INNER JOIN DateTimes AS CD ON T.CreatedDateTimeSK = CD.DateTimeSK
WHERE CD.SQLDate = '2014-08-22'

लेन-देन के लिए स्थानीय समय में, आज किए गए लेनदेन को प्राप्त करने के लिए:

SELECT COUNT(*)
FROM Transactions AS T
  INNER JOIN TimeZoneBridge AS TZB ON T.CreatedDateTimeSK = TZB.DateTimeSK AND T.TimeZoneSK = TZB.TimeZoneSK
  INNER JOIN DateTimes AS CD ON TZB.LocalDateTimeSK = CD.DateTimeSK
WHERE CD.SQLDate = '2014-08-22'

आपको ऑफसेट के TimeZoneSKसाथ बदलकर चीजों को सरल बनाने का प्रलोभन दिया जा सकता है REAL(जैसे, यूएस सेंट्रल डेलाइट टाइम के लिए -5.0), लेकिन यह टूट जाएगा यदि किसी तथ्य के रिकॉर्ड के लिए कुछ तारीख / समय डेलाइट सेविंग टाइम में हैं और कुछ नहीं हैं।

यदि फैक्ट रिकॉर्ड के लिए घटनाएँ अलग-अलग समय क्षेत्रों में हो सकती हैं, जैसे कि शिपमेंट या फ़्लाइट, तो आपको प्रत्येक दिनांक के लिए समय क्षेत्र फ़ील्ड की आवश्यकता होती है, और आप प्रति दिनांक पाँच बाइट्स तक होते हैं।

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

यह एक रचनात्मक दृष्टिकोण है। हालाँकि, जैसा कि आप कहते हैं कि आपके संयुक्त डेटाइम डिम टेबल में केवल 350,400 पंक्तियाँ होंगी, यदि आप दाने को महीन रिज़ॉल्यूशन में बदलना शुरू करते हैं, तो आप जल्दी से लाखों रिकॉर्ड में पहुँच जाएंगे। यदि आप समय आयाम की तुलना में एक अलग तिथि आयाम का चुनाव करते हैं, तो आपकी समय आयाम तालिका में केवल ४ in पंक्तियाँ हैं और आपकी तिथि आयाम तालिका में प्रति वर्ष केवल ३६५ पंक्तियाँ हैं (या २० वर्षों में rows३०० पंक्तियाँ)। आपकी तथ्य तालिका में फिर date_key और time_key के लिए एक कॉलम है। यह भी अधिक लचीला बनाता है यदि आपके पास कुछ तथ्य तालिकाएं हैं जो केवल तारीख ग्रैन्युलैरिटी की आवश्यकता होती हैं।

— मैट पामरली

एक आयाम में एक लाख पंक्तियाँ मुझे चिंतित नहीं करती हैं - डेटा केवल एक दशक में एक बार बदला जाता है, और पीके और दो या तीन सबसे अधिक उपयोग किए जाने वाले क्षेत्रों पर एक आवरण सूचकांक सर्वर रैम की एक तुच्छ मात्रा में ले जाएगा। हालाँकि, एक आधा दर्जन से अधिक SMALLINTबिलियन-पंक्ति फैक्ट टेबल में 12 जीबी प्लस ओवरहेड जोड़ रहे हैं, और अब आप असली पैसे की बात कर रहे हैं। उन तिथियों के लिए जिन्हें केवल तारीख संग्रहीत करने की आवश्यकता है, आप निश्चित रूप से उन्हें उचित तिथि के लिए "12:00 पूर्वाह्न" रिकॉर्ड कर सकते हैं।

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