🎇 ✍🏾 🙏🏻 संबंधपरक नेटवर्क डेटा मॉडल 🤛🏽 👩🏻‍🎓 📪

संबंधपरक मॉडल ने अपनी विशिष्टता खो दी है

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

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

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

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

SQL में कार्यान्वित रिलेशनल मॉडल की "सुंदरता" और कठोरता, 3 दशकों के लिए, प्रोग्रामर को प्रसन्न करती है। "पुराने" मॉडल: नेटवर्क या पदानुक्रमित लगभग भूल गए थे। हां, "लगभग अमर" IDMS [1] के संभावित अपवाद के साथ लगभग ऐसे सॉफ़्टवेयर उत्पाद नहीं हैं।

पिछले एक दशक में, वैकल्पिक डेटाबेस प्रबंधन प्रणाली (DBMS) बनाने के लिए सक्रिय कार्य चल रहा है, जिसे तथाकथित रूप से - NoSQL कहा जाता है। इस अवधारणा के तहत बहुत भिन्न प्रणालियाँ अब गिर जाती हैं जो एक दूसरे से बहुत भिन्न होती हैं। दिलचस्प है, "पुराने" नेटवर्क और पदानुक्रमित मॉडल NoSQL की अवधारणा में शामिल नहीं हैं! इस क्षेत्र में अच्छी समीक्षा [2,3,4] में मिल सकती है।

NoSQL श्रेणी में "ग्राफ़" डेटाबेस [5] शामिल हैं, जो कि कैनोनिकल नेटवर्क मॉडल CODASYL [6] के लगभग समीप हैं। जैसा कि नाम से ही स्पष्ट है, ऐसी प्रणालियाँ दो असंगठित समूह हैं - नोड्स (कोने) और किनारे (आर्क्स)। नेटवर्क डेटाबेस का मुख्य लाभ - नेविगेशन "निर्धारित" है , अनुरोध के प्रसंस्करण के समय नहीं है, जैसा कि आरडीबी में है, लेकिन नए डेटा को जोड़ने के समय (ग्राफ़ - कोने और किनारों के लिए), यह ग्राफ सिस्टम के लिए पूरी तरह से सच है। लेकिन CODASYL डेटाबेस के विपरीत, ग्राफ़ डेटाबेस को पॉप्युलेट होने से पहले संरचित नहीं किया जाता है।

अन्य सबसे लोकप्रिय NoSQL डेटाबेस कक्षाएं "कुंजी-मूल्य" (उदाहरण - रेडिस [7]) और "दस्तावेज़ संग्रहण" (उदाहरण - MongoDB [8]) हैं। चूंकि ऐसी प्रणालियों की विस्तृत समीक्षा इस लेख का उद्देश्य नहीं है, इसलिए केवल निम्नलिखित पर ध्यान देना महत्वपूर्ण है।

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

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

SQL के बिना रिलेशनल डेटाबेस

ऊपर वर्णित व्यावहारिक समस्याओं के अलावा, आरडीबी के उपयोग ने हाल ही में अन्य महत्वपूर्ण रुझानों को देखा है।

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

ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग (ओओपी) मानक बन गया है, लेकिन एसक्यूएल एक घोषणात्मक भाषा है जिसका व्याकरण सबसे आम ओओपी भाषाओं (सी ++, जावा, जावास्क्रिप्ट, पायथन) के साथ फिट नहीं है। परिणामस्वरूप, ORM (ऑब्जेक्ट-रिलेशनल मैपिंग - ऑब्जेक्ट-रिलेशनल मैपिंग (परिवर्तन) [9]) नामक वर्ग पुस्तकालयों के आधार पर RDBs (SQL प्रश्नों के साथ काम करना) को लोकप्रियता मिली है।

ORM कक्षाओं का उपयोग RDBs का उपयोग करते समय प्रोग्रामर को SQL के बिना करने की अनुमति देता है। ORM स्वचालित रूप से तालिकाओं को बनाने और डेटा में हेरफेर करने के लिए RDBs में SQL प्रश्न बनाता है। अधिकांश ORM में विभिन्न लोकप्रिय DBMS - SQLite, MySQL, PostgreSQL और अन्य के साथ इंटरफेस है, जो प्रोग्राम कोड को संशोधित किए बिना एक विकल्प देता है।

प्रत्येक प्रोग्रामिंग भाषा के लिए भी कई ORM कार्यान्वयन हैं। वे सभी समान हैं, इसलिए, निश्चित रूप से, भविष्य में, ओआरएम द्वारा हम पायथन भाषा [11] में Django ढांचे [10] के मॉडल वर्ग के मॉडल के संगत पुस्तकालय (पैकेज) का मतलब है।

