अर्थ के लिए डेटा मॉडलिंग

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

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

यह अध्याय परीक्षा के Data Modeling and Database Design खंड की नींव है, जो परीक्षा का एक-चौथाई हिस्सा है। यह सोच को कवर करता है; अगला अध्याय, Salesforce डेटा आर्किटेक्चर, कवर करता है कि प्लेटफ़ॉर्म उसे कैसे बनाता है। इसलिए ऑब्जेक्ट, फ़ील्ड और संबंधों पर जो कुछ परखा जाता है, उसके ज़्यादातर हिस्से के लिए दोनों अध्याय चाहिए।

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

इस अध्याय की वे बातें जो परीक्षा में सबसे ज़्यादा मायने रख सकती हैं। हर एक अपने परीक्षा उद्देश्य से जुड़ी है और वहाँ का लिंक देती है जहाँ उसे सिखाया गया है। आगे बढ़ते हुए इन पर निशान लगाते जाएँ।

DM-1: Salesforce डेटा मॉडल डिज़ाइन करने की तकनीकों की तुलना

• मैं कॉन्सेप्चुअल, लॉजिकल और फ़िज़िकल डेटा मॉडल का फ़र्क समझा सकता हूँ, और यह भी कि हर एक किसलिए है। (मॉडल को Salesforce में बदलें)
• मैं किसी ज़रूरत में संभावित एंटिटी (candidate entities) ढूँढ सकता हूँ, और कोई काम करने वाले व्यक्ति को डेटा के एक टुकड़े से अलग पहचान सकता हूँ। (संज्ञाएँ आपको संभावित एंटिटी देती हैं)
• मैं क्रोज़ फ़ुट नोटेशन (crow’s-foot notation) पढ़ और बना सकता हूँ: एक, कई, और वैकल्पिक या अनिवार्य के लिए दूसरा निशान। (रेखाओं को पढ़ें, वैकल्पिकता भी मायने रखती है)
• मैं किसी संबंध की कार्डिनैलिटी बता सकता हूँ: one-to-one, one-to-many, many-to-many। (पूछें “एक या कई?”)
• मुझे पता है कि many-to-many संबंध अपने आप में एक एंटिटी बन जाता है, और Salesforce में आमतौर पर दो पैरेंट वाला जंक्शन ऑब्जेक्ट (junction object)। (संबंध भी चीज़ें बन सकते हैं)
• मुझे पता है कि कब किसी संबंध को ऊपर लिखे जाने वाले फ़ील्ड के बजाय इतिहास (शुरुआत और अंत की तारीख़ों वाला रिकॉर्ड) चाहिए। (समय संबंधों को बदल देता है)
• मैं एक अच्छा यूनिक ID चुन सकता हूँ, और मुझे पता है कि नैचुरल की या निजी जानकारी वाली कोई भी चीज़ जोखिम भरी क्यों है। (फिर हमें यूनिक ID की बात करनी होगी)
• मुझे नैचुरल की और सरोगेट की का फ़र्क पता है, और यह भी कि एक रिकॉर्ड में कई बाहरी ID (external identifiers) हो सकते हैं। (नैचुरल की और सरोगेट की)
• मुझे पता है कि Auto Number फ़ील्ड एक पढ़ने लायक नंबर है, रिकॉर्ड का Salesforce ID नहीं। (संबंध यूनिक ID पर टिके होते हैं)
• मैं पहला, दूसरा और तीसरा नॉर्मल फ़ॉर्म लागू कर सकता हूँ, और ऐसा फ़ील्ड पहचान सकता हूँ जिसमें कई वैल्यू हों या जो किसी और चीज़ का तथ्य दोहराता हो। (1NF, 2NF और 3NF को समझने का एक आसान तरीका)
• मैं समझा सकता हूँ कि कब जानबूझकर डीनॉर्मलाइज़ करना है (यूज़र, रिपोर्टिंग, स्केल), और उसकी क़ीमत क्या है। (तीसरे नॉर्मल फ़ॉर्म तक डिज़ाइन करें, फिर पीछे हटें)
• मैं वैल्यू की किसी सूची के लिए पिकलिस्ट और किसी ऑब्जेक्ट की ओर lookup के बीच फ़ैसला कर सकता हूँ। (Lookup या पिकलिस्ट?)
• मुझे पता है कि एक custom report type ज़्यादा से ज़्यादा चार ऑब्जेक्ट संबंधों की इजाज़त देता है, और गहरे मॉडल के लिए यह क्यों मायने रखता है। (Lookup या पिकलिस्ट?)
• मुझे पता है कि master-detail कब ठीक बैठता है (चाइल्ड का पैरेंट कभी नहीं बदलता) और कब lookup ज़्यादा सुरक्षित है, जिसमें Salesforce की यह सलाह भी शामिल है कि एक पैरेंट पर 10,000 चाइल्ड से ज़्यादा न हों। (संबंध प्लेटफ़ॉर्म के फ़ैसले बनते हैं)
• मुझे पता है कि जहाँ हो सके पॉलीमॉर्फ़िक संबंधों से क्यों बचना चाहिए। (संबंध प्लेटफ़ॉर्म के फ़ैसले बनते हैं)
• मुझे पता है कि बिज़नेस एंटिटी का मतलब अपने-आप कस्टम ऑब्जेक्ट नहीं है: वह स्टैंडर्ड ऑब्जेक्ट, एक फ़ील्ड, कॉन्फ़िगरेशन, या Salesforce से बाहर रहने वाला डेटा भी हो सकती है। (बिज़नेस एंटिटी का मतलब अपने-आप कस्टम ऑब्जेक्ट नहीं है)

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

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

