क्रेग लर्मन की पुस्तक "अप्लाइंग यूएमएल विथ पैटर्न्स" इस समस्या के 3 सामान्य समाधानों का वर्णन करती है।
आपके उदाहरण विशेष रूप से सहायक नहीं हैं - आपके डेटाबेस में किसी व्यक्ति के नाम को प्रबंधित करने के 3 अलग-अलग तरीकों का कोई तार्किक कारण नहीं है (हालांकि यह डेटा आयात/निर्यात अजीबता के कारण नियमित रूप से होता है)।
हालांकि, वहां एक "व्यक्ति" इकाई होना बहुत आम है जो एक कर्मचारी (कर्मचारी_आईडी के साथ), एक संपर्क (संभावना तालिका के लिंक के साथ), या एक ग्राहक (एक ग्राहक_आईडी और ऑर्डर तालिका के लिंक के साथ) हो सकता है। .
लर्मन की पुस्तक में उन्होंने 3 समाधान दिए हैं।
उन सभी पर शासन करने के लिए एक तालिका यहां, आप सभी ज्ञात स्तंभों के साथ एक एकल तालिका बनाते हैं। यह एक गड़बड़ तालिका बनाता है, और प्रत्येक उपवर्ग को अनुप्रयोग परत पर बनाए रखने के नियमों को जानने के लिए जिम्मेदारी को धक्का देता है - डेटाबेस ग्राहकों के लिए ग्राहक_आईडी की आवश्यकता को लागू नहीं करेगा। हालांकि, यह जुड़ने को बहुत आसान बनाता है - किसी भी तालिका को किसी व्यक्ति से लिंक करने की आवश्यकता होती है, ठीक है, व्यक्ति तालिका से लिंक हो सकती है।
सुपरक्लास टेबल यह सामान्य विशेषताओं को एक ही तालिका में निकालकर चीजों को साफ करता है - उदा। "व्यक्ति" - और उपवर्ग-विशिष्ट क्षेत्रों को उपवर्ग तालिकाओं में धकेलता है। तो, आपके पास "व्यक्ति" सुपरक्लास तालिका के रूप में हो सकता है, और विशिष्ट उप-वर्ग डेटा के साथ "संपर्क", "कर्मचारी" और "ग्राहक" तालिकाएं हो सकती हैं। उपवर्ग तालिका में सुपरक्लास तालिका से वापस लिंक करने के लिए एक "person_id" कॉलम होता है। यह अधिक जटिल है - डेटा पुनर्प्राप्त करते समय इसे आम तौर पर अतिरिक्त शामिल होने की आवश्यकता होती है - लेकिन बहुत कम त्रुटि प्रवण - आप गलती से डेटा मॉडल को "कर्मचारी" के लिए अमान्य विशेषताओं को लिखने वाले बग से दूषित नहीं कर सकते हैं।
प्रति उपवर्ग तालिका - यह आपने वर्णन किया है। यह डेटा मॉडल में उचित मात्रा में दोहराव का परिचय देता है, और आपके पास अक्सर सशर्त जुड़ते हैं - "तालिका x पर शामिल हों यदि व्यक्ति प्रकार =y", जो डेटा एक्सेस कोड को मुश्किल बना सकता है।
