जारी रखा जाए।
पिछला भाग:
1-3 ,
4-6 ,
7-9 ,
10-13जारी रखा जाए। कैस्केडिंग डेटा विलोपन।14. एक और उदाहरण: एक ऑनलाइन स्टोर डेटाबेस।
आप परिचित हो गए हैं, मुझे उम्मीद है, डेटाबेस बनाने की बुनियादी अवधारणाओं के साथ और अब आप एक साधारण रिलेशनल डेटाबेस डिज़ाइन कर सकते हैं। नीचे दिए गए उदाहरण में, मैं उन कार्यों को सारांशित करता हूं जो आप डेटाबेस डिजाइन करते समय सामना करेंगे।
PS एक बहुत ही सरलीकृत रूप में नीचे दी गई जानकारी डेटाबेस बनाते समय सोचा प्रक्रिया को मॉडल करता है।
ऑनलाइन स्टोर प्रणाली।
उपयोग किए जाने वाले डेटा का अंदाजा लगाने के लिए, आइए उन कार्यों की रूपरेखा तैयार करें जिन्हें ऑनलाइन स्टोर को करना चाहिए।
- उत्पाद प्रदर्शन
- उत्पाद का वर्गीकरण
- ग्राहक पंजीकरण
- शॉपिंग कार्ट में आइटम जोड़ना
- खरीदारी कार्ट सामग्री प्रदर्शित करें
- आगंतुकों द्वारा आदेशों का स्थान
- आदि
सार और संबंध को परिभाषित करें।
कार्यों की सूची से हम उन संस्थाओं को प्राप्त कर सकते हैं जिनकी हमारे सिस्टम में महत्वपूर्ण भूमिकाएँ हैं।
उत्पाद ,
श्रेणियां ,
ग्राहक और
ऑर्डर ऐसी इकाइयाँ हैं जो लगभग हर ऑनलाइन स्टोर डेटाबेस में पाई जा सकती हैं। इस उदाहरण में, मैं आपको एक मॉडल दिखाऊंगा जिसमें केवल निम्नलिखित इकाइयां होंगी:
ग्राहक ,
ऑर्डर और
उत्पाद । संस्थाओं के बारे में फैसला करने के बाद, हम उनके बीच के रिश्तों के बारे में सोच सकते हैं।
- आदेश और उत्पाद के बीच कई-से-कई संबंध हैं। प्रत्येक ऑर्डर में 1 या अधिक उत्पाद होते हैं और प्रत्येक उत्पाद 0, 1 या अधिक ऑर्डर के साथ जुड़ा हो सकता है। तीन-तालिकाओं का उपयोग करके कई-से-कई संबंध बनाए जाते हैं। दो तालिकाएँ - डेटा स्रोत (ऑर्डर - ऑर्डर और उत्पाद - माल) और एक - कनेक्टिंग (ऑर्डरप्रोडक्ट्स), जिसे आप नीचे दी गई तस्वीर में देख सकते हैं। ध्यान दें कि दोनों ऑर्डर और उत्पादों का कनेक्शन टेबल के साथ एक-से-कई संबंध हैं। साथ में वे ऑर्डर और सामान के बीच कई-से-कई संबंध बनाते हैं।
- ग्राहकों और आदेशों में एक-से-कई संबंध हैं। प्रत्येक ग्राहक रिकॉर्ड ऑर्डर (ऑर्डर) के कई रिकॉर्ड के साथ जुड़ा हो सकता है और इसके विपरीत, प्रत्येक ऑर्डर रिकॉर्ड (विशिष्ट ऑर्डर) केवल एक ग्राहक रिकॉर्ड के साथ जुड़ा हो सकता है।
यह तालिका एक सरल उदाहरण है। "वास्तविक" ग्राहक तालिका, निश्चित रूप से, अधिक जानकारी (पता, शहर, आदि) शामिल है
इस मॉडल के बारे में कुछ नोट्स।
आदेश तालिका
ऑर्डर टेबल का प्रत्येक रिकॉर्ड, प्रत्येक ऑर्डर एक अद्वितीय ग्राहक रिकॉर्ड के साथ जुड़ा हुआ है, जिसमें एक
विदेशी कुंजी - customer_id फ़ील्ड का उपयोग करके एक अद्वितीय ग्राहक है।
आदेशों की संख्या।यदि आप सोच रहे थे कि क्या आप जोड़ सकते हैं, उदाहरण के लिए, आदेशों की संख्या के लिए फ़ील्ड (ऑर्डर_क्वैंटिटी), तो उत्तर नहीं है। यह डेटा
मौजूदा डेटा से प्राप्त किया जा सकता है। ऑर्डरपार्टी तालिका से उत्पादों की कुल संख्या (ऑर्डर_क्वैंटिटी) प्राप्त की जा सकती है। एक क्वेरी जो ऑर्डर में सामानों की मात्रा का पता लगाती है, SQL का उपयोग करके आसानी से उत्पन्न की जा सकती है।
भुगतान का प्रकार।फ़ील्ड जिसे आप ऑर्डर टेबल में जोड़ सकते हैं, वह है payment_type (भुगतान प्रकार)। यह जानकारी एक विशिष्ट आदेश के लिए अद्वितीय है और इसे अन्य डेटा से प्राप्त नहीं किया जा सकता है (ध्यान रखें कि भुगतान तालिका प्रकार ऑर्डर तालिका में एक विदेशी कुंजी बन जाएगी - ऑर्डर - भुगतान प्रकार युक्त एक अलग तालिका के लिंक के साथ)।
आदेश की कुल राशि।एक अन्य फ़ील्ड जिसे आप (और संभवतः चाहिए) ऑर्डर टेबल में जोड़ सकते हैं, कुल ऑर्डर राशि के लिए एक फ़ील्ड है। लेकिन आप सोच सकते हैं कि हम यह डेटा मौजूदा लोगों से प्राप्त कर सकते हैं। आप ऑर्डर के सभी सामानों की लागत जोड़ सकते हैं? हां। और नहीं। माल की कीमत एक परिवर्तनीय मूल्य है। इसलिए, जब आप अपने प्रत्येक सामान की लागत को जोड़कर एक ऑर्डर की कुल लागत की गणना करते हैं, और स्टोर के मालिक ऑर्डर में किसी एक सामान की लागत को दोगुना कर देते हैं, तो पहले से ही पूरे किए गए ऑर्डर की कुल लागत भी बदल जाएगी। दूसरे शब्दों में, यदि आप देखते समय ऑर्डर की कुल लागत की गणना करते हैं, और माल की कीमतें बदल सकती हैं, तो इतिहास के इस बहुत देखने में, एक स्थिति उत्पन्न हो सकती है जब पूरे ऑर्डर के लिए आपके द्वारा भुगतान की गई राशि बदल जाती है। इसीलिए ऑर्डर देते समय कुल लागत की गणना करना और ऑर्डर टेबल में स्टोर करना बेहतर होता है।
उत्पाद की कीमतों का इतिहास रखते हुए।इतिहास की बात करें तो, हम मान सकते हैं कि आपको प्रत्येक उत्पाद के लिए मूल्य इतिहास रखने की आवश्यकता हो सकती है। इस मामले में, आप ऑर्डर की तारीख को देख सकते हैं, टेबल price_history (मूल्य इतिहास) के लिए एक अनुरोध कर सकते हैं और ऑर्डर देने की तिथि पर सामान की लागत प्राप्त कर सकते हैं। इस मामले में, आपको ऑर्डर तालिका में ऑर्डर की कुल लागत को संग्रहीत नहीं करना होगा। मेरा मानना है कि अधिकांश ऑनलाइन स्टोर ऑर्डर आइटम का कुल मूल्य बनाए रखते हैं और इन वस्तुओं के लिए मूल्य इतिहास नहीं रखते हैं। लेकिन, आप की बात, डेवलपर यह तय करने के लिए आप पर निर्भर है कि यह करना है या नहीं।
माल की मेज।
माल की तालिका में, वैट को छोड़कर वस्तुओं के मूल्य संग्रहीत किए जाते हैं। VAT के साथ मूल्य की गणना प्रोग्राम कोड का उपयोग करके या SQL क्वेरी का उपयोग करके की जा सकती है। यही कारण है कि मैं वैट में शामिल कीमतों को स्टोर नहीं करता। आपको इस बात से अवगत होना चाहिए कि इस तरह से माल के मूल्य को स्टोर करना भविष्य में समझ में आ सकता है। इस मॉडल में, सामान की कीमत एक एकल तालिका फ़ील्ड में संग्रहीत की जाती है। एक बार जब आप किसी उत्पाद की कीमत बदल देते हैं, तो आप पिछले मूल्य को खो देते हैं। लेकिन अगर आप अपने डेटाबेस से पिछली बिक्री रिपोर्ट प्राप्त करने में सक्षम होना चाहते हैं, तो आपको प्रत्येक उत्पाद के लिए मूल्य इतिहास रखना होगा। यदि किसी उत्पाद ने एक निश्चित वर्ष में दो बार मूल्य बदल दिया है, तो आपको यह जानने के लिए मूल्य इतिहास की आवश्यकता है कि आपने किसी दिए गए वर्ष में इस उत्पाद के लिए कितना पैसा कमाया। और वैट के बाद से, जिस मूल्य पर बिक्री पर माल की कीमत बढ़ जाती है, वह आप तक नहीं पहुंचती है, तो माल के लिए लाभ रिपोर्ट में इसे ध्यान में रखना व्यर्थ है।
15. निष्कर्ष और आगे पढ़ना।
संबंधपरक डेटाबेस बड़ी मात्रा में सूचनाओं को कुशलतापूर्वक संग्रहीत करने के लिए एक उत्कृष्ट उपकरण है। इस गाइड में, मैंने मुख्य रूप से एक डेटाबेस मॉडल बनाने पर ध्यान केंद्रित किया। यह मॉडल किसी भी आरडीबीएमएस का उपयोग करके लागू किया जा सकता है, और एसक्यूएल का उपयोग करके उससे पूछताछ की जा सकती है।
आगे कहाँ जाना है?
यदि आप अपने डेटाबेस को विकसित करना चाहते हैं, तो
मैसकल वर्कबेन्च को अवश्य
देखें । यह इकाई-संबंध आरेख और अधिक बनाने के लिए एक महान उपयोगिता है। मैं सॉफ्टवेयर डेवलपर के रूप में अपने काम में इसका व्यापक रूप से उपयोग करता हूं, भले ही मेरा काम मैसकल आरडीबीएमएस का उपयोग नहीं करता हो।
इस गाइड को पढ़ने के बाद एक और तार्किक कदम संरचित क्वेरी भाषा (एसक्यूएल) से परिचित होना है। मैसकल वर्कबेन्च के साथ डेटाबेस तैयार करना या उन्हें सिकलीग के साथ प्रबंधित करना सभी बहुत अच्छा है, लेकिन ... अगर आप वास्तव में समझना चाहते हैं कि डेटाबेस का उपयोग कैसे करना है, तो SQL एक ऐसा कौशल है जिसके बिना आप सफल नहीं हुए हैं। W3Schools को आरंभ
करने के लिए कुछ बहुत अच्छे
एसक्यूएल ट्यूटोरियल हैं ।