मास्टर डेटा और पहचान

🌐 28 अन्य भाषाओं में भी उपलब्ध

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI से बनाई गई इमेज

AI द्वारा अनुवादित। समुदाय ने अभी इसकी समीक्षा नहीं की है। अंग्रेज़ी में पढ़ें

Data Architect कोर्स के अध्याय 6 की अध्ययन गाइड। पहले छह मॉड्यूल पढ़ें, चेकपॉइंट 1 के हल समेत; यह पेज आपको जाँचने में मदद करता है कि क्या याद रहा।

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

यह अध्याय परीक्षा के Master Data Management खंड (5%) और Salesforce Data Management से ग्राहक की एकल नज़र (single view) को संभालता है। वज़न के हिसाब से यह छोटा खंड है, लेकिन इसके विचार (अधिकार, मैचिंग, सर्वाइवरशिप) कई दूसरे परिदृश्यों के अंदर दिखते हैं। प्लेटफ़ॉर्म के आँकड़े बदलते रहते हैं, इसलिए उन पर भरोसा करने से पहले मौजूदा आँकड़े देख लें।

परीक्षा के लिए

जैसे-जैसे आगे बढ़ें, इन पर निशान लगाते जाएँ। हर एक उस जगह से जुड़ा है जहाँ उसे पढ़ाया गया है।

MDM-2: गोल्डन रिकॉर्ड और सच का सिस्टम

• मैं जानता हूँ कि अधिकार हर एट्रिब्यूट के लिए तय होता है, हर रिकॉर्ड के लिए नहीं: एक account के कुछ फ़ील्ड ERP में मास्टर हो सकते हैं और कुछ Salesforce में। (सच एट्रिब्यूट का होता है)
• मैं पूछता हूँ कि हर एट्रिब्यूट कहाँ बनता है, कहाँ एडिट होता है और कहाँ संदर्भित होता है, और उसके बदलने की latency क्या है। (कहाँ बनता है, कहाँ एडिट होता है, कहाँ संदर्भित होता है, और कितनी तेज़ी से?)
• मैं एक अधिकार-मानचित्र बना सकता हूँ, और जानता हूँ कि बिज़नेस मालिक और आधिकारिक सिस्टम एक ही चीज़ नहीं हैं। (अधिकार-मानचित्र बनाएँ)
• मैं जानता हूँ कि अधिकार जीवनचक्र के साथ बदल सकता है (Salesforce में एक prospect ERP-नियंत्रित ग्राहक बन जाता है), और यह कि कॉपी अधिकार नहीं है। (जीवनचक्र के साथ अधिकार बदलता है, कॉपी अधिकार नहीं है)

MDM-1: MDM की तकनीकें

• परीक्षा-ज्ञान: मैं चारों MDM implementation styles जानता हूँ, रजिस्ट्री, कंसॉलिडेशन, को-एग्ज़िस्टेंस और सेंट्रलाइज़्ड: हर एक क्या केंद्र में रखता है और क्या वह मान वापस भेजता है। (चारों आमने-सामने)
• मैं चारों MDM शैलियों में फ़र्क़ कर सकता हूँ: रजिस्ट्री, कंसॉलिडेशन, को-एग्ज़िस्टेंस और सेंट्रलाइज़्ड, और वह सबसे हल्की शैली चुन सकता हूँ जो समस्या हल कर दे। (चारों आमने-सामने)
• मैं जानता हूँ कि एक कैनॉनिकल डेटा मॉडल संरचना में सामंजस्य लाता है, लेकिन अधिकार तय नहीं करता। (साझा मॉडल, साझा सच नहीं है)
• मैं क्रम जानता हूँ: पहले सामंजस्य, फिर मैच, फिर कंसॉलिडेट। (पहले सामंजस्य, फिर मैच, फिर कंसॉलिडेट)
• मैं जानता हूँ कि सीमाएँ (thresholds) गलती सहने की क्षमता दिखाती हैं, और संवर्धन (enrichment) को उद्गम चाहिए। (सीमाएँ, समीक्षा और संवर्धन)
• परीक्षा-ज्ञान: मैं hierarchy management जानता हूँ: Parent Account हायरार्की बनाता है (Lightning व्यू 2,000 accounts तक दिखाती है, person accounts के बिना), हायरार्की का मास्टर अक्सर बँटा होता है, और एक कंपनी की कई जायज़ हायरार्की हो सकती हैं। (हायरार्की भी मास्टर डेटा है, एक हायरार्की, कई मास्टर)

