श्रेणी के बीच निर्णय लेने वाला सुपरटाइप / उपप्रकार: पूर्ण विच्छेद या अपूर्ण अतिव्यापी

Question

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

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

• प्रो: एक सामान्य क्षेत्र पर आधारित रिकॉर्ड्स का चयन करना, जैसे Hostname, या LocationID आसान है।
• प्रो: कोई अशक्त फ़ील्ड नहीं।
• Con: टेबल्स जिन्हें एक विशेष उपकरण के लिए CRUD संचालन में शामिल किया जाना चाहिए, स्पष्ट नहीं हैं, और भविष्य के DBA को भ्रमित कर सकते हैं।

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

• प्रो: यह तुरंत स्पष्ट है कि कौन सी तालिकाओं के लिए CRUD संचालन के लिए उपयोग किया जाता है।
• प्रो: केवल CRUD संचालन के लिए एक तालिका का उपयोग करना होगा।
• Con: सामान्य उप-प्रकार फ़ील्ड के आधार पर चयन रिकॉर्ड के लिए सभी तालिकाओं को संयोजित करने की आवश्यकता होती है, उदाहरण के लिए Hostname या LocationID द्वारा खोज करना।

दोनों स्थितियों में, ClassDiscriminator फ़ील्ड को उप-प्रकार तालिकाओं में एक CHECK बाधा के साथ उपयोग करने के लिए रखा जाता है ताकि यह नियंत्रित किया जा सके कि कौन से प्रकार डाले जा सकते हैं।

क्या ऐसी कोई सिफारिशें हैं जिसके लिए डिजाइन बेहतर है, या यह पूरी तरह से एक राय है और डेटाबेस के इच्छित उद्देश्य पर निर्भर है?

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

किसी भी इनपुट के लिए अग्रिम धन्यवाद। कृपया पूछें कि क्या कोई अतिरिक्त जानकारी चाहिए।

Comments

इसी तरह के प्रश्न के लिए dba.stackexchange.com/questions/15199/… देखें जिसका उत्तर दिया गया था

— स्टीफन सेन्कोमागो मूस

Answer 1

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

यह वास्तव में जटिल उपप्रकार के साथ किया गया है (कोर्ट केस प्रबंधन प्रणाली पर आवेदक और वाक्य, संयुक्त-जोखिम वाले वाणिज्यिक बीमा अनुबंध संरचनाओं को अलग करना) मुझे लगता है कि मेरे पास इस पर कुछ टिप्पणियां हैं। कुछ महत्वपूर्ण कोने मामले हैं:

• यदि उप-वर्गों में डेटाबेस फ़ील्ड की कुल संख्या अपेक्षाकृत कम है (कहते हैं: 100 से कम) या उप-वर्गों के बीच महत्वपूर्ण समानता है तो अलग-अलग भौतिक तालिकाओं में से उप-वर्गों को विभाजित करना संभवतः बहुत कम है। यह प्रश्नों और खोजों की रिपोर्टिंग के लिए महत्वपूर्ण ओवरहेड जोड़ देगा। ज्यादातर मामलों में यह एकल तालिका के लिए सबसे अच्छा है और आवेदन के भीतर अपने उपप्रकार का प्रबंधन करता है। (शायद आपकी समस्या के सबसे करीब)

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

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

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

• कुछ ओ / आर मैपर्स केवल उप-वर्गों के प्रबंधन के लिए एक विशेष दृष्टिकोण का समर्थन कर सकते हैं।

ज्यादातर मामलों में एक DB स्कीमा में भौतिक उप-प्रकार टेबल एक समस्या की तलाश में एक समाधान है, क्योंकि वे संभावित रूप से अवांछनीय दुष्प्रभाव हैं।

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

Comments

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

— TheSecretSquad

@reallythecrash - अशक्त क्षेत्रों के लिए ओवरहेड प्रति फ़ील्ड लगभग एक बाइट है, इसलिए संसाधन उपयोग के संदर्भ में यह उपवर्ग तालिकाओं के खिलाफ शामिल होने की तुलना में बहुत कम ओवरहेड है। वास्तव में एकमात्र दोष यह है कि तालिका बहुत सारे नल के साथ थोड़ी गड़बड़ दिखेगी।

— कंसर्नडऑफटुनब्रिजवेल्स

