तीसरे नॉर्मल फ़ॉर्म तक डिज़ाइन करें, फिर पीछे हटें

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

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

यह मॉड्यूल किस सवाल का जवाब देता है: मुझे साफ़, नॉर्मलाइज़्ड मॉडल से जानबूझकर कब हटना चाहिए?

पिछले मॉड्यूल में मैंने आपसे तीसरे नॉर्मल फ़ॉर्म के लिए डिज़ाइन करने को कहा था।

अब मैं आपसे उसे तोड़ने को कहने वाला हूँ।

कभी-कभी।

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

लेकिन एक बार जब मैं साफ़ लॉजिकल मॉडल समझ लेता हूँ, तो मैं सोच-समझकर फ़ैसला कर सकता हूँ कि डेटा इस्तेमाल करने वाले लोगों और सिस्टम के लिए उसे अलग आकार दूँ।

जहाँ मुमकिन हो तीसरे नॉर्मल फ़ॉर्म तक डिज़ाइन करें। फिर ज़रूरत पड़ने पर पीछे हटें।

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

सच का मॉडल बनाकर शुरुआत करें। फिर तय करें कि वह सच किस रूप में पहुँचाया जाए।

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

कुत्तों पर वापस, और इस बार हम कुछ सोचे-समझे फ़ैसले करते हैं।

नस्ल: पिकलिस्ट, या उसकी अपनी टेबल? इसे उन सवालों से गुज़ारें जो मैं इस मॉड्यूल में आगे दूँगा। क्या जानकारी का एक से ज़्यादा कॉलम है? हाँ: कम से कम आकार। कितनी वैल्यू? केनेल क्लब कुछ सौ नस्लों को मान्यता देते हैं (अकेले American Kennel Club की सूची में 205 हैं), जो मेरे लगभग 20 वाले अंदाज़े के नियम से बहुत आगे है। तो नस्ल अपनी टेबल की हक़दार बनती है, और हर कुत्ता अपनी नस्ल की ओर इशारा करता है। इससे वह सवाल तय हो जाता है जो हम मॉड्यूल 1 से साथ लेकर चल रहे हैं: नस्ल अपना अलग बॉक्स है।

कौशल-स्तर: एक पिकलिस्ट। सीख रहा है, अच्छा, माहिर। तीन लेबल, उनके बारे में कहने को और कुछ नहीं, और वे बदलेंगे नहीं। पिकलिस्ट ठीक इसी के लिए है।

हर कुत्ता कितने करतब जानता है? जवाब मॉडल में पहले से है: कुत्ते के, कुत्ते का करतब वाले रिकॉर्ड गिन लें। लेकिन ट्रेनर वह संख्या हर रिपोर्ट पर चाहता है, उससे सॉर्ट और फ़िल्टर करने के लिए, बिना दो टेबल पर रिपोर्ट बनाए। तो मैं पीछे हटता हूँ, और कुत्ते पर ही आने वाले करतब (Tricks Known) की गिनती रखता हूँ। वह एक कॉपी है। सच अब भी कुत्ते का करतब में रहता है; गिनती उसका एक रूप है, और उसे साथ-साथ चलना होगा। Salesforce हमें ठीक यही करने का एक साफ़ तरीका देता है, और हम इसे मॉड्यूल 6 में देखेंगे।

अब मोड़: डॉग स्कूल बिल्लियाँ भी लेने लगता है। हम क्या करें? एक विकल्प: Dog टेबल के बगल में एक Cat टेबल, और कुत्ते का करतब के बगल में एक Cat Trick जोड़ दें। सब कुछ दोगुना: हर स्क्रीन दो, हर रिपोर्ट दो, और जिस दिन वे ख़रगोश लेंगे, तीन। दूसरा विकल्प: थोड़ा पीछे हटें और देखें कि बिल्ली का भी एक मालिक है, शायद एक ब्रीडर, एक नस्ल, एक जन्म-तिथि और, सब्र हो तो, एक-दो करतब। कुत्ते जैसे ही तथ्य और वैसे ही संबंध। तो हम सामान्यीकरण करते हैं: एक पालतू (Pet), एक प्रजाति (Species) के साथ, कुत्ता या बिल्ली। हर नस्ल भी किसी प्रजाति की होती है, और प्रजाति असल में वहीं रहती है: लैब्राडोर एक कुत्ता है। पालतू जानबूझकर एक कॉपी रखता है, ताकि हर स्क्रीन और रिपोर्ट नस्ल देखे बिना “कुत्ता या बिल्ली?” से शुरू हो सके। एक और सोची-समझी कॉपी, और मॉड्यूल 6 में उसे अपना एक काम मिलता है।