MDM-3: जीतने वाले एट्रिब्यूट चुनना

• मैं मैचिंग, मर्जिंग और सर्वाइवरशिप को अलग-अलग रखता हूँ। (मैचिंग, मर्जिंग और सर्वाइवरशिप)
• मैं सर्वाइवरशिप नियम जानता हूँ: सबसे नया, सबसे ज़्यादा बार, स्रोत की प्राथमिकता, और यह कि हर नियम का एक मालिक होना चाहिए। (सर्वाइवरशिप: कौन-सा मान जीतता है?)
• मैं जानता हूँ कि मैच का मतलब merge ज़रूरी नहीं, और मैं merge सिर्फ़ साफ़ विजेता होने पर करता हूँ, पहले यह तय करके कि children का क्या होगा। (मैच का मतलब merge ज़रूरी नहीं, Merge का मेरा नियम: एक साफ़ विजेता)
• परीक्षा-ज्ञान: मैं जानता हूँ कि Salesforce account merge क्या करता है: तीन तक रिकॉर्ड, एक principal, सबसे पुराना Created By और Created Date रखा जाता है, बाकी Recycle Bin में, और person accounts के लिए contact point objects merge नहीं होते। (Salesforce merge असल में क्या करता है)

SDM-3: ग्राहक की एकल नज़र

• मैं जानता हूँ कि Data 360 का आइडेंटिटी रेज़ोल्यूशन स्रोत प्रोफ़ाइलों को एक यूनिफ़ाइड प्रोफ़ाइल में जोड़ता है और वापस के लिंक रखता है: रजिस्ट्री के सबसे क़रीब। (आइडेंटिटी रेज़ोल्यूशन “कौन?” का जवाब देता है)
• परीक्षा-ज्ञान: मैं Data 360 के match rules जानता हूँ: एक रूल की सारी शर्तें मैच होनी चाहिए, कोई भी रूल मैच कर सकता है; सटीकता के लिए ज़्यादा शर्तें, कंसॉलिडेशन के लिए कम। (मैच रूल)
• मैं match methods जानता हूँ (Exact, Exact Normalized, तीन precision पर Fuzzy): कम सटीक तरीका कंसॉलिडेशन बढ़ाता है, और गलत मैच का जोखिम भी। (मैच रूल)
• परीक्षा-ज्ञान: मैं जानता हूँ कि reconciliation rules (Last Updated, Most Frequent, Source Priority) तय करते हैं कि यूनिफ़ाइड प्रोफ़ाइल क्या दिखाए, लेकिन स्रोतों को नहीं बदलते; contact points का मिलान नहीं होता। (मिलान अब भी मास्टरिंग नहीं है)
• मैं काम के हिसाब से डुप्लिकेट मैनेजमेंट, आइडेंटिटी रेज़ोल्यूशन और एक समर्पित MDM प्लेटफ़ॉर्म में से चुन सकता हूँ। (तीन कामों के लिए तीन टूल)

MDM-4 और दोतरफ़ा डेटा

• मैं जानता हूँ कि दोतरफ़ा डेटा का मतलब दो मास्टर नहीं: ERP के स्वामित्व वाले फ़ील्ड पर Salesforce का एडिट एक अनुरोध है, इसलिए अनुरोध → जाँच → स्वीकृति → प्रकाशन डिज़ाइन करें, एक pending स्थिति के साथ। (दोतरफ़ा डेटा का मतलब दो मास्टर नहीं, जब मास्टर मना कर दे)
• मैं जानता हूँ कि लूप और टक्करों से कैसे बचें: शुरू हुए बदलाव को उसकी गूँज से अलग पहचानें, और तय करें कि कौन-से फ़ील्ड एक ट्रांज़ैक्शन की तरह साथ चलेंगे। (लूप और टक्करें)
• दो ERP में एक ग्राहक के लिए, मैं एक हायरार्की, बराबरी वाले accounts या हर ERP के लिए एक child वाला एक account चुन सकता हूँ, इस आधार पर कि क्लाइंट अपने ERP को कितनी अच्छी तरह सिंक में रखता है। (एक ग्राहक, दो ERP, पूछें कि वे ERP को सिंक में कैसे रखते हैं)

चेकपॉइंट 1: भाग 1 को एक साथ रखना

