मूवी थियेटर आरक्षण प्रणाली के लिए डेटाबेस मॉडल कैसे डिज़ाइन करें

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

हमें कुछ धारणाओं को ध्यान में रखना होगा:

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

आइए इस समस्या को हल करने के लिए एक संभावित डेटाबेस डिज़ाइन को देखें (मॉडल को MySQL डेटाबेस के लिए वर्टाबेलो के साथ बनाया गया था):

संक्षिप्त तालिका संरचना विवरण नीचे दिए गए हैं:

1. movie तालिका में फिल्मों के बारे में डेटा होता है जो थिएटर में दिखाया जाएगा। प्राथमिक कुंजी है id , जो अन्य सभी तालिकाओं में सभी प्राथमिक कुंजियों की तरह auto_incremented है। केवल अनिवार्य डेटा title है ।

   

   सभी क्षेत्रों का उनके नाम के अनुसार अर्थ होता है। कॉलम duration_min एक नई स्क्रीनिंग डालने को अक्षम करने के लिए या एक चेतावनी संदेश दिखाने के लिए इस्तेमाल किया जा सकता है अगर हम एक ऑडिटोरियम में एक स्क्रीनिंग में प्रवेश करना चाहते हैं जहां पिछली स्क्रीनिंग अभी भी प्रगति पर है:
   previous screening start time + duration_min of it > this screening start time

2. auditorium तालिका थिएटर में सभी सभागारों की पहचान करती है। सभी डेटा अनिवार्य है।

   

   seats_no फ़ील्ड का उपयोग चयनित स्क्रीनिंग/मूवी/ऑडिटोरियम/दिनांक सीमा के लिए सभागारों की उपलब्धता के प्रतिशत की गणना के लिए किया जा सकता है। यह डेटा अतिरेक का एक उदाहरण है क्योंकि हम प्रत्येक सभागार के लिए सीटों की संख्या seat टेबल। इस उदाहरण में यह प्रदर्शन में उल्लेखनीय सुधार नहीं कर सकता है। मैं इसे यहां एक विचार के रूप में दिखाता हूं जो अधिक जटिल मॉडल डिजाइन करने में मदद कर सकता है। यदि हम डेटाबेस को इस तरह से सेट करते हैं तो हमें यह ध्यान रखना चाहिए कि यदि हम डेटा के एक टुकड़े को बदलते हैं, तो हमें दूसरे को भी बदलना होगा। अगर हम seat . से डेटा जोड़ते या मिटाते हैं तालिका में हमें मूल्यों को समायोजित करना होगा seats_no auditorium टेबल।

3. screening तालिका में सभी स्क्रीनिंग का डेटा है और सभी फ़ील्ड अनिवार्य हैं। एक स्क्रीनिंग में एक संबंधित फिल्म, सभागार और प्रारंभ समय होना चाहिए। हम एक ही सभागार में एक ही समय में दो शो नहीं कर सकते। हम auditorium_id . से मिलकर बनी एक अद्वितीय कुंजी को परिभाषित कर सकते हैं और screening_start . यह सेटअप movie_id . की एक अनूठी कुंजी को परिभाषित करने से बेहतर है , auditorium_id , और screening_start क्योंकि इससे हम एक ही सभागार में एक ही समय में दो अलग-अलग फिल्मों की स्क्रीनिंग में प्रवेश कर सकेंगे।

   

   इस तालिका के लिए Vertabelo SQL पूर्वावलोकन कोड इस तरह दिखता है (नोटिस Screening_ak_1):

   -- Tables
   -- Table screening
   CREATE TABLE screening (
      id int    NOT NULL  AUTO_INCREMENT,
      movie_id int    NOT NULL ,
      auditorium_id int    NOT NULL ,
      screening_start timestamp    NOT NULL ,
      UNIQUE INDEX Screening_ak_1 (movie_id,auditorium_id,screening_start),
      CONSTRAINT Screening_pk PRIMARY KEY (id)
   );
   

4. seat तालिका में ऑडिटोरियम में हमारे पास मौजूद सभी सीटों की एक सूची है, जिसमें प्रत्येक सीट सख्ती से एक ऑडिटोरियम को सौंपी गई है। सभी फ़ील्ड अनिवार्य हैं।

   