• एक मिनट के लिए Salesforce को भूल जाएँ। Account और Contact से मैप करने से पहले बिज़नेस का मॉडल बनाएँ।
• उस शब्द को सुनें जो दो चीज़ें छिपाए हुए है। Steve Trucking में “ग्राहक” का मतलब रिटेल पार्टनर भी था और प्राप्तकर्ता भी।
• मॉडल बातचीत का हिस्सा है। आपका पहला मॉडल सही होने के लिए नहीं है; वह आपको यह दिखाने के लिए है कि आप कहाँ ग़लत हैं।
• रेखाओं को नाम दें। एक जैसे बॉक्स वाले दो मॉडल के अलग मतलब हो सकते हैं।
• हर संबंध से पूछें “अभी, या समय के साथ?”
• यूनिक, न बदलने वाला, बेमतलब, कभी PII नहीं।
• हर तथ्य को वहीं रखें जहाँ का वह है, फिर जानबूझकर पीछे हटें, और लिखें कि क्यों।
• डीनॉर्मलाइज़ेशन जटिलता को हटाता नहीं; खिसकाता है। जानें कि सच का मालिक कौन है।
• सच का एक स्रोत, कई आकार: स्क्रीन, रिपोर्ट, वेयरहाउस और AI।
• Setup से डिज़ाइन न करें। New Custom Object पर क्लिक करने से पहले मॉडल खींचें।
• हर फ़िज़िकल फ़ैसले को पीछे ट्रेस करें, किसी ऐसी चीज़ तक जिसकी बिज़नेस को ज़रूरत है।

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

शब्द	एक पंक्ति में
एंटिटी (Entity)	ऐसी चीज़ जिसकी बिज़नेस को परवाह है और जिसका वह डेटा रखता है
संभावित एंटिटी (Candidate entity)	ऐसी संज्ञा जो उसके बारे में पूछने के बाद एंटिटी बन सकती है
एट्रिब्यूट (Attribute)	एक तथ्य जो किसी एंटिटी का वर्णन करता है
संबंध (Relationship)	दो एंटिटी कैसे जुड़ी हैं, बिज़नेस की भाषा में नाम दिया हुआ
कार्डिनैलिटी (Cardinality)	एक तरफ़ के कितने, दूसरी तरफ़ के कितनों से जुड़ते हैं
वैकल्पिकता (Optionality)	संबंध अनिवार्य है, या शून्य भी हो सकता है
क्रोज़ फ़ुट (Crow’s foot)	रेखा के सिरे पर “कई” का निशान
जंक्शन ऑब्जेक्ट (Junction object)	Salesforce में many-to-many संबंध बनाने का तरीका: दोनों पैरेंट का एक चाइल्ड
कॉन्सेप्चुअल मॉडल (Conceptual model)	बिज़नेस में क्या मौजूद है और वह कैसे जुड़ा है; Salesforce के बिना
लॉजिकल मॉडल (Logical model)	डेटा: एट्रिब्यूट, यूनिक ID और संबंध, अब भी किसी प्लेटफ़ॉर्म से बँधा नहीं
फ़िज़िकल मॉडल (Physical model)	प्लेटफ़ॉर्म इसे कैसे बनाएगा: ऑब्जेक्ट, फ़ील्ड और संबंधों के टाइप
नैचुरल की (Natural key)	ऐसा ID जो बिज़नेस में पहले से मौजूद है, जैसे ट्रक का VIN
सरोगेट की (Surrogate key)	ऐसा ID जो सिर्फ़ रिकॉर्ड को पहचानने के लिए बनाया गया है
बाहरी ID (External identifier)	उसी रिकॉर्ड के लिए किसी दूसरे सिस्टम का ID, जिसे रखा और मैप किया जाता है
नॉर्मलाइज़ेशन (1NF, 2NF, 3NF)	हर तथ्य को उसकी सही जगह रखना: हर फ़ील्ड में एक वैल्यू, पूरी की के बारे में तथ्य, दूसरे तथ्यों के बारे में कोई तथ्य नहीं
डीनॉर्मलाइज़ेशन (Denormalization)	किसी ऐसी वजह से जिसे आप बता सकें, डेटा को जानबूझकर कॉपी करना या सपाट करना
अपडेट विसंगति (Update anomaly)	एक ही तथ्य कई जगह स्टोर, इसलिए एक बदलाव के बाद कुछ कॉपियाँ ग़लत रह जाती हैं

