एक ऐसा परिदृश्य तैयार करना जिसमें प्रत्येक संगीत कलाकार समूह या सोलो कलाकार हो

Question

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

परिदृश्य विवरण

• एक कलाकार का एक नाम है , और या तो एक समूह या एक सोलो कलाकार होना चाहिए (लेकिन दोनों नहीं)।

• एक समूह एक या अधिक सोलो कलाकारों से बना होता है और इसमें कई सदस्य होते हैं (जिनकी गणना समूह बनाने वाले सोलो कलाकारों की संख्या से की जानी चाहिए )।

• एक एकल कलाकार कई समूहों या किसी समूह का सदस्य हो सकता है और एक या अधिक उपकरण खेल सकता है ।

सवाल

ऐसे परिदृश्य का प्रतिनिधित्व करने के लिए ERD का निर्माण कैसे करें? मैं इसके 'भाग' से भ्रमित हूँ।

Answer 1

परिदृश्य का वह हिस्सा जिसे आप उलझन में हैं, सुपरटेक-उपप्रकार ¹ संरचना नामक एक क्लासिक निर्माण के साथ मॉडलिंग की जा सकती है ।

मैं (1) कुछ प्रासंगिक प्रारंभिक विचारों का परिचय दूंगा, (2) विस्तार से कि कैसे मैं वैचारिक स्तर पर विचार करुंगा- विचाराधीन व्यावसायिक संदर्भ, और (3) अतिरिक्त संबंधित सामग्री प्रदान करता है, SQL के माध्यम से संगत तार्किक-स्तर -DDL घोषणाएँ - निम्नानुसार।

परिचय

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

सुपर-टाइप-उपप्रकार क्लस्टर दो प्रकार के हो सकते हैं:

• अनन्य । इस बारे में आता है कि जब सुपरेंटिटी प्रकार का उदाहरण हमेशा एक और केवल एक उपप्रकार समकक्ष होना चाहिए; इसलिए, प्रश्न में संभावित उपप्रकार घटनाएँ पारस्परिक रूप से अनन्य हैं । यह वह प्रकार है जो आपके परिदृश्य की चिंता करता है।

  एक विशिष्ट मामला जिसमें एक अनन्य सुपर-टाइप-सबटाइप आता है, वह एक व्यावसायिक डोमेन है जहां एक संगठन और एक व्यक्ति दोनों को कानूनी पक्ष माना जाता है , जैसे कि पदों की इस श्रृंखला में जानबूझकर की गई स्थिति ।

• कोई नहीं । खुद को प्रस्तुत करता है जब एक सुपरटाइप उदाहरण को कई उपप्रकार घटनाओं द्वारा पूरक किया जा सकता है , जिनमें से प्रत्येक को एक अलग श्रेणी का होने के लिए मजबूर किया जाता है ।

  इस तरह के सुपर-टाइप-सबटाइप का एक उदाहरण इन पदों से निपटा जाता है ।

_{नोट : यह ध्यान देने योग्य है कि सुपरटेक्-उपप्रकार संरचनाएं- एक वैचारिक चरित्र के तत्वों के कारण- विशिष्ट डेटा प्रबंधन सैद्धांतिक ढांचे से संबंधित नहीं हैं, यह संबंधपरक, नेटवर्क या पदानुक्रम है - जिनमें से वैचारिक तत्वों का प्रतिनिधित्व करने के लिए विशेष संरचनाएं प्रदान की जाती हैं-।}

