मॉडल को Salesforce में बदलें

🌐 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 द्वारा अनुवादित। समुदाय ने अभी इसकी समीक्षा नहीं की है। अंग्रेज़ी में पढ़ें

मॉड्यूल 6 (कुल 6 में से) — अध्याय अर्थ के लिए डेटा मॉडलिंग, Data Architect कोर्स का अध्याय 2। हर मॉड्यूल अपने आप में पूरा है। पिछला: तीसरे नॉर्मल फ़ॉर्म तक डिज़ाइन करें, फिर पीछे हटें · अगला: अध्याय की अध्ययन गाइड, फिर अगला अध्याय: Salesforce डेटा आर्किटेक्चर

यह मॉड्यूल किस सवाल का जवाब देता है: एक लॉजिकल डेटा मॉडल फ़िज़िकल Salesforce डेटा मॉडल कैसे बनता है?

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

बैठो, रुको, मॉडल करो

फ़िज़िकल कदम किसी छोटी चीज़ पर सबसे आसानी से दिखता है, इसलिए पालतू पहले।

बिज़नेस और लोग कौन हैं? ब्रीडर एक बिज़नेस है, इसलिए वह Breeder रिकॉर्ड टाइप वाला एक Account बनता है। मालिक भी एक Account है, या Person Account, Owner रिकॉर्ड टाइप के साथ। एक ही स्टैंडर्ड ऑब्जेक्ट की दो किस्में, डायग्राम के ऊपर अगल-बगल, ठीक वहीं जहाँ वे मॉड्यूल 1 से हैं।

किसका कोई स्टैंडर्ड घर नहीं है? पालतू, नस्ल, करतब, पालतू का करतब और करतब का मूल्यांकन कस्टम ऑब्जेक्ट बनते हैं। और याद है वह प्रजाति जो हमने मॉड्यूल 5 में पालतू पर कॉपी की थी? यहाँ उसे अपना काम मिलता है: वह पालतू का रिकॉर्ड टाइप बन जाती है, Dog या Cat। एक Dog ऑब्जेक्ट और एक Cat ऑब्जेक्ट के बजाय, दो रिकॉर्ड टाइप वाला एक ऑब्जेक्ट, हर एक का अपना पेज लेआउट और पिकलिस्ट वैल्यू।

कौन-से संबंध master-detail हैं? मैं master-detail सिर्फ़ वहीं इस्तेमाल करता हूँ जहाँ चाइल्ड का पैरेंट कभी नहीं बदलेगा। पालतू का करतब ज़िंदगी भर अपने पालतू का होता है, और हर करतब का मूल्यांकन अपने पालतू के करतब का, इसलिए दोनों master-detail हैं। इसका फ़ायदा तुरंत मिलता है: master-detail ही पालतू को उसके पालतू के करतबों का roll-up summary रखने देता है, ताकि मॉड्यूल 5 वाली आने वाले करतब की गिनती अपने-आप साथ-साथ चलती रहे। लेकिन पालतू घर बदलते हैं, इसलिए मालिक एक lookup है।

कौन-से lookup हैं? Salesforce एक पैरेंट पर 10,000 से ज़्यादा चाइल्ड की सलाह नहीं देता। बैठो जैसा लोकप्रिय करतब, कोई आम नस्ल या कोई बड़ा ब्रीडर इसे आसानी से पार कर सकता है, इसलिए पालतू का करतब अपने करतब की ओर lookup से इशारा करता है, और पालतू अपनी नस्ल और ब्रीडर की ओर भी इसी तरह। और जहाँ हो सके, पॉलीमॉर्फ़िक संबंधों से बचें, वे जिनमें एक फ़ील्ड कई ऑब्जेक्ट टाइप की ओर इशारा कर सकता है। पहले दिन वे सुविधाजनक होते हैं और बाद में हर उस चीज़ के लिए मुश्किल जिसे उन्हें पढ़ना है: रिपोर्ट, इंटीग्रेशन, और अब एजेंट।

