Saya mencari saran tentang pendekatan pemodelan relasional terbaik untuk menyimpan survei, pertanyaan, dan tanggapan.

Saya mencari yang mana dari dua pendekatan di bawah ini yang paling baik, atau pendekatan alternatif untuk keduanya.

Setidaknya saya memiliki entitas ini:

• pertanyaan
• survei
• orang

Dan setidaknya hubungan ini:

• Setiap survei memiliki 1 atau lebih pertanyaan.
• Setiap pertanyaan dapat digunakan dalam 0 atau lebih survei.
• Setiap orang dapat melakukan survei 0 atau lebih.

Di sinilah saya mengalami masalah: bagaimana memodelkan respons terhadap pertanyaan survei yang dilakukan oleh seseorang.

Berikut adalah dua pendekatan yang saya pertimbangkan, yang tidak satu pun terlihat baik bagi saya. Diagram di sini sangat disederhanakan untuk menggambarkan masalah ini.

Pendekatan 1:

Apa yang saya tidak suka tentang pendekatan ini:

• The survey_person_question_responsemeja memiliki dua kolom yang berbeda yang merujuk pada survei: survey_question_survey_iddansurvey_person_survey_id
  • Ini akan menjadi kesalahan untuk memiliki survey_idreferensi yang berbeda dalam satu baris untuk dua kolom ini. Survei_pertanyaan harus dari survei yang sama dengan yang diambil orang dalam survey_person. Saya tidak bisa melihat cara yang baik untuk menegakkan ini.
• Sepertinya apa yang saya lakukan di sini adalah membuat hubungan antara dua hubungan. Itu terasa salah bagi saya karena beberapa alasan.

Pendekatan 2:

Cobalah untuk menghindari dua FK dari pendekatan 1 yang seharusnya merujuk pada nilai yang sama ...

Apa yang saya tidak suka tentang pendekatan ini:

• Tidak ada penegakan bahwa FK question_iddan survey_iddari survey_questionpasangan yang sah
• Tidak ada penegakan bahwa FK survey_iddan person_iddari survey_personpasangan yang sah

Setiap saran tentang:

• Apakah salah satu dari pendekatan ini adalah pendekatan yang khas
• Pro dan kontra dari salah satu pendekatan ini lebih dari yang lain
• Cara yang lebih baik untuk mengatur data ini sepenuhnya

Akan sangat dihargai!

Sesuai pemahaman saya tentang spesifikasi Anda, lingkungan bisnis Anda melibatkan hubungan ternary tingkat konseptual . Dalam hal ini, Anda perlu mendefinisikan:

1. tipe hubungan (atau asosiasi ) antara tipe entitas Person dan Survey ;
2. jenis hubungan antara Survei dan Pertanyaan ;
3. tipe hubungan yang membangun hubungan antara dua tipe hubungan tersebut di atas dan, sebagai konsekuensinya, antara Person , Survei dan Pertanyaan , yaitu, Respon (nama pendek yang menyederhanakan interpretasi, dari sudut pandang saya).

Jadi, saya menganggap Anda berada di jalur yang benar dengan Pendekatan 1 Anda , meskipun memerlukan beberapa perbaikan kecil (namun penting) untuk membuatnya lebih akurat. Saya akan merinci perbaikan dan pertimbangan terkait lainnya di bagian berikut.

Peraturan bisnis

Mari kita sedikit memperluas aturan bisnis yang berlaku dan merumuskannya kembali dengan cara berikut:

• Sebuah Orang register di nol-satu-atau-banyak Survei
• Sebuah Survei mendapat pendaftaran dari nol-satu-atau-banyak Orang
• Sebuah Survey terintegrasi oleh satu-ke-banyak Pertanyaan
• Sebuah Pertanyaan mengintegrasikan nol-satu-atau-banyak Survei
• Sebuah Pertanyaan menerima nol-satu-atau-banyak Responses
• Sebuah Respon disediakan oleh tepat satu Orang dalam konteks persis-satu Survey

Diagram Eksposisi IDEF1X

Kemudian, saya telah menciptakan IDEF1X ^sebuah diagram yang disajikan dalam Gambar 1 , yang mensintesis aturan bisnis dirumuskan di atas:

_{^a Definisi Integrasi untuk Information Modeling ( IDEF1X ) adalah teknik pemodelan yang sangat dianjurkan yang didirikan sebagai standar pada Desember 1993 oleh Amerika Serikat Institut Nasional Standar dan Teknologi ( NIST ). Hal ini kokoh didasarkan pada pekerjaan teoritis ditulis oleh satu-satunya pendiri dari model relasional , yaitu, Dr EF Codd dan juga pada pandangan-relasi entitas dikembangkan oleh Dr. PP Chen .}

The PersonSurvey Hubungan

Seperti yang saya lihat, yang PersonSurvey hubungan harus menyediakan sarana otorisasi sehingga Orang dapat mengambil bagian dalam diberikan Survey . Dengan cara ini, sekali Orang tertentu telah terdaftar dalam Survei tertentu , ia berwenang untuk memberikan Tanggapan terhadap Pertanyaan yang mengintegrasikan Survei masing-masing .

The SurveyQuestion Hubungan