_{यह इंगित करना भी उचित है कि हालांकि सुपर-टाइप-उपप्रकार क्लस्टर ऑब्जेक्ट-ओरिएंटेड एप्लिकेशन प्रोग्रामिंग (OOP) वंशानुक्रम और बहुरूपता के लिए एक निश्चित समानता रखते हैं, वे वास्तव में अलग-अलग डिवाइस हैं क्योंकि वे विभिन्न उद्देश्यों की सेवा करते हैं। एक डेटाबेस में वैचारिक मॉडल - वास्तविक दुनिया के पहलुओं का प्रतिनिधित्व करना चाहिए - सूचनात्मक आवश्यकताओं का वर्णन करने के लिए संरचनात्मक सुविधाओं के साथ एक सौदा होता है , जबकि अन्य चीजों के अलावा, ओओपी बहुरूपता और विरासत में, एक (ए) रेखाचित्र और (ख) कम्प्यूटेशनल और व्यवहार संबंधी विशेषताओं को लागू करता है। , पहलू जो निश्चित रूप से एप्लायंस प्रोग्राम डिजाइन और प्रोग्रामिंग से संबंधित हैं।}

_{इसके अलावा, एक व्यक्ति ओओपी वर्ग - एक आवेदन कार्यक्रम घटक- के अनुसार, जरूरी नहीं कि वह "दर्पण" एक व्यक्तिगत इकाई प्रकार की संरचना है जो हाथ में डेटाबेस के वैचारिक स्तर से संबंधित है। इस संबंध में, एक एप्लिकेशन प्रोग्रामर आम तौर पर, एक एकल वर्ग बना सकता है, जो दो (या अधिक) सभी गुणों को अलग-अलग वैचारिक-स्तर की इकाई प्रकारों को "संयोजित" करता है, और इस तरह के वर्ग में संगणित गुण भी शामिल हो सकते हैं।}

सुपरटेप-सबटाइप संरचनाओं के साथ एक वैचारिक मॉडल का प्रतिनिधित्व करने के लिए इकाई-संबंध निर्माण का उपयोग करना

आपने एक इकाई-संबंध आरेख (संक्षिप्तता के लिए ईआरडी) के लिए कहा, लेकिन, एक असाधारण मॉडलिंग प्लेटफॉर्म होने के नाते, डॉ। पीटर पिन-शान चेन ² द्वारा पेश की गई मूल विधि - तरह के परिदृश्यों का प्रतिनिधित्व करने के लिए पर्याप्त निर्माण की आपूर्ति नहीं की। सटीक डेटाबेस वैचारिक मॉडल की आवश्यकता है कि सटीकता के साथ चर्चा की।

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

अपनी रुचि के संदर्भ में मॉडलिंग करना

चित्र 1 में दिखाया गया चित्रण एक ईईआरडी है (रमैज ए। अल्मासरी और शमकांत बी। नवाथे ³ द्वारा प्रस्तावित प्रतीकों के समान का उपयोग करते हुए , जो ऐसी संरचनाओं को सुपरक्लास / उपवर्ग के रूप में संदर्भित करते हैं ) जहां मैंने आपके द्वारा वर्णित व्यवसाय डोमेन का मॉडल तैयार किया है। विशेष विवरण। यह एक पीडीएफ के रूप में भी उपलब्ध है जिसे ड्रॉपबॉक्स से डाउनलोड किया जा सकता है ।

आप ऊपर उल्लिखित चित्र में देख सकते हैं, दोनों Groupऔर SoloPerformerके रूप में प्रदर्शित कर रहे हैं विशेष के उपप्रकार Artistsuperentity के प्रकार:

आरेख विवरण

ईईआरडी के विवरण को शुरू करने के लिए, यह इंगित करना महत्वपूर्ण है कि आपका वाक्य

• "एक कलाकार होना चाहिए या तो एक समूह या एक SoloPerformer (लेकिन दोनों)"

से संबंधित है disjointness और पूर्णता हाथ में महाप्रकार-उप प्रकार क्लस्टर के पहलुओं।

Disjointness

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

जब एक सुपरपाइप को एक या अधिक संभव उपप्रकारों द्वारा पूरक किया जा सकता है, तो यह बिंदु एक छोटे सर्कल द्वारा "ओ" अक्षर के साथ एक लेबल पकड़े हुए व्यक्त किया जाना चाहिए, जो ओवरलैप नियम कहलाता है ।

भेदभाव करने वाला गुण

