डेटा वेयरहाउस में कई-से-कई संबंधों को लागू करने के कुछ तरीके क्या हैं?


25

डेटा वेयरहाउस मॉडलिंग (स्टार, स्नोफ्लेक) के प्रमुख टोपोलॉजी को एक से कई रिश्तों को ध्यान में रखकर बनाया गया है। इन मॉडलिंग योजनाओं में कई-से-कई संबंधों का सामना करने पर क्वेरी की पठनीयता, प्रदर्शन और संरचना बुरी तरह से खराब हो जाती है।

आयामों के बीच या तथ्य तालिका और एक डेटा वेयरहाउस में एक आयाम के बीच कई-से-कई संबंधों को लागू करने के कुछ तरीके क्या हैं और वे आवश्यक ग्रैन्युलैरिटी और क्वेरी प्रदर्शन के संबंध में क्या समझौता करते हैं?


आपको अपने प्रश्न को अधिक स्पष्ट रूप से बताने की आवश्यकता है। यह संभवतः इसलिए है कि 4 के बाद से किसी ने भी इसका जवाब नहीं दिया है। मेरे उत्तर के जवाब में आप जो कहते हैं, वह आपके मूल प्रश्न के समान नहीं है।
IAMIC

@ आईएनसी संपादित क्या यह बेहतर है?
ब्रायन बॉसुन-स्टैंटन

संपूर्ण :)
IAMIC

जवाबों:


17

मेरे अनुभव में, एक पुनरावर्ती पदानुक्रम इस से निपटने का सबसे व्यावहारिक तरीका है। यह निम्नलिखित लाभ प्रदान करता है:

  1. असीमित गहराई।
  2. सघनता।
  3. लचीलापन।
  4. स्पीड।

इसके विपरीत, यह "-to-many" जुड़ने के प्रत्येक स्तर के लिए एक अतिरिक्त तालिका लेता है। यह स्कीमा अपडेट के खिलाफ बनाए रखने के लिए कठिन कोडित और कठिन है।

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

मैं कई वर्षों से इस समस्या को हल करने की कोशिश कर रहा हूं। हाल ही में, यह वही है जिसके साथ मैं आया था।


1
आपने पूछा "इन कई-कई मॉडलिंग के कुछ तरीके क्या हैं और उनके प्रदर्शन और ग्रैन्युलैरिटी निहितार्थ क्या हैं?"। मैंने मॉडलिंग पर जवाब दिया। डाउन-वोट की जरूरत नहीं।
IAMIC

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

2
हां, वे मूल रूप से इसका मॉडल नहीं बनाते हैं। एक और तालिका जोड़ने और इस प्रकार कई-से-कई प्राप्त करने में क्या गलत होगा? RDBMS में, कोई फर्क नहीं पड़ता कि आप अपनी तालिकाओं को कैसे बनाते हैं, आप कई-से-कई के लिए 2 जुड़ने जा रहे हैं। कोई शॉर्टकट नहीं है। एकमात्र संभावित अपवाद PostgreSQL या Caché / M में सरणियाँ है।
IAMIC

1
(एक पुनरावर्ती पदानुक्रम एक अच्छा विचार है, वास्तव में।) समस्या को हल करने का एक तरीका एक आयाम के भीतर संभावित कई-से-कई रिश्तों की सूची को precomputing था, एक सामान्य आयाम तालिका में संदर्भित करता है, और फिर तथ्य तालिका में शामिल हो रहा है। सारांशित आयाम तालिका। "पुनरावर्ती पदानुक्रम" का आपका उत्तर एक और उपयोगी डिज़ाइन उत्तर है। मुझे आश्चर्य है कि क्या इन विभिन्न हैक के प्रदर्शन निहितार्थों पर कोई शोध हुआ है?
ब्रायन बॉसुन-स्टैंटन

