🧓🏽 🛌 🏚️ डेटा अखंडता की निगरानी के साधन के रूप में भौतिक विचार 👩‍❤️‍💋‍👩 🗼 😑

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

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

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

समस्या का बयान

मैं एक काल्पनिक सरलीकृत उदाहरण का उपयोग करके दृष्टिकोण के कार्यान्वयन को दिखाना चाहता हूं। इस तरह के उदाहरण को चुनना काफी कठिन हो गया, ताकि यह देखने में काफी सरल हो, लेकिन साथ ही साथ, ताकि दृष्टिकोण का आवेदन उचित हो, अगर अचानक कुछ गलत हुआ हो तो मुझे दोष न दें।

हमें प्लेसमेंट ज़ोन के संदर्भ में सामानों की आवश्यकता है। इस मामले में प्लेसमेंट स्टोर (एस) या गोदाम (डब्ल्यू) है।

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

दूसरे प्रकार का प्रतिबंध अंचल की संरचना है। हमारे उदाहरण में, हम तीन प्रकार के क्षेत्रों के लिए नियम स्थापित करने के लिए खुद को प्रतिबंधित करते हैं:

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

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

कार्यान्वयन

टेबल

create table location ( loc number primary key ,loc_type varchar2(1 char) check (loc_type in ('S','W')) ,status varchar2(1 char) not null check (status in ('W','A','I')) ,loc_desc varchar2(200 char) ); create table zone( zone number primary key ,loc number references location(loc) ,is_pirmary varchar(1 char) not null check (is_pirmary in ('Y','N')) ,zone_type varchar2(1 char) not null ,zone_desc varchar2(200 char) ); insert into location values (1,'S','W',' 1  '); insert into zone values (1,1,'Y','K','   1'); insert into zone values (2,1,'Y','S','   1'); insert into zone values (3,1,'Y','L','    1'); commit;

मुख्य क्षेत्रों की संख्या को सीमित करें

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

 create materialized view log on zone with rowid ,sequence (zone,loc,zone_type,is_primary) including new values

हम भी "गणना (*)" मूल्य के अनुरोध के द्वारा लौटे परिणाम में शामिल करने के लिए बाध्य हैं

  create materialized view mv$zoneloc_pimary$chk refresh fast on commit as select loc ,zone_type ,count(decode(is_primary,'Y',1)) primary_count ,count(*) cnt from zone group by loc,zone_type;

यह यहां ध्यान दिया जाना चाहिए: मूल्यांकन करने के लिए कि क्या मांग पर निर्मित भौतिक दृष्टिकोण अद्यतन करने के लिए तेज विधि का उपयोग कर सकता है, dbms_mivew.explain_mview प्रक्रिया मौजूद है । यह नियंत्रित करने के लिए इसका उपयोग करने की अत्यधिक सलाह दी जाती है कि प्रस्तुत करने के लिए फास्ट अपडेट विधि उपलब्ध है या नहीं। उदाहरण के लिए, यदि हम अनुरोध में गिनती (*) निर्दिष्ट करना भूल गए हैं, तो एक भौतिक दृश्य सफलतापूर्वक बनाया जाएगा और सम्मिलित ऑपरेशन करते समय सही ढंग से काम करेगा। हालाँकि, संशोधन, विलोपन के बाद, प्रायमरी_काउंट का मान नहीं लिया जाएगा, जो हमारे प्रतिबंध के तर्क का उल्लंघन करेगा। हालाँकि, अगर हम एक्सप्ले_म्यू का उपयोग करते हैं, तो ओरेकल हमें हमारा मिसकॉल बताने में मदद करेगा।

  SQL> set serveroutput on SQL> declare 2 result SYS.ExplainMVArrayType; 3 begin 4 dbms_mview.explain_mview(mv => 'select loc 5 ,zone_type 6 ,count(decode(is_primary,''Y'',1)) primary_counnt 7 --,count(*) cnt 8 from zone 9 group by loc,zone_type' 10 ,msg_array => result 11 ); 12 for i in 1..result.count 13 loop 14 dbms_output.put(rpad(result(i).capability_name,30,' ')); 15 dbms_output.put(' '||result(i).POSSIBLE); 16 dbms_output.put(' '||result(i).MSGTXT); 17 dbms_output.put_line(null); 18 end loop; 19 end; 20 / PCT F REFRESH_COMPLETE T REFRESH_FAST T REWRITE T PCT_TABLE F relation is not a partitioned table REFRESH_FAST_AFTER_INSERT T REFRESH_FAST_AFTER_ONETAB_DML F COUNT(*) is not present in the select list REFRESH_FAST_AFTER_ANY_DML F see the reason why REFRESH_FAST_AFTER_ONETAB_DML is disabled REFRESH_FAST_PCT F PCT is not possible on any of the detail tables in the materialized view REWRITE_FULL_TEXT_MATCH T REWRITE_PARTIAL_TEXT_MATCH T REWRITE_GENERAL T REWRITE_PCT F general rewrite is not possible or PCT is not possible on any of the detail tables PCT_TABLE_REWRITE F relation is not a partitioned table PL/SQL procedure successfully completed

