अवधारणात्मक ईआरडी मल्टी-टेबल कई से कई, या संभवतः पुनरावर्ती?

Question

मैं एक वैचारिक आरेख बना रहा हूं [हां, मुझे पता है कि मैंने विशेषताओं और कुंजियों को शामिल किया है - लेकिन यह सिर्फ मेरे लिए है कि मैं जो कुछ भी सीख रहा हूं, उसे समेकित करूं] - तो कृपया इसे रिश्ते और संबंधों पर ध्यान देने के साथ वैचारिक रूप में व्यवहार करें तालिकाओं और आरेख के लिए नहीं;)

मेरा मन बाधा है: मैं प्रोफाइल, स्थान और संगठन संबंधों को मॉडल करने का सबसे अच्छा तरीका पता लगाने की कोशिश कर रहा हूं।

सबसे पहले, नियम:

• एक या अधिक प्रोफ़ाइल के सदस्य एक या अधिक संगठनों के सदस्य / मित्र हो सकते हैं ; और इसके विपरीत।
• एक या अधिक प्रोफ़ाइल का सदस्य अन्य प्रोफ़ाइल का सदस्य / मित्र हो सकता है।
• एक या अधिक संगठन के अन्य संगठनों के सदस्य / मित्र हो सकते हैं।

मित्र और सदस्य अलग-अलग होते हैं, उस में, मित्र केवल पढ़ने के लिए होते हैं और सदस्य [स्तर के आधार पर] चीजों में संशोधन के लिए पूर्ण पहुंच रखते हैं।

चीजों को और अधिक जटिल करने के लिए, स्थानों के पास "आगे" परिष्कृत नियमों का अपना सेट होता है जैसे कि एक संगठन के पास दो स्थान होते हैं , लेकिन स्थान नियमों के आधार पर, उस संगठन का एक सदस्य [ प्रोफाइल ] एक स्थान पर पूर्ण पहुंच हो सकता है, लेकिन लोगों के लिए प्रतिबंधित पहुंच हो सकती है अन्य। [क्षमा करें: बेहतर देखने के आकार के लिए आपको संभवतः दूसरी विंडो में छवि को खोलना होगा।]

इसलिए जैसा कि आप देख सकते हैं, प्रोफ़ाइल और संगठनों की अवधारणा बहुत समान है, साथ ही साथ यह अभी तक मित्र और सदस्यों की मॉडलिंग की गई अवधारणा है [... जिसकी मैं कल्पना करता हूं कि मालिक की स्थापना के साथ वर्तमान मध्यस्थ तालिकाओं की तरह बहुत कुछ संभाला जाएगा। अभिलेख में व्यवस्थापक / सदस्य / मित्र आदि]। इसलिए, मैं निम्नलिखित अवधारणा के बारे में क्यों सोच रहा हूं:

उपरोक्त छवि में Option.2 देखें : जो वर्तमान संगठन और Organization_Locations टेबल्स और उनके रिश्तों को हटा देगा, यह Option.2 संगठन तालिका के साथ प्रोफ़ाइल के साथ कुछ पुनरावर्ती संबंध के रूप में प्रतिस्थापित करेगा ।

मुझे लगता है कि इस मामले की क्रूरता है कि क्या मैं पूरी तरह से प्रक्रिया में खुद को भ्रमित कर रहा हूँ, सादगी और लचीलेपन की गिरावट के लिए पॉलीमॉर्फिज़्म के साथ बहुत प्रोग्रामेटिक रूप से दिमाग लगा रहा हूं या नहीं;)

आपके विचारों के लिए अग्रिम धन्यवाद, बहुत सराहना की - एम :)।

संशोधित आरेख:

MDCCL के सवालों के जवाब में:

1. हाँ, प्रोफ़ाइल एक व्यक्ति से बना है और इसका एक ही अर्थ है - हालाँकि जहाँ आपका औचित्य है - मेरा मानना ​​है कि आप सही हैं: संगठन और व्यक्ति प्रोफ़ाइल के उपप्रकार हो सकते हैं ; इसलिए, एक प्रोफ़ाइल या तो एक व्यक्ति, या एक संगठन से बना है।
2. प्रति प्रोफ़ाइल एक ईमेल पता।
3. हाँ। ऊपर के रूप में, संगठन का कम से कम एक ईमेल पता होना चाहिए।
4. सही, एक निश्चित पता।
5. यह एक संभावना है, लेकिन एक दुर्लभता है - हालांकि मैं जो भी सीख रहा हूं, उससे - इसलिए भविष्य की दीर्घायु के लिए इस तरह का मॉडल होना चाहिए, और बस पुष्टि करने के लिए, एक स्थान इसलिए एक से अधिक व्यक्ति के स्वामित्व में हो सकता है।

