ईआर डायग्राम का महत्व

Question

मैं एक छात्र हूं और मैं अपनी शिक्षा के एक हिस्से के रूप में कई परियोजनाओं का विकास कर रहा हूं।

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

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

अब, मैं डेटाबेस सिद्धांतों का सख्त अनुयायी हूं। मुझे लगता है कि डेटाबेस को केवल ईआरडी से विकसित किया जाना चाहिए। तो, मैं सिर्फ निम्नलिखित जानना चाहता हूं:

• क्या उद्योग इन सिद्धांतों का पालन कर रहा है?
• क्या मैं सिर्फ ईआरडी विकसित करने पर अपना समय बर्बाद कर रहा हूं?
• ईआरडी विकसित करने के क्या लाभ हैं?

Comments

ईआर / ईईआर आरेख संस्थाओं के बीच अंतर्संबंधों को दर्शाता है और यह सिस्टम फंक्शनलिस्टों को भी बढ़ाता है।

यदि आप SQL सर्वर के लिए एक ERD बनाने के लिए एक नि: शुल्क उपकरण चाहते हैं ... जानकारी यहाँ मिल सकती है ... facebook.com/DataModelerTool या यहाँ ... plus.google.com/108968161662966473138

— कार्टर मेडलिन

IMHO, ERD सब कुछ महत्वपूर्ण नहीं पकड़ता है - समय के साथ संबंधों में परिवर्तन, लेन-देन की मात्रा, ऑब्जेक्ट मॉडल सिस्टम में विरासत, "रिश्ते" आदि बन जाते हैं। विशेष रूप से, ERD का कारक सभी क्रियाओं को पूरा करता है, डेटाबेस डिजाइन में बड़े अंतराल को छोड़ देता है। संज्ञाओं के अलावा एक उपन्यास को पढ़ने की कल्पना करें। मुझे लगता है कि वे उपयोगी उपकरण हैं, लेकिन निश्चित रूप से महत्वपूर्ण नहीं है, सबसे अच्छा दोपहर के भोजन के बाद नैपकिन की पीठ पर तैयार किया गया है।

— पूजो-लड़का

Answer 1

सादा और सरल, एक ईआरडी के बिना एक इमारत योजना के बिना एक घर बनाने के रूप में एक डेटाबेस विकसित करने के बारे में सोचें। यह उल्लेखनीय हो सकता है क्योंकि आपको लगता है कि बस एक ईंट एक दूसरे के ऊपर रखना कुछ बनाने के लिए पर्याप्त है, हालांकि जिस पल में कोई और परियोजना की जिम्मेदारी लेता है, उसमें आपदा संभावित है।

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

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

Comments

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

— एके

"निर्माण योजना" का उद्देश्य विकास प्रक्रिया या परियोजना को स्वयं को सीमांकित करना नहीं है, बल्कि हमेशा उस राज्य का अवलोकन प्रदान करना है जिसमें वर्तमान परियोजना है। कोई भी वास्तव में नई संस्थाओं या रिश्तों को जोड़ने से किसी को नहीं रोक रहा है (इसलिए योजना में बदलाव कर रहा है) लेकिन दूसरों को उन परिवर्तनों के बारे में भी जानना होगा।

— brezanac

Answer 2

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

Answer 3

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

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

मेरे पास कंपनी है और हम ERD डिज़ाइन करते हैं, कभी भी ERD के बिना डेटाबेस के बारे में नहीं सोचते। (वास्तव में यह मेरा अपना निजी प्रयोग है)

Answer 4

ईआरडी कुछ समय पहले अधिक मुख्यधारा हुआ करते थे। IMO अब वे कमोबेश वैकल्पिक हैं।

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

ईआरडी संचार का एक अच्छा तरीका है, ज़ाहिर है, लेकिन किसी भी तरह से या सभी परिस्थितियों में सबसे अच्छा नहीं है। कुछ टीम प्रलेखन और संचार के अन्य तरीकों को पसंद करती हैं।

इस उद्योग में कोई कंबल नियम नहीं हैं।

Comments

+1 लेकिन डेटाबेस के संबंध में अन्य तरीके ओड डॉक्यूमेंटेशन और कम्युनिकेशन का उपयोग किस प्रकार किया जाता है?

— चमत्कार 173

@ miracle173 एक अच्छी पुस्तक है: "चुस्त सिद्धांत, पैटर्न और अभ्यास # सी # में"। इसके अलावा मुझे दान नॉर्थ द्वारा व्यवहार विकास पर लेख dannorth.net

— AK

आपका क्या मतलब है some teams prefer other ways? मुझे लगता है कि यह बहुत सारे डाउन वोटों के साथ समाप्त हो सकता था। यदि स्टैकओवरफ्लो पर एक उत्तर के रूप में पोस्ट किया गया था!

— पम्प्र

Answer 5

उत्पादन कोड लिखने से पहले डिजाइन करना महत्वपूर्ण है। यह प्रोटोटाइप के लिए भी महत्वपूर्ण है; डेटाबेस लोग SQL लिखकर प्रोटोटाइप विकसित करते हैं। (याद रखें कि फ्रेड ब्रुक्स ने प्रोटोटाइप के बारे में क्या कहा था?)

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

वे डेवलपर्स के अलावा बहुत प्रभावी संचार उपकरण साबित नहीं हुए हैं। लेकिन डेटाबेस डिजाइनिंग में, महत्वपूर्ण संचार डेवलपर्स के बीच नहीं है; यह डेवलपर्स और डोमेन विशेषज्ञों (डेवलपर्स और व्यवसाय के लोगों के बीच) के बीच है।

ऑब्जेक्ट-रोल मॉडलिंग (ORM) की एक ग्राफिकल भाषा है, लेकिन यह "तथ्यों" (सरल वाक्य) पर आधारित है। कारोबारी लोग तथ्यों को बहुत आसानी से मान्य कर सकते हैं। कारोबारी लोग ईआर आरेख या ओआरएम आरेख को आसानी से मान्य नहीं कर सकते हैं ।

Comments

+1 लेकिन क्या आप ज्ञान संबंधी आंकड़े या अध्ययन करते हैं, जो ग्राफिकल भाषाओं का उपयोग करके संचार की समस्याओं के बारे में आपके दावों का समर्थन करते हैं?

— चमत्कार 173

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

— माइक शेरिल 'कैट रिकॉल'