सरोगेट कुंजी

सरोगेट कुंजी (या सिंथेटिक कुंजी, स्यूडोकी, इकाई पहचानकर्ता, तथ्यहीन कुंजी, या तकनीकी कुंजी) डेटाबेस में या तो मॉडलिंग की दुनिया में इकाई या डेटाबेस में वस्तु के लिए एक विशिष्ट पहचानकर्ता है। प्राकृतिक कुंजी | प्राकृतिक (या व्यवसाय) कुंजी के विपरीत, सरोगेट कुंजी एप्लिकेशन डेटा से प्राप्त नहीं होती है।

परिभाषा

सरोगेट की कम से कम दो परिभाषाएँ हैं:

सरोगेट (1) - हॉल, ओवलेट और टॉड (1976)

सरोगेट बाहरी दुनिया में एक इकाई का प्रतिनिधित्व करता है। सरोगेट आंतरिक रूप से सिस्टम द्वारा उत्पन्न होता है लेकिन फिर भी उपयोगकर्ता या एप्लिकेशन को दिखाई देता है।

सरोगेट (2) - वाइरिंगा और डी जॉन्ज (1991)

सरोगेट डेटाबेस में ही एक वस्तु का प्रतिनिधित्व करता है। सरोगेट आंतरिक रूप से सिस्टम द्वारा उत्पन्न होता है और उपयोगकर्ता या एप्लिकेशन के लिए अदृश्य होता है।

सरोगेट (1) परिभाषा भंडारण मॉडल के बजाय डेटा मॉडल से संबंधित है और इस पूरे लेख में इसका उपयोग किया गया है। दिनांक देखें (1998)।

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

हालांकि हॉल एट अल। (1976) अन्य लोग इस बारे में कुछ न कहें ने तर्क दिया है कि किराए की कोख में निम्नलिखित विशेषताएं होनी चाहिए:

• मूल्य का पुन: उपयोग नहीं किया जाता है
• मूल्य सिस्टम जनित है
• मूल्य उपयोगकर्ता या एप्लिकेशन द्वारा हेरफेर करने योग्य नहीं है
• मूल्य में कोई अर्थपूर्ण अर्थ नहीं है
• मूल्य उपयोगकर्ता या एप्लिकेशन को दिखाई नहीं देता है
• मान विभिन्न डोमेन से कई मानों से बना नहीं है।

अभ्यास में सरोगेट

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

सरोगेट कुंजी अक्सर अनुक्रमिक संख्या होती है (उदाहरण के लिए अनुकूली सर्वर एंटरप्राइज़ या Microsoft SQL सर्वर पहचान कॉलम, PostgreSQL या Informix serial, Oracle Corporation या Microsoft SQL सर्वर SEQUENCE या कॉलम परिभाषित किया गया है AUTO_INCREMENT MySQL में)। कुछ डेटाबेस सरोगेट कुंजियों के लिए संभावित डेटा प्रकार के रूप में UUID/GUID प्रदान करते हैं (उदाहरण के लिए PostgreSQL UUID या SQL सर्वर UNIQUEIDENTIFIER)।

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

अस्थायी डेटाबेस में, सरोगेट कुंजी और प्राकृतिक कुंजी के बीच अंतर करना आवश्यक है। प्रत्येक पंक्ति में व्यवसाय कुंजी और सरोगेट कुंजी दोनों होंगी। सरोगेट कुंजी डेटाबेस में अनूठी पंक्ति की पहचान करती है, व्यापार कुंजी मॉडलिंग की दुनिया की अनूठी इकाई की पहचान करती है। तालिका पंक्ति परिभाषित समय अवधि के लिए इकाई की सभी विशेषताओं को धारण करने वाले समय के एक टुकड़े का प्रतिनिधित्व करती है। वे स्लाइस व्यावसायिक इकाई के पूरे जीवन काल को दर्शाते हैं। उदाहरण के लिए, तालिका कर्मचारी अनुबंध अनुबंधित कार्य घंटों का ट्रैक रखने के लिए अस्थायी जानकारी रख सकता है। अनुबंध के लिए व्यापार कुंजी दोनों पंक्तियों में समान (गैर-अद्वितीय) होगी हालांकि प्रत्येक पंक्ति के लिए सरोगेट कुंजी अद्वितीय है।

सरोगेट कुंजी	व्यापार कुंजी	कर्मचारीनाम	कामकाजी घंटे प्रति सप्ताह	रोवैलिडफ्रॉम	रोवैलिडटो
1	BOS0120	John Smith	40	2000-01-01	2000-12-31
56	P0000123	Bob Brown	25	1999-01-01	2011-12-31
234	BOS0120	John Smith	35	2001-01-01	2009-12-31

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

