लॉजिकल मॉडल बनाएँ

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

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

यह मॉड्यूल किस सवाल का जवाब देता है: कॉन्सेप्चुअल मॉडल को मैं लॉजिकल डेटा मॉडल में कैसे बदलूँ?

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

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

पहले, कुत्तों पर वापस। हमारे पास बॉक्स और रेखाएँ हैं। अब दो नए सवाल: हर चीज़ के बारे में हम क्या जानते हैं, और एक को दूसरे से कैसे अलग पहचानते हैं?

इसका वर्णन क्या करता है? एक कुत्ते का नाम और जन्म-तिथि होती है। एक मालिक का नाम, फ़ोन नंबर और पता होता है। एक करतब का नाम और उसकी कठिनाई होती है। हर तथ्य उसी बॉक्स पर जाता है जिसका वह वर्णन करता है।

फिर जंक्शन। Bella बैठो कितना अच्छा करती है, और उसने यह कब सीखा: क्या यह Bella का वर्णन करता है? पूरी तरह नहीं; कुछ करतब वह दूसरों से बेहतर करती है। क्या यह बैठो का वर्णन करता है? नहीं; हर कुत्ता बैठो अलग तरह से करता है। यह Bella और बैठो, दोनों का एक साथ वर्णन करता है, इसलिए यह कुत्ते का करतब पर जाता है: कौशल-स्तर और सीखने की तारीख़। जंक्शन इसीलिए होता है: कुछ तथ्य सिर्फ़ जोड़ी के होते हैं।

कौन-सा कुत्ता कौन-सा है? पहले नाम आज़माएँ। Max नाम के बहुत सारे कुत्ते हैं, तो नाम यूनिक नहीं है। मालिक का फ़ोन नंबर? Marcus के दो कुत्ते एक ही फ़ोन पर हैं, लोग नंबर बदलते हैं, और यह किसी का निजी डेटा है, जो कुत्ते की ओर इशारा करने वाले हर सिस्टम में कॉपी हो जाएगा। माइक्रोचिप नंबर बेहतर लगता है: यह यूनिक है, और बदलता नहीं। लेकिन हो सकता है नए पिल्ले में अभी चिप न लगी हो, और की (key) ख़ाली नहीं हो सकती। तो माइक्रोचिप रहती है, ऐसी चीज़ के रूप में जिससे कुत्ते को यह भी कहा जाता है, और कुत्ते को उसका अपना Dog ID मिलता है: एक नंबर जो एक ही उबाऊ काम करता है, एक कुत्ते को दूसरे से अलग बताना।

Click to enlarge

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

कॉन्सेप्चुअल बताता है कि क्या मौजूद है; लॉजिकल बताता है कि डेटा के रूप में उसका अर्थ क्या है

ट्रक (Truck) को लीजिए। मुझे ट्रक के बारे में क्या जानना है? शायद उसका यूनिट नंबर, VIN, मेक, मॉडल, मॉडल वर्ष, लाइसेंस प्लेट, मौजूदा माइलेज और स्टेटस। ये ट्रक के एट्रिब्यूट (attributes) हैं।

अब डिलीवरी (Delivery) लीजिए। शायद रिटेल पार्टनर का ऑर्डर नंबर, डिलीवरी की तारीख़, वादा किया गया समय-दायरा, असल पहुँचने का समय, स्टेटस, और क्या इसमें इंस्टॉल या पुराना सामान उठाना (haul-away) शामिल है। फिर से, एट्रिब्यूट।

कॉन्सेप्चुअल मॉडल ने हमें बताया कि डिलीवरी मौजूद है। लॉजिकल मॉडल यह बताना शुरू करता है कि डिलीवरी का डेटा के रूप में अर्थ क्या है। ट्रक या डिलीवरी जैसा एक सादा बॉक्स फ़ील्ड के पूरे सेट का प्रतिनिधित्व कर सकता है।

Click to enlarge

