सूचना प्रणाली में आवधिक जानकारी बनाए रखना

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

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

उदाहरण के लिए, किसी व्यक्ति के बारे में जानकारी लें।

"". :
-
-
-
-
-
-
-


समय के साथ बदले जा सकने वाले विवरण सैद्धांतिक रूप से हो सकते हैं: उपनाम, पहला नाम, परिवार की स्थिति, निवास का पता और, ईमानदार होने के लिए, पॉल।

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

हम "व्यक्ति" ऑब्जेक्ट से चर विवरण निकालते हैं और आवधिक जानकारी संग्रहीत करने के लिए एक ऑब्जेक्ट बनाते हैं।

"". :
-
-

" ". :
-
-
-
-
-
-
-


(वास्तव में, आप व्यक्ति से विवरण में सभी विवरण स्थानांतरित कर सकते हैं, यहां लक्ष्य यह दिखाना है कि यह आवश्यक नहीं है)

सूचना वस्तु "सूचना के परिवर्तन की तिथि" और प्रमुख व्यक्ति वस्तु के लिंक की उपस्थिति से प्रतिष्ठित होती है।

सिस्टम के सभी ऑब्जेक्ट्स में, "व्यक्ति" ऑब्जेक्ट और इसके लिंक का उपयोग किया जाना चाहिए, और जानकारी को केवल एक सीधा लिंक के बिना एक अधीनस्थ वस्तु के रूप में उपयोग किया जाएगा।

ऐसा लगता होगा कि सब! लेकिन यह केवल लगता है।

व्यक्ति की सूची प्रदर्शित करने की कोशिश करते समय कठिनाइयाँ तुरंत शुरू हो जाती हैं। आइए एक क्वेरी लिखने की कोशिश करते हैं जो ऐसा करती है। हम कल्पना को शामिल करते हैं और हम रूसी में ऑब्जेक्ट एसक्यूएल प्रस्तुत करते हैं:

select ., ., .
from ,
where .ID = .


लेकिन यहाँ अभी समस्या है - हम व्यक्ति पर जानकारी का पूरा इतिहास देखेंगे। और हमें वर्तमान तिथि के लिए प्रासंगिक जानकारी वाले लोगों की सूची चाहिए। आवश्यकताओं का पालन करना:

select ., ., .
from ,
where .ID = .
and .ID = (select top 1 .ID from where .ID = . and . <= order by . desc)


परिणाम अब सही है, लेकिन क्वेरी बहुत लंबा समय लेती है और बड़े वॉल्यूम पर DBMS को पूरी तरह से अक्षम कर सकती है, क्योंकि उपश्रेणियों का एक समूह निष्पादित किया जा रहा है।

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

एक तारीख के साथ रजिस्टर को पूरक करें।

" ". :
-
-
-
-
...


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

select ., ., .
from ,
where .ID = .
and . >
and . <=


सब कुछ पहले से ही बहुत तेज़ है!

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

आइए देखें कि कोई व्यक्ति आवधिक जानकारी के दूसरे संस्करण को कैसे संग्रहीत कर सकता है, उदाहरण के लिए, संगठनों के संदर्भ में एक ही व्यक्ति के काम का स्थान।

. "". :
-
-
-
-
-


वर्तमान तिथि के लिए सभी कंपनी कर्मचारियों का चयन:

select ., ., ., ., .
from , ,
where .ID = .
and . >
and . <=
and .ID = .
and . <=
and . >
and . =


सब कुछ अच्छा और अद्भुत है। ऐसा लगता है कि कोई समस्या नहीं है ... जब तक हमें उन लोगों को गिनने / वापस लेने के लिए नहीं कहा जाता है, जिन्होंने वर्ष की शुरुआत से कंपनी में काम किया है?

आइए विचार करें कि यह कौन से कर्मचारी हो सकते हैं:
a) वह जो वर्ष की शुरुआत में काम करता था
b) वह जो वर्तमान तिथि के लिए काम करता है
ग) वह जो वर्ष की शुरुआत के बाद आया और अब तक छोड़ दिया गया

(सादगी के लिए, हम अनुरोध से व्यक्तियों को हटा देंगे; क्योंकि उनके साथ सब कुछ स्पष्ट है, हम मान लेंगे कि वे व्यक्ति के नाम क्षेत्र से उपलब्ध हैं)

select ., ., .
from ,
and .ID = .
and . =
and (
(. <= and . > ) /* */
or (. <= and . > ) /* */
or (. >= and . <= ) /* */
)


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

यहां आप किसी व्यक्ति के बारे में जानकारी के समान भंडारण दृष्टिकोण भी लागू कर सकते हैं।

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

"". :
-
-
-
-
-
-


हम उसी अनुरोध को फिर से लिखते हैं:

select ., ., .
from ,
and .ID = .
and . =
and (
(. <= and . > and . > ) /* */
or (. <= and . > ) /* */
or (. >= and . <= and . > ) /* */
)


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

इस डिजाइन के लिए धन्यवाद, आप बस सवालों के जवाब पा सकते हैं:
- उन लोगों की एक सूची जिन्होंने कभी (या अवधि) कंपनी के लिए काम किया है
- हाल ही में एक तारीख पर सेवानिवृत्त होने की सूची
- तारीख के बाद पहले बसे की एक सूची
- आदि।

पीएस मुझे आशा है कि थक नहीं

UPD 03/28/2011
मैक्सिमकैट के अनुसार, मैंने कर्मचारी के लिए अनुरोध ग्रंथों को अद्यतन किया।
मुख्य विवरण के बारे में एक नोट भी जोड़ा।