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