सामान्यीकरण: क्या स्थिर, संख्यात्मक मानों को एक वर्ष की तरह अपनी तालिका में विभाजित करना अनिवार्य माना जाता है?

Question

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

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

इस पर विचार?

संपादित करें: इस StackOverflow पर पोस्ट करने के लिए। क्या कोई इसे हटाने के लिए वोट कर सकता है या इसे ध्यान में रख सकता है?

Comments

ऐसा क्यों? यह यहाँ एक अच्छा फिट की तरह लगता है।

— लेह रिफ़ेल

जो प्रश्न मैं पूछना चाहता हूं, क्या आप इसे सामान्यीकरण या वास्तविक उत्पादन जरूरतों के बारे में पूछ रहे हैं? उत्पादन के लिए मैं पूछूंगा कि क्या यह एक वैध बात है?

— jcolebrand

Answer 1

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

Table: game_titles

game_title                      year_first_released
--
The first game                  1998
The second game                 1999
Best game: the third one        2001
The fourth game                 2003
Forty-two, the end of games     2011

आप मूल्यांकन करते हैं कि यह 2NF में है या नहीं यह प्रश्न आप स्वयं पूछ रहे हैं।

प्रश्न: सबसे पहले, क्या यह 1NF में है?

A: हाँ, यह है।

प्रश्न: प्रमुख विशेषताएँ (विशेषताएँ जो उम्मीदवार कुंजी का हिस्सा हैं) क्या हैं?

A: "game_title" एकमात्र प्रमुख विशेषता है।

प्रश्न: गैर-प्रमुख विशेषताएँ क्या हैं?

A: "year_first_released" एक ही है।

प्रश्न: क्या "year_first_released" कार्यात्मक रूप से पूरे "game_title" पर निर्भर है, या इसके केवल एक हिस्से पर?

एक: एकमात्र उम्मीदवार कुंजी, "game_title", एक एकल स्तंभ है; यह भी भागों नहीं है। तो "year_first_released" कार्यात्मक रूप से पूरे "game_title" पर निर्भर है।

Voilà। आपने 2NF पाया है।

आप पहले औपचारिक शब्दों में से कुछ के माध्यम से पूछ सकते हैं कि क्या यह 1NF में है, और फिर इस प्रश्न का उत्तर दें।

प्रश्न: क्या कोई समग्र उम्मीदवार कुंजी हैं?

A: नहीं।

Voilà। आपने फिर से 2NF पाया है।

परिभाषा के अनुसार, तालिका के लिए 2NF का उल्लंघन करने के लिए, इसके पास कम से कम एक उम्मीदवार की चाबी होनी चाहिए जिसमें एक से अधिक कॉलम हों।

यहां आपके मित्र की राय को अस्वीकार करने के आपके कारण हैं।

• एक वर्ष सिर्फ एक गैर-आदिम संख्यात्मक मान है।
• एक वर्ष अपने स्वभाव से स्थिर है।
• एक वर्ष अपने स्वयं के पहचानकर्ता के रूप में कार्य करता है।
• वर्षों की एक तालिका अतिरिक्त रखरखाव का परिचय देती है।
• वर्षों की एक तालिका में अतिरिक्त पंक्तियाँ हो सकती हैं जो संदर्भित नहीं हैं।
• वर्षों की एक तालिका डेटाबेस का आकार बढ़ाती है।

इन कारणों में से कोई भी कुछ भी नहीं है कि क्या तालिका 2NF में है।

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

ओह, और वह दो-स्तंभ तालिका जो मैंने ऊपर प्रदान की है - यह 5NF में है।

Comments

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

— मार्क स्टोरी-स्मिथ

Answer 2

किसी भी विशेषता के लिए एक अलग तालिका बनाने का सामान्यीकरण से कोई लेना-देना नहीं है। 2NF, 3NF, BCNF, 4NF, 5NF सभी गैर-प्रमुख निर्भरता को खत्म करने से संबंधित हैं। यदि आप किसी एकल विशेषता को एक नई तालिका में निकालते हैं और उसे किसी विदेशी कुंजी विशेषता से प्रतिस्थापित करते हैं, तो तालिका में निर्भरता तार्किक रूप से पहले की तरह ही होगी - इसलिए तालिका का संशोधित संस्करण इससे कम या अधिक सामान्यीकृत नहीं है पहले थी।

