मुझे लगता है कि ड्राफ्ट मॉडल (निम्नलिखित 6NF
और 3NF) आपकी मदद करेगा।
मैंने 'shop' कीवर्ड को हटाकर नामकरण परंपरा को सरल बनाया है।
(इसके अलावा दुकान इकाई एक अलग अवधारणा AKA SaaS का नेतृत्व कर सकती है)
SqlFiddle डेमो
टिप्पणियों में प्रश्नों के बारे में:
हाँ, सरोगेट आइडेंटिफ़ायर
का उपयोग करना एक सामान्य पैटर्न है अपनी मेजों पर। जैसा कि आप लेख में देख सकते हैं, यह इसके पेशेवरों और विपक्षों के साथ आएगा।
उदाहरण के लिए, प्रश्न में, आप ProductSpecification की वह प्राथमिक कुंजी देखेंगे तालिका ProductTypeOptions . की एक संरचना है , OptionValue और Product विदेशी कुंजियाँ।
इस बीच अन्य तालिकाओं की प्राथमिक कुंजी जैसे OptionValue एक संयुक्त कुंजी है (OptionId + ValueName )
ऐसा लगता है कि एक ID के लिए जीवन अधिक आसान हो जाएगा प्रत्येक तालिका में प्राथमिक कुंजी के रूप में फ़ील्ड, हाँ यह है लेकिन एक डेटाबेस डिज़ाइनर के रूप में आप कुछ मूल्यवान खो देंगे, व्यावसायिक तर्क .
वर्तमान डिज़ाइन में आप उत्पाद-विनिर्देश तालिका में इन बाधाओं को प्राप्त कर सकते हैं, वे आपके व्यावसायिक तर्क का हिस्सा दिखाएंगे:
ProductSpecificationपर प्रतिबंध की जांच करें{OptionValue.optionId = productTypeOption.optionId}जो "साइज़" के लिए "सफ़ेद" जैसे मान को असाइन किए जाने से रोकेगा।ProductSpecificationपर प्रतिबंध की जांच करें{product.productTypeId = productTypeOption.productTypeId}जो "नाइक" जैसे उत्पाद को "कार" के उत्पाद विनिर्देशों को असाइन किए जाने से रोकेगा।
यदि आप सरोगेट आइडेंटिफ़ायर का उपयोग करते हैं तो आप अपने डेटा बेस के अंदर इस प्रकार की बाधाओं को नहीं रख सकते हैं (इसे आज़माएं)।
उन्हें प्राप्त करने के लिए आपके आवेदन कार्यान्वयन के अंदर अतिरिक्त काम करने की आवश्यकता होगी।
BTW सरोगेट आइडेंटिफ़ायर का उपयोग करें, डेटा संगतता जांचें
, यदि अधिक रुचि हो तो देखें प्राथमिक कुंजी चुनना:प्राकृतिक या सरोगेट
.
ऐसा लगता है कि "नाइके" के "मेन्स शू" में मूल्य, स्टॉक और अधिभार होना चाहिए, इसलिए वे Product की प्राकृतिक संपत्ति हैं। टेबल।
