संबंधपरक डेटाबेस डिजाइन गाइड (4-6 का 15) [अनुवाद]

मैं शुरुआती लोगों के लिए लेखों की श्रृंखला के अनुवाद की निरंतरता पोस्ट करता हूं।
वर्तमान और बाद में, अधिक जानकारी गुण पर है।
शुरुआत यहाँ है ।

4. टैब और प्राथमिक कुंजी

जैसा कि आप पहले से ही पिछले भागों से जानते हैं, डेटा को उन तालिकाओं में संग्रहीत किया जाता है जिनमें पंक्तियाँ या रिकॉर्ड दूसरे तरीके से होते हैं। इससे पहले, मैंने एक तालिका का उदाहरण दिया जिसमें पाठों के बारे में जानकारी थी। आइए एक बार फिर उसकी तरफ देखें।



तालिका में 6 पाठ हैं। सभी 6 अलग-अलग हैं, लेकिन प्रत्येक पाठ के लिए एक ही फ़ील्ड के मानों को तालिका में संग्रहीत किया जाता है, अर्थात्: tutorial_id (पाठ पहचानकर्ता), शीर्षक (शीर्षक) और श्रेणी (श्रेणी)। Tutorial_id - पाठ तालिका की प्राथमिक कुंजी । प्राथमिक कुंजी एक मूल्य है जो तालिका में प्रत्येक रिकॉर्ड के लिए अद्वितीय है।
नीचे ग्राहक तालिका में customer_id प्राथमिक कुंजी है। इस मामले में, प्राथमिक कुंजी भी प्रत्येक रिकॉर्ड के लिए एक अद्वितीय मान (संख्या) है।

रोजमर्रा की जिंदगी में प्राथमिक कुंजी

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

कुछ उदाहरण

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

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

प्राथमिक कुंजी की विशेषता क्या है? प्राथमिक मुख्य विशेषताएं।

रिकॉर्ड की पहचान करने के लिए प्राथमिक कुंजी का उपयोग किया जाता है।

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

प्राथमिक कुंजी अद्वितीय है।

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

| first_name | last_name |
| वास्य | पुतकिन |
| वास्य | पुतकिन |

यानी वहाँ दो Vasya हैं। आप तालिका से एक विशिष्ट वास्य चुनना चाहते हैं। यह कैसे करना है? रिकॉर्ड एक दूसरे से अलग नहीं हैं। यह वह जगह है जहां प्राथमिक कुंजी मदद करती है। आईडी कॉलम (सिंथेटिक प्राथमिक कुंजी का क्लासिक संस्करण) और जोड़ें ...

आईडी | first_name | last_name |
1 | वास्य | पुतकिन |
2 | वास्य | पुतकिन |

अब हर वासना अद्वितीय है।

प्राथमिक कुंजी के प्रकार।

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

ऑटो नंबरिंग।

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

5. लिंकिंग एक्सटर्नल एक्सक्लूसिव कुंजी का उपयोग करना

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

• यह निर्धारित करना कि आप किन संस्थाओं को इसमें स्टोर करना चाहते हैं
• इन संस्थाओं के बीच क्या संबंध हैं

एक-से-कई।

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

एक बात जो अब महत्वपूर्ण है वह यह है कि एक-से-कई रिश्तों के लिए, दो अलग-अलग तालिकाओं की आवश्यकता होती है। एक ग्राहकों के लिए, दूसरा ऑर्डर के लिए। आइए इन दोनों तालिकाओं को बनाकर थोड़ा अभ्यास करें।

हम क्या जानकारी संग्रहीत करेंगे? हम पहला सवाल हल करते हैं।

शुरू करने के लिए, हम यह निर्धारित करेंगे कि हम ऑर्डर और ग्राहकों के बारे में क्या जानकारी संग्रहीत करेंगे। ऐसा करने के लिए, हमें अपने आप से यह सवाल पूछना चाहिए: "जानकारी के कौन से यूनिट ब्लॉक ग्राहकों से संबंधित हैं, और सूचना के कौन से यूनिट ब्लॉक ऑर्डर करने के लिए संबंधित हैं?"

हम एक ग्राहक तालिका तैयार करते हैं।

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