5. reservation_type तालिका सभी प्रकार के आरक्षणों का एक शब्दकोश है (फोन द्वारा, ऑनलाइन, व्यक्तिगत रूप से)। सभी फ़ील्ड अनिवार्य हैं।

   

6. employee तालिका सिस्टम का उपयोग करने वाले सभी कर्मचारियों को सूचीबद्ध करती है। सभी फ़ील्ड अनिवार्य हैं।

   

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

7. reservation और seat_reserved टेबल हमारे सिस्टम की मुख्य टेबल हैं। यही कारण है कि मैंने उन्हें अंतिम सूचीबद्ध किया। अन्य सभी टेबल रिजर्वेशन टेबल के बिना मौजूद हो सकते हैं लेकिन रिजर्वेशन टेबल के बिना हम पूरे डेटाबेस को डिजाइन करने का कारण खो देंगे।

   

   reservation टेबल टिकट आरक्षण और/या बिक्री के बारे में डेटा संग्रहीत करता है। यदि हमारे पास आरक्षण है, तो विशेषता reserved सत्य पर सेट किया जाएगा, reservation_type_id आरक्षण के मूल और employee_reserved_id के अनुसार सेट किया जाएगा इसमें id_employee होगा डेटा दर्ज करने वाले व्यक्ति का मूल्य (यदि ग्राहक द्वारा ऑनलाइन आरक्षण किया गया होता तो यह खाली होगा)। उसी तरह, यदि टिकट बेचे गए थे, तो employee_paid_id id_employee . से भरा होगा टिकट बेचने वाले व्यक्ति का मूल्य, भुगतान की गई विशेषता को सही पर सेट किया जाएगा। सक्रिय विशेषता यह पहचानती है कि कोई रिकॉर्ड अभी भी मान्य है या नहीं। यदि टिकट बेचे जाते हैं तो यह विशेषता हमेशा सत्य होगी और बिक्री के बिना आरक्षण स्क्रीनिंग शुरू होने से 30 मिनट पहले तक सक्रिय रहेगा

   

   seat_reserved तालिका हमें कई सीटों के लिए आरक्षण या एक भुगतान करने में सक्षम बनाती है। कर्मचारी द्वारा इंटरफ़ेस पर कुछ निःशुल्क सीटों की जाँच करने के बाद, उनमें से प्रत्येक के लिए इस तालिका में एक रिकॉर्ड जोड़ा जाएगा। यदि हम यह जांचना चाहते हैं कि कौन सी सीटें निःशुल्क हैं या ली गई हैं तो हम reservation तालिका जहां reservation.active = True ।

यह ध्यान देने योग्य है:

• employee_reserved_id अनिवार्य नहीं है क्योंकि एक सीट के लिए आरक्षण मौजूद नहीं हो सकता है (सीट का टिकट पिछले आरक्षण के बिना बेचा जाता है) या ऑनलाइन किया जाता है
• reservation_type_id आरक्षण प्रकार की "आईडी" को संदर्भित करने वाली एक विदेशी कुंजी है। यह अनिवार्य नहीं है क्योंकि आरक्षण मौजूद नहीं हो सकता है (यदि हमने पिछले आरक्षण के बिना बिक्री की है)
• reservation_contact आरक्षण करने वाले व्यक्ति के डेटा को संग्रहीत करने के लिए एक टेक्स्ट इनपुट फ़ील्ड है, यह अनिवार्य नहीं है क्योंकि आरक्षण मौजूद नहीं हो सकता है (यदि हमने पिछले आरक्षण के बिना बिक्री की है)
• employee_paid_id बिक्री करने वाले उपयोगकर्ता से संबंधित है, यह अनिवार्य नहीं है क्योंकि बिक्री नहीं हुई होगी (सीट आरक्षित थी, आरक्षण स्वचालित रूप से रद्द कर दिया गया था, सीट बेची नहीं गई थी)
• paid एक ध्वज है जो इंगित करता है कि भुगतान हो गया है और अनिवार्य है (मान हां/सही या नहीं/गलत हो सकते हैं)

अंत में, ध्यान रखें कि कोई भी अपनी सीट पर किसी और को ढूंढना पसंद नहीं करता: