Rules for
designing good tables(Codd's Rule for
Relational DBMS)
E.F Codd एक कंप्यूटर वैज्ञानिक थे जिन्होंने डेटाबेस
प्रबंधन के लिए रिलेशनल मॉडल का आविष्कार किया था। रिलेशनल मॉडल के आधार पर, रिलेशनल डेटाबेस
बनाया गया था। कोडड ने अपने रिलेशनल मॉडल के खिलाफ DBMS की अवधारणा का परीक्षण
करने के लिए 13 नियमों को लोकप्रिय रूप से Codd के 12 नियमों के रूप में
जाना जाता है। कोडेड का नियम वास्तविक रूप से परिभाषित करता है कि संबंधपरक
डेटाबेस प्रबंधन प्रणाली (RDBMS) बनने के लिए DBMS को किस गुणवत्ता की
आवश्यकता होती है। अब तक, शायद ही कोई व्यावसायिक उत्पाद है जो सभी 13
कोडड के नियमों का पालन करता है। यहां तक कि ओरेकल भी 13. में से केवल साढ़े आठ
(8.5) को फॉलो करता है। कोडेक के 12 नियम इस प्रकार हैं।
Rule zero(नियम शून्य)
यह नियम बताता है कि एक सिस्टम के लिए RDBMS के रूप में अर्हता प्राप्त करने के लिए, यह पूरी तरह से रिलेशनल क्षमताओं के माध्यम से डेटाबेस का प्रबंधन करने में सक्षम होना चाहिए।
Rule 1: Information rule
सभी जानकारी (मेटाडेटा सहित) को तालिकाओं की कोशिकाओं में संग्रहीत डेटा के रूप में दर्शाया जाना है। पंक्तियों और स्तंभों को कड़ाई से अनियंत्रित करना पड़ता है।
Rule 2: Guaranted Access
डेटा का प्रत्येक अद्वितीय टुकड़ा (परमाणु मूल्य) इसके द्वारा होना चाहिए: तालिका का नाम + प्राथमिक कुंजी (पंक्ति) + विशेषता (स्तंभ)।
नोट: POINTER के माध्यम से सीधे पहुंच की क्षमता इस नियम का उल्लंघन है।
Rule 3: Systematic treatment of NULL
नल के कई अर्थ हैं, इसका मतलब लापता डेटा हो सकता है, लागू नहीं या कोई मूल्य नहीं। इसे लगातार संभाला जाना चाहिए। इसके अलावा, प्राथमिक कुंजी कभी भी अशक्त नहीं होनी चाहिए। NULL पर अभिव्यक्ति शून्य देना चाहिए।
Rule 4: Active Online Catalog
डेटाबेस शब्दकोश (कैटलॉग) पूर्ण डेटाबेस का संरचना विवरण है और इसे ऑनलाइन संग्रहीत किया जाना चाहिए। कैटलॉग को बाकी डेटाबेस के समान नियमों द्वारा शासित होना चाहिए। कैटलॉग पर उसी क्वेरी भाषा का उपयोग किया जाना चाहिए जैसा कि क्वेरी डेटाबेस में किया जाता है।
Rule 5: Powerful and Well-Structured Language
डेटाबेस में संग्रहीत डेटा तक पहुंच के सभी शिष्टाचार प्रदान करने के लिए एक अच्छी तरह से संरचित भाषा होनी चाहिए। उदाहरण: SQL, आदि। यदि डेटाबेस इस भाषा के उपयोग के बिना डेटा तक पहुंच की अनुमति देता है, तो यह एक उल्लंघन है।
Rule 6: View Updation Rule
सभी दृश्य जो सैद्धांतिक रूप से अद्यतन करने योग्य हैं, उन्हें सिस्टम द्वारा भी अद्यतन किया जाना चाहिए।
Rule 7: Relational Level Operation
प्रत्येक स्तर पर संबंधों को सम्मिलित करना, हटाना, अद्यतन करना होगा। यूनियन, इंटरसेक्शन और माइनस जैसे सेट ऑपरेशन का भी समर्थन किया जाना चाहिए।
Rule 8: Physical Data Independence
डेटा का भौतिक भंडारण प्रणाली के लिए कोई मायने नहीं रखता। यदि कहा जाए, तो कुछ फाइल सपोर्टिंग टेबल का नाम बदला गया है या एक डिस्क से दूसरे में ले जाया गया है, यह एप्लिकेशन को प्रभावित नहीं करना चाहिए।
Rule 9: Logical Data Independence
यदि डेटाबेस के लॉजिकल स्ट्रक्चर (टेबल स्ट्रक्चर्स) में बदलाव होता है, तो डेटा का यूजर व्यू नहीं बदलना चाहिए। कहते हैं, यदि एक तालिका को दो तालिकाओं में विभाजित किया जाता है, तो एक नए दृश्य को दो तालिकाओं के जुड़ने के परिणामस्वरूप परिणाम देना चाहिए। इस नियम को संतुष्ट करना सबसे कठिन है।
Rule 10: Integrity Independence
डेटाबेस को अन्य कार्यक्रमों का उपयोग करने के बजाय अपनी स्वयं की अखंडता को लागू करने में सक्षम होना चाहिए। कुंजी और चेक बाधाओं, ट्रिगर आदि, डेटा शब्दकोश में संग्रहीत किया जाना चाहिए। यह RDBMS को फ्रंट-एंड से स्वतंत्र बनाता है।
Rule 11: Distribution Independence
एक डेटाबेस को नेटवर्क में इसके वितरण की परवाह किए बिना ठीक से काम करना चाहिए। भले ही एक डेटाबेस भौगोलिक रूप से वितरित किया जाता है, टुकड़ों में संग्रहीत डेटा के साथ, अंतिम उपयोगकर्ता को यह धारणा मिलनी चाहिए कि यह उसी स्थान पर संग्रहीत है। यह वितरित डेटाबेस की नींव देता है।
Rule 12: Nonsubversion Rule
यदि किसी सिस्टम में निम्न स्तर की पहुंच की अनुमति दी जाती है तो उसे डेटा को बदलने के लिए अखंडता नियमों को हटाने या बायपास करने में सक्षम नहीं होना चाहिए। यह किसी प्रकार की खोज या एन्क्रिप्शन द्वारा प्राप्त किया जा सकता है।
No comments:
Post a Comment
Please Do Not Enter Any Spam Link in the comment Box.