पहला सामान्य रूप: निश्चित परिभाषा

Question

मैं फर्स्ट नॉर्मल फॉर्म का एक निश्चित संस्करण प्राप्त करने की कोशिश कर रहा हूं। मैंने जो कुछ पढ़ा है, वह थोड़ा अलग है।

तिथि जैसे कई अधिकारियों का कहना है कि परिभाषा के अनुसार एक संबंध हमेशा पहले सामान्य रूप में होता है, जबकि अन्य आवश्यकताओं की एक सूची देते हैं। इसका मतलब है कि 1NF के लिए शून्य से लेकर कई आवश्यकताएं हैं।

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

मैं विशेष रूप से 1NF पर ध्यान केंद्रित कर रहा हूं क्योंकि यह SQL डेटाबेस से संबंधित है। प्रश्न यह है: यह सुनिश्चित करने के लिए कि कौन सी संपत्तियों की आवश्यकता है, एक तालिका पहले सामान्य रूप में है?

---

कई अधिकारियों का सुझाव है कि यदि एक तालिका किसी संबंध का प्रतिनिधित्व करती है , तो यह पहले से ही 1NF में है। यह 1NF की परिभाषा को एक संबंध की परिभाषा में वापस धकेलता है।

यहाँ 1NF में तालिका के कुछ गुण हैं:

• स्तंभ आदेश महत्वहीन है [1]
• पंक्तियों का आदेश महत्वहीन है
• सभी पंक्तियाँ समान लंबाई की हैं (यानी, पंक्ति डेटा कॉलम हेडर से मेल खाता है)
• कोई डुप्लिकेट पंक्तियाँ नहीं हैं (यह एक सरोगेट प्राथमिक कुंजी का उपयोग करके गारंटी दी जा सकती है, लेकिन पीके स्वयं की आवश्यकता नहीं है)
• कोई दोहराए जाने वाले कॉलम नहीं हैं
• प्रत्येक स्तंभ में एक एकल मान (परमाणु) होता है

[१] तकनीकी रूप से विशेषताएँ अनियंत्रित हैं, लेकिन एक तालिका में, पंक्ति डेटा स्तंभ हेडर के समान क्रम में होना चाहिए। हालाँकि, वास्तविक आदेश महत्वहीन है।

पर एक से अधिक डेटा :

परमाणु डेटा की अवधारणा यह है कि एक आइटम को और अधिक नहीं तोड़ा जा सकता है। यह अवधारणा इस योग्य है कि यद्यपि तकनीकी रूप से सब कुछ विज्ञापन nauseum से तोड़ा जा सकता है , प्रश्न में डेटा व्यावहारिक रूप से किसी भी तरह से टूट नहीं सकता है , यह इस बात पर निर्भर करता है कि डेटा का उपयोग कैसे किया जाएगा।

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

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

निर्भरता

पंक्तियों के बीच कोई संबंध नहीं होना चाहिए, इसके अलावा वे एक ही हेडर के अनुरूप हैं।

स्तंभों के बीच भी कोई संबंध नहीं होना चाहिए, लेकिन मेरा मानना ​​है कि यह उच्च सामान्य रूपों का विषय है।

सवाल यह है कि 1NF की परिभाषा में उपरोक्त में से कितना है? क्या स्वतंत्र पंक्तियाँ भी इसमें आती हैं?

Answer 1

प्रारंभिक

1971 में सामान्य रूप की परिभाषा ("डेटा बेस रिलेशनल मॉडल के आगे के सामान्यीकरण की प्रस्तुति से" को पहले सामान्य रूप के रूप में जाना जाता है ) और रिलेशनल प्रतिमान की परिभाषा को 1970 में वैज्ञानिक पत्र में प्रकाशित किया गया था जो एक मजबूत प्रदान करता है डेटाबेस प्रशासन के अभ्यास के लिए आधार, यानी, "बड़े साझा डेटा बैंकों के लिए डेटा का एक संबंधपरक मॉडल" (आरएम विचित्रता के लिए) डॉ। ईएफ कोडड द्वारा बनाया गया , जो एक ट्यूरिंग पुरस्कार प्राप्तकर्ता है और संबंधपरक ढांचे के संबंध में प्राधिकरण है।

हाँ, डॉ। कॉड के पाठ के बारे में बहुत सारी व्याख्याएँ, व्याख्याएँ, खुलासे, विचलन और राय हैं, लेकिन मैं व्यक्तिगत रूप से मूल स्रोत से चिपके रहना पसंद करता हूँ और मेरा सुझाव है कि आप इसका विश्लेषण स्वयं करें ताकि आप अपना निष्कर्ष निकाल सकें।

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

