डेटा गुणवत्ता और गवर्नेंस

🌐 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 कोर्स के अध्याय 5 की अध्ययन गाइड। पहले छह मॉड्यूल पढ़ें; यह पेज आपको जाँचने में मदद करता है कि क्या याद रहा।

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

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

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

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

GOV-2: गवर्नेंस प्रोग्राम डिज़ाइन करना

• मैं जानता हूँ कि रिकॉर्ड का मालिक (एक्सेस के लिए प्लेटफ़ॉर्म का एक तरीका) डेटा का मालिक (एक बिज़नेस संपत्ति के रूप में डेटा के लिए जवाबदेह) नहीं है, और यह कि हर फ़ील्ड पर एक Data Owner दर्ज किया जा सकता है। (रिकॉर्ड का मालिक डेटा का मालिक नहीं है)
• मैं डेटा के मालिक (नीति तय करता है), डेटा स्टीवर्ड (उसे चालू रखता है) और कस्टोडियन (सिस्टम चलाता है) में फ़र्क कर सकता हूँ। (मालिक, स्टीवर्ड, कस्टोडियन)
• परीक्षा-ज्ञान: मैं गवर्नेंस प्रोग्राम चलाने के तीन तरीके जानता हूँ, सेंट्रलाइज़्ड, फ़ेडरेटेड (विकेंद्रीकृत) और हाइब्रिड, और यह कि हर एक का इस पर क्या असर है कि नीति कौन तय करता है और साझा परिभाषाएँ कहाँ रहती हैं। (प्रोग्राम कैसे चलता है)
• मैं RACI से यह जवाब दे सकता हूँ कि डेटा कहाँ बनता है, कहाँ बदला जाता है और कहाँ उसका हवाला दिया जाता है। (RACI को अपनी जगह कमानी होगी)
• मैं किसी गवर्नेंस नीति के लिए लागू करने का बिंदु बता सकता हूँ (परमिशन, वैलिडेशन, सिर्फ़ इंटीग्रेशन वाले फ़ील्ड, फ़ील्ड हिस्ट्री), सिर्फ़ ट्रेनिंग नहीं। (गवर्नेंस को मशीनी बनना होगा)
• मैं जानता हूँ कि मापने लायक गुणवत्ता संकेत वे हैं जिन पर कोई कार्रवाई करेगा। (वही मापें जिस पर कोई कार्रवाई करेगा)

SDM-2 और MDM-4: खराब डेटा को बाहर रखना

• मैं तय कर सकता हूँ कि Account बनाना खुला हो या बंद, और मैं ERP में मास्टर होने वाले Account के लिए अस्थायी रिकॉर्ड टाइप वाला रास्ता जानता हूँ। (खुला या बंद?, बीच का रास्ता)
• मैं गवर्न किए गए एट्रिब्यूट (ERP ID, कानूनी नाम) की रक्षा कर सकता हूँ, जबकि Salesforce के अपने फ़ील्ड बदले जा सकें: एक हाइब्रिड गोल्डन रिकॉर्ड। और मैं जानता हूँ कि Dynamic Forms पेज पर सिर्फ़ पढ़ने लायक फ़ील्ड लागू करना नहीं है; फ़ील्ड-लेवल सिक्योरिटी या वैलिडेशन रूल है। (गवर्न किए गए रिकॉर्ड की रक्षा करें, हर फ़्लो के लिए एक रिकॉर्ड टाइप)
• मैं जानता हूँ कि दोतरफ़ा फ़्लो सबसे मुश्किल हैं: अगर कोई फ़ील्ड ERP में मास्टर है, तो Salesforce उसे बदलने का अनुरोध कर रहा है, और टकराव के लिए एक नियम चाहिए (ERP जीतता है, बदला हो तो खारिज, या कोई व्यक्ति सुलझाए)। (गवर्न किए गए रिकॉर्ड की रक्षा करें)
• मैं जानता हूँ कि अनिवार्य फ़ील्ड नकली डेटा (N/A, 999999) पैदा कर सकते हैं, और इसके विकल्प क्या हैं। (अनिवार्य फ़ील्ड को नकली डेटा न बनाने दें)
• मैं तय कर सकता हूँ कि जाँच में फ़ेल होने वाले आने वाले डेटा का क्या हो: स्वीकार, खारिज या अलग (quarantine), और अपवाद का मालिक कौन है। (डेटा की हर सीमा को गुणवत्ता का एक फ़ैसला चाहिए)
• मैं जानता हूँ कि रेफ़रेंस डेटा को भी मेटाडेटा चाहिए: परिभाषाएँ, एक मालिक, एक सोर्स और सिस्टमों के बीच मैपिंग। (रेफ़रेंस डेटा को भी मेटाडेटा चाहिए)

DM-3: बिज़नेस और तकनीकी मेटाडेटा

• परीक्षा-ज्ञान: मैं बिज़नेस मेटाडेटा (मतलब, परिभाषाएँ, मालिक, नियम, संवेदनशीलता) को तकनीकी मेटाडेटा (ऑब्जेक्ट, फ़ील्ड, टाइप, API नाम, स्कीमा, मैपिंग, लिनिएज) से अलग पहचानता हूँ। (दो तरह का मेटाडेटा)
• मैं बिज़नेस डिक्शनरी (इसका मतलब क्या है), लिनिएज (यह कहाँ से आया) और वर्गीकरण (इसके साथ कैसा बर्ताव होना चाहिए) में फ़र्क जानता हूँ। (अपने डेटा को जानें)
• मैं Salesforce के वर्गीकरण फ़ील्ड जानता हूँ: Data Owner, Field Usage, Data Sensitivity Level, Compliance Categorization, स्टैंडर्ड और कस्टम फ़ील्ड पर। (वर्गीकरण एक अलग सवाल का जवाब देता है)
• मैं जानता हूँ कि संवेदनशील फ़ील्ड को वर्गीकृत करना है, हर फ़ील्ड को नहीं, और यह कि लागू किए बिना वर्गीकरण सिर्फ़ सजावट है। (लागू किए बिना वर्गीकरण सिर्फ़ सजावट है)

GOV-1: व्यक्तिगत और संवेदनशील डेटा

