1. High-level Database Models Prof. Yin-Fu Huang CSIE, NYUST Chapter 4

2. Database Systems Yin-Fu Huang 4.1The Entity-Relationship Model Design phrase 1) What information will be stored 2) How information elements will be related to one another 3) What constraints may be assumed (See Fig. 4.1) High-level models: 1) E/R (Entity/Relationship) diagram 2) UML (Unified Modeling Language) 3) ODL (Object Description Language) Starting with a high-level model and then converting the design to the relational model

3. Database Systems Yin-Fu Huang 4.1The Entity-Relationship Model

4. Database Systems Yin-Fu Huang Three principal element types: 1) Entity sets 2) Attributes 3) Relationships 4.1.1 Entity Sets Entity set ↔ class However, the E/R model is a static concept, involving the structure of data and not the operations on data. 4.1.2 Attributes we assume that attributes are of primitive types, such as strings, integers, or reals. 4.1The Entity-Relationship Model

5. Database Systems Yin-Fu Huang 4.1.3 Relationships Relationships are connections among two or more entity sets. 4.1.4 Entity-Relationship Diagrams Entity set ↔ rectangle Attribute ↔ oval Relationship ↔ diamond (See Fig. 4.2) 4.1The Entity-Relationship Model

6. Database Systems Yin-Fu Huang 4.1The Entity-Relationship Model

7. Database Systems Yin-Fu Huang 4.1.5 Instances of an E/R Diagram A relationship R that connects n entity sets E 1, E 2, …, E n may be imagined to have an “instance” that consists of a finite set of tuples (e 1, e 2, …, e n ), where each e i is chosen from the entities that are in the current instance of entity set E i. 4.1.6 Multiplicity of Binary E/R Relationships Many-one One-one Many-many The arrows means “at most one” (See Fig. 4.3) 4.1The Entity-Relationship Model

8. Database Systems Yin-Fu Huang 4.1The Entity-Relationship Model

9. Database Systems Yin-Fu Huang 4.1The Entity-Relationship Model 4.1.7 Multiway Relationships Example (See Fig. 4.4) 4.1.8 Roles in Relationships It is possible that one entity set appears two or more times in a single relationship. Each line to the entity set represents a different role that the entity set plays in the relationships. Example (See Fig. 4.5 and Fig. 4.6)

10. Database Systems Yin-Fu Huang 4.1The Entity-Relationship Model

11. Database Systems Yin-Fu Huang 4.1The Entity-Relationship Model

12. Database Systems Yin-Fu Huang 4.1The Entity-Relationship Model

13. Database Systems Yin-Fu Huang 4.1The Entity-Relationship Model 4.1.9 Attributes on Relationships Example (See Fig. 4.7) We can instead invent a new entity set, whose entities have the attributes ascribed to the relationship. (See Fig. 4.8) 4.1.10 Converting Multiway Relationships to Binary Any relationship connecting more than two entity sets can be converted to a collection of binary, many-one relationships. A connecting entity set (See Fig. 4.9)

14. Database Systems Yin-Fu Huang 4.1The Entity-Relationship Model

15. Database Systems Yin-Fu Huang 4.1The Entity-Relationship Model

16. Database Systems Yin-Fu Huang 4.1The Entity-Relationship Model

17. Database Systems Yin-Fu Huang 4.1The Entity-Relationship Model 4.1.11 Subclasses in the E/R Model “isa” relationships “an A is a B” expresses an “isa” relationship from entity set A to entity set B. (See Fig. 4.10) Example e.g., Roger Rabbit The three components are connected into one entity by the isa relationships.

18. Database Systems Yin-Fu Huang 4.1The Entity-Relationship Model

19. Database Systems Yin-Fu Huang 4.2.1 Faithfulness First and foremost, the design should be faithful to the specifications of the application. 4.2.2 Avoiding Redundancy We should be careful to say everything once only. e.g., having an attribute studioName of entity set Movies Reasons: 1) Extra space is required to represent the data. 2) An update-anomaly potential 4.2Design Principles

20. Database Systems Yin-Fu Huang 4.2.3 Simplicity Counts Avoiding introducing more elements into your design than is absolutely necessary. (See Fig. 4.11) 4.2.4 Choosing the Right Relationships Adding to our design every possible relationship is not often a good idea. 1) Redundancy 2) Update anomaly 3) Delete anomaly Example (See Fig. 4.7 and Fig. 4.12) 4.2Design Principles

21. Database Systems Yin-Fu Huang 4.2Design Principles

22. Database Systems Yin-Fu Huang 4.2Design Principles

23. Database Systems Yin-Fu Huang 4.2Design Principles

24. Database Systems Yin-Fu Huang 4.2.5 Picking the Right Kind of Element Using attributes or using entity sets? Example Make the name and address of the studio be attributes of movies and eliminate the Studio entity set. Problems: 1) Redundancy: the address of the studio 2) Update anomaly 3) Delete anomaly If we did not record addresses of studios, then there is no harm in making the studio name an attribute of movies. 4.2Design Principles