इसके अलावा के दायरे के भीतर disjointness इस महाप्रकार-उप प्रकार संघ के कारक है, यह की ओर ध्यान रखते लायक है Artist.Typeयह उप-प्रकार के रूप में कार्य करता है: संपत्ति है, क्योंकि यह इस व्यवस्था में एक बहुत ही प्रासंगिक कार्य किया जाता है discriminator । इसे इस तरह से नामित किया गया है क्योंकि यह वह संपत्ति है जो अनन्य प्रकार के उपप्रकार को इंगित करता है जिसके साथ एक विशिष्ट उदाहरण Artistसंबंधित है।

कोई भी प्रशंसनीय समूहों के मामलों में , एक भेदभावपूर्ण संपत्ति का उपयोग अनावश्यक है, एक निश्चित सुपरटेप के लिए कई उपप्रकार हो सकते हैं जैसे कि पूरक (जैसा कि ऊपर लाया गया है)।

कुल विशेषज्ञता नियम और पूर्णता

आवश्यकता यह है कि प्रत्येक Artistको हमेशा एक पूरक उपप्रकार उदाहरण होना चाहिए जो इस क्लस्टर की पूर्णता विशेषता के साथ करना है। यह कुल विशेषज्ञता नियम के माध्यम से चित्रित किया गया है , Artist(ए) के असमान नियम निर्माण को जोड़ने (ए) के साथ सुपर-टाइप को जोड़ने वाली डबल-लाइन प्रतीक के माध्यम से प्रदर्शित किया गया है।

सोलो कलाकारों के साथ संबंधित समूह

वाक्यों का मूल्यांकन

• "एक समूह एक या एक से अधिक SoloPerformers से बना है "

तथा

• “एक सोलोपरफॉर्मर कई समूहों का सदस्य हो सकता है या किसी समूह का ",

एक पहचान सकता है कि दोनों उपप्रकार में शामिल हैं कई-से-कई (एम: एन) एसोसिएशन (या संबंध) में शामिल हैं, जिन्हें मैंने हीरे के आकार के बॉक्स के साथ लेबल के रूप में दर्शाया था Group-SoloPerformer।

यदि बेस टेबल के रूप में एक रिलेशनल डेटाबेस में कार्यान्वित किया जाता है , तो यह घटक कुल प्राप्त करने के लिए बहुत उपयोगी होगा (यानी, गणना करने के लिए)Number का SoloPerformersएक ठोस ऊपर है कि मेकअप Group(आवश्यकताओं आपके द्वारा निर्दिष्ट में से एक)।

सोलो परफॉर्मर्स और इंस्ट्रूमेंट्स के बीच का जुड़ाव

वजीफा

• "एक सोलोपरफॉर्मर [...] एक या अधिक इंस्ट्रूमेंट्स बजा सकता है"

हमें इसका उल्लेख करने की अनुमति देता है, उसी समय,

• "एक उपकरण शून्य, एक या एक से अधिक SoloPerformers द्वारा खेला जाता है।"

इस प्रकार, यह एक एम: एन एसोसिएशन का एक और उदाहरण है, और मैंने नामित हीरे के आकार का आंकड़ा इस्तेमाल किया SoloPerformer-Instrument इसे उजागर करने के लिए ।

अतिरिक्त सामग्री

सुपर-टाइप-सबटाइप संरचनाओं के दायरे को समाप्त करने के लिए मैं दो और संसाधनों को शामिल करने जा रहा हूं, अर्थात

1. एक IDEF1X ⁴ चित्र में प्रस्तुत चित्र 2 ( और आप इसे एक PDF के रूप ड्रॉपबॉक्स से डाउनलोड कर सकते हैं और साथ ही,) कि इस मुद्दे पर व्यापार डोमेन के बारे में चित्र की इस तरह की अर्थपूर्ण क्षमताओं को दिखाता है; तथा