ORM बहुत "सुविधाजनक" है और प्रोग्रामर वास्तव में यह नहीं सोचते हैं कि इस API का उपयोग करके उन्हें न केवल रिलेशनल मॉडल के फायदे मिलते हैं, बल्कि इसके सभी नुकसान भी हैं। उदाहरण के लिए, कोड में ही, आप तालिका मॉडल को ओवरराइड नहीं कर सकते हैं - एक कॉलम जोड़ें या निकालें, एक नई तालिका जोड़ें, आदि। डेटाबेस माइग्रेशन बनाने के लिए, आपको पहले कोड को फिर से लिखना होगा, फिर "एक मंजिल ऊंची उठो", और फिर प्रोग्राम को पुनरारंभ करें। नतीजतन, एक प्रोग्राम बनाना असंभव है जो प्रोग्राम के संचालन के दौरान डेटा योजना के लिए सबसे सरल परिवर्तन प्रदान करता है, कार्यक्रम को स्वयं बदले बिना।

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

जब कोई व्यक्ति SQL क्वेरी लिखता है, तो यह माना जाता है कि वह कंप्यूटिंग संसाधनों की लागत को सोचता है और समझता है। ORM इस कार्य को पूरा करता है।

नई पीढ़ी के डेटाबेस के रूप में हाइपरटेबल

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

मुख्य अवधारणा हाइपरटेबल है (GT) - यह एक डेटाबेस है जिसमें संबंधों (तालिकाओं) के एक सेट के रूप में उपयोग किया जाता है:

"संबंधपरक" विशेषताएँ (डेटा डोमेन), जिनमें से मान, RDB में हैं, फ़ील्ड तालिका फ़ील्ड के लिए स्व-परिभाषित डेटा के साथ फ़ील्ड फ़ील्ड हैं
"नेटवर्क" विशेषताएँ (लिंक डोमेन)। हम उन्हें एटीएस कहेंगे - टाइप "लिंक" की विशेषता

तालिका की पंक्तियों में PBX फ़ील्ड के मान हाइपरटेबल में शामिल किसी भी तालिका में किसी भी पंक्तियों के स्पष्ट संदर्भ हैं।

हमारे द्वारा शुरू की गई हाइपरटेबल की अवधारणा का परियोजना [13] से कोई लेना-देना नहीं है, जिसे 2016 में बंद कर दिया गया था।

एक कार्यशील प्रोटोटाइप है - पायथन में उपकरणों का एक सेट - HTMS (हाइपर टेबल मैनेजमेंट सिस्टम), जिसमें निम्न स्तर (ऊपर से नीचे) शामिल हैं:

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

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

भविष्य के लेखों में, पाठकों को अधिक विस्तार से HTMS प्रणाली से परिचित कराने की योजना है।

साहित्य

1. आईडीएमएस - en.wikipedia.org/wiki/IDMS
2. आधुनिक डेटाबेस के प्रकार / जॉन हैमिन्क - डेटाबेस जोन, मार्च। 09, 2018 - dzone.com/articles/the-types-of-modern-dat डेटाबेस
3. अनस्ट्रक्चर्ड डेटाबेस (NoSQL) / एंड्री वोल्कोव - ओरेकल पैच, नोव। 14, 2018 - oracle-patches.com/db/nosql/3739
4. क्या रिलेशनल डेटाबेस बर्बाद होते हैं? (अंग्रेजी से अनुवादित) / टोनी बैन - habr.com/en/post/103021/
5. ग्राफ डेटाबेस / आइडा - ओरेकल पैच, अक्टूबर .22, 18 - oracle-patches.com/db/3680- ग्राफ - डेटाबेस
6. CODASYL - en.wikipedia.org/wiki/CODASYL
7. रेडिस - redis.io
8. MongoDB - www.mongodb.com
9. ओडीसियस / डीएफएस: बिग डेटा / जून-सुंग किम और अन्य के हस्तांतरण प्रसंस्करण के लिए डीबीएमएस और वितरित फाइल सिस्टम का एकीकरण - सूचना विज्ञान और प्रौद्योगिकी महाविद्यालय, ड्रेक्सल विश्वविद्यालय, फिलाडेल्फिया, यूएसए, 2014
10. वस्तु-संबंधपरक मानचित्रण - en.wikipedia.org/wiki/Object-relational_mapping
11. Django सॉफ्टवेयर फाउंडेशन - www.djangoproject.com
12. पायथन सॉफ्टवेयर फाउंडेशन - www.python.org
13. हाइपरटेबल - www.hypertable.com

संबंधपरक नेटवर्क डेटा मॉडल

संबंधपरक मॉडल ने अपनी विशिष्टता खो दी है

SQL के बिना रिलेशनल डेटाबेस

नई पीढ़ी के डेटाबेस के रूप में हाइपरटेबल

More articles: