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

स्टार स्कीमा

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

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

अब जब हम सिस्टम के बारे में थोड़ा जान गए हैं, तो आइए डेटा वेयरहाउस और उसके टुकड़ों और प्रक्रियाओं की जांच शुरू करें।

डेटा वेयरहाउस बनाम डेटा मार्ट

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

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

डेटा वेयरहाउस-डेटा मार्ट संबंध के दो अलग-अलग दृष्टिकोण हैं:

  • ऊपर से नीचे :डेटा मार्ट डेटा वेयरहाउस से बनाए जाते हैं। (यह कुछ ऐसा है जिससे बिल इनमोन, "डेटा वेयरहाउस के पिता", इस विचार के साथ सहमत होंगे कि वेयरहाउस 3NF में होने चाहिए।)
  • नीचे से ऊपर :डेटा मार्ट पहले बनाए जाते हैं, फिर डेटा वेयरहाउस में संयुक्त होते हैं। (यह दृष्टिकोण राल्फ किमबॉल, एक डेटा वेयरहाउस और डायमेंशनल मॉडलिंग विशेषज्ञ, अधिवक्ताओं के करीब है।)

ETL प्रक्रिया नियमित आधार पर OLAP सिस्टम में "नया" डेटा जोड़ने के लिए उपयोग किया जाता है। ईटीएल एक्सट्रैक्ट, ट्रांसफॉर्म और लोड के लिए छोटा है। जैसा कि नाम से संकेत मिलता है, हम एक या अधिक परिचालन डेटाबेस से डेटा निकालेंगे, इसे हमारे वेयरहाउस संरचना में फिट करने के लिए रूपांतरित करेंगे, और डेटा को DWH में लोड करेंगे।

आयामी मॉडलिंग , जो डेटा वेयरहाउस डिज़ाइन का हिस्सा है, जिसके परिणामस्वरूप आयामी मॉडल का निर्माण होता है। इसमें दो तरह की टेबल शामिल हैं:

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

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

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

इस जानकारी के साथ, अब हम स्टार स्कीमा डेटा मॉडल में खुदाई कर सकते हैं।

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




तारा स्कीमा DWH में उपयोग किया जाने वाला सबसे सरल मॉडल है। चूंकि तथ्य तालिका स्कीमा के केंद्र में होती है, जिसके चारों ओर आयाम तालिकाएं होती हैं, यह मोटे तौर पर एक तारे की तरह दिखता है। यह विशेष रूप से तब स्पष्ट होता है जब तथ्य तालिका पांच आयाम तालिकाओं से घिरी होती है। स्टार स्कीमा का एक प्रकार सेंटीपीड स्कीमा , जहां तथ्य तालिका बड़ी संख्या में छोटे आयाम तालिकाओं से घिरी होती है।

डेटा मार्ट में आमतौर पर स्टार स्कीमा का उपयोग किया जाता है। हम उन्हें टॉप-डाउन डेटा मॉडल दृष्टिकोण से जोड़ सकते हैं। हम दो स्टार स्कीमा (डेटा मार्ट) का विश्लेषण करेंगे और फिर उन्हें एक मॉडल बनाने के लिए संयोजित करेंगे।

स्टार स्कीमा उदाहरण:बिक्री

बिक्री रिपोर्ट आज की सबसे आम रिपोर्टों में से एक है। जैसा कि हमने पहले उल्लेख किया है, ज्यादातर मामलों में हम लाइव सिस्टम से बिक्री रिपोर्ट तैयार कर सकते हैं। लेकिन जब डेटा या व्यवसाय का आकार इसे बहुत बोझिल बना देता है, तो हमें प्रक्रिया को सुव्यवस्थित करने के लिए डेटा वेयरहाउस या डेटा मार्ट बनाना होगा। हमारे स्टार स्कीमा को डिजाइन करने के बाद, एक ETL प्रक्रिया ऑपरेशनल डेटाबेस (डेटाबेस) से डेटा प्राप्त करेगी, डेटा को DWH के लिए उचित प्रारूप में बदल देगी, और डेटा को वेयरहाउस में लोड करेगी।