6. स्थान निश्चित रूप से अधिकांश अन्य लोगों के बीच अभिन्न इकाई है। शायद मैं स्पष्ट कर दूंगा कि यहाँ क्या किया जा सकता है, तो आप पढ़िए, हालाँकि मेरे अन्य उत्तर जो इस प्रश्न से पहले लाभदायक जोड़ को उम्मीद करेंगे [ फिर अंत में # ६ पर मेरे उत्तर को देखें ];) पुन: भूमिका के स्वामी। An **Organization** can be an Owner of zero or more **Locations**. A Person can be an owner of zero of more Locations[इसलिए, जैसा कि आपने पहले बताया था; सीधे शब्दों में कहें, एक प्रोफ़ाइल शून्य या अधिक स्थान / s का स्वामी हो सकता है।

7. हां, एक प्रोफ़ाइल जो किसी स्थान का मालिक है वह सभी रोल अनुमतियों को मानता है [सुपर उपयोगकर्ता]; एक प्रोफ़ाइल जो एक व्यवस्थापक है , वह स्थान के कुछ विवरणों में संशोधन कर सकती है , लेकिन मुख्य रूप से अन्य सभी प्रोफाइलों के माध्यम से आपूर्ति किए गए विवरणों / डेटा को संपादित / संपादित करने में मदद करती है - यह मुख्य रूप से उक्त स्थान / एस के 'मूल सदस्य / सदस्यों द्वारा आपूर्ति की जाएगी ; जो मूल सदस्य को छोड़ देता है , जो केवल सभी संबंधित स्थान विवरणों को पढ़ सकता है और डेटा की आपूर्ति कर सकता है जिसे किसी व्यवस्थापक / स्वामी द्वारा जांच की जानी चाहिए । इसके अलावा, किसी भी प्रोफाइल[संगठन / व्यक्ति] एक मूल सदस्य 'केवल पढ़ने के लिए' की तरह है - चलो उन्हें अतिथि कहते हैं - लेकिन केवल अगर स्थान सार्वजनिक [और निजी नहीं ] के रूप में सेट है , हालांकि वे एक मूल सदस्य की तरह इनपुट की आपूर्ति नहीं कर सकते हैं ।

8. सही बात।
9. आपका अंतर्ज्ञान अद्भुत है! हां, it is foreseen that a single Location could contain one to many LocationTypes- चीजों को और अधिक जटिल करने के लिए - यह अनुमान लगाया जाता है कि उन व्यक्तिगत लोकेशनटाइप्स में 'पैरेंट' लोकेशन से जुड़ी प्रोफाइल के लिए अलग-अलग अनुमति हो सकती है; जिनमें से, अनुमतियाँ स्थान से स्थान स्थान / स्थान [OS OS सुरक्षा अनुमतियाँ] जैसी बहुत कुछ फ़िल्टर करेंगी। मैं अपने आरेख के माध्यम से ध्यान देता हूं कि आप एक विवरण के रूप में अधिक टाइप करने की बात कर रहे हैं?
10. हाँ।
11. 12 देखें।
12. सही है, के लिए की क्षमता Profile1 [व्यक्ति या संगठन] पर कार्रवाई करने के लिए PROFILE2 [व्यक्ति या संगठन] के स्वामित्व वाले स्थान [अगर वे सही अनुमतियां साथ हैं मित्र / सदस्य] सर्वोपरि है।
13. बहुत ही उचित - a) सहमत हैं। b) सहमत हैं। ग) हाँ, हम्म? ... शायद यह प्रोफाइल [व्यक्ति] प्रोफाइल [व्यक्ति] = दोस्तों के समान ही होना चाहिए । विवरण जो भी हो, यह स्थान के चारों ओर घूमता है , क्योंकि संगठन / संगठन अन्य संगठन स्थान / कार्य पर कार्य करेगा ; शब्दार्थ, मुझे संदेह है कि कोई भी संगठन उस स्थान के संगठन के 'सदस्य' के रूप में उपस्वास्थ्यकर को पेश करना चाहेगा, चाहे वह कितना भी अच्छा क्यों न हो।