कुछ वैकल्पिक नाम (सिस्टम जनित कुंजी) सरोगेट अवधारणा की प्रकृति के बजाय नए सरोगेट मान उत्पन्न करने के तरीके का वर्णन करते हैं।

सरोगेट्स पैदा करने के दृष्टिकोण में शामिल हैं:

• सार्वभौमिक रूप से अद्वितीय पहचानकर्ता (यूयूआईडी)
• विश्व स्तर पर विशिष्ट पहचानकर्ता (GUIDs)
• वस्तु पहचानकर्ता (ओआईडी)
• अनुकूली सर्वर एंटरप्राइज़ या Microsoft SQL सर्वर पहचान स्तंभ IDENTITY या IDENTITY(n,n)
• ओरेकल कॉर्पोरेशन SEQUENCE, या GENERATED AS IDENTITY (संस्करण 12.1 से शुरू)
• माइक्रोसॉफ्ट एसक्यूएल सर्वर SEQUENCE (एसक्यूएल सर्वर 2012 से शुरू) * PostgreSQL या IBM Informix सीरियल
• माई एसक्यूएल AUTO_INCREMENT
• SQLite INTEGER PRIMARY KEY (अगर AUTOINCREMENT उपयोग किया जाता है तो यह संख्याओं के पुन: उपयोग को रोक देगा जो पहले से ही उपयोग किए जा चुके हैं लेकिन उपलब्ध हैं)
• माइक्रोसॉफ्ट पहुंच में AutoNumber डेटा प्रकार
• AS IDENTITY GENERATED BY DEFAULT IBM Db2 और PostgreSQL में।
• टेराडाटा में आइडेंटिटी कॉलम (डेटा परिभाषा भाषा में लागू)।
• तालिका अनुक्रम जब अनुक्रम की गणना प्रक्रिया और फ़ील्ड के साथ अनुक्रम तालिका द्वारा की जाती है: आईडी, अनुक्रमनाम, अनुक्रम वैल्यू और वृद्धि मूल्य

लाभ

स्थिरता

पंक्ति मौजूद होने पर सरोगेट कुंजियाँ आमतौर पर नहीं बदलतीं। इसके निम्नलिखित फायदे हैं:

• एप्लिकेशन डेटाबेस में पंक्ति के लिए अपना संदर्भ नहीं खो सकते हैं (चूंकि पहचानकर्ता नहीं बदलता है)।
• प्राथमिक या प्राकृतिक कुंजी डेटा को हमेशा संशोधित किया जा सकता है, यहां तक ​​कि उन डेटाबेस के साथ भी जो संबंधित विदेशी कुंजी में कैस्केडिंग अपडेट का समर्थन नहीं करते हैं।

आवश्यकता परिवर्तन

विशेषताएँ जो विशिष्ट रूप से किसी इकाई की पहचान करती हैं, बदल सकती हैं, जो प्राकृतिक कुंजियों की उपयुक्तता को अमान्य कर सकती हैं। निम्नलिखित उदाहरण पर विचार करें:

कर्मचारी का नेटवर्क उपयोगकर्ता नाम प्राकृतिक कुंजी के रूप में चुना जाता है। किसी अन्य कंपनी के साथ विलय होने पर, नए कर्मचारियों को सम्मिलित किया जाना चाहिए। कुछ नए नेटवर्क उपयोगकर्ता नाम विरोध पैदा करते हैं क्योंकि उनके उपयोगकर्ता नाम स्वतंत्र रूप से उत्पन्न हुए थे (जब कंपनियां अलग थीं)।

इन मामलों में, आम तौर पर प्राकृतिक कुंजी में नई विशेषता जोड़ी जानी चाहिए (उदाहरण के लिए, original_company कॉलम)। सरोगेट कुंजी के साथ, सरोगेट कुंजी को परिभाषित करने वाली केवल तालिका बदली जानी चाहिए। प्राकृतिक कुंजी के साथ, प्राकृतिक कुंजी का उपयोग करने वाली सभी तालिकाओं (और संभवतः अन्य, संबंधित सॉफ़्टवेयर) को बदलना होगा।

कुछ समस्या डोमेन स्पष्ट रूप से उपयुक्त प्राकृतिक कुंजी की पहचान नहीं करते हैं। सरोगेट कुंजियाँ ऐसी प्राकृतिक कुंजी चुनने से बचें जो गलत हो सकती है।

प्रदर्शन

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

अनुकूलता

