सही या गलत: प्रत्येक तालिका के लिए अच्छी कुंजी कॉल करने के लिए अच्छी डिज़ाइन कॉल, यदि कुछ और नहीं है, तो चल रहा पूर्णांक

Question

किराने की दुकान परिदृश्य पर विचार करें (मैं इसे बना रहा हूं) जहां आपके पास तथ्य रिकॉर्ड हैं जो बिक्री लेनदेन का प्रतिनिधित्व करते हैं, जहां तथ्य तालिका के स्तंभों में शामिल

SaleItemFact Table 
------------------ 
CustomerID 
ProductID 
Price 
DistributorID 
DateOfSale 
Etc 
Etc 
Etc 

यहां तक ​​कि अगर वहाँ मेज जब आप सभी चाबियाँ पर विचार में डुप्लिकेट हैं, मैं संघर्ष होता है कि एक किराए संख्यात्मक कुंजी (यानी पहचान स्तंभ) चल ऊपर बनाया जाना चाहिए, जैसे , ट्रांज़ेक्शन संख्या प्रकार पूर्णांक।

मैं किसी को, उनका तर्क है कि एक तथ्य तालिका एक अद्वितीय कुंजी नहीं हो सकता है (हालांकि मैं एक आविष्कार और बर्बाद 4 बाइट चाहते हैं, लेकिन कैसे एक आयाम तालिका के बारे में?

Answer 1

पहले सामान्य रूप में प्रत्येक तालिका पर प्राथमिक कुंजी की आवश्यकता होती है। तो यह अच्छी डेटाबेस डिजाइन के लिए आवश्यक न्यूनतम है। प्राथमिक कुंजी के लिए आप जो चुनते हैं वह बहुत बहस के लिए खुला है। लेकिन डेटाबेस डिजाइन के लिए पहला सामान्य रूप नहीं है।

Answer 2

एक कारण यह कई के बीच देख सकते हैं करने के लिए, प्रति पंक्ति एक अद्वितीय कुंजी (डेटा से निर्मित, या अन्यथा) उस विशिष्ट पंक्ति में अद्यतन या हटाने की सुविधा है।

किसी भी मामले में, यह प्रश्न मूर्खतापूर्ण है, क्योंकि वास्तव में कोई इंजीनियरिंग व्यापार नहीं है - हिस्सेदारी पर। कुंजी रखने के लिए कोई वास्तविक प्रस्तावित लाभ नहीं है, तो क्या बात है? सच/हाँ, पंक्तियों में अद्वितीय पहचानकर्ता होना चाहिए।

Answer 3

डेटा गोदामों के लिए, तथ्य सारणी में अक्सर एक समग्र प्राथमिक कुंजी होती है, आमतौर पर आपके आयाम तालिकाओं के लिए सभी विदेशी कुंजी का समग्र होता है।

आपके तथ्य सारणी में कोई प्राथमिक कुंजी नहीं है, क्योंकि वे अक्सर जगह बर्बाद करने के अलावा कोई उद्देश्य नहीं देते हैं - और बड़े डाटावायरहाउस के लिए जगह काफी बड़ी हो सकती है। हालांकि आपकी आयाम सारणी में प्राथमिक कुंजी होगी।

यदि आप अपनी किराने की दुकान के OLTP भाग के बारे में बात कर रहे हैं, तो आप सामान्य रूप से मानक OLTP डेटाबेस डिज़ाइन का पालन करेंगे, अपनी टेबल को सामान्यीकृत करेंगे और प्राथमिक कुंजी प्रदान करेंगे।

Answer 4

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

इसे छोड़कर, आपको अपेक्षाकृत कम लागत (4 बाइट्स) पर आईडी के आधार पर आसानी से चयन, अद्यतन, हटाने में सक्षम होने का लाभ प्राप्त होता है। जो तर्कसंगत रूप से, तालिका जितनी बड़ी होगी, उतनी ही उपयोगी आईडी होगी। तो 4 बाइट कम है और एक बिंदु के कम हो जाता है बड़ी मेज :-)

Answer 5

अपने प्रश्न Datawarehousing किया जा रहा है क्योंकि:

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

• फैक्ट टेबल ज्यादातर (लगभग हमेशा) में प्राथमिक कुंजी होती है जो दो या दो से अधिक विदेशी कुंजी का संयोजन होता है।

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

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