[6]। यह अभी भी मेरे लिए एक ग्रे ग्रे है, लेकिन यहाँ जाता है ... संभवतः मेरे प्रतिबंध के लिए, सदस्य / मित्र संबंधों के बीच समानता इतनी करीब है कि मैंने उन्हें संयोजित करने के लिए सोचा; अपने आरेख और व्याख्या के साथ दृष्टि में, ऐसा प्रतीत होता है कि आप उन्हें अलग रखने के लिए सही हो सकते हैं [ मैं एनम संपत्ति के माध्यम से एकल संबंध को अलग करने जा रहा था: मालिक / व्यवस्थापक / सदस्य / मित्र ]। उदाहरण के रूप में आपकी अवधारणा: एक संगठन के स्वामित्व वाले एक स्थान पर कई प्रोफ़ाइल [व्यक्ति या संगठन] के लिए शून्य होगा, हालांकि प्रोफाइल के संबंध के माध्यम से स्थान पर कार्य करने के बीच एक स्पष्ट अंतर होना चाहिए [सदस्य या मित्र ] Roles के माध्यम से चिह्नित।So perhaps, the default relation between any Profile is Friend [much like Guest at Answer#7], enabling them to view the read-only Location data and msg/email the Location Owner/Admin - but not allow them to receive Location updates, news, etc., as a Member would.

Comments

अपने ERD उदाहरण बनाने के लिए आपने किस सॉफ्टवेयर का उपयोग किया?

— एलियास

Microsoft Visio;)

— MVC नौसिखिया

Answer 1

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

प्रारंभिक डेटा मॉडल और व्यापार नियम ग्रहण किया

मैंने आपके नियमों को समझने के बाद आपके विवरणों को समझने के लिए, आपके द्वारा पढ़े गए और आपके आरेखों की बारीकी से जांच करने के बाद अपने द्वारा ग्रहण किए गए व्यावसायिक नियमों की एक सूची को परिभाषित किया है। इस तरह की सूची को परिभाषित करने के बाद, मैंने एक IDEF1X ^[1] डेटा मॉडल प्राप्त किया, जिसे मैंने एक बाहरी प्लेटफॉर्म (ड्रॉपबॉक्स) में .PDF दस्तावेज़ के रूप में अपलोड करने का फैसला किया था, क्योंकि इसके प्रारूप के कारण यह डेटा मॉडल एक एम्बेडेड छवि में अच्छी तरह से फिट नहीं होता है। ये दो साधन कुछ महत्वपूर्ण बिंदुओं के संदर्भ के रूप में उपयोगी होने वाले हैं, जिन्हें मैं आगे बढ़ने के लिए हल करने के लिए नीचे दिए गए ऐस्पेक्ट्स नामक खंड में गणना करता हूं ।

सबसे पहले, यहाँ है ...

• संगठन और प्रोफाइल प्रारंभिक डेटा मॉडल ।

चूंकि यह केवल यही है, प्रारंभिक, इसे एक ऐसा साधन मानें जो हमें वांछित अंतिम डेटा मॉडल को तैयार करने में मदद करता है।

मान लिया व्यावसायिक नियम

कहा कि प्रारंभिक डेटा मॉडल व्यावसायिक नियमों (आपके प्रश्न से अनुमानित) के संग्रह से लिया गया है, जिसे मैं इस प्रकार समझूंगा:

संगठन और प्रोफाइल

ध्यान दें कि Profileवर्तमान में इसके लिए एक पर्याय के रूप में समझा जाता है Person।

• एक -से-Organization एक का मित्र है । Profiles
• एक -से-Organization एक का मित्र है । Organizations
• एक -से-Organization एक का सदस्य है । Organizations
• A एक-से-Profile एक का सदस्य है ।Organizations
• A Profile, टू-वन का मित्र है Profiles।
• A एक-से-Profile एक का सदस्य है । Profiles

स्थान और पते

• एक एक-से-कईOrganization का मालिक है । Locations
• ए Locationको एक-से-कई LocationTypes ( केवल एक दिए गए बिंदु पर एक समय में) द्वारा वर्गीकृत किया जाता है ।
• एक Locationहो सकता है एक-से-कई Addresses ( एक Physical , एक के लिए Shipping, एक के लिए Billing, या एक है कि सभी ने कहा उद्देश्यों को पूरा करती, या एक है कि जोड़ती दो उद्देश्यों और एक और है कि कार्य करता है केवल एक उनमें से)।

• एक -से-कईAddress द्वारा रखा जा सकता है या, एक और तरीका है, एक-से-कई रखता है । ProfilesProfile Addresses

• एक विशिष्ट Addressद्वारा इस्तेमाल किया जा सकता है एक-से-कई Profiles (के रूप में सेवारत Physicalके लिए एक Profile , के लिए इस्तेमाल किया जा रहा Billingद्वारा एक अलग से एक , आदि)। तो, के Addressलिए एक समान तरीके से काम करता है Locationsऔर Profiles।

  • इस प्रकार, एक व्यक्ति एक ही समय में , प्रकार का Addressहो सकता है , और ।PhysicalShipping Billing

