Translate the following into table and constraint defini>ons Student SSN PK BirthDate PermAddress See (par>al) answer next page Complete coverage No overlap Applicant ApplyDate Vandy Student EntryDate Translate the following into table and constraint defini>ons CREATE TABLE Student ( SSN INTEGER PRIMARY KEY, BirthDate Date, PermAddress VARCHAR(60)) CREATE TABLE Applicant ( SSN INTEGER PRIMARY KEY, ApplyDate Date, FOREIGN KEY (SSN) REFERENCES Student ON DELETE CASCADE ON UPDATE CASCADE) CREATE TABLE VandyStudent ( SSN INTEGER PRIMARY KEY, EntryDate Date, FOREIGN KEY (SSN) REFERENCES Student ON DELETE RESTRICT ON UPDATE RESTRICT) Student SSN PK BirthDate PermAddress Complete coverage No overlap Applicant ApplyDate Vandy Student EntryDate What’s missing? Asser>ons (or alterna>vely in-­‐table checks or triggers) – see the midterm key and the prac>ce midterm key under Schedule for examples of asser>ons you can adapt. BTW – you don’t need special asser>ons for “par>al coverage” allowed or “overlap allowed” condi>ons Consider the following buggy UML snippet, in which the Name a]ribute in the Floor table refers to the Name a]ribute in the Dorm Table. Floor# is an integer no greater than 10. Replace it by a correct UML snippet that represents the same database defini>on. Dorm Name PK Occupancy 1..1 1..* Floor Name PK Floor# PK … See answer next page Consider the following buggy UML snippet, in which the Name a]ribute in the Floor table refers to the Name a]ribute in the Dorm Table. Floor# is an integer no greater than 10. Replace it by a correct UML snippet that represents the same database defini>on. Dorm Name PK Occupancy 1..1 Dorm Name PK Occupancy 1..1 1..* Floor Name PK Floor# PK … Floor 1..* Floor# (PK) PK … remember that I treat the u composi>on operator as synonymous with 1..1 and the aggrega>on operator as synonymous with 0..1 CREATE TABLE Floor ( Floor# INTEGER, DormName VARCHAR(60), PRIMARY KEY (Floor#, DormName), /* PK a]ributes always NOT NULL, whether explitely declared or not */ FOREIGN KEY (DormName) REFERENCES Dorm(Name) ....) Consider the following buggy UML snippet, in which the Name a]ribute in the Floor table refers to the Name a]ribute in the Dorm Table. FloorID is an auto-­‐increment PK Dorm Name PK Occupancy 1..1 1..* Floor Name FloorID PK … Consider the following buggy UML snippet, in which the Name a]ribute in the Floor table refers to the Name a]ribute in the Dorm Table. FloorID is an auto-­‐increment PK Dorm Name PK Occupancy 1..1 1..* Floor Name FloorID PK … Dorm Name PK Occupancy 1..1 1..* Floor FloorID PK … CREATE TABLE Floor ( FloorID INTEGER, DormName VARCHAR(60) NOT NULL, /* if NOT NULL forgo]en then consistent with 0..1 rather than 1..1 PRIMARY KEY (FloorID), FOREIGN KEY (DormName) REFERENCES Dorm(Name) ....) Joe Elm Jane Oak Pa>ent Name PK Address 1..1 0..* LabTest TestID PK Result Date 1..1 1..* 0..* LO1 Joe LO2 Jane LabOrder OrderID PK 1..1 ... LT11 LO1 Joe ... LT12 LO1 Joe ... LT21 LO2 Jane ... LT21 LO2 Jane ... “Circularity” can enable inconsistency LabTest is intended as a single unit test; LabOrder is a ba]ery of tests ordered at one >me Suppose you have pa>ents Joe and Jane. Joe has lab order LO1 with par>cular tests LT11 and LT12. Jane has lab order LO2 with par>cular tests LT21 and LT22. Can Joe be mistakenly associated with LO2 while s>ll being associated with LT11 and LT12 without causing a constraint viola>on? Above is the DB as we would intend it – correct and consistent Joe Elm Jane Oak Pa>ent Name PK Address 1..1 0..* LabTest TestID PK Result Date 1..1 FK(Name) REFS Pa>ent 1..* 0..* LO1 Joe LO2 JaneJoe LT11 LO1 Joe ... LT12 LO1 Joe ... LT21 LO2 Jane ... LT21 LO2 Jane ... FK(OrderID) REFS LabOrder LabOrder OrderID PK 1..1 ... Joe could be erroneously associated with LO2 and there would be no constraint viola>on, of either the FK constraint from LabOrder to Pa>ent or the FK constraint from LabOrder to LabTest. BUT this example isn’t about wrongness per say, its about inconsistency – LO2 is now, in different parts of the database, associated with both Jane and Joe, and s>ll, no constraint viola>on We could write an asser>on or trigger to insure consistency, or do some other design modifica>on to insure consistency. Some might think that redundancy, for purposes of error checking, can be good ... and it can be, like parity bits, but in this DB case can be expensive (interes>ng thought: think about how you might use PK box construct(s) to build in redundancy that can be easily checked within table at the cost of a couple of addi>onal fields per tuple). My point here is just be aware of inconsistency that can arise from “circularity” and in any case. Consider removing the Pa>ent/LabTest link Joe Elm Jane Oak Pa>ent Name PK Address 1..1 X 0..* LabTest TestID PK Result 1..1 LT11 LO1 Joe ... LT12 LO1 Joe ... LT21 LO2 Jane ... LT21 LO2 Jane ... 1..* FK(OrderID) REFS LabOrder FK(Name) REFS Pa>ent 0..* LO1 Joe LO2 JaneJoe LabOrder OrderID PK 1..1 Date LO2 is now unambiguously associated with Joe – its s>ll incorrect, but not inconsistent! A design team might actually think about gejng rid of the LabOrder class (or making it an associa>on class) and replacing the LabOrder table with a view, perhaps Lesson – beware the redundancy that arises from circularity (and otherwise) Joe Elm Jane Oak LabTest LabID PK Result Pa>ent Name PK Address 1..1 1..* 0..* LO1 Joe LO2 Jane LabOrder OrderID PK 1..1 Date What we want is a consistent and correct DB SELECT P.Name P.Address, LT.LabID, LT.Result FROM Pa>ent P, LabOrder LO, LabTest LT WHERE P.Name = LO.Name AND LO.OrderID = LT.OrderID LT11 LO1 ... LT12 LO1 ... LT21 LO2 ... LT21 LO2 ...