डिक्शनरी, लिनिएज और वर्गीकरण

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

यह मॉड्यूल किस सवाल का जवाब देता है: आप कैसे दर्ज करें कि डेटा का मतलब क्या है, वह कहाँ से आया, और वह कितना संवेदनशील है?

आपको विरासत में एक org मिला है। Account में 900 फ़ील्ड हैं, उनमें Customer_Type__c, Customer_Class__c, Customer_Category__c, Customer_Status__c, ERP_Status__c और Account_Status__c। इनमें से कौन-सा बताता है कि कोई सच में ग्राहक है या नहीं? आप विवरण खोलते हैं। तीन खाली हैं। एक में लिखा है “Customer Type.” शुक्रिया। एक कहता है कि यह ERP से आया; एक और छह साल पहले किसी ने बनाया था जो कब का जा चुका है। अब सोचिए कि आप आर्किटेक्ट नहीं, बल्कि एक इंटीग्रेशन, एक रिपोर्टिंग टीम, या एक एजेंट हैं। संगठन के पास ढेर सारा डेटा है। इसका यह मतलब नहीं कि उसे पता है कि डेटा का मतलब क्या है।

यहीं मेटाडेटा आर्किटेक्चर बनता है, तीन सवालों के ज़रिए जो आपस में जुड़े हैं लेकिन एक जैसे नहीं:

• डिक्शनरी: इस डेटा का मतलब क्या है?
• लिनिएज: यह कहाँ से आया?
• वर्गीकरण: इसके साथ कैसा बर्ताव होना चाहिए?

दो तरह का मेटाडेटा

मेटाडेटा दो तरह का होता है, और आपको दोनों चाहिए। बिज़नेस मेटाडेटा वह है जो डेटा का बिज़नेस के लिए मतलब है: परिभाषा, मालिक, उसके इस्तेमाल के नियम, वह कितना संवेदनशील है। तकनीकी मेटाडेटा यह है कि वह कैसे बना है और कैसे चलता है: ऑब्जेक्ट और फ़ील्ड, टाइप और लंबाई, API नाम, स्कीमा, एक सिस्टम से दूसरे सिस्टम की मैपिंग, सोर्स से टारगेट तक का लिनिएज। किसी फ़ील्ड का API नाम और टाइप डेवलपर को बताते हैं कि उसे कैसे इस्तेमाल करें; उसकी परिभाषा और मालिक बाकी सबको बताते हैं कि इस्तेमाल करें या नहीं। जब ये आपस में मेल न खाएँ, या कोई एक गायब हो, तो वहीं इंटीग्रेशन और रिपोर्ट गड़बड़ाते हैं।

परीक्षा-ज्ञान। बिज़नेस मेटाडेटा (मतलब, परिभाषाएँ, मालिक, नियम, संवेदनशीलता: बिज़नेस डिक्शनरी और वर्गीकरण) को तकनीकी मेटाडेटा (ऑब्जेक्ट, फ़ील्ड, टाइप, API नाम, स्कीमा, मैपिंग और लिनिएज) से अलग पहचानें।

मतलब से शुरू करें

अध्याय 3 ने नियम तय किया था: हर फ़ील्ड को एक विवरण मिले। Customer Status नाम के फ़ील्ड के लिए “Customer Status” नहीं, बल्कि कुछ ऐसा: “Steve Trucking के साथ पार्टनर का मौजूदा व्यावसायिक रिश्ता। सक्रिय होने के बाद ERP से सेट होता है। संभावित ग्राहक की योग्यता जाँचने के लिए इस्तेमाल न करें।” अब मुझे पता है कि इसका मतलब क्या है, यह कहाँ से आता है और इसे किस काम के लिए इस्तेमाल नहीं करना है। यही एक बिज़नेस डिक्शनरी की शुरुआत है: उस डेटा की साझा परिभाषाएँ जो मायने रखता है। ग्राहक क्या है? सक्रिय ग्राहक? Delivered का मतलब क्या है? समय पर किसे माना जाता है? ये तब तक ज़ाहिर लगते हैं जब तक आप पाँच विभागों को एक कमरे में न बिठा दें: Finance की एक परिभाषा है, Sales की दूसरी, Operations की तीसरी, वेयरहाउस की चौथी, और किसी ने पाँचवीं पर एक डैशबोर्ड बना दिया है। समस्या यह नहीं कि कोई अंग्रेज़ी नहीं बोलता। समस्या यह है कि एंटरप्राइज़ ने मतलब पर सहमति नहीं बनाई है।

