रिश्ते हर जगह होते हैं:लोगों के बीच, संगठनों के बीच, संगठनों और लोगों के बीच। किसी कंपनी के कर्मचारी होने, प्रोजेक्ट टीम के सदस्य होने या किसी अन्य कंपनी की सहायक कंपनी होने के बारे में सोचें। क्या इन सभी रिश्तों को सटीक रूप से मॉडल और प्रबंधित करने का कोई सीधा तरीका है? क्या हम आसानी से इस सवाल का जवाब दे सकते हैं कि 'कौन जानता है?'
रिश्तों की एक त्वरित समीक्षा
वास्तव में इस मूल मॉडल को कैसे प्राप्त किया गया था, इसका वर्णन मेरे पिछले लेख, फ्लेक्सिबल एंड मैनेजेबल बिल ऑफ मैटेरियल्स (बीओएम) डिजाइन में किया गया था।
इस मॉडल में और पारंपरिक बीओएम डिजाइन में, 1st interactor बेहतर Party Relationship - कर्मचारी के बजाय नियोक्ता, टीम के सदस्य के बजाय टीम लीडर, आदि।
यहां बताया गया है कि डेटा कैसा दिख सकता है (कोष्ठक में प्रत्येक पक्ष की भूमिका के साथ):
| 1 इंटरेक्टर | <थ>2 इंटरेक्टर|
|---|---|
| विजेट कंपनी इंक (नियोक्ता) | प्रबंधक 1 (कर्मचारी) |
| विजेट कंपनी इंक (नियोक्ता) | प्रबंधक 2 (कर्मचारी) |
| विजेट कंपनी इंक (नियोक्ता) | कर्मचारी 1 (कर्मचारी) |
| विजेट कंपनी इंक (नियोक्ता) | कर्मचारी 2 (कर्मचारी) |
| विजेट कंपनी इंक (नियोक्ता) | कर्मचारी 3 (कर्मचारी) |
| विजेट कंपनी इंक (नियोक्ता) | कर्मचारी 4 (कर्मचारी) |
| प्रबंधक 1 (जिम्मेदार) | कर्मचारी 1 (रिपोर्ट करता है) |
| प्रबंधक 1 (जिम्मेदार) | कर्मचारी 2 (रिपोर्ट करता है) |
| प्रबंधक 2 (जिम्मेदार) | कर्मचारी 3 (रिपोर्ट करता है) |
| प्रबंधक 2 (जिम्मेदार) | कर्मचारी 4 (रिपोर्ट करता है) |
एक अधिक परिष्कृत मॉडल
कल्पना कीजिए कि आप निम्न की तरह एक प्रोजेक्ट डेवलपमेंट टीम बनाना चाहते हैं:
स्रोत:https://www.edrawsoft.com/template-matrix -org-chart.php
इस टीम पदानुक्रम में अधिकांश भूमिकाएँ वास्तविक हैं - उदा। आवश्यकता विश्लेषक सिस्टम विश्लेषक को रिपोर्ट करता है। इसे देखने का एक और तरीका यह है कि सिस्टम विश्लेषक आवश्यकता विश्लेषक का प्रबंधन करता है।
भूमिकाओं के बीच संबंधों को बाएं से दाएं (एलटीआर) या दाएं से बाएं (आरटीएल) पढ़ा जा सकता है। आम तौर पर एक सम्मेलन या दूसरे - एलटीआर या आरटीएल - से चिपके रहना सबसे अच्छा होता है, लेकिन व्यवहार में आप पा सकते हैं कि इसके अपवाद भी हैं।
साथ ही, ध्यान दें कि यह आरेख भूमिकाओं को समूहीकृत करने के विभिन्न तरीकों को दर्शाता है। कुछ भूमिकाएँ वास्तविक हैं, जैसा कि हमने चर्चा की है; अन्य तार्किक हैं - उदा। तकनीकी समूह, प्रशिक्षण समूह, कोर टीम और सहायता टीम।
हम कह सकते हैं कि यह आरेख टीम संरचना को परिभाषित करता है परियोजना विकास टीम को पूरा करने के लिए आवश्यक भूमिकाओं का उपयोग करना। यह टीम के वास्तविक उदाहरण से अलग है, जो प्रत्येक भूमिका के लिए वास्तविक लोगों के नामों से बना होगा।
इसलिए हमें एक ऐसा डेटा मॉडल चाहिए जो लचीला और विन्यास योग्य हो , जैसे यह वाला:
पीली तालिका में मेटाडेटा . होता है , और नीली तालिकाओं में व्यावसायिक डेटा . होता है ।
फाउंडेशन मेटाडेटा सेट करना
हम party_type टेबल। यह तालिका अलग करती है कि कोई पार्टी व्यक्ति है या संगठन।
इससे पहले कि हम बहुत कुछ करें, हमें role_type मेटाडेटा तालिका:
| सुंदर नाम | पार्टी प्रकार |
|---|---|
| HM राजस्व और सीमा शुल्क (HMRC) | संगठन |
| आंतरिक राजस्व सेवा (IRS) | संगठन |
| पासपोर्ट सेवा | संगठन |
| वही | संगठन |
| सीमित कंपनी | संगठन |
| पब्लिक लिमिटेड कंपनी | संगठन |
| आवेदक | व्यक्ति |
| स्वयं | व्यक्ति |
| सीटीओ इंजीनियरिंग | व्यक्ति |
| प्रोजेक्ट मैनेजर | व्यक्ति |
| परियोजना विशेषज्ञ | व्यक्ति |
| सिस्टम एनालिस्ट | व्यक्ति |
| आवश्यकता विश्लेषक | व्यक्ति |
| तकनीकी क्लर्क | व्यक्ति |
| सिस्टम व्यवस्थापक | व्यक्ति |
| वरिष्ठ हार्डवेयर इंजीनियर | व्यक्ति |
| हार्डवेयर इंजीनियर | व्यक्ति |
| वरिष्ठ सॉफ्टवेयर इंजीनियर | व्यक्ति |
| सॉफ्टवेयर इंजीनियर | व्यक्ति |
| डेटाबेस इंजीनियर | व्यक्ति |
| तकनीकी सहायता | व्यक्ति |
| QA प्रबंधक | व्यक्ति |
| वेब डिज़ाइनर | व्यक्ति |
| सॉफ्टवेयर QA इंजीनियर | व्यक्ति |
| परियोजना कार्यालय | व्यक्ति |
| सूचना सुरक्षा इंजीनियर | व्यक्ति |
| तकनीकी | संगठन |
| प्रशिक्षण | संगठन |
| कोर टीम | संगठन |
| सहायता टीम | संगठन |
आपने निःसंदेह नोट किया है कि प्रत्येक भूमिका किसी व्यक्ति या संगठन की होती है। क्या संभव है, इसका अंदाजा लगाने के लिए, मैंने कुछ बाहरी संगठनों को जोड़ा है, जिनके साथ हमारी काल्पनिक लिमिटेड कंपनी, एबीसी सॉफ्टवेयर इंक के संबंध हैं।
रोजगार मेटाडेटा जोड़ना
अगला कार्य वैध भूमिका-जोड़े को परिभाषित करना है पहले और दूसरे इंटरेक्टर्स के बीच। बदले में, यह परिभाषित करता है कि पार्टियों के संबंध किस प्रकार के हो सकते हैं। आइए role_type_relationship कंपनी की कर्मचारी भूमिकाओं के साथ मेटाडेटा तालिका। आखिरकार, हम पहले कर्मचारियों के बिना टीम नहीं बना सकते:
| पहली भूमिका का प्रकार | दूसरी भूमिका प्रकार | विवरण दिशा | <थ>विवरणरिश्ते का प्रकार | |
|---|---|---|---|---|
| सीमित कंपनी | सीटीओ इंजीनियरिंग | एलटीआर | रोजगार | असली |
| सीमित कंपनी | प्रोजेक्ट मैनेजर | एलटीआर | रोजगार | असली |
| सीमित कंपनी | परियोजना विशेषज्ञ | एलटीआर | रोजगार | असली |
| सीमित कंपनी | सिस्टम एनालिस्ट | एलटीआर | रोजगार | असली |
| सीमित कंपनी | आवश्यकता विश्लेषक | एलटीआर | रोजगार | असली |
| सीमित कंपनी | तकनीकी क्लर्क | एलटीआर | रोजगार | असली |
| सीमित कंपनी | सिस्टम एडमिनिस्ट्रेटर | एलटीआर | रोजगार | असली |
| सीमित कंपनी | वरिष्ठ हार्डवेयर इंजीनियर | एलटीआर | रोजगार | असली |
| सीमित कंपनी | हार्डवेयर इंजीनियर | एलटीआर | रोजगार | असली |
| सीमित कंपनी | वरिष्ठ सॉफ्टवेयर इंजीनियर | एलटीआर | रोजगार | असली |
| सीमित कंपनी | सॉफ्टवेयर इंजीनियर | एलटीआर | रोजगार | असली |
| सीमित कंपनी | डेटाबेस इंजीनियर | एलटीआर | रोजगार | असली |
| सीमित कंपनी | तकनीकी सहायता | एलटीआर | रोजगार | असली |
| सीमित कंपनी | QA प्रबंधक | एलटीआर | रोजगार | असली |
| सीमित कंपनी | वेब डिज़ाइनर | एलटीआर | रोजगार | असली |
| सीमित कंपनी | सॉफ्टवेयर QA इंजीनियर | एलटीआर | रोजगार | असली |
| सीमित कंपनी | परियोजना कार्यालय | एलटीआर | रोजगार | असली |
| सीमित कंपनी | सूचना सुरक्षा इंजीनियर | एलटीआर | रोजगार | असली |
| सीमित कंपनी | आवेदक | एलटीआर | चुनता है | असली |
मान लीजिए कि एबीसी सॉफ्टवेयर इंक निम्नलिखित भूमिकाओं के लिए दो कर्मचारियों, जेन स्मिथ और एलेक्स जोन्स को नियुक्त करने जा रहा है:
| पार्टी संबंध | <वें colspan="3">भूमिका प्रकार संबंध||||
|---|---|---|---|---|
| पहला इंटरैक्टर (संगठन) | दूसरा इंटरैक्टर (व्यक्ति) | पहला इंटरैक्टर (भूमिका) | दूसरा इंटरैक्टर (भूमिका) | विवरण |
| एबीसी सॉफ्टवेयर इंक. | जेन स्मिथ | सीमित कंपनी | सीटीओ इंजीनियरिंग | रोजगार |
| एबीसी सॉफ्टवेयर इंक. | एलेक्स जोन्स | सीमित कंपनी | प्रोजेक्ट मैनेजर | रोजगार |
समय पर एक कदम पीछे लेते हुए, आप देखेंगे कि जेन स्मिथ और एलेक्स जोन्स को काम पर रखने से पहले यह रिश्ता शुरू हुआ था; उन्हें ABC Software Inc. में नौकरी के लिए आवेदन करना था। रिश्ता कुछ इस तरह दिखेगा:
| पार्टी संबंध | <वें colspan="3">भूमिका प्रकार संबंध||||
|---|---|---|---|---|
| पहला इंटरैक्टर (संगठन) | दूसरा इंटरैक्टर (व्यक्ति) | पहला इंटरैक्टर (भूमिका) | दूसरा इंटरैक्टर (भूमिका) | विवरण |
| एबीसी सॉफ्टवेयर इंक. | जेन स्मिथ | सीमित कंपनी | आवेदक | चुनता है |
| एबीसी सॉफ्टवेयर इंक. | एलेक्स जोन्स | सीमित कंपनी | आवेदक | चुनता है |
क्या आपको संभावनाएं दिखाई देने लगी हैं कि पार्टी संबंध पैटर्न समर्थन करता है?
हमारे पास applicant और एक अन्य तालिका जिसे employee , जैसा कि अन्य मॉडलों में पाया जा सकता है। यदि आप इसके बारे में सोचते हैं, तो वे कई समान विशेषताओं को साझा करेंगे - नाम, पता, जन्म तिथि, आदि; आपको applicant करने के लिए employee सफल भाड़े पर। लेकिन क्या इसमें शामिल लोग एक चीज से दूसरी चीज में तब्दील हो गए हैं? बिलकूल नही! वे अब भी वही लोग हैं!
वास्तव में, यह केवल संबंध है जो बदल गया है एबीसी सॉफ्टवेयर इंक और जेन स्मिथ या एलेक्स जोन्स के बीच। और ठीक यही पार्टी संबंध पैटर्न मॉडल है।
जारी है:प्रोजेक्ट टीम मेटाडेटा
इससे पहले कि हम एक party_relationship इस तथ्य को परिभाषित करने के लिए कि जेन स्मिथ एलेक्स जोन्स का प्रबंधन करता है, हमें परियोजना विकास टीम की संरचना को परिभाषित करना चाहिए। यह केवल एक मान्य पदानुक्रम बनाने के लिए माता-पिता और बच्चे की भूमिकाओं को जोड़ने का प्रश्न है:
| पहली भूमिका का प्रकार | दूसरी भूमिका प्रकार | विवरण दिशा | <थ>विवरणरिश्ते का प्रकार | |
|---|---|---|---|---|
| परियोजना विकास दल | सीटीओ इंजीनियरिंग | आरटीएल | लीड | असली |
| सीटीओ इंजीनियरिंग | प्रोजेक्ट मैनेजर | एलटीआर | प्रबंधन | असली |
| प्रोजेक्ट मैनेजर | सिस्टम एनालिस्ट | एलटीआर | प्रबंधन | असली |
| प्रोजेक्ट मैनेजर | सिस्टम एडमिनिस्ट्रेटर | एलटीआर | प्रबंधन | असली |
| प्रोजेक्ट मैनेजर | परियोजना विशेषज्ञ | एलटीआर | प्रबंधन | असली |
| प्रोजेक्ट मैनेजर | वरिष्ठ सॉफ्टवेयर इंजीनियर | एलटीआर | प्रबंधन | असली |
| प्रोजेक्ट मैनेजर | तकनीकी सहायता | एलटीआर | प्रबंधन | असली |
| प्रोजेक्ट मैनेजर | वेब डिज़ाइनर | एलटीआर | प्रबंधन | असली |
| प्रोजेक्ट मैनेजर | सॉफ्टवेयर QA इंजीनियर | एलटीआर | प्रबंधन | असली |
| प्रोजेक्ट मैनेजर | परियोजना कार्यालय | एलटीआर | प्रबंधन | असली |
| प्रोजेक्ट मैनेजर | सूचना सुरक्षा इंजीनियर | एलटीआर | प्रबंधन | असली |
| प्रोजेक्ट मैनेजर | डेटाबेस इंजीनियर | एलटीआर | प्रबंधन | असली |
| प्रोजेक्ट मैनेजर | तकनीकी सहायता | एलटीआर | प्रबंधन | असली |
| प्रोजेक्ट मैनेजर | QA प्रबंधक | एलटीआर | प्रबंधन | असली |
| सिस्टम एनालिस्ट | आवश्यकता विश्लेषक | एलटीआर | प्रबंधन | असली |
| आवश्यकता विश्लेषक | तकनीकी क्लर्क | एलटीआर | प्रबंधन | असली |
| सिस्टम व्यवस्थापक | वरिष्ठ हार्डवेयर इंजीनियर | एलटीआर | प्रबंधन | असली |
| वरिष्ठ हार्डवेयर इंजीनियर | हार्डवेयर इंजीनियर | एलटीआर | प्रबंधन | असली |
| वरिष्ठ सॉफ्टवेयर इंजीनियर | सॉफ्टवेयर इंजीनियर | एलटीआर | प्रबंधन | असली |
उपरोक्त सभी भूमिकाओं के लिए, रिश्ते को बाएं से दाएं पढ़ा जाता है - उदा। प्रोजेक्ट मैनेजर डेटाबेस इंजीनियर का प्रबंधन करता है। वैकल्पिक रूप से, आप दाएं से बाएं प्रारूप को अपना सकते हैं (डेटाबेस इंजीनियर परियोजना प्रबंधक को रिपोर्ट करता है) यदि वह आपका पसंदीदा सम्मेलन है।
अंत में, हमें अपने दो नए कर्मचारियों के बीच संबंध को परिभाषित करना चाहिए:
| पार्टी संबंध | <वें colspan="3">भूमिका प्रकार संबंध||||
|---|---|---|---|---|
| पहला इंटरैक्टर (संगठन) | दूसरा इंटरैक्टर (व्यक्ति) | पहला इंटरैक्टर (भूमिका) | दूसरा इंटरैक्टर (भूमिका) | विवरण |
| जेन स्मिथ | एलेक्स जोन्स | सीटीओ इंजीनियरिंग | प्रोजेक्ट मैनेजर | प्रबंधन |
बेशक आपके पास इस पदानुक्रम के आकार में कितनी भी टीमें हो सकती हैं। इसलिए, एक मायने में, party_relationship एक उदाहरण है role_type_relationship . यह उसी तरह है जैसे कोई वस्तु OO प्रोग्रामिंग में एक वर्ग का उदाहरण है।
लॉजिकल मेटाडेटा सहित
परियोजना विकास टीम आरेख के संदर्भ में, हम निम्नलिखित भूमिकाओं के बीच तार्किक संबंध को भी परिभाषित कर सकते हैं :
| पहली भूमिका का प्रकार | <थ>दूसरी भूमिका का प्रकारविवरण दिशा | <थ>विवरणरिश्ते का प्रकार | ||
|---|---|---|---|---|
| कोर टीम | परियोजना विशेषज्ञ | आरटीएल | सदस्य है | तर्कसंगत |
| कोर टीम | सिस्टम एनालिस्ट | आरटीएल | सदस्य है | तर्कसंगत |
| कोर टीम | आवश्यकता विश्लेषक | आरटीएल | सदस्य है | तर्कसंगत |
| कोर टीम | तकनीकी क्लर्क | आरटीएल | सदस्य है | तर्कसंगत |
| कोर टीम | सिस्टम एडमिनिस्ट्रेटर | आरटीएल | सदस्य है | तर्कसंगत |
| कोर टीम | वरिष्ठ हार्डवेयर इंजीनियर | आरटीएल | सदस्य है | तर्कसंगत |
| कोर टीम | हार्डवेयर इंजीनियर | आरटीएल | सदस्य है | तर्कसंगत |
| कोर टीम | वरिष्ठ सॉफ्टवेयर इंजीनियर | आरटीएल | सदस्य है | तर्कसंगत |
| कोर टीम | सॉफ्टवेयर इंजीनियर | आरटीएल | सदस्य है | तर्कसंगत |
| कोर टीम | डेटाबेस इंजीनियर | आरटीएल | सदस्य है | तर्कसंगत |
| कोर टीम | तकनीकी सहायता | आरटीएल | सदस्य है | तर्कसंगत |
| कोर टीम | QA प्रबंधक | आरटीएल | सदस्य है | तर्कसंगत |
| कोर टीम | वेब डिज़ाइनर | आरटीएल | सदस्य है | तर्कसंगत |
| कोर टीम | सॉफ्टवेयर QA इंजीनियर | आरटीएल | सदस्य है | तर्कसंगत |
| कोर टीम | परियोजना कार्यालय | आरटीएल | सदस्य है | तर्कसंगत |
| कोर टीम | सूचना सुरक्षा इंजीनियर | आरटीएल | सदस्य है | तर्कसंगत |
| सहायता टीम | वेब डिज़ाइनर | आरटीएल | सदस्य है | तर्कसंगत |
| सहायता टीम | सॉफ्टवेयर QA इंजीनियर | आरटीएल | सदस्य है | तर्कसंगत |
| सहायता टीम | परियोजना कार्यालय | आरटीएल | सदस्य है | तर्कसंगत |
| सहायता टीम | सूचना सुरक्षा इंजीनियर | आरटीएल | सदस्य है | तर्कसंगत |
ध्यान दें कि party_relationship कभी उदाहरण नहीं है तार्किक role_type_relationship . तो तार्किक संबंधों को परिभाषित करने का क्या मतलब है?
खैर, यह शायद एक उदाहरण के माध्यम से सबसे अच्छी तरह से समझाया गया है। कल्पना कीजिए कि आप उन सभी कर्मचारियों को एक पत्र भेजना चाहते हैं जो तार्किक रूप से समर्थन टीम के सदस्य हैं। एक मेलिंग सूची बनाने के लिए, आप एक क्वेरी लिखेंगे जो सभी तार्किक समर्थन टीम 2 इंटरएक्टर भूमिकाओं को एक ही वास्तविक 2 इंटरेक्टर भूमिकाओं में शामिल करती है, जो party_relationship , 2 इंटरएक्टर में शामिल हुआ party . इससे आप सभी संबंधितों के नाम और पते प्राप्त कर सकेंगे।
एक विशेष मामला
आपने role_type मेटाडेटा तालिका, अर्थात्:
| भूमिका प्रकार | पार्टी प्रकार |
|---|---|
| स्वयं | व्यक्ति |
| वही | संगठन |
ये एक विशेष मामले के दो उदाहरण हैं, जो तब होता है जब किसी पक्ष का स्वयं के साथ एक प्रतिवर्त संबंध होता है:
| पहली भूमिका का प्रकार | दूसरी भूमिका प्रकार | विवरण दिशा | <थ>विवरणरिश्ते का प्रकार | |
|---|---|---|---|---|
| स्वयं | सिस्टम एनालिस्ट | एलटीआर | नियोजित | असली |
उदाहरण के लिए, एक स्व-नियोजित सिस्टम विश्लेषक के लिए, party_relationship में 1 और 2 इंटरैक्टर्स वापस उसी party को देखें पंक्ति - यानी दोनों विदेशी कुंजी कॉलम में बिल्कुल समान party.ID . है मूल्य।
संदर्भ होने का महत्व
कल्पना कीजिए कि हमारे पास एक छोटी एनालिटिक्स टीम है जो मूल रूप से प्रोजेक्ट मैनेजर और तकनीकी क्लर्क के बीच की शाखा से बनती है:
| पहली भूमिका का प्रकार | दूसरी भूमिका प्रकार | विवरण दिशा | <थ>विवरणरिश्ते का प्रकार | |
|---|---|---|---|---|
| छोटी एनालिटिक्स टीम | प्रोजेक्ट मैनेजर | आरटीएल | लीड | असली |
| प्रोजेक्ट मैनेजर | सिस्टम एनालिस्ट | एलटीआर | प्रबंधन | असली |
| सिस्टम एनालिस्ट | आवश्यकता विश्लेषक | एलटीआर | प्रबंधन | असली |
| आवश्यकता विश्लेषक | तकनीकी क्लर्क | एलटीआर | प्रबंधन | असली |
यहां प्रत्येक संबंध परियोजना विकास टीम संरचना में भी मौजूद है। तो, हम एक प्रोजेक्ट मैनेजर → सिस्टम एनालिस्ट रिलेशनशिप को दूसरे से कैसे अलग करते हैं?
हम वैकल्पिक संदर्भ . का उपयोग करते हैं role_type_relationship और role_type . छोटी एनालिटिक्स टीम के लिए, हम सभी संबंधों के संदर्भ को "छोटी एनालिटिक्स टीम", शीर्ष-स्तरीय तत्व के रूप में सेट करते हैं। और हम प्रोजेक्ट डेवलपमेंट टीम स्ट्रक्चर के लिए उसी तरह का काम करते हैं। जब हम संरचना को पार करते हैं, तो हम ऐसा केवल उस टीम के प्रकार के लिए करते हैं जिसमें हम रुचि रखते हैं।
पार्टी संबंध BOM पैटर्न के फायदे और नुकसान
यदि आपने इस विषय पर मेरे अन्य लेख पढ़े हैं, तो आपने शायद अनुमान लगाया है कि मैं बिल ऑफ मैटेरियल्स डिज़ाइन पैटर्न का प्रशंसक हूं। यह सरल है, लेकिन बहुत शक्तिशाली है। चेतावनी यह है कि इसका उचित उपयोग किया जाना चाहिए और इसे सिलवाया जाना चाहिए ताकि आपका कार्यान्वयन प्रबंधनीय बना रहे।
बीओएम पैटर्न के इस पार्टी संबंध कार्यान्वयन में, हम यह सुनिश्चित करते हैं कि हमारे संबंध हमारे डोमेन में मौजूद इंटरैक्टर्स के बीच स्वीकार्य संबंधों को पहले परिभाषित करके सटीक बने रहें। उदाहरण के लिए, यह आंतरिक राजस्व सेवा को ABC सॉफ़्टवेयर इंक में वेब डिज़ाइनर के रूप में "नियोजित" होने से रोकेगा।
इस प्रकार संबंधों को परिभाषित करने से क्या संभावनाएं उत्पन्न होती हैं? ठीक है, आपके संगठन को यह जानने की आवश्यकता हो सकती है कि आपके वर्तमान कर्मचारियों और ठेकेदारों ने किन अन्य संगठनों के लिए काम किया है। यह हितों के संभावित टकराव या धोखाधड़ी से बचने में मदद करता है। इसका एक उदाहरण एक पुरस्कार देने वाली संस्था है। यह जानने की जरूरत है कि इसके मूल्यांकनकर्ताओं ने पहले किन स्कूलों में पढ़ाया है ताकि यह सुनिश्चित हो सके कि वे उन स्कूलों के परीक्षा पत्रों का आकलन नहीं करते हैं। पार्टी संबंध मॉडल में, पूछताछ करना और उस जानकारी को प्राप्त करना आसान होता है।
दूसरी ओर, आपका संगठन उसी जानकारी को संग्रहीत करना चाह सकता है क्योंकि यह व्यावसायिक अवसर प्रस्तुत कर सकता है। यह सिर्फ आपके डोमेन पर निर्भर करता है।
संक्षेप में, आप अच्छी तरह से संरचित पार्टी संबंध डेटा से जो जानकारी प्राप्त कर सकते हैं वह अमूल्य हो सकती है।
