Week 8 - answer

Exercise Normalise this data on outstanding video rentals Describe your result as an ER model (relationships not foreign keys) Source:

Normalisation Video data –Artist is the same for a given video title –So is Length –So these depend only on Video Title –So normalise this data into one table: Video with a primary key of VideoTitle Borrower data –Borrower(name) and Card Nbr are related –So Normalise to a Borrower table with a primary key of CardNbr What remains is –DateDue, DaysOverdue, VideoTitle, CopyNbr and CardNbr –These represent a Rental –Primary key is VideoTitle, CopyNbr, and Date (why not CardNbr?)

Normalised Tables Video(VideoTitle, Artist, Length) Borrower (CardNbr, Name) Rental (VideoTitle, CopyNbr, DateDue, DaysOverdue, CardNbr)

CopyNbr not unique in the shop but only for a VideoTitle This indicates Foreign Key becomes part of the PrimaryKey ER model

Observations We can improve on this model in two ways: –When a video is returned, the rental record will be deleted. But this will also delete knowledge of the existence of a video copy, so we need to introduce a Copy table –The DaysOverdue is actually a function of today’s date and the due date- today seems to be 8/32/00 (i.e.9/1/00) so this data is redundant since it can be calculated –In UML you would be able to keep this attribute but mark it as derived and define the rule for calculating it. –This model is closer to the model you might create working top-down

CREATE TABLE Video( TitleVARCHAR(20) NOT NULL, ArtistVARCHAR(20), LengthINTEGER, CONSTRAINTpk_Video PRIMARY KEY (Title) ); CREATE TABLE Borrower( CardNbrINTEGER NOT NULL, BorrowerNameVARCHAR(8), CONSTRAINTpk_Borrower PRIMARY KEY (CardNbr) ); CREATE TABLE Rental( DueDateDATE NOT NULL, CopyNbrINTEGER NOT NULL, TitleVARCHAR(20) NOT NULL, CONSTRAINTpk_Rental PRIMARY KEY (DueDate,CopyNbr,Title) ); CREATE TABLE Copy( CopyNbrINTEGER NOT NULL, TitleVARCHAR(20) NOT NULL, CONSTRAINTpk_Copy PRIMARY KEY (CopyNbr,Title) ); Create LINK tables -- CREATE TABLE Borrower_Rental( CardNbrINTEGER NOT NULL, DueDateDATE NOT NULL, CopyNbrINTEGER NOT NULL, TitleVARCHAR(20) NOT NULL, PRIMARY KEY (DueDate,CopyNbr,Title), FOREIGN KEY(CardNbr) REFERENCES Borrower(CardNbr) ON DELETE RESTRICT ON UPDATE RESTRICT, FOREIGN KEY(DueDate,CopyNbr,Title) REFERENCES Rental(DueDate,CopyNbr,Title) ON DELETE RESTRICT ON UPDATE RESTRICT );

QSEE code generation Note the additional link table. This is because Borrower is optional (the second entry in the sample data). QSEE is very strict about forbidding nulls as foreign keys, so it creates an addition link table. Nulls in foreign key fields is a big debating point – theorists on the one side, pragmatists on the other. In my view QSEE should allow this as a optional setting. The only way to avoid this additional table is to remove the optionality, generate the DDL and then edit the foreign key column to remove the ‘Not Null’ constraint from the foreign key column.

Questions for the customer Is VideoTitle really unique? Can two videos have the same title? Is there a standard identifier like ISBN which would be better? How could this be linked to IMDb e.g. Out of AfricaOut of Africa Numbering copies of a title is a bit harder than numbering every copy with a serial number which is unique in the store. Would this be a better approach?