डिक्शनरी किसी स्प्रेडशीट या डॉक्यूमेंटेशन टूल में रह सकती है, लेकिन उसकी अहम परिभाषाएँ उस जगह के करीब होनी चाहिए जहाँ लोग डेटा इस्तेमाल करते हैं। प्लेटफ़ॉर्म पर, यह फ़ील्ड विवरण, हेल्प टेक्स्ट और वर्गीकरण मेटाडेटा है। एनालिटिक्स में यह और भी ज़्यादा मायने रखता है: “revenue” का मतलब एग्ज़िक्यूटिव डैशबोर्ड पर एक और किसी एनालिस्ट की क्वेरी में दूसरा नहीं हो सकता। सिमैंटिक लेयर इसी के लिए है, और Data 360 के सिमैंटिक मॉडल फ़िज़िकल डेटा के ऊपर मेट्रिक, डाइमेंशन और संबंध जैसी गवर्न की गई परिभाषाएँ रखते हैं (Create a Semantic Model in Data 360 (opens in a new tab))। टेक्नोलॉजी बदलती है; आवश्यकता नहीं: अहम डेटा को एक सहमति वाला मतलब चाहिए।

और मतलब से शुरू करें, टेक्नोलॉजी से नहीं। जो डिक्शनरी ऑब्जेक्ट, फ़ील्ड, टाइप और API नाम से शुरू होती है, वह इम्प्लीमेंटेशन को डॉक्यूमेंट करती है। जो बिज़नेस शब्दों से शुरू होती है, वह एंटरप्राइज़ को डॉक्यूमेंट करती है:

बिज़नेस शब्द	मतलब	कहाँ दर्शाया गया है
रिटेल पार्टनर (Retail Partner)	एक रिटेलर जिसके लिए Steve Trucking कॉन्ट्रैक्ट के तहत डिलीवरी करता है	Salesforce Account; फ़ाइनेंस ERP का ग्राहक
डिलीवरी (Delivery)	एक प्राप्तकर्ता को, एक पते पर, एक दिन में एक डिलीवरी	आज RouteDesk; डिलीवरी Salesforce में आने के बाद एक work order
प्राप्तकर्ता (Recipient)	डिलीवरी पाने वाला व्यक्ति	डिलीवरी पर प्राप्तकर्ता का विवरण
Delivered	तय ऑपरेशनल परिभाषा के अनुसार पूरी हुई	डिलीवरी स्टेटस
समय पर डिलीवरी	तय डिलीवरी विंडो के भीतर पूरी हुई	निकाली गई मेट्रिक

Click to enlarge

एक मतलब, कई तकनीकी रूप।

फिर पूछें कि यह कहाँ से आया

जब मुझे पता हो कि किसी वैल्यू का मतलब क्या है, तो मैं जानना चाहता हूँ कि वह कहाँ से आई। यही लिनिएज है। Salesforce में किसी पार्टनर का कानूनी नाम: क्या किसी रिप ने टाइप किया, क्या ERP ने भेजा, क्या किसी इंटीग्रेशन ने उसे बदला, क्या Data 360 ने उसे एकीकृत किया, क्या उसकी गणना हुई, क्या AI ने उसे बनाया? इनसे तय होता है कि मैं उस पर कितना भरोसा करूँ और उसके साथ क्या कर सकता हूँ। मॉड्यूल 2 के अस्थायी रिकॉर्ड याद करें: दो Account दोनों “Keystone” कह सकते हैं, एक कल किसी रिप ने बनाया, दूसरा आधिकारिक पहचानकर्ता के साथ ERP से आया। एक जैसा टेक्स्ट, अलग लिनिएज, अलग बर्ताव।

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

कुछ लिनिएज मुफ़्त में मिलता है: Account पर ERP ID, Created By और Last Modified By, इंटीग्रेशन लॉग, मैपिंग दस्तावेज़। Data 360 अपने डेटा ऑब्जेक्ट में लिनिएज फ़ील्ड जोड़ता है जो हर रिकॉर्ड के लिए डेटा सोर्स और सोर्स ऑब्जेक्ट दर्ज करते हैं (Data Lineage Fields (opens in a new tab))। लेकिन यह न मानें कि सिस्टम इंटीग्रेट होने से लिनिएज अपने आप आ जाता है। कभी-कभी सबसे काम का लिनिएज एक फ़ील्ड होता है: Source System = Keystone। और अगर सोर्स गवर्नेंस के लिए मायने रखता है, तो उसे मशीनी तौर पर भरोसेमंद बनाएँ, इंटीग्रेशन से सेट हो, किसी व्यक्ति के टाइप करने से नहीं।

