सामान्य ईआर आरेख गलतियाँ

जानें कि ईआर (इकाई संबंध) आरेख, इसके भाग, और इसे बनाते समय अक्सर क्या गलत होता है।

क्या आपने कभी रिलेशनल डेटाबेस मॉडल बनाया है? या हो सकता है कि आप अपना पहला बनाने की कोशिश कर रहे हों? आप जानते हैं (या आपको जल्द ही पता चल जाएगा) कि वास्तविक दुनिया की समस्याओं को डेटाबेस लॉजिक में अनुवाद करना कभी-कभी काफी कठिन हो सकता है।

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

तो, आइए देखें कि ईआर आरेख क्या है और हम इसकी सामान्य गलतियों से कैसे बच सकते हैं।

ईआर आरेख क्या है?

"ईआर आरेख", या ईआरडी, इकाई संबंध आरेख के लिए संक्षिप्त है। यह मॉडलिंग की जाने वाली समस्या का मानचित्रण करता है, लेकिन एक संरचित तरीके से जो संस्थाओं के बीच संबंधों को दर्शाता है।

एक ईआर आरेख के बिल्डिंग ब्लॉक्स

ईआर आरेखों में निम्नलिखित तत्व होते हैं:

• इकाई
• रिश्ते
• इकाई या संबंध विशेषताएँ

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

एक बार हमारे पास इकाइयाँ हो जाने के बाद, रिश्ते create बनाना आवश्यक है . एक संबंध दिखाता है कि कैसे एक इकाई एक या एक से अधिक अन्य संस्थाओं से जुड़ी और जुड़ी हुई है।

ईआर आरेख का अंतिम तत्व एक इकाई या संबंध है विशेषता . एक विशेषता एक इकाई या रिश्ते से संबंधित संपत्ति का विवरण है। गुणों के मूल्य होते हैं। ऊपर बताई गई संस्थाओं के लिए कुछ विशेषताएं हो सकती हैं:

• कर्मचारी, छात्र, शिक्षक, खरीदार - आईडी, नाम, उपनाम, जन्म तिथि, पता, आदि।
• उत्पाद - आईडी, श्रेणी, विवरण, रंग, क्रमांक, आदि।
• विभाग - आईडी, विभाग का नाम, विभाग प्रमुख, कर्मचारियों की संख्या, आदि।
• भुगतान - आईडी, दिनांक और समय, राशि।
• स्थान - शहर, ज़िप कोड, क्षेत्र, देश, महाद्वीप।

संबंधों के प्रकार

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

संस्थाओं के बीच तीन प्रकार के संबंध होते हैं:

• एक-से-एक (1:1)
• एक से कई (1:एन)
• कई-से-अनेक (एम:एन)

एक-से-एक (1:1) संबंध

पहला संबंध प्रकार है एक-से-एक , या 1:1 . इस संबंध में, एक इकाई का एक उदाहरण केवल दूसरी इकाई के एक उदाहरण के साथ जोड़ा जा सकता है (और इसके विपरीत, निश्चित रूप से)।

मान लें कि हमारे पास विद्यार्थी इकाई है विशेषताओं के साथ नाम और उपनाम . हमारे पास id . इकाई भी है एकमात्र विशेषता id . के साथ . 1:1 संबंध का मतलब होगा कि एक छात्र के पास केवल एक आईडी नंबर हो सकता है। इसका मतलब यह भी है कि एक आईडी नंबर केवल एक छात्र का हो सकता है।

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

यहाँ इस संबंध का एक उदाहरण दिया गया है:

वन-टू-मैनी (1:N) संबंध

डेटाबेस संबंध का सबसे सामान्य प्रकार है एक-से-अनेक या 1:N . एक-से-अनेक संबंध का अर्थ है कि एक इकाई के प्रत्येक एकल उदाहरण को दूसरी इकाई के कई उदाहरणों से जोड़ा जा सकता है। इसका अर्थ यह भी है कि दूसरी इकाई के प्रत्येक उदाहरण को पहली इकाई के केवल एक उदाहरण से जोड़ा जा सकता है।

