Database
 sql >> डेटाबेस >  >> RDS >> Database

ईआर डेटा मॉडल का परिचय

इकाई-संबंध डेटा मॉडल , जिसे ER . भी कहा जाता है , विभिन्न डेटा मॉडलों में से एक है जिसका उपयोग आप अपने डेटा के बारे में तर्क करने के लिए कर सकते हैं।

विशेष रूप से, यह एक वैचारिक डेटा मॉडल . है , क्योंकि यह किसी विशेष कार्यान्वयन से जुड़ा नहीं है। यह लॉजिक डेटा मॉडल का काम है।

ईआर डेटा मॉडल इतना सामान्य, इतना उच्च स्तर है, कि इसे विभिन्न प्रकार के पूरी तरह से विभिन्न प्रकार के डेटाबेस द्वारा कार्यान्वित किया जा सकता है।

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

मुझे ऐसे परिदृश्य का विश्लेषण करने में मदद करने के लिए ईआर आरेख बहुत अच्छे लगते हैं जहां डेटा शामिल है।

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

ईआर मॉडल की रचना करने वाले 2 आइटम हैं:

  • इकाइयां
  • संबंध

निकाय डेटा के प्रकार होते हैं, जैसे आइटम या लोग, जिनमें सामान्य गुण होते हैं।

संबंध संस्थाओं के बीच संबंध हैं।

मैं आपको एक उदाहरण देता हूं, चलिए किताबों और उनके लेखकों के बारे में बात करते हैं। हमारे पास 2 इकाइयां हैं :

  • पुस्तक
  • लेखक

एक विशेष पुस्तक पुस्तक इकाई का एक उदाहरण है।

चूंकि हमारे पास 2 इकाइयां हैं, इसलिए हमारे पास 2 संबंध . हैं उन दोनों के बीच। एक एकल पुस्तक और लेखक इकाई के बीच का संबंध है। एक एकल लेखक और पुस्तकों की इकाई के बीच का संबंध है। अगर हम इसके बारे में सोचते हैं, तो हमारे पास है:

  • एक किताब में एक लेखक होता है
  • एक लेखक कई अलग-अलग किताबें लिख सकता है

इकाईयों के लिए विज़ुअल नोटेशन

इस सरल उदाहरण को देखते हुए, हम विज़ुअल नोटेशन को शुरू करना शुरू कर सकते हैं जो हमें हमारे परिदृश्य का ईआर डेटा मॉडल बनाने में मदद करेगा।

<ब्लॉकक्वॉट>

नोट:ईआर आरेख बनाने के कई अलग-अलग तरीके हैं। मैं उसका उपयोग करूंगा, मेरी राय में , अधिक दृश्य है और अधिक समझ में आता है।

निकायों को आयतों के रूप में दर्शाया जाता है, उनमें कुछ पाठ उनकी पहचान करने के लिए होते हैं:

संबंधों के लिए दृश्य संकेत

संस्थाओं के बीच संबंध को उसके सबसे बुनियादी रूप में, दो संबंधों को जोड़ने वाली रेखा का उपयोग करके, और संबंध के प्रकार की पहचान करने के लिए इसमें कुछ पाठ के साथ एक हीरे का प्रतिनिधित्व किया जाता है:

ध्यान दें कि मैंने 2 संबंध नहीं बनाए हैं "पुस्तक में लेखक है" और "लेखक ने पुस्तक लिखी है"। मैंने एक किताब और एक लेखक के बीच एक ही संबंध "लेखक" बनाया है।

कार्डिनैलिटीज

एक बार जब हमारा संबंध हो जाता है, तो हमें अब इसमें शामिल संख्याओं को इंगित करना चाहिए। इस समय, हमारे कई प्रश्न हैं:

  • एक किताब में कितने लेखक हो सकते हैं?
  • क्या कोई लेखक अनेक पुस्तकें लिख सकता है?
  • क्या लेखक कहलाने के लिए लेखक को कम से कम एक किताब लिखने की ज़रूरत है?
  • क्या एक किताब कई लेखकों द्वारा लिखी जा सकती है?
  • क्या कोई किताब बिना लेखक के मौजूद हो सकती है?

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

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

मैं संख्याएं पसंद करता हूं, जो चीजों को स्पष्ट करती हैं:

उपरोक्त संख्याओं का अर्थ यह है:एक पुस्तक को 1 या अधिक लेखकों द्वारा लिखा जा सकता है। n यानी जितने भी तत्व हों।

और एक लेखक ने 0 पुस्तकों (शायद यह अभी एक लिख रहा है) से लेकर अनंत पुस्तकों तक लिखा हो सकता है।

पहले को शून्य-से-अनेक संबंध . कहा जाता है . दूसरा एक-से-अनेक संबंध . है ।

हमारे पास यह भी हो सकता है:

  • एक-से-एक संबंध
  • अनेक-से-अनेक संबंध
  • शून्य से एक संबंध

विशेषताएं

प्रत्येक इकाई में एक या अधिक विशेषताएँ हो सकती हैं।

मान लें कि हम उपरोक्त संबंध का उपयोग किसी किताबों की दुकान में करेंगे। प्रत्येक लेखक का एक नाम, एक जीवनी, एक वेबसाइट URL होता है।

प्रत्येक पुस्तक का एक शीर्षक, एक प्रकाशक, प्रकाशन का एक वर्ष, एक ISBN होता है। यदि हम चाहें तो प्रकाशक एक इकाई भी हो सकता है। लेकिन हम इसे किसी पुस्तक की विशेषता के रूप में भी परिभाषित कर सकते हैं।

इस प्रकार हम उपरोक्त जानकारी का प्रतिनिधित्व कर सकते हैं:

पहचानकर्ता विशेषताएँ