फिर भी, हमारे ज़्यादातर डायग्राम में बॉक्स सादे ही रहते हैं, तीन वजहों से। फ़ील्ड की संख्या बढ़ती जाती है। फ़ील्ड जल्दी पुराने पड़ जाते हैं। और हर फ़ील्ड के ऐसे ब्योरे होते हैं जिन्हें ऑब्जेक्ट मॉडल में दिखाना मुश्किल है: उसका API नाम, लेबल, डेटा टाइप और लंबाई। ये ब्योरे ज़रूर दर्ज होंगे, बस पहले डेटा मॉडल में नहीं। जब कुछ मुख्य फ़ील्ड दिखाने से बात समझाने में सच में मदद मिलती है, तो मैं एक विस्तृत डेटा मॉडल (detailed data model) बनाता हूँ: एक केंद्रित हिस्सा, जिसमें सिर्फ़ वही फ़ील्ड हों जो उस बात के लिए मायने रखते हैं।

एट्रिब्यूट को एंटिटी का वर्णन करना चाहिए

किसी एट्रिब्यूट को देखते समय मैं एक सीधा-सा सवाल पूछता हूँ: यह किसका वर्णन करता है? ट्रक का मेक साफ़ तौर पर ट्रक का वर्णन करता है। लेकिन डिलीवरी पर क्रू सदस्यों के नाम? क्या वे डिलीवरी का वर्णन करते हैं? या वे एक क्रू का वर्णन करते हैं, जिसका एक क्रू असाइनमेंट था, जो उस रूट के लिए था, जिसमें यह स्टॉप शामिल था?

यहीं डेटा मॉडल ऐसी चीज़ें उजागर करने लगता है जो स्क्रीन पर बिल्कुल ठीक लगती हैं। एक कोऑर्डिनेटर कहता है, “मैं डिलीवरी पर क्रू के नाम देखना चाहता हूँ।” यह यूज़र-एक्सपीरियंस की एक जायज़ ज़रूरत है। ज़रूरी नहीं कि इसका मतलब क्रू के नाम डिलीवरी पर स्टोर करना हो। ये दो अलग बातें हैं, और नॉर्मलाइज़ेशन के साथ हम इस पर लौटेंगे। फ़िलहाल यह पूछने की आदत डालें कि यह तथ्य असल में किस चीज़ का वर्णन करता है। यह सवाल आपको बहुत परेशानी से बचाएगा।

फिर हमें यूनिक ID की बात करनी होगी

एट्रिब्यूट चीज़ों का वर्णन करते हैं। लेकिन हल करने के लिए एक और समस्या है: मुझे कैसे पता चले कि कौन-सी चीज़ कौन-सी है?

दो प्राप्तकर्ताओं का नाम John Smith है। क्या वे एक ही व्यक्ति हैं? शायद हाँ, शायद नहीं। नाम काफ़ी नहीं है। पता? लोग घर बदलते हैं। फ़ोन नंबर बदलते हैं। ईमेल पते बदलते हैं। रिटेल पार्टनर का नाम भी बदल सकता है।

यह हमें की (keys) तक लाता है: वह जिससे हम अपने मॉडल में किसी चीज़ को यूनिक तौर पर पहचान सकें। यह ऐसा क्षेत्र है जिस पर सालों में मेरी काफ़ी पक्की राय बन गई है। किसी ID से मैं चार चीज़ें चाहता हूँ:

यूनिक। न बदलने वाला। बेमतलब। कभी PII नहीं।

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

न बदलने वाला। यह वाला छूट जाता है। अगर हम किसी रिटेल पार्टनर को उसके नाम से पहचानते हैं और पार्टनर अपना नाम बदल लेता है, तो क्या हमें नया पार्टनर मिल गया? नहीं। बिज़नेस एंटिटी वही रही; उसका एक एट्रिब्यूट बदला। रिकॉर्ड का यूनिक ID उस चीज़ में बदलाव के बाद भी बना रहना चाहिए जिसे वह पहचानता है, और इससे नाम, ईमेल पते, फ़ोन नंबर, पते और यूज़रनेम बाहर हो जाते हैं, चाहे सिस्टम पहली बार बनाते समय वे कितने भी सुविधाजनक लगें।