प्लेटफ़ॉर्म से बाहर क्या रहता है? अगर पालतू ऐसा GPS कॉलर पहनता है जो बताता है कि वह कहाँ है, तो उस लोकेशन को अंदर कॉपी करने की ज़रूरत ही नहीं। वह एक एक्सटर्नल ऑब्जेक्ट हो सकता है, जो कॉलर के ट्रैकिंग सिस्टम से लाइव पढ़ा जाए।

Click to enlarge

उस डायग्राम का हर फ़ैसला किसी ऐसी चीज़ तक वापस जाता है जो हमने पहले तय की थी, और बात यही है। अब वही कदम Steve Trucking के लिए।

लॉजिकल मॉडल से शुरू करें

हमारे Steve Trucking लॉजिकल मॉडल में अब रिटेल पार्टनर, डिस्ट्रिब्यूशन सेंटर, मैनिफ़ेस्ट, डिलीवरी, डिलीवरी आइटम, प्राप्तकर्ता, रूट, स्टॉप, क्रू, ट्रक और क्रू असाइनमेंट हैं। ये बिज़नेस की अवधारणाएँ हैं, और अब मैं इन्हें Salesforce से मैप करना शुरू कर सकता हूँ।

एक रिटेल पार्टनर शायद Account हो। एक डिलीवरी शायद किसी ऐसी चीज़ से मैप हो जो Salesforce के पास फ़ील्ड में शेड्यूल किए गए काम के लिए पहले से है, या वह कस्टम ऑब्जेक्ट बन सकती है। मैनिफ़ेस्ट के लिए कोई स्टैंडर्ड चीज़ फ़िट नहीं बैठती, इसलिए वह शायद कस्टम बनेगा। और प्राप्तकर्ता सच में मुश्किल सवाल है: Person Account, Contact, या बस डिलीवरी पर दर्ज जानकारी? उसका जवाब हम अगले अध्याय में ठीक से देंगे।

अहम शब्द अब भी शायद है। सिर्फ़ इसलिए इम्प्लीमेंटेशन मान न लें कि बिज़नेस की कोई अवधारणा Salesforce ऑब्जेक्ट जैसी सुनाई देती है। इसीलिए हमने पहले लॉजिकल मॉडल बनाया: वह हमें कुछ देता है जिस पर Salesforce डिज़ाइन को परखा जा सके।

बिज़नेस एंटिटी का मतलब अपने-आप कस्टम ऑब्जेक्ट नहीं है

यह एक जाल है जिससे मैं चाहता हूँ कि एडमिन बचें: “हमने ग्यारह एंटिटी पहचानीं, तो हमें ग्यारह कस्टम ऑब्जेक्ट चाहिए।” नहीं। एक लॉजिकल एंटिटी बताती है कि बिज़नेस की वह अवधारणा मायने रखती है। वह यह तय नहीं करती कि Salesforce उसे कैसे स्टोर करे। कोई अवधारणा स्टैंडर्ड ऑब्जेक्ट बन सकती है, कस्टम ऑब्जेक्ट, ऑब्जेक्ट के बीच का संबंध, एक या कुछ फ़ील्ड, कॉन्फ़िगरेशन में संभाली जाने वाली वैल्यू, या ऐसा डेटा जो पूरी तरह Salesforce से बाहर रहता है (Steve Trucking की डिलीवरी फ़ोटो इसके अच्छे उम्मीदवार हैं)। ये फ़ैसले फ़िज़िकल मॉडल में होते हैं, और ठीक इसीलिए हमने इन्हें पहली कॉल पर नहीं किया।

एट्रिब्यूट फ़िज़िकल फ़ील्ड बनते हैं