यह बदलाव के लिए डिज़ाइन करना है, और यह एक ट्रेड-ऑफ़ है। बहुत जल्दी सामान्यीकरण करें और सब कुछ एक धुँधली “Thing” बन जाता है, एक type फ़ील्ड के साथ जिसे कोई नहीं समझता। मैं सामान्यीकरण तब करता हूँ जब बिज़नेस सच में मेरे पास दूसरी किस्म लेकर आता है, और दोनों लगभग सब कुछ साझा करती हैं, जैसे यहाँ कुत्ते और बिल्लियाँ। अगर बिल्लियों को बहुत अलग तथ्य चाहिए होते, तो मैं दो बार सोचता।

Click to enlarge

अब वैसे ही फ़ैसले Steve Trucking में, जहाँ दाँव ऊँचे हैं।

सबसे साफ़ मॉडल हमेशा सबसे अच्छा सिस्टम नहीं होता

एक स्टॉप पर खड़े क्रू की कल्पना करें। डिलीवरी के अपने आइटम हैं। इंस्टॉल की एक चेकलिस्ट है। हर कदम की फ़ोटो चाहिए। प्राप्तकर्ता दस्तख़त करता है।

नॉर्मलाइज़्ड मॉडल ख़ूबसूरत है: Delivery → Delivery Item → Install Checklist → Photo, हर एक अपनी सही जगह।

फिर मैं उन लोगों के साथ बैठता हूँ जो इसे असल में इस्तेमाल करते हैं। एक क्रू दिन में लगभग दस स्टॉप पूरे करता है, घरों के ड्राइववे में, अक्सर बिना सिग्नल के। अगर मेरा ख़ूबसूरत मॉडल उन्हें एक स्टॉप पूरा करने के लिए स्क्रीनों और related lists की भूलभुलैया से गुज़ारता है, तो मेरे पास एक आर्किटेक्चर की समस्या है।

हम सिर्फ़ डेटा मॉडल डिज़ाइन नहीं कर रहे।

हम एक सिस्टम डिज़ाइन कर रहे हैं।

कभी-कभी यूज़र एक्सपीरियंस जीतता है

पूरी तरह नॉर्मलाइज़्ड मॉडल से कभी-कभी पीछे हटने की एक वजह यह है: यूज़र एक्सपीरियंस।

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

यहीं मैं सिर्फ़ यह पूछना बंद करता हूँ कि “सिद्धांत में यह तथ्य कहाँ का है?” और यह पूछना शुरू करता हूँ कि “यह सिस्टम असल में इस्तेमाल कैसे होगा?”

इसका मतलब यह नहीं कि एक अतिरिक्त क्लिक की हर शिकायत मॉडल को सपाट कर दे। इसका मतलब है कि इस्तेमाल में आसानी आर्किटेक्चर का एक जायज़ इनपुट है।

कभी-कभी रिपोर्टिंग जीतती है

रिपोर्टिंग एक और आम वजह है।

हर रिटेल पार्टनर एक स्कोरकार्ड चाहता है: क्षेत्र के हिसाब से, महीने के हिसाब से समय पर हुई डिलीवरी। साफ़ मॉडल में डिलीवरी अपने डिस्ट्रिब्यूशन सेंटर को जानती है, और DC अपने क्षेत्र को। तकनीकी रूप से हम वहाँ तक पहुँच सकते हैं।

लेकिन क्या रिपोर्टिंग टूल पहुँच सकता है? क्या वे लोग पहुँच सकते हैं जो अपनी रिपोर्ट ख़ुद बनाते हैं? क्या वे सवाल का जवाब ऐसे रिपोर्टिंग आर्किटेक्चर के बिना दे सकते हैं जो ख़ुद सवाल से ज़्यादा पेचीदा हो?

