डेटा आर्किटेक्ट की तरह सोचना

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

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

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

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

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

परिदृश्य को आर्किटेक्ट की तरह पढ़ना (हर उद्देश्य को सहारा देता है)

• मैं असली ज़रूरत को उस डिज़ाइन से अलग करता हूँ जिसमें वह आई (“हमें Approver 2 और Approver 3 फ़ील्ड चाहिए” बनाम “हमें हर अप्रूवल ट्रैक करना है”)। (ज़रूरत को बस यूँ ही न मान लें)
• मैं उन छिपी हुई ज़रूरतों को ढूँढ़ता हूँ जो किसी ने नहीं बताईं: मालिकाना हक, ताज़गी, विफलता, रिटेंशन, एक्सेस। (छिपी हुई ज़रूरतें ढूँढ़ें)
• मैं इसे संख्याओं में रखता हूँ: रोज़ का वॉल्यूम, साल का, बढ़त के साथ, और मैं ध्यान देता हूँ कि कब एक और शून्य जवाब बदल देता है। (अपने आँकड़े जानें)
• काम करने वाले कई जवाबों में से, मैं बताई गई ज़रूरतों और पाबंदियों के आधार पर तुलना करता हूँ कि हर एक से क्या मिलता है और क्या छूटता है। (जानें कि बदले में आप क्या छोड़ रहे हैं, पाबंदियाँ जवाब बदल देती हैं)
• मैं लागत, लाइसेंसिंग और सीमाओं को इस बात का हिस्सा मानता हूँ कि कोई टूल फ़िट होता है या नहीं, बाद में सोचने की चीज़ नहीं। (नौ सवाल)

डेटा मॉडल (DM-1 को सहारा देता है)

• मैं किसी मॉडल को इस आधार पर परख सकता हूँ कि क्या वह बिज़नेस को सहारा देता है, उसके साथ बढ़ सकता है, और अच्छा प्रदर्शन करता है। (सहारा। विकास। प्रदर्शन।)
• मैं ऐसे मॉडल को पहचान सकता हूँ जो बहुत सपाट है (Field 1, Field 2, Field 3), ज़रूरत से ज़्यादा नॉर्मलाइज़्ड है, या गलत स्टैंडर्ड ऑब्जेक्ट पर बना है। (बहुत सपाट, बहुत पेचीदा, या बस गलत)
• मैं जानता हूँ कि पिकलिस्ट छोटी, स्थिर सूची के लिए क्यों ठीक है और lookup ऐसी सूची के लिए क्यों ठीक है जो बढ़ती रहती है या किसी इंटीग्रेशन से आती है। (समस्या हल करने के कई तरीके)
• मैं जानता हूँ कि जिस key में कोई अर्थ छिपा हो (जैसे नाम का कोई हिस्सा), वह उस अर्थ के बदलते ही टूट जाती है। (कुछ फ़ैसले बदलना सस्ता होता है)

जो पहले से है उसे बदलना (DM-1 और SDM-2 को सहारा देता है)

• मैं जानता हूँ कि किसी फ़ील्ड का टाइप बदलना, या किसी मौजूदा फ़ील्ड को Required (अनिवार्य) बनाना, बाद में चीज़ें क्यों तोड़ सकता है, और जब तक कोड या flows फ़ील्ड को रेफ़र करते हैं तब तक प्लेटफ़ॉर्म टाइप बदलने से क्यों रोकता है। (हड्डियाँ बदलने में सावधान रहें)
• मैं यह पैटर्न जानता हूँ: बदलने के बजाय जोड़ें, चौंकाने के बजाय डिप्रिकेट करें, और यह भी कि Field Usage किसी फ़ील्ड को डिप्रिकेशन के उम्मीदवार के रूप में चिह्नित कर सकता है। (हड्डियाँ बदलने में सावधान रहें)
• मैं पलटने की कसौटी के पीछे के master-detail तथ्य जानता हूँ: detail का एक्सेस और ownership master के हिसाब से चलते हैं, master को डिलीट करने पर उसके details डिलीट हो जाते हैं, roll-up summary के लिए master-detail चाहिए, और lookup तभी master-detail में बदलता है जब हर रिकॉर्ड में वैल्यू हो। (पलटने की कसौटी, और जानें)

लाइसेंस और शेयरिंग (SDM-1 को सहारा देता है)

• मैं जानता हूँ कि high-volume community यूज़र्स (इनमें Customer Community भी है) के रोल नहीं होते और वे शेयरिंग मॉडल इस्तेमाल नहीं करते, इसलिए उनका एक्सेस sharing sets और share groups से आता है, और Apex sharing उन तक नहीं पहुँच सकता। (एक हल किया हुआ उदाहरण: Apex sharing)

