1. Assignment 3 1

2. 2 Design Methodology A structured approach that uses procedures, techniques, tools, and documentation aids to support and facilitate the process of design. Three main phases 1.Conceptual database design Understanding client data E-R (EER) Model Contract between clients and designers E-R Model could be used for any database system 2.Logical database design Mapping E-R Model to (relational) database schema Normalization 3.Physical database design

3. 3 How to Represent Relationship? Primary Key and Foreign Key! 1:1 1:* (1..m) *:* (m..n) Complex relationship Recursive relationship Superclass / Subclass Relationship

4. 4 One-to-Many (1:*) Owner (1) Owns (0..*) PropertyForRent Parent entity: one side Owner Child entity: many side PropertyForRent Do we need a table for the relationship? NO! Copy PK of parent entity to child entity as FK Copy Ono to PropertyForRent Does it work to copy Pno to Owner?

5. 5 Mapping Entities with Relationship to Table Schemas E-R Model Owner (Ono, firstName, lastName, Phone) Property(Pno, Street, City, State, Zipcode, Rent) Owner (1) Owns (0..*) Property Table Schemas (DBDL) Owner (Ono, firstName, lastName, Phone) PK: Ono AK: FK: None Property(Pno, Street, City, State, Zipcode, Rent, Ono) PK: Pno AK: Street, City, Zipcode FK: Ono references Owner

6. 6 Example E1E2 A1B1 A2 composite (A21, A22)B2: Multi-value B3 PK: A1PK: B1 E1 (1..*) RelatedTo (1) E2 Table Schemas (DBDL) E1 (A1, A21, A22, B1)E2 (B1, B3) PK: A1 PK: B1 AK: None AK: None FK: B1 references E2 FK: None E2 (B1, B2, NewID) PK: NewID AK: None FK: B1 references E2

7. 7 One-to-One (1:1) Are the two entity types identical with different names? Client -------- Customer Staff ---------- Employee Can the two entity types be combined into one entity type? Client (1) Provides (1) RegstrationInfo Client (1) Has (1) Interview

8. 8 One-to-One (1:1) The two entity types are not identical, and cannot be combined into one entity. Do we need a new table for the relationship? NO! Copy one PK as FK. Which Direction: Three Cases Total on both sides Partial both sides Total on one side and Partial on the other side

9. 9 One-to-One (1:1) Total on One Side and Partial on the Other Side Entity1 (1..1) RelatedTo (0..1) Entity2 Partial Total Copy PK of Entity1 to Entity2 Each record of Entity2 will have a non-null value for FK Total Do it this way! Copy PK of Entity2 to Entity1 Some records of Entity1 will have null value for FK Partial

10. 10 One-to-One (1:1) Total on Both Sides Entity1 (1..1) RelatedTo (1..1) Entity2 What does it mean? Duplicate Entity? Combined into one entity. If not Duplicate Entity Copy PK of one entity to another entity as FK.

11. 11 One-to-One (1:1) Partial on Both Sides Entity1 (0..1) RelatedTo (0..1) Entity2 Either way Which side is more partial? Performance issue

12. 12 Many-to-Many (*:*) Entity1 (0..*) RelatedTo (1..*) Entity2 Will Coping PK as FK work! NO! No multi-value attributes! What to do? Adding a new table!

13. 13 Many-to-Many (*:*) Client (0..*) Views (0..*) Property (Date, Comment) New Table Viewing Attributes: Date, Comment New relationships Client (1..1) Has (0..*) Viewing (0..*) BeViewed (1..1) Property One (*:*) becomes two (1:*) Copy PK of both Client and Property to Viewing as FK Figure out PK or create a new ID attribute

14. 14 Original Entities (E-R Model) Property (Pno, Street, City, State, Zipcode, Ono) Client (Cno, firstName, lastName, Phone, MaxRent, PrefType) Client (0..*) Views (0..*) Property (Date, Comment) Table Schemas (DBDL) Property (Pno, Street, City, State, Zipcode, Ono) PK: Pno AK: Street, City, Zipcode FK: Ono references Owner (not from the *:* relationship) Client (Cno, firstName, lastName, Phone, MaxRent, PrefType) PK: Cno AK: None FK: None Viewing (Cno, Pno, ViewDate, Comment) PK: Cno, ViewDate AK: None FK: Cno references Client Pno references Property Example

15. 15 DBDL (Database Design Language) Branch (Bno, Street, City, State, Zipcode, Phone) PK: Bno AK: Street, City, Zipcode Phone FK: None Staff (Sno, firstName, lastName, Address, Bno ) PK: Sno AK: None FK: Bno references Branch Client (Cno, firstName, lastName, Phone, MaxRent, PrefType) PK: Cno AK: None FK: None Viewing (ID, Rno, Pno, ViewDate, Comment) PK: ID AK: Rno, ViewDate FK: Rno references Client (Cno) Pno references Property No multi-value attributes, no composite attributes. All relationships are maintained through FKs. New attribute ID for Viewing.