तो, भौतिकवादी दृश्य बनाया गया है, यह केवल प्रतिबंध जोड़ने के लिए बना हुआ है

  alter table mv$zoneloc_pimary$chk add constraint zone_loc_primary$chk check (primary_count=1) deferrable initially deferred;

कृपया ध्यान दें कि प्रतिबंध को स्थगित बनाया गया है। तथ्य यह है कि ओरेकल द्वारा प्रस्तुति को अपडेट करने की प्रक्रिया में, कुछ मध्यवर्ती स्तर पर, यह पता चला सकता है कि प्रतिबंध का अस्थायी रूप से उल्लंघन किया जाएगा। इस तरह के झूठे सकारात्मक से बचने के लिए, ऐसे प्रतिबंधों को जानबूझकर देरी से सेट करना बेहतर है।

इस प्रतिबंध के संचालन की जांच करें

  SQL> insert into location values (2,'S','W',' 2     '); 1 row inserted SQL> commit; Commit complete

आइए एक ऐसे प्रकार के साथ एक ज़ोन बनाने का प्रयास करें जिसमें "मुख्य" चिह्न न हो।

  SQL> insert into zone values (4,2,'N','S','    '); 1 row inserted SQL> commit; ORA-02091: transaction rolled back ORA-02290: check constraint (ZTXN.ZONE_LOC_PRIMARY$CHK) violated

हम एक ही प्रकार के साथ प्लेसमेंट के लिए दो मुख्य क्षेत्रों की पहचान करने की कोशिश करेंगे।

  SQL> insert into zone values (5,2,'Y','L','    '); 1 row inserted SQL> commit; Commit complete SQL> insert into zone values (6,2,'Y','L','    '); 1 row inserted SQL> commit; ORA-02091: transaction rolled back ORA-02290: check constraint (ZTXN.ZONE_LOC_PRIMARY$CHK) violated

आवास क्षेत्रों की संरचना का प्रतिबंध

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

सबसे पहले आपको आवंटन तालिका के लिए एक भौतिकीकृत शाकाहारी लॉग बनाना होगा। ज़ोन तालिका के लिए, पहले से बनाए गए लॉग का उपयोग किया जाएगा।

 create materialized view log on location with rowid ,sequence (loc,loc_type,status) including new values;

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

  create materialized view mv$location$zone$join refresh fast on commit as select l.loc ,l.loc_type ,z.zone ,z.zone_type ,l.rowid l_rowid ,z.rowid z_rowid from location l ,zone z where z.loc(+) = l.loc and l.status in ('A','I')

दृश्‍य में शामिल होने के लिए भौतिक वेजी लॉग बनाएं

 create materialized view log on mv$location$zone$join with rowid ,sequence (loc,loc_type,zone_type) including new values;

एक समग्र भौतिक दृश्य बनाएं

  create materialized view mv$location$zone$agg refresh fast on commit as select loc ,loc_type ,count(decode(zone_type,'K',1)) K_cnt ,count(decode(zone_type,'S',1)) S_cnt ,count(decode(zone_type,'L',1)) L_cnt ,count(*) cnt from mv$location$zone$join group by loc,loc_type;

खैर, सीमाएं खुद

  alter table mv$location$zone$agg add constraint wh_zones_chk check(loc_type != 'W' or K_cnt > 0 and S_cnt = 0 and L_cnt > 0) deferrable initially deferred; alter table mv$location$zone$agg add constraint store_zones_chk check(loc_type != 'S' or K_cnt >= 0 and S_cnt > 0 and L_cnt > 0) deferrable initially deferred;

प्रतिबंधों के संचालन की जाँच करें:

  SQL> insert into location (loc,loc_type,status,loc_desc) 2 values (3,'S','W',' 3    '); 1 row inserted SQL> commit; Commit complete

ड्राफ्ट की स्थिति में प्लेसमेंट सफलतापूर्वक बनाया गया है। आइए इसे सक्रिय करने का प्रयास करें:

  SQL> update location set status = 'A' where loc = 3; 1 row updated SQL> commit; ORA-02091: transaction rolled back ORA-02290: check constraint (ZTXN.STORE_ZONES_CHK) violated

नहीं। यदि आप इसके प्रकार के लिए आवश्यक क्षेत्र परिभाषित नहीं हैं तो आप किसी प्लेसमेंट को सक्रिय नहीं कर सकते।

  SQL> insert into zone(zone,loc,is_primary,zone_type) values (7,3,'Y','S'); 1 row inserted SQL> insert into zone(zone,loc,is_primary,zone_type) values (8,3,'Y','L'); 1 row inserted SQL> update location set status = 'A' where loc = 3; 1 row updated Commit complete

निष्कर्ष

इसका उपयोग कब करना है

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

जब परीक्षण तर्क के सही संचालन में आत्मविश्वास की कमी है, और परीक्षण लिंक के माध्यम से डेटा को संशोधित किया जा सकता है, तो परीक्षण के चरणों में इस तरह के प्रतिबंधों को रखना बहुत सुविधाजनक है।

जब इसका उपयोग नहीं करना है

जाहिर है, आपको इस दृष्टिकोण का उपयोग उन मामलों में नहीं करना चाहिए जहां यह प्रदर्शन में एक उल्लेखनीय गिरावट देता है।

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

डेटा अखंडता की निगरानी के साधन के रूप में भौतिक विचार