उदाहरण के लिए, एक इकाई है खरीदार id . विशेषताओं के साथ , नाम , और उपनाम . हम भुगतान . इकाई के साथ संबंध स्थापित करना चाहते हैं जिसमें विशेषताएं हैं id , तारीख , और मान . यह एक 1:N संबंध है क्योंकि एक खरीदार एक या अधिक भुगतान कर सकता है। हालांकि, कई खरीदारों द्वारा एक भुगतान नहीं किया जा सकता है; इसे केवल एक खरीदार ही बना सकता है।

यहाँ उदाहरण है:

इस रिश्ते को दूसरी तरफ भी देखा जा सकता है। इस स्थिति में, इसे अनेक-टू-वन . कहा जाता है या N:1 . बेशक, यह एक नए प्रकार का रिश्ता नहीं है। यह 1 के समान है:N, लेकिन इसे विपरीत दिशा से देखा जाता है।

उदाहरण के तौर पर, मान लें कि हमारे पास कर्मचारी . इकाई है id . विशेषताओं के साथ , नाम , और उपनाम . हम कर्मचारी . स्थापित करना चाहते हैं इकाई के साथ संबंध विभाग जिसमें विशेषताएं हैं id और नाम . इन दो संस्थाओं के बीच संबंध N:1 है। इसका मतलब है कि प्रत्येक कर्मचारी केवल एक विभाग में काम कर सकता है, लेकिन एक ही विभाग में कई कर्मचारी काम कर सकते हैं।

कई-से-अनेक (एम:एन) संबंध

ए अनेक-से-अनेक या एम:एन संबंध का अर्थ है कि पहली इकाई के प्रत्येक उदाहरण को दूसरी इकाई के एक से अधिक उदाहरणों से जोड़ा जा सकता है। इसका अर्थ यह भी है कि दूसरी इकाई के प्रत्येक उदाहरण को पहली इकाई के कई उदाहरणों से जोड़ा जा सकता है।

आइए देखें कि विद्यार्थी . संस्थाओं के बीच यह कैसे काम करता है और व्याख्यान . मान लें कि विद्यार्थी id . विशेषताएँ हैं , नाम , और उपनाम . इकाई व्याख्यान id . विशेषताएँ हैं और नाम . कई-से-अनेक संबंधों की व्याख्या निम्न तरीके से की जा सकती है:एक छात्र एक या अधिक व्याख्यान में भाग ले सकता है, जबकि एक व्याख्यान में एक या अधिक छात्र भाग ले सकते हैं।

यहाँ इस उदाहरण के लिए आरेख है:

डेटाबेस मॉडलिंग में, ऐसे संबंधों को आम तौर पर दो या अधिक 1:N या N:1 संबंधों में नई संस्थाओं को पेश करके विभाजित किया जाता है।

ईआर आरेख बनाते समय की जाने वाली विशिष्ट गलतियां

कई ईआर आरेख गलतियाँ इन चार श्रेणियों में से एक में फिट होती हैं:

• इकाइयों के बीच गलत संबंध
• एक इकाई के बजाय एक इकाई उदाहरण का उपयोग करना
• एक इकाई के साथ एक विशेषता को भ्रमित करना
• जटिल विशेषताएं

आइए प्रत्येक को अलग-अलग देखें।

इकाईयों के बीच गलत संबंध

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

आइए एक उदाहरण देखें। यदि आप किसी बैंक के लिए डेटाबेस बना रहे हैं, तो संभवतः आप क्लाइंट इकाई के साथ एक ईआर आरेख बनाएंगे। id . विशेषताओं वाले , नाम , और उपनाम . आपके पास खाता . नामक एक इकाई भी होगी id . विशेषताओं के साथ और टाइप करें . यदि आपके पास बैंकिंग उद्योग में अनुभव की कमी है, तो आप शायद सोचेंगे कि ग्राहक के बीच हमेशा 1:N संबंध होता है। और खाता संस्थाओं, जैसा कि नीचे दिखाया गया है।