निकाले गए डेटा को लिनिएज की सबसे ज़्यादा ज़रूरत होती है। मान लीजिए Steve Trucking ट्रक की लोकेशन, डिलीवरी विंडो और रूट के इतिहास से देर से डिलीवरी का जोखिम निकालता है, और डिस्पैच उसे प्राथमिकता तय करने में इस्तेमाल करता है। “high” कहाँ से आया? अब एक एजेंट जोड़ें जो किसी प्राप्तकर्ता से कहता है “आपकी डिलीवरी देर से चल रही है,” और आपको जानना होगा कि वह किस डेटा पर आधारित था (grounding), और वह कितना ताज़ा था। आप स्टोर की गई वैल्यू से जितना दूर गणना की गई, एकीकृत, अनुमानित और जनरेट की गई वैल्यू की ओर जाते हैं, लिनिएज उतना ही ज़्यादा मायने रखता है।

वर्गीकरण एक अलग सवाल का जवाब देता है

अब: इसके साथ कैसा बर्ताव होना चाहिए? प्राप्तकर्ता का नाम, डिलीवरी का पता, फ़ोन नंबर, डिलीवरी नोट्स, डिलीवरी स्टेटस, ट्रक नंबर, डिस्ट्रिब्यूशन सेंटर, रिटेल पार्टनर, फ़ोटो: ये सब बराबर संवेदनशील नहीं हैं। “Out for delivery” कोई फ़ोन नंबर नहीं है, और DC कोड किसी के घर के अंदर की फ़ोटो नहीं है। Salesforce आपको यह हर फ़ील्ड पर दर्ज करने देता है, स्टैंडर्ड हो या कस्टम: Data Owner, Field Usage, Data Sensitivity Level और Compliance Categorization (Data Classification Metadata Fields (opens in a new tab))। अध्याय 3 ने इन्हें टैक्सोनॉमी फ़ील्ड कहा था, और बताया था कि ये क्यों मायने रखते हैं: किसी फ़ील्ड को PII या GDPR के रूप में चिह्नित करें, और प्रक्रियाएँ उसे ढूँढ सकती हैं, मास्किंग टूल से लेकर Salesforce की AI trust layer तक, जो चिह्नित वैल्यू को किसी large language model तक पहुँचने से रोक सकती है। अध्याय 3 की एक चेतावनी: Salesforce अब एजेंटों के लिए वह LLM मास्किंग बंद रखता है, क्योंकि वह वह संदर्भ हटा सकती है जिसकी एजेंट को ज़रूरत है (जो मायने रखता है, उसे वर्गीकृत करें: टैक्सोनॉमी फ़ील्ड)। इसलिए वर्गीकरण को अब भी बाकी कंट्रोल चलाने होंगे।

यहाँ मेरा पक्ष सोचा-समझा है: संवेदनशील फ़ील्ड को वर्गीकृत करें, हर फ़ील्ड को नहीं। मैं नहीं चाहता कि हज़ारों फ़ील्ड वर्गीकृत करने में तीन महीने लगें ताकि कोई “100% वर्गीकृत” की रिपोर्ट दे सके और उसे कोई इस्तेमाल न करे। प्राप्तकर्ता का फ़ोन नंबर: हाँ। घर का पता: हाँ। डिलीवरी नोट्स जिनमें गेट कोड और “आँगन में कुत्ता है” हो सकता है: हाँ। फ़ोटो जिनमें लोग या घर दिख सकते हैं: बिल्कुल। कोई अंदरूनी डिस्प्ले लेबल? गवर्नेंस की ऊर्जा वहाँ नहीं जानी चाहिए। इसका मतलब यह नहीं कि बिना डॉक्यूमेंटेशन वाले फ़ील्ड ठीक हैं। दो अलग काम: डॉक्यूमेंटेशन व्यापक है; वर्गीकरण सोचा-समझा। यही वर्गीकरण को सार्थक बनाए रखता है।

ऐसी टैक्सोनॉमी जिसे लोग इस्तेमाल कर सकें

वर्गीकरण को एक शब्दावली चाहिए, एक टैक्सोनॉमी। Salesforce के डिफ़ॉल्ट हैं Public, Internal, Confidential, Restricted और MissionCritical; आपका संगठन अपने लेबल चाह सकता है। मैं उन्हें तय नहीं कर रहा। बस उन्हें समझने लायक रखें: अगर 47 श्रेणियाँ हैं और प्राइवेसी टीम के बाहर कोई श्रेणी 31 और 32 में फ़र्क नहीं बता सकता, तो यह मदद नहीं कर रही। एक अच्छी टैक्सोनॉमी लेबल को बर्ताव से जोड़ती है। अगर कोई फ़ील्ड संवेदनशील व्यक्तिगत डेटा है, तो उसे कौन देख सकता है, क्या वह सैंडबॉक्स में जा सकता है, क्षेत्र से बाहर जा सकता है, एनालिटिक्स में दिख सकता है, उसे कितने समय रखा जाता है, क्या कोई एजेंट उसे इस्तेमाल कर सकता है? अब वर्गीकरण काम कर रहा है।

