भूख लगी है लेकिन आप खाना नहीं बनाना चाहते हैं? एक रेस्तरां को कॉल करें, अपना पसंदीदा भोजन ऑर्डर करें, और एक डेटा मॉडल के बारे में पढ़ें जो पूरी प्रक्रिया को व्यवस्थित कर सकता है।
"समय बचाने वाली" तकनीक की प्रचुरता के बावजूद, हमारे पास खाने जैसी बुनियादी ज़रूरतों को पूरा करने के लिए कम समय लगता है। अगर हम कुछ खाना चाहते हैं, लेकिन हमारे पास खुद पकाने के लिए समय (या कौशल) नहीं है, तो हम एक रेस्तरां (यानी टेकअवे या टेकआउट) से खाना मंगवा सकते हैं, जो हमारे भोजन को हमारे दरवाजे पर लाएगा। बेशक, हमें इस सुविधा के लिए भुगतान करना होगा, इसलिए हम उम्मीद करते हैं कि खाना अच्छा और गर्म हो!
जाहिर है, कोई भी रेस्तरां अपने ग्राहकों को संतुष्ट रखने के लिए प्रेरित होता है। आपको यह जानकर आश्चर्य हो सकता है कि टेकअवे चलाने में कितना काम लगता है। अधिकांश ऑर्डर और डिलीवरी को प्रबंधित करने के लिए किसी न किसी प्रकार के ट्रैकिंग सिस्टम का उपयोग करते हैं। आइए ऐसी ही एक प्रणाली के तहत डेटा मॉडल को देखें। अपने लिए एक नाश्ता लें, वापस बैठें और लेख का आनंद लें।
रेस्तरां व्यवसाय के बारे में हमें क्या पता होना चाहिए?
खाना बनाना और ग्राहकों तक पहुंचाना आसान नहीं है। स्वादिष्ट भोजन तैयार करने के लिए सबसे पहले आपके पास प्रतिभा और ज्ञान होना चाहिए। आपको व्यवस्थित होने की भी आवश्यकता है:अगर ये भोजन समय पर और सही जगह पर पहुंचाए जा रहे हैं तो सब कुछ पूरी तरह से काम करने की जरूरत है!
इससे पहले कि हम कोई भी भोजन देना शुरू करें, हमें यह जानना होगा:
- भोजन का आदेश किसने दिया
- भोजन कहां और कब दिया जाना चाहिए
- आदेश में कौन से व्यंजन शामिल हैं
- आदेश को पूरा करने के लिए हमें किन सामग्रियों की आवश्यकता है
- यदि आदेश का भुगतान पहले ही किया जा चुका है
हमें डिलीवरी की स्थिति को ट्रैक करने और उनके भोजन और/या हमारी डिलीवरी प्रक्रिया के बारे में ग्राहकों की प्रतिक्रिया रिकॉर्ड करने की भी आवश्यकता है। इसके अलावा, शायद हम जानना चाहते हैं कि कौन से भोजन सबसे अधिक (या कम से कम) लोकप्रिय हैं। और हमें कुछ वित्तीय जानकारी भी रिपोर्टिंग और विश्लेषण उद्देश्यों के लिए रखनी चाहिए।
आइए मान लें कि हमारे पास एक ऐप है जिसका उपयोग हमारे ग्राहक डिलीवरी के लिए ऑर्डर देने के लिए कर सकते हैं। यह उन्हें मेनू आइटम चुनने, उनके लिए भुगतान करने और डिलीवरी का समय और पता निर्दिष्ट करने की अनुमति देता है। ऐसे ऐप के नीचे डेटा मॉडल कैसा दिख सकता है?
डेटा मॉडल
आप Edit model in your browser . पर क्लिक करके इस मॉडल को अपने ब्राउज़र में खोल सकते हैं बटन।
डेटा मॉडल में तीन विषय क्षेत्र होते हैं:
Restaurants & customersMenusOrders
हम प्रत्येक विषय क्षेत्र को सूचीबद्ध क्रम में प्रस्तुत करेंगे।
रेस्तरां और ग्राहक
Restaurants & customers विषय क्षेत्र में तीन टेबल होते हैं जो हमारे रेस्तरां (एक से अधिक हो सकते हैं), जिन शहरों में हम काम करते हैं, और हमारे ग्राहकों के बारे में विवरण संग्रहीत करते हैं।
ग्राहक और रेस्तरां दोनों शहरों (या कस्बों, गांवों, आदि) में स्थित हैं। इसलिए, हमें एक city शब्दकोश। इसमें केवल दो विशेषताएँ हैं, city_name और zip_code . अगर हम एक से अधिक देशों में काम करते हैं, तो हमें एक देश शब्दकोश की भी आवश्यकता होगी जो इस तालिका से संबंधित हो, लेकिन हम यहां उस पर नहीं जाएंगे।
इसके बाद, हमें उन सभी रेस्तरां की एक सूची चाहिए जो हम संचालित करते हैं। हम restaurant उसके लिए तालिका। चीजों को सरल रखने के लिए, हम केवल प्रत्येक रेस्तरां का address संग्रहित करेंगे और city यह कहाँ स्थित है।
इस विषय क्षेत्र में अंतिम तालिका customer टेबल। यह वह जगह है जहां हम अपने सभी पंजीकृत डिलीवरी ग्राहकों की एक सूची संग्रहित करेंगे। हम बाद में मॉडल में ग्राहकों को उनके ऑर्डर से जोड़ने के लिए इस तालिका के डेटा का उपयोग करेंगे। बेशक, ऑर्डर देने के लिए ग्राहकों को हमारे मॉडल में पंजीकृत होने की आवश्यकता नहीं है, लेकिन हमें अभी भी इस सूची की आवश्यकता है। हम लॉयल्टी प्रोग्राम के रूप में पंजीकृत ग्राहकों को छूट प्रदान कर सकते हैं। या शायद हम इस डेटा का उपयोग विशेष ऑफ़र वाले ग्राहकों से संपर्क करने के लिए करेंगे। प्रत्येक पंजीकृत ग्राहक के लिए, हम स्टोर करेंगे:
customer_name- ग्राहक का पूरा नाम।city_id- संदर्भcityजहां ग्राहक रहता है।address- ग्राहक का पता।contact_phone- ग्राहक का फोन नंबर।email- पंजीकरण प्रक्रिया के दौरान ग्राहक द्वारा उपयोग किया गया ईमेल पता।confirmation_code- पंजीकरण प्रक्रिया के दौरान उपयोग किया जाने वाला एक पुष्टिकरण कोड।password- इस ऐप के लिए ग्राहक द्वारा चुना गया पासवर्ड।time_joined- ग्राहक के हमारे आवेदन में शामिल होने का टाइमस्टैम्प।
मेनू
इस विषय क्षेत्र में हमारे रेस्तरां के मेनू के बारे में जानकारी है। अभी के लिए, मान लें कि हमारे सभी रेस्तरां एक ही मेनू का उपयोग करते हैं।
पहली तालिका है category शब्दकोश। इसमें केवल एक UNIQUE विशेषता है, category_name . इस फ़ील्ड में शायद सामान्य मेनू श्रेणियां होंगी, जैसे "पेय", "शुरुआत", "सलाद", "सैंडविच", "पिज्जा", आदि।
इसके बाद, हमारे पास menu_item टेबल। यह हमारे किसी भी मेनू पर हमारे पास (या था) सभी वस्तुओं को सूचीबद्ध करता है। प्रत्येक आइटम के लिए, हम स्टोर करेंगे:
item_name- उस आइटम का नाम, उदा. "चिकन सैंडविच"।category_id- संदर्भcategoryवह वस्तु जिससे संबंधित है, उदा। "सैंडविच"।description- उस वस्तु का विवरण। यह प्रिंटेड मेन्यू जैसा ही होना चाहिए।ingredients- उस वस्तु को बनाने के लिए प्रयुक्त सामग्री और उनकी मात्रा। यह फ़ील्ड वास्तव में एक नुस्खा संग्रहीत कर सकती है।price- एक आइटम की मौजूदा कीमत (जैसे कि एक चिकन सैंडविच)।active- यदि आइटम वर्तमान मेनू पर पेश किया जाता है।
यदि हम मेनू को कई भाषाओं में संग्रहीत करना चाहते हैं, तो हमें इस लेख में प्रस्तुत दृष्टिकोण की तरह एक दृष्टिकोण का उपयोग करना चाहिए।
अधिकांश रेस्तरां में विशेष, सीमित समय के ऑफ़र होते हैं। उनके पास असीमित समय के लिए कुछ ऑफ़र भी हो सकते हैं। हम offer इनके लिए तालिका। प्रत्येक के लिए, हमारे पास होगा:
date_active_fromऔरdate_active_to- साथ में, ये परिभाषित करते हैं कि यह ऑफ़र कब सक्रिय है। यदि किसी ऑफ़र की अवधि असीमित है या यदि यह दिनों के बजाय घंटों पर आधारित है, तो इन दो विशेषताओं में NULL मान होंगे। इस प्रकार के ऑफ़र का एक उदाहरण है "मार्च के महीने के दौरान, एक करी खरीदें और एक पर 50% छूट प्राप्त करें"।time_active_fromऔरtime_active_to- दिन के उस समय को परिभाषित करता है जब कोई ऑफ़र मान्य होता है - उदा। "हर दिन सुबह 6-9 बजे तक मुफ़्त कॉफ़ी पाएं"।offer_price- उस ऑफ़र की कीमत.
ऑफ़र में शामिल सभी मेनू आइटम in_offer टेबल। इस तालिका में offer_id . की UNIQUE जोड़ी है - menu_item_id ।
यदि हमारे रेस्तरां में अलग-अलग मेनू हैं, तो हमें प्रत्येक रेस्तरां के लिए एक अलग मेनू बनाना होगा। फिर हमें मेनू और ऑफ़र को विदेशी कुंजियों का उपयोग करने वाले रेस्तरां से जोड़ना होगा। यह हमें दूसरों को प्रभावित किए बिना किसी भी रेस्तरां के लिए मेनू और ऑफ़र बदलने की अनुमति देगा। यह सिर्फ डेटाबेस को जटिल नहीं करेगा; व्यापार मॉडल भी अधिक जटिल हो जाएगा। यही कारण है कि अधिकांश रेस्तरां शृंखलाएं केवल एक मेनू से चिपकी रहती हैं और इसलिए मैंने इस मॉडल में इस पद्धति का उपयोग नहीं करने का निर्णय लिया।
आदेश
हमारे मॉडल में अंतिम विषय क्षेत्र है Orders विषय क्षेत्र। यह वह जगह है जहां हमारे पास ऑर्डर और उनकी स्थिति को स्टोर करने के लिए आवश्यक सब कुछ होगा।
यहां केंद्रीय तालिका है placed_order टेबल। इस तालिका के नाम के रूप में केवल "आदेश" का उपयोग नहीं करना सबसे अच्छा है:"आदेश" एक SQL कीवर्ड है। तालिकाओं और स्तंभों के नाम के रूप में कीवर्ड का उपयोग करने से बचने का प्रयास करें; अन्यथा, प्रश्न लिखते समय आपको त्रुटियाँ मिल सकती हैं। प्रत्येक आदेश के लिए, हम रिकॉर्ड करेंगे:
restaurant_id-restaurantउस आदेश से संबंधित।order_time- ऑर्डर देने के समय का टाइमस्टैम्प।estimated_delivery_time- इस ऑर्डर की सुनियोजित डिलीवरी का टाइमस्टैम्प।food_ready- एक टाइमस्टैम्प यह दर्शाता है कि ऑर्डर आइटम कब तैयार किए गए थे। भोजन तैयार होने तक इसमें NULL मान होगा। हम इस विशेषता का उपयोग उस समय के अंतर की गणना करने के लिए कर सकते हैं जब ऑर्डर दिया गया था और जब खाना तैयार किया गया था। हम इसका उपयोग यह पता लगाने के लिए भी कर सकते हैं कि भोजन कब तैयार हुआ और कब वितरित किया गया। कर्मचारियों की कार्यकुशलता बढ़ाने के मामले में यह जानकारी बहुत मददगार हो सकती है।actual_delivery_time- एक टाइमस्टैम्प जब यह आदेश वास्तव में वितरित किया गया था। यह तब तक NULL रहेगा जब तक कि ग्राहक को खाना डिलीवर नहीं कर दिया जाता।delivery_address- वह पता जहां ऑर्डर दिया जाना चाहिए।customer_id-customerजिसने यह आदेश दिया। इस विशेषता में एक NULL मान हो सकता है यदि आदेश किसी ऐसे व्यक्ति द्वारा दिया गया था जो एक पंजीकृत ऐप उपयोगकर्ता नहीं है।price- उस क्रम में शामिल सभी वस्तुओं की कीमत।discount- कीमत पर लागू छूट की राशि (जैसे कूपन या लॉयल्टी छूट), यदि कोई हो।final_price- ऑर्डर की कीमत घटाकर छूट।comment- ऑर्डर देते समय ग्राहक द्वारा डाली गई अतिरिक्त टिप्पणियां। यह अतिरिक्त वितरण निर्देश या कुछ और हो सकता है जो ग्राहक को महत्वपूर्ण लगे।ts- एक टाइमस्टैम्प जब यह रिकॉर्ड तालिका में डाला गया था।
in_order तालिका उन सभी वस्तुओं या विशेष प्रस्तावों को सूचीबद्ध करती है जो एक आदेश में शामिल हैं। इस तालिका में प्रत्येक रिकॉर्ड के लिए, हम स्टोर करेंगे:
placed_order_id- संबंधितorder।offer_id- संदर्भofferतालिका, लेकिन केवल तभी जब इस क्रम में एक या अधिक ऑफ़र शामिल हों। उस स्थिति में,menu_item_idविशेषता NULL होगी।menu_item_id- संदर्भmenu_itemतालिका, लेकिन केवल तभी जब यह रिकॉर्ड किसी मेनू आइटम से संबंधित हो, न कि किसी ऑफ़र से।quantity- इस क्रम में कितने ऑफ़र या मेनू आइटम शामिल हैं।item_price- एकल ऑफ़र या मेनू आइटम की कीमत।price– इस लाइन के लिए कुल मूल्य,item_price. के रूप में व्यक्त किया गया है *quantity।comment- ग्राहक द्वारा डाली गई कोई भी टिप्पणी जो विशेष रूप से उस ऑर्डर आइटम से संबंधित है, उदा। "कृपया पिज़्ज़ा को 8 स्लाइस में काटें"।
comment तालिका हमें आदेशों से संबंधित कई टिप्पणियों को सम्मिलित करने का समर्थन करने देती है। प्रत्येक टिप्पणी के लिए, हम संबंधित आदेश की आईडी और ग्राहक की आईडी संग्रहीत करेंगे। जब यह टिप्पणी दर्ज की गई थी तब हम उसका टाइमस्टैम्प भी संगृहीत करेंगे। हम यह भी चिन्हित करेंगे कि यह टिप्पणी एक शिकायत थी या प्रशंसा; इन दोनों में से केवल एक को एक बार में सेट किया जा सकता है। अगर कोई सेट नहीं है, तो हम इस टिप्पणी को तटस्थ मानेंगे।
हमारे मॉडल में अंतिम दो टेबल उन स्थितियों से संबंधित हैं जिन्हें हम ऑर्डर के लिए असाइन करेंगे। status_catalog तालिका में सभी संभावित UNIQUE status_name . की एक सूची है विशेषताएँ जिन्हें हम ऑर्डर पर असाइन कर सकते हैं। order_status तालिका में सभी स्थितियाँ होती हैं जो आदेशों को सौंपी जाती हैं। इस तालिका में प्रत्येक रिकॉर्ड के लिए, हम ऑर्डर और स्थिति से संबंधित विदेशी कुंजी और यह स्थिति निर्दिष्ट किए जाने पर टाइमस्टैम्प संग्रहीत करेंगे।
आप रेस्टोरेंट डिलीवरी डेटा मॉडल के बारे में क्या सोचते हैं?
आज हमने एक डेटा मॉडल पर चर्चा की है जिसका उपयोग रेस्तरां डिलीवरी ऑर्डर को व्यवस्थित, प्रबंधित और स्टोर करने के लिए किया जा सकता है। हम प्रत्येक आदेश की स्थिति और कुछ वित्तीय विवरणों को ट्रैक कर सकते हैं। मेरे पास इस बारे में कुछ विचार हैं कि हम इस मॉडल को और अधिक मजबूत कैसे बना सकते हैं, लेकिन मुझे आपकी राय जानकर खुशी होगी। कृपया इसे टिप्पणी अनुभाग में साझा करें!
