6

मैं निम्न तालिकाओं है:डिजाइन - छठे सामान्य रूप

Blogs { BlogName } 
BlogPosts { BlogName, PostTitle } 

ब्लॉग पोस्ट एक इकाई और एक ही समय जो (तीसरी घोषणा पत्र के अनुसार) 6NF के अनुसार अमान्य है पर एक रिश्ता मॉडलिंग कर रहा है।

6NF में, यह होगा:

Blogs { BlogName } 
Posts { PostTitle } 
BlogPosts { BlogName, PostTitle} 

अगर मैं एक दृश्य NBR (सिर्फ एक उदाहरण) द्वारा ब्लॉग पोस्ट ऑर्डर करने के लिए चाहता था, कि एक और तालिका

BlogPostsSorting { BlogName, PostTitle , SortOrder } 

मैं है किया जाएगा यह सही है?

+0

आपका प्रस्तावित 6 एनएफ स्कीमा मानता है कि कोई भी ब्लॉग कभी भी पोस्ट शीर्षक का पुन: उपयोग नहीं करता है। –

+0

सबसे पहले, जबकि दिनांक और डार्विन के पास 6 एनएफ पर बहुत कुछ कहना है, मुझे विश्वास नहीं है कि टीटीएम करता है। दूसरा, ध्यान दें कि हालांकि 6 एनएफ हमेशा प्राप्त करने योग्य है, यह हमेशा वांछनीय नहीं होता है। Darwen का संबंधपरक डेटाबेस सिद्धांत (मुफ्त डाउनलोड) का परिचय, 7.3 6 एनएफ अपघटन का आकलन, पीपी 180-2। – onedaywhen

उत्तर

4

sqlvogel सही in this answer है।

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

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

चाहे आपको सॉर्टिंगऑर्डर रिवर को अतिरिक्त के रूप में चाहिए, इस पर निर्भर करता है कि ब्लॉगपोस्ट्स हो सकते हैं या नहीं, जिसके लिए कोई सॉर्टिंग ऑर्डर की आवश्यकता नहीं है। यदि ऐसा नहीं हो सकता है, तो आपके सॉर्टिंगऑर्डर रिवर बस BlogPosts को प्रतिस्थापित करता है। यदि वहां हो सकता है, तो आप दो relvars हो सकता है; या वैकल्पिक रूप से आप अभी भी सॉर्टिंगऑर्डर रिवरर कर सकते हैं, और डमी मान (उदा।, हमेशा -1) का उपयोग करके ऑर्डर किए बिना पोस्ट के मामले के माध्यम से अपना रास्ता हैक कर सकते हैं।

+0

BlogPostsSorting {BlogName, PostTitle, SortOrder}। यदि यह एक कुंजी {BlogName, PostTitle} प्लस एक गैर-कुंजी विशेषता {SortOrder} है, तो यह 6 एनएफ है। (ओह रुको, क्या आप किसी संभावित दूसरी कुंजी {BlogName, SortOrder} के प्रभाव का जिक्र कर रहे थे ???मुझे नहीं लगता कि यह कुछ भी प्रभावित करता है। रिवर अभी भी nonloss decomposable नहीं है।) –

+0

टिप्पणी यह ​​टिप्पणी थी कि यह टिप्पणी गायब हो गई प्रतीत होती है। –

6

आपकी टेबल की चाबियाँ क्या हैं? कॉलम नामों के आधार पर मुझे लगता है कि BlogPosts की कुंजी केवल {BlogName, PostTitle} हो सकती है। उस स्थिति में BlogPosts पहले से ही 6 एनएफ में है - इसमें कोई गैर-प्राइम विशेषता नहीं है और इसलिए गैर-विघटित नहीं हो सकता है। ब्लॉग रिवर और पोस्ट रिवरर अनावश्यक होंगे - आपको उनकी आवश्यकता नहीं है।

ब्लॉग पोस्ट (तीसरी घोषणा पत्र के अनुसार)

आप मुझे बता सकते हैं जहां आपको लगता है तीसरा घोषणा पत्र का कहना है कि एक इकाई और एक ही समय जो 6NF के अनुसार अमान्य है पर एक रिश्ता मॉडलिंग है यह अमान्य है मुझे यकीन है कि यह नहीं है लेकिन मैं जानना चाहता हूं कि आप इस तरह के निष्कर्ष पर कैसे पहुंचे।

+0

टीटीएम के पास 6 एनएफ (यह क्यों होगा?) के बारे में कुछ भी स्पष्ट नहीं है और क्रिस डेट जानबूझकर 'इकाई' शब्द का उपयोग करने से बचाता है। – onedaywhen

+1

हालांकि सामान्यीकरण से संबंधित नहीं, यदि हम ब्लॉग रिवर को समाप्त कर देते हैं तो एक व्यावहारिक डिज़ाइन समस्या होगी: हम पहले ब्लॉग पर निर्णय लेने तक ब्लॉग पंजीकृत नहीं कर पाएंगे। मुझे लगता है कि यह बिंदु @ एरविन स्मोउट बनाता है, मानते हैं कि वे * अंतर्निहित * बाधाओं को ले रहे हैं। – onedaywhen

संबंधित मुद्दे