• परीक्षा-ज्ञान: मैं जानता हूँ कि किन बाहरी लाइसेंसों में स्टैंडर्ड शेयरिंग आती है: Customer Community Plus और Partner Community, जिन्हें बाहरी यूज़र्स के लिए रोल चाहिए; Customer Community sharing sets इस्तेमाल करता है। (कौन क्या देखता है, और किसे लाइसेंस चाहिए)

परीक्षा से आगे

परीक्षा फ़र्श है, छत नहीं। ये इस अध्याय की वे आदतें हैं जो एक आर्किटेक्ट को चाहिए, चाहे कोई सवाल उनके बारे में कभी पूछे या नहीं।

• “सच का एक ही स्रोत”: कौन-सा सच? यह सच का एक आर्किटेक्चर है, एक रिकॉर्ड नहीं।
• स्कीमा में अधिकार को दिखने लायक बनाएँ: जिन फ़ील्ड का मालिक कोई दूसरा सिस्टम है, उनके लिए एक prefix।
• भरोसे के लिए सिर्फ़ मान काफ़ी नहीं: स्रोत, आखिरी पुष्टि कब हुई, किसने बदला।
• MDM प्रोडक्ट से नहीं, समस्या से शुरू करें। MDM अधिकार के बारे में एक बिज़नेस फ़ैसला है।
• जोड़ना, मास्टर करना नहीं है।
• जहाँ गलत मैच महँगे हैं, वहाँ जान-बूझकर कम मैच करें।
• बाहरी लोड से आए डुप्लिकेट रखें जब आपको पीछे तक ट्रेस करना पड़ सकता है।
• यूनिफ़ाइड प्रोफ़ाइल एक नक्शा है। गोल्डन रिकॉर्ड एक फ़ैसला है।
• दिखाना, अधिकार नहीं है।
• पहचान को एकीकृत करने से सिक्योरिटी की सीमाएँ नहीं मिटतीं।
• सबसे मुश्किल चीज़ bi-directionals हैं। साझा अधिकार समस्या नहीं है; अस्पष्ट अधिकार समस्या है।
• अस्वीकार हुए अनुरोध को कभी प्रतिद्वंद्वी सच न बनने दें।
• एक फ़ील्ड जो बताए कि यह मास्टर डेटा है, वही तय करता है कि क्या एडिट हो सकता है, रिकॉर्ड टाइप नहीं।
• ERP हमारे नियंत्रण में नहीं हैं। हमारे नियंत्रण में यह है कि हम उन्हें Salesforce में कैसे दिखाते हैं।

जानने लायक शब्द

शब्द	एक पंक्ति में
मास्टर डेटा मैनेजमेंट (MDM)	सिस्टमों के पार मुख्य डेटा की आधिकारिक पहचान और मानों को स्थापित करना और नियंत्रित करना
अधिकार-मानचित्र (authority map)	हर एट्रिब्यूट के लिए: उसे कौन बनाता है, फ़ैसले का मालिक कौन है, कौन-सा सिस्टम आधिकारिक है, उसे कौन बदल सकता है
गोल्डन रिकॉर्ड	इस बारे में एक नियंत्रित फ़ैसला कि कौन-से मान आधिकारिक हैं
हाइब्रिड गोल्डन रिकॉर्ड	एक रिकॉर्ड जिसके कुछ एट्रिब्यूट कहीं और मास्टर होकर अंदर कॉपी होते हैं, और कुछ लोकल स्वामित्व में हैं
रजिस्ट्री	वह MDM जो स्रोतों को बदले बिना रिकॉर्ड को एक ही एंटिटी के रूप में जोड़ता है
कंसॉलिडेशन	वह MDM जो डेटा को केंद्र में मिलाता है, आम तौर पर एनालिटिक्स के लिए, बिना वापस भेजे
को-एग्ज़िस्टेंस	वह MDM जो मास्टर किया हुआ मान तय करता है और उसे स्रोतों को वापस प्रकाशित करता है
सेंट्रलाइज़्ड MDM	वह MDM जिसमें नियंत्रित डेटा मास्टर में बनता है और बाँटा जाता है
कैनॉनिकल डेटा मॉडल	किसी अवधारणा का एंटरप्राइज़ में तय किया गया आकार, जिससे सिस्टमों को एक-दूसरे से मैप किया जाता है
सामंजस्य (harmonization)	मानों को तुलना के लायक बनाना: स्टैंडर्ड फ़ॉर्मेट, कोड और संक्षिप्त रूप
मैचिंग	यह तय करना कि क्या रिकॉर्ड एक ही चीज़ को दर्शाते हैं
सर्वाइवरशिप	स्रोतों के असहमत होने पर कौन-सा मान जीतेगा, इसके नियम
Principal रिकॉर्ड	Salesforce merge में वह रिकॉर्ड जो बचा रहता है और अपने hidden और read-only फ़ील्ड रखता है
Match method	Data 360 की एक मैच शर्त मानों की तुलना कैसे करती है: exact, exact normalized या fuzzy
आइडेंटिटी रेज़ोल्यूशन	Data 360 का स्रोत प्रोफ़ाइलों को मिलाकर यूनिफ़ाइड प्रोफ़ाइल बनाना
यूनिफ़ाइड प्रोफ़ाइल	keys का एक सेट जो एक व्यक्ति या कंपनी को दर्शाने वाले स्रोत रिकॉर्ड को जोड़ता है
मिलान के नियम (reconciliation rules)	Data 360 के नियम कि यूनिफ़ाइड प्रोफ़ाइल कौन-सा मान दिखाए
बँटे मास्टर वाली हायरार्की	एक हायरार्की जिसकी शाखाओं के मालिक अलग-अलग सिस्टम हैं

