सर्वेक्षण, प्रश्न और उत्तर के बारे में डेटाबेस में अनावश्यक विदेशी कुंजियों को संभालने के लिए सर्वश्रेष्ठ डेटा मॉडलिंग दृष्टिकोण

Question

मैं सर्वेक्षण, सवाल और प्रतिक्रियाओं को संग्रहीत करने के लिए सर्वश्रेष्ठ संबंधपरक मॉडलिंग दृष्टिकोण पर सलाह की तलाश कर रहा हूं।

मैं देख रहा हूं कि नीचे दिए गए दोनों दृष्टिकोणों में से कौन सा सर्वोत्तम है, या दोनों में से एक वैकल्पिक दृष्टिकोण।

मेरे पास कम से कम ये इकाइयाँ हैं:

• सवाल
• सर्वेक्षण
• व्यक्ति

और कम से कम ये रिश्ते:

• प्रत्येक सर्वेक्षण में 1 या अधिक प्रश्न हैं।
• प्रत्येक प्रश्न का उपयोग 0 या अधिक सर्वेक्षणों में किया जा सकता है।
• प्रत्येक व्यक्ति 0 या अधिक सर्वेक्षण कर सकता है।

यहाँ मैं मुसीबत में चला रहा हूँ: कैसे एक व्यक्ति द्वारा किए गए सर्वेक्षण के सवालों के जवाब मॉडल के लिए।

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

दृष्टिकोण 1:

मुझे इस दृष्टिकोण के बारे में क्या पसंद नहीं है:

• survey_person_question_responseतालिका में दो विभिन्न स्तंभों कि एक सर्वेक्षण का उल्लेख है: survey_question_survey_idऔरsurvey_person_survey_id
  • survey_idइन दो स्तंभों के लिए एक पंक्ति में अलग-अलग संदर्भ होना एक त्रुटि होगी । सर्वे_क्वेस्टियन उसी सर्वेक्षण से होना चाहिए जिस व्यक्ति ने सर्वे_पर्सन में लिया था। मैं इसे लागू करने का एक अच्छा तरीका नहीं देख सकता।
• ऐसा लगता है कि मैं यहां जो कर रहा हूं वह दो रिश्तों के बीच संबंध बना रहा है। जो किसी कारण से मुझे गलत लगता है।

दृष्टिकोण 2:

दृष्टिकोण 1 से दो एफके से बचने की कोशिश करें जो समान मूल्य का उल्लेख करें ...

मुझे इस दृष्टिकोण के बारे में क्या पसंद नहीं है:

• ऐसा कोई प्रवर्तन नहीं है कि question_idऔर survey_idएफके एक वैध survey_questionजोड़ी से हैं
• ऐसा कोई प्रवर्तन नहीं है कि survey_idऔर person_idएफके एक वैध survey_personजोड़ी से हैं

किसी भी सलाह पर:

• इन दृष्टिकोणों में से एक विशिष्ट दृष्टिकोण है या नहीं
• इनमें से किसी एक के पक्ष और विपक्ष दूसरे के ऊपर पहुंचते हैं
• इस डेटा को पूरी तरह से व्यवस्थित करने का एक बेहतर तरीका

बहुत सराहना की जाएगी!

Answer 1

आपकी विशिष्टताओं के बारे में मेरी समझ के अनुसार, आपके व्यवसाय के वातावरण में एक वैचारिक-स्तर की त्रैमासिक संबंध शामिल है । इस संबंध में, आपको परिभाषित करने की आवश्यकता है:

1. संबंध प्रकार (या एसोसिएशन ) इकाई प्रकार व्यक्ति और सर्वेक्षण के बीच ;
2. सर्वेक्षण और प्रश्न के बीच संबंध प्रकार ;
3. संबंध प्रकार जो दो पूर्वोक्त संबंध प्रकारों के बीच संबंध स्थापित करता है और, परिणामस्वरूप, व्यक्ति , सर्वेक्षण और प्रश्न , अर्थात, प्रतिक्रिया (एक छोटा नाम जो व्याख्या को सरल करता है, मेरे दृष्टिकोण से) के बीच।

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

