एक टैक्सी सेवा के लिए एक डेटाबेस मॉडल

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

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

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

इस कैब डेटाबेस मॉडल के साथ हम क्या हासिल करना चाहते हैं?

इस लेख में प्रस्तुत मॉडल निम्न में सक्षम होगा:

• ड्राइवर शेड्यूल बनाएं
• वास्तविक समय में ड्राइवर की उपलब्धता को ट्रैक करें
• ड्राइवरों को संभावित सवारी की सूची प्रदान करें
• ड्राइवरों को सूची से एक सवारी चुनने की अनुमति दें
• ड्राइवरों के काम के घंटे और आय की गणना करें
• विभिन्न आंकड़े संग्रहीत करें (उदा. रद्द होने वाली सवारी का प्रतिशत, प्रति ड्राइवर प्रति माह भुगतान, आदि)

टैक्सी कंपनियों के बारे में हमें क्या जानना चाहिए?

कैब कंपनी के लिए डेटा मॉडल तैयार करने से पहले, हमें निम्नलिखित सवालों के जवाब देने में सक्षम होना चाहिए:

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

2. क्या कोई ड्राइवर एक ही दिन में कई शिफ्ट में काम कर सकता है?
   अगर ड्राइवर कैब एसोसिएशन का सदस्य है, तो वे सुबह काम कर सकते हैं, घर जा सकते हैं और उसी शाम फिर से काम कर सकते हैं। हालांकि, कुछ क्षेत्रों (जैसे न्यूयॉर्क शहर) में शिफ्ट की लंबाई और/या कैब ड्राइवर प्रतिदिन कितने घंटे काम कर सकते हैं, इस पर कानूनी प्रतिबंध हैं।

3. <मजबूत>3. सवारी कौन शुरू करता है?
   ज्यादातर मामलों में, ग्राहक टैक्सी कॉल सेंटर से संपर्क करेगा और डिस्पैचर सिस्टम में अपना अनुरोध दर्ज करेगा। एक अन्य परिदृश्य तब होता है जब ग्राहक सीधे कैब का आदेश देता है (उदाहरण के लिए, मोबाइल ऐप के माध्यम से) और इस प्रक्रिया में कोई कॉल सेंटर कर्मचारी शामिल नहीं होता है। एक तीसरा विकल्प - जो कॉल सेंटर को भी बायपास करता है - तब होता है जब कोई ग्राहक स्टेशन पर कैब लेता है या सड़क पर एक कैब लेता है।

डेटा मॉडल

हमारे मॉडल में दो मुख्य खंड और तीन अवर्गीकृत टेबल हैं। हम उनमें से प्रत्येक पर करीब से नज़र डालेंगे।

अनुभाग 1:कैब, ड्राइवर और शिफ्ट

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

हम driver टेबल। इस तालिका में, हम नाम, उपनाम और जन्म तिथि जैसी सामान्य विशेषताओं को शामिल करेंगे। हमारे पास कुछ विशेषताएं भी होंगी जो इस मॉडल के लिए काफी विशिष्ट हैं:

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

कई अन्य ड्राइवर-संबंधित विवरण हैं जिन्हें हम डेटाबेस में संग्रहीत कर सकते हैं:उपयोगकर्ता नाम और पासवर्ड, प्रत्येक ड्राइवर ने काम करना शुरू किया, और प्रत्येक ड्राइवर का वर्तमान रोजगार प्रकार। हम अभी इन विवरणों में नहीं जाएंगे क्योंकि वे विशेष रूप से इस मॉडल से संबंधित नहीं हैं। मैं उन्हें उपयोगकर्ता प्रशासन के अंतर्गत वर्गीकृत करता हूं, जो कि अधिकांश प्रणालियों में समान है।

अब, चलिए cab और car_model टेबल। यह वह जगह है जहां हम अपनी कंपनी द्वारा संचालित कारों की एक सूची संग्रहीत करेंगे। हम प्रत्येक वाहन के बारे में कुछ विवरण भी संग्रहीत करेंगे। इन दो तालिकाओं में सबसे महत्वपूर्ण विशेषताएँ हैं:

• model_description - यह एक टेक्स्ट विशेषता है जो एक निश्चित प्रकार की कार का कंपनी-निर्दिष्ट विवरण रखती है। उदाहरण के लिए, कैब कंपनियां एक कार में यात्रियों की संख्या, ट्रंक (बूट) स्थान और अन्य तथ्यों को संग्रहीत करना चाह सकती हैं।
• license_plate - लाइसेंस प्लेट पर नंबर (वाहन पंजीकरण प्लेट या नंबर प्लेट) विशिष्ट रूप से एक कार को कंपनी और सरकारी उद्देश्यों दोनों के लिए परिभाषित करता है। बेशक, अगर कार खरीदी या बेची जाती है, तो हमें लाइसेंस प्लेट की जानकारी बदलनी पड़ सकती है। इस तालिका में, हम केवल कंपनी के वर्तमान वाहनों को ही स्टोर करेंगे; अगर हमें इतिहास रखना है, तो हम अपने मॉडल में एक और टेबल जोड़ सकते हैं।
• owner_id - यह विशेषता driver टेबल। यह वैकल्पिक है क्योंकि हम इसका उपयोग केवल तभी करेंगे जब ड्राइवर अपनी कैब का मालिक होगा। (आमतौर पर कैब एसोसिएशन में ऐसा होता है)।
• active - यह एक बूलियन मान है जो दर्शाता है कि कंपनी अभी भी कार का उपयोग कर रही है या नहीं।

अंत में, आइए इस अनुभाग की सबसे महत्वपूर्ण तालिका पर एक नज़र डालें:shift टेबल। इस तालिका के पीछे का विचार कारों और ड्राइवरों के लिए वास्तविक कामकाजी घंटों और शेड्यूल शिफ्ट को स्टोर करना है। प्रत्येक शिफ्ट में कम से कम एक कैब होगी (cab_id ) और एक ड्राइवर (driver_id ) प्राथमिक कुंजी के अलावा, जो एक अद्वितीय शिफ्ट आईडी संख्या है, इस तालिका में ये एकमात्र अनिवार्य विशेषताएँ हैं।

shift_start_time और shift_end_time विशेषताएँ वास्तविक क्षण हैं जब एक पारी शुरू और समाप्त होती है। अक्सर, ये प्रीसेट होते हैं। यदि कोई शेड्यूल नहीं है, जैसा कि कैब एसोसिएशन में होता है, तो ये समय login_time के समान होगा। और logout_time गुण, क्रमशः। login_time और logout_time वास्तविक समय में ड्राइवर लॉग इन करते हैं (अपनी कार में मोबाइल डिवाइस के माध्यम से या टैक्सी कंपनी जिस भी तरीके का उपयोग करती है)। जब ड्राइवर सिस्टम में लॉग इन करता है, तो उपलब्ध सवारी की एक सूची दिखाई देगी, और ड्राइवर एक का चयन करेगा। बेशक, डिस्पैचर को भी सूचित किया जाएगा कि ड्राइवर अब काम कर रहा है।

अनुभाग 2:सवारी

यह खंड केवल दो तालिकाओं से बना है, लेकिन वे इस मॉडल के सच्चे दिल हैं।

cab_ride तालिका, हम प्रत्येक संभावित सवारी के लिए एक रिकॉर्ड संग्रहीत करेंगे। जो होता है उसके अनुसार हम इस रिकॉर्ड को अपडेट करेंगे। आइए विशेषताओं का त्वरित अवलोकन करें:

• shift_id - यह shift टेबल; यह हमें दी गई सवारी के लिए ड्राइवर और कैब विवरण प्रदान करता है।
• ride_start_time और ride_end_time - ये तब अपडेट होते हैं जब ड्राइवर संकेत देते हैं कि वे वर्तमान में व्यस्त हैं (राइड स्टार्ट) और बाद में फिर से उपलब्ध (राइड एंड)।
• address_starting_point और address_destination - ये वे स्थान हैं जहां एक सवारी शुरू होती है और समाप्त होती है। ड्राइवर शायद अपने टेबलेट या GPS पर नेविगेशन प्राप्त करने के लिए दोनों स्थानों की खोज करेगा, इसलिए संभव है कि जब हम इन दो विशेषताओं को अपडेट करेंगे।
• GPS_starting_point और GPS_destination - ये ऊपर वर्णित प्रारंभिक और समाप्ति स्थानों के जीपीएस निर्देशांक हैं। ये मान वैकल्पिक हैं क्योंकि हम इन्हें तभी अपडेट करेंगे जब हमारे पास डेटा होगा।
• canceled - यह एक साधारण हां/नहीं मान है जो हमें बताता है कि क्या कोई सवारी रद्द कर दी गई है। हमारे पास उस सवारी का रिकॉर्ड पहले से ही हमारी तालिका में होगा, इसलिए हम सवारी को रद्द के रूप में चिह्नित कर सकते हैं।
• payment_type_id और price - ये एक सवारी के लिए भुगतान की गई राशि और ग्राहक द्वारा उपयोग की जाने वाली भुगतान विधि के बारे में जानकारी प्रदान करते हैं।

