1. © D. Wong 2003 1 Ch. 2 Entity-Relationship Data Model (continue)  Data models  Entity-Relationship diagrams  Design Principles  Modeling of constraints  Weak entity sets

2. © D. Wong 2003 2 Entity-Relationship Diagrams Symbols attributes relationships entity sets Cardinality (Multiplicity): one - one many - one m many - many m n

3. © D. Wong 2003 3 Entity-Relationship Diagrams (continue 1)  Entity –Has a set of attributes –The key is underlined  Key –Attributes which uniquely identify an entity in an entity set –An inherent property of the data (e.g. movie title and year) –Serve as a constraint SS#

4. © D. Wong 2003 4 Entity-Relationship Diagrams (continue 2)  Multiway relationships  Relationships with roles  Attributes on relationships –E.g. salary of a star for a movie –Not necessary by adding new entity set, whose entities have the attributes

5. © D. Wong 2003 5 E/R Diagrams Multiway relationships  Can be converted to a collection of binary, many- one relationships –Introduce new entity set (connecting entity set)  Entities are tuples of the relationship set for the multiway relationship –Introduce many-one relationships from the connecting entity set to each of the entity sets that provide components of tuples in the original, multiway relationship

6. © D. Wong 2003 6 ER Diagrams –Inheritance  Subclasses –special-case entity sets with own special attributes and/or relationships  isa relationship : One-One relationship to handle inheritance, to connect entity set to its subclasses. –E.g. every Cartoon is a Movie  ER symbol for isa : isa Super class Subclass (arrows not drawn)

7. © D. Wong 2003 7 Design Principles  Faithfulness : Reflects the reality of the data and the problem with the appropriate: –attributes –data ranges –relationships –cardinality E.g. Stars Movies Stars -in

8. © D. Wong 2003 8 Design Principles (2)  Avoid Redundancy –Redundancy : duplicate representation of data, lead to  Inconsistency, violate data integrity  Waste space E.g. Studios Movies Owns Studio_name

9. © D. Wong 2003 9 Design Principles (3)  Keep it simple : Avoid more elements than needed  Pick the right kind of element –attributes or entity set –what should the relationships be

10. © D. Wong 2003 10 DB design  Centers on the entity sets and relationships making up the database.  Users and designers must work together to: –Specify the entity sets and relationships and their meanings –Specify the attributes and the meaning of it –Specify the constraints –Identify key attributes of entity sets –Specify how the data would be viewed –Specify who can view and modify what and when  Better to do a good job in the original design –Need collaboration of users and designers  Reminder: Changing database design later usually very costly.

11. © D. Wong 2003 11 Constraints  Constraints are part of the schema, not of an instance of the database.  Classification of Constraints –Keys –Single-value constraints –Referential integrity constraints –Domain constraints –General constrains

12. © D. Wong 2003 12 Keys in the E/R Model  Key for an entity set E is a set K of one or more attributes such that, given any two distinct entities e 1 and e 2 in E, e 1 and e 2 cannot have identical values for each of the attributes in the key K. (Ref. 2.3.2) –E.g. Movie(title, year, length, filmtype), E1 = (titanic, 1960, 120, color), E2 = (titanic, 1997, 180, color) –A key can consist of more than one attribute –There can be more than one possible key (candidate keys), but designate one as the “primary key”. –Attributes that constitute the primary key cannot be null –If the entity set is in an isa-hierarchy, require the root entity set have all the attributes needed for a key. –In E/R diagram, attributes of a key are underlined

13. © D. Wong 2003 13 Single-Value Constraints  Assertion: at most one value exists in a given context  Ways to express single-value constraints in E/R: –Each attribute of an entity set has a single value  Some attributes may allow null  Key attributes should not be null  No formal representation in E/R diagram, make a notation beside the attribute –Many-one relationship E F R

14. © D. Wong 2003 14 Referential Integrity  Assertion: exactly one value exists in a given role  Enforced at database implementation –Forbid the deletion of a referenced entity –Require that if referenced entity is deleted, then all entities that reference it are deleted as well.  Use a rounded arrow in the diagram MoviesStudios Owned by 

15. © D. Wong 2003 15 Other kinds of constraints  Domain constraints : restrict the value of an attribute to be in a limited set. –No formal notation in E/R, place a notation next to the attribute –E.g. declaring the type of an attribute –E.g specify range for the attribute value  General constraints –E.g. degree of the relationships MoviesStars Stars-in <=10

16. © D. Wong 2003 16 Definition: An entity set whose key is composed of attributes some or all of which belong to another entity set. Causes: 1.entity sets in a hierarchy based on classification 2.Connecting entity sets to eliminate a muliway relationship. Weak Entity Sets Unit-of Crew Studios number name addr

17. © D. Wong 2003 17 Weak Entity Sets Requirements 1. Key consists of zero or more of its own attributes, and 2. Key attributes from entity sets that are reached by supporting relationships (many-one) 3. R is a supporting relationship for a weak entity set E to some entity set F, R must: –Be a binary, many-one relationship from E to F –R must have referential integrity from E to F –The attributes that F supplies for the key of E must be key attributes of F –If F is weak, then key attributes of F supplied to E may be attributes of some entity set to which F is connected by a supporting relationship (recursive) –For multiple supporting relationship from E to F, each relationship is used to supply a copy of the key attributes of F