विफलता (MIG-1 और इंटीग्रेशन वाले अध्यायों को सहारा देता है)

• मैं जानता हूँ कि “जॉब पूरा हुआ” और डेटा सही है एक बात नहीं है, और मिलान (reconciliation) उन रिकॉर्ड को कैसे ढूँढ़ता है जो नहीं पहुँचे। (आंशिक सफलता भी ऐसी विफलता है जिसे आपको समझना होगा)

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

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

• किसी के हाथ में ब्लूप्रिंट होना चाहिए। आर्किटेक्चर अधूरी जानकारी के साथ अच्छे फ़ैसले लेना, और उनके नतीजे जानना है।
• डेटा मॉडल ही हड्डियाँ है। बाकी सब उसी पर बनता है।
• पलटने की कसौटी: इसे पलटना कितना मुश्किल है, और इस पर कितना कुछ निर्भर होगा?
• आर्किटेक्चर गुरुत्व पैदा करता है। बदलाव को महँगा निर्भरताएँ बनाती हैं, बदलाव खुद नहीं।
• असर के दायरे के बारे में सोचें, Salesforce के अंदर भी और पूरे एंटरप्राइज़ में भी। आर्किटेक्चर दो-तरफ़ा ट्रैफ़िक है।
• लिख लें कि क्यों: संदर्भ, विकल्प, फ़ैसला, नतीजे, मालिक, समीक्षा। नया फ़ैसला दर्ज करें; पुराना मिटाएँ नहीं।
• किस बात में सबसे अच्छा? एक कम-से-सर्वोत्तम फ़ैसला सर्वोत्तम आर्किटेक्चर का हिस्सा हो सकता है, अगर आप जानते हैं कि आप उसे ले रहे हैं।
• सर्वोत्तम की एक तस्वीर साथ रखें, ताकि आप जानें कि आप उससे किस दिशा में दूर जा रहे हैं, और क्यों।
• Think Correct. Think Fast. (सही सोचें। तेज़ सोचें।) रफ़्तार उस सोच से आती है जो पल आने से पहले हो चुकी हो।
• आज के लिए बनाएँ। कल की योजना बनाएँ। विफलता की योजना बनाएँ। और जब कोई संख्या न दे, तो 30 प्रतिशत बढ़त मानकर चलें।
• नौ सवाल सीखें, सिर्फ़ जवाब नहीं।
• AI एक रॉकेट बूस्टर है। बनाना समझ-बूझ नहीं है, जो पलटा नहीं जा सकता वह अब भी पलटा नहीं जा सकता, और इंसानी समीक्षा कोई रस्म नहीं है। भरोसा करें, पर जाँचें।

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

शब्द	एक पंक्ति में
आर्किटेक्चरल फ़ैसला	ऐसा फ़ैसला जिसे पलटना मुश्किल हो, और जिस पर बहुत कुछ निर्भर हो
पलटने की कसौटी (Reversibility Test)	इसे पलटना कितना मुश्किल है, और इस पर कितना कुछ निर्भर होगा?
गुरुत्व	वे निर्भरताएँ जो समय के साथ किसी फ़ैसले के आसपास जमा हो जाती हैं
असर का दायरा (blast radius)	वह सब कुछ जो किसी फ़ैसले के बदलने पर हिलता है
निर्णय रिकॉर्ड	संदर्भ, विकल्प, फ़ैसला, नतीजे, मालिक और समीक्षा-बिंदु, छोटा रखा गया
ट्रेड-ऑफ़	किसी विकल्प से क्या मिलता है, और उसके बदले वह क्या छोड़ता है
छिपी हुई ज़रूरत	कुछ ऐसा जिसकी बिज़नेस बिना माँगे उम्मीद करता है, जैसे लोड फ़ेल होने पर रिकवरी
Steve की “शून्यों की गिनती” (Steve’s Number of Zeros)	वॉल्यूम में एक और शून्य पूरा आर्किटेक्चर बदल सकता है
मिलान (reconciliation)	जो होना चाहिए था उसकी तुलना जो हुआ उससे, रिकॉर्ड-दर-रिकॉर्ड
डिप्रिकेट करना	किसी चीज़ को जाने वाली के रूप में चिह्नित करना, फिर सोच-समझकर उसे रिटायर करना, उसे जगह पर बदलने के बजाय
High-volume यूज़र	एक community यूज़र (लाइसेंसों में Customer Community भी) जिसका कोई रोल नहीं, शेयरिंग मॉडल से बाहर
स्कीमा का बेतरतीब फैलाव (schema sprawl)	ऐसे ऑब्जेक्ट और फ़ील्ड जो बनाना सस्ता होने की वजह से जमा होते जाते हैं, जब तक कि मॉडल किसी का डिज़ाइन किया हुआ न रहे

