डेटाबेस की मॉडलिंग करते समय हमें कमजोर संस्थाओं का उपयोग कब करना चाहिए?

Question

यह मूल रूप से एक सवाल है कि कमजोर संस्थाएं क्या हैं? हमें उनका उपयोग कब करना चाहिए? उन्हें कैसे मॉडलिंग करनी चाहिए?

सामान्य संस्थाओं और कमजोर संस्थाओं के बीच मुख्य अंतर क्या है? क्या कमजोर संस्थाएँ डोमेन ड्रिवेन डिज़ाइन करते समय वस्तुओं को महत्व देती हैं?

प्रश्न को विषय पर रखने में मदद के लिए विकिपीडिया से लिया गया एक उदाहरण है जिसका उपयोग लोग इन प्रश्नों का उत्तर देने के लिए कर सकते हैं:

इस उदाहरण OrderItemमें एक कमजोर इकाई के रूप में मॉडलिंग की गई थी, लेकिन मैं यह नहीं समझ सकता कि इसे सामान्य इकाई के रूप में क्यों नहीं बनाया जा सकता।
एक और सवाल यह है कि यदि मैं ऑर्डर हिस्ट्री (यानी इसमें स्थिति में बदलाव) को ट्रैक करना चाहता हूं, तो क्या यह सामान्य या कमजोर इकाई होगी?

Answer 1

औपचारिक रूप से एक "कमजोर" इकाई में निम्नलिखित विशेषताएं हैं।

1.  It is existence-dependent on another entity, i.e., 
    it cannot exist without the entity with which it has a relationship.

2.  It inherits at least part of it's primary key from the entity to which 
    it is related. 


    i.e. -> A weak entity's primary key must be a composite key that includes 
       the primary key of the entity on which it is existence-dependent.

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

Comments

हममम तो मेरे उदाहरण के बारे में क्या? यहाँ OrderItemपर निर्भर है Orderक्योंकि कोई orderItemsभी बिना किसी के अस्तित्व में नहीं हो सकता है order, लेकिन मैं यह नहीं देख सकता कि मैं ItemLineNumberकेवल एक आइटम की पहचान करने के लिए उपयोग क्यों नहीं कर सकता ? वास्तव में मैं सिर्फ ItemLineNumberएक ऑटो बनाने intके लिए अद्वितीयता का बीमा और orderIDदो संस्थाओं को एक साथ जोड़ने के लिए एक विदेशी कुंजी का उपयोग कर सकते हैं ?!

— सांगो

यदि आप क्रमिक आईडी की विशिष्ट पहचान करने के लिए अपने OrderItem को परिभाषित करते हैं, और OrderId कुंजी का हिस्सा नहीं है, तो आप OrderItems को पहले के आदेश नागरिकों के रूप में मान रहे हैं और वास्तव में एक कमजोर इकाई नहीं है। यदि आप चाहते हैं तो आप ऑर्डर टेबल पर अन्य तालिकाओं को व्यक्तिगत रूप से FK कर सकते हैं; यह पहले से ही ऑर्डरइडम पर पाने के लिए ऑर्डरआईडी के लिए अनावश्यक है। दूसरी ओर, यदि आपने ऑर्डरआईएम के साथ ऑर्डरआईम और एक ऑर्डरआईडी (या समान) को ऑर्डर के लिए प्रासंगिक किया है, तो आपके पास एक कमजोर इकाई होगी और व्यक्तिगत लाइन आइटम केवल ऑर्डरआईड और सीक्वेंस का उपयोग करके रेफरेंसिबल होंगे। इरादा के अनुसार मॉडल का उपयोग।

— एड हेस्टिंग्स

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

— एड हेस्टिंग्स

Answer 2

एक OrderItemआदेश या उत्पाद के बिना अस्तित्व नहीं हो सकता। इसलिए यह कमजोर है क्योंकि यह निर्भरता इसे नियंत्रित करती है।

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

Answer 3

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

ईआर आरेख को व्यवसाय की आवश्यकता के अनुसार डिज़ाइन किया जाना है।

Answer 4

देखें, एक ऑर्डर में कई ऑर्डर आइटम (बहुविकल्पी विशेषता) हैं। इस प्रकार नियम के अनुसार हम अलग तालिका बनाते हैं।

अब, मान लें कि 2 ग्राहकों के पास समान ऑर्डर है। दोनों एक ही कीमत पर iPhone खरीदते हैं, छूट, एक ही तिथि, आदि। तो आदर्श रूप से iPhone के क्रम में दो सटीक tuples होना चाहिए क्रमिक संबंध में। लेकिन एक संबंध की बाधा के अनुसार, सभी टुपल्स अद्वितीय होने चाहिए। तो अब दो आइटम एक ही आइटम_लाइन_नंबर से संबंधित होने देता है। कोई समस्या नहीं है। अब ग्राहक के एक कैंसिल पर विचार करें। क्या iPhone ऑर्डर है। इसके अलावा item_line_number ट्यूपल को हटा दिया जाएगा। अब अन्य ग्राहक जिन्होंने आईफोन खरीदा है, वे भी M: 1 पत्राचार के कारण डिलीट हो जाते हैं। तो अंत में डेटाबेस असंगत है। इसलिए हम एक डिस्क्रिप्टर कुंजी का उपयोग करते हैं, जो क्रमबद्ध होगी। एक आईफ़ोन को हटाने का आदेश डेटाबेस में भ्रष्टाचार का कारण नहीं बनता है।