एट्रिब्यूट के साथ भी यही बदलाव होता है। हमारे लॉजिकल ट्रक में यूनिट नंबर, VIN, मेक, मॉडल, मॉडल वर्ष, लाइसेंस प्लेट और स्टेटस है। अब हम तय करते हैं कि वे फ़िज़िकल रूप में कैसे मौजूद रहेंगे: कौन-सा ऑब्जेक्ट उनका मालिक है, वे कौन-से फ़ील्ड टाइप इस्तेमाल करेंगे, कौन-से अनिवार्य हैं, कौन-से यूनिक होने चाहिए, कौन-से बाहरी ID हैं, किन्हें वैलिडेशन चाहिए, कौन-से स्टोर होने के बजाय निकाले (derive) जाते हैं, और कौन-से संवेदनशील हैं। लॉजिकल स्तर पर हमने पूछा था कि ट्रक का मतलब क्या है। फ़िज़िकल स्तर पर हम पूछते हैं कि Salesforce ट्रक को कैसे दर्शाएगा। अलग सवाल।

Click to enlarge

संबंध प्लेटफ़ॉर्म के फ़ैसले बनते हैं

संबंधों पर हमने जो सारा समय लगाया, उसका फ़ल यहाँ मिलता है। हमें पहले से पता है कि हर एक one-to-one, one-to-many या many-to-many है, अनिवार्य है या वैकल्पिक, और क्या उसका इतिहास मायने रखता है। अब हम तय करते हैं कि Salesforce उसे कैसे लागू करे: एक lookup, एक master-detail, या एक Salesforce Junction Object, और शायद अपने ख़ुद के एट्रिब्यूट वाला एक जंक्शन, क्योंकि, जैसा हमने पाया, संबंध का अपना बिज़नेस अर्थ हो सकता है।

क्रू असाइनमेंट को याद करें। हम यह अध्याय यह कहकर शुरू कर सकते थे, “चलो क्रू और ट्रक के बीच एक Salesforce Junction Object बनाते हैं।” देखिए हम क्या छोड़ देते: संबंध क्यों है, क्या उसे तारीख़ और रूट चाहिए, क्या उसका कोई स्टेटस है, और क्या हफ़्तों बाद आने वाले नुकसान के क्लेम को उसका इतिहास चाहिए। ये बिज़नेस सवाल हमें बताते हैं कि क्रू असाइनमेंट है क्या। उसके बाद ही हमें तय करना चाहिए कि Salesforce उसे कैसे बनाए, और क्या Salesforce के पास पहले से कुछ है जो यह काम करता है।

अब फ़िज़िकल मॉडल खींचें

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

Click to enlarge

मैं चाहता हूँ कि आप उन तीनों डायग्राम को अगल-बगल रखकर क्रम देख सकें: तीन असंबंधित डायग्राम नहीं, बल्कि एक ही बिज़नेस, तीन स्तरों पर।

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

फ़िज़िकल मॉडल को प्लेटफ़ॉर्म का सम्मान करना होगा

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

कभी-कभी फ़िज़िकल मॉडल मॉड्यूल 5 में किए गए डीनॉर्मलाइज़ेशन के फ़ैसलों की वजह से भी जानबूझकर साफ़ लॉजिकल मॉडल से अलग होगा। कोई बात नहीं, जब तक हम बता सकें कि क्यों।

Setup से डिज़ाइन न करें

एक आदत है जो, अगर आपमें है, तो मैं चाहता हूँ कि आप तोड़ें: अपने डेटा आर्किटेक्चर की शुरुआत Setup → Object Manager → New Custom Object से करना और चलते-चलते मॉडल समझना। Salesforce चीज़ें बनाना बेहद आसान बना देता है; यह उसकी एक ताक़त है, और एक वजह भी कि कमज़ोर डेटा मॉडल इतनी तेज़ी से बन जाते हैं। कुछ क्लिक और आपके पास एक ऑब्जेक्ट है, कुछ और क्लिक और आपके पास फ़ील्ड और एक संबंध है। फिर डेटा आता है, फ़्लो बनते हैं, रिपोर्ट बनती हैं, इंटीग्रेशन उस पर निर्भर हो जाते हैं, और पाँच मिनट में बनाया गया ऑब्जेक्ट बदलना बहुत महँगा हो जाता है। यह अध्याय 1 वाली पलटने की कसौटी (Reversibility Test) है। इसलिए New Custom Object पर क्लिक करने से पहले, मॉडल खींचें।