स्थान और भूमिकाएँ

• A एक-से-कईLocation खोलता है । Roles
• एक से कईRole में किया जा सकता है । Locations
• एक Profile(एक बार यह के रूप में स्थापित किया गया है Memberएक के Organization) बाहर ले जाने के कर सकते हैं एक-से-कई Roles , में एक-से-कई Locations (लेकिन केवल एक विशिष्ट Roleप्रत्येक में Locationसमय में एक खास बिंदु पर, यानी, कभी नहीं दो या अधिक Roles एक ही समय में )।

आगे बढ़ने के लिए हल करने की आकांक्षा

अपने डेटा मॉडल के रिज़ॉल्यूशन में आगे बढ़ने के लिए, यहां प्रासंगिक बिंदुओं की एक सूची दी गई है, जो एक बार हमें काम करने के बाद इस लक्ष्य तक पहुंचने में हमारी मदद करने जा रहे हैं:

1. मैंने मान लिया है कि Profileआपके संदर्भ में इस शब्द का एक जैसा (या समान) अर्थ है Person, लेकिन यह थोड़ा अलग हो सकता है। इस तरह, क्या आप कहेंगे कि आपके परिदृश्य में, निकाय Organizationऔर Personउपप्रकार हैं Profile?

2. क्या एक Profile(या Person) खुद को एक-से-कई कर सकता है EmailAddresses , या एक Profile(या Person) बिल्कुल एक के लिए तय है EmailAddress?

3. क्या आप के Organizationमाध्यम से संपर्क किए जाने की संभावना प्रदान करना चाहते हैं Telephoneऔर Email, या आप केवल Profile(या Person) के लिए संभव होना चाहते हैं?

4. मुझे लगता है कि एक सही प्रकार से एक के लिए Locationतय है , क्या यह सही है? AddressPhysical

5. क्या यह एक-से-कई अलग - अलग Locationद्वारा साझा किया जाना संभव है या , अन्यथा, केवल एक के स्वामित्व में हो सकता है ?Organizations Location Organization

6. आपने टिप्पणियों के माध्यम से कहा है कि एक Memberऔर एक होने का तथ्य Friendसमान है। जैसा कि आप मेरे प्रस्तावित प्रारंभिक डेटा मॉडल में देख सकते हैं, मैंने आपको मूल विनिर्देशों का पालन किया और विभिन्न संस्थाओं में सदस्यता Organizationऔर Profile(या Person) के सभी संभावित संयोजनों का चित्रण किया क्योंकि मुझे लगता है कि यह सबसे अच्छा संभव परिभाषित करने के प्रयास में सहायक हो सकता है आपके परिदृश्य के उस हिस्से के लिए संरचना। किस अर्थ में:

   • मैं यह मानता हूं कि an Organization is a Member of another Organizationकथन a Profile (or Person) is a Member of an Organizationमें इकाई के संबंध में कथन की तुलना में कथन का अलग-अलग प्रभाव है Location।
   • आप डेटा मॉडल में देख सकते हैं, मुझे लगता है कि Roleके Ownerएक लिए ही मान्य है Organization, और, मेरे लिए मान्य Rolesके लिए एक Profile(या Person), अंदर एक Locationहैं Adminऔर Member। आपका इन सभी के बारे में क्या विचार है? चूंकि आप उन व्यावसायिक नियमों के सीधे संपर्क में हैं जो आपकी स्थिति पर लागू होते हैं, तो आपको यह बताने की आवश्यकता है कि क्या मेरी धारणा सही है।

7. क्या एक Profile(या Person) Rolesसमान के अंदर अलग-अलग खेल सकते हैं Location? यानी, एक कर सकते हैं Personएक ही समय में हो सकता है, Adminऔर यह भी एक Memberही की Location? इस संबंध में क्या नियम हैं?

8. मुझे लगता है कि एक ही Profile(या Person) विभिन्न खेल सकते हैं Rolesअलग में Locations। उदाहरण के लिए: एक विशिष्ट Profile(या Person) Location"1 " में "व्यवस्थापक" है , और यह एक ही Profile(या Person) "2" में एक ही समय Memberमें एक " " है Location। क्या मैं सही हू?

9. क्या किसी विशेष के लिए एक ही समय में Locationअलग-अलग होना संभव है LocationTypes, या क्या किसी व्यक्ति Locationको ठीक एक धारण करने के लिए तय किया गया है LocationType?

10. क्या विशेषता Organization.Websiteकिसी विशेष संगठन के वेबसाइट पते का प्रतिनिधित्व करती है, जैसे "dba.stackexchange.com"?