तभी मैं क्षेत्र को डिलीवरी पर कॉपी या व्युत्पन्न (derive) कर सकता हूँ, वहाँ के क़रीब जहाँ उसका इस्तेमाल होता है।

अब मैंने दोहराव ला दिया है। तो मुझे एक और सवाल चाहिए: सच का मालिक कौन है?

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

डीनॉर्मलाइज़ेशन जटिलता को ख़त्म नहीं करता।

वह उसे खिसका देता है।

Lookup या पिकलिस्ट?

यह एक छोटा उदाहरण है जिससे Salesforce एडमिन का सामना हर समय होता है। यूज़र को वैल्यू के एक सेट में से चुनना है। क्या मैं एक और एंटिटी बनाकर उससे संबंध जोड़ूँ, या पिकलिस्ट इस्तेमाल करूँ?

डिलीवरी का स्टेटस लीजिए: शेड्यूल्ड, लोडेड, डिलीवरी के लिए निकली, पहुँच रही है, डिलीवर हुई, इंस्टॉल हुई, अपवाद, लौटाई गई। लेबल की एक छोटी, स्थिर सूची। मुझे ठीक पिकलिस्ट ही चाहिए।

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

अगर मैं हर उस अवधारणा के लिए ऑब्जेक्ट बनाऊँ जो सिद्धांत में नॉर्मलाइज़ हो सकती है, तो मैं तकनीकी रूप से ख़ूबसूरत ऐसा सिस्टम बना सकता हूँ जिसे इस्तेमाल करने में किसी को मज़ा न आए। अगर मैं हर अवधारणा को पिकलिस्ट बना दूँ क्योंकि यह आसान है, तो मैं बहुत जल्दी ख़ुद को कोने में घेर सकता हूँ।

तो मैं पूछता हूँ: क्या इसकी अपनी जानकारी है? संबंध? क्या यह स्वतंत्र रूप से बदलती है? क्या इसे डेटा की तरह संभालना ज़रूरी है? क्या आगे चलकर बिज़नेस को इससे एक लेबल से ज़्यादा चाहिए हो सकता है?

ये वे सवाल हैं जो मैं डिज़ाइन सेशन में सच में पूछता हूँ।

क्या जानकारी का एक से ज़्यादा कॉलम है? अगर वैल्यू को विवरण, अवधि, हुनर की सूची, एक मालिक चाहिए, तो वह अब लेबल नहीं रही।

कितनी वैल्यू? मेरा अंदाज़े का नियम लगभग 20 है। 20 वैल्यू के बाद पिकलिस्ट टूटने लगती है, और ऑब्जेक्ट के बारे में सोचने का समय आ जाता है। अमेरिकी राज्य, पचास, एक अपवाद हैं जिनके साथ हम जीते हैं, और देश और भी बुरे हैं; सच कहूँ, क्या किसी को देशों की पिकलिस्ट पसंद है? मुझे तो वे खिजाऊ लगती हैं।

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

क्या लोगों को इस पर फ़िल्टर और रिपोर्ट करना है? उसके लिए पिकलिस्ट बढ़िया हैं। Lookup उतने साफ़ नहीं। हर lookup एक छलाँग जोड़ता है: एक report type जुड़े हुए ऑब्जेक्ट की सिर्फ़ एक छोटी कड़ी ही फ़ॉलो करता है (एक custom report type ज़्यादा से ज़्यादा चार ऑब्जेक्ट संबंध की इजाज़त देता है), स्क्रीन related lists के अंदर related lists बन जाती है, और कोड ज़्यादा पेचीदा हो जाता है।

वैल्यू की एक सूची अक्सर पिकलिस्ट के रूप में जन्म लेती है और, समय के साथ, अपना अलग ऑब्जेक्ट कमा लेती है। उसे कमाने दें।

Click to enlarge

कभी-कभी स्केल जवाब बदल देता है