फ़िज़िकल का मतलब स्थायी नहीं है

तीनों मॉडल को अलग रखने की एक और वजह है: टेक्नोलॉजी बदलती है। आज Steve Trucking का कुछ डेटा Salesforce core पर रहता है। कल उसका कुछ हिस्सा Data 360, किसी वेयरहाउस, या किसी ऐसे सिस्टम में रह सकता है जिसे हमने अभी चुना नहीं, और AI असिस्टेंट को अपना अलग रूप चाहिए। फ़िज़िकल आर्किटेक्चर बदल सकता है, जबकि बिज़नेस की अवधारणाएँ हैरानी की हद तक स्थिर रहती हैं: रिटेल पार्टनर, डिलीवरी और प्राप्तकर्ता तब भी मौजूद रहते हैं। यही लॉजिकल मॉडल को क़ीमती बनाता है। यह बिज़नेस का एक टिकाऊ वर्णन है जो आज के इम्प्लीमेंटेशन से बँधा नहीं है।

आर्किटेक्ट यहाँ क्या तय करता है

लॉजिकल मॉडल को फ़िज़िकल Salesforce मॉडल में बदलते हुए मैं यह तय कर रहा होता हूँ:

• बिज़नेस की कौन-सी एंटिटी Salesforce की स्टैंडर्ड क्षमताओं से मैप होती हैं, और किन्हें कस्टम ऑब्जेक्ट या कोई दूसरा रूप चाहिए।
• लॉजिकल एट्रिब्यूट फ़िज़िकल फ़ील्ड कैसे बनते हैं, और संबंध प्लेटफ़ॉर्म पर कैसे लागू होते हैं।
• फ़िज़िकल डिज़ाइन में सोचा-समझा डीनॉर्मलाइज़ेशन कहाँ होना चाहिए।
• कौन-सा डेटा Salesforce पर रहना चाहिए, और कौन-सा कहीं और।
• प्लेटफ़ॉर्म की कौन-सी ख़ूबियाँ फ़िज़िकल मॉडल को लॉजिकल मॉडल से अलग होने पर मजबूर करती हैं।

सबसे अहम, मैं हर फ़ैसले को पीछे की ओर ट्रेस कर पाना चाहता हूँ। अगर आप मेरे फ़िज़िकल मॉडल में किसी चीज़ की ओर इशारा करके पूछें, “यह वहाँ क्यों है?”, तो मुझे आपको लॉजिकल मॉडल और कॉन्सेप्चुअल मॉडल से होते हुए किसी ऐसी चीज़ तक वापस ले जा पाना चाहिए जिसकी बिज़नेस को सच में ज़रूरत है: बिज़नेस → कॉन्सेप्चुअल → लॉजिकल → फ़िज़िकल।

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

हमने यह अध्याय एक पहली कॉल पर संज्ञाएँ सुनते हुए शुरू किया था, और इसे एक ऐसे फ़िज़िकल मॉडल पर ख़त्म कर रहे हैं जिसे हम बिज़नेस तक वापस ट्रेस कर सकते हैं। अब जबकि हमने Salesforce पर बनाना चुना है, अगला सवाल और गहरा जाता है: हम असल में किस तरह के डेटा प्लेटफ़ॉर्म पर बना रहे हैं?

और जानें

• Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab), Salesforce Developers, Winter ‘27 (अंग्रेज़ी में, 2026-10-02 को जाँचा गया): “पैरेंट-चाइल्ड संबंधों को इस तरह कॉन्फ़िगर करें कि एक पैरेंट रिकॉर्ड पर 10,000 से ज़्यादा चाइल्ड न हों।” यह data skew के बारे में एक दिशानिर्देश है, कोई सख़्त सीमा नहीं; अध्याय 7 इसमें गहराई से जाता है।
• Roll-Up Summary Field (opens in a new tab), Salesforce Help (अंग्रेज़ी में, 2026-10-12 को जाँचा गया): एक roll-up summary, master-detail संबंध के ज़रिए detail रिकॉर्ड गिनता या जोड़ता है।