cab_ride तालिका में NULL मान हो सकता है। इसके दो कारण हैं:

• सवारी रद्द हो जाती है, जिसका अर्थ है कि इन क्षेत्रों में कोई डेटा दर्ज नहीं किया जाएगा;
• भले ही हमारे पास अंततः सभी डेटा हो, लेकिन जब रिकॉर्ड शुरू में डाला जाता है तो हमारे पास यह सब नहीं होगा। हम प्रत्येक रिकॉर्ड को कई बार अपडेट करेंगे - बहुत कम से कम, जब सवारी शुरू होगी और समाप्त होगी (या रद्द हो जाएगी) तो हम इसे अपडेट करेंगे।

इस खंड में दूसरी तालिका cab_ride_status टेबल। यहां सिंगल राइड से जुड़े हर बदलाव के लिए एक रिकॉर्ड जोड़ा जाता है। जब डिस्पैचर सिस्टम में एक नई सवारी में प्रवेश करता है, तो वे cab_ride तालिका, लेकिन एक संबंधित रिकॉर्ड cab_ride_status तालिका (संबंधित स्थिति के साथ)। उस सवारी से संबंधित प्रत्येक परिवर्तन के बाद, इस तालिका में एक और रिकॉर्ड जोड़ा जाएगा। विशेषताएं हैं:

• cab_ride_id और status_id - ये विदेशी कुंजियाँ हैं जो ride status तालिका (जिसे हम नीचे कवर करेंगे)। दोनों अनिवार्य हैं।
• status_time - यह उस वास्तविक समय को संग्रहीत करता है जब रिकॉर्ड डाला गया था। यह भी अनिवार्य है।
• cc_agent_id और shift_id - ये उस कर्मचारी के संदर्भ हैं जिसने स्टेटस अपडेट डाला है। यह डिस्पैचर या ड्राइवर हो सकता है। संभवत:डिस्पैचर प्रारंभिक स्थिति सम्मिलित करेगा और चालक निम्नलिखित सभी स्थितियों को सम्मिलित करेगा।
• status_details - यह एक टेक्स्ट विशेषता है जिसका उपयोग अतिरिक्त जानकारी संग्रहीत करने के लिए किया जा सकता है। उदाहरण के लिए, एक डिस्पैचर सवारी के बारे में विशेष निर्देश रिकॉर्ड करने के लिए इस विशेषता का उपयोग कर सकता है।

अवर्गीकृत तालिकाएं

अंत में, आइए जल्दी से अपनी अवर्गीकृत तालिकाओं पर चलते हैं।

cc_agent तालिका में कॉल सेंटर एजेंटों या प्रेषकों की एक सूची है जो cab_ride और cab_ride_status टेबल.

status शब्दकोश में, हम उन सभी संभावित स्थितियों की एक सूची संग्रहीत करेंगे, जिन्हें हम किसी राइड को असाइन कर सकते हैं। कुछ मूल्यों में शामिल हैं “नई सवारी” , “ड्राइवर को दी गई सवारी” , “सवारी शुरू हुई” , “सवारी समाप्त” , या “सवारी रद्द” ।

Payment_type एक और शब्दकोश तालिका है। इसकी सामग्री का उपयोग payment_type_id . को अपडेट करने के लिए किया जाता है cab_ride टेबल। सामान्य मूल्य हैं “नकद” और “क्रेडिट कार्ड” ।

आप टैक्सी डेटा मॉडल को कैसे सुधारेंगे?

इस लेख में प्रस्तुत कैब/टैक्सी डेटाबेस मॉडल केवल सबसे महत्वपूर्ण कार्यात्मकताओं पर केंद्रित है। ऐसे कई सुधार हैं जो हम कर सकते हैं। मार्ग केवल एक है जिसके बारे में मैं सोच सकता हूँ।

भविष्य में, हमारे पास शायद ड्राइवर रहित कैब होंगी। उस स्थिति में, हम ड्राइवर को मॉडल से हटा देंगे और रिचार्ज और मरम्मत के समय जैसी चीजों को बदल देंगे।

बेझिझक टिप्पणी करें और अपने विचार जोड़ें।