@reallythecrash - यदि आप वास्तव में चाहते हैं (और आपका DBMS इसका समर्थन करता है - आपने निर्दिष्ट नहीं किया है कि आप क्या उपयोग कर रहे हैं) तो आप प्रकार के अवरोधक के आधार पर चेक अवरोधों को स्थापित कर सकते हैं जो कि उपयुक्त क्षेत्रों पर अशक्त / नहीं-शून्य को लागू करते हैं। कक्षा।

— कंसर्नडऑफटुनब्रिजवल्स

Answer 2

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

मुझे लगता है कि आप पाएंगे कि डिवाइस के प्रकार एक ईएवी पैटर्न को वारंट करने के लिए काफी बड़े होंगे जैसा कि दूसरे उत्तर में बताया गया है। डेविड हे पुस्तक I संदर्भ इस पैटर्न को बहुत प्रभावी ढंग से शामिल करता है। हालाँकि, यदि उप-प्रकारों की संख्या कम है, तो आप कई अशक्त स्तंभों के साथ केवल सुपर प्रकार की तालिका को लागू करने का निर्णय लेने के लिए अंगूठे का एक नियम कर सकते हैं, केवल उप-प्रकार की तालिकाएं डुप्लिकेट किए गए कॉलम के साथ, या दोनों। यदि प्रत्येक उप-प्रकार अपनी विशेषताओं में बहुत भिन्न होता है और सुपर प्रकार के स्तर पर कोई संबंध नहीं है, तो आप केवल उप-प्रकार तालिकाओं के साथ जा सकते हैं। यदि विपरीत सत्य है, तो आप केवल सुपर-प्रकार की तालिकाओं के साथ जा सकते हैं। यदि कोई मिश्रण है, तो दोनों को लागू करें।

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

Comments

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

— TheSecretSquad

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

— TheSecretSquad

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

— टोड एवरेट

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

— टॉड एवरेट

Answer 3

एक उत्पाद इन्वेंट्री नहीं है। इन्वेंटरी और उत्पाद अलग हैं।

एक उत्पाद वास्तव में एक उत्पाद का एक विनिर्देश है, भौतिक वस्तु नहीं है।

भौतिक चीज एक एसेट है जो कंपनी का मालिक है (या स्टोर)। आपके पास ऐसी संपत्तियां हो सकती हैं, जिन्हें आप क्रम संख्या (असतत संपत्ति) या ऐसी संपत्तियों से ट्रैक करते हैं, जिन्हें आप केवल मात्रा (इन्वेंट्री एसेट) द्वारा ट्रैक करते हैं।

मैं सिल्वरस्टोन के डेटा मॉडल संसाधन बुक वॉल्यूम 1 को देखूंगा। उनके पास गर्व, फीचर्स, प्राइसिंग, इन्वेंट्री के लिए एक अच्छा स्कीमा है। इससे आपका काफी समय बचेगा।

Comments

सिल्वरस्टन के डेटा मॉडल संसाधन बुक का उल्लेख करने के लिए +1 बिंदु। देख लिया और यह ज्ञानवर्धक था। विस्तार से और पढ़ने के लिए उत्सुक, जैसा कि मुझे लगता है कि डेटा मॉडलिंग प्रश्नों के साथ किसी को भी होना चाहिए। धन्यवाद।

— TheSecretSquad

Answer 4

मेरे द्वारा पूछे गए प्रश्नों में से एक यह है कि आप अपने इन्वेंट्री आइटम की विभिन्न विशेषताओं पर नज़र क्यों रख रहे हैं? - या, विशेष रूप से, आप इस विशेषता जानकारी के साथ क्या कर रहे हैं?

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

डिवाइस इन्वेंट्री सिस्टम के डिजाइन के बारे में इस उत्तर पर एक नज़र डालें और उत्पाद कैटलॉग सिस्टम के डिज़ाइन के बारे में यह उत्तर देखें कि ईएवी दृष्टिकोण ईएवी के जोखिम क्या हैं और कैसे के बारे में चर्चा के साथ आपके आवेदन को सरल बना सकता है। न्याय करें कि क्या वे जोखिम आपके विशिष्ट आवेदन पर लागू नहीं हो सकते हैं।

Comments

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

— TheSecretSquad