แรงบันดาลใจจากการสร้างแบบจำลองคำถาม Django: การสร้างแบบจำลองฐานข้อมูลที่มีความสัมพันธ์หลายต่อหลายหลายใน Django การออกแบบ db เป็นสิ่งที่ชอบ:
CREATE TABLE Book
( BookID INT NOT NULL
, BookTitle VARCHAR(200) NOT NULL
, PRIMARY KEY (BookID)
) ;
CREATE TABLE Tag
( TagID INT NOT NULL
, TagName VARCHAR(50) NOT NULL
, PRIMARY KEY (TagID)
) ;
CREATE TABLE BookTag
( BookID INT NOT NULL
, TagID INT NOT NULL
, PRIMARY KEY (BookID, TagID)
, FOREIGN KEY (BookID) REFERENCES Book (BookID)
, FOREIGN KEY (TagID) REFERENCES Tag (TagID)
) ;
CREATE TABLE Aspect
( AspectID INT NOT NULL
, AspectName VARCHAR(50) NOT NULL
, PRIMARY KEY (AspectID)
) ;
CREATE TABLE TagAspect
( TagID INT NOT NULL
, AspectID INT NOT NULL
, PRIMARY KEY (TagID, AspectID)
, FOREIGN KEY (TagID) REFERENCES Tag (TagID)
, FOREIGN KEY (AspectID) REFERENCES Aspect (AspectID)
) ;
และปัญหาคือวิธีการกำหนดBookAspectRating
ตารางและการบังคับใช้ Referential Integrity ดังนั้นจึงไม่สามารถเพิ่มการจัดอันดับสำหรับ(Book, Aspect)
ชุดค่าผสมที่ไม่ถูกต้อง
AFAIK CHECK
ข้อ จำกัดที่ซับซ้อน(หรือASSERTIONS
) ที่เกี่ยวข้องกับแบบสอบถามย่อยและมากกว่าหนึ่งตารางที่อาจเป็นไปได้ที่จะแก้ปัญหานี้ไม่สามารถใช้ได้ใน DBMS ใด ๆ
อีกแนวคิดหนึ่งคือใช้ (pseudocode) มุมมอง:
CREATE VIEW BookAspect_view
AS
SELECT DISTINCT
bt.BookId
, ta.AspectId
FROM
BookTag AS bt
JOIN
Tag AS t ON t.TagID = bt.TagID
JOIN
TagAspect AS ta ON ta.TagID = bt.TagID
WITH PRIMARY KEY (BookId, AspectId) ;
และตารางที่มี Foreign Key ไปที่มุมมองด้านบน:
CREATE TABLE BookAspectRating
( BookID INT NOT NULL
, AspectID INT NOT NULL
, PersonID INT NOT NULL
, Rating INT NOT NULL
, PRIMARY KEY (BookID, AspectID, PersonID)
, FOREIGN KEY (PersonID) REFERENCES Person (PersonID)
, FOREIGN KEY (BookID, AspectID)
REFERENCES BookAspect_view (BookID, AspectID)
) ;
คำถามสามข้อ:
มี DBMS ที่อนุญาต (อาจปรากฏขึ้น)
VIEW
ด้วยPRIMARY KEY
หรือไม่มี DBMS ที่ช่วยให้
FOREIGN KEY
ว่า(และไม่เพียงฐาน)?REFERENCES
VIEW
TABLE
ปัญหาความสมบูรณ์นี้สามารถแก้ไขได้เป็นอย่างอื่น - ด้วยคุณสมบัติ DBMS ที่มีอยู่หรือไม่
ชี้แจง:
เนื่องจากอาจไม่มีวิธีการแก้ปัญหาที่น่าพึงพอใจ 100% - และคำถาม Django ก็ไม่ได้เป็นของฉัน! - ฉันสนใจกลยุทธ์ทั่วไปของการโจมตีที่เป็นไปได้ของปัญหาไม่ใช่วิธีแก้ปัญหาอย่างละเอียด ดังนั้นคำตอบเช่น"ใน DBMS-X สามารถทำได้ด้วยทริกเกอร์ในตาราง A"จึงเป็นที่ยอมรับอย่างสมบูรณ์