संस्करण और डेटा इतिहास

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

टाइप ०

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

टाइप 1

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

लाभ:

• कोई अतिरेक नहीं जोड़ा गया
• बहुत ही सरल संरचना

नुकसान:

• कहानियों को संग्रहीत नहीं करता है

टाइप 2

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



एक उदाहरण:

आईडी	नाम	POSITION_ID	विभाग	DATE_START	DATE_END
1	अंजन	21	2	08/11/2010 10:42:25	01.01.9999
2	डेनिस	23	3	08/11/2010 10:42:25	01.01.9999
3	बोरिस	26	2	08/11/2010 10:42:25	01.01.9999
4	शेल्डन	22	3	08/11/2010 10:42:25	01.01.9999
5	पैसे	25	2	08/11/2010 10:42:25	01.01.9999

इस उदाहरण में, डिफ़ॉल्ट संस्करण की तारीख '01 .01.9999 'है, जिसके बजाय यह निर्दिष्ट करना, कहना, अशक्त करना संभव होगा, लेकिन फिर आईडी, DATE_START और DATE_END और, से अतिरिक्त प्राथमिक कुंजी बनाने में समस्या होगी। एक विशिष्ट तिथि के लिए चयन की स्थिति सरल है (" where snapshot_date between DATE_START and DATE_END



बजाय" where snapshot_date>DATE_START and (snapshot_date < DATE_END or DATE_END is null)



"।

इस कार्यान्वयन के साथ, जब आप किसी कर्मचारी को बर्खास्त करते हैं, तो आप बस वर्तमान संस्करण की समाप्ति तिथि को बर्खास्तगी की तारीख के बजाय व्यावसायिक रिकॉर्ड को बदल सकते हैं।

लाभ:

• एक पूर्ण और असीमित संस्करण इतिहास रखता है
• आवश्यक अवधि के डेटा के लिए सुविधाजनक और आसान पहुंच

नुकसान:

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

टाइप 3

रिकॉर्ड में पिछले विशेषता मानों के लिए अतिरिक्त फ़ील्ड हैं। जब नया डेटा प्राप्त होता है, तो पुराने डेटा को वर्तमान मानों के साथ अधिलेखित कर दिया जाता है।

	आईडी	UPDATE_TIME	LAST_STATE	CURRENT_STATE
1	1	08/11/2010 12:58:48	0	1
2	2	08/11/2010 12:29:16	1	1

लाभ:

• डेटा की छोटी राशि
• इतिहास की आसान और त्वरित पहुँच

नुकसान:

• सीमित कहानी

टाइप 4

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



एक उदाहरण:

 select * from emp
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

आईडी	नाम	POSITION_ID	विभाग
1	अंजन	21	2
2	डेनिस	23	3
3	बोरिस	26	2
4	शेल्डन	22	3
5	पैसे	25	2

 select * from emp_history
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

आईडी	नाम	POSITION_ID	विभाग	DATE को
1	अंजन	21	1	11/11/2010 14:12:13
2	डेनिस	23	2	11/11/2010 14:12:13
3	बोरिस	26	1	11/11/2010 14:12:13
4	शेल्डन	22	2	11/11/2010 14:12:13

लाभ:

• वर्तमान संस्करणों के साथ त्वरित कार्य

नुकसान:

• एकल इकाई को अलग-अलग तालिकाओं में अलग करना

हाइब्रिड टाइप / टाइप 6 (1 + 2 + 3)

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

एक उदाहरण:

संस्करण	आईडी	नाम	POSITION_ID	विभाग	DATE_START	DATE_END	वर्तमान
1	1	अंजन	21	2	08/11/2010 10:42:25	01.01.9999	1
1	2	डेनिस	23	3	08/11/2010 10:42:25	01.01.9999	1
1	3	बोरिस	26	2	08/11/2010 10:42:25	08/11/2010 11:42:25	0
2	3	बोरिस	26	2	08/11/2010 11:42:26	01.01.9999	1

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

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



मुझे एससीडी कार्यान्वयन पर कुछ सुझाव जोड़ें:

• संग्रहीत प्रक्रियाओं में रिकॉर्ड बदलने के लिए एक तंत्र को लागू करने का प्रयास करें - यह परिवर्तन कोड के लिए स्पष्ट रूप से अवांछनीय है, भले ही परिवर्तन कोड आपके बाहरी अनुप्रयोग में स्पष्ट रूप से परिभाषित स्थानों में संग्रहीत हो;
• यदि आप 1 मॉडल से दूसरे में एक चिकनी संक्रमण करना चाहते हैं, तो आप यह कर सकते हैं:
  
  1) नाम बदलने के साथ टाइप 2 एससीडी द्वारा तालिका बदलें, उदाहरण के लिए, table_name_scd2 पर
  
  2) पुरानी तालिका के नाम के साथ एक अद्यतन दृश्य बनाएं, जो पुरानी तालिका के समान संरचना में डेटा का उत्पादन करेगा;
  
  3) यदि आप संग्रहीत प्रक्रियाओं में सभी परिवर्तन नहीं करते हैं (मुझे आशा है कि यह अस्थायी है :)) जो आपने पहले ही बदल दिया है, तो ऐसे ट्रिगर्स बनाएं जो नए फ़ील्ड को पॉप्युलेट करेंगे यदि वे अनुरोध द्वारा सेट नहीं किए गए हैं (जब: new.start_date अशक्त है। ..) और इसे लॉग इन करें फिर यह सुनिश्चित करें कि आपने सब कुछ बदल दिया है
• ऐसे मामलों में जहां संस्करण की शुरुआत और अंत के क्षेत्रों का उपयोग किया जाता है, प्राथमिक कुंजी का उपयोग करने के अलावा, जिसमें ऑब्जेक्ट की पहचानकर्ता और संस्करण की शुरुआत और समाप्ति तिथियां शामिल हैं, आपको संस्करण तिथियों के गैर-चौराहे पर प्रतिबंध बनाकर अखंडता को नियंत्रित करने की आवश्यकता होगी। यह बहुत अच्छा है अगर आपका DBMS गैर-नियतात्मक कार्यों के आधार पर चेक बाधाओं का समर्थन करता है जो आपको ऐसा करने की अनुमति देता है (वैसे, मैं यह जानना चाहूंगा कि कौन से DBMS इसका समर्थन करते हैं), लेकिन यदि यह नहीं है, तो आप अपवाद बनाने या बदलने और फेंकने से पहले ट्रिगर में स्थिति की जांच कर सकते हैं। उल्लंघन के मामले में। Oracle के लिए उदाहरण:
  
  

   create or replace trigger T_EMP_CHECK before insert or update on emp for each row declare f_ok number; begin select count(*) into f_ok from dual where exists( select null from emp e where e.id = :new.id and e.date_start <= :new.date_end and e.date_end >= :new.date_start ); if f_ok>0 then raise DUP_VAL_ON_INDEX; end if; end T_EMP_CHECK;
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  
• टाइप 1 से टाइप 4 में स्विच करते समय, आपको बस एक पहले अपडेट ट्रिगर बनाने की आवश्यकता होती है, जिसमें आप रिकॉर्ड को एक नए टेबल में रिकॉर्ड के लिए स्टोर करेंगे

पुनश्च। हबरलायुडी, साझा करें कि आप किस दिलचस्प हाइब्रिड कार्यान्वयन से मिले हैं?