जो डिज़ाइन कुछ हज़ार रिकॉर्ड के साथ बढ़िया चलता है, वह लाखों के साथ बहुत अलग बर्ताव कर सकता है।

इसलिए सिर्फ़ डायग्राम न देखें। संख्याएँ जानें।

Steve Trucking साल में लगभग एक मिलियन डिलीवरी करती है, और हर साल 30% बढ़ रही है। हर डिलीवरी पर लगभग आठ स्टेटस अपडेट जमा होते हैं। यानी इस साल आठ मिलियन स्टेटस रिकॉर्ड, और तीसरे साल तक लगभग 13.5 मिलियन सालाना। साथ में हर साल चार-पाँच मिलियन फ़ोटो।

वही मॉडल। बहुत अलग आर्किटेक्चर।

हम Architecting at Scale में इसमें कहीं गहराई से उतरेंगे। फ़िलहाल याद रखें: वॉल्यूम डेटा मॉडलिंग का फ़ैसला बदल सकता है। जो संबंध तार्किक रूप से सही है, वह अपने-आप हर स्केल पर सबसे अच्छा फ़िज़िकल डिज़ाइन नहीं होता।

अलग-अलग इस्तेमाल करने वालों को अलग-अलग आकार चाहिए

अब तक हम ऑपरेशनल सिस्टम के बारे में सोच रहे थे। कोऑर्डिनेटर डिलीवरी के रूट बनाते हैं। क्रू स्टॉप पूरे करते हैं। बिज़नेस चलने के साथ सिस्टम बदलता है।

लेकिन बिज़नेस सालों के इतिहास का विश्लेषण भी करना चाहता है। कौन-से पार्टनर और क्षेत्र देर से चलते हैं? डिलीवरी का समय कैसे बदला है? इंस्टॉल के लिए कितनी बार दूसरी विज़िट चाहिए होती है?

एक एनालिटिकल सिस्टम वही जानकारी अलग तरह से व्यवस्थित चाह सकता है। आप डेटा वेयरहाउस, फ़ैक्ट (fact), डाइमेंशन (dimension) और स्टार स्कीमा (star schema) जैसे शब्द सुनेंगे। हम इन्हें यहाँ नहीं खोल रहे; Steve Trucking में वह Snowflake वेयरहाउस है, और हम कोर्स में आगे इस पर लौटेंगे।

फ़िलहाल: अलग-अलग इस्तेमाल करने वालों को एक ही सच के अलग-अलग आकार चाहिए हो सकते हैं।

AI एक और इस्तेमाल करने वाला जोड़ता है

और अब एक और इस्तेमाल करने वाला है: AI।

एक प्राप्तकर्ता मैसेज करता है, “मेरी डिलीवरी कहाँ है?” एक AI असिस्टेंट यह देख सकता है:

डिलीवरी 10427, रूट 3312, स्टॉप 7, ट्रक 117, समय-दायरा 13:00–15:00।

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

आपका Redrock डिशवॉशर Phoenix डिस्ट्रिब्यूशन सेंटर से निकले आज के रूट का सातवाँ स्टॉप है। ट्रक तीन स्टॉप दूर है, और आप अब भी दोपहर 1–3 बजे के अपने समय-दायरे में हैं।

हमने कई जुड़ी हुई एंटिटी से जानकारी ली और एक ख़ास इस्तेमाल करने वाले के लिए एक सपाट, संदर्भ से भरपूर रूप तैयार किया।

इसका मतलब यह नहीं कि मैं अपना नॉर्मलाइज़्ड मॉडल नष्ट कर दूँ। और इसका मतलब बिल्कुल यह नहीं कि “AI को सपाट डेटा पसंद है, तो सब कुछ एक विशाल ऑब्जेक्ट में डाल दो।” ऐसा न करें।

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

सच का एक स्रोत इस्तेमाल के लिए कई आकारों को सहारा दे सकता है।

कोर्स में आगे हम grounding (डेटा पर आधारित करना) और retrieval में कहीं गहराई से उतरेंगे।

कई सच न बनाएँ

यहाँ एक ख़तरा है।