11. यदि Profile"1" (समझा जाता है Person) "2" का Member(या Friend) है Profile, तो क्या Profile"1" के लिए "2" के स्वामित्व Roleमें होना संभव है ? मेरा मानना ​​है कि इस तरह के परिदृश्य केवल एक और एक के बीच संबंधों के लिए मान्य हैं , आपको क्या लगता है?LocationProfileOrganizationMember Person

12. इसी तरह, अगर में Organization"1" एक है Member(या Friend) की Organization"2", इसके लिए संभव है Organization"1" बाहर ले जाने के लिए एक Roleएक में Locationके स्वामित्व में Organization"2"? फिर से, मुझे लगता है कि इस तरह के परिदृश्य केवल Organizationए और ए के बीच के रिश्तों के लिए मान्य हैं Member Person, क्या यह सही है?

13. इस संबंध में - मैं यह प्रश्न लिख रहा हूं- मुझे लगता है कि यह कहना उचित होगा कि इसमें केवल तीन अलग-अलग प्रकार के रिश्ते शामिल हैं Organizationsऔर Persons, और हम परिभाषित कर सकते हैं:

    • (ए) एक Organizationऔर एक Person" Membership" के बीच संबंध ।
    • (बी) "और " के रूप में एक Personऔर अलग के बीच संबंध ।PersonFriendhip
    • (ग) हमें अभी तक एक व्यक्ति और दूसरे के बीच संबंधों का वर्णन करने के लिए एक सार्थक नाम मिल गया है ।OrganizationOrganization
    • तो, मुझे पता है कि आप (ए), (बी) और (सी) के बारे में क्या सोचते हैं।

14. क्या यह संभव है एक के लिए Organizationएक होने के लिए Friend(या एक Memberका) एक-से-कई अलग अलग Organizationsएक ही समय में? या यह केवल विशेष रूप से एक अलग के Organizationसाथ एक संबंध रखने के लिए ही संभव हैOrganization?

पहला अग्रिम दर्शाते हुए क्रमिक डेटा मॉडल

ऊपर सूचीबद्ध किए गए लंबित पहलुओं पर आपकी प्रतिक्रियाओं और प्रस्तावों पर ध्यान देने के बाद, मैंने निम्नलिखित बनाया है ...

• संगठन और प्रोफाइल प्रारंभिक डेटा मॉडल - पहला अग्रिम ।

हालाँकि मैं अभी तक इसके साथ बहुत सहज महसूस नहीं करता, लेकिन यह नया डेटा मॉडल निम्नलिखित व्यावसायिक नियमों को व्यक्त करता है:

• एक Profileहै या तो एक Organization या एक Person। ^[2]
• एक Profileकी भेंट दोस्त हो सकता है एक-से-कई FriendProfiles हैं, और एक Profileके स्वीकार करने दोस्त हो सकता है एक-से-कई FriendProfiles । ^[3]
• एक में कईLocation शामिल हो सकते हैं । ^[4] Locations

आपकी बाद की विशिष्ट टिप्पणियों के उत्तर

यह मेरे लिए वास्तव में दिलचस्प है कि मैं चिंताओं के अलगाव को नोट / यौगिक कर सकूं [जैसे कि LocationAddress और ProfileAddress] - क्योंकि मैं स्पष्ट रूप से सही रिश्तों के बिना उन सभी को पकड़ना चाहता था और [funnily, यह मेरे मूल ERD के साथ सही नहीं लगा]।

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

अपने व्यक्तिगत अनुभव से, मैं समझता हूं कि इस चरण को अपने पूरे संदर्भ में महत्वपूर्ण चीजों को डालने के साथ करना है, यह उन संघों को देखने के साथ करना है जो विभिन्न संस्थाओं के बीच मौजूद हैं जो ब्याज के विशेष परिदृश्य में प्रासंगिकता के हैं, और फिर डेटा मॉडल में इन चीजों का चित्रण। जिस विशिष्ट मामले के बारे में आप टिप्पणी कर रहे हैं, उस Addressइकाई में अन्य संस्थाओं के साथ विभिन्न प्रकार के कनेक्शन हो सकते हैं, एक के साथ Profileऔर एक अलग के साथ Location।

