डेटाबेस में मॉडलिंग विरासत

Question

डेटाबेस असाइनमेंट के लिए मुझे स्कूल के लिए सिस्टम तैयार करना होगा। आवश्यकताओं का एक हिस्सा कर्मचारियों, छात्रों और माता-पिता के लिए जानकारी मॉडल करना है।

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

मेरा प्रश्न है: मैं इसे डेटाबेस (mysql) में कैसे मॉडल करूं?

विचार अब तक इस प्रकार हैं:

1. कि प्रत्येक प्रकार के लिए सभी जानकारी शामिल है एक अखंड व्यक्ति तालिका बनाएँ और किस प्रकार संग्रहित किया जा रहा है पर निर्भर करता है शून्य मान के बहुत सारे होगा। (मुझे संदेह है कि यह व्याख्याता के साथ अच्छी तरह से नीचे जाएगा जब तक कि मैंने बहुत को तर्कसंगत रूप से तर्क दिया)।
2. तीन व्यक्तियों के साथ एक व्यक्ति तालिका जो उपप्रकारों का संदर्भ देती है लेकिन जिनमें से दो शून्य हो जाएंगी - असल में मुझे यह भी यकीन नहीं है कि क्या यह समझ में आता है या संभव है?

3. इस wikipage about django के अनुसार यह इस प्रकार उप-प्रकारों पर प्राथमिक कुंजी लागू करने के लिए संभव है:

   "id" integer NOT NULL PRIMARY KEY REFERENCES "supertype" ("id")

4. कुछ किसी और मैं के बारे में सोचा नहीं है ...

इसलिए उन है जो के लिए पहले डेटाबेस में मॉडलिंग विरासत; तुमने ये कैसे किया? आप किस विधि की सिफारिश करते हैं और क्यों?

लेख/ब्लॉग पोस्ट या पिछले प्रश्नों के लिंक स्वागत से अधिक हैं।

आपके समय के लिए धन्यवाद!

अद्यतन

ठीक उत्तर सभी के लिए धन्यवाद। मेरे पास पहले से ही एक अलग पता तालिका थी इसलिए यह कोई मुद्दा नहीं है।

चीयर्स,

एडम

Answer 1

4 टेबल कर्मचारियों, छात्रों, अभिभावकों और व्यक्ति सामान्य सामान के लिए। कर्मचारी, छात्रों और माता-पिता के पास फोर्ज कुंजी है जो प्रत्येक व्यक्ति को वापस संदर्भित करती है (दूसरी तरफ नहीं)।

व्यक्ति का क्षेत्र है जो इस व्यक्ति के उप-वर्ग (यानी कर्मचारी, छात्र या अभिभावक) की पहचान करता है।

संपादित करें:

रूप HLGM से कहा, पते एक अलग तालिका में मौजूद होना चाहिए, के रूप में किसी भी व्यक्ति को एक से अधिक पते हो सकता है। (हालांकि - मैं अपने आप से असहमत होने वाला हूं - आप जानबूझकर एक व्यक्ति को पते को बाधित करना चाहते हैं, मेलिंग सूचियों आदि के विकल्पों को सीमित करना)।

Answer 2

"जो लोग पहले एक डेटाबेस में भाग मॉडलिंग की है तो;? आप इसे कैसे क्या किया क्या विधि आप की सिफारिश करते हैं और यही कारण है "

तरीके 1 और 3 अच्छे हैं। अंतर आपके ज्यादातर मामलों में क्या हैं।

1) अनुकूलन - जो बदलना आसान है? अभिभावक तालिका में एफके संबंधों के साथ कई अलग-अलग टेबल।

2) प्रदर्शन - जिसके लिए कम शामिल होने की आवश्यकता है? एक एकल टेबल

चूहों। कोई डिजाइन दोनों को पूरा नहीं करता है।

इसके अलावा, आपके मोनो-टेबल और एफके-टू-पैरेंट के अलावा एक तीसरा डिज़ाइन है।