Saya berasumsi bahwa properti (atau atribut) yang disebut suvery_question.question_number dalam diagram Anda digunakan untuk mewakili Urutan presentasi dari contoh Pertanyaan yang diberikan sehubungan dengan Survei tertentu . Seperti yang Anda lihat, saya telah menyatakan properti seperti SurveyQuestion.PresentationOrder , dan saya pikir Anda harus mencegah (i) dua Pertanyaan atau lebih. Nilai-nilai Jumlah saham berbagi (ii) nilai PresentationOrder yang sama dalam (iii) kemunculan SurveyQuestion yang sama .

Untuk menggambarkan kebutuhan itu, saya telah memasukkan ALTERNATE KEY komposit (AK) dalam kotak yang mewakili jenis entitas ini, yang terdiri dari kombinasi properti ( SurveyNumber, QuestionNumber, PresentationOrder ). Seperti yang Anda ketahui, AK komposit dapat dinyatakan dalam desain DDL logis dengan bantuan batasan UNIK multi-kolom (seperti yang saya contohkan dalam SurveyQuestiontabel yang merupakan bagian dari tata letak DDL ekspositor yang dijelaskan beberapa bagian di bawah).

The Respon Jenis entitas

Ya, dengan tipe entitas Respons saya menggambarkan hubungan antara dua hubungan lainnya ; itu mungkin tampak aneh pada pandangan pertama tetapi tidak ada yang salah dengan pendekatan ini, selama itu (a) merupakan fitur dari konteks bisnis yang menarik secara akurat dan (b) diwakili benar dalam tata letak yang logis-tingkat.

Ya, Anda sepenuhnya benar, itu akan menjadi kesalahan untuk menggambarkan bagian skenario di tingkat logis abstraksi dengan menggunakan dua Response.SurveyNumber(atau, katakanlah Response.SurveyId) nilai yang dirujuk dari dua kolom berbeda di Responsebaris yang sama .

Berasal dari tata letak SQL-DDL logis

-- 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)
);

Dua KUNCI ASING komposit di dalam Responsetabel

Ini, mungkin, poin paling penting untuk didiskusikan: referensi dibuat dari Responsebaris tertentu ke

1. SurveyQuestion.SurveyNumber, dan
2. SurveyPerson.SurveyNumber

harus memiliki nilai yang cocok . Sejauh yang saya ketahui, opsi terbaik untuk menegakkan kondisi ini secara deklaratif adalah dengan memanfaatkan dua komposit ASING KUNCI (FK).

Seperti ditunjukkan dalam desain DDL, FK pertama membuat referensi ke PersonSurveytabel PRIMARY KEY (PK), yaitu (PersonId, SurveyNumber), dan disesuaikan dengan kolom Response.PersonIddan Response.SurveyNumber.

FK kedua menunjuk ke SurveyQuestiontabel PK, yaitu (SurveyNumber, QuestionNumber), dan, karenanya, terdiri dari kolom Response.SurveyNumberdan Response.QuestionNumber.

Dengan cara ini, Response.SurveyNumberkolom ini cukup instrumental karena digunakan sebagai bagian dari referensi FK dalam dua kendala yang berbeda.

Dengan metode ini, salah satu memastikan manajemen database sistem-dijamin integritas referensial dari

• (a) Responseuntuk PersonSurvey;
• (b) Responseke SurveyQuestion; dan
• (c) masing-masing tabel yang mewakili jenis entitas asosiatif ke tabel yang mewakili jenis entitas independen, yaitu Person, Surveydan Question.

Data yang diturunkan untuk menghindari pembaruan anomali

Saya perhatikan dalam diagram Anda dua elemen yang saya hargai layak disebutkan. Elemen-elemen ini terkait dengan dua PersonSurveykolom yang dapat (harus) diturunkan .

Dalam hal itu, Anda dapat menurunkan PersonSurvey.IsStarteddatum oleh query jika diberikan Personterjadinya telah memberikan satu atau lebih Responsesuntuk Questionsyang mengintegrasikan tepat Surveymelalui SurveyQuestionmeja.

Dan Anda juga bisa mendapatkan PersonSurvey.IsCompletedtitik data dengan menentukan apakah Personinstance yang diberikan telah memasok a Responseuntuk semua Questionsyang berisi nilai 'BENAR' di IsMandatorykolom dalam SurveyQuestionbaris tertentu .

Dengan cara menurunkan nilai-nilai ini, Anda mencegah beberapa anomali pembaruan yang akhirnya akan muncul jika Anda menyimpan nilai-nilai tersebut di SurveyQuestionkolom.

Pertimbangan penting

Seperti @Dave tunjukkan dengan benar dalam komentarnya, jika Anda menghadapi persyaratan di masa depan yang menuntut pengelolaan berbagai jenis respons yang menyiratkan mengelola tanggal, nilai numerik, pilihan ganda, dan aspek lain yang mungkin, Anda harus memperluas tata letak basis data ini.

Ini adalah salah satu alasan mengapa saya tidak suka membuat awalan kolom saat memigrasikannya sebagai kunci asing. Dalam kasus pertama Anda, alat pemodelan dapat memaksa Anda untuk mengawali salah satu survey_idkolom dalam survey_person_question_responsetabel. Anda mungkin dapat menyesuaikan ini setelah hubungan dibuat.

Jika perlu hapus bidang id survei yang berlebihan ketika Anda membangun model fisik di mana Anda tidak perlu kolom yang digandakan. Seperti yang telah Anda identifikasi, kedua model Anda memiliki masalah, tetapi saya percaya model pertama secara keseluruhan lebih baik.