2. संबंधित एक्सप्लोजिट डीडीएल तार्किक संरचना जो एक्सक्लूसिव है कि SQL डेटाबेस मैनेजमेंट सिस्टम के आधार पर चर्चा के तहत पूर्ण परिदृश्य को कैसे प्रबंधित किया जाए।

1. IDEF1X प्रतिनिधित्व

IDEF1X सूचना मॉडलिंग तकनीक निश्चित रूप से सीमा-उपप्रकार संरचनाओं को चित्रित करने की क्षमता प्रदान करती है, हालांकि एक सीमा के साथ: यह इंगित करने के लिए एक दृश्य तंत्र उधार नहीं देता है कि क्या एक सटीक क्लस्टर एक विशेष या गैर-विशिष्ट प्रकार का है (इसके मूल) प्रतीक केवल संवाद कर सकते हैं सभी संभावित उप-प्रकार के महत्व की पूर्ण या अपूर्ण पहचान)। सौभाग्य से, कोई व्यक्ति सूचना प्रौद्योगिकी (आईई) संकेतन को आईडीईएफ 1 एक्स मानक की वर्णनात्मक शक्ति का लाभ उठाते हुए इस सर्वोपरि पहलू को अधिक सटीक रूप से दिखाने के लिए नियोजित कर सकता है।

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

विदेशी कुंजी और सुपर-टाइप-उपप्रकार क्लस्टर

जैसा कि प्रदर्शित किया गया है, IDEF1X एक और लाभ प्रदान करता है: फॉरवर्ड डिजाइन (एफके) की परिभाषाओं को प्रदर्शित करने का साधन, प्रमुख महत्व के तत्व यदि एक चिकित्सक एक रिलेशनल डेटाबेस में सुपरटाइप-उपप्रकार एसोसिएशन का प्रतिनिधित्व करने जा रहा है ।

इस तरह की संगति को चित्रित करने के लिए, प्राइमेरी कुंजी (पीके) की संप्रभुता की संपत्ति, यानी Artist.ArtistNumber, को स्थानांतरित करना होगा Groupऔर SoloPerformer, हालांकि, इसे दो अलग-अलग भूमिका नामों को सौंपा गया है , क्रमशः, ^{5, 6} , GroupNumberऔर SoloPerformerNumberजोर देने के उद्देश्य से। अर्थ प्रत्येक subentity प्रकार के संदर्भ में संपत्ति से अवगत करा दिया।

पीके के रूप में विशेषता होने के अलावा, Group.GroupNumberऔर SoloPerformer.SoloPerformerNumberगुण एक ही समय में, फॉर्वर्ड कुंजी (एफके) के रूप में चित्रित किए गए हैं Artist.ArtistNumber, जो कि पीके प्रॉपर्टी का संदर्भ देते हैं।

इसलिए, चूंकि प्रत्येक SoloPerformerऔर Groupघटना एक सटीक उदाहरण पर अस्तित्व-निर्भर हैArtist , इसलिए ये इकाई प्रकार एक पहचान संघ में शामिल होते हैं जो पूर्ववर्ती पैराग्राफ में देरी पीके संपत्ति प्रवासन प्रक्रिया के माध्यम से प्रभावी होता है।

विदेशी कुंजी और साहचर्य इकाई प्रकार

IDEF1X आरेख एफके को चित्रित करने के लिए कार्य करता है जो प्रासंगिकता के दो सहयोगी इकाई प्रकारों के पीके की रचना करता है , GroupMemberऔर SoloPerformerInstrument; पहला एक दो उपप्रकारों को जोड़ता है, और दूसरा एक उपप्रकार एक स्वतंत्र इकाई प्रकार के साथ जोड़ता है, अर्थात Instrument।

2. एक्सपोजर एसक्यूएल-डीडीएल तार्किक घोषणाएं

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

संबंधपरक प्रतिमान के कई लाभों में से एक यह है कि यह अपनी प्राकृतिक संरचना में जानकारी का प्रतिनिधित्व करने की अनुमति देता है, और रिलेशनल सिद्धांत में प्रस्तावित प्रणालियों के सबसे लोकप्रिय सन्निकटन विभिन्न SQL डेटाबेस प्रबंधन सिस्टम हैं।