बेमतलब। पहली बार सुनने पर यह अजीब लगता है। मैं क्यों चाहूँगा कि ID का कोई मतलब न हो? क्योंकि मतलब बदलते हैं। सोचिए कोई ऐसा डिलीवरी ID बनाता है जिसमें DC, रिटेल पार्टनर, डिलीवरी की तारीख़ और एक क्रम संख्या छिपी है: PHX-KEY-20261002-0042। चतुराई भरा लगता है। फिर प्राप्तकर्ता डिलीवरी शुक्रवार पर खिसका देता है। क्या हम ID बदलें? अगर नहीं बदलते, तो वह हमसे झूठ बोल रहा है। अगर बदलते हैं, तो हमने डिलीवरी का यूनिक ID सिर्फ़ इसलिए बदल दिया क्योंकि उसका एक एट्रिब्यूट बदला, और हर वह सिस्टम जिसने पुराना ID रखा था, उसका पता खो बैठा। ID दो काम करने की कोशिश कर रहा था: डिलीवरी को पहचानना और उसका वर्णन करना। मैं चाहूँगा कि वर्णन एट्रिब्यूट करें और ID एक ही उबाऊ काम करे: उसे पहचानना। उबाऊ ID ही अच्छे ID हैं।

कभी PII नहीं। यह इतना अहम है कि मैं इसे अलग रखता हूँ। व्यक्तिगत पहचान वाली जानकारी (PII) को ID की तरह सिर्फ़ इसलिए इस्तेमाल न करें कि वह यूनिक दिखती है। Steve Trucking में प्राप्तकर्ता को फ़ोन नंबर से पहचानने का मन होता है। लेकिन की हर उस जगह कॉपी होती है जहाँ सिस्टम को रिकॉर्ड जोड़ने होते हैं: इंटीग्रेशन, एक्सपोर्ट, लॉग, रिटेल पार्टनर को वापस जाने वाली स्टेटस फ़ाइलें, डेटा वेयरहाउस, टेस्ट डेटा। फ़ोन नंबर को की बना दें, और आपने प्राप्तकर्ता का निजी डेटा पूरे आर्किटेक्चर में फैला दिया।

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

तो मेरा नियम है: यूनिक, न बदलने वाला, बेमतलब, कभी PII नहीं।

नैचुरल की और सरोगेट की

डेटाबेस वालों के पास इनमें से कुछ चीज़ों के नाम हैं। नैचुरल की (natural key) बिज़नेस डेटा में पहले से मौजूद होती है: ट्रक का VIN इसका अच्छा उदाहरण है। हमारे एप्लिकेशन ने इसे नहीं बनाया, और इसका पहले से मतलब है। सरोगेट की (surrogate key) ख़ास तौर पर रिकॉर्ड को पहचानने के लिए बनाई जाती है; यह किसी चीज़ का वर्णन नहीं करती, बस पहचानती है।

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

एक चीज़ के कई काम के ID हो सकते हैं

अंदरूनी रिकॉर्ड ID ज़रूरी नहीं कि वही ID हो जो बाकी हर सिस्टम इस्तेमाल करता है। Steve Trucking अंदर किसी डिलीवरी को एक जनरेट किए गए ID से पहचान सकती है। हर रिटेल पार्टनर उसी डिलीवरी को अपने ऑर्डर नंबर से जानता है: Keystone अपने CSV मैनिफ़ेस्ट में, Redrock अपने API में, Brightwave अपने EDI संदेशों में। और RouteDesk, यानी पुराने डिस्पैच टूल, में आठ साल का इतिहास RouteDesk के अपने डिलीवरी ID इस्तेमाल करता है।

ये ID मायने रखते हैं। हमें इन्हें रखना और सही तरह मैप करना होगा, क्योंकि स्टेटस अपडेट हर पार्टनर के पास उसी के नंबर के साथ वापस जाना चाहिए। लेकिन इन सबको डिलीवरी का यूनिक ID बनने की ज़रूरत नहीं। “इसका ID क्या है?” के एक से ज़्यादा जवाब हो सकते हैं, और आर्किटेक्ट को पता होना चाहिए कि किस संदर्भ में कौन-सा ID आधिकारिक है। मास्टर डेटा और इंटीग्रेशन के साथ हम इस पर लौटेंगे।