और, हां, जब कुछ सही या स्वाभाविक नहीं लगता है , तो यह अच्छी तरह से एक संकेत हो सकता है कि किसी को प्रासंगिक डेटा को समझने के लिए अधिक प्रयास करने की आवश्यकता है। इस तरीके से, Addressइकाई उन चीजों में से एक है, जिन पर मैं विचार करता हूं, जिन पर अधिक ध्यान देने की आवश्यकता है, क्योंकि मुझे लगता है कि ए Profileऔर के बीच के रिश्ते को इकाई के माध्यम से नियंत्रित किया जा Address सकता है Location(इस तथ्य के कारण कि प्रत्येक Locationमें कम से कम एक भौतिक होना चाहिए Address), इसलिए हम नवीनतम मॉडल में चित्रित सहयोगी संस्था को खारिज कर सकते हैंProfileAddress , लेकिन आपको इन बिंदुओं को जारी रखना चाहिए और मुझे अपने विचारों से अवगत कराना चाहिए।

इसके अलावा, बेहतर पठनीयता [जैसे ProfileId - LocationOwnerProfileId] के लिए संस्थाओं में PK / FK संप्रदायों को बदलने के लिए IDEF1X में यह आम बात है?

हां, यह आपसे एक बहुत ही चतुर टिप्पणी है, क्योंकि IDEF1X फ़ॉरऑनडॉग कुंजियों को निरूपित करने के लिए भूमिका नामों के उपयोग की सिफारिश करता है , ताकि इकाई के अनुसार ऐसी विशेषताओं के अर्थ को कैप्चर किया जा सके जिसमें इसका उपयोग किया जा रहा है। यह भी ध्यान देने योग्य है कि यह भी प्राथमिक कुंजी प्रवासन की अवधारणा से दृढ़ता से संबंधित है । वास्तव में, भूमिका नाम का उपयोग IDEF1X से पहले है, क्योंकि यह मूल रूप से डॉ। ईएफ कोडड द्वारा अपने 1970 के सेमिनल पाठ में प्रस्तुत किया गया था। इस तरीके से, कोई स्पष्ट रूप से निष्ठा देख सकता है कि आईडीईएफ 1 एक्स मानक रिलेशनल मॉडल की ओर रहता है ।

मैं यह जानने के लिए आतुर हो जाऊंगा कि आपको क्या पसंद नहीं है / ऐसा नहीं लगता कि यह समाधान में / साथ मॉडल नहीं करता है?

Addressइकाई के बारे में पहले से ही वर्णित विवरणों के अलावा , मुझे यकीन नहीं है कि किसी विशेष में Rolesदिए गए द्वारा किए गए एक या एक के लिए बराबर हैं । मेरे दृष्टिकोण से, पहले एक के साथ जुड़े होने की जरूरत है , और फिर यह नियुक्त करेगा एक विशेष रूप से प्रदर्शन करने के लिए कहा , लेकिन आप परिदृश्य को बेहतर जानते हैं, इसलिए यह नियम अनावश्यक हो सकता है। इस संबंध में, मैं इस तथ्य के बारे में बात पर जोर देना है कि यह मुझे प्रासंगिक वर्णन या पता करने के लिए के लिए बहुत मददगार होगा जा रहा हूँ अर्थ है कि करने के लिए इस डेटा संरचना दे के भविष्य के उपयोगकर्ताओं , औरProfileLocationOrganizationPersonPersonOrganizationOrganizationPersonRoleLocationOrganizationProfileLocation, लेकिन मैं समझता हूं कि इसे गोपनीय जानकारी माना जा सकता है, इसलिए यह एक सीमा होगी।

वर्तमान संरचना के साथ, ऐसा लगता है कि हर कोई ( Organizationया Person) किसी से संबंधित हो सकता है (फिर से, Organizationया Person) और Roleकहीं भी / (कुछ भी ) कर सकता है ( Locationलेकिन), perharps, यह प्रिसिसेली है जिसे आप और उपयोगकर्ता इस डेटाबेस से उम्मीद कर रहे हैं जिसके लिए आप निश्चित रूप से अच्छी तरह से परिभाषित बाधाओं को प्रदान करेंगे। यदि यह मामला है, तो हम लगभग एक अंतिम समाधान प्रदान कर रहे हैं। चूंकि, स्वाभाविक रूप से, आपकी राय इस स्थिति में निर्णायक है, आपको इस विचारों को भी मानना ​​चाहिए और फिर मुझे अपने निष्कर्षों को बताना चाहिए ताकि हम अंतिम कदम उठा सकें।

संभव दूसरी अग्रिम

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

इस प्रश्न और उत्तर प्रक्रिया में पहले से ही जो प्रस्तुत किया गया है, इसके अलावा, मैं मानता हूं कि पिछले डेटा मॉडल से एक नई प्रगति प्रदान करना अन्य साधकों के लिए एक समान समस्या के लिए सहायक हो सकता है। तो, मैंने बनाया है ...

संगठन और प्रोफाइल प्रारंभिक डेटा मॉडल - दूसरा अग्रिम