25. Database Systems Yin-Fu Huang The conditions under which we prefer to use an attribute instead of an entity set: 1) All relationships in which E is involved must have arrows entering E. 2) The only key for E is all its attributes. 3) No relationship involves E more than once. Replacing E: 1) If there is a many-one relationship R from some entity set F to E, then remove R and make the attributes of E be attributes of F. 4.2Design Principles

26. Database Systems Yin-Fu Huang 2) If there is a multiway relationship R with an arrow to E, make the attributes of E be attributes of R and delete the arc from R to E. Tradeoff between using a multiway relationship and using a connecting entity set Example More studios (See Fig. 4.13) 4.2Design Principles

27. Database Systems Yin-Fu Huang 4.2Design Principles

28. Database Systems Yin-Fu Huang 4.3.1 Keys in the E/R Model Every entity set must have a key. There can be more than one possible key for an entity set. When an entity set is involved in an isa-hierarchy, we require that the root entity set have all the attributes needed for a key, and that the key for each entity is found from its component in the root entity set. 4.3.2 Representing Keys in the E/R Model Example (See Fig. 4.17) 4.3Constraints in the E/R Model

29. Database Systems Yin-Fu Huang 4.3Constraints in the E/R Model

30. Database Systems Yin-Fu Huang 4.3.3 Referential Integrity A value appearing in one context must also appear in another. e.g., relationship Owns from Movies to Studios Example (See Fig. 4.18) 4.3.4 Degree Constraints A bounding number to the edges that connect a relationship to an entity set Example (See Fig. 4.19) 4.3Constraints in the E/R Model

31. Database Systems Yin-Fu Huang 4.3Constraints in the E/R Model

32. Database Systems Yin-Fu Huang 4.3Constraints in the E/R Model

33. Database Systems Yin-Fu Huang It is possible for an entity set’s key to be composed of attributes, some or all of which belong to another entity set.. 4.4.1 Causes of Weak Entity Sets Two principal reasons: 1) A hierarchy based on classifications unrelated to the “isa hierarchy” 2) The connecting entity sets Example key: (Studios)name+(Crews)number (See Fig. 4.20) 4.4Weak Entity Sets

34. Database Systems Yin-Fu Huang 4.4Weak Entity Sets

35. Database Systems Yin-Fu Huang key: (Genus)name+(Species)name (See Fig. 4.21) key: (Stars)name+(Studios)name+(Movies)(title+year) (See Fig. 4.22) 4.4.2 Requirements for Weak Entity Sets If E is a weak entity set then its key consists of: 1) zero or more of its own attributes, and 2) key attributes from entity sets that are reached by certain many-one relationships from E to other entity sets, called supporting relationships for E. 4.4Weak Entity Sets

36. Database Systems Yin-Fu Huang 4.4Weak Entity Sets

37. Database Systems Yin-Fu Huang 4.4Weak Entity Sets

38. Database Systems Yin-Fu Huang In order for R to be a supporting relationship for E, the following conditions must be obeyed: 1) R must be a binary, many-one relationship from E to F. 2) R must have referential integrity from E to F. 3) The attributes that F supplies for the key of E must be key attributes of F. 4) If F is itself weak, then some or all of the key attributes of F supplied to E will be key attributes of one or more entity sets G to which F is connected by a supporting relationship. 4.4Weak Entity Sets

39. Database Systems Yin-Fu Huang 5) If there are several different supporting relationships from E to F, then each relationship is used to supply a copy of the key attributes of F to help form the key of E. 4.4.3 Weak Entity Set Notation If an entity set is weak, it will be shown as a rectangle with a double border. Its supporting many-one relationships will be shown as diamonds with a double border. If an entity set supplies any attributes for its own key, then those attributes will be underlined. 4.4Weak Entity Sets

40. Database Systems Yin-Fu Huang It is possible for there to be many-one relationships from a weak entity set that are not supporting relationships, and therefore do not get a double diamond. e.g., relationship: Studio-of (Each movie has a unique owning studio, determined by the many-one relationship from Movies to Studios.) 4.4Weak Entity Sets

41. Database Systems Yin-Fu Huang Converting an E/R design to a relational database schema: 1) Turn each entity set into a relation with the same set of attributes, and 2) Replace a relationship by a relation whose attributes are the keys for the connected entity sets. Several special situations: 1) Weak entity sets cannot be translated straightforwardly to relations. 2) “Isa” relationships and subclasses require careful treatment. 4.5From E/R Diagrams to Relational Designs

42. Database Systems Yin-Fu Huang 3) Sometimes, we do well to combine two relations, especially the relation for an entity set E and the relation that comes from a many-one relationship from E to some other entity set. 4.5.1 From Entity Sets to Relations Example (See Fig. 4.23) 4.5.2 From E/R Relationships to Relations Relationships in the E/R model are also represented by relations. 4.5From E/R Diagrams to Relational Designs