ऊपर प्रस्तुत मॉडल में एक तथ्य तालिका (रंगीन हल्का लाल) और पांच आयाम तालिकाएं (रंगीन हल्का नीला) शामिल हैं। मॉडल में टेबल हैं:

  • fact_sales - इस तालिका में आयाम तालिकाओं के साथ-साथ दो तथ्य (कीमत और बेची गई मात्रा) के संदर्भ हैं। ध्यान दें कि सभी पाँच विदेशी कुंजियाँ मिलकर तालिका की प्राथमिक कुंजी बनाती हैं।
  • dim_sales_type – यह एक बिक्री-प्रकार आयाम तालिका है जिसमें केवल एक विशेषता है, “type_name "।
  • dim_employee - यह एक कर्मचारी आयाम तालिका है जो बुनियादी कर्मचारी विशेषताओं को संग्रहीत करती है:पूरा नाम और जन्म वर्ष।
  • dim_product - यह केवल दो विशेषताओं (प्राथमिक कुंजी के अलावा) के साथ एक उत्पाद आयाम तालिका है:उत्पाद का नाम और उत्पाद प्रकार।
  • dim_time - यह तालिका समय आयाम को संभालती है। इसमें प्राथमिक कुंजी के अलावा पाँच विशेषताएँ होती हैं। निम्नतम स्तर का डेटा तिथि के अनुसार बिक्री है (action_date ) action_week विशेषता उस वर्ष में सप्ताह की संख्या है (अर्थात जनवरी के पहले सप्ताह को नंबर 1 दिया जाएगा; दिसंबर के अंतिम सप्ताह को नंबर 52 मिलेगा, आदि) actual_month और actual_year विशेषताएँ कैलेंडर माह और वर्ष को संग्रहीत करती हैं जब बिक्री हुई थी। इन्हें action_date . से निकाला जा सकता है गुण। action_weekday विशेषता उस दिन का नाम संग्रहीत करती है जब बिक्री हुई थी।
  • dim_store - यह एक स्टोर आयाम है। प्रत्येक स्टोर के लिए हम उस शहर, क्षेत्र, राज्य और देश को सहेजेंगे जहां वह स्थित है। यहां हम स्पष्ट रूप से देख सकते हैं कि स्टार स्कीमा असामान्य है।

स्टार स्कीमा उदाहरण:आपूर्ति आदेश

नीचे दिखाए गए इस मॉडल और बिक्री मॉडल के बीच बहुत सी समानताएं हैं।




इस मॉडल का उद्देश्य रखे गए ऑर्डर के इतिहास को संग्रहीत करना है। हमारे पास एक तथ्य तालिका और चार आयाम तालिकाएं हैं। आयाम तालिकाएं dim_employee , dim_product और dim_time बिक्री मॉडल के समान ही हैं। हालाँकि, निम्न तालिकाएँ भिन्न हैं:

  • fact_supply_order - इसमें दिए गए ऑर्डर के बारे में समेकित डेटा होता है।
  • dim_supplier - एक आयाम तालिका है जो आपूर्तिकर्ता डेटा को उसी तरह संग्रहीत करती है जैसे dim_store डेटा को सेल्स मॉडल में स्टोर करता है।

स्टार स्कीमा के लाभ और हानि

स्टार स्कीमा का उपयोग करने के बहुत सारे फायदे हैं। तथ्य तालिका प्रत्येक आयाम तालिका से ठीक एक संबंध से संबंधित है, और हमें आयाम तालिकाओं का वर्णन करने के लिए किसी अतिरिक्त शब्दकोश की आवश्यकता नहीं है। यह प्रश्नों को सरल करता है और क्वेरी निष्पादन समय को कम करता है। हम वही रिपोर्ट सीधे अपने OLTP सिस्टम से तैयार कर सकते हैं, लेकिन क्वेरी बहुत अधिक जटिल होगी और यह सिस्टम के समग्र प्रदर्शन को प्रभावित कर सकती है। बिक्री मॉडल के लिए निम्न नमूना क्वेरी 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

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

गैलेक्सी स्कीमा

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

हमारे दो उदाहरण डेटा मार्ट से निर्मित आकाशगंगा स्कीमा, नीचे दिखाया गया है:




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


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. डेटा गवर्नेंस के लिए मानवीय दृष्टिकोण अपनाएं

  2. कर्सर विकल्पों पर अनुवर्ती कार्रवाई

  3. ऑप्टिमाइज़ेशन थ्रेशोल्ड - डेटा को समूहीकृत करना और एकत्र करना, भाग 5

  4. Salesforce.com पर अपने ODBC कनेक्शन को प्रमाणित करने के लिए OAuth का उपयोग करना

  5. कैसे सुनिश्चित करें कि डेटाबेस का नियमित रूप से बैकअप लिया जाता है