खुद को परखें

कोर्स की शैली में छोटे परिदृश्य। खोलने से पहले अपना जवाब तय कर लें।

1. “ग्राहक के लिए Salesforce ही हमारा सच का एक स्रोत है।” आप क्या पूछेंगे?

कौन-सा सच? अधिकार हर एट्रिब्यूट का होता है: कानूनी नाम, बिलिंग पता और क्रेडिट लिमिट का मालिक शायद ERP हो, जबकि account executive और success tier का मालिक Salesforce। एक अधिकार-मानचित्र बनाएँ। फिर से पढ़ें: सच एट्रिब्यूट का होता है।

2. सर्विस एजेंटों को देखना है कि एक Salesforce contact वही व्यक्ति है जिसने ऑनलाइन खरीदा था। किसी को सिस्टमों में बदलाव की ज़रूरत नहीं। कौन-सी MDM शैली?

रजिस्ट्री: स्रोतों को बदले बिना रिकॉर्ड को एक पहचान के रूप में जोड़ें, जो Data 360 आइडेंटिटी रेज़ोल्यूशन करता है। वह सबसे हल्का पैटर्न चुनें जो समस्या हल कर दे। फिर से पढ़ें: रजिस्ट्री: बताओ कौन कौन है।

3. हर फ़ील्ड के लिए सर्वाइवरशिप “सबसे नया जीतता है” पर सेट है। कोई ERP के स्वामित्व वाले कानूनी नाम की Salesforce कॉपी बदल देता है। क्या होता है, और गलत क्या है?

सबसे नया मान जीतता है, और कॉपी अधिकार पर हावी हो जाती है। “सबसे नया” भरोसे के बारे में एक बयान है जो कुछ एट्रिब्यूट (मोबाइल नंबर) पर ठीक बैठता है और दूसरों पर नहीं। जहाँ अधिकार-मानचित्र कहता है कि फ़ील्ड का मालिक ERP है, वहाँ ERP जीतता है। फिर से पढ़ें: सर्वाइवरशिप: कौन-सा मान जीतता है?।

4. Legacy ग्राहक रिकॉर्ड इम्पोर्ट होते हैं और मौजूदा accounts से मैच करते हैं। उन्हें merge करें?

सावधान रहें। मैच का मतलब merge ज़रूरी नहीं, और merge legacy ID और पुराने मान मिटा देता है जिन्हें आपको ट्रेस करना पड़ सकता है। उन्हें जोड़ें, जब तक कोई साफ़ विजेता न हो और डुप्लिकेट में ऐसा कुछ न हो जो आपको चाहिए। फिर से पढ़ें: Merge का मेरा नियम: एक साफ़ विजेता।

5. Data 360 का यूनिफ़ाइड प्रोफ़ाइल Dallas दिखाता है। टीम कहती है कि अब Dallas हर सिस्टम के लिए गोल्डन मान है। क्या ऐसा है?