• customer_id (प्राथमिक कुंजी) - ग्राहक पहचानकर्ता
• first_name - नाम
• last_name - मध्य नाम
• पता - पता
• zip_code - पिनकोड
• देश - देश
• जन्म_तिथि - जन्म तिथि
• उपयोगकर्ता नाम - उपयोगकर्ता नाम (लॉगिन)
• पासवर्ड - पासवर्ड

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


SQLyog में एक तालिका बनाना। ध्यान दें कि customer_id फ़ील्ड के लिए प्राथमिक कुंजी (PK) चेक बॉक्स चयनित है। Customer_id फ़ील्ड प्राथमिक कुंजी है। ऑटो इंक चेकबॉक्स भी चुना जाता है, जिसका अर्थ है कि डेटाबेस स्वचालित रूप से एक अद्वितीय संख्यात्मक मान का विकल्प देगा, जो कि शून्य से शुरू होकर, प्रत्येक बार एक इकाई से बढ़ेगा।

हम ऑर्डर की एक तालिका डिज़ाइन करते हैं।
सूचना के न्यूनतम ब्लॉक क्या हैं जो हमें एक आदेश के लिए चाहिए?

• order_id (प्राथमिक कुंजी) - आदेश पहचानकर्ता
• ऑर्डर_डेट - ऑर्डर की तारीख और समय
• ग्राहक - ग्राहक जिसने ऑर्डर दिया है

नीचे SQLYog में एक उदाहरण तालिका है।


ड्राफ्ट तालिका। ग्राहक फ़ील्ड ग्राहक तालिका में customer_id फ़ील्ड के लिए संदर्भ (विदेशी कुंजी) है।

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

एक विदेशी कुंजी संबंध बनाना।

आप सोच रहे होंगे: "मैं कैसे सुनिश्चित हो सकता हूं या मैं यह कैसे देख सकता हूं कि ऑर्डर टेबल में ग्राहक फ़ील्ड ग्राहक तालिका में ग्राहक_आईडी फ़ील्ड को संदर्भित करता है"। उत्तर सरल है - आप ऐसा नहीं कर सकते क्योंकि मैंने अभी तक आपको कनेक्शन बनाने का तरीका नहीं दिखाया है।
नीचे विंडो के साथ SQLyog विंडो है जिसका उपयोग मैंने तालिकाओं के बीच संबंध बनाने के लिए किया था।


ऑर्डर टेबल और ग्राहकों के बीच एक विदेशी कुंजी संबंध बनाएं।

ऊपर दी गई विंडो में, आप देख सकते हैं कि बाईं ओर ऑर्डर टेबल का ग्राहक क्षेत्र दाईं ओर ग्राहक तालिका की प्राथमिक कुंजी (customer_id) के साथ कैसे जुड़ा हुआ है।

अब, जब आप तालिकाओं में हो सकने वाले डेटा को देखते हैं, तो आप देखेंगे कि दोनों तालिकाएँ जुड़ी हुई हैं।


ऑर्डर ग्राहकों से ग्राहक क्षेत्र से जुड़े होते हैं, जो ग्राहक तालिका को संदर्भित करता है।

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

6. सुरक्षा-संचार विभाग का सृजन

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

सार।

आपको आश्चर्य हो सकता है कि एक इकाई क्या है। खैर ... यह प्रणाली में "बात" है। वहाँ। मेरी माँ हमेशा चाहती थी कि मैं एक शिक्षक बनूँ क्योंकि मैं विभिन्न चीजों को बहुत अच्छी तरह से समझाता हूँ।

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

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

ग्राहक द्वारा आदेश का भुगतान किया जाता है ... यह दिलचस्प है। क्या हम अपने ऑनलाइन स्टोर के डेटाबेस में भुगतान के लिए एक अलग तालिका बनाने जा रहे हैं? हो सकता है कि। लेकिन क्या भुगतान सूचनाओं का न्यूनतम ब्लॉक है जो ऑर्डर से संबंधित है? यह संभव भी है।

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

चलो बहुत अकादमिक नहीं है।

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


वहां पर रुकें, आप वास्तव में डेटाबेस में अपनी डिग्री प्राप्त करने के करीब हैं।

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


यदि आप एक जटिल अनुप्रयोग पर काम कर रहे हैं तो एक इकाई-संबंध आरेख काफी बड़ा हो सकता है। कुछ चार्ट में सैकड़ों या हजारों टेबल भी हो सकते हैं।

संचार।

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

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