व्यापार नियम

आइए हम लागू व्यापार नियमों को थोड़ा विस्तारित करें और उन्हें निम्नलिखित तरीके से सुधारें:

• एक व्यक्ति शून्य-एक-या-कई सर्वेक्षण में पंजीकृत होता है
• एक सर्वेक्षण में शून्य-एक-या-कई व्यक्तियों का पंजीकरण हो जाता है
• एक सर्वेक्षण एक-से-कई सवालों से एकीकृत होता है
• एक प्रश्न शून्य-एक-या कई सर्वेक्षणों को एकीकृत करता है
• एक प्रश्न शून्य-एक-या कई प्रतिक्रियाएँ प्राप्त करता है
• वास्तव में एक सर्वेक्षण के संदर्भ में एक व्यक्ति द्वारा एक प्रतिक्रिया प्रदान की जाती है

एक्सपोजिटरी IDEF1X आरेख

फिर, मैं IDEF1X बनाया है ^एक चित्र है कि में प्रस्तुत किया है चित्रा 1 , जो ऊपर से तैयार व्यापार के नियम का संश्लेषण:

---

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

---

PersonSurvey संबंध

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

SurveyQuestion संबंध

मुझे लगता है कि आपके चित्र में suvery_question.question_number नामक संपत्ति (या विशेषता) का उपयोग किसी विशेष सर्वेक्षण के संबंध में दिए गए प्रश्न उदाहरण की प्रस्तुति के आदेश का प्रतिनिधित्व करने के लिए किया जाता है । आप देख सकते हैं, मैं के रूप में इस तरह की संपत्ति में निरूपित किया जाता है SurveyQuestion.PresentationOrder , और मुझे लगता है कि आपको लगता है कि (i) दो या अधिक रोकने चाहिए Question.QuestionNumber मूल्यों शेयर (ii) एक ही PresentationOrder (iii) एक ही में मूल्य SurveyQuestion घटना।

उस आवश्यकता को चित्रित करने के लिए, मैंने इस इकाई प्रकार का प्रतिनिधित्व करने वाले बॉक्स में एक समग्र ALTERNATE KEY (AK) को शामिल किया है, जिसमें गुणों के संयोजन ( सर्वेनंबर, प्रश्नावली, PresentationOrder ) शामिल है। जैसा कि आप अच्छी तरह से जानते हैं, एक मिश्रित AK को एक बहु-स्तंभ UNIQUE बाधा की सहायता से तार्किक DDL डिज़ाइन में घोषित किया जा सकता है (जैसा कि मैंने SurveyQuestionतालिका में अनुकरणीय है कि एक्सप्लॉरी डीडीएल लेआउट का एक भाग नीचे कुछ खंडों में दर्शाया गया है )।

रिस्पांस इकाई प्रकार

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

हां, आप पूरी तरह से सही हैं, यह दो भागों के दो अलग-अलग स्तंभों से संदर्भित मानों Response.SurveyNumber(या कहें, Response.SurveyId) के माध्यम से अमूर्त के तार्किक स्तर पर परिदृश्य के उस हिस्से को चित्रित करने के लिए एक त्रुटि होगी Response।

व्युत्पन्न तार्किक एसक्यूएल-डीडीएल लेआउट

-- You should determine which are the most fitting 
-- data types and sizes for all your table columns 
-- depending on your business context characteristics.

-- As one would expect, you are free to make use of 
-- your preferred (or required) naming conventions.

CREATE TABLE Person (
    PersonId        INT      NOT NULL,
    FirstName       CHAR(30) NOT NULL,
    LastName        CHAR(30) NOT NULL,
    GenderCode      CHAR(3)  NOT NULL,
    BirthDate       DATE     NOT NULL,
    CreatedDateTime DATETIME NOT NULL,
    --
    CONSTRAINT Person_PK PRIMARY KEY (PersonId),
    CONSTRAINT Person_AK UNIQUE      (
        FirstName,
        LastName,
        GenderCode,
        BirthDate
    )
);