कई डेटाबेस एप्लिकेशन डेवलपमेंट सिस्टम, ड्राइवर और ऑब्जेक्ट-रिलेशनल मैपिंग सिस्टम, जैसे कि रूबी ऑन रेल्स या हाइबरनेट (जावा) का उपयोग करते समय, प्रत्येक तालिका के लिए प्राकृतिक कुंजी के बजाय पूर्णांक या GUID सरोगेट कुंजी का उपयोग करना बहुत आसान होता है डेटाबेस-सिस्टम-एग्नोस्टिक ऑपरेशंस और ऑब्जेक्ट-टू-रो मैपिंग का समर्थन करें।

एकरूपता

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

सत्यापन

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

नुकसान

अलगाव

जेनरेट की गई सरोगेट कुंजियों के मूल्यों का पंक्ति में रखे गए डेटा के वास्तविक दुनिया के अर्थ से कोई संबंध नहीं है। सरोगेट कुंजी का उपयोग करके किसी अन्य तालिका के लिए विदेशी कुंजी संदर्भ रखने वाली पंक्ति का निरीक्षण करते समय, सरोगेट कुंजी की पंक्ति का अर्थ कुंजी से ही नहीं समझा जा सकता है। संबंधित डेटा आइटम देखने के लिए प्रत्येक विदेशी कुंजी को जोड़ा जाना चाहिए। यदि उचित डेटाबेस बाधाओं को सेट नहीं किया गया है, या विरासत प्रणाली से आयात किया गया डेटा जहां संदर्भित अखंडता नियोजित नहीं किया गया था, तो विदेशी-कुंजी मान होना संभव है जो प्राथमिक-कुंजी मान के अनुरूप नहीं है और इसलिए अमान्य है। (इस संबंध में, सीजे डेट सरोगेट चाबियों की अर्थहीनता को लाभ के रूप में मानते हैं।)

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

निर्यात और साझा किए जाने वाले डेटा के लिए सरोगेट कुंजियाँ अप्राकृतिक हैं। विशेष कठिनाई यह है कि दो अन्य समान स्कीमाओं (उदाहरण के लिए, परीक्षण स्कीमा और विकास स्कीमा) से तालिकाओं में ऐसे रिकॉर्ड हो सकते हैं जो व्यावसायिक दृष्टि से समतुल्य हों, लेकिन अलग-अलग कुंजियाँ हों। क्षणिक डेटा को छोड़कर, सरोगेट कुंजियों को निर्यात नहीं करके इसे कम किया जा सकता है (सबसे स्पष्ट रूप से, उन अनुप्रयोगों को निष्पादित करने में जिनका डेटाबेस से लाइव कनेक्शन है)।

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

क्वेरी अनुकूलन

संबंधपरक डेटाबेस मानते हैं कि तालिका की प्राथमिक कुंजी पर अद्वितीय सूचकांक (डेटाबेस) लागू होता है। अद्वितीय सूचकांक दो उद्देश्यों को पूरा करता है: (i) इकाई अखंडता को लागू करने के लिए, क्योंकि प्राथमिक कुंजी डेटा पंक्तियों में अद्वितीय होना चाहिए और (ii) पूछताछ के दौरान पंक्तियों की त्वरित खोज करना। चूँकि सरोगेट कुंजियाँ किसी तालिका की पहचान करने वाली विशेषताओं को प्रतिस्थापित करती हैं - प्राकृतिक कुंजी - और चूंकि पहचान करने वाली विशेषताओं को क्वेरी किए जाने की संभावना है, इसलिए संभावित प्रश्नों को पूरा करते समय क्वेरी ऑप्टिमाइज़र को पूर्ण तालिका स्कैन करने के लिए मजबूर किया जाता है। पूर्ण तालिका स्कैन का उपाय पहचान करने वाली विशेषताओं, या उनके सेट पर अनुक्रमणिका लागू करना है। जहां इस तरह के सेट स्वयं उम्मीदवार कुंजी हैं, इंडेक्स अद्वितीय इंडेक्स हो सकता है।

हालाँकि, ये अतिरिक्त अनुक्रमणिकाएँ डिस्क स्थान लेंगी और आवेषण और विलोपन को धीमा कर देंगी।

सामान्यीकरण

सरोगेट कुंजियों के परिणामस्वरूप किसी भी प्राकृतिक कुंजी में डुप्लिकेट मान हो सकते हैं। दोहराव को रोकने के लिए, SQL का उपयोग करके तालिका को परिभाषित करते समय प्राकृतिक कुंजियों की भूमिका को अद्वितीय बाधाओं के रूप में संरक्षित करना चाहिए CREATE TABLE बयान या ALTER TABLE ... ADD CONSTRAINT बयान, अगर बाधाओं को बाद के विचार के रूप में जोड़ा जाता है।

बिजनेस प्रोसेस मॉडलिंग

क्योंकि सरोगेट चाबियां अप्राकृतिक हैं, व्यावसायिक आवश्यकताओं को मॉडलिंग करते समय त्रुटियां दिखाई दे सकती हैं। व्यावसायिक आवश्यकताओं, प्राकृतिक कुंजी पर भरोसा करते हुए, फिर सरोगेट कुंजी में अनुवाद करने की आवश्यकता होती है। रणनीति तार्किक मॉडल (जिसमें सरोगेट कुंजियाँ दिखाई नहीं देती हैं) और उस मॉडल के भौतिक कार्यान्वयन के बीच स्पष्ट अंतर बनाना है, यह सुनिश्चित करने के लिए कि तार्किक मॉडल सही और यथोचित अच्छी तरह से सामान्यीकृत है, और यह सुनिश्चित करने के लिए कि भौतिक मॉडल सही है तार्किक मॉडल का सही कार्यान्वयन।

अनजाने में खुलासा

यदि सरोगेट कुंजियाँ क्रमिक रूप से उत्पन्न की जाती हैं, तो मालिकाना जानकारी लीक हो सकती है। हाल ही में उत्पन्न अनुक्रमिक कुंजी से पहले उत्पन्न अनुक्रमिक कुंजी को घटाकर, उस समय अवधि के दौरान डाली गई पंक्तियों की संख्या सीख सकते हैं। यह उजागर कर सकता है, उदाहरण के लिए, लेन-देन की संख्या या प्रति अवधि नए खाते। उदाहरण के लिए जर्मन टैंक समस्या देखें।

इस समस्या को दूर करने के कुछ उपाय हैं:

• अनुक्रमिक संख्या को यादृच्छिक राशि से बढ़ाएं;
• यादृच्छिक कुंजी उत्पन्न करें जैसे कि सार्वभौमिक अद्वितीय पहचानकर्ता।

अनजाने अनुमान

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

यह भी देखें

• प्राकृतिक कुंजी
• वस्तु पहचानकर्ता
• लगातार वस्तु पहचानकर्ता

संदर्भ

स्रोत

• Nijssen, G.M. (1976). डाटा बेस मैनेजमेंट सिस्टम्स में मॉडलिंग. North-Holland Pub. Co. ISBN 0-7204-0459-2.
• एंगेल्स, आर.डब्ल्यू.: (1972), ए ट्यूटोरियल ऑन डाटा-बेस ऑर्गनाइजेशन, एनुअल रिव्यू इन ऑटोमैटिक प्रोग्रामिंग, वॉल्यूम.7, पार्ट 1, पेर्गमॉन प्रेस, ऑक्सफोर्ड, पीपी. 1-64।
• बोरजे लैंगफोर्स | लैंगफोर्स, बी (1968)। एलीमेंट्री फाइल्स एंड एलीमेंट्री फाइल रिकॉर्ड्स, प्रोसीडिंग्स ऑफ फाइल 68, फाइल ऑर्गनाइजेशन पर एक IFIP/IAG इंटरनेशनल सेमिनार, एम्स्टर्डम, नवंबर, पीपी। 89-96।
• Wieringa, Roel; de Jonge, Wiebren (1991). वस्तुओं और भूमिकाओं की पहचान - वस्तु पहचानकर्ताओं पर दोबारा गौर किया गया (PDF) (Technical report). Technical Report / Faculty of Mathematics and Computer Science. Vol. IR-267. Amsterdam: Faculty of Mathematics and Computer Science, Vrije Universiteit. CiteSeerX 10.1.1.16.3195. Retrieved 2022-12-02.
• Date, C. J. (1998). "Chapters 11 and 12". रिलेशनल डेटाबेस राइटिंग 1994-1997. ISBN 0201398141.
• Carter, Breck. "इंटेलिजेंट बनाम सरोगेट कीज़". Retrieved 2006-12-03.
• Richardson, Lee. "Create Data Disaster: Avoid Unique Indexes – (Mistake 3 of 10)". Archived from the original on 2008-01-30. Retrieved 2008-01-19.
• Berkus, Josh. "डाटाबेस सूप: प्राथमिक कीविल, भाग I". Retrieved 2006-12-03.

श्रेणी:डेटा मॉडलिंग

zh: संबंध कुंजी#.E4.BB.A3.E7.90.86.E9.8D.B5