कुछ सामान्य कॉलम के साथ तीन अलग-अलग टेबल (आमतौर पर सभी सबक्लास टेबल के बीच सुपरक्लास कॉलम की कॉपी-पेस्ट)। यह बहुत लचीला और काम करने में आसान है। लेकिन, इसे एक समग्र सूची को इकट्ठा करने के लिए तीन तालिकाओं के एक संघ की आवश्यकता है।

Answer 3

अच्छी तरह से मुझे लगता है कि सभी दृष्टिकोण वैध हैं और किसी भी व्याख्याता जो इसे एक टेबल में खींचने के लिए चिह्नित करता है (जब तक कि आवश्यकताएं कहने के लिए विशिष्ट नहीं हैं) अपनी व्यक्तिगत राय के कारण एक व्यवहार्य रणनीति को हटा रहा है।

मैं अत्यधिक अनुशंसा करता हूं कि आप एनएचबेर्नेट पर प्रलेखन देखें क्योंकि यह उपरोक्त प्रदर्शन के लिए विभिन्न दृष्टिकोण प्रदान करता है। जो अब मैं तोते तोड़ने का प्रयास करूंगा।

आपके विकल्प:

• 1) सभी डेटा एक "सीमांकक" कॉलम है कि के साथ एक मेज। यह कॉलम बताता है कि व्यक्ति किस प्रकार का व्यक्ति है। यह सरल परिदृश्यों में व्यवहार्य है और (गंभीरता से) उच्च प्रदर्शन जहां जोड़ों को बहुत अधिक नुकसान पहुंचाएगा
• 2) प्रति वर्ग तालिका जो स्तंभों के दोहराव का कारण बनती है लेकिन फिर से जुड़ने से बचती है, इसलिए इसकी सरल और एक तेज़ तेज़ी से (हालांकि केवल एक लिल और इंडेक्सिंग अधिकांश परिदृश्यों में इसे कम करता है)।

• 3) "उचित" विरासत। सामान्य संस्करण। आप लगभग वहां हैं लेकिन आपकी कुंजी गलत जगह आईएमओ में है। आपका कर्मचारी तालिका एक PersonId को शामिल करना चाहिए, ताकि आप तो कर सकते हैं:

  चयन employee.id, कर्मचारी भीतरी से person.name employee.personId = person.personId

पर व्यक्ति में शामिल होने के सभी नामों को प्राप्त करने के लिए कर्मचारियों का नाम जहां केवल व्यक्ति तालिका पर निर्दिष्ट किया गया है।

Answer 4

ओओ डेटाबेस एक ही सामान के माध्यम से जाते हैं और बहुत अधिक विकल्पों के साथ आते हैं।

यदि बिंदु डेटाबेस में उप-वर्गों का मॉडल करना है, तो संभवतः आप वास्तविक ओओ डेटाबेस में देखे गए समाधानों (लाइनों को खाली छोड़कर) के बारे में सोच रहे हैं।

यदि नहीं, तो आप ऐसी प्रणाली बनाने के बारे में सोच सकते हैं जो इस तरह से विरासत का उपयोग नहीं करता है।

विरासत हमेशा कम इस्तेमाल किया जाना चाहिए, और यह शायद इसके लिए एक बहुत बुरा मामला है।

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

लेकिन फिर, यदि आप स्कूल में हैं, तो वे जो भी सिखाने की कोशिश कर रहे हैं उससे मेल नहीं खा सकते हैं ...

Answer 5

मैं # 3 के लिए जाऊंगा।

आपका लक्ष्य एक व्याख्याता को प्रभावित करना है, न कि पीएम या ग्राहक। अकादमिक नल और नापसंद (अव्यवस्थित रूप से) को नापसंद करते हैं जो आपको अन्य विधियों (जो नल पर भरोसा करते हैं) का उपयोग करने के लिए दंडित करते हैं।

और आपको जरूरी नहीं है कि django एक्सटेंशन (प्राथमिक कुंजी ... संदर्भ ...) इसके लिए एक सामान्य विदेशी कुंजी का उपयोग कर सकते हैं।

Answer 6

"सही" एक काम के प्रयोजनों के लिए इस सवाल का जवाब शायद # 3 है:

Person 
PersonId Name Address1 Address2 City Country 

Student 
PersonId StudentId GPA Year .. 

