तो आप अपना पहला डेटाबेस मॉडल बनाना चाहते हैं लेकिन आप नहीं जानते कि कैसे शुरू करें? आगे पढ़ें!
मुझे लगता है कि आप पहले से ही टेबल, कॉलम और संबंधों के बारे में कुछ जानते हैं। यदि आप नहीं देखते हैं, तो जारी रखने से पहले हमारे वीडियो ट्यूटोरियल देखें।
सिस्टम विवरण के साथ प्रारंभ करें
आपको हमेशा एक विवरण . के साथ एक डेटाबेस मॉडल बनाना शुरू करना चाहिए एक प्रणाली का। कक्षा की स्थिति में, एक शिक्षक द्वारा आपको एक प्रणाली विवरण दिया जाता है। वास्तविक जीवन में, विवरण तैयार करना एक प्रक्रिया है अपने ही अधिकार में। मैं बस यह मान लूंगा कि आपके पास विवरण है। इससे कोई फर्क नहीं पड़ता कि यह आपको आपके क्लाइंट, आपके बॉस, आपके शिक्षक द्वारा दिया गया था, या आपने इसे स्वयं लिखा था।
विवरण पर एक नज़र डालें और सभी संज्ञाओं को हाइलाइट करें . विवरण में संज्ञाओं को मोटे तौर पर तीन श्रेणियों में विभाजित किया जा सकता है:तालिकाएँ, विशेषताएँ और उदाहरण।
- टेबल्स सिस्टम में प्राथमिक संस्थाओं का प्रतिनिधित्व करते हैं:लोग, भौतिक वस्तुएं, घटनाएं, लेनदेन, आदि।
- विशेषताएं एक प्राथमिक इकाई से जुड़े गुण हैं। वे आपकी इकाई की विशेषताओं का वर्णन करते हैं। डेटाबेस मॉडल में वे आपकी तालिका के स्तंभ होंगे.
- उदाहरण बस यही हैं, उदाहरण। वे डेटाटाइप . को समझने में आपकी सहायता करते हैं कुछ विशेषताओं के और वे रिश्ते . को समझने में आपकी सहायता करते हैं विभिन्न संस्थाओं के बीच।
विवरण से शुरू करने से आपको उसी शब्दावली . का उपयोग करने के लिए बाध्य करने का लाभ मिलता है आपके उपयोगकर्ताओं के रूप में। यदि आप प्राथमिक विद्यालय के लिए एक प्रणाली बनाते हैं, तो आपको विद्यार्थियों के बारे में बात करनी चाहिए। यदि आप किसी विश्वविद्यालय के लिए समान प्रणाली बनाते हैं, तो आपको छात्रों के बारे में बात करनी चाहिए।
टेबल, संबंध, कॉलम
- एक बार जब आपकी संज्ञाएं हाइलाइट हो जाएं, तो तालिकाओं . की पहचान करें . आपको एक ही बार में सब कुछ मॉडल करने की ज़रूरत नहीं है। पहले सिस्टम की मुख्य कार्यक्षमता पर ध्यान दें।
- जब आपके पास टेबल हों, तो रिश्ते का पता लगाएं तालिकाओं के बीच। इस कदम से नई मध्यवर्ती (जंक्शन) तालिकाएँ शुरू हो सकती हैं।
- अंत में कॉलमजोड़ें टेबल पर।
इस बिंदु पर, आपको विवरण को फिर से पढ़ना चाहिए और देखना चाहिए कि कहीं कुछ छूट तो नहीं गया है। मैं आपको विश्वास दिलाता हूं कि जोड़ने के लिए कुछ होगा। नई तालिकाएँ, नए संबंध और नए स्तंभ जोड़ें। विवरण फिर से पढ़ें...
ध्यान रखने योग्य बातें
डेटाबेस मॉडल बनाना एक पुनरावृत्ति . है प्रक्रिया। एक बार में सब कुछ मॉडल करने का प्रयास न करें। अपने सिस्टम की मुख्य संस्थाओं से शुरू करें। आप बाद में और विवरण जोड़ सकते हैं।
प्रश्न पूछना ठीक है . विवरण कितना भी सटीक क्यों न हो, आपको हमेशा कुछ संदेह होगा। कुछ हमेशा कम निर्दिष्ट किया जाएगा। उन चीजों के बारे में प्रश्न पूछें जिनके बारे में आप निश्चित नहीं हैं। यदि आप प्रश्न नहीं पूछ सकते हैं, तो एक उचित धारणा बनाएं और अपने द्वारा की गई धारणा को नोट कर लें।
हमेशा एक से अधिक तरीके . होते हैं प्रत्येक प्रणाली को मॉडल करने के लिए। कुछ मॉडल स्पष्ट रूप से खराब हैं, लेकिन अधिकांश के साथ यह तय करना मुश्किल है कि वे सही हैं या गलत। मॉडल इस बात पर निर्भर करता है कि सिस्टम का उद्देश्य क्या है, सिस्टम में डेटा कैसे आता है, यहां तक कि डिजाइनर के व्यक्तिगत स्वाद पर भी। जैसे-जैसे आप अनुभव प्राप्त करेंगे, आप अपने डिज़ाइन निर्णयों के बारे में अधिक आश्वस्त होंगे।
उदाहरण:कार रेंटल सिस्टम
उदाहरण के तौर पर हम कार रेंटल सिस्टम के लिए एक डेटाबेस मॉडल बनाएंगे। सबसे पहले, सिस्टम के विवरण पर एक नज़र डालें:
एक कार रेंटल कंपनी ग्राहकों को कार किराए पर देती है। कंपनी के पास कई कारें हैं। प्रत्येक कार का एक ब्रांड, मॉडल का नाम, उत्पादन वर्ष, माइलेज, रंग आदि होता है। कारों को अलग-अलग श्रेणियों में बांटा गया है:छोटी, मध्यम आकार, बड़ी, लिमोसिन।
कंपनी के पास ऐसे कई स्थान हैं जहां आप कार किराए पर ले सकते हैं। किराये के स्थान देश भर के विभिन्न शहरों में स्थित हैं। एक शहर में एक से अधिक कंपनी स्थान हो सकते हैं।
21 साल से अधिक उम्र का कोई भी व्यक्ति जिसके पास वैध ड्राइविंग लाइसेंस है, वह कार किराए पर ले सकता है। 25 वर्ष से कम या 75 वर्ष से अधिक के ग्राहक अन्य ग्राहकों की तुलना में अलग (उच्च) शुल्क का भुगतान करते हैं।
कार किराए पर लेने से पहले, ग्राहक आमतौर पर कार के लिए आरक्षण करता है। एक ग्राहक उस तारीख को निर्दिष्ट करता है जब कार किराए पर ली जाएगी, पिक-अप स्थान, ड्रॉप-ऑफ स्थान और कार की श्रेणी जिसे वह किराए पर लेना चाहता है। एक ग्राहक निर्दिष्ट कर सकता है, कि वह कार में कुछ अतिरिक्त उपकरण चाहता है, उदाहरण के लिए एक जीपीएस, एक बच्चे के लिए एक कार सीट, आदि।
जब कोई ग्राहक कार किराए पर लेता है, तो वह पिक-अप और ड्रॉप-ऑफ़ स्थान और ड्रॉप-ऑफ़ तिथि की घोषणा करता है। ग्राहक विभिन्न प्रकार के बीमा खरीद सकता है। वह यह भी तय कर सकता है कि उसे बीमा की आवश्यकता नहीं है क्योंकि बीमा अन्यथा कवर किया गया है, उदाहरण के लिए उसकी क्रेडिट कार्ड कंपनी द्वारा। ग्राहक अतिरिक्त विकल्प चुन सकता है जैसे जल्दी ड्रॉप-ऑफ की संभावना, विभिन्न ईंधन भरने के विकल्प आदि।
जब ग्राहक कार लौटाता है तो वह शुल्क का भुगतान करता है।
हम सभी संज्ञाओं को हाइलाइट करके शुरू करते हैं:
अगला चरण तालिकाओं . को ढूंढना है . हम सिस्टम में बुनियादी संस्थाओं की तलाश करते हैं। एक शुरुआत के लिए, आपके पास कम से कम ये होने चाहिए:कार, ग्राहक, स्थान, शहर, उपकरण, (कार) श्रेणी, बीमा। हम उन्हें आरेख में डालते हैं। मैंने id
जोड़ा प्रत्येक तालिका में कॉलम क्योंकि प्रत्येक तालिका में किसी प्रकार की आईडी होनी चाहिए। आप प्राथमिक कुंजी को बाद में कभी भी बदल सकते हैं।
बुनियादी सिस्टम निकाय मॉडल में हैं लेकिन आपको ध्यान देना चाहिए कि हम सिस्टम की मुख्य कार्यक्षमता को याद कर रहे हैं:कार किराए पर लेना और आरक्षण करना। याद रखें कि हमने शुरुआत में क्या कहा था:टेबल न केवल भौतिक वस्तुएं हैं बल्कि घटनाएं और लेनदेन भी हैं। आपको reservation
जोड़ना चाहिए और rental
टेबल के रूप में भी। ये रहा:
अब हम मॉडल में तालिकाओं के बीच संदर्भ जोड़ते हैं। जैसे ही मैंने उन्हें जोड़ा, मैंने संदर्भों को क्रमांकित किया। प्रत्येक संदर्भ के आगे वाला नोट आपको बताता है कि इसे कब जोड़ा गया था:
- हर कार एक श्रेणी की होती है,
- हर आरक्षण कारों की एक श्रेणी के लिए है,
- प्रत्येक स्थान एक शहर में है,
- प्रत्येक आरक्षण में एक पिकअप और एक ड्रॉप ऑफ स्थान होता है,
- प्रत्येक आरक्षण एक ग्राहक द्वारा किया जाता है,
- हर रेंटल ग्राहक द्वारा लिया जाता है,
- हर रेंटल एक खास कार के लिए है,
- हर रेंटल का पिक अप और ड्रॉप ऑफ लोकेशन होता है।
- हर रेंटल किसी न किसी बीमा से जुड़ा होता है। लेकिन क्या प्रत्येक किराये के लिए केवल एक बीमा है? नहीं। किराये से जुड़े बीमा के कई टुकड़े हो सकते हैं (वाहन क्षति के खिलाफ बीमा, व्यक्तिगत चोटों के खिलाफ, किसी और की कार को घायल करने के खिलाफ, ...) मैंने
rental_insurance
. नामक एक मध्यवर्ती तालिका जोड़ी हैrental
. से जुड़ा है औरinsurance
टेबल.
हम अभी भी कार और उपकरण के बीच के संदर्भ को याद कर रहे हैं। क्या उपकरण स्थायी रूप से एक कार से जुड़ा होता है या इसे एक कार से दूसरी कार में ले जाया जा सकता है? विवरण में उस प्रश्न का कोई उत्तर नहीं है, इसलिए हम एक उचित धारणा बनाएंगे:हाँ, इसे स्थानांतरित किया जा सकता है। हम एक नई तालिका जोड़ते हैं car_equipment
और car
. के बीच संदर्भ और equipment
।
हम company
को हटा देते हैं टेबल। रेंटल कंपनी सिस्टम में निहित रूप से मौजूद है। आखिरकार, दूसरी कंपनी का अपना सिस्टम और अपना डेटाबेस होगा।
अंत में, हम कॉलम और उनके डेटाटाइप जोड़ते हैं। हम यह भी देखते हैं कि reservation
. के बीच कोई संबंध नहीं है और equipment
. लेकिन क्या आरक्षण किसी विशेष उपकरण के लिए किया गया है? नहीं, यह एक प्रकार के उपकरण के लिए बनाया गया है:हम तालिका जोड़ते हैं equipment_category
और टेबल कनेक्ट करें reservation
और equipment
इसके लिए।
हम कर रहे हैं? विवरण फिर से पढ़ें। हमारा डेटाबेस मॉडल अभी भी शुल्कों को छोड़ देता है। अच्छा...
पाठक के लिए यह एक अभ्यास है। (लेकिन अगर आपको अपने डेटाबेस मॉडलिंग कौशल का अभ्यास करने का मन नहीं है, तो यहां आप कार रेंटल कंपनी के लिए उपयोग के लिए तैयार डेटाबेस संरचना पा सकते हैं।)