• मैं मुख्य कानूनों को पहचानता हूँ (GDPR, CCPA/CPRA, PIPEDA, LGPD, ऑस्ट्रेलिया का Privacy Act, HIPAA, PCI DSS, SOX, COPPA), और जानता हूँ कि GDPR EU के बाहर के संगठनों तक पहुँच सकता है, और यह कि कानूनों में क्या साझा है: अधिकार, ट्रांसफ़र, उल्लंघन की सूचना और जवाबदेही। (वे नियम जिन्हें आपको पहचानना चाहिए, कानून सीमा पर नहीं रुकते)
• मैं एन्क्रिप्शन, मास्किंग, छद्मनामीकरण और अनामीकरण में फ़र्क जानता हूँ, और यह कि छद्मनामीकृत डेटा अब भी व्यक्तिगत डेटा है। (अनामीकृत, छद्मनामीकृत, एन्क्रिप्टेड, मास्क्ड)
• मैं जानता हूँ कि कम इकट्ठा करना प्राइवेसी का एक कंट्रोल है, और रिटेंशन शुरू में ही डिज़ाइन होता है। (कम इकट्ठा करना एक आर्किटेक्चर फ़ैसला है, रिटेंशन मॉडल का हिस्सा है)
• मैं सहमति डेटा मॉडल जानता हूँ: Individual पर ग्लोबल सहमति, एंगेजमेंट चैनल की सहमति, कॉन्टैक्ट पॉइंट की सहमति, और डेटा इस्तेमाल का मकसद (data use purpose)। (वह मॉडल इस्तेमाल करें जो Salesforce पहले से बना चुका है)
• मैं जानता हूँ कि अनुरोधों की समय-सीमा होती है (GDPR: एक महीना, जिसे दो और महीने बढ़ाया जा सकता है), इसलिए कॉपियों का नक्शा पहले से मौजूद होना चाहिए। (घड़ी चल रही है)
• मैं जानता हूँ कि भुला दिए जाने के अधिकार का मतलब है हर कॉपी ढूँढना (हिस्ट्री, आर्काइव, एनालिटिक्स, लॉग, फ़ाइलें, फ़्री टेक्स्ट), और यह कि Privacy Center की नीतियाँ हर ऑब्जेक्ट के लिए किसी ग्राहक रिकॉर्ड पर चलती हैं। (अब व्यक्ति कहता है: मुझे भूल जाओ, Privacy Center एक टूल है)
• मैं Shield Platform Encryption के ट्रेड-ऑफ़ जानता हूँ: probabilistic फ़ील्ड को SOQL में फ़िल्टर, ग्रुप या सॉर्ट नहीं किया जा सकता; deterministic एन्क्रिप्शन फ़िल्टर करने देता है; एन्क्रिप्टेड फ़ील्ड criteria-based शेयरिंग नहीं चला सकते। (एन्क्रिप्शन एक कंट्रोल है, कम्प्लायंस नहीं)
• मैं जानता हूँ कि प्रोडक्शन का संवेदनशील डेटा सैंडबॉक्स में कॉपी नहीं करना है, और यह कि Data Mask की जगह Data Mask & Seed ले रहा है। (प्रोडक्शन का जोखिम सैंडबॉक्स में कॉपी न करें)
• मैं फ़ील्ड हिस्ट्री ट्रैकिंग (हर ऑब्जेक्ट पर 20 फ़ील्ड तक; 18 महीने, 24 सिर्फ़ API से; लंबे टेक्स्ट के लिए सिर्फ़ बदलाव होना दर्ज होता है) बनाम Field Audit Trail (200 फ़ील्ड तक, डिलीट करने तक रखा जाता है) जानता हूँ। (इतिहास भी डेटा है)
• मैं Event Monitoring लॉग का रिटेंशन जानता हूँ (ऐड-ऑन के बिना कुछ इवेंट के लिए 1 दिन, उसके साथ डिफ़ॉल्ट रूप से 30 दिन, बढ़ाने पर 365 तक), और यह कि ज़रूरत पड़ने से पहले इवेंट्स को किसी SIEM में एक्सपोर्ट करना है: पेड लॉग कॉन्ट्रैक्ट शुरू होने से पहले के वापस नहीं मिल सकते। (ऑडिटिंग और मॉनिटरिंग एक जैसे नहीं हैं)

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

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

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

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