CREATE TABLE Survey (
    SurveyNumber    INT       NOT NULL,
    Description     CHAR(255) NOT NULL,
    CreatedDateTime DATETIME  NOT NULL,
    --
    CONSTRAINT Survey_PK PRIMARY KEY (SurveyNumber),
    CONSTRAINT Survey_AK UNIQUE      (Description)
);

CREATE TABLE PersonSurvey (
    PersonId           INT      NOT NULL,
    SurveyNumber       INT      NOT NULL,
    RegisteredDateTime DATETIME NOT NULL,
    --
    CONSTRAINT PersonSurvey_PK         PRIMARY KEY (PersonId, SurveyNumber),
    CONSTRAINT PersonSurveyToPerson_FK FOREIGN KEY (PersonId)
        REFERENCES Person (PersonId),
    CONSTRAINT PersonSurveyToSurvey_FK FOREIGN KEY (SurveyNumber)
        REFERENCES Survey (SurveyNumber)
);

CREATE TABLE Question (
    QuestionNumber  INT       NOT NULL,
    Wording         CHAR(255) NOT NULL,
    CreatedDateTime DATETIME  NOT NULL,
    --
    CONSTRAINT Question_PK PRIMARY KEY (QuestionNumber),
    CONSTRAINT Question_AK UNIQUE      (Wording)
);

CREATE TABLE SurveyQuestion (
    SurveyNumber       INT      NOT NULL,
    QuestionNumber     INT      NOT NULL,
    PresentationOrder  TINYINT  NOT NULL,
    IsMandatory        BIT      NOT NULL,
    IntegratedDateTime DATETIME NOT NULL,
    --
    CONSTRAINT SurveyQuestion_PK PRIMARY KEY (SurveyNumber, QuestionNumber),
    CONSTRAINT SurveyQuestion_AK UNIQUE      (
        QuestionNumber,
        SurveyNumber,
        PresentationOrder
    ),
    CONSTRAINT SurveyQuestionToSurvey_FK   FOREIGN KEY (SurveyNumber)
        REFERENCES Survey   (SurveyNumber),
    CONSTRAINT SurveyQuestionToQuestion_FK FOREIGN KEY (QuestionNumber)
        REFERENCES Question (QuestionNumber)
);

CREATE TABLE Response (
    SurveyNumber     INT      NOT NULL,
    QuestionNumber   INT      NOT NULL,
    PersonId         INT      NOT NULL,
    Content          TEXT     NOT NULL,
    ProvidedDateTime DATETIME NOT NULL,
    --
    CONSTRAINT Response_PK                 PRIMARY KEY (SurveyNumber, QuestionNumber, PersonId),
    CONSTRAINT ResponseToPersonSurvey_FK   FOREIGN KEY (PersonId, SurveyNumber)
        REFERENCES PersonSurvey   (PersonId, SurveyNumber),
    CONSTRAINT ResponseToSurveyQuestion_FK FOREIGN KEY (SurveyNumber, QuestionNumber)
        REFERENCES SurveyQuestion (SurveyNumber, QuestionNumber)
);

Responseतालिका में दो सम्मिश्रित कुंजी चिह्न

यह, शायद, चर्चा करने के लिए सबसे महत्वपूर्ण बिंदु है: किसी दिए गए Responseपंक्ति से किए गए संदर्भ

1. SurveyQuestion.SurveyNumber, तथा
2. SurveyPerson.SurveyNumber

मूल्यों का मिलान होना चाहिए । जहां तक ​​मेरा सवाल है, इस स्थिति को घोषित रूप से लागू करने का सबसे अच्छा विकल्प दो समग्र फॉर्वर्ड कुंजी (FKs) का उपयोग करना है।

