Integrity Rules and
Constraints
एक संबंधपरक मॉडल
में बाधाएं एक बहुत महत्वपूर्ण विशेषता हैं। वास्तव में, संबंधपरक मॉडल विशेषताओं या तालिकाओं पर बाधाओं के अच्छी
तरह से परिभाषित सिद्धांत का समर्थन करता है। बाधाएं उपयोगी हैं क्योंकि वे एक
डिजाइनर को डेटाबेस में डेटा के शब्दार्थ को निर्दिष्ट करने की अनुमति देते हैं।
बाधाएं वे नियम हैं जो DBMSs को यह जांचने के
लिए मजबूर करते हैं कि डेटा शब्दार्थ को संतुष्ट करता है।
डोमेन अखंडता
डोमेन संबंध में
विशेषताओं के मूल्यों को प्रतिबंधित करता है और रिलेशनल मॉडल का एक बाधा है।
हालाँकि, डेटा के लिए वास्तविक
दुनिया शब्दार्थ हैं जो केवल डोमेन बाधाओं के साथ उपयोग किए जाने पर निर्दिष्ट
नहीं किए जा सकते हैं। हमें यह बताने के लिए अधिक विशिष्ट तरीकों की आवश्यकता है
कि डेटा मान क्या हैं या अनुमति नहीं है और कौन सा प्रारूप किसी विशेषता के लिए
उपयुक्त है। उदाहरण के लिए, कर्मचारी आईडी
(ईआईडी) अद्वितीय होनी चाहिए या कर्मचारी जन्मतिथि [जन 1, 1950, 1 जनवरी, 2000] श्रेणी में है। इस तरह की जानकारी
तार्किक बयानों में प्रदान की जाती है जिसे अखंडता बाधा कहा जाता है।
नीचे वर्णित कई
प्रकार की अखंडता बाधाएं हैं।
1 समग्र अखंडता
इकाई अखंडता
सुनिश्चित करने के लिए, यह आवश्यक है कि प्रत्येक तालिका में एक
प्राथमिक कुंजी हो। न तो पीके और न ही इसके किसी भी हिस्से में अशक्त मूल्य हो
सकते हैं। ऐसा इसलिए है क्योंकि प्राथमिक कुंजी के लिए शून्य मान का अर्थ है कि हम
कुछ पंक्तियों की पहचान नहीं कर सकते हैं। उदाहरण के लिए, EMPLOYEE तालिका में, फोन एक प्राथमिक कुंजी नहीं हो सकता है क्योंकि कुछ लोगों
के पास टेलीफोन नहीं हो सकता है।
2 निर्देशात्मक
अखंडता
संदर्भात्मक
अखंडता के लिए आवश्यक है कि एक विदेशी कुंजी में एक मिलान प्राथमिक कुंजी होनी
चाहिए या यह अशक्त होनी चाहिए। यह बाधा दो तालिकाओं (माता-पिता और बच्चे) के बीच
निर्दिष्ट है; यह इन तालिकाओं में पंक्तियों के बीच पत्राचार को बनाए रखता
है। इसका मतलब है कि एक पंक्ति में एक तालिका से दूसरी तालिका में संदर्भ मान्य
होना चाहिए।
कंपनी के ग्राहक
/ आदेश डेटाबेस में संदर्भात्मक अखंडता बाधा के उदाहरण:
ग्राहक (CustID, CustName)
ऑर्डर (ऑर्डरआईडी, कस्टिड, ऑर्डरडेट)
यह सुनिश्चित
करने के लिए कि कोई अनाथ रिकॉर्ड नहीं हैं, हमें संदर्भात्मक अखंडता
को लागू करने की आवश्यकता है। एक अनाथ रिकॉर्ड वह है जिसका विदेशी कुंजी एफके
मूल्य संबंधित इकाई में नहीं मिलता है - वह इकाई जहां पीके स्थित है। याद रखें कि
एक सामान्य जोड़ एक PK और FK के बीच है।
संदर्भात्मक
अखंडता में कहा गया है कि ऑर्डर तालिका में ग्राहक आईडी (CustID) ग्राहक तालिका में एक वैध CustID से मेल खाना चाहिए। अधिकांश संबंधपरक डेटाबेस
में घोषणात्मक संदर्भात्मक अखंडता होती है। दूसरे शब्दों में, जब तालिकाओं का
निर्माण किया जाता है तो संदर्भात्मक अखंडता बाधाएं खड़ी हो जाती हैं।
यहाँ एक कोर्स /
कक्षा डेटाबेस से एक और उदाहरण दिया गया है:
कोर्स (CrCCode, DeptCode, विवरण)
कक्षा (CrsCode, अनुभाग, ClassTime)
संदर्भात्मक
अखंडता में कहा गया है कि क्लास टेबल में CrsCode को कोर्स टेबल
में एक वैध CrsCode से मेल खाना चाहिए। इस स्थिति में, यह पर्याप्त नहीं
है कि क्लास टेबल में CrCCode और सेक्शन पीके बनाते हैं, हमें रेफ़रिंग
अखंडता को भी लागू करना चाहिए।
संदर्भात्मक
अखंडता की स्थापना करते समय यह महत्वपूर्ण है कि पीके और एफके एक ही डेटा प्रकार
हैं और एक ही डोमेन से आते हैं, अन्यथा रिलेशनल डेटाबेस मैनेजमेंट सिस्टम
(आरडीबीएमएस) शामिल होने की अनुमति नहीं देगा। RDBMS एक लोकप्रिय डेटाबेस
प्रणाली है जो IBM के सैन जोस रिसर्च लेबोरेटरी के ई। एफ। कोडड
द्वारा शुरू किए गए संबंधपरक मॉडल पर आधारित है। अन्य डेटाबेस सिस्टम की तुलना में
रिलेशनल डेटाबेस सिस्टम का उपयोग करना और समझना आसान है।
Microsoft Access में प्रासंगिक अखंडता
Microsoft (MS) एक्सेस में, ऑर्डर तालिका में CustID में ग्राहक तालिका में PK को शामिल करके संदर्भात्मक अखंडता स्थापित की
जाती है। एमएस एक्सेस में एडिट रिलेशनशिप स्क्रीन पर यह देखने के लिए चित्र 9.1
देखें।
Transact-SQL (MS SQL
Server) का उपयोग करके प्रासंगिक
अखंडता
Transact-SQL का उपयोग करते समय, एफके के साथ
ऑर्डर टेबल बनाते समय संदर्भात्मक अखंडता सेट की जाती है। नीचे सूचीबद्ध विवरण
ग्राहक तालिका में पीके को संदर्भित आदेश तालिका में एफके दिखा रहे हैं।
CREATE TABLE Customer
( CustID INTEGER PRIMARY KEY,
CustName CHAR(35) )
( CustID INTEGER PRIMARY KEY,
CustName CHAR(35) )
CREATE TABLE Orders
( OrderID INTEGER PRIMARY KEY,
CustID INTEGER REFERENCES Customer(CustID),
OrderDate DATETIME )
( OrderID INTEGER PRIMARY KEY,
CustID INTEGER REFERENCES Customer(CustID),
OrderDate DATETIME )
विदेशी प्रमुख
नियम
संदर्भात्मक
अखंडता की स्थापना करते समय अतिरिक्त विदेशी प्रमुख नियमों को जोड़ा जा सकता है, जैसे कि चाइल्ड
रो के साथ क्या करना है (आदेश तालिका में), जब पीके, माता-पिता
(ग्राहक) के हिस्से के साथ रिकॉर्ड हटा दिया जाता है या बदल दिया जाता है
(अद्यतन)। उदाहरण के लिए, MS Access में रिलेशनशिप विंडो को एडिट करें (चित्र 9.1
देखें) एफके नियमों के लिए दो अतिरिक्त विकल्प दिखाता है: कैस्केड अपडेट और
कैस्केड डिलीट। यदि ये चयनित नहीं हैं,
तो सिस्टम चाइल्ड रिकॉर्ड
मौजूद होने पर पैरेंट टेबल (कस्टमर टेबल) में पीके मानों को हटाने या अपडेट को रोक
देगा। चाइल्ड रिकॉर्ड मैचिंग पीके के साथ कोई भी रिकॉर्ड है।
कुछ डेटाबेस में, Set to Null नामक डिलीट विकल्प का चयन करते समय एक अतिरिक्त विकल्प
मौजूद होता है। इसमें चुना गया है, PK पंक्ति हटा दी गई है, लेकिन चाइल्ड
टेबल में FK NULL पर सेट है। हालांकि यह एक अनाथ पंक्ति बनाता है, यह स्वीकार्य है।
उद्यम की कमी
एंटरप्राइज
बाधाएं - कभी-कभी सिमेंटिक बाधाओं के रूप में संदर्भित - उपयोगकर्ता या डेटाबेस
प्रशासकों द्वारा निर्दिष्ट अतिरिक्त नियम हैं और कई तालिकाओं पर आधारित हो सकते
हैं।
यहाँ कुछ उदाहरण
हैं।
एक कक्षा में
अधिकतम 30 छात्र हो सकते हैं।
एक शिक्षक प्रति सेमेस्टर
में अधिकतम चार कक्षाएं सिखा सकता है।
एक कर्मचारी पांच
से अधिक परियोजनाओं में भाग नहीं ले सकता है।
किसी कर्मचारी का
वेतन कर्मचारी के प्रबंधक के वेतन से अधिक नहीं हो सकता है।
व्यापार नियम
आवश्यकताओं को
इकट्ठा करते समय उपयोगकर्ताओं से व्यावसायिक नियम प्राप्त किए जाते हैं।
आवश्यकताओं को इकट्ठा करने की प्रक्रिया बहुत महत्वपूर्ण है, और इसके परिणामों
को उपयोगकर्ता द्वारा सत्यापित किया जाना चाहिए ताकि डेटाबेस डिज़ाइन का निर्माण
किया जा सके। यदि व्यावसायिक नियम गलत हैं, तो डिजाइन गलत होगा, और अंततः निर्मित
एप्लिकेशन उपयोगकर्ताओं द्वारा अपेक्षित रूप से कार्य नहीं करेगा।
व्यापार नियमों
के कुछ उदाहरण हैं:
एक शिक्षक कई
छात्रों को पढ़ा सकता है।
एक कक्षा में
अधिकतम 35 छात्र हो सकते हैं।
एक कोर्स कई बार
पढ़ाया जा सकता है, लेकिन केवल एक प्रशिक्षक द्वारा।
सभी शिक्षक
कक्षाएं नहीं पढ़ाते हैं।
कार्डिनलिटी और
कनेक्टिविटी
कार्डिनैलिटी और
कनेक्टिविटी को निर्धारित करने के लिए व्यावसायिक नियमों का उपयोग किया जाता है।
कार्डिनैलिटी संबंधित इकाई की एक घटना के साथ जुड़ी न्यूनतम और अधिकतम संख्या में
होने वाली घटनाओं को व्यक्त करके दो डेटा तालिकाओं के बीच संबंध का वर्णन करता है।
चित्र 9.2 में, आप देख सकते हैं कि रिश्ते के प्रतीक पर कार्डिनैलिटी को
अंतरतम चिह्नों द्वारा दर्शाया गया है। इस आकृति में, दाईं ओर
कार्डिनिटी 0 (शून्य) और बाईं ओर 1 (एक) है।
दूसरी तरफ, रिश्ते के प्रतीक
का सबसे बाहरी प्रतीक, दो तालिकाओं के बीच कनेक्टिविटी का
प्रतिनिधित्व करता है। कनेक्टिविटी दो तालिकाओं के बीच का संबंध है, उदाहरण के लिए, एक से एक या एक
से कई। केवल समय शून्य है जब FK शून्य हो सकता है। जब भागीदारी की बात आती है, तो इन संस्थाओं
के बीच संबंधों के तीन विकल्प हैं: या तो 0 (शून्य), 1 (एक) या कई। उदाहरण के
लिए, चित्र 9.2 में, इस रेखा के बाहरी, बाएँ हाथ की तरफ
1 और एक, बाहरी, दाएँ हाथ की तरफ कनेक्टिविटी 1 है।
चित्र 9.3। वह
प्रतीक दिखाता है जो एक से कई संबंधों का प्रतिनिधित्व करता है।
चित्र 9.4 में, दोनों आंतरिक
(कार्डिनैलिटी का प्रतिनिधित्व करते हैं) और बाहरी (कनेक्टिविटी का प्रतिनिधित्व
करते हैं) मार्कर दिखाए जाते हैं। इस प्रतीक के बाईं ओर को न्यूनतम 1 और अधिकतम 1
के रूप में पढ़ा जाता है। दाईं ओर, इसे निम्न के रूप में पढ़ा जाता है: न्यूनतम 1
और अधिकतम कई।
संबंध प्रकार
ईआरडी में दो
तालिकाओं को जोड़ने वाली रेखा, तालिकाओं के बीच संबंध प्रकार को इंगित करती
है: या तो पहचान या गैर-पहचान। एक पहचान संबंध में एक ठोस रेखा होगी (जहां पीके
में एफके होता है)। एक गैर-पहचान वाले संबंध को एक टूटी हुई रेखा द्वारा इंगित
किया जाता है और पीके में एफके शामिल नहीं करता है। अध्याय 8 में अनुभाग देखें जो
अधिक स्पष्टीकरण के लिए कमजोर और मजबूत संबंधों पर चर्चा करता है।
वैकल्पिक संबंध
एक वैकल्पिक
संबंध में, एफके अशक्त हो सकता है या माता-पिता की तालिका को एक बच्चे
की तालिका घटना होने की आवश्यकता नहीं है। चित्र 9.6 में दिखाया गया प्रतीक, एक प्रकार को
शून्य और तीन प्रागों (कई को इंगित करता है) के साथ दिखाता है जिसे शून्य और कई के
रूप में व्याख्या किया गया है।
उदाहरण के लिए, यदि आप चित्र 9.7
के दाईं ओर ऑर्डर तालिका को देखते हैं,
तो आप देखेंगे कि ग्राहक
होने के लिए ग्राहक को ऑर्डर देने की आवश्यकता नहीं है। दूसरे शब्दों में, कई पक्ष वैकल्पिक
हैं।
चित्र 9.7 में
संबंध प्रतीक को इस प्रकार भी पढ़ा जा सकता है:
बाईं ओर: ऑर्डर
इकाई में ग्राहक तालिका में न्यूनतम एक संबंधित इकाई और अधिकतम एक संबंधित इकाई
होनी चाहिए।
दाईं ओर: एक
ग्राहक न्यूनतम शून्य आदेश या अधिकतम कई आदेश दे सकता है।
चित्र 9.8 एक
शून्य और एक के साथ वैकल्पिक संबंध प्रतीक का एक अन्य प्रकार दिखाता है, जिसका अर्थ शून्य
या एक है। एक पक्ष वैकल्पिक है।
चित्र 9.9 एक उदाहरण
देता है कि कैसे एक शून्य से एक प्रतीक का उपयोग किया जा सकता है।
अनिवार्य संबंध
एक अनिवार्य
संबंध में, एक इकाई घटना के लिए एक संबंधित इकाई घटना की आवश्यकता होती
है। इस संबंध के लिए प्रतीक एक और केवल एक दिखाता है जैसा कि चित्र 9.10 में
दिखाया गया है। एक पक्ष अनिवार्य है।
उदाहरण के लिए
चित्र 9.11 देखें कि कैसे एक और केवल एक अनिवार्य प्रतीक का उपयोग किया जाता है।
चित्र 9.12 यह
दर्शाता है कि एक से कई संबंधों का प्रतीक ऐसा दिखता है जहां कई पक्ष अनिवार्य
हैं।
उदाहरण के लिए
चित्र 9.13 का संदर्भ लें कि किस प्रकार कई प्रतीकों का उपयोग किया जा सकता है।
अब तक हमने देखा
है कि एक रिलेशनशिप सिंबल का सबसे अलग पक्ष (चित्र 9.14 में सिंबल के बाईं ओर) में
0 (शून्य) कार्डिनैलिटी और कई की कनेक्टिविटी हो सकती है (सिंबल के दाईं ओर दिखाया
गया है) चित्र 9.14), या एक (दिखाया नहीं गया)।
हालाँकि, इसमें 0 (शून्य)
की कनेक्टिविटी नहीं हो सकती है, जैसा कि चित्र 9.15 में दिखाया गया है।
कनेक्टिविटी केवल 1 हो सकती है।
कनेक्टिविटी
प्रतीक अधिकतम दिखाते हैं। इसलिए यदि आप इसके बारे में तार्किक रूप से सोचते हैं, यदि बाईं ओर
कनेक्टिविटी प्रतीक 0 (शून्य) दिखाता है, तो तालिकाओं के बीच कोई
संबंध नहीं होगा।
एक चित्र प्रतीक
को पढ़ने का तरीका, जैसे कि चित्र 9.16 में एक है, इस प्रकार है।
ऑर्डर टेबल में
कस्टिड को ग्राहक तालिका में न्यूनतम 0 और अधिकतम 1 गुना होना चाहिए।
0 का मतलब है कि
ऑर्डर तालिका में CustID शून्य हो सकती है।
बाएं-सबसे 1
(कनेक्टिविटी का प्रतिनिधित्व करने से पहले दाईं ओर) कहता है कि यदि ऑर्डर तालिका
में CustID है, तो यह केवल एक बार ग्राहक तालिका में हो सकता
है।
जब आप
कार्डिनैलिटी के लिए 0 प्रतीक देखते हैं, तो आप दो चीजों को मान
सकते हैं: टी
आदेश तालिका में FK नल की अनुमति
देता है, और
एफके पीके का
हिस्सा नहीं है क्योंकि पीके में शून्य मान नहीं होना चाहिए।
No comments:
Post a Comment
Please Do Not Enter Any Spam Link in the comment Box.