कई सार परतों के साथ डेटाबेस डिजाइन करने में मेटामोडेल का उपयोग (भाग 2)

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

पहला भाग: http://habrahabr.ru/blogs/sql/119317/

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

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

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

मैंने एप्लिकेशन एप्लिकेशन विकसित करते समय आवश्यक अधिकांश मॉडलिंग मॉडलिंग घटकों को इकट्ठा करने की कोशिश की। पहले भाग के अंत में एक आरेख था:



अब मैं इसे और अधिक विस्तार से समझाऊंगा। आरेख की निचली रेखा पर, रिलेशनल डेटा में घटकों को सफेद रंग में चिह्नित किया जाता है, और आरडीबीएमएस में प्लेसमेंट के लिए अपघटन या मेटा-विवरण की आवश्यकता वाले घटकों को ग्रे में चिह्नित किया जाता है। आइए उन पर अधिक विस्तार से विचार करें:

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

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

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

विशेषताएँ और समूह प्रकार
उपरोक्त समूहों में से प्रत्येक की अपनी विशेषताएं और प्रकार हो सकते हैं, यह काफी स्वाभाविक लगता है। और विभिन्न समूहों के लिए कार्यान्वयन के कई उदाहरण और साधन हैं।

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

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

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

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

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

आपका ध्यान देने के लिए धन्यवाद।