शब्द	एक पंक्ति में
डेटा गवर्नेंस	डेटा की नीतियाँ, और वह आर्किटेक्चर जो उन्हें सच बनाता है
डेटा का मालिक (data owner)	किसी तरह के डेटा के लिए जवाबदेह व्यक्ति या विभाग
डेटा स्टीवर्ड	वह व्यक्ति जो रोज़-ब-रोज़ डेटा को सेहतमंद रखता है
कस्टोडियन (custodian)	वह टीम जो डेटा रखने वाले सिस्टम चलाती है
RACI	Responsible, Accountable, Consulted, Informed (ज़िम्मेदार, जवाबदेह, सलाह ली गई, सूचित)
अस्थायी (provisional) रिकॉर्ड	आधिकारिक सिस्टम के स्वीकार करने से पहले बनाया गया रिकॉर्ड
बिज़नेस डिक्शनरी	बिज़नेस के अहम शब्दों की सहमति वाली परिभाषाएँ
लिनिएज (डेटा की वंशावली)	कोई वैल्यू कहाँ से आई और रास्ते में उसके साथ क्या हुआ
डेटा वर्गीकरण	डेटा पर संवेदनशीलता और कम्प्लायंस श्रेणी के लेबल लगाना, ताकि उसे सही कंट्रोल मिलें
टैक्सोनॉमी	लेबलों का वह सेट जिससे कोई संगठन डेटा वर्गीकृत करता है
व्यक्तिगत डेटा	वह जानकारी जो किसी व्यक्ति को पहचानती है, या उससे वापस जोड़ी जा सकती है
छद्मनामीकरण (pseudonymization)	पहचानकर्ता बदलना, जबकि वापस जाने का रास्ता अब भी मौजूद है; अब भी व्यक्तिगत डेटा
अनामीकरण (anonymization)	व्यक्ति को पहचानने की वाजिब क्षमता हटा देना
सहमति डेटा मॉडल	व्यक्ति, चैनल, कॉन्टैक्ट पॉइंट और मकसद के हिसाब से सहमति के लिए Salesforce के ऑब्जेक्ट
भुला दिए जाने का अधिकार	जहाँ कानून देता है, वहाँ किसी व्यक्ति का अपना व्यक्तिगत डेटा मिटवाने का अधिकार
हाइब्रिड गोल्डन रिकॉर्ड	एक रिकॉर्ड जिसमें मास्टर सिस्टम के फ़ील्ड और Salesforce के अपने फ़ील्ड हों, हर एक का एक ही स्रोत
बिज़नेस / तकनीकी मेटाडेटा	डेटा का मतलब क्या है और उसका मालिक कौन है / वह कैसे बना है और कैसे चलता है
Field Audit Trail	लंबी फ़ील्ड हिस्ट्री: हर ऑब्जेक्ट पर 200 फ़ील्ड तक, डिलीट होने तक रखी जाती है
Event Monitoring	लॉगिन, एक्सपोर्ट, API कॉल और व्यू के लॉग, सीमित समय तक रखे जाते हैं
SIEM	एक सिक्योरिटी रिपॉज़िटरी जहाँ इवेंट लॉग रखे और विश्लेषित किए जाते हैं

खुद को परखें

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

1. नीति कहती है कि ग्राहक का कानूनी नाम सिर्फ़ Finance बदल सकता है। टीम इसे ट्रेनिंग में बताने की योजना बना रही है। क्या छूट रहा है?

लागू करने का एक बिंदु। ट्रेनिंग कोई कंट्रोल नहीं है: फ़ील्ड-लेवल एक्सेस, ऐसा फ़ील्ड जिसे सिर्फ़ इंटीग्रेशन लिखता है, एक वैलिडेशन रूल, या एक नियंत्रित प्रक्रिया इस्तेमाल करें। नीति मालिक तय करते हैं; आर्किटेक्ट उसे मशीनी तौर पर सच बनाता है। गवर्नेंस को मशीनी बनना होगा फिर से पढ़ें।

2. ग्राहक ERP में मास्टर होते हैं। सेल्स रिप्स को नए संभावित ग्राहकों को तुरंत बेचना शुरू करना है। दो सिस्टमों के मास्टर रिकॉर्ड बनाए बिना आप उन्हें यह कैसे करने देंगे?

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

3. एक नया अनिवार्य फ़ील्ड “N/A” और “999999” से भर रहा है। क्या हुआ, और इसके बजाय आप क्या करेंगे?

यूज़र्स को जवाब जानने से पहले ही जवाब देने पर मजबूर किया गया। इसे प्रक्रिया में बाद में अनिवार्य करें, किसी दूसरे सिस्टम को यह देने दें, अस्थायी स्थिति इस्तेमाल करें, या जब “पता नहीं” असली जवाब हो तो साफ़ Unknown की अनुमति दें। अनिवार्य फ़ील्ड को नकली डेटा न बनाने दें फिर से पढ़ें।

4. टीम ने नामों की जगह टोकन लगा दिए और कहती है कि डेटा अनामीकृत है, इसलिए डिलीशन का अनुरोध पूरा हो गया। क्या ऐसा है?