Comments

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

— jcolebrand

@jcolebrand: आप जो कहते हैं, उससे सहमत हैं। फिर भी प्रश्न का उत्तर एक ही है: आप इसे करते हैं या नहीं इसका सामान्यीकरण से कोई लेना देना नहीं है।

— nvogel

मैं सहमत हूँ। जैसा कि मैंने कहा, मेरा आधा-अधूरापन था "मुझे ऐसा लगता है जैसे ओपी यहाँ कुछ याद कर रहा है" ... क्योंकि मुझे यकीन नहीं है कि उस अवधारणा के साथ कहाँ जाना है।

— jcolebrand

Answer 3

मेरे दृष्टिकोण से एक अलग वर्ष की तालिका केवल तभी समझ में आएगी जब "रिलीज़ वर्ष" कैलेंडर वर्ष नहीं होगा, लेकिन उदाहरण के लिए एक वित्तीय वर्ष जो कई कैलेंडर वर्षों (जैसे कि अक्टूबर से अक्टूबर तक) हो सकता है।

इसके बाद वित्तीय वर्ष की परिभाषा (वास्तविक शुरुआत और अंतिम तिथि) की तालिका बनेगी

Comments

+1 आपको केवल एक तालिका की आवश्यकता है अगर इसमें विशेषताएँ होने वाली हैं :)

— जैक कहते हैं कि topanswers.xyz की कोशिश करें

Answer 4

से http://en.wikipedia.org/wiki/Second_normal_form :

1NF तालिका 2NF में है यदि और केवल यदि, किसी भी उम्मीदवार को कुंजी K और किसी भी विशेषता A को दिया जाता है जो उम्मीदवार कुंजी का घटक नहीं है, तो A केवल K के भाग के बजाय पूरे K पर निर्भर करता है।

आपने यह नहीं बताया कि वर्ष उम्मीदवार की कुंजी का हिस्सा है या नहीं, लेकिन मुझे यकीन नहीं है कि यह मायने रखता है, क्योंकि किसी भी मामले में 2 एनएफ संतुष्ट होगा जहां तक ​​वर्ष का संबंध है।

व्यावहारिक स्तर पर आपके द्वारा सूचीबद्ध सभी कारणों से वर्ष को अलग करना एक बुरा विचार है।

Answer 5

मैं इसके आकार के कारण अलग-अलग तालिका के विरुद्ध तर्क को नापसंद करता हूं या इसमें अप्रयुक्त पंक्तियाँ होंगी। यहां तक ​​कि अगर आप 1000 साल इस तालिका में डालते हैं, तो आकार नगण्य होगा।

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

कैलेंडर तालिका के लिए तर्क अलग-अलग हो सकता है, जहां प्रत्येक पंक्ति एक दिन का प्रतिनिधित्व करती है और अन्य विशेषताओं (सप्ताह का दिन, यूटीसी ऑफसेट, चाहे वह छुट्टी हो, आदि) हो सकती है।

लेकिन साल अकेले? नहीं, मुझे कोई लाभ नहीं दिखता है ... और जैसा कि दूसरों ने बताया है, उनसे पूछें कि उन्हें क्यों लगता है कि यह अधिक सामान्यीकृत है? या उन्हें क्या हासिल हुआ? यदि आप प्रश्नों को लिखना पसंद कर रहे हैं

WHERE othertable.year = 2011

के बजाय

WHERE dt >= 20110101 AND dt < 20120101

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

Answer 6

मैं पूरी तरह से कैटकॉल के जवाब से एक बिंदु को छोड़कर सहमत हूं: "वर्ष" हमेशा एक आदिम मूल्य नहीं हो सकता है, लेकिन मुझे लगता है कि यह एक डेटाबेस डिजाइन एक की तुलना में व्यावसायिक तर्क अवधारणा का अधिक है।

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

इस विशिष्ट मामले के लिए, मैं फिर से कहता हूं कि कैटकॉल का उत्तर सही है, लेकिन सिर्फ यह बताना चाहता था। (क्षमा करें, अभी तक टिप्पणी के लिए पर्याप्त प्रतिनिधि नहीं है।)