अगर मैं रिपोर्टिंग के लिए क्षेत्र को डिलीवरी पर कॉपी करूँ, एक सपाट रूप Snowflake को भेजूँ, और AI असिस्टेंट के लिए संदर्भ से भरपूर एक रूप बनाऊँ, तो सही कौन-सा है?

इस सवाल का जवाब चाहिए। मैं जानना चाहता हूँ कि आधिकारिक वैल्यू कहाँ रहती है। बाकी सब किसी मक़सद के लिए उस सच का एक रूप है।

वह जगह है system of record (रिकॉर्ड का सिस्टम)। डीनॉर्मलाइज़्ड कॉपियाँ अच्छी हो सकती हैं: स्टॉप स्क्रीन, स्कोरकार्ड, Snowflake और AI का संदर्भ, हर एक अपने लिए बने आकार के साथ अपना काम बेहतर करता है, और उन्हें देखना ठीक है। लेकिन जब कुछ बदलता है, तो बदलाव system of record से शुरू होता है, आमतौर पर रिलेशनल मॉडल से, और बाहर हर कॉपी तक बहता है। कोई Snowflake में क्षेत्र ठीक नहीं करता, या AI के संदर्भ को हाथ से नहीं बदलता। स्रोत पर ठीक करें, और बदलाव को बहने दें।

Click to enlarge

और यह सबसे ज़्यादा तब मायने रखता है जब डेटा बदलता है। अगर कोई डिस्ट्रिब्यूशन सेंटर आज दूसरे क्षेत्र में चला जाए, तो क्या पिछले महीने की डिलीवरी में नया क्षेत्र दिखना चाहिए? शायद। शायद नहीं। इतिहास के लिए मुझे वह क्षेत्र चाहिए हो सकता है जो डिलीवरी के समय सच था। यह अब सिंक्रनाइज़ेशन की समस्या नहीं रही। यह बिज़नेस का फ़ैसला है।

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

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

डीनॉर्मलाइज़ेशन पर विचार करते हुए मैं यह तय कर रहा होता हूँ:

• बिज़नेस के हर तथ्य का आधिकारिक स्रोत कहाँ रहता है।
• क्या साफ़ मॉडल यूज़र, रिपोर्टिंग, स्केल या परफ़ॉर्मेंस के लिए असली समस्याएँ पैदा करता है।
• क्या एक सरल रूप दोहराव के लायक है, और कॉपी भरोसेमंद कैसे बनी रहेगी।
• जब मौजूदा स्रोत बदले, तो क्या ऐतिहासिक वैल्यू भी बदलनी चाहिए।
• क्या एनालिटिक्स या AI को ऑपरेशनल सिस्टम से अलग आकार का डेटा चाहिए।

शुरुआती बिंदु कभी नहीं बदलता: जानें कि सच कहाँ का है। फिर, जब ज़रूरतें इसे सही ठहराएँ, तो उसे पहुँचाने के लिए आकार दें।

आगे, Salesforce फिर से तस्वीर में आता है। हम जो डिज़ाइन किया है उसे एक फ़िज़िकल (भौतिक) डेटा मॉडल में बदलने जा रहे हैं।

और जानें

• Build Powerful Reports with Custom Report Types (opens in a new tab), Salesforce Admins, 24 जून 2019 (अंग्रेज़ी में, 2026-10-12 को जाँचा गया): एक custom report type “4 ऑब्जेक्ट संबंधों तक फैल सकता है।”
• Unleash the hounds, terriers and lapdogs: American Kennel Club recognizes 3 more breeds (opens in a new tab), PBS NewsHour, 2 जनवरी 2026 (अंग्रेज़ी में, 2026-10-12 को जाँचा गया): “AKC इन तीन नई नस्लों समेत 205 नस्लों को मान्यता देता है।”
• मज़े के लिए: FCI Breeds Nomenclature (opens in a new tab), Fédération Cynologique Internationale (अंग्रेज़ी में, 2026-10-12 को जाँचा गया): अंतरराष्ट्रीय महासंघ की नस्लों की सूची, दस समूहों में। इसे स्क्रॉल करके देखें, और आप समझ जाएँगे कि नस्ल ने अपनी टेबल क्यों कमाई।