3
@ ब्रायन उपयोगी उत्तर के लिए मत भूलना। यह समुदाय बनाने में मदद करता है। आपके प्रश्न का उत्तर देने के लिए, मैं इन हैक्स पर किसी भी शोध में नहीं आया हूं, सिवाय इसके कि "क्या तेज है: एक पुनरावर्ती CTE या मैन्युअल ट्री बिल्ड?"। आप पहले से बताए गए समाधान को अच्छी तरह समझते हैं। मैं इसे अनुक्रमित दृश्य के साथ जोड़ूंगा, जो निश्चित रूप से आश्वस्त करता है कि आपके पास हमेशा सही पूर्व-आबादी वाला संबंध मानचित्र है।
IAMIC

6

एम के लिए कुछ परिदृश्य: डेटा वेयरहाउस मॉडल में एम संबंध

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

परिदृश्य 1: एम: एम एक तथ्य तालिका पर आयाम

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

विकल्प 1 - एम: एम ड्राइवर-फैक्ट ब्रिज टेबल यह डेटा की काफी बड़ी मात्रा होगी, क्योंकि इसमें किसी दिए गए पॉलिसी के लिए ड्राइवर एक्स लेनदेन पंक्तियां हैं। SSAS इस डेटा संरचना का सीधे उपभोग कर सकता है, लेकिन यह एक रोल टूल के माध्यम से क्वेरी करने के लिए धीमा है।

यदि आपका M: M संबंध उन इकाइयों पर आधारित है जो तथ्य पंक्ति (जैसे कार पर ड्राइवर) के लिए विशिष्ट हैं, तो यह एक ROLAP टूल के लिए भी उपयुक्त हो सकता है, बशर्ते आपका ROLAP उपकरण M का समर्थन करता है: M संबंध (जैसे व्यवसाय में संदर्भों का उपयोग करना) ऑब्जेक्ट्स)।

विकल्प 2 - डमी 'संयोजन' आयाम तालिका यदि आप एक तथ्य तालिका के लिए सामान्य कोड की सूची मैप कर रहे हैं (यानी लिंक किए गए निकाय तथ्य पंक्ति के लिए अजीब नहीं हैं) तो आप एक और दृष्टिकोण ले सकते हैं जो डेटा वॉल्यूम कम कर देगा। इस तरह के परिदृश्य का एक उदाहरण एक असंगत यात्रा पर आईसीडी कोड है। प्रत्येक inpatient यात्रा में एक या एक से अधिक ICD निदान और / या इसके खिलाफ सूचीबद्ध प्रक्रियाएं होंगी। ICD कोड वैश्विक हैं।

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

तथ्य तालिका में 'संयोजन' आयाम के लिए एक आयाम कुंजी हो सकती है, और आयाम पंक्ति में वास्तविक ICD कोड के संदर्भों की एक सूची है। अधिकांश रॉप उपकरण इस डेटा संरचना का उपभोग कर सकते हैं। यदि आपका टूल केवल वास्तविक M: M संबंध के साथ काम करेगा, तो आप एक ऐसा दृश्य बना सकते हैं जो M: M संबंध को तथ्य और कोडिंग संदर्भ तालिका के बीच का अनुकरण करता है। यह SSAS के साथ पसंदीदा तरीका होगा।

विकल्प 1 के लाभ: - उचित रूप से अनुक्रमित, एम: एम तालिका के माध्यम से एक निश्चित संबंध के साथ तथ्य तालिका पंक्तियों का चयन करने पर आधारित प्रश्न यथोचित रूप से कुशल हो सकते हैं।

  • थोड़ा सरल वैचारिक मॉडल

विकल्प 2 के लाभ: - डेटा संग्रहण अधिक कॉम्पैक्ट है

  • आप एक सीधे 1: M संबंध को 'संयोजन' आयाम पर एक कोड के रूप में एक मानव-पठनीय प्रारूप में प्रस्तुत करके अनुकरण कर सकते हैं। यह डम्बर रिपोर्टिंग टूल पर अधिक उपयोगी हो सकता है जो एम: एम संबंधों के लिए समर्थन की कमी है।

परिदृश्य 2: एम: एम आयामों के बीच संबंध:

एक उपयोग के मामले के बारे में सोचना मुश्किल है, लेकिन कोई फिर से आईसीडी कोड के साथ स्वास्थ्य सेवा से बाहर की परिकल्पना कर सकता है। एक लागत विश्लेषण प्रणाली पर, inpatient यात्रा एक आयाम बन सकती है, और इसमें M: M संबंध (या NHS-स्पीच में सलाहकार-प्रकरण) और कोडिंग के बीच संबंध होंगे।

इस मामले में आप एम: एम संबंध स्थापित कर सकते हैं, और संभवतः आधार आयाम पर उनमें से एक मानव-पठनीय प्रतिपादन को संहिताबद्ध कर सकते हैं। रिश्तों को सीधे M: M लिंक टेबल के माध्यम से या पहले की तरह एक 'संयोजन' तालिका के माध्यम से किया जा सकता है। इस डेटा संरचना को व्यावसायिक वस्तुओं या बेहतर गुणवत्ता वाले रोल टूल के माध्यम से सही तरीके से समझा जा सकता है।

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


5

मैं वास्तव में जानना चाहता हूं कि आपके मॉडल में आपके मन में किस तरह के कई-से-कई संबंध हैं, या तो यह लेन-देन प्रणाली में है या जो भी डेटा मॉडल वर्तमान में है।

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

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


अच्छा उत्तर। दो मामले हैं जो मैं यहां खोज रहा हूं। तथ्य और आयाम के बीच एक एन: एम, और एक 1: एन: तथ्य, आयाम और आयाम के बीच एम।
ब्रायन बॉल्सन-स्टैंटन

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

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

1
@ ब्रायन बोसुन-स्टैंटन ने किमबॉल फोरम पर एक नज़र डाली और अपनी टूलकिट पुस्तकों में पुलों और आउटरिगरों को
केड रूक्स

@ कैड क्या आप उन लोगों का वर्णन करते हुए जवाब दे सकते हैं? :)
ब्रायन बॉल्सन-स्टैंटन

5

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

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

एक पुल तालिका का उपयोग करके वैकल्पिक पदानुक्रमों की मॉडलिंग करना:

http://www.kimballgroup.com/wp-content/uploads/2012/05/DT62Alternative.pdf

कई संबंधों के लिए कई विकल्प (संख्यात्मक शेयर आवंटन से बंधे - कुछ दिलचस्प आगे और पीछे के लिए टिप्पणियां देखें)

http://www.pythian.com/news/364/implementing-many-to-many-relationships-in-data-warehousing/

दुर्भाग्य से, किमबॉल के बहुत सारे सूचना सप्ताह / DBMS पत्रिका लेखों के अब अच्छे लिंक नहीं हैं ...


'वैकल्पिक पदानुक्रम' लेख का लिंक टूट गया है। हो सकता है कि आप इसका जिक्र कर रहे हों: kimballgroup.com/html/designtipsPDF/DesignTips2004/…
एंडी तजहजोनो

कई लेखों के लिए लिंक के लिए धन्यवाद । मेरे 'अहा!' इससे पल।
एंडी तजहोनो

दूसरा लिंक मर चुका है। यहाँ उसी लेख की एक नई कड़ी है। यह कुछ हद तक विकृत है, और किसी बिंदु पर इसके सभी ग्राफिक्स खो दिए हैं। blog.pythian.com/…
posfan12

1

एक तरीका है कि हम इसे हल कर सकते हैं एक फैक्ट टेबल के लिए बस 2 कॉलम हैं, 2 आयामों से विदेशी कुंजी के लिए कई संबंध वाले जहाज हैं।


1
यह कैसे मामलों को हल करता है?
ब्रायन बॉल्सन-स्टैंटन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.