1. DATABASE APPLICATION DEVELOPMENT SAK 3408 Database Design II (week 3)

2. SAK3408 by PSS (W3) Try  Construct an E-R diagram for a video rental store that has a set of customer that can borrows one or more cars.

3. SAK3408 by PSS (W3) Answer :Simple CustomerVideo Borrow

4. SAK3408 by PSS (W3) Answer : Advance ? CustomerVideo Borrow Cus_ID Add PhoneNo Vid_ID Title Price D_Borrow 1N

5. SAK3408 by PSS (W3) Design Techniques 1. Avoid redundancy. 2. Limit the use of weak entity sets. 3. Don’t use an entity set when an attribute will do.

6. SAK3408 by PSS (W3) Avoiding Redundancy  Redundancy = saying the same thing in two (or more) different ways.  Wastes space and (more importantly) encourages inconsistency. Two representations of the same fact become inconsistent if we change one and forget to change the other. Recall anomalies due to FD’s.

7. SAK3408 by PSS (W3) Example: Good CarsManfs ManfBy name This design gives the address of each manufacturer exactly once. nameaddr

8. SAK3408 by PSS (W3) Example: Bad CarsManfs ManfBy name This design states the manufacturer of a beer twice: as an attribute and as a related entity. name manf addr

9. SAK3408 by PSS (W3) Example: Bad Cars name This design repeats the manufacturer’s address once for each beer and loses the address if there are temporarily no beers for a manufacturer. manfmanfAddr

10. SAK3408 by PSS (W3) Entity Sets Versus Attributes  An entity set should satisfy at least one of the following conditions: It is more than the name of something; it has at least one nonkey attribute. or It is the “many” in a many-one or many-many relationship.

11. SAK3408 by PSS (W3) Example: Good CarsManfs ManfBy name Manfs deserves to be an entity set because of the nonkey attribute addr. Cars deserves to be an entity set because it is the “many” of the many-one relationship ManfBy. nameaddr

12. SAK3408 by PSS (W3) Example: Good Cars name There is no need to make the manufacturer an entity set, because we record nothing about manufacturers besides their name. manf

13. SAK3408 by PSS (W3) Example: Bad CarsManfs ManfBy name Since the manufacturer is nothing but a name, and is not at the “many” end of any relationship, it should not be an entity set. name

14. SAK3408 by PSS (W3) Don’t Overuse Weak Entity Sets  Beginning database designers often doubt that anything could be a key by itself. They make all entity sets weak, supported by all other entity sets to which they are linked.  In reality, we usually create unique ID’s for entity sets. Examples include social-security numbers, automobile VIN’s etc.

15. SAK3408 by PSS (W3) When Do We Need Weak Entity Sets?  The usual reason is that there is no global authority capable of creating unique ID’s.  Example: it is unlikely that there could be an agreement to assign unique player numbers across all football teams in the world.

16. SAK3408 by PSS (W3) Practice I  Construct an ER diagram for a car- insurance company that has a set of customers, each of whom owns one or more cars. Each car has associated with it zero to any number of recorded accidents.

17. SAK3408 by PSS (W3) Practice II  A database is being constructed to keep track of the teams and games of a football league. A team has a number of players, not all of whom participate in each game. It is desired to keep track of the players participating in each game for each team, the position they played in that game, and the result of the game. Design an ER schema for this application.

18. SAK3408 by PSS (W3) What’s next ?  Converting our ER diagram into relational  Definition: A relation is a named, two-dimensional table of data Table is made up of rows (records), and columns (attribute or field)  However : Not all tables qualify as relations ???

19. SAK3408 by PSS (W3) Relation Requirement : Every relation has a unique name. Every attribute value is atomic (not multivalued, not composite) Every row is unique (can’t have two rows with exactly the same values for all their fields) Attributes (columns) in tables have unique names The order of the columns is irrelevant The order of the rows is irrelevant

20. SAK3408 by PSS (W3) How to map ER to Relation ?  Entity set -> relation. Attributes -> attributes.  Relationships -> relations whose attributes are only: The keys of the connected entity sets. Attributes of the relationship itself.

21. SAK3408 by PSS (W3) Example CustomerVideo Borrow Cus_ID Add PhoneNo Cus_IDAddPhoneNo CUSTOMER CUSTOMER(Cus_ID, Add, PhoneNo) Primary Key

22. SAK3408 by PSS (W3) Key  Keys are special fields that serve two main purposes: Primary keys are unique identifiers of the relation. Examples include employee numbers, social security numbers, etc. This is how we can guarantee that all rows are unique Foreign keys are identifiers that enable a dependent relation (on the many side of a relationship) to refer to its parent relation (on the one side of the relationship)  Keys can be simple (a single field) or composite (more than one field)  Keys usually are used as indexes to speed up the response to user queries

23. SAK3408 by PSS (W3) Primary Key Foreign Key (implements 1:N relationship between customer and order) Combined, these are a composite primary key (uniquely identifies the order line)…individually they are foreign keys (implement M:N relationship between order and product)

24. SAK3408 by PSS (W3) ER-to Relational Mapping Algorithm 1. Mapping of regular entity types 2. Mapping of weak entity types 3. Mapping of Binary 1:1 relationship types 4. Mapping of Binary 1:N relationship types 5. Mapping of Binary M:N relationship types 6. Mapping of Multivalued attributes 7. Associative Entities Mapping of N-ary relationship types