43. Database Systems Yin-Fu Huang 4.5From E/R Diagrams to Relational Designs

44. Database Systems Yin-Fu Huang 1) For each entity set involved in relationship R, we take its key attribute or attributes as part of the schema of the relation for R. 2) If the relationship has attributes, then these are also attributes of relation R. Example (See Fig. 4.24 and Fig. 4.25) Key of Contracts: starName+title+year+studioOfStar +producingStudio 4.5From E/R Diagrams to Relational Designs

45. Database Systems Yin-Fu Huang 4.5From E/R Diagrams to Relational Designs

46. Database Systems Yin-Fu Huang 4.5From E/R Diagrams to Relational Designs

47. Database Systems Yin-Fu Huang 4.5.3 Combining Relations One common situation occurs when there is an entity set E with a many-one relationship R from E to F. The relations E and R can be combined into one relation with a schema consisting of: 1) All attributes of E 2) The key attributes of F 3) Any attributes belonging to relationship R Example (See Fig. 4.26) 4.5From E/R Diagrams to Relational Designs

48. Database Systems Yin-Fu Huang 4.5From E/R Diagrams to Relational Designs

49. Database Systems Yin-Fu Huang But not for a many-many relationship Example (See Fig. 4.27) 4.5.4 Handling Weak Entity Sets Three things for weak entity sets: 1) The relation for the weak entity set W itself must include not only the attributes of W but also the key attributes of the supporting entity sets. 4.5From E/R Diagrams to Relational Designs

50. Database Systems Yin-Fu Huang 4.5From E/R Diagrams to Relational Designs

51. Database Systems Yin-Fu Huang 2) The relation for any relationship in which the weak entity set W appears must use as a key for W all of its key attributes, including those of other entity sets that contribute to W's key. 3) A supporting relationship R need not be converted to a relation at all. Example (See Fig. 4.28) No relation for Unit-of 4.5From E/R Diagrams to Relational Designs

52. Database Systems Yin-Fu Huang 4.5From E/R Diagrams to Relational Designs

53. Database Systems Yin-Fu Huang The principal conversion strategies are: 1) Follow the E/R viewpoint. For each entity set E in the hierarchy, create a relation that includes the key attributes from the root and any attributes belonging to E. 2) Treat entities as objects belonging to a single class. For each possible subtree that includes the root, create one relation, whose schema includes all the attributes of all the entity sets in the subtree. 4.6Converting Subclass Structures to Relations

54. Database Systems Yin-Fu Huang 3) Use null values. Create one relation with all the attributes of all the entity sets in the hierarchy. Each entity is represented by one tuple, and that tuple has a null value for whatever attributes the entity does not have. 4.6.1 E/R-Style Conversion We do not create a relation for “isa”. Example (See Fig. 4.31) 4.6Converting Subclass Structures to Relations

55. Database Systems Yin-Fu Huang 4.6Converting Subclass Structures to Relations

56. Database Systems Yin-Fu Huang Movies(title, year, length, genre) MurderMysteries(title, year, weapon) Cartoons(title, year) Voices(title, year, starName) The movies that are both cartoons and murder mysterieshave tuples in all first three relations. There may be silent cartoons in our database. 4.6.2 An Object-Oriented Approach Example 4.6Converting Subclass Structures to Relations

57. Database Systems Yin-Fu Huang Movies(title, year, length, genre) MoviesC(title, year, length, genre) MoviesMM(title, year, length, genre, weapon) MoviesCMM(title, year, length, genre, weapon) Voices(title, year, starName) 4.6.3 Using Null Values to Combine Relations Example Movies(title, year, length, genre, weapon) 4.6Converting Subclass Structures to Relations

58. Database Systems Yin-Fu Huang 4.6.4 Comparison of Approaches A list of the principal issues: 1) We would prefer to find all the attributes we needed to answer a query in one relation. Nulls approach √ ∗ A query like “what films of 2008 were longer than 150 minutes?” Straight-E/R approach √ Object-Oriented approach × 4.6Converting Subclass Structures to Relations

59. Database Systems Yin-Fu Huang ∗ A query like “what weapons were used in cartoons of over 150 minutes in length?” Straight-E/R approach × Object-Oriented approach √ 2) We would like not to use too many relations. Nulls approach: only one relation Straight-E/R approach: only one relation per entity set in the hierarchy Object-Oriented approach: 2 n relations if n children 4.6Converting Subclass Structures to Relations

60. Database Systems Yin-Fu Huang 3) We would like to minimize space and avoid repeating information. Object-Oriented approach: only one tuple per entity Nulls approach: only one tuple per entity, but these tuples are “long”. Straight-E/R approach: several tuples for each entity, but only the key attributes are repeated. 4.6Converting Subclass Structures to Relations

61. Database Systems Yin-Fu Huang The End.