के रूप में DDL डिजाइन में दिखाया गया है, पहले FK के लिए एक संदर्भ बना रही है PersonSurveyतालिका प्राथमिक कुंजी (पी), यानी, (PersonId, SurveyNumber)और स्तंभों के आधार पर पुष्टि कर रहा है Response.PersonIdऔर Response.SurveyNumber।

दूसरा एफके SurveyQuestionटेबल पीके की ओर इशारा कर रहा है , यानी (SurveyNumber, QuestionNumber), और, तदनुसार, स्तंभों से बना है Response.SurveyNumberऔर Response.QuestionNumber।

इस तरह, Response.SurveyNumberस्तंभ काफी महत्वपूर्ण है क्योंकि यह दो अलग-अलग बाधाओं में एफके संदर्भ के हिस्से के रूप में उपयोग किया जाता है ।

इस विधि के साथ, एक डेटाबेस प्रबंधन प्रणाली-गारंटी रेफरल अखंडता से सुनिश्चित करता है

• (ए) Responseसे PersonSurvey;
• (बी) Responseसे SurveyQuestion; तथा
• (ग) स्वतंत्र इकाई प्रकार, अर्थात् Person, Surveyऔर के लिए खड़े तालिकाओं के लिए एक सहयोगी इकाई प्रकार का प्रतिनिधित्व करने वाले तालिकाओं में से प्रत्येक Question।

अद्यतन विसंगतियों से बचने के लिए व्युत्पन्न डेटा

मैंने आपके चित्र दो तत्वों पर ध्यान दिया है जिन्हें मैं सम्मान देता हूं। ये तत्व दो PersonSurveyस्तंभों से संबंधित हैं जो व्युत्पन्न किए जा सकते हैं (चाहिए) ।

इस संबंध में, PersonSurvey.IsStartedयदि आप किसी दिए Personगए एक या अधिक Responsesको तालिका के माध्यम से Questionsसटीक रूप Surveyसे एकीकृत करने के लिए प्रदान करते हैं, तो आप क्वेरी द्वारा डेटम प्राप्त कर सकते हैं SurveyQuestion।

और अगर आप भी प्राप्त कर सकते हैं PersonSurvey.IsCompletedयदि किसी विशेष का निर्धारण करके डेटा बिंदु Personउदाहरण एक की आपूर्ति की है Responseसभी के लिए Questionsहै कि में 'TRUE' के एक मूल्य cointain IsMandatoryएक विशिष्ट में स्तंभ SurveyQuestionपंक्ति।

इन मूल्यों की व्युत्पत्ति के माध्यम से, आप कुछ अद्यतन विसंगतियों को रोक रहे हैं जो अंततः आपके द्वारा SurveyQuestionस्तंभ में ऐसे मान रखे जाने की स्थिति में उत्पन्न होंगे ।

महत्वपूर्ण विचार

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

Comments

वाह, यह पूरी तरह से मेरे सिर में सवाल का जवाब दिया और फिर मुझे और अधिक सिखाया! चूंकि टिप्पणियों में सुधार का सुझाव देना चाहिए: यह थोड़ा भ्रमित था कि चाबियाँ दोनों के साथ समाप्त हो गईं IDऔर Number, लेकिन अन्यथा यह शानदार है। धन्यवाद।

— Zach Mierzejewski

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

— एमडीसीसीएल

Answer 2

यह एक कारण है कि जब मैं उन्हें विदेशी कुंजियों के रूप में माइग्रेट कर रहा हूं तो कॉलम को उपसर्ग करना पसंद नहीं करता। आपके पहले मामले में, मॉडलिंग टूल आपको तालिका के किसी एक survey_idकॉलम को उपसर्ग करने के लिए मजबूर कर सकता है survey_person_question_response। संबंध बनाने के बाद आप इसे समायोजित करने में सक्षम हो सकते हैं।

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

Comments

अंतर्दृष्टि के लिए धन्यवाद - मैंने भौतिक मॉडल में 1 कॉलम तक ढह गया था जो मेरे द्वारा वांछित सभी चीजों को लागू करता है।

— 23