25. SAK3408 by PSS (W3) STEP 1(Regular entity types) 1. Simple attributes: E-R attributes map directly onto the relation 2. Composite attributes: Use only their simple, component attributes

26. SAK3408 by PSS (W3) (a) CUSTOMER entity type with simple attributes Figure 2.12 Mapping a regular entity (b) CUSTOMER relation

27. SAK3408 by PSS (W3) (a) CUSTOMER entity type with composite attribute Figure 2.13 Mapping a composite attribute (b) CUSTOMER relation with address detail

28. SAK3408 by PSS (W3) STEP 2(Weak entity types) Becomes a separate relation with a foreign key taken from the superior entity Primary key composed of:  Partial identifier of weak entity  Primary key of identifying relation (strong entity)

29. SAK3408 by PSS (W3) Figure 2.15 M apping a weak entity (a) Weak entity DEPENDENT

30. SAK3408 by PSS (W3) (b) Relations resulting from weak entity NOTE: the domain constraint for the foreign key should NOT allow null value if DEPENDENT is a weak entity Foreign key Composite primary key

31. SAK3408 by PSS (W3) STEP 3(Binary 1:1 Relationship Types)  One-to-One - Primary key on the mandatory side becomes a foreign key on the optional side

32. SAK3408 by PSS (W3) Figure 2.18 Mapping a binary 1:1 relationship (a) Binary 1:1 relationship

33. SAK3408 by PSS (W3) (b) Resulting relations

34. SAK3408 by PSS (W3) STEP 4(Binary 1:N Relationship Types)  One-to-Many - Primary key on the one side becomes a foreign key on the many side

35. SAK3408 by PSS (W3) Figure 2.16 mapping a 1:M relationship (a) Relationship between customers and orders

36. SAK3408 by PSS (W3) (b) Mapping the relationship Foreign key

37. SAK3408 by PSS (W3) STEP 5(Binary M:N Relationship Types) new relation  Many-to-Many - Create a new relation with the primary keys of the two entities as its primary key

38. SAK3408 by PSS (W3) Figure 2.17 Mapping M:N relationship (a) ER diagram (M:N) The Supplies relationship will need to become a separate relation

39. SAK3408 by PSS (W3) (b) Three resulting relations New intersection relation Foreign key Composite primary key

40. SAK3408 by PSS (W3) STEP 6 (Multivalued attributes) Multi-valued Attribute - Becomes a separate relation with a foreign key taken from the superior entity

41. SAK3408 by PSS (W3) Figure 2.14 Mapping a multivalued attribute 1 – to – many relationship between original entity and new relation (a) Multivalued attribute becomes a separate relation with foreign key (b)

42. SAK3408 by PSS (W3) STEP 7(N-aray Relationship Types)  One relation for each entity and one for the associative entity  Associative entity has foreign keys to each entity in the relationship

43. SAK3408 by PSS (W3) Figure 2.21 Mapping a ternary relationship (a) Ternary relationship with associative entity

44. SAK3408 by PSS (W3) (b) Mapping the ternary relationship Remember that the primary key MUST be unique

45. SAK3408 by PSS (W3) Additional step : Unary Relationship  One-to-Many - Recursive foreign key in the same relation  Many-to-Many - Two relations: One for the entity type One for an associative relation in which the primary key has two attributes, both taken from the primary key of the entity

46. SAK3408 by PSS (W3) Figure 2.20 Mapping a unary 1:N relationship (a) EMPLOYEE entity with Manages relationship (b) EMPLOYEE relation with recursive foreign key

47. SAK3408 by PSS (W3) Mapping a unary M:N relationship (a) Bill-of-materials relationships (M:N) (b) ITEM and COMPONENT relations

48. SAK3408 by PSS (W3) Addition step : Associative Entities  Identifier Not Assigned Default primary key for the association relation is composed of the primary keys of the two entities (as in M:N relationship)  Identifier Assigned It is natural and familiar to end-users Default identifier may not be unique

49. SAK3408 by PSS (W3) Figure 2.19 Mapping an associative entity (a) Associative entity

50. SAK3408 by PSS (W3) (b) Three resulting relations

51. SAK3408 by PSS (W3) Practice I  Use your previous ERD from the car insurance company and build the relation

52. SAK3408 by PSS (W3) Practice II BANK CUSTOMER LOANACCOUNT BANK_BRANCH Code Name Amount Type Loan_no Balance Acct_no Branch_noAddr Phone Name Addr NoKP Type BRANCHES L_C A_C LOANS ACCTS

53. SAK3408 by PSS (W3) Correspondence between ER and Relational Model ER ModelRelational Model Entity type“Entity” relation 1:1 or 1:N relationship typeForeign key or “Relationship” relation M:N relationship type“Relationship” relation and two foreign keys N-ary relationship type“Relationship” relation and two foreign keys Simple attributeAttribute Composite attributeSet of simple component attributes Multivalued attributeRelation and foreign key Key attributePrimary key

54. SAK3408 by PSS (W3) Recalled : Teaching Plan W3  Transforming ERD into Relations  Data normalization (1NF, 2NF, 3NF)… to be continued…