परिचय

इस डेटाबेस डिज़ाइन ट्यूटोरियल में दिखाया गया है कि किसी जटिल वास्तविक प्रोजेक्ट के लिए डेटाबेस टेबल्स कैसे डिज़ाइन किए जाएँ। हम Google Calendar का एक क्लोन डिज़ाइन करेंगे। यह श्रृंखला "Database Design using Minimal Modeling" पुस्तक के दृष्टिकोण को समझाती है। पहले हम कैलेंडर डेटा को समझाने वाला एक पूर्ण logical model बनाएँगे, फिर उसी logical model के आधार पर table design करेंगे.

लक्षित पाठक

इस पुस्तक का उद्देश्य आपको किसी अस्पष्ट विचार से डेटाबेस टेबल्स की पूर्ण परिभाषा तक पहुँचने में मदद करना है। पाठ का शुरुआती 3/4 हिस्सा केवल डेटाबेस की सामान्य समझ की माँग करता है और logical model को समझाता है। अंतिम 1/4 हिस्सा बताता है कि logical model से physical table structure तक कैसे पहुँचा जाए.

विषय-सूची

  • परिचय
  • इस पुस्तक का दृष्टिकोण
  • समस्या का विवरण
  • Part 1: बुनियादी all-day event
  • Part 2: time-based event
  • Part 3: recurring all-day event
  • Part 4: calendar page rendering
  • Part 5: time-based event का calendar page rendering
  • Part 6: अब तक का पूर्ण logical model
  • Part 7: SQL table creation
  • निष्कर्ष
  • अगले चरण

इस पुस्तक का दृष्टिकोण

लोग अक्सर table design से शुरुआत करते हैं, लेकिन हम एक अलग तरीका अपनाते हैं। पहले logical model लिखा जाता है और data attributes तथा entities के बीच संबंधों को परिभाषित किया जाता है। जब logical model तय हो जाता है, तब physical tables डिज़ाइन की जाती हैं.

समस्या का विवरण

हम Google Calendar की मुख्य सुविधाओं को लागू करेंगे। user-संबंधित डेटा को न्यूनतम रूप में लागू किया जाएगा। events में title, description, location जैसी properties होंगी। सबसे जटिल हिस्सा time और date है.

Part 1: बुनियादी all-day event

anchor

सबसे पहले हमें anchors ढूँढ़ने होंगे। anchor एक entity है, जैसे user(User) और event(Event)। anchor ID और counting को संभालते हैं.

user properties

हम user के लिए न्यूनतम डेटा मॉडल करेंगे। उदाहरण के लिए, email.

all-day event properties

हमें event name, start date, और end date को store करना होगा.

link

हमें यह तय करना होगा कि किस जगह यह जानकारी store की जाए कि किसी खास user ने किसी खास event को create किया। इसे property की बजाय link के रूप में संभाला जाएगा.

Part 2: time-based event

time zone

time zone कई देशों और क्षेत्रों में उपयोग होती है। time zone की definitions कभी-कभी बदलती रहती हैं। हम time zone से संबंधित एक न्यूनतम model लागू करेंगे.

time zone properties

हम time zone का मानव-पठनीय नाम store करेंगे.

time-based event properties

हम event name, start time, और end time store करेंगे। इसमें local time का उपयोग होगा.

link

time zone और time-based event के बीच link को परिभाषित किया जाता है.

date event और time event की समानताएँ

हम दोनों event types के बीच समानताओं पर विचार करेंगे। logical modeling के माध्यम से निर्णय को बाद तक टाला जा सकता है.

Part 3: recurring all-day event

property #1, interval

यह परिभाषित किया जाता है कि event कितनी बार दोहराया जाता है.

property #2, intertwined property

recurring event के interval को परिभाषित किया जाता है.

property #3

monthly event के मामले में यह परिभाषित किया जाता है कि वह उसी तारीख पर दोहराया जाए या उसी weekday पर.

weekday: micro-anchor

हम तय करते हैं कि weekday को कहाँ store किया जाए। इसके लिए एक नया anchor जोड़ा जाता है.

link

weekday और event के बीच link को परिभाषित किया जाता है.

पूर्णता की जाँच

यह जाँचने के लिए कि modeling पूरी हुई या नहीं, हम मूल requirements की फिर से समीक्षा करते हैं.

recurrence limit: और अधिक intertwined properties

यह परिभाषित किया जाता है कि event कब तक दोहराया जाएगा.

Part 4: calendar page rendering

अब तक हमने calendar के record वाले हिस्से पर चर्चा की है। अब हमें user का calendar week view दिखाने की आवश्यकता है.


GN⁺ की संक्षिप्त प्रस्तुति

यह ट्यूटोरियल जटिल डेटाबेस डिज़ाइन को चरण-दर-चरण समझाता है, जिससे शुरुआती पाठक भी इसे आसानी से समझ सकें। Google Calendar की मुख्य सुविधाओं को मॉडल करके यह ऐसे उपयोगी उदाहरण देता है जिन्हें वास्तविक प्रोजेक्ट्स में लागू किया जा सकता है। यह बताता है कि logical modeling के माध्यम से डेटाबेस डिज़ाइन की गलतियों से कैसे बचा जाए और कैसे यह प्रक्रिया स्वाभाविक रूप से physical table design तक पहुँचती है। इसी तरह की सुविधाओं वाले प्रोजेक्ट्स में Microsoft Outlook Calendar आदि शामिल हैं.

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.