कई-से-कई, OLAP और MS SQL सर्वर विश्लेषण सेवाएँ

कई-से-कई संबंध और एमएस SQL ​​सर्वर विश्लेषण सेवाएँ

मैं इस पोस्ट को ऐसी सरल समस्या के लिए समर्पित करना चाहता हूं जैसे कि MS SQL सर्वर विश्लेषण सेवाओं का उपयोग करते हुए कई-कई रिश्तों का OLAP क्यूब प्रसंस्करण।


सबसे पहले, मैं इस बारे में कैसे संपर्क करूं। अधिकारियों ने कहा कि मौजूदा डेटाबेस पर कुछ प्रकार के एनालिटिक्स को तैनात करना अच्छा होगा। Google की एक छोटी सी खोज करने के बाद, यह पता चला कि OLAP तकनीक सही है। और चूंकि MS SQL सर्वर कंपनी के सर्वर पर तैनात है, इसलिए विश्लेषण सेवाएँ घटक और भी बेहतर है।

अपने हाथों को खुशी से रगड़ते हुए, मैंने Microsoft ट्यूटोरियल को पकड़ा जो SQL सर्वर के साथ बंडल में आता है। और दो दिन बाद मुझे यकीन था कि मैं सब कुछ कर सकता हूं। लेकिन, यह यहाँ नहीं था ... मौजूदा डेटाबेस में, तालिकाओं के बीच के अधिकांश रिश्ते कई-से-कई रिश्ते बन गए, जो पहले किसी भी जटिलता को चित्रित नहीं करते थे। लेकिन व्यवहार में, यह पता चला है कि कोई भी व्यक्ति बहुत सार्थक हाथ लहराए बिना नहीं कर सकता, क्योंकि अन्यथा, घन केवल गलत जानकारी देता है।

RuNet में, इस विषय पर जानकारी प्राप्त करना आसान काम नहीं था। या तो यह हर किसी के लिए निश्चित रूप से एक मामला है, या स्की नहीं जाता है। हालाँकि, मुझे अभी भी इस विषय पर एक बहुत बड़ा अंग्रेजी मैनुअल मिला। दरअसल, जो लोग अंग्रेजी को पूरी तरह से समझते हैं या विषय को बहुत अच्छी तरह से समझना चाहते हैं उन्हें आगे पढ़ने के लिए नहीं, बल्कि लिंक का अनुसरण करने के लिए आमंत्रित किया जाता है: http://www.sqlbi.com/articles/many2many/

जो लोग, मेरे जैसे हैं, उनके पास अंग्रेजी पाठ्यपुस्तकें पढ़ने के लिए समय नहीं है, पर पढ़ें। पोस्ट इस नियमावली का अनुवाद नहीं है: बल्कि, इसके पहले उदाहरणों का एक निश्चित सारांश + जो Microsoft टेक्स्टबुक से कुछ मूल बातें हैं।

असल में समस्या क्या है। यदि पाठक इस पद से परिचित हो गया: http://habrahabr.ru/post/67272/ , तो वह जानता है कि ओलप के लिए मानक योजनाएं "स्टार" और "स्नोफ्लेक" योजनाएं हैं। लेकिन क्या होगा अगर हम कई-कई रिश्तों से घिरे थे?

सबसे आसान विकल्प विचारों का उपयोग करके कई-से-कई रिश्तों से दूर होना है - यह प्रसंस्करण अनुरोधों की गति को सकारात्मक रूप से प्रभावित करेगा। छोड़ने में असमर्थ? चलो ठीक है।

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



एक दूरगामी उदाहरण, लेकिन समस्या अभी भी दिखाई दे रही है: दो एम 2 एम कनेक्शन के माध्यम से भविष्य के आयाम को एक तथ्य तालिका से कैसे जोड़ा जाए? यह सरल है, हम एसएसएएस को बताएंगे कि कहां देखना है।
आयाम (प्रकार, दिनांक, श्रेणियाँ, व्यक्ति, खाते) बनाने के लिए प्रारंभिक चरणों का पालन करना (देखें http://habrahabr.ru/post/67272/ ), हम बिक्री माप (पंक्तियों की संख्या) पर एक घन बनाने की कोशिश कर रहे हैं। डिफ़ॉल्ट रूप से, विज़ुअल स्टूडियो हमें केवल तीन उपाय (प्रकार, लेखा, दिनांक) प्रदान करेगा - क्योंकि केवल वे सीधे हमारे माप से संबंधित हैं। क्यूब बनाने के बाद, अपने हाथों से शेष दो उपाय जोड़ें। प्लस, हम क्यूब के अंदर दो और सहायक उपाय बनाते हैं जो एम 2 एम कनेक्शन के प्रसंस्करण के लिए जिम्मेदार होंगे: ब्रिज अकाउंट्स पर्सन्स और ब्रिज पर्सन कैटेगरी (दोनों - पंक्तियों की संख्या जिसमें टेबल स्पष्ट हैं)।
इस प्रकार, हमारे पास निम्नलिखित चित्र होंगे:





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

इस गलतफहमी को दूर करने के लिए, हम एसएसएएस को दिखाएंगे जहां हमारे अनुरोधों को संसाधित करने के लिए जानकारी की तलाश करें। ऐसा करने के लिए, "माप का उपयोग करना" टैब पर उन ग्रे बॉक्स को भरें: ग्रे बॉक्स पर क्लिक करें-> ellipsis-> कनेक्शन का प्रकार "कई से कई" चुनें -> उपायों का एक मध्यवर्ती समूह चुनें, जैसा कि तस्वीर में लिखा गया है:



देखा! सब कुछ काम करता है। आप अगली तस्वीर देख सकते हैं:



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

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

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

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