खुद को परखें

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

1. एक बिज़नेस आपको बताता है कि एक क्रू एक ट्रक चलाता है। छह हफ़्ते बाद कोई पूछता है कि किसी ख़ास दिन ट्रक 117 किस क्रू के पास था। मॉडल में क्या होना चाहिए था?

एक क्रू असाइनमेंट (Crew Assignment): क्रू और ट्रक के बीच का संबंध, अपने आप में एक रिकॉर्ड के रूप में, शुरुआत की तारीख़, अंत की तारीख़ और रूट के साथ। समय के साथ क्रू और ट्रक many-to-many हैं, और बिज़नेस को इतिहास की परवाह है। ट्रक पर एक फ़ील्ड होता तो वह ऊपर से लिख दिया जाता। फिर से पढ़ें: समय संबंधों को बदल देता है।

2. एक टीम हर प्राप्तकर्ता के फ़ोन नंबर को यूनिक ID बनाने का प्रस्ताव रखती है, “क्योंकि वह यूनिक है।” आप क्या कहेंगे?

यह कसौटियों पर खरा नहीं उतरता: फ़ोन नंबर बदलते हैं और साझा होते हैं, इसलिए यह न तो न बदलने वाला है और न भरोसे से यूनिक, और यह निजी जानकारी है जो रिकॉर्ड से जुड़ने वाले हर सिस्टम में कॉपी हो जाएगी। एक बेमतलब, जनरेट किया गया ID इस्तेमाल करें और फ़ोन नंबर को एट्रिब्यूट के रूप में रखें। फिर से पढ़ें: फिर हमें यूनिक ID की बात करनी होगी।

3. एक डिलीवरी में Item 1, Item 2 और Item 3 फ़ील्ड हैं। चार आइटम वाली एक डिलीवरी आती है। असली समस्या क्या है, और उसका हल?

मॉडल ने एक दोहराई जाने वाली संरचना फ़ील्ड के अंदर छिपा दी (पहले नॉर्मल फ़ॉर्म की समस्या)। हल Item 4 फ़ील्ड नहीं है; हल है एक डिलीवरी आइटम (Delivery Item) एंटिटी, Delivery का चाइल्ड, ताकि हर आइटम एक रिकॉर्ड हो। फिर से पढ़ें: पहला नॉर्मल फ़ॉर्म।

4. हर डिलीवरी में डिस्ट्रिब्यूशन सेंटर के मैनेजर का नाम स्टोर है। मैनेजर बदल जाता है। क्या ग़लत हुआ?

किसी और चीज़ (डिस्ट्रिब्यूशन सेंटर) का तथ्य डिलीवरी पर स्टोर किया गया: तीसरे नॉर्मल फ़ॉर्म की समस्या, और अब सैकड़ों रिकॉर्ड में फैली अपडेट विसंगति। मैनेजर डिस्ट्रिब्यूशन सेंटर के साथ रहना चाहिए; डिलीवरी डिस्ट्रिब्यूशन सेंटर की ओर इशारा करती है। फिर से पढ़ें: तीसरा नॉर्मल फ़ॉर्म।

5. स्टॉप की किस्म (सिर्फ़ डिलीवरी, इंस्टॉल के साथ, पुराना सामान उठाने के साथ) को अवधि, क्रू के हुनर और एक चेकलिस्ट चाहिए। पिकलिस्ट या ऑब्जेक्ट?

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

6. पार्टनर क्षेत्र के हिसाब से समय पर डिलीवरी का स्कोरकार्ड चाहते हैं, और क्षेत्र डिस्ट्रिब्यूशन सेंटर पर रहता है। आप क्षेत्र को हर डिलीवरी पर कॉपी कर देते हैं। आपको क्या तय करना होगा?

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

7. बैठो जैसा करतब लाखों पालतुओं से जुड़ सकता है। पालतू का करतब से करतब तक master-detail या lookup?

Lookup। Salesforce की सलाह है कि एक पैरेंट पर 10,000 से ज़्यादा चाइल्ड न हों, और कोई लोकप्रिय करतब इसे पार कर जाएगा। Master-detail पालतू का करतब से पालतू तक ठीक बैठता है, क्योंकि पालतू के करतब का पैरेंट कभी नहीं बदलता और एक पालतू कुछ ही करतब जानता है; यही पालतू को अपनी आने वाले करतब की गिनती roll up करने देता है। फिर से पढ़ें: बैठो, रुको, मॉडल करो।

और जानें

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