नहीं। मिलान तय करता है कि यूनिफ़ाइड प्रोफ़ाइल क्या दिखाए; यह स्रोतों को नहीं बदलता और न मास्टरिंग का फ़ैसला लेता है। अगर हर सिस्टम को एक नियंत्रित मान इस्तेमाल करना है, तो वह को-एग्ज़िस्टेंस या सेंट्रलाइज़्ड MDM है, एक मालिक के साथ। फिर से पढ़ें: मिलान अब भी मास्टरिंग नहीं है।

6. मेडिकल रिकॉर्ड बनाम मार्केटिंग रिकॉर्ड की मैचिंग: वही नियम?

नहीं। मार्केटिंग में गलत मैच गलत ऑफ़र भेजता है; मेडिकल डेटा में यह दो लोगों का इतिहास मिला देता है। सख़्ती गलत होने की कीमत के हिसाब से तय करें, और जहाँ घुल-मिल जाना महँगा है वहाँ कम मैच करें। फिर से पढ़ें: गलत होने की कीमत।

7. Reps Salesforce से ERP के स्वामित्व वाला बिलिंग पता अपडेट करना चाहते हैं। आप इसे कैसे डिज़ाइन करेंगे?

एक अनुरोध के रूप में, एडिट के रूप में नहीं: Salesforce प्रस्तावित मान भेजता है, ERP उसे जाँचता और स्वीकार करता है, और आधिकारिक मान वापस प्रकाशित करता है। तब तक एक pending स्थिति रखें, और अस्वीकृति, टक्करों और गूँजों को संभालें। फिर से पढ़ें: दोतरफ़ा डेटा का मतलब दो मास्टर नहीं।

8. Steve Trucking में, वही John Smith दो रिटेल पार्टनर्स के मैनिफ़ेस्ट में आता है। उसे एकीकृत करें?

नहीं, जान-बूझकर। किसी पार्टनर को कभी दूसरे के प्राप्तकर्ता नहीं दिखने चाहिए, और एक यूनिफ़ाइड पहचान वह पुल है जिससे जानकारी रिसती है। जहाँ घुल-मिल जाना महँगा है वहाँ कम मैच करें; अगर कोई पार्टनर बार-बार आने वालों की पहचान चाहता है, तो उसे सिर्फ़ उसी पार्टनर तक सीमित रखें। फिर से पढ़ें: क्या मैं पार्टनर्स के पार प्राप्तकर्ताओं को एकीकृत करूँगा?।

9. एक rep ERP के स्वामित्व वाले पते के लिए नई गली भेजता है, जबकि उसी मिनट ERP में कोई शहर बदल देता है। आप क्या तय करेंगे?

क्या पता एक ट्रांज़ैक्शन की तरह चलता है। अगर हाँ, तो सारे फ़ील्ड साथ जाते हैं या कोई नहीं जाता, और अनुरोध अस्वीकार हो जाता है क्योंकि इस बीच पता बदल गया। यह पहली टक्कर से पहले तय करें, और याद रखें कि अनुरोध ERP का मान बदलने के लिए कह रहा है, उसे बदल नहीं रहा। फिर से पढ़ें: लूप और टक्करें।

10. एक क्लाइंट का एक ग्राहक दो ERP में है, और कोई भी दोनों रिकॉर्ड को सिंक में नहीं रखता। सेल्स एक account चाहती है। आप क्या सुझाएँगे?

एक account नहीं। अगर वे अपने ही ERP में रिकॉर्ड को सिंक में नहीं रख सकते, तो Salesforce उनके लिए यह नहीं कर सकता: उन्हें बराबरी वाले accounts या एक हायरार्की के रूप में दिखाएँ, और वह संरचना दिखाएँ जिसे सेल्स पहले से जानती है। हर ERP के लिए एक child वाले एक account के लिए ऐसा क्लाइंट चाहिए जो साझा मानों को सिंक में रखे। फिर से पढ़ें: पूछें कि वे ERP को सिंक में कैसे रखते हैं।

और जानें

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (अंग्रेज़ी में, 2026-09-25 को जाँचा गया): उद्देश्यों और उनके वेटेज की आधिकारिक सूची। परीक्षा बुक करने से पहले हमेशा मौजूदा संस्करण देखें।
• हर मॉड्यूल का अपना “और जानें” खंड उसके तथ्यों के पीछे के Salesforce दस्तावेज़ों की सूची देता है, जाँच की तारीख के साथ।