मुझे लगता है कि सवाल पर्याप्त स्पष्ट है। मेरे डाटावायरहाउस टेबल में से कुछ कॉलम प्राथमिक कुंजी से रिश्तेदार हो सकते हैं। लेकिन क्या यह अच्छा अभ्यास है? यह denormalized है, तो इसे फिर से हटाया नहीं जाना चाहिए (डेटावेयर में डेटा)। उम्मीद है कि सवाल कुछ हद तक स्पष्ट है।क्या डाटावायरहाउस (रिश्तों) में विदेशी कुंजी रखने का अच्छा अभ्यास है?
मुझे कोई जानकारी नहीं है। लेकिन कोई भी जवाब देने है, इसलिए मैं googled और a best practises paper जो कहने के लिए बहुत उपयोगी "यह निर्भर करता है" लग पाया :-)
जबकि विदेशी कुंजी की कमी डेटा अखंडता मदद, वे सब सम्मिलित करें, अद्यतन पर एक जुड़े लागत है और बयान हटाएं। जब आप डेटा अखंडता और सत्यापन सुनिश्चित करना चाहते हैं तो
मुझे लगता है कि आप वास्तव में एफके को संदर्भ तालिका में संदर्भित करते हैं। डीडब्ल्यू लोडिंग के दौरान, इंडेक्स और लोडिंग को तेज करने के लिए किसी भी विदेशी कुंजी को गिरा दिया जाता है - ईटीएल प्रक्रिया कुंजी की देखभाल करती है।
विदेशी कुंजी बाधा आवेषण और अद्यतन के दौरान "सक्रिय" होती है (यह तब होता है जब यह जांचने की आवश्यकता होती है कि मूल तालिका में मुख्य मान मौजूद है) और मूल तालिका में प्राथमिक कुंजी के हटाए जाने के दौरान। यह पढ़ने के दौरान हिस्सा नहीं खेलता है। डीडब्ल्यू में रिकॉर्ड हटाना (नियंत्रित) एक नियंत्रित प्रक्रिया होनी चाहिए जो आयाम तालिकाओं से हटाने से पहले किसी मौजूदा संबंध के लिए स्कैन करती है।
तो, अधिकांश डीडब्ल्यू में बाधाओं के रूप में लागू विदेशी कुंजी नहीं होती है।
quesiton स्पष्ट है, लेकिन "अच्छा अभ्यास" गलत सवाल प्रतीत होता है।
" में एफके का" हो सकता है?
विदेशी कुंजी डेटाबेस संशोधन के दौरान अखंडता बाधाओं को संरक्षित करने के लिए एक तंत्र है।
यदि आपका डीडब्ल्यू केवल पढ़ने योग्य है (वापस लिखने के बिना डेटा स्रोत जमा करना), तो एफके की कोई आवश्यकता नहीं है।
यदि आपका डीडब्ल्यू लिखता है, तो ईमानदारी की स्थिरताओं को आम तौर पर ईटीएल (बल्कि, यह स्टोर समकक्ष) द्वारा भाग लेने वाले डेटा स्रोतों में समन्वयित करने की आवश्यकता होती है। यह प्रक्रिया डेटाबेस में एफके पर भरोसा कर सकती है या नहीं।
तो सही सवाल होगा: क्या आप की आवश्यकता है।
एक में एक विदेशी कुंजी बाधा उपयोग करने का कारण -
(हालांकि, इस/कागज पर किया जा सकता है एक अलग दस्तावेज में भी केवल अन्य कारण से मैं के बारे में सोच सकते हैं रिश्ते के दस्तावेजीकरण किया जाएगा।) डाटा वेयरहाउस किसी भी अन्य डेटाबेस के समान है: डेटा अखंडता सुनिश्चित करने के लिए।
यह भी संभव है कि क्वेरी प्रदर्शन लाभान्वित होगा क्योंकि विदेशी कुंजी कुछ प्रकार की क्वेरी को फिर से लिखने की अनुमति देती है जो उनके बिना सामान्य रूप से संभव नहीं होती है। डेटा अखंडता अभी भी विदेशी कुंजी का उपयोग करने का मुख्य कारण है।
एफके बाधाएं SQL सर्वर पर किमबाल आयामी मॉडल में अच्छी तरह से काम करती हैं।
आमतौर पर, आपके ईटीएल को आयाम सरोगेट आईडी निर्धारित करने के लिए आयाम तालिका (आमतौर पर धीरे-धीरे बदलते आयामों को संभालने के लिए व्यावसायिक कुंजी पर) देखने की आवश्यकता होगी, और आयाम सरोगेट आईडी आमतौर पर एक पहचान है, और आयाम पर पीके आम तौर पर आयाम सरोगेट आईडी है, जो पहले से ही एक सूचकांक (शायद क्लस्टर) है।
इस बिंदु पर आरआई होने के कारण लिखने के साथ ओवरहेड नहीं है, क्योंकि यह विकास के दौरान ईटीएल दोषों को पकड़ने में भी मदद कर सकता है। साथ ही, तथ्य तालिका के पीके को सभी एफके का संयोजन होने से संभावित डेटा मॉडलिंग समस्याओं और डबल लोडिंग में भी मदद मिल सकती है।
यदि आप सामान्य रूप से उपयोग किए गए फ़्लैट किए गए दृश्य या अपने स्टार मॉडल के टेबल-मूल्यवान फ़ंक्शंस बनाना चाहते हैं तो यह वास्तव में चयन पर ओवरहेड को कम कर सकता है। चूंकि अतिरिक्त आंतरिक आयामों में शामिल होता है, इसलिए एक और केवल एक पंक्ति उत्पन्न करने की गारंटी दी जाती है, इसलिए ऑप्टिमाइज़र तालिका में देखने की आवश्यकता को समाप्त करने के लिए इन बाधाओं का बहुत प्रभावी ढंग से उपयोग कर सकता है। एफके बाधाओं के बिना, इन लुकअप को उन तथ्यों को खत्म करने के लिए किया जाना चाहिए जहां आयाम मौजूद नहीं है।
डीडब्ल्यू में एफके-बाधाओं का उपयोग करना एक साइकिल हेल्मेट पहनना है। यदि ईटीएल सही ढंग से डिज़ाइन किया गया है, तो आप तकनीकी रूप से की आवश्यकता नहीं है। उस ने कहा, अगर मेरे पास हर बार एक मिलियन डॉलर थे तो मैंने बग-फ्री ईटीएल देखा है, मेरे पास शून्य डॉलर होंगे।
जब तक आप उस बिंदु पर नहीं हैं जहां एफके-बाधाएं प्रदर्शन के मुद्दों का कारण बन रही हैं, तो मैं छुट्टी कहता हूं। रेफरेंसियल अखंडता की समस्याओं को साफ करना उन्हें जाने-माने से जोड़ने से कहीं अधिक कठिन हो सकता है ;-)
डेटा और डेटा वेयरहाउसिंग में मेरे 20+ वर्ष का अनुभव आपके साथ सहमत है ... परियोजनाएं बदलती/विकसित होती हैं और ग्राहक (और डेवलपर!) आसानी से धारणाओं को तोड़ने वाले परिवर्तनों को आसानी से पेश कर सकते हैं। एफके होने के नाते वास्तव में एक महान सुरक्षा नेट है - "साइकिल हेलमेंट" चट्टानों को एक सिमुलेशन के रूप में! विफल होने पर, मैं लोड प्रक्रिया के अंतिम "मान्य" चरण को प्रोत्साहित करता हूं जो कम से कम डेटा में बाधाओं/विशिष्टता की जांच करता है। महान जवाब, बिल। –
केवल पढ़ने-योग्य डीडब्ल्यू/डीएम में एफके बाधाओं को बनाने का एक बहुत अच्छा कारण है। हां, उन्हें वास्तव में केवल पढ़ने के लिए डीडब्लू स्वयं के दृष्टिकोण से जरूरी नहीं है, अगर आपका ईटीएल बुलेट प्रूफ इत्यादि है, लेकिन अनुमान लगाएं - डीडब्ल्यू में लोडिंग डेटा पर जीवन क्यों नहीं रुकता है। अधिकांश बीआई विश्लेषणात्मक/रिपोर्टिंग टूल स्वचालित रूप से अपने मॉडल (उदाहरण के लिए एसएसएएस टैब्यूलर मॉडल) बनाने के लिए आपके डीडब्ल्यू रिश्तों के बारे में जानकारी का उपयोग कर रहे हैं। मेरी विनम्र राय में यह अकेले ईटीएल प्रक्रिया के दौरान एफके बाधाओं को छोड़ने और पुनर्जीवित करने पर छोटे ओवरहेड से अधिक है।
हां, सर्वोत्तम अभ्यास के रूप में, अपने तथ्य सारणी पर एफके बाधाओं को लागू करें। SQL सर्वर में, NOCHECK का उपयोग करें। ओरेकल में हमेशा विश्वसनीय अक्षमता का उपयोग करें। यह गोदाम या मार्ट को संबंधों के बारे में जानने की अनुमति देता है, लेकिन इसे INSERT, अद्यतन, या हटाए गए कार्यों पर जांच न करें। स्टार ट्रांसफॉर्मेशन, ऑप्टिमाइज़ेशन इत्यादि एफके बाधाओं पर भरोसा नहीं कर सकते हैं जैसे कि वे इस्तेमाल किए गए प्रश्नों को बेहतर बनाने के लिए, लेकिन कोई नहीं जानता कि बीआई या ओलाप टूल्स का इस्तेमाल आगे की ओर या आपके गोदाम या मार्ट पर किया जाएगा। इनमें से कुछ उपकरण संबंधों को परिभाषित करने के लिए उपयोग कर सकते हैं। इसके अलावा, आपने कितने बदसूरत दिखने वाले गोदामों को कम या कोई बाहरी दस्तावेज के साथ देखा है और उन्हें इंजीनियर को रिवर्स करने की कोशिश करनी है? एफके को परिभाषित करना हमेशा इसके साथ मदद करता है।
डिज़ाइनर के रूप में हम कभी भी हमारे डेटा वेयरहाउस या मार्ट्स को स्वयं-दस्तावेज के रूप में नहीं लगते हैं जैसा हमें करना चाहिए। एफके परिभाषित करना निश्चित रूप से उसमें मदद करता है। अब, यह कहकर, यदि स्टार स्कीमा को एफके को परिभाषित किए बिना ठीक तरह से डिज़ाइन किया गया है, तो उन्हें पढ़ना और उन्हें समझना आसान है।
और ओरेकल तथ्य सारणी के लिए, हमेशा प्रत्येक एफके पर एक आयाम पर एक स्थानीय बिटमैप इंडेक्स परिभाषित करें। बस कर दो। इंडेक्सिंग एफके परिभाषित होने की तुलना में वास्तव में अधिक महत्वपूर्ण है।
+1। "विदेशी कुंजी डेटाबेस संशोधन के दौरान अखंडता बाधाओं को संरक्षित करने के लिए एक तंत्र है। यदि आपका डीडब्ल्यू केवल पढ़ने के लिए है, तो एफके की कोई ज़रूरत नहीं है ..." - बुल की आंख! –
कुछ डेटाबेस में स्टार या स्नोफ्लेक संरचित डेटा गोदामों के स्थानों में विशिष्ट अनुकूलन होते हैं। उन मामलों में, यहां तक कि केवल पढ़ने की स्थिति पर, विदेशी कुंजी वेयरहाउस को सतर्क करने के लिए सेवा कर सकती हैं कि तार कैसे संरचित किया जाता है - यह बताने के लिए कि तथ्य और आयाम क्या हैं।यहां तक कि सामान्यीकृत डेटाबेस में भी विदेशी कुंजी अनुकूलक को प्रभावित कर सकती है। मैं यह निर्धारित करने के लिए संघर्ष कर रहा हूं कि यह कब और कितना मायने रखता है, लेकिन यह निश्चित रूप से कुछ प्रभाव डालता है। – Chipmonkey