खुद को परखें

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

1. एक सेल्स टीम Opportunity पर Approver 2 और Approver 3 फ़ील्ड माँगती है, हर एक की तारीख के साथ। आप क्या पूछेंगे, और क्या बना सकते हैं?

“क्यों” पूछें, और यह कि कितने अप्रूवल हो सकते हैं। अगर दो या तीन से ज़्यादा हो सकते हैं, तो ज़रूरत हर अप्रूवल को ट्रैक करने की है, फ़ील्ड जोड़ने की नहीं: एक चाइल्ड ऑब्जेक्ट, हर अप्रूवल का एक रिकॉर्ड। दोबारा पढ़ें: ज़रूरत को बस यूँ ही न मान लें।

2. कोई एक फ़ील्ड का लेबल बदलना चाहता है, और कोई दूसरा उस कस्टमर आइडेंटिफ़ायर का फ़ॉर्मेट बदलना चाहता है जिसे पाँच सिस्टम पहले से स्टोर करते हैं। आपका ज़्यादा ध्यान किस पर जाना चाहिए, और क्यों?

आइडेंटिफ़ायर पर। लेबल बदलना सस्ता है। आइडेंटिफ़ायर पलटने की कसौटी पर खरा नहीं उतरता: पलटना मुश्किल है, और उस पर पहले से बहुत कुछ निर्भर है। गलत होने की कीमत के अनुपात में ध्यान दें। दोबारा पढ़ें: कुछ फ़ैसले बदलना सस्ता होता है।

3. एक टेक्स्ट फ़ील्ड बरसों से इस्तेमाल में है। बिज़नेस चाहता है कि अब उसमें नंबर रहे। आपका तरीका क्या है?

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

4. 1,200 लोकेशन, हर लोकेशन पर रोज़ 100 अपॉइंटमेंट, साल में लगभग 305 दिन, हर अपॉइंटमेंट के दो रिकॉर्ड, पाँच साल का डेटा रखा जाता है, 30 प्रतिशत बढ़त। मोटे तौर पर कितने रिकॉर्ड, और यह क्यों मायने रखता है?

पहले साल में लगभग 73 मिलियन रिकॉर्ड (36.6 मिलियन अपॉइंटमेंट, हर एक के दो रिकॉर्ड), और बढ़त के साथ पाँच साल में 650 मिलियन से ज़्यादा। वही फ़ीचर, कुछ और शून्य, बिल्कुल अलग आर्किटेक्चर। दोबारा पढ़ें: अपने आँकड़े जानें।

5. रात का एक लोड एक मिलियन रिकॉर्ड पर “पूरा हुआ” बताता है। आपको कैसे पता चलेगा कि यह सफल रहा?

आप मिलान करते हैं। पाने वाली तरफ़ हर सेव किए गए रिकॉर्ड की पुष्टि करती है; भेजने वाला जो भेजा उसकी तुलना जिसकी पुष्टि हुई उससे करता है। गायब पुष्टियों का मतलब है कि यह सफल नहीं रहा, जॉब का स्टेटस चाहे जो कहे, और वे बताती हैं कि किन रिकॉर्ड को दोबारा भेजना है, किसी व्यक्ति के पास भेजना है, या किन पर अलर्ट उठाना है। दोबारा पढ़ें: आंशिक सफलता भी ऐसी विफलता है जिसे आपको समझना होगा।

6. 15 मिलियन Customer Community यूज़र्स की एक community को रिकॉर्ड का पेचीदा एक्सेस चाहिए। कोई Apex sharing का सुझाव देता है। समस्या क्या है?

वे high-volume यूज़र्स हैं: कोई रोल नहीं, शेयरिंग मॉडल से बाहर, इसलिए Apex के लिखने को कोई share रिकॉर्ड नहीं है। एक्सेस sharing sets और share groups से आता है। लाइसेंस ने तय किया कि कौन-से शेयरिंग टूल मौजूद हैं। दोबारा पढ़ें: एक हल किया हुआ उदाहरण: Apex sharing।

7. एक AI टूल मिनटों में एक नए ऐप के लिए बीस ऑब्जेक्ट बना देता है। अब आर्किटेक्ट का काम क्या है?

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

और जानें

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