संबंध यूनिक ID पर टिके होते हैं

अब उन रेखाओं पर वापस जाएँ जो हमने खींची थीं। एक मैनिफ़ेस्ट में डिलीवरी की सूची होती है। एक प्राप्तकर्ता डिलीवरी पाता है। एक क्रू के क्रू असाइनमेंट होते हैं। ये संबंध तभी काम करते हैं जब हम दोनों सिरों की चीज़ों को भरोसे से पहचान सकें।

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

Click to enlarge

इस मोड़ पर आप सोच रहे होंगे, “Salesforce हर रिकॉर्ड को एक ID देता है।” सही, और हम वहाँ पहुँचेंगे। अगर डेटा Salesforce में रहता है, तो हर रिकॉर्ड को Salesforce का बनाया हुआ एक ID मिलता है। यह उलझा हुआ और पढ़ने में मुश्किल होता है, इसलिए हम आमतौर पर एक ऐसा ID फ़ील्ड भी दिखाते हैं जिसे लोग इस्तेमाल कर सकें, जैसे डिलीवरी नंबर D-000184227, जो एक Auto Number फ़ील्ड है। लोग अक्सर सोचते हैं कि यही नंबर रिकॉर्ड का ID है, लेकिन ऐसा नहीं है: Salesforce ID नीचे अब भी मौजूद है। कोई बाहरी सिस्टम या डेटाबेस, Oracle या SQL Server, के भी अपने यूनिक ID होते हैं। लेकिन आर्किटेक्चर में आगे चलकर Salesforce, फ़ाइनेंस का ERP, Snowflake, Data 360, पार्टनर के सिस्टम और ऐसे सिस्टम भी हो सकते हैं जो अभी मौजूद ही नहीं हैं। लॉजिकल मॉडल बिज़नेस डेटा का वर्णन करता है, बिना हर फ़ैसले को किसी एक टेक्नोलॉजी पर टिकाए। Salesforce इसे फ़िज़िकल रूप में कैसे लागू करेगा, यह बाद का कदम है।

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

कॉन्सेप्चुअल मॉडल को लॉजिकल मॉडल में बदलते हुए मैं यह तय कर रहा होता हूँ:

• कौन-से एट्रिब्यूट सच में हर एंटिटी का वर्णन करते हैं।
• हर एंटिटी की यूनिक पहचान कैसे होती है, और क्या वह ID इतना स्थिर है कि उसका यूनिक ID बन सके।
• कौन-से बिज़नेस ID (पार्टनर के ऑर्डर नंबर, पुराने सिस्टम के ID) रखने और मैप करने हैं।
• क्या संवेदनशील जानकारी को की की तरह इस्तेमाल किया जा रहा है।
• क्या संबंध भरोसेमंद यूनिक ID के ज़रिए एंटिटी को जोड़ते हैं।

अब हमारे पास एंटिटी, संबंध, एट्रिब्यूट और यूनिक ID हैं: एक असली लॉजिकल डेटा मॉडल की शुरुआत। लेकिन एक समस्या अब भी है। बिल्कुल सही डेटा को ग़लत जगह रख देना बहुत आसान है। यहीं नॉर्मलाइज़ेशन काम आता है।

और जानें

• Custom Field Types (opens in a new tab), Salesforce Help (अंग्रेज़ी में, 2026-10-09 को जाँचा गया): Auto Number हर रिकॉर्ड को एक यूनिक नंबर देता है, जिसका डिस्प्ले फ़ॉर्मैट हो सकता है, जैसे प्रीफ़िक्स और आगे के शून्य; यह रिकॉर्ड का Salesforce ID नहीं है। यह भी देखें: Auto-Number Fields Are Not Always Sequential (opens in a new tab) (अंग्रेज़ी में, 2026-10-09 को जाँचा गया)।