Theo hiểu biết của tôi về thông số kỹ thuật của bạn, môi trường kinh doanh của bạn liên quan đến một mối quan hệ ternary cấp khái niệm . Về vấn đề này, bạn cần xác định:
- loại mối quan hệ (hoặc liên kết ) giữa các loại thực thể Person và Survey ;
- loại mối quan hệ giữa Khảo sát và Câu hỏi ;
- loại mối quan hệ thiết lập kết nối giữa hai loại mối quan hệ nói trên và, do đó, giữa Người , Khảo sát và Câu hỏi , tức là Phản hồi (một tên ngắn hơn giúp đơn giản hóa việc giải thích, theo quan điểm của tôi).
Vì vậy, tôi cho rằng bạn đang đi đúng hướng với Cách tiếp cận 1 của mình , mặc dù nó đòi hỏi một số tinh chỉnh nhỏ (nhưng quan trọng) để làm cho nó chính xác hơn. Tôi sẽ trình bày chi tiết các sàng lọc như vậy và các cân nhắc liên quan khác trong các phần sau.
Quy tắc kinh doanh
Hãy để chúng tôi mở rộng các quy tắc kinh doanh áp dụng một chút và cải tổ chúng theo cách sau:
- Một người đăng ký trong các cuộc khảo sát không có một hoặc nhiều
- Một cuộc khảo sát có được đăng ký của những người không có một hoặc nhiều người
- Một khảo sát được tích hợp bởi nhiều câu hỏi
- Một câu hỏi tích hợp zero-một-hoặc-nhiều Khảo sát
- Một câu hỏi nhận zero-một-hoặc-nhiều Responses
- Một đáp ứng được cung cấp bởi chính xác-one Person trong bối cảnh chính xác-one Khảo sát
Sơ đồ IDEF1X tiếp xúc
Sau đó, tôi đã tạo cho IDEF1X một sơ đồ được trình bày trong Hình 1 , tổng hợp các quy tắc kinh doanh được xây dựng ở trên:
một Integration Definition Thông tin Modeling ( IDEF1X ) là một kỹ thuật xây dựng mô hình đánh giá cao recommendable đã được thành lập như là một tiêu chuẩn trong tháng 12 năm 1993 do Viện Quốc gia Hoa Kỳ Tiêu chuẩn và Công nghệ ( NIST ). Nó hoàn toàn dựa trên công trình lý thuyết được sáng lập bởi người sáng lập duy nhất của mô hình quan hệ , tức là Tiến sĩ EF Codd và cũng dựa trên quan điểm về mối quan hệ thực thể được phát triển bởi Tiến sĩ PP Chen .
Các PersonSurvey mối quan hệ
Như tôi thấy, mối quan hệ PersonSurvey được yêu cầu cung cấp một phương tiện ủy quyền để một Người có thể tham gia vào một Khảo sát nhất định . Theo cách này, một khi một Người nào đó đã được đăng ký trong một Khảo sát cụ thể , người đó được ủy quyền để cung cấp Phản hồi cho các Câu hỏi tích hợp Khảo sát tương ứng .
Các SurveyQuestion mối quan hệ
Tôi giả sử rằng thuộc tính (hoặc thuộc tính) được gọi là suvery_question.question_number trong sơ đồ của bạn được sử dụng để thể hiện Thứ tự trình bày của một thể hiện Câu hỏi nhất định đối với một Khảo sát cụ thể . Như bạn có thể thấy, tôi đã ký hiệu các thuộc tính như SurveyQuestion.PftimeationOrder và tôi nghĩ rằng bạn nên ngăn chặn (i) hai hoặc nhiều câu hỏi. Các giá trị củaQuestionNumber chia sẻ (ii) cùng một giá trị PresentationOrder trong (iii) cùng một sự kiện SurveyQuestion .
Để miêu tả nhu cầu đó, tôi đã bao gồm một ALTERNATE KEY (AK) tổng hợp trong hộp đại diện cho loại thực thể này, bao gồm sự kết hợp của các thuộc tính ( SurveyNumber, questionNumber, PresentationOrder ). Như bạn đã biết, một AK tổng hợp có thể được khai báo trong thiết kế DDL hợp lý với sự trợ giúp của một ràng buộc UNIITE nhiều cột (như tôi đã minh họa trong SurveyQuestionbảng là một phần của bố cục DDL giải trình bày một vài phần bên dưới).
Các phản ứng loại thực thể
Có, với Phản hồi loại thực thể tôi đang mô tả mối quan hệ giữa hai mối quan hệ khác ; nó có thể có vẻ vụng về ở cái nhìn đầu tiên nhưng không có gì là sai với cách tiếp cận này, miễn là nó (a) đại diện cho các tính năng của bối cảnh kinh doanh quan tâm một cách chính xác và (b) được thể hiện đúng trong một bố cục logic cấp.
Vâng, bạn hoàn toàn chính xác, sẽ là một lỗi khi mô tả một phần của kịch bản ở mức độ trừu tượng logic bằng hai Response.SurveyNumberResponse.SurveyId giá trị (hoặc, giả sử ) được tham chiếu từ hai cột khác nhau trong cùng một Responsehàng.
Bố cục SQL-DDL hợp lý
-- 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)
);
Hai phím NGOẠI TỆ tổng hợp trong Responsebảng
Đây có lẽ là điểm quan trọng nhất để thảo luận: các tài liệu tham khảo được thực hiện từ một Response hàng để
SurveyQuestion.SurveyNumbervà SurveyPerson.SurveyNumber
phải có giá trị khớp . Theo tôi thấy, lựa chọn tốt nhất để thực thi điều kiện này theo cách khai báo là sử dụng hai phím NGOẠI TỪ (FK) tổng hợp.
Như được thể hiện trong thiết kế DDL, FK đầu tiên đang tạo tham chiếu đến PersonSurveybảng PRIMARY KEY (PK), nghĩa là (PersonId, SurveyNumber), và được tuân thủ bởi các cột Response.PersonIdvà Response.SurveyNumber.
FK thứ hai đang chỉ vào SurveyQuestionbảng PK, nghĩa là (SurveyNumber, QuestionNumber), và, theo đó, được tạo thành từ các cột Response.SurveyNumbervà Response.QuestionNumber.
Theo cách này, Response.SurveyNumbercột khá công cụ vì nó được sử dụng như một phần của tham chiếu FK theo hai ràng buộc khác nhau.
Với phương pháp này, người ta đảm bảo hệ thống quản lý cơ sở dữ liệu được đảm bảo tính toàn vẹn tham chiếu từ
- (a)
Response đến PersonSurvey;
- (b)
Response đến SurveyQuestion; và
- (c) mỗi bảng đại diện cho một loại thực thể kết hợp các bảng đứng với nhiều loại thực thể độc lập, cụ thể là
Person, Surveyvà Question.
Dữ liệu được tạo ra để tránh cập nhật sự bất thường
Tôi đã nhận thấy trong sơ đồ của bạn hai yếu tố mà tôi đánh giá cao là đáng nói. Các yếu tố này có liên quan đến hai PersonSurveycột có thể (nên) dẫn xuất .
Về vấn đề đó, bạn có thể lấy được PersonSurvey.IsStarteddữ liệu bằng cách truy vấn nếu một Personsự kiện nhất định đã cung cấp một hoặc nhiều hơn Responsesđể Questionstích hợp chính xác Surveythông qua SurveyQuestionbảng.
Và bạn cũng có thể có được PersonSurvey.IsCompletedđiểm dữ liệu bằng cách xác định xem một Persontrường hợp cụ thể có cung cấp Responsecho tất cả các Questionsgiá trị đó có giá trị 'TRUE' trong IsMandatorycột trong một SurveyQuestionhàng cụ thể hay không .
Bằng cách lấy đạo hàm của các giá trị này, bạn đang ngăn chặn một số bất thường cập nhật cuối cùng sẽ phát sinh trong trường hợp bạn giữ các giá trị đó trong SurveyQuestioncột.
Cân nhắc quan trọng
Như @Dave đã chỉ ra một cách đúng đắn trong nhận xét của mình, nếu bạn phải đối mặt với yêu cầu trong tương lai yêu cầu quản lý các loại phản hồi khác nhau có nghĩa là quản lý ngày, giá trị số, nhiều lựa chọn và các khía cạnh có thể khác, bạn sẽ phải mở rộng bố cục cơ sở dữ liệu này.
IDvàNumber, nhưng nếu không thì điều này thật tuyệt vời. Cảm ơn bạn.