एक बैंक में एक ग्राहक के कई खाते हो सकते हैं। हालाँकि, एक खाते का स्वामित्व केवल एक ग्राहक के पास हो सकता है। क्या यह वास्तव में सच है? शायद यह है, शायद ऐसा नहीं है। बहुत सारे बैंक संयुक्त खाते की पेशकश करते हैं जिनका उपयोग कई ग्राहक कर सकते हैं। क्या आप ऐसी सेवा प्रदान करने वाले बैंक के लिए ईआर डायग्राम बना रहे हैं? यदि बैंक संयुक्त खातों की पेशकश नहीं करता है, तो आप सही हैं:ग्राहक . के बीच संबंध और खाता 1 है:एन। हालांकि, यदि बैंक संयुक्त खातों की पेशकश करता है, तो संबंध एम:एन है।

एक निकाय के बजाय एक निकाय इंस्टेंस का उपयोग करना

एक और आम गलती एक इकाई के बजाय एक इकाई उदाहरण का उपयोग कर रही है। एक इकाई उदाहरण एक निश्चित इकाई की एक एकल घटना है - यानी एक इकाई जो वास्तव में एक बड़ी श्रेणी की विशेषता हो सकती है।

मान लें कि हम एक ऐसी कंपनी में काम करते हैं जो कुछ कर्मचारियों को मोबाइल फोन और लैपटॉप आवंटित करती है। इसलिए, हमारे डेटाबेस में, हमारे पास लैपटॉप . नामक एक इकाई होगी id . विशेषताओं के साथ और मॉडल और कर्मचारी . नामक एक इकाई id . विशेषताओं के साथ , नाम , और उपनाम , सही?

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

आप यहां उदाहरण पा सकते हैं:

किसी विशेषता को किसी निकाय के साथ भ्रमित करना

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

याद रखें, हमने संस्थाओं को ऐसी किसी भी चीज़ के रूप में परिभाषित किया है जिस पर हम डेटा एकत्र कर सकते हैं। इसे ध्यान में रखते हुए, हम देख सकते हैं कि वर्तमान कर्मचारी इकाई को दो संस्थाओं में विभाजित किया जा सकता है:कर्मचारी और विभाग , नीचे दिखाए गए रूप में।

जटिल विशेषताएं

आखिरी आम गलती जिसके बारे में हम बात करेंगे, वह है एक इकाई में एक जटिल विशेषता शामिल करना। दूसरे शब्दों में, हमारे पास एक विशेषता है जो वास्तव में अपनी इकाई होनी चाहिए ।

मान लें कि हमारे पास विद्यार्थी . नामक एक इकाई है जिसे निम्नलिखित विशेषताओं द्वारा परिभाषित किया गया है:id , नाम , उपनाम , तारीख_जन्म , पता , और परीक्षा_उत्तीर्ण . यहां, परीक्षा_उत्तीर्ण एक जटिल विशेषता है जिसमें एक से अधिक जानकारी होती है, यानी परीक्षा आईडी और तारीख और छात्र का स्कोर। इसे इस तरह छोड़ना एक गलती होगी। इसके बजाय, हमें एक नई इकाईबनाना चाहिए इस जटिल विशेषता से बाहर . नई इकाई को परीक्षाओं . नाम दिया जा सकता है और निम्नलिखित विशेषताओं से मिलकर बनता है:id , तारीख , students_id , और स्कोर .

आप यहां उदाहरण पा सकते हैं:

क्या आपको कोई उपयोगी ईआर आरेख युक्तियाँ मिलीं?

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

क्या आपके पास एक गैर-अच्छे ईआर आरेख का अपना उदाहरण है? या हो सकता है कि कुछ अन्य गलतियाँ हों जो आप अक्सर पाते हैं? कृपया मुझे टिप्पणी अनुभाग में बताएं।