तो, अंत में, यहाँ कुछ नमूने DDL स्टेटमेंट्स हैं - ( बी ) बेस टेबल स्कीमास के साथ-साथ (बी) कुछ अड़चनों के कारण- जो कि अमूर्तता के तार्किक स्तर पर प्रतिनिधित्व करते हैं, वैचारिक मॉडलिंग व्यायाम ऊपर इलाज किया जाता है।

--
--
CREATE TABLE Artist ( -- Stands for the supertype.
    ArtistNumber    INT      NOT NULL,
    Name            CHAR(30) NOT NULL,
    Type            CHAR(1)  NOT NULL, -- Holds the discriminator values.
    CreatedDateTime DATETIME NOT NULL,
    --
    CONSTRAINT Artist_PK      PRIMARY KEY (ArtistNumber),
    CONSTRAINT Artist_AK      UNIQUE      (Name), -- ALTERNATE KEY.
    CONSTRAINT Artist_Type_CK CHECK       (Type IN ('G', 'S')) -- Enforces retaining either ‘G’, for ‘Group’, or ‘S’, for ‘SoloPerformer’, only.
);

CREATE TABLE MyGroup ( -- Represents one subtype.
    GroupNumber   INT  NOT NULL, -- To be constrained as PK and FK simultaneously.
    FormationDate DATE NOT NULL,
    --
    CONSTRAINT MyGroup_PK         PRIMARY KEY (GroupNumber),
    CONSTRAINT MyGroupToArtist_FK FOREIGN KEY (GroupNumber)
        REFERENCES Artist (ArtistNumber)  
);

CREATE TABLE SoloPerformer ( -- Denotes the other subtype.
    SoloPerformerNumber INT  NOT NULL, -- To be constrained as PK and FK simultaneously.
    BirthDate           DATE NOT NULL,
    --
    CONSTRAINT SoloPerformer_PK               PRIMARY KEY (SoloPerformerNumber),
    CONSTRAINT SoloPerformerNumberToArtist_FK FOREIGN KEY (SoloPerformerNumber)
        REFERENCES Artist (ArtistNumber)  
);

CREATE TABLE GroupMember ( -- Stands for a M:N association involving the two subtypes.
    MemberNumber INT  NOT NULL,
    GroupNumber  INT  NOT NULL,
    JoinedDate   DATE NOT NULL,
    --
    CONSTRAINT GroupMember_PK                PRIMARY KEY (MemberNumber, GroupNumber), -- Composite PK.
    CONSTRAINT GroupMemberToSoloPerformer_FK FOREIGN KEY (MemberNumber)
        REFERENCES SoloPerformer (SoloPerformerNumber),
    CONSTRAINT GroupMemberToMyGroup_FK       FOREIGN KEY (GroupNumber)
        REFERENCES MyGroup       (GroupNumber)  
);

CREATE TABLE Instrument ( -- Represents an independent entity type.
    InstrumentNumber INT      NOT NULL,
    Name             CHAR(30) NOT NULL,
    --
    CONSTRAINT Instrument_PK PRIMARY KEY (InstrumentNumber),
    CONSTRAINT Instrument_AK UNIQUE      (Name) -- ALTERNATE KEY.  
);

CREATE TABLE SoloPerformerInstrument ( -- Denotes another M:N association, in this case between a subtype and an independent entity type.
    SoloPerformerNumber INT  NOT NULL,
    InstrumentNumber    INT  NOT NULL,
    CreatedDate         DATE NOT NULL,
    --
    CONSTRAINT SoloPerformerInstrument_PK                PRIMARY KEY (SoloPerformerNumber, InstrumentNumber), -- Composite PK.
    CONSTRAINT SoloPerformerInstrumentToSoloPerformer_FK FOREIGN KEY (SoloPerformerNumber)
        REFERENCES SoloPerformer (SoloPerformerNumber),
    CONSTRAINT SoloPerformerInstrumentToInstrument_FK    FOREIGN KEY (InstrumentNumber)
        REFERENCES Instrument    (InstrumentNumber)  
);
--
--