लागू किए बिना वर्गीकरण सिर्फ़ सजावट है

प्राप्तकर्ता के फ़ोन नंबर को संवेदनशील चिह्नित करें और कुछ और न बदलें, तो आपने डॉक्यूमेंटेशन लिखा है। काम का है, लेकिन गवर्नेंस इससे आगे जाती है: वर्गीकरण को परमिशन, मास्किंग, एन्क्रिप्शन, रिटेंशन, सहमति, डेटा की आवाजाही, सैंडबॉक्स के इस्तेमाल, ऑडिट और AI एक्सेस को चलाना चाहिए। इसमें से कुछ आर्किटेक्ट का डिज़ाइन फ़ैसला है; कुछ प्लेटफ़ॉर्म अब टैग और वर्गीकरण सीधे पॉलिसी में लागू करते हैं, जैसे Data 360 की गवर्नेंस करती है (Data Governance in Data 360 (opens in a new tab))। और किसी फ़ील्ड को Restricted चिह्नित करने से कोई उसे पढ़ने से नहीं रुकता। वर्गीकरण बताता है कि फ़ील्ड के साथ कैसा बर्ताव होना चाहिए; सिक्योरिटी उसे सच बनाती है। क्रम यह है: डेटा पहचानें, उसे समझें, जो मायने रखता है उसे वर्गीकृत करें, फिर वे कंट्रोल लगाएँ जो वह वर्गीकरण माँगता है।

Click to enlarge

आपके डेटा के बारे में तीन सवाल, और तीसरे को कुछ न कुछ चलाना ही होगा।

रेफ़रेंस डेटा को भी मेटाडेटा चाहिए

देश के कोड, डिलीवरी स्टेटस, DC कोड, पार्टनर पहचानकर्ता, रद्द करने की वजहें: ये तब तक सरल लगते हैं जब तक दो सिस्टम असहमत न हों। एक कहता है CANCELLED, दूसरा CANCELED, तीसरा CNCL, चौथा 9। रेफ़रेंस डेटा को परिभाषाएँ, एक मालिक, एक सोर्स, वैल्यू बदलने पर एक जीवनचक्र, और सिस्टमों के उसे अलग-अलग दर्शाने पर मैपिंग चाहिए। छोटी वैल्यू बहुत बड़ी प्रक्रियाएँ चला सकती हैं। अध्याय 6 इसमें और आगे जाता है।

तीनों एक साथ

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

अब डिलीवरी स्टेटस लें। डिक्शनरी: डिलीवरी की मौजूदा ऑपरेशनल स्थिति। लिनिएज: Steve Trucking की डिलीवरी प्रक्रिया से सेट होता है और हर पार्टनर को उसके अपने इंटीग्रेशन से वापस भेजा जाता है। वर्गीकरण: ऑपरेशनल, संवेदनशील नहीं। अलग डेटा, अलग बर्ताव। यही असली बात है।

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

परीक्षा से आगे: AI क्या बदलता है। वर्गीकरण वह स्विच बनता जा रहा है जो तय करता है कि एजेंट क्या निकाल या दोहरा सकता है, और लिनिएज को एजेंट के जवाब या कार्रवाई तक पूरा पहुँचना होता है। अगर कोई एजेंट किसी प्राप्तकर्ता से कहता है कि डिलीवरी देर से है, तो आर्किटेक्चर को बता पाना चाहिए कि वह किस डेटा पर आधारित था, वह कहाँ से आया, और क्या एजेंट को उसे इस्तेमाल करने की अनुमति थी। “Salesforce में कहीं” लिनिएज नहीं है, और “ग्राहक डेटा” कोई वर्गीकरण नहीं है।

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

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

डेटा को गवर्न करने से पहले जानें कि आपके पास क्या है: उसका मतलब क्या है, वह कहाँ से आया, उसके साथ कैसा बर्ताव होना चाहिए। व्यापक रूप से डॉक्यूमेंट करें, सोच-समझकर वर्गीकृत करें, जहाँ मायने रखता हो वहाँ लिनिएज रखें। वरना आप डेटा को गवर्न नहीं करते। बस वह आपके पास होता है।

और जानें

• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।
• Salesforce Help, Data 360: Data Lineage Fields (opens in a new tab), Data Governance in Data 360 (opens in a new tab) और Create a Semantic Model in Data 360 (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।