जैसा कि इस तरह के डेटा मॉडल में देखा जा सकता है, मैंने उन कई-से-कई संबंधों को हटा दिया है, जिन्हें मैंने पहले Profileऔर Addressबाद के मॉडल में दर्शाया है , क्योंकि किसी दिए गए Profileपहले से ही कई Addresses स्वामित्व से संबंधित है Locations।

एक और परिवर्तन जो इस नई अग्रिम में चित्रित किया गया है, वह यह है कि इसमें अब संभावना है कि किसी दिए Locationगए एक-से-कई स्वामित्व हो सकते हैं Profiles। नतीजतन, मैंने Locationप्राथमिक कुंजी ( LocationOwnerProfileIdविशेषता को खारिज करके ) को बदल दिया है और फिर एक सहयोगी संस्था ( कई-से-कई ) को जोड़ा है जो कि संबंधित Profileहै Location।

टिप्पणियाँ

_{1. आईडीईएफ 1 एक्स एक अत्यधिक अनुशंसित डेटा मॉडलिंग तकनीक है जिसे यूएस नेशनल इंस्टीट्यूट ऑफ स्टैंडर्ड एंड टेक्नोलॉजी ( एनआईएसटी ) ने 1993 में एक मानक के रूप में परिभाषित किया था ।}

_{2. यह एक (सुपर) प्रकार-उप-प्रकार क्लस्टर का एक ऑयर्स है । यदि आप रुचि रखते हैं, तो यहां एक जवाब है जिसमें मैं इस तरह के संबंधों के साथ अधिक विस्तृत तरीके से व्यवहार करता हूं।}

_{3. कई-से-कई पदानुक्रमित संबंधों का एक उदाहरण है , और संरचना के लिए बहुत अनुकरणीय है जिसने "पार्ट्स एक्सप्लोरेशन समस्या" का निश्चित समाधान दिया है । इस तरह का समाधान, निश्चित रूप से डॉ। एडगर फ्रैंक कॉड द्वारा अपने 1970 के व्यापक प्रभावशाली पेपर "बड़े साझा डेटा बैंकों के लिए डेटा का एक संबंधपरक मॉडल" में पेश किया गया था ।}

_{4. जैसे, यह एक-से-कई (या कई-से-एक) पदानुक्रमित संबंध का एक उदाहरण है ।}

Comments

कृपया मेरे संशोधित प्रश्न पर ध्यान दें जिसमें आपके प्रश्नों के उत्तर हैं। मुझे पता है कि व्यक्तिगत पत्राचार dba द्वारा परिलक्षित होता है - लेकिन मुझे आशा है कि जब वे कहते हैं कि वे मुझे लिप्त कर सकते हैं - "आपकी प्रतिक्रिया सबसे कुशल और उपयोगी जोड़ है जो मैंने कभी भी किसी भी प्रश्न के लिए प्राप्त किया है," - तो सभी के लिए एक बड़ा हार्दिक धन्यवाद आपके प्रयास इस प्रकार अब तक, मैं वास्तव में विनम्र और प्रशंसनीय हूँ! [... और अगर यह अभी और भविष्य में कई अन्य सदस्यों की मदद नहीं करता है, तो मैं अपना कीबोर्ड खाऊंगा;)]

— MVC नौसिखिया

Answer 2

मुझे लगता है कि आप ऑब्जेक्ट मॉडलिंग से और डेटा मॉडलिंग से अवधारणाओं को एक साथ मिलाने की कोशिश कर रहे हैं जो आपको समस्या की अपनी समझ को स्पष्ट करने में मदद नहीं कर रहा है। मुझे आशा है कि मैं अव्यवस्था के बिना थोड़ा अव्यवस्था को साफ कर सकता हूं।

संबंधपरक मॉडल, जैसे, विरासत का समर्थन नहीं करता है, कभी भी बहुरूपता का मन नहीं करता है। इसका मतलब यह है कि एक विशेष रूप से डिज़ाइन किए गए डिज़ाइन पैटर्न का उपयोग तब किया जाता है जब किसी वास्तविक जीवन की स्थिति को मॉडलिंग करना जो किसी ऑब्जेक्ट मॉडल में आसानी से विरासत और बहुरूपता द्वारा नियंत्रित किया जाता है। बाद में उस विशेष डिजाइन पैटर्न पर और अधिक।