डेटा अखंडता और स्थिरता विचार

पहले बताए गए सभी के साथ समझौते में, डिजाइनर को यह गारंटी देनी चाहिए कि प्रत्येक "सुपरटाइप" पंक्ति हर समय उसके "उपप्रकार" समकक्ष के साथ पूरक है और बदले में, सुनिश्चित करें कि "सबटाइप" पंक्ति मान के साथ संगत है। सुपरस्क्रिप्ट "विभेदक" कॉलम में निहित है।

यह कहा जा सकता है कि परिस्थितियों को घोषित रूप से लागू करने के लिए बहुत व्यावहारिक और सुरुचिपूर्ण होगा (जैसा कि संबंधपरक ढांचे का प्रस्ताव है) लेकिन, अफसोस, प्रमुख एसक्यूएल प्लेटफार्मों में से किसी ने भी ऐसा करने के लिए उपयुक्त तंत्र प्रदान नहीं किया है (जहां तक ​​मुझे पता है)। इसलिए, ACID परिवहन को नियोजित करना बहुत सुविधाजनक है ताकि ये शर्तें हमेशा एक डेटाबेस में मिलें (अन्य विकल्प TRIGGERS का उपयोग करने के लिए होगा, लेकिन वे चीजों को बेकार कर देते हैं)।

डेटा व्युत्पत्ति विचार

संबंधपरक मॉडल का एक मुख्य पहलू यह है कि यह डेटा व्युत्पत्ति को डेटा प्रबंधन में सर्वोपरि कारक मानता है । अनुसार, यह (क) बनाने की सुविधा आधार संबंधों -या आधार एसक्यूएल में तालिकाओं, के रूप में DDL बयान के ऊपर और में दिखाया गया है (ख) व्युत्पन्न संबंधों - व्युत्पन्न एसक्यूएल, यानी में टेबल, उन का चयन आपरेशन के सहारे हो सकता है कि द्वारा घोषित आगे के शोषण के लिए विचारों के रूप में तय किया गया-

इसलिए, कोई व्यक्ति "पूर्ण" समूह डेटा बिंदुओं को देखने वाला एक दृश्य घोषित कर सकता है :

CREATE VIEW FullGroup AS
    SELECT G.GroupNumber,
           A.Name,
           A.CreatedDateTime,
           G.FormationDate
         FROM Artist A
         JOIN MyGroup G 
           ON G.GroupNumber = A.ArtistNumber;

और अन्य दृश्य जो सूचना के "पूर्ण" सोलोफॉर्मर टुकड़ों को जोड़ती है :

CREATE VIEW FullSoloPerformer AS
    SELECT SP.SoloPerformerNumber,
            A.Name,
            A.CreatedDateTime,
           SP.BirthDate
         FROM Artist A
         JOIN SoloPerformer SP 
           ON SP.SoloPerformerNumber = A.ArtistNumber;

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

---

संदर्भ

_{¹ कोड, ईएफ (दिसम्बर 1979)। अधिक अर्थ कैप्चर करने के लिए डेटाबेस रिलेशनल मॉडल का विस्तार करना , डेटाबेस सिस्टम पर एसीएम ट्रांजेक्शंस , वॉल्यूम 4 अंक 4 (पीपी। 397,344)। न्यूयॉर्क, एनवाई, यूएसए।}

_{² चेन, पीपी (मार्च 1976)। इकाई-संबंध मॉडल- डेटा के एकीकृत दृश्य के लिए , डेटाबेस सिस्टम पर ACM लेनदेन - विशेष मुद्दा: बहुत बड़े डेटा मामलों पर अंतर्राष्ट्रीय सम्मेलन से पत्र: 22-22 सितंबर, 1975, फ्रामिंघम, एमए , खंड 1 अंक (पीपीपी) । 9-36)। न्यूयॉर्क, एनवाई, यूएसए।}

