IOS के लिए कोर डेटा। अध्याय संख्या 4। सैद्धांतिक भाग

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



सामग्री:

• अध्याय संख्या 1। आरंभ करना ( व्यावहारिक भाग )
• अध्याय संख्या 2। मास्टर कोर डेटा ( व्यावहारिक भाग )
• अध्याय संख्या 3। डेटा भंडारण: SQLite और अन्य विकल्प
• अध्याय संख्या 4। डेटा मॉडल बनाना
• अध्याय संख्या ५। डेटा ऑब्जेक्ट्स के साथ कार्य करना
• अध्याय संख्या 6। परिणाम सेट करना
• अध्याय संख्या 7। प्रदर्शन और स्मृति ट्यूनिंग
• अध्याय संख्या 8। संस्करण और प्रवासन
• अध्याय संख्या 9। NSFetchedResultsController का उपयोग कर तालिकाओं का प्रबंधन करें
• अध्याय संख्या 10। उन्नत अनुप्रयोगों में कोर डेटा का उपयोग करना

प्रविष्टि

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

डेटाबेस डिजाइन

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

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

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

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

युक्ति : डेटा का ध्यान रखें, न कि उस डेटा का संग्रहण तंत्र।

एक रिलेशनल डेटाबेस को सामान्य करना

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

"एक रिश्ता आर चौथे सामान्य रूप में है (4NF) अगर और केवल अगर, जहाँ भी R में MVD मौजूद है, A -> -> B कहते हैं, तो R की सभी विशेषताएँ कार्यात्मक रूप से A पर निर्भर हैं। दूसरे शब्दों में, R में केवल निर्भरता (FD या MVD) K -> X के हैं (यानी उम्मीदवार कुंजी K से कुछ अन्य विशेषता X के लिए एक कार्यात्मक निर्भरता)। समान रूप से: आर 4 एनएफ में है अगर यह बीसीएनएफ में है और आरवी के सभी एमवीडी वास्तव में एफडी हैं। "

(c) www.databasedesign-resource.com/normal-forms.html

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

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

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

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

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

Xcode में मॉडल डिज़ाइनर का उपयोग करना

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

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


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


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


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


जैसा कि हम देख सकते हैं, डिफ़ॉल्ट रूप से Xcode तालिकाओं के रूप में संस्थाओं को प्रदर्शित करता है। यदि यह आपके लिए मॉडल के चित्रमय प्रतिनिधित्व के साथ काम करना अधिक सुविधाजनक है, तो आपको संपादक के निचले भाग में "संपादक शैली" शिलालेख के ऊपर स्थित "ग्राफ़ व्यू" बटन पर क्लिक करना होगा।


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


+ ईमेल विशेषता को कहा जाता है
+ वैकल्पिक है
+ अस्थायी या अनुक्रमित नहीं
+ स्ट्रिंग प्रकार
+ न्यूनतम और अधिकतम लंबाई पर कोई सीमा नहीं
+ कोई डिफ़ॉल्ट मान नहीं
+ कोई बाउंड रेगुलर एक्सप्रेशन नहीं
+ फील्ड स्पॉटलाइट द्वारा अनुक्रमित नहीं
+ फ़ील्ड मान बाहरी रिकॉर्ड में संग्रहीत नहीं किया जाएगा

प्लेयर इकाई के टीम संचार पर स्विच करने से पैनल निम्नानुसार बदलता है:


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

प्लेयर के सार पर एक नज़र डालें:


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

विशेषताएँ देखें और संपादित करें

Xcode के "गुण" खंड में किसी भी विशेषता का चयन करें ताकि दायाँ पैनल अपना रूप बदल ले और चयनित विशेषता के लिए सभी जानकारी प्रदर्शित करे। नीचे दी गई तालिका में विशेषता गुण का नाम और उसके उद्देश्य का वर्णन किया गया है।

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

लिंक देखें और संपादित करें

उसी तरह जैसे कि विशेषता की जानकारी देखते समय, हम किसी लिंक का चयन करके लिंक के गुणों को देख सकते हैं।

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

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

