एजाइल डीडब्ल्यूएच डिजाइन पद्धतियों का अवलोकन

भंडारण सुविधा विकसित करना एक लंबा और गंभीर कार्य है।

किसी परियोजना के जीवन में बहुत कुछ इस बात पर निर्भर करता है कि शुरुआत में ऑब्जेक्ट मॉडल और आधार संरचना के बारे में कितनी अच्छी तरह सोचा गया है।

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

दूसरी ओर, सामान्य रूप से व्यवसाय और विशेष रूप से ग्राहकों की आवश्यकताएं तेजी से बदलती हैं, और डेटा "गहराई" और "व्यापकता" दोनों में बढ़ता है। और यहीं पर किसी तारे का मुख्य नुकसान प्रकट होता है - सीमित लचीलापन.

और यदि एक DWH डेवलपर के रूप में आपके शांत और आरामदायक जीवन में अचानक:

• कार्य उत्पन्न हुआ "कम से कम कुछ जल्दी करो, और फिर हम देखेंगे";
• एक तेजी से विकसित होने वाली परियोजना सामने आई, जिसमें नए स्रोतों को जोड़ा गया और सप्ताह में कम से कम एक बार बिजनेस मॉडल को फिर से तैयार किया गया;
• एक ग्राहक सामने आया है जिसे यह पता नहीं है कि सिस्टम कैसा दिखना चाहिए और अंततः उसे कौन से कार्य करने चाहिए, लेकिन वह प्रयोग करने के लिए तैयार है और लगातार इसके करीब पहुंचते हुए वांछित परिणाम को परिष्कृत करता है;
• प्रोजेक्ट मैनेजर खुशखबरी लेकर आया: "और अब हम चुस्त हैं!"

या यदि आप यह जानने में रुचि रखते हैं कि आप भंडारण सुविधाएं कैसे बना सकते हैं - तो कटौती में आपका स्वागत है!

"लचीलापन" का क्या मतलब है?

सबसे पहले, आइए परिभाषित करें कि "लचीला" कहलाने के लिए किसी सिस्टम में कौन से गुण होने चाहिए।

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

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

तो, लचीले भंडारण में क्या क्षमताएं होनी चाहिए? यहां तीन बिंदु हैं:

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

और हाँ, इन सभी आवश्यकताओं को एक ही प्रणाली में पूरा करना संभव है (बेशक, कुछ मामलों में और कुछ आपत्तियों के साथ)।

नीचे मैं डेटा वेयरहाउस के लिए दो सबसे लोकप्रिय त्वरित डिजाइन पद्धतियों पर विचार करूंगा - एंकर मॉडल и डेटा वॉल्ट. उदाहरण के लिए, EAV, 6NF (अपने शुद्ध रूप में) और NoSQL समाधानों से जुड़ी हर चीज़ जैसी उत्कृष्ट तकनीकों को कोष्ठक से बाहर रखा गया है - इसलिए नहीं कि वे किसी तरह बदतर हैं, और इसलिए भी नहीं कि इस मामले में लेख अधिग्रहण की धमकी देगा औसत शोधन की मात्रा. यह सिर्फ इतना है कि यह सब थोड़े अलग वर्ग के समाधानों से संबंधित है - या तो उन तकनीकों से जिन्हें आप विशिष्ट मामलों में उपयोग कर सकते हैं, चाहे आपके प्रोजेक्ट की समग्र वास्तुकला (जैसे ईएवी) कुछ भी हो, या विश्व स्तर पर अन्य सूचना भंडारण प्रतिमान (जैसे ग्राफ़ डेटाबेस) और अन्य विकल्प NoSQL).

"शास्त्रीय" दृष्टिकोण की समस्याएं और लचीली पद्धतियों में उनके समाधान

"शास्त्रीय" दृष्टिकोण से मेरा तात्पर्य अच्छे पुराने सितारे से है (अंतर्निहित परतों के विशिष्ट कार्यान्वयन की परवाह किए बिना, किमबॉल, इनमोन और सीडीएम के अनुयायी मुझे माफ कर दें)।

1. कनेक्शन की कठोर कार्डिनैलिटी

यह मॉडल डेटा के स्पष्ट विभाजन पर आधारित है आयाम и तथ्य. और यह, लानत है, तार्किक है - आखिरकार, अधिकांश मामलों में डेटा विश्लेषण कुछ वर्गों (आयामों) में कुछ संख्यात्मक संकेतकों (तथ्यों) के विश्लेषण के लिए आता है।

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

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

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

और कुछ समय बाद, सहकर्मियों ने एक नई मार्केटिंग रणनीति पेश की जिसमें वे एक ही पद पर कार्य कर सकते हैं एक ही समय में कई प्रमोशन. और अब आपको संबंध को एक अलग ऑब्जेक्ट में अलग करके तालिकाओं को संशोधित करने की आवश्यकता है।

(सभी व्युत्पन्न ऑब्जेक्ट जिनमें प्रमोशन चेक जुड़ा हुआ है, उन्हें भी अब सुधारने की आवश्यकता है)।

डेटा वॉल्ट और एंकर मॉडल में संबंध

इस स्थिति से बचना काफी सरल हो गया: ऐसा करने के लिए आपको बिक्री विभाग पर भरोसा करने की ज़रूरत नहीं है। सभी कनेक्शन प्रारंभ में अलग-अलग तालिकाओं में संग्रहीत किए जाते हैं और इसे अनेक-से-अनेक के रूप में संसाधित करें।

यह दृष्टिकोण प्रस्तावित किया गया था डैन लिनस्टेड प्रतिमान के भाग के रूप में डेटा वॉल्ट और पूरा समर्थन किया लार्स रॉनबैक в एंकर मॉडल.

परिणामस्वरूप, हमें लचीली कार्यप्रणाली की पहली विशिष्ट विशेषता मिलती है:

वस्तुओं के बीच संबंध मूल संस्थाओं की विशेषताओं में संग्रहीत नहीं होते हैं, बल्कि एक अलग प्रकार की वस्तु होते हैं।

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

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

2. डेटा दोहराव

लचीली वास्तुकला द्वारा हल की गई दूसरी समस्या कम स्पष्ट है और पहली जगह में अंतर्निहित है। SCD2 प्रकार माप (दूसरे प्रकार के धीरे-धीरे बदलते आयाम), हालाँकि केवल वे ही नहीं।

एक क्लासिक वेयरहाउस में, एक आयाम आम तौर पर एक तालिका होती है जिसमें एक सरोगेट कुंजी (पीके के रूप में) और अलग-अलग कॉलम में व्यावसायिक कुंजी और विशेषताओं का एक सेट होता है।

यदि कोई आयाम संस्करणीकरण का समर्थन करता है, तो संस्करण वैधता सीमाएं फ़ील्ड के मानक सेट में जोड़ दी जाती हैं, और स्रोत में एक पंक्ति के लिए रिपॉजिटरी में कई संस्करण दिखाई देते हैं (संस्करणित विशेषताओं में प्रत्येक परिवर्तन के लिए एक)।

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

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

आमतौर पर इसका परिणाम यह होता है एक ही जानकारी कई स्थानों पर एक साथ संग्रहीत होती है. उदाहरण के लिए, निवास के क्षेत्र और ग्राहक की श्रेणी के बारे में जानकारी एक साथ "ग्राहक" आयाम और "खरीद", "डिलीवरी" और "कॉल सेंटर कॉल" तथ्यों के साथ-साथ "ग्राहक - ग्राहक प्रबंधक" में संग्रहीत की जा सकती है। "लिंक तालिका.

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

3. पुनर्कार्य की अरेखीय जटिलता

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

यदि उपरोक्त शायद ही संशोधित ईटीएल प्रक्रियाओं वाले सिस्टम का वर्णन करता है, तो आप ऐसे प्रतिमान में रह सकते हैं - आपको बस यह सुनिश्चित करने की आवश्यकता है कि सभी संबंधित वस्तुओं में नए संशोधन सही ढंग से किए गए हैं। यदि संशोधन बार-बार होते हैं, तो गलती से कई कनेक्शनों के "लापता" होने की संभावना काफी बढ़ जाती है।

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

डेटा वॉल्ट और एंकर मॉडल में वस्तुओं और विशेषताओं को संग्रहीत करना

लचीले आर्किटेक्चर के लेखकों द्वारा प्रस्तावित दृष्टिकोण को निम्नानुसार तैयार किया जा सकता है:

जो बदलता है, उसे जो वैसा ही रहता है, उसे अलग करना जरूरी है। अर्थात्, कुंजियों को विशेषताओं से अलग संग्रहीत करें।

हालाँकि, किसी को भ्रमित नहीं होना चाहिए संस्करणित नहीं विशेषता के साथ अपरिवर्तित: पहला अपने परिवर्तनों का इतिहास संग्रहीत नहीं करता है, लेकिन बदल सकता है (उदाहरण के लिए, इनपुट त्रुटि को ठीक करते समय या नया डेटा प्राप्त करते समय); दूसरा कभी नहीं बदलता है।

डेटा वॉल्ट और एंकर मॉडल में वास्तव में क्या अपरिवर्तनीय माना जा सकता है, इस पर दृष्टिकोण भिन्न हैं।

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

प्रतिमान में एंकर मॉडल अपरिवर्तित माना जाता है केवल सरोगेट कुंजी सार। बाकी सब कुछ (प्राकृतिक कुंजियों सहित) इसकी विशेषताओं का एक विशेष मामला मात्र है। जिसमें सभी विशेषताएँ डिफ़ॉल्ट रूप से एक दूसरे से स्वतंत्र हैं, इसलिए प्रत्येक विशेषता के लिए a अलग टेबल.

В डेटा वॉल्ट इकाई कुंजियाँ वाली तालिकाएँ कहलाती हैं हुबामी. हब में हमेशा फ़ील्ड का एक निश्चित सेट होता है:

• प्राकृतिक इकाई कुंजियाँ
• सरोगेट कुंजी
• स्रोत से लिंक करें
• जोड़ने का समय रिकॉर्ड करें

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