_{³ एल्माश्री, आर एंड नवथे, एसबी (2003)। डेटाबेस सिस्टम का फंडामेंटल , चौथा संस्करण। Addison-Wesley Longman Publishing Co., Inc. बोस्टन, MA, संयुक्त राज्य अमेरिका।}

_{⁴ राष्ट्रीय मानक और प्रौद्योगिकी संस्थान (यूएस) [एनआईएसटी] (दिसंबर 1993)। सूचना मॉडलिंग (IDEF1X), संघीय सूचना प्रसंस्करण मानक प्रकाशन , वॉल्यूम 184 के लिए एकीकरण परिभाषा । यूएसए।}

_{⁵ कॉड, ईएफ (जून 1970)। बड़े साझा डेटा बैंकों के लिए डेटा का एक संबंधपरक मॉडल , एसीएम के संचार , वॉल्यूम 13 अंक 6 (पीपी 377-387)। न्यूयॉर्क, एनवाई, यूएसए।}

_{⁶ संदर्भ ⁴ देखें}

Answer 2

MDCCL द्वारा उत्तर आकर्षक, शैक्षिक और संभवतः सही है (हालांकि मेरे पे-ग्रेड से ऊपर)।

इसके विपरीत, मैंने प्रश्न की फिर से व्याख्या की और सरलतम संभव समाधान के लिए मूल बातें पर वापस चला गया। शायद मैं धोखा दे रहा हूं और सही मायने में इस सवाल का जवाब नहीं दे रहा हूं ... लेकिन यहां वैसे भी जाता है।

प्रश्न पढ़ते और पढ़ते समय मैं भ्रमित था। "कलाकार" शब्द को देखते समय मैं अलग-अलग लोगों के बारे में सोचता रहा। लेकिन नहीं, यह "कलात्मक ब्रांड लेबलिंग" के अर्थ में है, जैसे संगीत रिकॉर्ड एल्बम में एक शीर्षक और "कलाकार" होता है, चाहे कलाकार जॉनी कैश की तरह एक व्यक्ति हो या द क्योर जैसा समूह हो ।

आइए एक उदाहरण के रूप में अब कलाकार को राजकुमार के रूप में जाना जाता है । उन्होंने एल्बम इस प्रकार प्रकाशित किए हैं:

• राजकुमार
• राजकुमार और क्रांति
• प्रिंस एंड न्यू पावर जेनरेशन
• [ कस्टम प्रतीक ]

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

इसलिए, हम वेंडी और लिसा के साथ "कलाकार" का एक और उदाहरण होगा, जबकि मेल्विन और कोलमैन प्रत्येक व्यक्ति कलाकार होंगे लेकिन "कलाकार" नहीं। उन व्यक्तिगत महिलाओं को दो "कलाकारों" ((1) राजकुमार और क्रांति , (2) वेंडी और लिसा ) के कलाकार के रूप में सौंपा जाएगा ।

निम्नलिखित चित्र एक कॉम्पैक्ट फैशन में इस उदाहरण डेटा को दिखाने का एक अनाड़ी प्रयास है। हम दो अलग-अलग बैंड (कलाकारों) से संबंधित दो रेखांकित महिलाओं (कलाकारों) को दिखाते हैं। और हम इटैलिकाइज़्ड आदमी को दिखाते हैं, प्रिंस, जो चार बैंड (कलाकार) से संबंधित है, लेकिन अंतिम बैंड (कलाकार) से संबंधित नहीं है ।

यदि वह व्यवसाय डोमेन का वर्णन करता है, तो मैं निम्नलिखित तालिका डिजाइन (और ईआरडी) का प्रस्ताव करूंगा।

मूल रूप से हमारे पास कई-कई-कई रिश्तों की एक जोड़ी है:

• एक कलाकार (चाहे एकल या एक बैंड) एक या एक से अधिक कलाकारों को सौंपा गया हो। और एक कलाकार एक या अधिक "कलाकार" / बैंड का सदस्य हो सकता है।
• एक कलाकार एक या अधिक उपकरण खेल सकता है। और प्रत्येक इंस्ट्रूमेंट में कई कलाकार हो सकते हैं जो इसे खेलने में सक्षम हैं।

"समूह" और "सोलोपरफॉर्मर" के लिए:

• एक "सोलो" केवल एक "कलाकार" को सौंपा गया कोई "कलाकार" है।
  (सदस्यता तालिका में केवल एक बच्चे का रिकॉर्ड है कि आर्टिस्ट की आईडी को विदेशी कुंजी के रूप में सौंपा गया है।)
• एक "समूह" किसी भी "कलाकार" को एक से अधिक "कलाकार" को सौंपा गया है।
  (सदस्यता तालिका में दो या अधिक बच्चों के रिकॉर्ड में आर्टिस्ट की आईडी को विदेशी कुंजी के रूप में निर्दिष्ट किया गया है।)

यदि व्यावसायिक तर्क का एक हिस्सा सोलो बनाम समूह वाले कलाकार आइटमों के बीच अंतर करना है, तो हम SQL में उन कलाकार पंक्तियों के लिए प्रश्न कर सकते हैं जिनकी केवल एक पंक्ति सदस्यता तालिका बनाम जिसमें एकाधिक हैं। लेकिन व्यावहारिक रूप से, यह संभवतः इस जानकारी को निरूपित करने के लिए समझ में आता है:

• आर्टिस्ट टेबल पर "सोलो / ग्रुप" बुलियन जोड़ना, और ...
• इस एकल / एकाधिक सदस्यता को ऐप में लागू करें।

यदि प्रश्न का लक्ष्य डेटाबेस संरचना (या ईआरडी) के भीतर इस सोलो बनाम समूह भेद को लागू करना था, तो मैं असफल रहा। लेकिन किसी भी तरह से, मुझे उम्मीद है कि यह उत्तर दिलचस्प और उपयोगी साबित हो सकता है।

Comments

बहुत अच्छा परिप्रेक्ष्य

— Pmpr

Answer 3

एमडीसीसीएल का उत्तर ईईआरडी स्तर पर दर्शाए गए अनुसार सुपरक्लास / उपवर्ग या सामान्यीकरण / विशेषज्ञता के पीछे की अवधारणाओं का एक शानदार सारांश है।

इस उत्तर का उद्देश्य तीन डिज़ाइन पैटर्न या तकनीकों को इंगित करना है जो यह जानने के लायक हैं कि ईईआरडी को एक रिलेशनल डिज़ाइन में कैसे परिभाषित किया जाए, जो परिभाषित स्तंभों के साथ परिभाषित तालिकाओं पर आधारित है।

यहाँ तीन हैं:

• सिंगल क्लास इनहेरिटेंस
• कक्षा तालिका वंशानुक्रम
• प्राथमिक कुंजी साझा की

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

साझा प्राथमिक कुंजी एक तकनीक है जिसके द्वारा उपवर्ग तालिकाओं में प्रविष्टियाँ सुपरक्लास तालिका में संबंधित प्रविष्टि की पहचान "विरासत" द्वारा एक पहचान प्राप्त कर सकती हैं।

SO पर, इन नामों के साथ तीन टैग हैं। प्रत्येक टैग के तहत जानकारी टैब एक विवरण प्रदान करता है, और टैग के तहत कई सवाल हैं।

बहुत सारी वेब साइटें भी हैं जो इन तकनीकों को प्रस्तुत करती हैं। मैं मार्टिन फाउलर से सलाह लेता हूं। मुझे उसके प्रस्तुत करने का तरीका पसंद है। यहाँ कुछ वेब पेज हैं:

सिंगल टेबल इनहेरिटेंस क्लास टेबल इनहेरिटेंस