अंत में, मूल डेटा हटाने के नियमों का उपयोग करता है ताकि यह पता चल सके कि मूल को हटाने के दौरान अंतिम वस्तुओं के साथ क्या करना है।कोर डेटा सपोर्ट करने वाले कई अनइंस्टॉल विकल्प हैं। इस प्रकार के विलोपन हैं: कोई क्रिया नहीं, Nullify, Cascade, Deny। इस अध्याय में "कॉन्फ़िगरेशन नियम" खंड निष्कासन नियमों और उनके अर्थ पर चर्चा करता है।

गुणों के रूप में क्वेरी का उपयोग करना

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

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

"Predicate" फ़ील्ड में, मानक NSPredicate प्रारूप का उपयोग करके फ़िल्टर के मानदंड निर्दिष्ट करें (हम अध्याय 6 में प्रारूप और NSPredicate के बारे में अधिक बात करेंगे)। इस उदाहरण में, विधेय इस तरह दिखेगा: lastName BEGINSWITH "W" ।

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

 NSFetchedRequest *fetchRequest = [[NSFetchedRequest alloc] init]; [fetchRequest setEntity:[NSEntityDescription entityForName:@"Team" inManagedObjectContext:self.managedObjectContext]]; NSArray *teams = [self.managedObjectContext executeFetchRequest:fetchRequest error:nil]; if([teams count] > 0){ NSManagedObject *team = [teams objectAtIndex:0]; NSSet *wPlayers = [team valueForKey:@"wPlayers"]; for(NSManagedObject *wPlayer in wPlayers) { NSLog(@"%@ %@", [wPlayer valueForKey:@"firstName"], [wPlayer valueForKey:@"lastName"]); } } 

यदि हम इस कोड को निष्पादन के लिए चलाते हैं, तो आपके पास पहले से ही आवेदन में कौन सा डेटा है, इसके आधार पर, हमें निम्नलिखित आउटपुट देखना चाहिए:

 2011-07-31 19:08:23.005 League Manager[8039:f203] Dwyane Wade 2011-07-31 19:08:23.006 League Manager[8039:f203] Tyson Warner 

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


इस तरह से बनाए गए गुणों के अनुरोध डेटा मॉडल में संग्रहीत किए जाते हैं और fetchRequestTemplateForName: NSManagedObjectModel वर्ग विधि का उपयोग करके प्राप्त किया जा सकता है। application:didFinishLaunchingWithOptions: कुछ कोड जोड़ें application:didFinishLaunchingWithOptions: नए बने अनुरोध के स्वास्थ्य को सत्यापित करने के लिए प्रतिनिधि विधि:

 NSFetchRequest *fetchRequest = [self.managedObjectModel fetchRequestForTemplateName:@"GreenTeams"]; NSArray *teams = [self.managedObjectContext executeFetchRequest:fetchRequest error:nil]; for(NSManagedObject *team in teams){ NSLog(@"%@", [team valueForKey:@"name"]); } 

आपके पास एप्लिकेशन में मौजूद डेटा के आधार पर, आपको निम्नलिखित आउटपुट को देखना चाहिए:

 2011-07-31 19:17:25.598 League Manager[8184:f203] Boston Celtics 

इकाई निर्माण

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

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


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


अगला कदम प्लेयर एंटिटी को बदलना है: पेरेंट (इनहेरिट की गई) पर्सन एंटिटी को सेट करें। प्लेयर इकाई का चयन करें और ड्रॉप-डाउन सूची में जिसे "पेरेंट एंटिटी" कहा जाता है, "पर्सन" चुनें:


अब प्लेयरऑफर विशेषता dateOfBirth उपलब्ध होगी।

विशेषताएँ बनाएँ

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


इस अध्याय में पहले, हमने विभिन्न गुण गुणों के बारे में बात की। निस्संदेह सबसे महत्वपूर्ण विशेषता संपत्ति इसका प्रकार है। डिफ़ॉल्ट रूप से, कोर डेटा कई प्रकार प्रदान करता है:



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

लिंक बनाना

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

Xcode में, कनेक्शन बनाते समय या किसी को चुनते समय, हम सेटिंग्स का एक सेट देखते हैं जो हमें कनेक्शन की प्रकृति को बदलने की अनुमति देगा। उदाहरण के लिए, यदि हम खिलाड़ी इकाई में टीम संबंध का चयन करते हैं, तो हम निम्नलिखित चित्र देखेंगे:


