Database
 sql >> डेटाबेस >  >> RDS >> Database

स्टार स्कीमा बनाम स्नोफ्लेक स्कीमा

पिछले दो लेखों में, हमने दो सबसे आम डेटा वेयरहाउस मॉडल पर विचार किया:स्टार स्कीमा और स्नोफ्लेक स्कीमा। आज, हम इन दो स्कीमाओं के बीच के अंतरों की जांच करेंगे और बताएंगे कि कब एक या दूसरे का उपयोग करना बेहतर है।

स्टार स्कीमा और स्नोफ्लेक स्कीमा रिलेशनल डेटाबेस का उपयोग करके डेटा मार्ट या संपूर्ण डेटा वेयरहाउस को व्यवस्थित करने के तरीके हैं। ये दोनों आयाम तालिकाओं का उपयोग करते हैं तथ्य तालिका . में एकत्रित डेटा का वर्णन करने के लिए ।

हर कोई कुछ न कुछ बेचता है, चाहे वह ज्ञान हो, उत्पाद हो या सेवा हो। इस जानकारी को या तो एक परिचालन प्रणाली में या एक रिपोर्टिंग प्रणाली में संग्रहीत करना भी एक आवश्यकता है। इसलिए हम लगभग हर कंपनी के डेटा वेयरहाउस के अंदर किसी न किसी प्रकार के बिक्री मॉडल को खोजने की उम्मीद कर सकते हैं।

आइए स्टार और स्नोफ्लेक स्कीमा दोनों में बिक्री मॉडल पर एक और नज़र डालें।

द स्टार स्कीमा



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

इस मॉडल से, हम आसानी से देख सकते हैं कि इस स्कीमा को 'स्टार स्कीमा' क्यों कहा जाता है:यह केंद्रीय तथ्य तालिका के चारों ओर आयाम तालिकाओं के साथ एक स्टार की तरह दिखता है।

द स्नोफ्लेक स्कीमा



यह स्नोफ्लेक स्कीमा स्टार स्कीमा के समान ही डेटा संग्रहीत करता है। फैक्ट टेबल के आयाम वही होते हैं जो स्टार स्कीमा उदाहरण में होते हैं। सबसे महत्वपूर्ण अंतर यह है कि स्नोफ्लेक स्कीमा में आयाम तालिकाएँ सामान्यीकृत होती हैं। दिलचस्प बात यह है कि आयाम तालिकाओं को सामान्य करने की प्रक्रिया को स्नोफ्लेकिंग कहा जाता है।

एक बार फिर, नेत्रहीन रूप से स्नोफ्लेक स्कीमा हमें इसके नाम की याद दिलाता है, आयाम तालिकाओं की कई परतों के साथ एक अनियमित स्नोफ्लेक जैसी आकृति बनाते हैं।

पहला अंतर:सामान्यीकरण

जैसा कि उल्लेख किया गया है, सामान्यीकरण स्टार और स्नोफ्लेक स्कीमा के बीच एक महत्वपूर्ण अंतर है। इसके बारे में, कुछ बातें जानने योग्य हैं:

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

आइए इन दो स्कीमाओं के बीच दूसरे प्रमुख अंतर पर चलते हैं।

दूसरा अंतर:क्वेरी जटिलता

हमारे पहले दो लेखों में, हमने 2016 में बर्लिन स्टोर में बेचे जाने वाले सभी फ़ोन-प्रकार के उत्पादों की मात्रा प्राप्त करने के लिए बिक्री मॉडल पर इस्तेमाल की जा सकने वाली एक क्वेरी का प्रदर्शन किया।

स्टार स्कीमा क्वेरी इस तरह दिखती है:

SELECT 
  dim_store.store_address,
  SUM(fact_sales.quantity) AS quantity_sold

FROM 
  fact_sales
  INNER JOIN dim_product ON fact_sales.product_id = dim_product.product_id
  INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id

WHERE 
  dim_time.action_year = 2016
  AND dim_store.city = 'Berlin'
  AND dim_product.product_type = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

स्नोफ्लेक स्कीमा से समान परिणाम प्राप्त करने के लिए, हमें इस क्वेरी का उपयोग करना होगा:

SELECT 
  dim_store.store_address,
  SUM(fact_sales.quantity) AS quantity_sold

FROM 
  fact_sales
  INNER JOIN dim_product ON fact_sales.product_id = dim_product.product_id
  INNER JOIN dim_product_type ON dim_product.product_type_id = dim_product_type.product_type_id
  INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_year ON dim_time.year_id = dim_year.year_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id
  INNER JOIN dim_city ON dim_store.city_id = dim_city.city_id

WHERE 
  dim_year.action_year = 2016
  AND dim_city.city = 'Berlin'
  AND dim_product_type.product_type_name = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

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

स्टार स्कीमा में, हम केवल उन आयाम तालिकाओं के साथ तथ्य तालिका में शामिल होते हैं जिनकी हमें आवश्यकता होती है। अधिक से अधिक, हमारे पास प्रति आयाम तालिका में केवल एक जॉइन होगा। और अगर हम आयाम तालिका का उपयोग नहीं कर रहे हैं, तो हमें इससे परेशान होने की भी आवश्यकता नहीं है। स्नोफ्लेक स्कीमा क्वेरी में, हम नहीं जानते कि सही आयाम स्तर प्राप्त करने के लिए हमें कितनी गहराई तक जाना होगा, जिससे प्रश्नों को लिखने की प्रक्रिया जटिल हो जाती है।

दो तालिकाओं में शामिल होने में समय लगता है क्योंकि डीएमबीएस अनुरोध को संसाधित करने में अधिक समय लेता है। dim_store और dim_city तालिकाओं को हमारे मॉडल में निकटता में रखा गया है, लेकिन वे डिस्क पर एक दूसरे के पास कहीं भी स्थित नहीं हो सकते हैं। एक बेहतर संभावना है कि डेटा डिस्क पर भौतिक रूप से करीब होगा यदि वह उसी तालिका के अंदर रहता है।

मूल रूप से, स्नोफ्लेक स्कीमा डेटा मार्ट के विरुद्ध चलने वाली क्वेरी अधिक धीमी गति से निष्पादित होगी। लेकिन ज्यादातर मामलों में यह कोई समस्या पेश नहीं करेगा:अगर हमें एक मिलीसेकंड या एक सेकंड में परिणाम मिलता है तो इससे कोई फर्क नहीं पड़ता।

चीजों को गति देना

रिपोर्टिंग में तेजी लाने के लिए, हम यह कर सकते हैं:

  • डेटा को उस स्तर तक एकत्रित करें जिसकी हमें रिपोर्ट में आवश्यकता है। यह डेटा को महत्वपूर्ण रूप से संपीड़ित करेगा। हमें ऐसी प्रक्रियाएं बनानी होंगी जो हमारे लाइव डेटा को रिपोर्टिंग स्कीमा संरचना (ईटीएल प्रक्रिया) में फिट करने के लिए बदल दें।
  • सभी . के लिए एक केंद्रीय भंडारण क्षेत्र बनाएं कंपनी का समेकित डेटा, न केवल बिक्री डेटा।
  • केवल उपयोगकर्ताओं को विश्लेषण और रिपोर्ट के लिए आवश्यक डेटा दें।

स्नोफ्लेक बनाम स्टार स्कीमा:आपको किसका उपयोग करना चाहिए?

अब जब हमने सिद्धांत और क्वेरी गति को देख लिया है, तो आइए मामले के केंद्र में आते हैं:आप कैसे जानते हैं कि किसी दिए गए प्रोजेक्ट पर किस स्कीमा का उपयोग करना है?

स्नोफ्लेक स्कीमा का उपयोग करने पर विचार करें :

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

तारा स्कीमा का उपयोग करने पर विचार करें :

  • डेटा मार्ट में। डेटा मार्ट केंद्रीय डेटा वेयरहाउस से निकाले गए डेटा के सबसेट हैं। वे आम तौर पर विभिन्न विभागों के लिए बनाए जाते हैं और यहां तक ​​कि सभी इतिहास डेटा भी शामिल नहीं होते हैं। इस सेटिंग में, संग्रहण स्थान को सहेजना प्राथमिकता नहीं है।

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

  • यदि आप ऐसे टूल का उपयोग करते हैं जिनके लिए बैकग्राउंड में स्टार स्कीमा की आवश्यकता होती है। (फिर से, यह आमतौर पर कोई समस्या नहीं है।)

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


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. SQL जॉइन के लिए आपका अंतिम गाइड:INNER JOIN - भाग 1

  2. BYOC के लिए नई सुविधा - क्लस्टर को रोकना और फिर से शुरू करना

  3. ट्रांजैक्ट-एसक्यूएल में संयोजन

  4. वर्ष 2038 की समस्या क्या है?

  5. UI डिज़ाइन पैटर्न जो स्केल नहीं करते हैं