I would like to model something similar to the following scenario in a database built on MySQL:
I am managing reviews of texts. These texts can either be books or parts of books (e. g. different articles). There may be multiple reviews per text. It can also be guaranteed there is an identifying relationship between from an article to the containing book.
My approach was the following:
The table Review
has an ID
as a primary key, a name
and a foreign key to the primary keys of Book
and Book Part
. Book
and Book Part
have primary keys and some custom attributes for each (see below). Additionally, there is an identifying 1-to-n relationship between Book
and Book Part
.
Is this a viable approach?
Edit: I created a picture for the model.
Description of attributes
Review
------
author - author of the review
rating - an integer describing how well the author liked the text
idBook - book the review is about
idBook_Part - book part the review is about
Book
----
author - author of the book
year - year the book was published
Book Part
---------
author - author of the book part
start page - page where the book part starts in the book
end page - page where the book part ends in the book
idBook - book that contains the part
Note: The attributes of Book and Book Part are intentionally not supersets of each other.
To make sure Review
contains either an idBook
or an idBook_Part
I have written a MySQL trigger for INSERT
and UPDATE
statements that checks that exactly one of them is NULL
.
References to literature are appreciated as well.
Best Answer
Alternative to your approach (exclusive arcs) which you may want to consider is to create a common parent table for Book, and BookPart. For instance, ReviewableEntity:
Now
Review
can have just one foreign key toReviwableEntity
.There is a challenge to enforce that book details are always stored in book table, and book parts in BookPart table which can be solved in multiple ways .
1. Create stored procedures that insert/update data properly and deny direct manipulation of data with
REVOKE
2. Carry over
re_type
attribute to detail tables (Book and BookPart)3. Ignore the problem on db level, and deal with it by administrative means, e.g. force developers to insert into proper table(surprisingly , for this particular case it's not the worst approach ) .
Update.
Compared to exclusive arcs a parent table has the following advantages :
1. Adding new reviewable type is an easy and cheep operation (creating a new table + modifying enum) which can be performed online even for very large table. Exclusive arc approach requires adding column to existing table and modifying code that enforces non-nullability of only one field
2. Other tables can reference ReviewableEntity without knowing exact type
3. Extracting common attributes from detail tables and storing them in common parent will allow queries to hit only one (parent) table thus eliminating joins.
On the other hand, exclusive arc is a way simpler design, and doesn't require extra table .
Also, your choice may be influenced by RDMBS features. From what I remember, mysql didn't have CHECK constraints, so enforcing on db level
NOT NULL
for only one ofIdBook
,IdBookPart
will require trigger .Another option (which I personally don't like) is to have join tables ,
book_part_review( IdBookPart, IdReview)
, andbook_review(IdBook, IdReview)
.