पूर्वोक्त आवेगों पर बल देने का कार्य एक धर्मार्थ शब्द के लिए अनुचित होगा - अनुचित , क्योंकि इसे काफी दूर से देखने पर, इस मद सामग्री को कुछ शोधन और विस्तार की आवश्यकता होती है, हाँ, लेकिन कार्य का मुख्य शरीर से ठोस था। बहुत ही गर्भाधान (और, वास्तव में, डॉ। कोडड ने अधिकांश - सभी ऐसे परिशोधन और स्वयं विस्तार नहीं किए हैं)।

मैं ज्ञान के इस असाधारण स्रोत के बारे में मेरी समझ को मजबूत करने के लिए लगातार आरएम का पुनर्मिलन जारी रखता हूं (और मेरा यह सम्मान हर रेयर पर बढ़ता रहता है); इसका उद्देश्य दिग्गजों के कंधों पर खड़ा होना है।

संबंधों और तालिकाओं

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

आरएम में स्वाभाविक रूप से ऐसे गुण होते हैं जो एक तालिका को यह निर्धारित करना होगा कि क्या यह वास्तव में किसी संबंध को चित्रित करता है, लेकिन मैं उनके बारे में एक अनौपचारिक और सरल व्याख्या की पेशकश करूंगा (एक और, हाँ!)।

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

एक तालिका होने के नाते जो वास्तव में एक संबंध का प्रतिनिधित्व करता है, महत्वपूर्ण है, क्योंकि जब यह एक संबंधपरक प्रकार के हेरफेर संचालन से गुजरता है, तो परिणाम, फिर से, एक तालिका जो एक संबंध का प्रतिनिधित्व करती है। इस तरीके से, उक्त तालिका का व्यवहार अनुमानित है ।

परमाणु डोमेन (कॉलम)

आरएम के पहले खंडों में, डॉ। कोडड ने कुछ अवधारणाओं को पेश करने के लिए संबंधों के कई नमूने प्रस्तुत किए हैं; इसलिए, परमाणु डोमेन के अर्थ को समझने के लिए , हम आरएम से निम्नलिखित अंश के साथ शुरू करते हैं जो कुछ प्रासंगिक बिंदुओं का विवरण देता है:

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

इस प्रकार, कोई यह कह सकता है कि उपरोक्त दोनों प्रकार के संबंध दो प्रकारों में से एक में फिट होते हैं, या तो कहें कि A या तरह B :

• Kind A केवल समूह (तालिकाएँ), जो उन डोमेन (स्तंभों) के साथ संरचित होते हैं, जिनमें उनके प्रत्येक टुपल्स (पंक्तियों) में विशेष रूप से सरल मान होते हैं , अर्थात, ऐसे डोमेन (कॉलम) में संबंध (तालिकाएँ) मान के रूप में नहीं होते हैं, जिनमें इस संदर्भ का अर्थ है कि मूल्य परमाणु हैं क्योंकि उन्हें नए संबंधों (तालिकाओं) में क्रमिक रूप से विघटित नहीं किया जा सकता है । इसलिए, इस वर्ग के संबंध सामान्यीकृत हैं , अर्थात, वे 1NF का अनुपालन करते हैं, उनका फॉर्म वांछनीय है।

• Kind B को विशेष रूप से उन संबंधों (तालिकाओं) द्वारा एकीकृत किया जाता है जिनमें एक या एक से अधिक डोमेन (कॉलम) होते हैं जो संबंध को प्रत्येक संबंधित टपल (पंक्ति) में मान के रूप में रखते हैं, और यह दर्शाता है कि कहा गया है कि मूल्य गैर - परमाणु हैं क्योंकि वे बाद में नए संबंधों में टूट सकते हैं (टेबल्स), यानी, वे डीकोमोज़ेबल हैं । इस प्रकार, इस प्रकार के संबंध असामान्य हैं, अर्थात, वे 1NF का उल्लंघन करते हैं, वे अवांछनीय रूप में हैं।

मानकीकरण

डॉ। कोडड निम्नलिखित पैराग्राफ के साथ आरएम में सामान्यीकरण के बारे में अनुभाग का परिचय देता है:

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

फिर वह दिखाने के लिए आगे बढ़ता है:

1. संबंधों का एक समूह जहां एक अप्राकृतिक होता है (इसमें ऐसे डोमेन होते हैं जिनमें संबंध होते हैं मान के रूप में, अर्थात, वे गैर-भौतिक हैं (यानी, वे गैर-सरल हैं)

2. संबंधों का एक समूह जो एक सामान्यीकृत है (यानी, एक जो विघटित हो गया था; अर्थात, जो संबंध मूल्यवान डोमेन को सरल लोगों में तोड़ दिया गया था जो दर्शाता है कि वे परमाणु हैं)

और फिर वह अप्राकृतिक से सामान्यीकृत संबंध प्राप्त करने की प्रक्रिया का वर्णन करता है।

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

सच में, वह इंगित करता है:

आगे एक सामान्य प्रकार के संचालन संभव हैं। इस पत्र में इन पर चर्चा नहीं की गई है।

और कहा कि संचालन, अर्थात, दूसरा और तीसरा सामान्य रूप (2NF और 3NF) वास्तव में "डेटा बेस रिलेशनल मॉडल के आगे सामान्यीकरण" में विस्तृत है, और जैसा कि ऊपर वर्णित है, इस पेपर की प्रस्तुति (और बाद में मुद्रण और प्रकाशन) के बाद। , मूल सामान्य रूप पहले सामान्य रूप से जाना जाने लगा।

जैसा कि एक प्रैक्टिशनर देख सकता है, आरडीबी कार्यान्वयन में अप्राकृतिक संबंध (तालिकाओं) का परिचय (लगभग हमेशा अनावश्यक) दृढ़ संकल्प है ।

एक संबंध जो 1NF को संतुष्ट करता है, बाधाओं और डेटा हेरफेर के संचालन की परिभाषा को आसान बनाता है, जो डेटा सबलंगेज के माध्यम से लागू किया जा सकता है जो कि असामान्य संबंधों (तालिकाओं) के लिए आवश्यक से कम जटिल है, जैसा कि डॉ। कोडड निम्नलिखित पंक्तियों में बताते हैं:

डेटा के एक संबंधपरक मॉडल को अपनाने, जैसा कि ऊपर वर्णित है, एक लागू पेडीकैट पर आधारित एक सार्वभौमिक डेटा सबलंगेज के विकास की अनुमति देता है। यदि संबंधों का संग्रह सामान्य रूप में है, तो पहले-क्रम की गणना पथरी ग्रस्त होती है। ऐसी भाषा अन्य सभी प्रस्तावित डेटा भाषाओं के लिए भाषाई शक्ति प्रदान करती है, और कई प्रकार की होस्ट भाषाओं (प्रोग्रामिंग, कमांड- या समस्या उन्मुख) में एम्बेड करने के लिए एक मजबूत उम्मीदवार होगी (उपयुक्त वाक्यविन्यास संशोधन के साथ)। [...]

[...]

डेटा सबलंगेज की सार्वभौमिकता इसकी वर्णनात्मक क्षमता (इसकी कंप्यूटिंग क्षमता नहीं) में निहित है।

हतप्रभ

देखने की मेरी बात से, घबराहट उत्पन्न हो गई है, की वजह से व्याख्याओं, स्पष्टीकरण, आदि, 1NF और के बारे में (क) ऊपर उल्लिखित अतिरिक्त आरएम ही है, और की वजह से (ख) के लिए आगे प्रयास को फिर से परिभाषित 1NF कि राज्य कि संबंध हैं उन डोमेन के साथ, जो मान रखते हैं, बदले में, संबंध 1NF के साथ अनुपालन करते हैं जब तक कि वे प्रत्येक संगत टपल के लिए एक एकल मान हैं।

मेरे अपने अन्य बिंदुओं पर ले लो

पंक्तियों के बीच कोई संबंध नहीं होना चाहिए, इसके अलावा वे एक ही हेडर के अनुरूप हैं।

मुझे यकीन है कि अगर मैं सही ढंग से कि बयान के इरादे समझ में नहीं कर रहा हूँ, लेकिन, के अलावा एक ही हेडर के अनुरूप से, वहाँ एक होना चाहिए कनेक्शन (tuples) के बीच एक रिश्ता (टेबल) उनमें से प्रत्येक के रूप में की पंक्तियों एक के बारे में एक अभिकथन होना चाहिए विशिष्ट इकाई प्रकार की विशेष घटना (ब्याज के व्यावसायिक संदर्भ के रूप में परिभाषित) कि संबंध (तालिका) का प्रतिनिधित्व करना है।

स्तंभों के बीच भी कोई संबंध नहीं होना चाहिए, लेकिन मेरा मानना ​​है कि यह उच्च सामान्य रूपों का विषय है।

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

अनुकरणीय संबंध के संबंध में (तालिका)

• Salary (PersonNumber, EffectiveDate, Amount)

टपल (पंक्ति)

• Salary (x, y, z)

अर्थ बताएगा

• The Salary payed to the Person identified by PersonNumber x, on EffectiveDate y corresponds to the Amount of z

इसलिए, Salaryसंबंध (तालिका) के प्रत्येक टुपल ( तालिका) को ऊपर दिखाए गए दावे की संरचना में फिट होना चाहिए, और अंतर प्रासंगिक डोमेन (स्तंभ) मानों के प्रतिस्थापन होगा, लेकिन (ए) के बीच एक संबंध होना चाहिए सभी Salaryडोमेन (कॉलम) और भी (बी) के बीच प्रत्येक ट्यूपल (पंक्ति) के संबंध में उनके सभी संबंधित मूल्य; ऐसा संबंध अपरिहार्य है।

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

Answer 2

एक उदाहरण। एक टेक्स्ट स्ट्रिंग लें जिसमें एक सामान्य यूएस एड्रेस हो:

"123 Cornhusk Rd., South Succotash, NY 12345"

कॉर्नस्क रोड के सभी निवासियों या दक्षिण सुकोतश शहर या न्यूयॉर्क के एक विशेष निवासी को खोजने के लिए एक प्रश्न लिखना एक कठिन काम होगा। विशेष रूप से जब आपके पास डेटा में निम्नलिखित तार हों:

"123 Cornhusk Road, South Succotash, NY 12345"
"123 Cornhusk Rd., South Succotash, New York 12345"
"123 Cornhusk, South Succotash, NY 12345"
"123 Cornhusk Rd., SOUTH SUCCOTASH, NY 12345"

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

पहले सामान्य रूप दर्ज करें। मैं इसके विवरण में नहीं जाऊँगा कि यह कैसे किया जाता है, बस एक सामान्य रूप पर विचार करें जैसा कि अधिकांश डेटाबेस में देखा गया है:

create table Addresses(
  ...
  Street  varchar,
  City    int        references Cities( ID ),
  State   char( 2 )  references States( ID ),
  Zip     int
  ...
);

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

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

इसलिए हमें "वर्णों का तार" लेना होगा और इसे "पते" में बदलना होगा। लेकिन संबोधन की सर्व-समावेशी परिभाषा के साथ आना इतना सरल नहीं है जितना दिखता है। खासकर जब एक से अधिक देशों में पते के साथ काम कर रहे हों।

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

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

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

Answer 3

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

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

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

बहु-निर्भर निर्भरता जैसी पंक्ति निर्भरता 1NF का उल्लंघन नहीं करती है, लेकिन स्तंभों के बीच निर्भरता की तरह, उच्च सामान्य रूपों का विषय है। लगभग दोहराए जाने वाले कॉलम जैसे phone1, phone2आदि 1NF का उल्लंघन नहीं करते हैं, भले ही वे खराब डिज़ाइन हों।

Answer 4

विकीपीडिया की परिभाषा और स्पष्टीकरण 1NF के बारे में, मुझे लगता है कि काफी अच्छा है। - जोनलो

विकिपीडिया लेख में एक वाक्य पर विस्तार:

टेलीफोन नंबर के रूप में देखा, पाठ परमाणु नहीं है

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

क्या इसे आगे तोड़ने का कोई मतलब है या नहीं, यह इस सवाल से प्रासंगिक है कि क्या पहले सामान्य रूप से मुलाकात की गई थी। 1NF के पीछे का बिंदु सभी डेटा तक पहुंच प्रदान करना है। लेकिन अगर आप की-एक्सेस के माध्यम से पुनः प्राप्त करते हैं, तो आपके पास सबस्ट्रक्चर है, तो आपके पास सबस्ट्रक्चर की पहुंच नहीं है। - वाल्टर मिती

"1NF" का उपयोग विभिन्न चीजों के एक समूह का मतलब करने के लिए किया जाता है , जिनमें से कई एक साथ एक साथ निरर्थक और सामान्य हैं। इसके लिंक सहित "डेटाबेस मैनेजमेंट सिस्टम में सामान्यीकरण" के लिए मेरा उत्तर देखें । उनमें से एक मेरा जवाब है "dbms में परमाणु क्या है" । (स्टैक ओवरफ्लो में दोनों।) - फिलिपी

---

_{प्रश्न पर छोड़ी गई टिप्पणियों से निर्मित सामुदायिक विकी उत्तर}