एप्लिकेशन के बैकबोन को डिज़ाइन करना आमतौर पर सिर्फ टेबल परिभाषाओं को टाइप करने के बारे में नहीं होता है। यह सॉफ्टवेयर स्टैक के हर लेयर में फैलने वाले एक आर्किटेक्चरल निर्णय है। एक मजबूत एंटिटी रिलेशनशिप डायग्राम (ERD) डेटा इंटीग्रिटी, प्रदर्शन और स्केलेबिलिटी के लिए ब्लूप्रिंट के रूप में कार्य करता है। जब सीनियर इंजीनियर डेटाबेस स्कीमा डिज़ाइन के प्रति उपाय करते हैं, तो वे सिर्फ बॉक्स को लाइनों से जोड़ने के बारे में नहीं सोचते। वे डेटा के जीवनचक्र, लेज़र स्टोरेज इंजन की सीमाओं और उस एप्लिकेशन लॉजिक की आवश्यकताओं को ध्यान में रखते हैं जो अंततः इस जानकारी का उपयोग करेगी।
यह गाइड उत्पादन परिवेशों में उपयोग किए जाने वाले संरचनात्मक और दार्शनिक मानकों में गहराई से जाता है। हम नामकरण प्रणाली, नॉर्मलाइजेशन रणनीतियों, संबंध मॉडलिंग और डेटा गवर्नेंस के अक्सर नज़रअंदाज़ किए जाने वाले पहलुओं का अध्ययन करेंगे। लक्ष्य एक त्वरित समाधान प्रदान करना नहीं है, बल्कि टिकाऊ डेटा मॉडलिंग के लिए एक फ्रेमवर्क स्थापित करना है।
📐 ठोस डेटा मॉडलिंग की नींव
एक भी लाइन खींचने से पहले, एक को रिलेशनल मॉडल के मूल घटकों को समझना चाहिए। एंटिटी रिलेशनशिप डायग्राम इन घटकों का दृश्य प्रतिनिधित्व है। पेशेवर परिस्थितियों में स्पष्टता अत्यंत महत्वपूर्ण है। डायग्राम में अस्पष्टता कोड में अस्पष्टता का कारण बनती है, और कोड में अस्पष्टता उत्पादन में बग्स का कारण बनती है।
- एंटिटीज़: ये वास्तविक दुनिया की वस्तुओं या अवधारणाओं का प्रतिनिधित्व करते हैं। डेटाबेस में, इन्हें टेबल में बदला जाता है। एक एंटिटी एकल और विशिष्ट होनी चाहिए। सामान्य नामों जैसे
आइटम्सके बजायउत्पादयाइन्वेंटरी. - गुणधर्म: ये एक एंटिटी के गुणधर्म हैं। वे टेबल के अंदर कॉलम बन जाते हैं। गुणधर्म परमाणु होने चाहिए, जिसका अर्थ है कि वे एक ही मान रखते हैं, एक सूची या एक जटिल वस्तु नहीं।
- संबंध: ये एंटिटीज़ के बीच बातचीत के तरीके को परिभाषित करते हैं। एक संबंध एक टेबल की एक पंक्ति को दूसरी टेबल की एक पंक्ति से जोड़ता है। यहाँ कार्डिनैलिटी को समझना आवश्यक है।
सीनियर डेवलपर्स जोर देते हैं कि डायग्राम स्वयं दस्तावेज़ीकरण करने वाला होना चाहिए। यदि कोई डेवलपर ERD को देखता है और व्यापार तर्क के बारे में प्रश्न पूछने के लिए मजबूर होता है, तो डिज़ाइन विफल हो गया है। प्रत्येक टेबल और कॉलम का स्पष्ट उद्देश्य होना चाहिए जिसे उसके नाम और संदर्भ से निष्कर्ष निकाला जा सके।
🏷️ नामकरण प्रणाली और मानक
नामकरण एक स्कीमा का सबसे दृश्यमान पहलू है, फिर भी इसे अक्सर बाद में ध्यान में लाया जाता है। स्थिर नामकरण डेवलपर्स के लिए स्कीमा पढ़ने में मानसिक भार को कम करता है। इसके अलावा यह स्वचालित कोड जनरेशन टूल्स और ORM फ्रेमवर्क्स में मदद करता है।
टेबल नाम
- बहुवचन रूप: टेबल के लिए बहुवचन संज्ञा का उपयोग करें।
उपयोगकर्ताके बजायउपयोगकर्ता। यह अवधारणा के साथ मेल खाता है कि एक टेबल में रिकॉर्ड्स का संग्रह होता है। - अंडरस्कोर: अपनाएं
स्नेक_केसतालिका के नाम के लिए। यह कैमल केस की तुलना में पठनीयता में सुधार करता है, विशेष रूप से उन परिस्थितियों में जहां केस संवेदनशीलता ऑपरेटिंग सिस्टम के बीच बदल सकती है। - परिसर: प्रीफिक्स का उपयोग तब तक न करें जब तक कि डोमेन अलगाव के लिए आवश्यक न हो। जबकि कुछ टीमें जैसे प्रीफिक्स का उपयोग करती हैं
tbl_याdb_आधुनिक उपकरण अक्सर इसे स्वचालित रूप से संभालते हैं। नाम साफ रखें।
कॉलम के नाम
- वर्णनात्मक: एक कॉलम का नाम उसमें रखे गए डेटा की व्याख्या करना चाहिए, बाहरी दस्तावेज़ीकरण के बिना।
बनाया_गया_समयबेहतर हैसीयासमय. - विदेशी कुंजियाँ: विदेशी कुंजी कॉलम के नाम को संदर्भित तालिका के अनुरूप रखें। यदि
उपयोगकर्तातालिका को संदर्भित कर रहे हैं, तो कॉलम का नाम होना चाहिएउपयोगकर्ता_आईडी। इससे जॉइन शर्त स्पष्ट हो जाती है। - बूलियन: प्रीफिक्स का उपयोग करें जैसे
है_,है_याकर_बूलियन स्थिति को इंगित करने के लिए। उदाहरणों में शामिल हैंसक्रिय है,सदस्यता है, यासंपादित कर सकता है.
पूरे प्रोजेक्ट में सामंजस्य विशिष्ट नियम चयन से अधिक महत्वपूर्ण है। एक मानक सहमति पर पहुंचने के बाद, इसे लिंटिंग टूल्स या सहकर्मी समीक्षा के माध्यम से लागू किया जाना चाहिए।
🔗 संबंधों और कार्डिनैलिटी का नियंत्रण करना
एक संबंधात्मक डेटाबेस की शक्ति इसके संबंधों में है। इन संबंधों के गलत प्रबंधन के कारण डेटा की दोहराव और अखंडता त्रुटियां आम होती हैं। सीनियर डेवलपर संबंधों को कार्डिनैलिटी के आधार पर वर्गीकृत करते हैं: एक प्रतिनिधि के कितने उदाहरण दूसरे प्रतिनिधि से संबंधित हैं।
| संबंध प्रकार | विवरण | कार्यान्वयन |
|---|---|---|
| एक से एक (1:1) | टेबल A में एक रिकॉर्ड टेबल B में बिल्कुल एक रिकॉर्ड से संबंधित होता है। | एक तालिका में एक अद्वितीय विदेशी कुंजी रखें। |
| एक से बहुत (1:N) | टेबल A में एक रिकॉर्ड टेबल B में बहुत सारे रिकॉर्ड से संबंधित होता है। | टेबल B में टेबल A को संदर्भित करने वाली विदेशी कुंजी रखें। |
| बहुत से बहुत (M:N) | टेबल A के रिकॉर्ड टेबल B में बहुत से रिकॉर्ड से संबंधित हो सकते हैं और इसके विपरीत भी। | दो विदेशी कुंजियों वाली एक जंक्शन तालिका बनाएं। |
एक से एक संबंध
ये अन्य प्रकारों की तुलना में कम आम हैं, लेकिन विशिष्ट परिस्थितियों में दिखाई देते हैं, जैसे संवेदनशील डेटा को अलग करना या प्रदर्शन के लिए बड़े डेटा सेट को विभाजित करना। उदाहरण के लिए, एक उपयोगकर्ता तालिका सार्वजनिक प्रोफाइल डेटा रख सकती है, जबकि एक उपयोगकर्ता_विवरण तालिका निजी जानकारी जैसे सोशल सिक्योरिटी नंबर रखती है। यह संबंध विदेशी कुंजी कॉलम पर अद्वितीय सीमा द्वारा बल द्वारा बनाए रखा जाता है।
एक से बहुत संबंध
यह संबंधात्मक डिजाइन का कार्यकर्ता है। एक आदेश तालिका एक से संबंधित हैआर्डरआइटम्स तालिका। एक आदेश में कई आइटम हो सकते हैं। विदेशी कुंजी का स्थान हैआर्डरआइटम्स तालिका जो इसकी ओर इशारा करती हैआदेश तालिका। इस संरचना के कारण प्रत्येक आइटम के लिए पूरे आदेश हेडर को दोहराए बिना कुशल खोज की अनुमति मिलती है।
बहु-से-बहु संबंध
मानक संबंधात्मक प्रणालियों में दो तालिकाओं के बीच सीधा संबंध असंभव है। एक संयोजन तालिका, जिसे अक्सर संबंधात्मक एकता कहा जाता है, की आवश्यकता होती है। उदाहरण के लिए, जोड़नाछात्र औरपाठ्यक्रम। एक छात्र कई पाठ्यक्रम ले सकता है, और एक पाठ्यक्रम में कई छात्र हो सकते हैं। संयोजन तालिकानामांकन में शामिल हैछात्र_id औरपाठ्यक्रम_id। इस तालिका में नामांकन की तारीख या ग्रेड जैसे अतिरिक्त डेटा भी संग्रहीत किया जा सकता है।
जब इन संबंधों के मॉडलिंग करते हैं, तो वैकल्पिकता को ध्यान में रखें। क्या उपयोगकर्ता के प्रोफाइल होना अनिवार्य है? यदि हां, तो संबंध अनिवार्य है। यदि उपयोगकर्ता प्रोफाइल के बिना भी मौजूद हो सकता है, तो विदेशी कुंजी खाली हो सकती है। आरेख में इसे स्पष्ट रूप से परिभाषित करने से एप्लिकेशन लेयर में तर्क त्रुटियों से बचा जा सकता है।
🧱 सामान्यीकरण और डेटा अखंडता
सामान्यीकरण डेटा को कम अतिरेक और अच्छी अखंडता के लिए संगठित करने की प्रक्रिया है। जबकि अक्सर कठोर नियमों के रूप में पढ़ाया जाता है, वरिष्ठ विकासकर्ता इसे एक स्पेक्ट्रम के रूप में देखते हैं। लक्ष्य डेटा शुद्धता और प्रश्न प्रदर्शन के बीच संतुलन बनाए रखना है।
पहला सामान्य रूप (1NF)
- परमाणुता सुनिश्चित करें: प्रत्येक कॉलम में केवल एक मान होता है।
- अलग-अलग कॉलम सुनिश्चित करें: एक ही सेल के भीतर कोई दोहराए गए समूह या ऐरे नहीं हैं।
- अद्वितीय पंक्तियाँ सुनिश्चित करें: प्रत्येक पंक्ति को अद्वितीय रूप से पहचाना जा सकना चाहिए।
दूसरा सामान्य रूप (2NF)
- 1NF की आवश्यकताओं को पूरा करें।
- आंशिक निर्भरता हटाएं। सभी गैर-कुंजी विशेषताओं को पूरे मुख्य कुंजी पर निर्भर होना चाहिए, केवल इसके कुछ हिस्से पर नहीं। यह संयुक्त कुंजी के साथ काम करते समय निर्णायक है।
तीसरा सामान्य रूप (3NF)
- 2NF की आवश्यकताओं को पूरा करें।
- स्थानांतरण निर्भरता हटाएं। गैर-की विशेषताएं अन्य गैर-की विशेषताओं पर निर्भर नहीं होनी चाहिए। उदाहरण के लिए, यदि एक तालिका में है
कर्मचारीआईडी,प्रबंधकआईडी, औरप्रबंधकनाम, तो प्रबंधक का नाम प्रबंधक आईडी पर निर्भर करता है, कर्मचारी आईडी पर नहीं। प्रबंधक विवरण को अलग तालिका में स्थानांतरित करें।
जब डेनॉर्मलाइज़ करें:
3NF का सख्ती से पालन करना हमेशा उत्तर नहीं है। पढ़ने पर निर्भर एप्लिकेशन में, बहुत सारी तालिकाओं को जोड़ने से प्रदर्शन की समस्या हो सकती है। सीनियर इंजीनियर जॉइन की जटिलता कम करने के लिए कुछ विशिष्ट डेटा बिंदुओं को डेनॉर्मलाइज़ कर सकते हैं। उदाहरण के लिए, उपयोगकर्ता नाम एक में आदेशों तालिका में स्टोर करना स्वीकार्य हो सकता है यदि उपयोगकर्ता नाम बहुत कम बदलते हैं और पढ़ने की गति महत्वपूर्ण है। हालांकि, इससे अपडेट विचलन आता है। यदि उपयोगकर्ता नाम बदलता है, तो प्रत्येक आदेश रिकॉर्ड को अपडेट करना होगा। इस व्यापार को दस्तावेज़ित और समझा जाना चाहिए।
🔑 की चयन रणनीतियाँ
प्राथमिक की (PK) एक पंक्ति के लिए एकमात्र पहचानकर्ता है। की के चयन का डेटाबेस इंजन द्वारा डेटा के इंडेक्सिंग और संबंधों के निर्माण के तरीके पर प्रभाव पड़ता है।
प्राकृतिक की
एक प्राकृतिक की मौजूदा व्यापार डेटा पर निर्भर करती है, जैसे सोशल सिक्योरिटी नंबर या ईमेल पता। लाभ यह है कि की वास्तविक दुनिया का अर्थ प्रतिनिधित्व करती है। नुकसान यह है कि प्राकृतिक की बदल सकती है, और वे अक्सर प्रभावी इंडेक्सिंग के लिए बहुत लंबी होती हैं। ईमेल जैसे एक अद्वितीय पहचानकर्ता को विदेशी की के रूप में उपयोग करने से अन्य तालिकाओं में बहुत बढ़ोतरी हो सकती है।
सरोगेट की
एक सरोगेट की एक कृत्रिम पहचानकर्ता है, जिसे आमतौर पर स्वतः बढ़ता हुआ पूर्णांक या UUID होता है। इसका कोई व्यापारिक अर्थ नहीं होता है। यह अधिकांश आधुनिक प्रणालियों के लिए प्राथमिक विधि है। यह तब भी स्थिर रहता है जब आधार डेटा बदलता है। यह संक्षिप्त होता है, जिससे इंडेक्स खोज तेज होती है। यह रिश्तों को सरल बनाता है क्योंकि विदेशी की छोटी और अधिक स्थिर होती है।
- पूर्णांक सरोगेट: इंडेक्सिंग और संग्रहण के लिए कुशल। उच्च आयतन लेनदेन प्रणालियों के लिए आदर्श।
- UUIDs: वितरित प्रणालियों के लिए उपयोगी, जहां बहुत से नोड्स के बीच अद्वितीयता को निर्धारित करने की आवश्यकता होती है बिना समन्वय के। वे आईडी अनुक्रम में खाली जगहों से बचते हैं, लेकिन पूर्णांकों की तुलना में बड़े होते हैं और इंडेक्स के लिए कम अनुकूल होते हैं।
🛡️ सीमांकन और डेटा अखंडता
एक डेटाबेस केवल उन नियमों के बराबर अच्छा है जो इसकी रक्षा करते हैं। सीमांकन सुनिश्चित करते हैं कि डेटा सटीक और संगत रहे, चाहे एप्लिकेशन इससे कैसे भी बातचीत करे।
- NOT NULL: यह सुनिश्चित करें कि आवश्यक फील्ड हमेशा भरे जाएं। इससे डेटाबेस में अपूर्ण रिकॉर्ड स्टोर करने से बचा जाता है जो एप्लिकेशन तर्क को तोड़ सकते हैं।
- UNIQUE: ऐसे कॉलम में दोहराए गए इनपुट को रोकें जहां अलग-अलग होना आवश्यक हो, जैसे ईमेल पते या उत्पाद SKUs।
- चेक: कस्टम लॉजिक के लिए अनुमति दें। उदाहरण के लिए, यह सुनिश्चित करना कि छूट प्रतिशत 0 और 100 के बीच हो।
- डिफ़ॉल्ट: समझदारी वाले फॉलबैक मान प्रदान करें। यदि उपयोगकर्ता समय क्षेत्र नहीं बताता है, तो डिफ़ॉल्ट यूटीसी के रूप में निर्धारित करें।
संदर्भात्मक अखंडता की सीमाएँ संबंधों को बनाए रखने के लिए महत्वपूर्ण हैं।हटाने पर नियम निर्धारित करते हैं कि जब एक मातृ रिकॉर्ड हटाया जाता है तो क्या होता है। विकल्पों में शामिल हैं:
- कैस्केड: बच्चे के रिकॉर्ड को स्वचालित रूप से हटा दें। सावधानी से उपयोग करें, क्योंकि इससे अनजाने में डेटा की हानि हो सकती है।
- प्रतिबंधित: यदि बच्चे के रिकॉर्ड मौजूद हैं तो हटाने को रोकें। इससे एप्लिकेशन को लॉजिक को स्पष्ट रूप से संभालने के लिए मजबूर किया जाता है।
- NULL सेट करें: यदि मातृ रिकॉर्ड हटाया जाता है तो विदेशी कुंजी को NULL कर दें। यह केवल तभी काम करता है जब कॉलम NULL मानों की अनुमति देता है।
⚡ प्रदर्शन और इंडेक्सिंग विचारों
प्रदर्शन के लिए डिज़ाइन करना स्कीमा स्तर पर शुरू होता है। जबकि प्रश्नों को बाद में अनुकूलित किया जाता है, एक खराब स्कीमा अनुकूलन को असंभव बना सकता है।
इंडेक्सिंग रणनीति
- प्राथमिक कुंजियाँ: स्वचालित रूप से इंडेक्स किया गया।
- विदेशी कुंजियाँ: जॉइन ऑपरेशन और सीमा जांच को तेज करने के लिए इंडेक्स किया जाना चाहिए।
- प्रश्न कॉलम: आमतौर पर उपयोग किए जाने वाले कॉलम
जहाँ,क्रम द्वारा व्यवस्थित करें, यासमूह द्वाराक्लॉज को इंडेक्स किया जाना चाहिए।
हालांकि, इंडेक्स मुफ्त नहीं हैं। वे डिस्क स्पेस का उपयोग करते हैं और लेखन ऑपरेशन को धीमा करते हैं। प्रत्येक इन्सर्ट, अपडेट या हटाने को इंडेक्स के अपडेट करना होता है। सीनियर डेवलपर्स अति इंडेक्सिंग से बचते हैं। वे इंडेक्स जोड़ने से पहले वास्तविक प्रश्न पैटर्न का विश्लेषण करते हैं।
डेटा प्रकार
सही डेटा प्रकार का चयन स्टोरेज और गति को प्रभावित करता है। तारीखों या संख्याओं के लिए एक सामान्य स्ट्रिंग प्रकार का उपयोग स्थान का बर्बाद करता है और तुलना को धीमा कर देता है। उपयोग करें समय-चिह्न तारीख और समय के लिए। उपयोग करें दशमलव मुद्रा के लिए तैयार करने के लिए ताकि तैरते बिंदु त्रुटियों से बचा जा सके। उपयोग करें बूलियन संख्याओं या स्ट्रिंग्स के बजाय सच/झूठ की स्थिति के लिए।
🔄 विकास और रखरखाव
सॉफ्टवेयर आवश्यकताएं बदलती हैं। आज काम करने वाला एक स्कीमा एक साल में अप्रचलित हो सकता है। एक स्थिर आरेख एक दोष है। ईआरडी को एप्लिकेशन के साथ विकसित होना चाहिए।
स्कीमा के लिए संस्करण नियंत्रण
स्कीमा परिवर्तनों को कोड के रूप में लिया जाना चाहिए। माइग्रेशन स्क्रिप्ट्स को एक संस्करण नियंत्रण प्रणाली में स्टोर करें। इससे टीमों को यह ट्रैक करने में मदद मिलती है कि क्या बदला गया, किसने बदला, और कब। यह भी अनुमति देता है कि यदि माइग्रेशन में समस्या आए तो वापस ले लिया जा सके। कभी भी स्क्रिप्ट के बिना उत्पादन डेटाबेस को हाथ से बदलें।
दस्तावेज़ीकरण स्वच्छता
- टिप्पणियाँ: जटिल तर्क या व्यापार नियमों को समझाने के लिए डेटाबेस में टिप्पणियों का उपयोग करें जिन्हें सीमाओं द्वारा बल नहीं दिया जा सकता।
- आरेख अद्यतन: यदि कोड में परिवर्तन होता है, तो आरेख में भी परिवर्तन होना चाहिए। अद्यतन नहीं आरेख भ्रम और नियुक्ति या डीबगिंग के दौरान बर्बाद समय का कारण बनता है।
- परिवर्तन लॉग: महत्वपूर्ण संरचनात्मक परिवर्तनों का लॉग बनाए रखें। यह बाद में यह समझने में मदद करता है कि किसी विशिष्ट डिज़ाइन निर्णय को क्यों बनाया गया था।
🚫 बचने के लिए सामान्य त्रुटियाँ
यहां तक कि अनुभवी टीमें भी गलतियां करती हैं। विफलता के सामान्य पैटर्न को पहचानना रोकथाम में मदद करता है।
- चक्रीय निर्भरता: तालिका A के बी पर निर्भरता है, और B के A पर निर्भरता है। इससे निर्माण या हटाने के दौरान बंद रास्ता बनता है। अस्थायी रूप से खाली मानों को अनुमति देकर या तीसरी तालिका के उपयोग से चक्र को तोड़ें।
- अत्यधिक सामान्यीकरण: छोटे संबंधों के लिए बहुत सारी तालिकाएं बनाने से जटिल क्वेरीज़ बनती हैं जिन्हें बनाए रखना मुश्किल होता है। कभी-कभी, एक ही तालिका पर्याप्त होती है।
- अस्पष्ट विदेशी कुंजियाँ: एक कॉलम जिसका नाम है
आईडीबहुत सारी तालिकाओं में संदर्भ के बिना भ्रम पैदा कर सकता है। हमेशा उपयोग करेंतालिका_आईडीनामकरण। - मृत डेटा को नजरअंदाज करना: डेटा को स्थायी रूप से हटाना अक्सर अनुत्क्रमणीय होता है। मृत डेटा के लिए डिज़ाइन करने के लिए एक और इंडेक्स जोड़ें
is_deletedफ्लैग और इस पर एक इंडेक्स।
📝 सीनियर-लेवल विचारों का सारांश
एक उच्च गुणवत्ता वाले डेटा मॉडल का निर्माण करने के लिए सैद्धांतिक ज्ञान और व्यावहारिक अनुभव का मिश्रण आवश्यक होता है। यह काफी नहीं है कि आपको विदेशी कुंजी क्या है, इसके बारे में पता हो; आपको यह समझना होगा कि यह प्रश्न योजना और लेनदेन लॉकिंग पर कैसे प्रभाव डालती है। निम्नलिखित चेकलिस्ट एक टिकाऊ डिज़ाइन के लिए महत्वपूर्ण कार्रवाइयों का सारांश प्रस्तुत करती है।
- ✅ निरंतर रूप से संख्यात्मक, स्नेक_केस नामकरण प्रणाली का उपयोग करें।
- ✅ सही कार्डिनैलिटी के साथ संबंधों को स्पष्ट रूप से परिभाषित करें।
- ✅ नॉर्मलाइजेशन सिद्धांतों को लागू करें, लेकिन रणनीतिक डेनॉर्मलाइजेशन की अनुमति दें।
- ✅ आंतरिक पहचान के लिए सरोगेट कुंजियों को प्राथमिकता दें।
- ✅ एप्लिकेशन में ही नहीं, बल्कि डेटाबेस स्तर पर भी प्रतिबंधों को लागू करें।
- ✅ विदेशी कुंजियों और अक्सर पूछे जाने वाले कॉलम पर इंडेक्स बनाएं।
- ✅ सभी स्कीमा परिवर्तनों को वर्जन नियंत्रण में रखें।
- ✅ चित्रों को वास्तविक डेटाबेस स्थिति के साथ समन्वय में रखें।
इन अभ्यासों का पालन करके विकासकर्ता ऐसे प्रणालियां बनाते हैं जो लचीली, समझने योग्य हैं और व्यवसाय के साथ बढ़ने में सक्षम हैं। प्रारंभिक डिज़ाइन चरण में निवेश की गई मेहनत तकनीकी दायित्व को कम करने और बाद में चलने वाली प्रक्रिया को आसान बनाने में लाभ देती है। डेटा किसी भी एप्लिकेशन की सबसे मूल्यवान संपत्ति है; इसकी संरचना को अनुशासन के साथ लेना एक सीनियर पेशेवर की पहचान है।