Staff 
PersonId StaffId Salary .. 

Parent 
PersonId ParentId ParentType EmergencyContactNumber .. 

कहाँ PersonId हमेशा प्राथमिक कुंजी, और भी पिछले तीन तालिकाओं में एक विदेशी कुंजी है।

मुझे यह दृष्टिकोण पसंद है क्योंकि यह एक से अधिक भूमिका रखने वाले व्यक्ति को प्रदर्शित करना आसान बनाता है। एक शिक्षक, माता-पिता भी बहुत अच्छा हो सकता है, उदाहरण के लिए।

Answer 7

मैं पांच टेबल व्यक्ति छात्र स्टाफ जनक पता सुझाव है

क्यों - लोगों के पास अनेक addesses हो सकता है और लोगों को भी अधिक भूमिकाएं हो सकती और जानकारी आप कर्मचारियों के लिए चाहते हैं के बारे में जानकारी से अलग है क्योंकि आप माता-पिता या छात्र के लिए स्टोर करने की आवश्यकता है।

आगे आप नाम के बजाय नाम को अंतिम_नाम, मध्य_नाम, first_name, name_suffix (जैसे जूनियर) के रूप में स्टोर करना चाहते हैं। मुझे विश्वास है कि आप last_name पर खोज करने में सक्षम होंगे! नाम अद्वितीय नहीं है, इसलिए आपको यह सुनिश्चित करना होगा कि आपके पास एक अद्वितीय सरोगेट प्राथमिक कुंजी है।

डेटाबेस बनाने की कोशिश करने से पहले सामान्यीकरण के बारे में पढ़ें। यहाँ एक स्रोत के साथ शुरू करने के लिए है: http://www.deeptraining.com/litwin/dbdesign/FundamentalsOfRelationalDatabaseDesign.aspx

Answer 8

सुपर प्रकार व्यक्ति इस तरह बनाया जाना चाहिए:

CREATE TABLE Person(PersonID int primary key, Name varchar ... etc ...) 

सभी उप प्रकार इस तरह बनाया जाना चाहिए:

CREATE TABLE IF NOT EXISTS Staffs(StaffId INT NOT NULL , 
    PRIMARY KEY (StaffId) , 
    CONSTRAINT FK_StaffId FOREIGN KEY (StaffId) REFERENCES Person(PersonId) 
) 

CREATE TABLE IF NOT EXISTS Students(StudentId INT NOT NULL , 
    PRIMARY KEY (StudentId) , 
    CONSTRAINT FK_StudentId FOREIGN KEY (StudentId) REFERENCES Person(PersonId) 
) 

CREATE TABLE IF NOT EXISTS Parents(PersonID INT NOT NULL , 
    PRIMARY KEY (PersonID) , 
    CONSTRAINT FK_PersonID FOREIGN KEY (PersonID) REFERENCES Person(PersonId) 
) 

उपप्रकार कर्मचारियों, छात्रों, माता-पिता में विदेशी कुंजी दो शर्तों को जोड़ती है:

1. व्यक्तिगत पंक्ति को हटाया नहीं जा सकता है जब तक कि संबंधित उप प्रकार पंक्ति हटाई नहीं जाएगी। उदाहरण के लिए यदि छात्र प्रविष्टि व्यक्ति प्रविष्टि को हटाए बिना व्यक्ति तालिका में संदर्भित तालिका में छात्र छात्र प्रविष्टि है, तो व्यक्ति प्रविष्टि को हटाया नहीं जा सकता है, जो बहुत महत्वपूर्ण है। यदि छात्र ऑब्जेक्ट बनाया गया है तो छात्र ऑब्जेक्ट को हटाए बिना हम आधार व्यक्ति ऑब्जेक्ट को हटा नहीं सकते हैं।

---

1. सभी आधार प्रकार हमेशा मौजूदा आधार प्रकार होगा सुनिश्चित करें कि प्रत्येक आधार प्रकार बनाने के लिए विदेशी कुंजी "रिक्त नहीं है"। उदाहरण के लिए यदि आप छात्र ऑब्जेक्ट बनाते हैं तो आपको पहले व्यक्ति ऑब्जेक्ट बनाना होगा।