संस्थाओं को एक अद्वितीय कुंजी द्वारा पहचाना जाना चाहिए। पुस्तक इकाई को विशिष्ट रूप से ISBN विशेषता द्वारा पहचाना जा सकता है। प्रत्येक पुस्तक में एक एकल ISBN होता है (यह देखते हुए कि हम किसी पुस्तक की एक प्रति नहीं, बल्कि एक पुस्तक "शीर्षक" का प्रतिनिधित्व करते हैं)।

हम प्राथमिक कुंजी विशेषताओं को उनके आधार पर पहचानते हैं:

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

इसलिए हमें एक अद्वितीय कुंजी विशेषता जोड़नी चाहिए। उदाहरण के लिए एक id विशेषता:

पहचानकर्ता विशेषताएँ कई विशेषताओं पर लागू हो सकती हैं।

उदाहरण के लिए, पासपोर्ट आईडी और लेखक देश विशिष्ट रूप से व्यक्ति की पहचान करते हैं, और id . को प्रतिस्थापित कर सकते हैं विशेषता हमने जोड़ी:

कौन सा चुनना है? यह एक बात है कि आपके आवेदन में क्या अधिक समझ में आता है। यदि हम एक किताबों की दुकान की मॉडलिंग कर रहे हैं, तो हम सभी पुस्तक लेखकों के देश और पासपोर्ट आईडी की उम्मीद नहीं कर सकते। इसलिए हम एक यादृच्छिक id का उपयोग करेंगे हम प्रत्येक लेखक को चुनेंगे और उसके साथ जुड़ेंगे।

रिलेशन एट्रिब्यूट

गुण संस्थाओं के लिए अद्वितीय नहीं हैं। संबंधों में विशेषताएँ भी हो सकती हैं।

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

लेकिन हमें अभी भी जानकारी याद आती है। हमें यह जानने की जरूरत है कि उस व्यक्ति ने किताब कब उधार ली थी, और वे इसे किस तारीख को लौटाते हैं, ताकि हम किसी विशेष पुस्तक के सभी इतिहास के बारे में जानकारी अपने पुस्तकालय में संग्रहीत कर सकें। यह जानकारी या तो पुस्तक या पाठक संस्थाओं से संबंधित नहीं है; यह संबंध से संबंधित है:

कमजोर इकाइयां

हमने ऊपर प्राथमिक कुंजी के बारे में बात की, और कैसे मदद एक इकाई की विशिष्ट पहचान करती है।

कुछ निकाय अपने अस्तित्व के लिए अन्य संस्थाओं पर निर्भर करते हैं, और उन्हें कमजोर निकाय . कहा जाता है ।

मान लीजिए हमें एक ऑनलाइन दुकान के लिए ऑर्डर मॉडल करने की आवश्यकता है।

प्रत्येक ऑर्डर के लिए, हम ऑर्डर आईडी स्टोर करेंगे, जो 1 से शुरू होता है और समय के साथ बढ़ता जाता है, तारीख और समय, और ग्राहक के बारे में जानकारी, ताकि हम जान सकें कि किसे बिल देना है और कहां भेजना है।

फिर हमें यह भी जानना होगा कि उन्होंने क्या आदेश दिया। हम एक कमजोर इकाई "ऑर्डर की गई वस्तु" बनाते हैं, जो चेकआउट के समय कार्ट में प्रत्येक आइटम का प्रतिनिधित्व करती है।

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

यह एक कमजोर इकाई है क्योंकि एक आदेशित वस्तु इकाई एक आदेश इकाई के बिना मौजूद नहीं हो सकती है।

पुनरावर्ती संबंध

एक इकाई का स्वयं के साथ एक पुनरावर्ती संबंध हो सकता है। मान लीजिए कि हमारे पास एक व्यक्ति इकाई है। हम माता-पिता-बच्चे के रिश्ते को इस तरह से मॉडल कर सकते हैं:

एक व्यक्ति के 0 से n बच्चे हो सकते हैं, एक बच्चे के 2 माता-पिता होते हैं (सरलतम परिदृश्य को देखते हुए)।

ISA संबंध

ISA का अर्थ IS-A है, और यह ER मॉडल में सामान्यीकरण को मॉडल करने का एक तरीका है।

हम इसका उपयोग समान संस्थाओं को एक समान छतरी के नीचे समूहित करने के लिए करते हैं। उदाहरण के लिए एक लेखक और एक पाठक, पुस्तकों और पुस्तकालय उदाहरण के मामले में, एक व्यक्ति इकाई का उपयोग करके सामान्यीकृत किया जा सकता है।

उन दोनों का एक नाम है, इसलिए हम नाम को व्यक्ति इकाई तक निकालते हैं, और संबंधित इकाई में लेखक या पाठक होने की ख़ासियत का प्रबंधन करते हैं:

गैर-बाइनरी संबंध

हर रिश्ता सख्ती से द्विआधारी नहीं होता है। आइए एक सबक परिदृश्य लें।

स्कूल के एक कमरे में आज 10:00 बजे एक पाठ होता है, जिसमें एक शिक्षक भौतिकी के बारे में कक्षा से बात कर रहा होता है।

इसलिए, एक पाठ दिन के किसी विशेष समय पर दिया जाता है, इसमें एक विषय, एक शिक्षक, एक कक्षा और एक कमरा शामिल होता है।

हम इसे इस तरह से मॉडल कर सकते हैं:


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. SQL में स्ट्रिंग्स को कैसे संयोजित करें

  2. जब DISTINCT <> GROUP BY

  3. एडब्ल्यूएस लोचदार बीनस्टॉक के लिए एक Django ऐप को तैनात करना

  4. अधिक लेन-देन लॉग काटना वसा

  5. सरल मानकीकरण और तुच्छ योजनाएँ — भाग 3