अन्य सभी इकाई विशेषताएँ नामक विशेष तालिकाओं में संग्रहीत की जाती हैं उपग्रहों. एक हब में विभिन्न विशेषताओं के सेट संग्रहीत करने वाले कई उपग्रह हो सकते हैं।

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

साथ ही, डेटा लोडिंग प्रक्रिया को अनुकूलित करने के लिए, विभिन्न स्रोतों से प्राप्त विशेषताओं को अक्सर व्यक्तिगत उपग्रहों में शामिल किया जाता है।

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

В एंकर मॉडल कुंजियाँ संग्रहीत करने वाली तालिकाएँ कहलाती हैं एंकर. और वे रखते हैं:

• केवल सरोगेट कुंजियाँ
• स्रोत से लिंक करें
• जोड़ने का समय रिकॉर्ड करें

एंकर मॉडल के दृष्टिकोण से प्राकृतिक कुंजियों पर विचार किया जाता है सामान्य गुण. यह विकल्प समझने में अधिक कठिन लग सकता है, लेकिन यह वस्तु को पहचानने के लिए अधिक गुंजाइश देता है।

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

लेकिन यहां एक कपटपूर्ण बिंदु है: यदि विभिन्न प्रणालियों की विशेषताओं को एक इकाई में संयोजित किया जाता है, तो सबसे अधिक संभावना है कि उनमें से कुछ हैं "चिपकाने" के नियम, जिससे सिस्टम को यह समझना चाहिए कि विभिन्न स्रोतों के रिकॉर्ड इकाई के एक उदाहरण से मेल खाते हैं।

В डेटा वॉल्ट ये नियम संभवतः गठन का निर्धारण करेंगे मास्टर इकाई का "सरोगेट हब"। और किसी भी तरह से प्राकृतिक स्रोत कुंजियों और उनकी मूल विशेषताओं को संग्रहीत करने वाले हब को प्रभावित नहीं करता है। यदि किसी बिंदु पर विलय नियम बदलते हैं (या जिन विशेषताओं के द्वारा इसे निष्पादित किया जाता है उन्हें अद्यतन किया जाता है), तो यह सरोगेट हब को दोबारा स्वरूपित करने के लिए पर्याप्त होगा।

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

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

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

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

डेटा वॉल्ट और एंकर मॉडल के बीच एक और महत्वपूर्ण अंतर उपलब्धता है कनेक्शन के गुण:

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

तथ्य भंडारण

इससे पहले, हमने मुख्य रूप से माप मॉडलिंग के बारे में बात की थी। तथ्य थोड़े कम स्पष्ट हैं.

В डेटा वॉल्ट तथ्यों को संग्रहीत करने के लिए एक विशिष्ट वस्तु है जोड़ना, जिनके उपग्रहों में वास्तविक संकेतक जोड़े जाते हैं।

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

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

तदनुसार, एंकर मॉडल में एक तथ्य कुंजी का विस्तार करते समय मॉड्यूलरिटी के साथ समस्याएं उत्पन्न नहीं होती हैं (यह केवल संबंधित एंकर के लिए एक नया संबंध जोड़ने के लिए पर्याप्त है), लेकिन तथ्यों को प्रदर्शित करने के लिए एक मॉडल को डिजाइन करना कम स्पष्ट है; "कृत्रिम" एंकर दिखाई दे सकते हैं जो व्यवसाय वस्तु मॉडल को अस्पष्ट तरीके से प्रदर्शित करता है।

लचीलापन कैसे प्राप्त किया जाता है

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

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

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

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

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

अंधेरा पक्ष

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

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

ऐसे कई तथ्य हैं जो इस स्थिति को आसान बनाते हैं:

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

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

उदाहरण के लिए, यहाँ यह लेख में एक तालिका के नमूने के साथ एंकर मॉडल के प्रदर्शन का विस्तृत तुलनात्मक परीक्षण शामिल है।

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

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

कुल मिलाकर

विचारित लचीले आर्किटेक्चर का मुख्य सार उनके "डिज़ाइन" की मॉड्यूलरिटी है।

यह वह संपत्ति है जो अनुमति देती है:

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

इस लचीलेपन की कीमत है उत्पादकता. इसका मतलब यह नहीं है कि ऐसे मॉडलों पर स्वीकार्य प्रदर्शन हासिल करना असंभव है। अक्सर, आपको अपने इच्छित मेट्रिक्स प्राप्त करने के लिए अधिक प्रयास और विवरण पर ध्यान देने की आवश्यकता हो सकती है।

क्षुधा

इकाई प्रकार डेटा वॉल्ट

डेटा वॉल्ट के बारे में अधिक जानकारी:
डैन लिस्टैड की वेबसाइट
रूसी में डेटा वॉल्ट के बारे में सब कुछ
हैबे पर डेटा वॉल्ट के बारे में

इकाई प्रकार एंकर मॉडल

एंकर मॉडल के बारे में अधिक जानकारी:

एंकर मॉडल के रचनाकारों की वेबसाइट
एविटो में एंकर मॉडल को लागू करने के अनुभव के बारे में लेख

विचारित दृष्टिकोणों की सामान्य विशेषताओं और अंतरों के साथ सारांश तालिका:

स्रोत: www.habr.com