खेतों की सूची:

• पहला नाम
• परम अस्तित्व
• प्रतिक्रिया
• क्षणिक (क्षणिक)
• ऐच्छिक
• टू-रिलेशनशिप है
• मात्रा (न्यूनतम और अधिकतम)
• निष्कासन नियम

निम्नलिखित अनुभागों में, हम इन क्षेत्रों की अधिक विस्तार से जांच करेंगे कि वे किसी इकाई के गुणों को कैसे प्रभावित करते हैं और उनका क्या मतलब है।

संचार का नाम (नाम)

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

गंतव्य और उलटा

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

प्रतिलोम क्षेत्र को बिना प्रतिलोम संबंध पर छोड़ना दो चेतावनी की गारंटी देता है: एक संगति त्रुटि और एक गलत तरीके से कॉन्फ़िगर की गई विशेषता।

आप इसे अनदेखा कर सकते हैं, आखिरकार, ये केवल संकलक चेतावनी हैं, त्रुटियां नहीं हैं, लेकिन आप अप्रत्याशित परिणाम का सामना कर सकते हैं। कोर डेटा Redo / Undo ऑपरेशन को संभालने के लिए ऑब्जेक्ट ग्राफ स्थिरता बनाए रखने के लिए दो-तरफ़ा संचार जानकारी का उपयोग करता है। एक व्युत्क्रम इकाई को निर्दिष्ट किए बिना कनेक्शन छोड़कर, आप पूर्ववत् / फिर से संचालन करने के लिए ऑब्जेक्ट ग्राफ की स्थिरता बनाए रखने की जिम्मेदारी लेते हैं। ऐप्पल प्रलेखन दृढ़ता से इसके खिलाफ सलाह देता है, विशेष रूप से कई-से-कई संबंधों का उपयोग करने के मामले में। यदि आप उलटा कनेक्शन निर्दिष्ट नहीं करते हैं, तो कनेक्शन के दूसरे छोर से प्रबंधित ऑब्जेक्ट को एक बदले हुए ऑब्जेक्ट के रूप में चिह्नित नहीं किया जाएगा, अगर कनेक्शन के इस तरफ से प्रबंधित ऑब्जेक्ट बदल गया है।

क्षणिक (क्षणिक)

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

• उन संस्थाओं के बीच संबंध जो अस्थायी हैं और वर्तमान एप्लिकेशन लॉन्च सत्र से अधिक समय तक मौजूद नहीं होना चाहिए
• संचार जानकारी जो कुछ बाहरी डेटा स्रोतों से प्राप्त की जा सकती है, यह एक और कोर डेटा स्टोर या किसी अन्य जानकारी का स्रोत हो सकता है

ज्यादातर मामलों में, आप अपने कनेक्शन को स्थायी और बनाए रखना चाहेंगे।

वैकल्पिक (वैकल्पिक)

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

बहुत से संबंध

विकल्प भी एक चेकबॉक्स है। यदि चेकबॉक्स सेट है, तो वर्तमान कनेक्शन उस छोर पर बहुत सारी वस्तुओं को इंगित कर सकता है, यदि नहीं, तो हमें "एक-एक" कनेक्शन मिलता है।

मात्रा (न्यूनतम और अधिकतम)

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

नियम हटाएं

हटाए गए नियम उन क्रियाओं को निर्धारित करते हैं जो किसी ऑब्जेक्ट को लिंक से हटाते समय कोर डेटा की आवश्यकता होती है।
हटाने के 4 प्रकार हैं:
1. कैस्केड - स्रोत ऑब्जेक्ट को हटा दिया जाता है, सभी संबंधित (अंतिम) ऑब्जेक्ट भी हटा दिए जाते हैं
2. इनकार - यदि स्रोत ऑब्जेक्ट कुछ वस्तुओं के साथ जुड़ा हुआ है, तो विलोपन नहीं होता है
3. Nullify - सभी संबंधित वस्तुओं के लिए मूल ऑब्जेक्ट को हटा दिया जाता है, प्रतिक्रिया शून्य पर सेट की जाती है।
4. कोई कार्रवाई नहीं - मूल ऑब्जेक्ट को हटा दिया जाता है, संबंधित ऑब्जेक्ट किसी भी तरह से नहीं बदलते हैं

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