जब ईआर मॉडल पहली बार विकसित किया गया था, यह संबंधपरक मॉडलिंग के लिए एक कार्यान्वयन अज्ञेय विकल्प माना जाता था। पहले तो, इसमें विरासत जैसा कुछ भी नहीं था। लेकिन 1980 या 1990 के दशक में कुछ समय, मॉडल को कुछ समान अभिव्यंजक क्षमताओं को प्रदान करने के लिए बढ़ाया गया था जो आपको विरासत के साथ मिलती हैं। इसे "विस्तारित ईआर मॉडल" के रूप में जाना जाता था, लेकिन सभी व्यावहारिक उद्देश्यों के लिए, आज के ईआर मॉडल में ईईआर विशेषताएं शामिल हैं।

एक ईईआर सुविधा "सामान्यीकरण / विशेषज्ञता" नाम से जाती है। आप वेब पर इस अवधारणा को खोज और पढ़ सकते हैं। जेन-स्पेक एक ही अभिव्यंजक क्षमता प्रदान करता है जो एक ऑब्जेक्ट मॉडल में कक्षाएं और उपवर्ग प्रदान करते हैं। हालांकि, जनरल-स्पेक स्थिति के लिए जनरल-रिलेशनल टेबल डिज़ाइन के आसपास के मुद्दों से संबंधित नहीं है। उस पर और बाद में।

ईआर मॉडलिंग में, एक संबंध में हमेशा समान इकाइयां शामिल होती हैं। इसलिए, किसी संगठन और प्रोफ़ाइल के बीच का मित्र संबंध वही नहीं है, जो किसी प्रोफ़ाइल और किसी अन्य प्रोफ़ाइल के बीच का मित्र संबंध है। दोनों रिश्तों को अलग-अलग नामों की जरूरत है। यदि आप इस नियम का पालन नहीं करते हैं तो आप बस अपने आप को गाँठ में बाँध लेंगे।

या तो वह, या आपको एक सामान्यीकृत इकाई के साथ आने की जरूरत है जिसमें संगठन, प्रोफाइल और संभवतः स्थान सभी विशेषज्ञ हैं। मैं आपके मामले को इतनी अच्छी तरह से समझ नहीं पा रहा हूं कि आप इसकी मदद कर सकें।

आगे बढ़ते हुए, मैंने देखा कि आप अपने रिलेशनल मॉडल और अपने ईआर मॉडल को एक ही मॉडल में एक साथ जोड़ रहे हैं। अधिकांश अनुभवी डेटाबेस आर्किटेक्ट ऐसा करते हैं। लेकिन मैं आपको सलाह देता हूं कि आप दोनों मॉडलों को अलग रखें (हालांकि एक-दूसरे के साथ सामंजस्य स्थापित करें) जब तक आप दक्षता प्राप्त नहीं कर लेते।

अंत में, एक डिज़ाइन रिलेशनल टेबल कैसे होता है जो जीन-स्पेक स्थिति का प्रतिनिधित्व करता है? इन दो डिज़ाइन पैटर्न "क्लास-टेबल-इनहेरिटेंस" और "सिंगल-टेबल-इनहेरिटेंस" को देखने का प्रयास करें। Stackoverflow में इन पर के लिए दो टैग हैं। वेब पर पैटर्न की कुछ बहुत अच्छी प्रस्तुतियाँ भी हैं। मैं विशेष रूप से मार्टिन फाउलर के उपचार को पसंद करता हूं। वह यह जानने के लिए लगता है कि मॉडल मॉडल कैसे सोचते हैं। उम्मीद है की यह मदद करेगा।

Comments

आपके समय और शानदार उत्तर के लिए धन्यवाद - ठीक है, इसलिए वे अवधारणाएं मेरे विकल्प की ओर झुकाव लगती हैं: 2. कृपया संशोधित देखें: प्रश्न में आरेख। प्रोफ़ाइल और स्थान - संगठन की प्रमुख संस्थाएँ वास्तव में कुछ विस्तारित विशेषताओं के साथ केवल एक प्रोफ़ाइल है। मैंने यह भी तय किया है कि मित्र / सदस्य समान हैं। * कई प्रोफाइल / संगठनों के सदस्य के रूप में कई प्रोफाइल / संगठन हो सकते हैं। * कई स्थानों में उनके साथ जुड़े कई प्रोफाइल / संगठन हो सकते हैं - गधे का प्रकार। सबसे अधिक संभावना है कि एनम द्वारा नियंत्रित किया जाएगा: मालिक / व्यवस्थापक / सदस्य। क्या यह मेरे संशोधित आरेख के साथ तुलनीय होगा?

— MVC नौसिखिया

AFAICT, तालिका Profile_Members एक प्रोफ़ाइल और दूसरे के बीच एक पुनरावर्ती कई-से-कई संबंधों का प्रतिनिधित्व करता है। जहाँ तक मुझे मिल गया है।

— वाल्टर मिती