Case Studies of ER Modelling: Specialisation
- Siddharth Sharma
- Mar 6
- 3 min read
Quick Recap: Specialization एक Top-Down Approach (ऊपर से नीचे की ओर) है। जब डेटाबेस डिज़ाइनर के पास एक बड़ी Higher-level Entity (Superclass) होती है, लेकिन उसे लगता है कि इस Entity के कुछ रिकॉर्ड्स में कुछ खास (Specific) Attributes हैं जो बाकी रिकॉर्ड्स में नहीं हैं, तो वह उस बड़ी Entity को कई छोटी Lower-level Entities (Subclasses) में तोड़ (Divide) देता है।
Case Study 1: Library Management System (लाइब्रेरी मैनेजमेंट सिस्टम)
1. The Scenario (परिदृश्य): एक डिजिटल लाइब्रेरी अपने यहाँ मौजूद सभी प्रकार के आइटम्स का रिकॉर्ड रखने के लिए डेटाबेस बना रही है। डिज़ाइनर ने शुरुआत में सिर्फ एक ही Entity बनाई: Library_Item।
2. Before Specialization (स्पेशलाइजेशन से पहले):
Entity: Library_Item {Item_ID, Title, Publisher, Publish_Year, Author_Name, ISBN, Director_Name, Duration_Minutes}
3. The Problem (समस्या): लाइब्रेरी में किताबें (Books) और डीवीडी (DVDs) दोनों हैं। अगर आइटम कोई Book है, तो उसमें Director_Name और Duration_Minutes की वैल्यू खाली (NULL) रहेगी। अगर आइटम कोई DVD है, तो उसमें Author_Name और ISBN की वैल्यू खाली (NULL) रहेगी। डेटाबेस में बहुत सारे NULL values होने से स्पेस (Space) खराब होता है और प्रोसेसिंग धीमी हो जाती है।
4. The Solution using Specialization (समाधान): डिज़ाइनर ने एक Top-Down Approach का उपयोग किया और Library_Item को दो अलग-अलग Entities में स्पेशलाइज़ कर दिया।
Superclass Entity: Library_Item {Item_ID [Primary Key], Title, Publisher, Publish_Year}
Subclass Entities:
Book {Author_Name, ISBN}
DVD {Director_Name, Duration_Minutes}
अब डेटाबेस एकदम साफ (Clean) हो गया है। कोई भी अनावश्यक NULL value स्टोर नहीं करनी पड़ेगी।
Case Study 2: Hospital Staff System (अस्पताल कर्मचारी सिस्टम)
1. The Scenario (परिदृश्य): एक अस्पताल अपने स्टाफ का रिकॉर्ड रख रहा है। उनके पास एक मुख्य Entity है: Hospital_Staff।
2. Before Specialization (स्पेशलाइजेशन से पहले):
Entity: Hospital_Staff {Staff_ID, Name, Contact_No, Salary, Specialization_Field, Medical_License_No, Ward_Assigned, Shift_Timing}
3. The Problem (समस्या): स्टाफ में Doctors और Nurses दोनों शामिल हैं। एक Doctor के पास Medical_License_No और Specialization_Field (जैसे Cardiologist) होते हैं, लेकिन Nurse के पास यह नहीं होते। वहीं, एक Nurse की Shift_Timing और Ward_Assigned फिक्स होती है, जो सीनियर Doctors पर लागू नहीं होती।
4. The Solution using Specialization (समाधान): Hospital_Staff को उनके काम (Role) के आधार पर स्पेशलाइज़ किया गया:
Superclass Entity: Staff {Staff_ID [Primary Key], Name, Contact_No, Salary}
Subclass Entities:
Doctor {Specialization_Field, Medical_License_No}
Nurse {Ward_Assigned, Shift_Timing}
Case Studies of ER Modeling: Aggregation
Quick Recap: साधारण ER Model में हम दो Entities के बीच Relationship बना सकते हैं, लेकिन दो Relationships को आपस में नहीं जोड़ सकते। Aggregation में हम एक Relationship और उससे जुड़ी Entities को एक सिंगल बॉक्स (Virtual Entity) में बंद कर देते हैं, ताकि उस पूरे ब्लॉक को किसी तीसरी Entity के साथ जोड़ा जा सके।
Case Study 3: IT Project Management (आईटी प्रोजेक्ट मैनेजमेंट)
1. The Scenario (परिदृश्य): एक IT कंपनी में कई Employee अलग-अलग Project पर काम करते हैं। इसके अलावा, कंपनी के पास अलग-अलग Hardware_Device (जैसे Laptops, Testing Phones) हैं जो काम के लिए दिए जाते हैं।
2. The Initial ER Design (शुरुआती डिज़ाइन):
Employee और Project के बीच एक Relationship है: "Works_On"।
अब हमें यह ट्रैक करना है कि किस काम के लिए कौन सा हार्डवेयर दिया गया है।
3. The Problem (समस्या): हार्डवेयर सिर्फ Employee को नहीं दिया गया है (क्योंकि वह निजी इस्तेमाल के लिए नहीं है), और न ही वह सिर्फ Project को दिया गया है (प्रोजेक्ट कोई इंसान नहीं है जो डिवाइस यूज़ करे)। हार्डवेयर उस Employee को दिया गया है जो उस विशिष्ट Project पर काम कर रहा है। यानी, Hardware_Device का कनेक्शन "Works_On" रिलेशनशिप के साथ होना चाहिए, जो कि ER Model के नियमों के खिलाफ है (एक Entity का कनेक्शन रिलेशनशिप से डायरेक्ट नहीं हो सकता)।
4. The Solution using Aggregation (समाधान): डिज़ाइनर Aggregation का उपयोग करेगा:
वह Employee, Project, और उनके बीच के "Works_On" रिलेशनशिप को एक बड़े आयत (Rectangle) के अंदर रख देगा। इस पूरे ब्लॉक को एक Aggregated Entity मान लिया जाएगा।
अब इस बड़े ब्लॉक को Hardware_Device Entity के साथ एक नए Relationship (जैसे "Uses") के माध्यम से जोड़ दिया जाएगा।
Case Study 4: Job Interview System (जॉब इंटरव्यू सिस्टम)
1. The Scenario (परिदृश्य): एक कंपनी में जॉब इंटरव्यू चल रहे हैं।
एक Applicant (उम्मीदवार) किसी Job_Role (पद) के लिए अप्लाई करता है। उनके बीच "Applies_For" रिलेशनशिप है।
एक Interviewer (इंटरव्यू लेने वाला) उस इंटरव्यू को कंडक्ट करता है।
2. The Problem (समस्या): Interviewer सीधे केवल Applicant से नहीं जुड़ा है (क्योंकि वह उसी उम्मीदवार का इंटरव्यू किसी दूसरे रोल के लिए नहीं ले रहा)। वह इस बात से जुड़ा है कि उस उम्मीदवार ने उस विशिष्ट रोल के लिए जो अप्लाई किया है, उसका इंटरव्यू लेना है।
3. The Solution using Aggregation (समाधान):
Applicant, Job_Role, और उनके "Applies_For" रिलेशनशिप को एक साथ मिलाकर एक Aggregated Entity बना दिया जाता है।
अब इस पूरे ब्लॉक को Interviewer के साथ "Conducts" नाम के रिलेशनशिप से जोड़ दिया जाता है।
Summary (सारांश):
Specialization हमें अनावश्यक (Unnecessary) NULL वैल्यूज से बचाता है और डेटाबेस को अधिक स्पष्ट (Detailed) बनाता है।
Aggregation हमें बहुत ही जटिल (Complex) बिजनेस नियमों को ER डायग्राम में आसानी से दर्शाने की शक्ति (Power) देता है।
Comments