नहीं, अगर टोकन को व्यक्ति से वापस जोड़ा जा सकता है: वह छद्मनामीकरण है, और डेटा अब भी व्यक्तिगत है। ठीक-ठीक बताएँ कि सिस्टम क्या करता है, मैपिंग कहाँ रहती है, और लीगल को तय करने दें कि क्या इससे आवश्यकता पूरी होती है। अनामीकृत, छद्मनामीकृत, एन्क्रिप्टेड, मास्क्ड फिर से पढ़ें।

5. एक प्राप्तकर्ता डिलीवरी के मैसेज के लिए सहमत है, पर मार्केटिंग के लिए नहीं। मॉडल को इसे कैसे रखना चाहिए?

सहमति डेटा मॉडल से, एक चेकबॉक्स से नहीं: व्यक्ति, चैनल (SMS), खास नंबर, और डेटा इस्तेमाल का मकसद (डिलीवरी की सूचनाएँ, मार्केटिंग नहीं)। और तय करें कि सहमति के लिए कौन-सा सिस्टम आधिकारिक है, ताकि सहमति वापस लेना उस पर काम करने वाले हर सिस्टम तक पहुँचे। वह मॉडल इस्तेमाल करें जो Salesforce पहले से बना चुका है फिर से पढ़ें।

6. कम्प्लायंस को एक एन्क्रिप्टेड Social Security फ़ील्ड पर रिपोर्ट फ़िल्टर करनी हैं। फ़ील्ड डिफ़ॉल्ट एन्क्रिप्शन स्कीम इस्तेमाल करता है। समस्या क्या है?

Probabilistic एन्क्रिप्शन SOQL के WHERE क्लॉज़ या डेटा-मैनेजमेंट फ़िल्टर में फ़िल्टर करने नहीं देता। Deterministic एन्क्रिप्शन थोड़ी मज़बूती की कीमत पर फ़िल्टर करने देता है। एन्क्रिप्शन ट्रेड-ऑफ़ वाला एक डिज़ाइन फ़ैसला है, आखिर में टिक किया जाने वाला चेकबॉक्स नहीं। एन्क्रिप्शन एक कंट्रोल है, कम्प्लायंस नहीं फिर से पढ़ें।

7. किसी घटना के छह महीने बाद, कोई पूछता है कि रिकॉर्ड के एक सेट को किसने एक्सपोर्ट किया। किसी ने Event Monitoring का स्टोरेज सेट नहीं किया था। आप उन्हें क्या बता सकते हैं?

शायद कुछ नहीं: इवेंट लॉग सीमित समय तक रखे जाते हैं (बढ़ाने पर भी ज़्यादा से ज़्यादा एक साल), इसलिए उससे पुराना सब कुछ चला जाता है, जब तक उसे एक्सपोर्ट न किया गया हो। ज़रूरत पड़ने से पहले Event Monitoring सेट करें और इवेंट्स को किसी SIEM में भेजें। ऑडिटिंग और मॉनिटरिंग एक जैसे नहीं हैं फिर से पढ़ें।

8. एक रिप Salesforce से किसी ग्राहक का कानूनी नाम बदलने को कहता है, जो ERP में मास्टर है। उन्हीं मिनटों में कोई उसे ERP में बदल देता है। डिज़ाइन को क्या कहना चाहिए?

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

9. किसी व्यक्ति का डेटा मिटाने का अनुरोध आता है। टीम की योजना है कि अब यह नक्शा बनाना शुरू करे कि उसका डेटा कहाँ रहता है। समस्या क्या है?

घड़ी पहले से चल रही है: GDPR के तहत एक महीना, जिसे जटिल अनुरोधों के लिए दो और महीने बढ़ाया जा सकता है। कॉपियों का नक्शा अनुरोध आने से पहले मौजूद होना चाहिए। घड़ी चल रही है फिर से पढ़ें।

और जानें

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