जब वास्तुकार डेटा संरचना डिज़ाइन करना शुरू करते हैं, तो ध्यान अक्सर संबंधों की ओर जाता है। हम एकता और उन्हें जोड़ने वाले संबंधों पर बहुत ध्यान केंद्रित करते हैं। रेखाएं खींची जाती हैं, क्राउ के पैर जोड़े जाते हैं, और कार्डिनैलिटी को परिभाषित किया जाता है। यह मानना आसान है कि डेटाबेस की खाका केवल तालिकाओं के एक दूसरे से जुड़ने के तरीके से निर्धारित होती है। हालांकि, यह दृष्टिकोण वास्तव में डेटा को एक साथ रखने वाले मूल निर्माण ब्लॉकों को नजरअंदाज करता है: अभिलक्षण।
अभिलक्षण वे विशिष्ट जानकारी हैं जो एक एकता के भीतर संग्रहीत की जाती हैं। वे डेटा की प्रकृति को परिभाषित करते हैं, केवल यह नहीं कि यह अन्य डेटा से कैसे संबंधित है। जबकि संबंध नेटवर्क की संरचना निर्धारित करते हैं, अभिलक्षण उस नेटवर्क के भीतर जानकारी की अखंडता, प्रदर्शन और उपयोगिता निर्धारित करते हैं। अभिलक्षण डिज़ाइन के बारे में बातचीत को नजरअंदाज करने से एक ऐसा सिस्टम बन सकता है जो काम करता है लेकिन स्केल, डेटा गुणवत्ता और प्रश्न दक्षता के मामले में कठिनाइयों का सामना करता है।
यह मार्गदर्शिका एंटिटी-रिलेशनशिप डायग्राम (ERD) में अभिलक्षणों की महत्वपूर्ण भूमिका का अध्ययन करती है। हम बुनियादी परिभाषाओं से आगे बढ़कर अभिलक्षण चयन के नॉर्मलाइजेशन, स्टोरेज अनुकूलन और लंबे समय तक रखरखाव के प्रभाव का अध्ययन करेंगे।
🛠️ डेटा मॉडल में अभिलक्षणों को परिभाषित करना
एक अभिलक्षण एक एकता का गुण या विशेषता है। एक भौतिक डेटाबेस में, इसका अर्थ तालिका के भीतर एक कॉलम होता है। संकल्पनात्मक चरण में, यह एक एंटिटी आयत के साथ जुड़े वृत्त या अंडाकार के रूप में होता है। एकता और अभिलक्षण के बीच अंतर कभी-कभी धुंधला हो सकता है, लेकिन नियम सरल है: यदि डेटा एकता का वर्णन करता है और स्वतंत्र रूप से अस्तित्व में नहीं आ सकता, तो यह एक अभिलक्षण है।
एक के बारे में सोचेंग्राहकएकता। नाम, पता और जन्मतिथि अभिलक्षण हैं। वे ग्राहक का वर्णन करते हैं लेकिन एक आर्डर या उत्पाद की तरह स्वतंत्र रूप से रिकॉर्ड के रूप में अस्तित्व में नहीं होते हैं। हालांकि, इन अभिलक्षणों को कैसे संग्रहीत करना है, इस निर्णय जहां समस्या शुरू होती है।
आपको जानने के लिए आवश्यक अभिलक्षणों के प्रकार
सभी अभिलक्षण समान नहीं होते हैं। एक अभिलक्षण के विशिष्ट वर्गीकरण को समझना उसकी स्टोरेज आवश्यकताओं और सीमाओं के निर्धारण में मदद करता है। नीचे डेटा मॉडलिंग के दौरान आमतौर पर मिलने वाले प्रकारों का विवरण दिया गया है।
| अभिलक्षण प्रकार | विवरण | उदाहरण |
|---|---|---|
| सरल अभिलक्षण | परमाणु मान; आगे विभाजित नहीं किया जा सकता। | उम्र, सोशल सिक्योरिटी नंबर |
| संयुक्त अभिलक्षण | उप-भागों में विभाजित। | पता (स्ट्रीट, शहर, जिप) |
| बहु-मूल्य अभिलक्षण | एकल एकता उदाहरण के लिए कई मान धारण कर सकता है। | फोन नंबर, ईमेल पते |
| व्युत्पन्न अभिलक्षण | अन्य अभिलक्षणों से गणना की गई। | उम्र (जन्मतिथि से गणना), कुल मूल्य |
| की अभिलक्षण | एकता की विशिष्ट पहचान करता है। | ग्राहक आईडी, ऑर्डर नंबर |
इनमें से प्रत्येक प्रकार को तार्किक डिज़ाइन चरण में विशिष्ट तरीके से संभालने की आवश्यकता होती है। एक सरल अभिलक्षण और एक संयुक्त अभिलक्षण के बीच अंतर न करने से कठोर स्कीमा बन सकते हैं जिन्हें बाद में संशोधित करना मुश्किल होता है। उदाहरण के लिए, पूरा पता एकल स्ट्रिंग के रूप में संग्रहीत करने से शहर या जिप कोड के आधार पर फ़िल्टर करना कठिन हो जाता है, जिसके लिए जटिल स्ट्रिंग संचालन की आवश्यकता होती है।
⚖️ खराब विशेषता डिज़ाइन की छुपी लागत
बहुत से टीमें विशेषताओं को संबंधों को स्थापित करने के बाद भरे जाने वाले छोटे-छोटे विवरण के रूप में देखती हैं। इस दृष्टिकोण के परिणामस्वरूप अक्सर महत्वपूर्ण तकनीकी ऋण बनता है। जब विशेषताओं को खराब तरीके से परिभाषित किया जाता है, तो उनके प्रभाव पूरे प्रणाली में फैल जाते हैं।
- डेटा अखंडता की समस्याएं: यदि कोई विशेषता स्पष्ट व्यावसायिक तर्क के बिना खाली मानों की अनुमति देती है, तो रिपोर्ट्स अविश्वसनीय हो जाती हैं। यदि किसी विशेषता में सीमाएं (जैसे अधिकतम लंबाई या मान्य सीमा) की कमी है, तो डेटाबेस गंदे डेटा को स्वीकार कर लेता है।
- प्रश्न प्रदर्शन में गिरावट: सूचकांक के बिना व्युत्पन्न डेटा को बार-बार संग्रहीत करने से अपडेट की गति धीमी हो जाती है। विपरीत रूप से, अक्सर पूछे जाने वाली विशेषताओं को सूचकांकित न करने से खोज ऑपरेशन धीमे हो जाते हैं।
- नॉर्मलाइजेशन के उल्लंघन: विशेषताओं को गलत तरीके से विभाजित करना या मिलाना अक्सर रिकॉर्ड के इन्सर्ट, डिलीट या अपडेट के दौरान असामान्यताओं का कारण बनता है।
- स्केलेबिलिटी के बॉटलनेक: असीमित रूप से बढ़ने वाली विशेषताएं (जैसे एक ही टेक्स्ट फ़ील्ड में टैग की सूची संग्रहीत करना) प्रभावी पार्टीशनिंग और शार्डिंग रणनीतियों को रोकती हैं।
यह सिर्फ उचित कॉलम होने के बारे में नहीं है; यह उचित सीमाओं और डेटा प्रकार होने के बारे में है। एक varchar फ़ोन नंबर संग्रहीत करने के लिए उपयोग किया जाने वाला फ़ील्ड एक विशिष्ट पूर्णांक या प्रारूपित स्ट्रिंग प्रकार की तुलना में कम कुशल और कम सटीक है जो इनपुट की पुष्टि करता है।
🔍 गहन अध्ययन: विशेषता डिज़ाइन पैटर्न
दृढ़ प्रणालियों के निर्माण के लिए, डिज़ाइनरों को विशेषताओं को परिभाषित करते समय विशिष्ट पैटर्न का उपयोग करना चाहिए। इन पैटर्नों से डेटा मॉडल में संगतता और स्पष्टता सुनिश्चित होती है।
1. परमाणुता और प्रथम सामान्य रूप
विशेषता डिज़ाइन का पहला नियम परमाणुता है। प्रत्येक विशेषता में एकल, अविभाज्य मान होना चाहिए। एक ही सेल में कई मानों को संग्रहीत करने से बचें।
- बुरी प्रथा: एक
कौशलविशेषता जिसमें “SQL, Python, Java” है। - अच्छी प्रथा: एक अलग जंक्शन तालिका जो कर्मचारी और कौशल.
परमाणुता के उल्लंघन से प्रश्न पूछना जटिल हो जाता है। आप बिना स्ट्रिंग के विश्लेषण किए आसानी से नहीं गिन सकते कि कितने कर्मचारी “Python” जानते हैं। विशेषताओं को परमाणु रखने से डेटा प्राप्त करने और संग्रहीत करने के लिए आवश्यक तर्क को सरल बनाया जा सकता है।
2. नामकरण प्रथाएं और स्पष्टता
विशेषता के नाम स्वयं स्पष्ट होने चाहिए। अस्पष्टता रखरखाव के शत्रु है। भविष्य के डेवलपर्स के लिए स्पष्ट न होने वाले संक्षिप्त रूपों से बचें। विशेषताओं के लिए एकवचन संज्ञा का उपयोग करें ताकि यह दर्शाया जा सके कि वे एक एकल संपत्ति का वर्णन करती हैं।
- अस्पष्ट:
तारीखयामान. - स्पष्ट:
जन्मतिथियालेनदेन मूल्य.
नामकरण में सामंजस्य ऑटोमेटेड टूल्स द्वारा दस्तावेज़ीकरण और कोड उत्पन्न करने में सहायता करता है। यदि मॉडल किसी भी स्थान पर बनाया गया समय का उपयोग करता है, तो उत्पादित SQL प्रश्न उस पैटर्न का पालन करेंगे, जिससे इंजीनियरिंग टीम के लिए मानसिक भार कम होता है।
3. नॉल के प्रबंधन
प्रत्येक विशेषता के लिए नॉल के संबंध में एक परिभाषित नियम होना चाहिए। बहुत से प्रणालियों में, NULL एक खाली स्ट्रिंग या शून्य के बराबर नहीं माना जाता है। यह तय करना कि क्या एक विशेषता नॉल हो सकती है, व्यापार तर्क पर आधारित होना चाहिए।
- अनिवार्य विशेषताएं: यदि एक ग्राहक ईमेल पते के बिना अस्तित्व में नहीं आ सकता है, तो विशेषता को
NOT NULL. - वैकल्पिक विशेषताएं: यदि एक उत्पाद मध्य नाम न हो सकता है, तो विशेषता को
NULL.
अत्यधिक उपयोग करना NULL SQL क्वेरी में त्रिमूल्य तर्क त्रुटियों के कारण बन सकता है (जहां NULL = NULL गलत है)। डिज़ाइन चरण में स्पष्ट रूप से NULL का निपटान करने से इन तार्किक जाल से बचा जा सकता है।
🧩 विशेषताएँ बनाम संबंध: संतुलन ढूंढना
अक्सर विवाद होता है कि विशेषताओं को जोड़ना कब बंद करना चाहिए और नए संस्थानों को बनाना शुरू करना चाहिए। यह पारंपरिक “विशेषता बनाम संस्थान” समस्या है। निर्णय संबंध की कार्डिनैलिटी पर निर्भर करता है।
यदि कोई विशेषता स्वतंत्र रूप से अस्तित्व में हो सकती है या उसके अपने गुण हैं, तो यह संभवतः एक संस्थान होनी चाहिए। यदि यह शुद्ध रूप से वर्णनात्मक है और माता-पिता पर निर्भर है, तो यह विशेषता ही रहती है।
- परिदृश्य A: एक कार के पास एक
रंगविशेषता है। यह वर्णनात्मक है। इसका अपना जीवन नहीं है। - परिदृश्य B: एक कार के पास एक
मालिक। मालिक एक व्यक्ति है जिसके अपने गुण हैं (नाम, पता)। यह एक संस्थान से संबंध है, विशेषता नहीं। - परिदृश्य C: एक पाठ्यक्रम के पास है
विषय। यदि विषय मानक हैं (गणित, विज्ञान), तो उन्हें विशेषताएँ बनाया जा सकता है। यदि विषय जटिल हैं (विवरण, कठिनाई स्तर के साथ), तो उन्हें संस्थान बनाना चाहिए।
इस संतुलन को गलत करने से या अत्यधिक अननियमित तालिकाएँ या अनावश्यक रूप से टूटे मॉडल बनते हैं। लक्ष्य आवश्यक विवरण को बनाए रखना है बिना उस जटिलता के जो व्यापार तर्क की आवश्यकता नहीं है।
📉 नॉर्मलाइजेशन पर प्रभाव
नॉर्मलाइजेशन डेटा को अतिरेक को कम करने के लिए व्यवस्थित करने की प्रक्रिया है। विशेषताएँ इस प्रक्रिया के दौरान आगे-पीछे ले जाए जाने वाली प्राथमिक इकाइयाँ हैं। 3rd नॉर्मल फॉर्म (3NF) तक पहुँचने के लिए विशेषताओं के व्यवहार को समझना आवश्यक है।
स्थानांतरित निर्भरता
एक स्थानांतरित निर्भरता तब होती है जब कोई गैर-की विशेषता दूसरी गैर-की विशेषता पर निर्भर होती है। यह विशेषता डिज़ाइन में एक सामान्य त्रुटि है।
एक कल्पना कीजिए आदेश तालिका जिसमें है आदेश_आईडी, ग्राहक_आईडी, ग्राहक_नाम, और ग्राहक_पता.
ग्राहक_नामपर निर्भर करता हैग्राहक_आईडी.ग्राहक_पतापर निर्भर करता हैग्राहक_आईडी.ग्राहक_नामपर निर्भर नहीं करता हैआदेश_आईडी.
यहाँ, ग्राहक_पता सीधे नहीं बल्कि अप्रत्यक्ष रूप से आदेश_आईडी के माध्यम से ग्राहक_आईडी. इसके लिए सामान्यीकरण करने के लिए, आपको ग्राहक विशेषताओं को अलग एक ग्राहक तालिका। इससे स्टोरेज कम होती है और यह सुनिश्चित करता है कि यदि ग्राहक बदल जाता है, तो आपको केवल एक रिकॉर्ड को अपडेट करना होता है।
क्रियाशील निर्भरता
प्रत्येक विशेषता को प्राथमिक कुंजी पर स्पष्ट क्रियाशील निर्भरता होनी चाहिए। यदि आप निर्धारित नहीं कर सकते कि कौन सी कुंजी एक विशेषता के मूल्य को निर्धारित करती है, तो वह विशेषता उस तालिका में नहीं बैठती है। यह जांच डेटा अखंडता के लिए अत्यंत महत्वपूर्ण है।
नियम: प्रत्येक गैर-कुंजी विशेषता को कुंजी, पूरी कुंजी और केवल कुंजी के बारे में तथ्य प्रदान करना चाहिए।
🚫 बचने के लिए सामान्य त्रुटियाँ
यहां तक कि अनुभवी डिजाइनर भी विशेषताओं को परिभाषित करते समय जाल में फंस सकते हैं। नीचे सबसे आम त्रुटियाँ और उनसे बचने के तरीके दिए गए हैं।
1. व्युत्पन्न डेटा संग्रहीत करना
प्रश्नों के दौरान गणना समय बचाने के लिए गणना किए गए मानों को संग्रहीत करने के लिए आकर्षक होता है। उदाहरण के लिए, कुल मूल्य आदेश तालिका में संग्रहीत करना, जबकि इसे लाइन आइटम्स.
- जोखिम: डेटा असंगतता। यदि आइटम की कीमत बदलती है, तो ऐतिहासिक आदेश कुल मूल्य गलत हो जाता है, जब तक कि आप कुल मूल्य फ़ील्ड को भी अपडेट नहीं करते।
- समाधान: केवल मूल डेटा संग्रहीत करें। व्युत्पन्न मानों की गणना प्रश्न समय या एप्लिकेशन परत पर करें।
2. डेटा प्रकारों के बारे में उपेक्षा करना
सभी चीजों के लिए एक सामान्य स्ट्रिंग प्रकार का उपयोग करना समय बचाने का त्वरित तरीका है, लेकिन यह बाद में समस्याएं खड़ी करता है। स्ट्रिंग के रूप में संग्रहीत तारीखों को क्रमबद्ध या फ़िल्टर करने में कुशलता नहीं मिलती है। स्ट्रिंग के रूप में संग्रहीत संख्याएं गणितीय संचालन को रोकती हैं।
- सर्वोत्तम व्यवहार: क्षेत्र के अनुरूप विशिष्ट डेटा प्रकार का चयन करें। उपयोग करें
तारीख,पूर्णांक,दशमलव, याBLOBउचित रूप से।
3. अक्षर सेट के बारे में उपेक्षा करना
पाठ विशेषताओं के लिए एक परिभाषित अक्षर सेट की आवश्यकता होती है। यदि आप ASCII मानते हैं लेकिन UTF-8 इनपुट प्राप्त करते हैं, तो आप विशेष अक्षरों को खो देंगे। यह वैश्विक एप्लिकेशन के लिए महत्वपूर्ण है।
- जांचें:सुनिश्चित करें कि डेटाबेस आपके लक्षित दर्शकों के लिए आवश्यक कॉलेशन और अक्षर संकेतन का समर्थन करता है।
🚀 विशेषताओं के प्रदर्शन प्रभाव
विशेषताएं सीधे डेटाबेस इंजन द्वारा डेटा के प्राप्त करने और संग्रहीत करने के तरीके को प्रभावित करती हैं। एक विशेषता के भौतिक कार्यान्वयन के प्रदर्शन मापदंडों पर प्रभाव पड़ता है।
इंडेक्सिंग रणनीतियां
सभी विशेषताओं को इंडेक्स करने की आवश्यकता नहीं है। इंडेक्सिंग लेखन ऑपरेशन (INSERT, UPDATE, DELETE) पर ओवरहेड जोड़ती है, लेकिन पठन ऑपरेशन (SELECT) को तेज करती है।
- उच्च कार्डिनैलिटी:बहुत सारे अद्वितीय मान वाली विशेषताएं (जैसे ईमेल) इंडेक्स के लिए अच्छे उम्मीदवार हैं।
- निम्न कार्डिनैलिटी:कम अद्वितीय मान वाली विशेषताएं (जैसे लिंग या स्थिति) आमतौर पर इंडेक्स के लिए खराब उम्मीदवार हैं, जब तक कि विशिष्ट फ़िल्टरिंग संयोजनों में उपयोग न किया जाए।
स्टोरेज दक्षता
चर लंबाई वाली विशेषताएं निश्चित लंबाई वाली विशेषताओं की तुलना में स्थान बचा सकती हैं, लेकिन वे फ्रैगमेंटेशन ला सकती हैं। स्टोरेज इंजन को समझना महत्वपूर्ण है।
- निश्चित लंबाई:तेजी से प्राप्त करना, यदि डेटा छोटा है तो स्थान का बर्बाद करना।
- चर लंबाई:स्थान बचाता है, मेटाडेटा ओवरहेड के कारण थोड़ा धीमी प्राप्ति।
✅ विशेषता डिजाइन के लिए एक चेकलिस्ट
अपने ईआर आरेख को अंतिम रूप देने से पहले, इस चेकलिस्ट को देखें ताकि आपकी विशेषताओं की बल बनाए रखें।
- ☑️ क्या प्रत्येक विशेषता परमाणु है (एक ही फ़ील्ड में सूचियां नहीं हैं)?
- ☑️ क्या प्रत्येक विशेषता का एक अद्वितीय, वर्णनात्मक नाम है?
- ☑️ क्या डेटा प्रकार प्रत्याशित मान के लिए उपयुक्त है?
- ☑️ क्या सभी फ़ील्ड के लिए नलता सीमाएं परिभाषित हैं?
- ☑️ क्या व्युत्पन्न विशेषताओं को गणना के लिए हटा दिया गया है?
- ☑️ क्या कोई विशेषता नॉर्मलाइजेशन नियमों का उल्लंघन करती है?
- ☑️ क्या स्टोरेज आकार प्रत्याशित डेटा आयतन के लिए अनुकूलित है?
- ☑️ क्या विदेशी कुंजियां मातृ विशेषताओं से सही तरीके से जुड़ी हैं?
इस सूची का पालन करने से यह सुनिश्चित होता है कि आपके डेटा मॉडल का आधार मजबूत है। यह ध्यान केंद्रित करता है कि “क्या यह अभी काम करता है” से “क्या यह वर्षों तक काम करेगा” पर बदल देता है।
🔗 जटिल प्रणालियों में विशेषताओं का अंतर्क्रिया
जटिल प्रणालियों में, गुण अक्सर बहुत से संदर्भों को छूते हैं। एक ऑडिट ट्रेल को ध्यान में रखें। आपको शायद एक गुण की आवश्यकता होगी जो बताए कि किसने एक रिकॉर्ड में बदलाव किया और कब। इसे अक्सर हर टेबल पर गुणों के सेट के रूप में लागू किया जाता है (बनाया_द्वारा, बनाया_गया_समय, अद्यतन_द्वारा, अद्यतन_समय).
हालांकि इससे अतिरिक्तता जुड़ती है, लेकिन यह ट्रेसेबिलिटी के लिए जानबूझकर चुनी गई डिजाइन विधि है। इस मामले में, गुण केवल डेटा बिंदु नहीं हैं; वे सिस्टम मेटाडेटा हैं। इस जटिलता को प्रबंधित करने के लिए प्रत्येक गुण के उद्देश्य को समझना महत्वपूर्ण है।
एक और महत्वपूर्ण बात अंतरराष्ट्रीयकरण है। नाम या पते जैसे गुणों को विभिन्न प्रारूपों को संभालना होता है। एकल गुण संरचना वैश्विक उपयोगकर्ता आधार के लिए पर्याप्त नहीं हो सकती है। लचीलेपन के लिए शुरुआत में डिजाइन करना—शायद पहले नाम और अंतिम नाम के लिए अलग-अलग गुणों का उपयोग करके, एकल पूरा_नामस्ट्रिंग—के बजाय—बाद में महत्वपूर्ण रूप से रीफैक्टरिंग के प्रयास को बचा सकता है।
🛡️ सुरक्षा और गोपनीयता के मामले
गुण अक्सर संवेदनशील जानकारी रखते हैं। सुरक्षा के लिए डिजाइन करना यह पहचानने से शुरू होता है कि कौन से गुण सुरक्षा के लिए आवश्यक हैं।
- PII (व्यक्तिगत रूप से पहचाने जाने वाली जानकारी):नाम, पते और पहचान संख्याएं आराम और स्थानांतरण के दौरान एन्क्रिप्शन के लिए आवश्यक हैं।
- पहुंच नियंत्रण:कुछ गुण केवल विशिष्ट भूमिकाओं के लिए दृश्यमान होने चाहिए। आदर्श रूप से एर डायग्राम में यह नोट किया जाना चाहिए कि कौन से फील्ड संवेदनशील हैं, भले ही नियंत्रण एप्लिकेशन लेयर पर ही लागू हो।
- अनुपालन:नियम जैसे GDPR या CCPA कुछ गुणों को कितने समय तक स्टोर करने के तरीके पर प्रभाव डालते हैं। डेटा रखरखाव नीतियों (जैसे
समाप्त_होता_है_समयगुण) के समर्थन के लिए स्कीमा डिजाइन करना अनुपालन में मदद करता है।
मॉडलिंग चरण के दौरान इन मामलों को नजरअंदाज करने से बाद में महंगे सुरक्षा पैच या कानूनी मुद्दों की स्थिति बन सकती है। संवेदनशील गुणों के साथ संरचनात्मक गुणों के समान दृष्टिकोण अपनाएं।
📝 मुख्य बातों का सारांश
गुण आपके डेटाबेस का आधार हैं। उनके बिना, संबंध केवल खाली रेखाएं हैं जो खाली बॉक्स को जोड़ती हैं। अच्छी तरह से डिजाइन किए गए गुणों के सेट से यह सुनिश्चित होता है कि डेटा सटीक, कुशल और सुरक्षित है।
- परमाणुता पर ध्यान केंद्रित करें:डेटा को छोटे-छोटे और अविभाज्य रखें।
- नॉर्मलाइजेशन का सम्मान करें:अनियमितताओं को रोकने के लिए अंतरित निर्भरताओं को दूर करें।
- प्रतिबंधों को परिभाषित करें: व्यावसायिक नियमों को लागू करने के लिए डेटा प्रकारों और नॉन-नल योग्यता का उपयोग करें।
- प्रदर्शन पर विचार करें: समझदारी से इंडेक्स बनाएं और स्टोरेज प्रकारों का सावधानी से चयन करें।
- सुरक्षा के लिए योजना बनाएं: संवेदनशील डेटा को जल्दी से पहचानें।
अभिलक्षण डिजाइन के बारीकियों में समय लगाकर, आप एक डेटा मॉडल बनाते हैं जो बदलाव के प्रति लचीला होता है और संचालन में कुशल होता है। एक एर आर आर डायग्राम की शक्ति केवल इसके संबंधों में नहीं है, बल्कि उन विवरणों की सटीकता में है जो यह अंकित करता है।
