1. 6.1 Chapter 6: Database Design and the ER Model Skip 6.5.3, 6.10, 6.11

2. 6.2 What is involved in database design? Understand the information of interest Understand what you want to do with it Steps:  understand needs of prospective users → requirements specification  conceptual design → ER model  logical design → logical model  physical design → file organization, internal storage,... Focus on the information Not part of this but important later:  queries  application programs What can go wrong?  leaving out information you will need  misunderstanding the information

3. 6.3 Your Project What is the enterprise What is the information of interest What do you want to do with it

4. 6.4 Modeling A database can be modeled as:  a collection of entities  relationship among entities An entity is an object that exists and is distinguishable from other objects  example: specific person, company, event, plant Entities have attributes  example: people have names and addresses An entity set is a set of entities of the same type that share the same properties  example: set of all persons, companies, trees, holidays

5. 6.5 Entity Sets customer and loan customer_id customer_ customer_ customer_ loan_ amount name street city number

6. 6.6 Relationship Set borrower Distinction between relation (relational model) and relationship set (ER model) This is the set of links between two entity sets

7. 6.7 Relationship Sets (Cont.) A relationship set can have an attribute E.g. the depositor relationship may have attribute access_date

8. 6.8 Degree of a Relationship Set Relationship sets may involve more than two entity sets Example: employees of a bank may have jobs at different branches Ternary relationship set among entity sets employee, job, and branch employee(name,..) job(title,...)branch(name, city, assets) Smith.. (employee info) teller...(duties etc.)CNLB Aurora 10000 Jones... custodian... First Bank Auburn 1000 loan officer... Degree: number of entity sets that participate in a relationship set Most relationship sets are binary

9. 6.9 Attributes An entity has attributes (like a relation) customer = (cust_id, cust_name, cust_street, cust_city loan = (loan_number, amount ) Attribute types:  simple and composite  single-valued and multi-valued multivalued: phone_numbers  derived: can be computed from other attributes example: age, given date_of_birth

10. 6.10 Mapping Cardinalities The number of entities to which another entity can be associated via a relationship set Most useful in describing binary relationship sets For a binary relationship set the mapping cardinality is  one to one (monogamy)  one to many (polygyny)  many to one (polyandry)  many to many (group marriage)

11. 6.11 Mapping Cardinalities Some elements in A and B may not be mapped to any elements in the other set one to one one to many many to one many to many

12. 6.12 Keys Super key, candidate key, primary key for entity sets as before Keys for relationship sets? Combining primary keys of the participating entity sets forms a super key of a relationship set (customer_id, account_number) is the super key of borrower

13. 6.13 E-R Diagrams Rectangles represent entity sets. Diamonds represent relationship sets. Lines link attributes to entity sets and entity sets to relationship sets. Ellipses represent attributes  double ellipses represent multivalued attributes.  dashed ellipses denote derived attributes. Underline indicates primary key attributes

14. 6.14 E-R Diagram With Composite, Multivalued, and Derived Attributes

15. 6.15 Relationship Sets with Attributes

16. 6.16 Roles Entity sets of a relationship need not be distinct Labels “manager” and “worker” are roles Roles are indicated by labeling the lines that connect diamonds to rectangles (optional)

17. 6.17 Cardinality Constraints Express cardinality constraints by drawing either a directed line (  ), signifying “one,” or an undirected line (—), signifying “many,” between the relationship set and the entity set. One-to-one relationship:  a customer is associated with at most one loan via the relationship borrower  a loan is associated with at most one customer via borrower

18. 6.18 Indicating Cardinality Constraints By directed (  = “one”) or undirected lines (— = “many”) One-to-one:  a customer is associated with at most one loan via relationship borrower  a loan is associated with at most one customer via borrower

19. 6.19 One-To-Many (a) and Many-To-One (b) ( a) a loan is associated with at most one customer via borrower, a customer many have several (including 0) loans (b) a loan is associated with several (including 0) customers via borrower...

20. 6.20 Many-To-Many Relationship A customer is associated with several (possibly 0) loans via borrower A loan is associated with several (possibly 0) customers via borrower

21. 6.21 Participation of an Entity Set in a Relationship Set Total participation (indicated by double line): every entity in the entity set participates in at least one relationship in the relationship set  participation of loan in borrower is total every loan must have a customer associated to it via borrower Partial participation: some entities may not participate in any relationship in the relationship set  example: participation of customer in borrower is partial

22. 6.22 Participation of an Entity Set in a Relationship Set Total participation (indicated by double line): every entity in the entity set participates in at least one relationship in the relationship set.  participation of loan in borrower is total: every loan must have a customer associated with it. Partial participation: some entities may not participate in any relationship in the relationship set.  participation of customer in borrower is partial: some customers have no loans.

23. 6.23 Alternative Notation for Cardinality Limits Cardinality limits can also express participation constraints

24. 6.24 E-R Diagram with a Ternary Relationship

25. 6.25 Cardinality Constraints on Ternary Relationships At most one arrow out of a ternary (or greater degree) relationship.  e.g. an arrow from works_on to job indicates each employee works on at most one job at any branch. More than one arrow allows two meanings.  e.g. an arrow from works_on to job and branch R between A, B and C with arrows to B and C could mean 1. each employee works on most one job at one branch or 2. each (employee, job) pair is associated with a unique branch entity, and each (employee, branch) pair is associated with a unique job To avoid confusion, allow only one arrow

26. 6.26 Design Issues Use of entity sets vs. attributes  exercise: construct a diagram for a child with mother and father as attributes. Is there a better way? Use of entity sets vs. relationship sets  exercise: replace job by attributes of works_on in slide 24  compare the two Binary versus n-ary relationship sets  is there a neat way to represent slide 24 using binary relationships? Placement of relationship attributes  can access_date in slide 15 be an attribute of loan under an conditions?

27. 6.27 Binary Vs. Non-Binary Relationships Some relationships that appear to be non-binary may be better represented using binary relationships  e.g. a ternary relationship parents, relating a child to his/her father and mother, might best be replaced by two binary relationships, father and mother  using two binary relationships allows partial information (e.g. only mother being known)  some relationships are naturally non-binary (works_on, slide 24) Non-binary relationships can be converted to binary: (don't bother)

28. 6.28 Mapping Cardinalities affect ER Design Can make access_date an attribute of account, instead of a relationship attribute, if each account can have only one customer That is, the relationship from account to customer is many to one, or equivalently, customer to account is one to many

29. 6.29 Weak Entity Sets An entity set that does not have a primary key is referred to as a weak entity set. The existence of a weak entity set depends on the existence of a identifying entity set  it must relate to the identifying entity set via a total, one-to-many relationship set from the identifying to the weak entity set  identifying relationship depicted using a double diamond The discriminator (or partial key) of a weak entity set is the set of attributes that distinguishes among all the entities of a weak entity set. The primary key of a weak entity set is formed by the primary key of the strong entity set on which the weak entity set is existence dependent, plus the weak entity set’s discriminator.

30. 6.30 Weak Entity Sets Weak entity set: An entity set that has no primary key. Its existence depends on the existence of a strong entity set.  There is no payment without an associated loan.  If a loan entity is deleted, all associated payments must be deleted. Depicted by  double rectangles  double lines (total participation)  one-to-many cardinality (one loan may have many payments).

31. 6.31 Weak Entity Sets (Cont.) The discriminator (or partial key) of a weak entity set is the set of attributes that distinguishes it among all the other entities dependent on the same strong entity.  payment_number – discriminator of the payment entity set The primary key of a weak entity set: the primary key of the associated strong entity set plus the discriminator.  primary key for payment – (loan_number, payment_number) Exercise: Construct an ER diagram for strong entity course and weak entity course_offering. What are the primary and partial keys?

32. 6.32 More Weak Entity Set Examples In a university, a course is a strong entity and a course_offering can be modeled as a weak entity The discriminator of course_offering would be semester (including year) and section_number (if there is more than one section) If we model course_offering as a strong entity we would model course_number as an attribute. Then the relationship with course would be implicit in the course_number attribute

33. 6.33 Extended E-R Features: Specialization Top-down design process; we designate sub groupings within an entity set that are distinctive from other entities in the set. These sub groupings become lower-level entity sets that have attributes or participate in relationships that do not apply to the higher-level entity set. Depicted by a triangle component labeled ISA (E.g. customer “is a” person). Attribute inheritance – a lower-level entity set inherits all the attributes and relationship participation of the higher-level entity set to which it is linked.

34. 6.34 Specialization Analogous to inheritance in C++. Top-down design process.  Designate sub groupings within an entity set.  These become lower-level entity sets that have attributes or relationships that do not apply to the higher-level entity set. Depicted by a triangle component labeled ISA (i.e., saving_account “is an” account). Attribute inheritance: a lower-level entity set inherits the attributes and relationship participation of the higher-level entity set.

35. 6.35 Specialization Example

36. 6.36 Generalization Bottom-up: combine entity sets that share some features into a higher-level entity set. Specialization and generalization are inverses. Represented in an E-R diagram in the same way. The terms are used interchangeably. Can have multiple specializations based on different features. E.g.  permanent_employee vs. temporary_employee  officer vs. secretary vs. teller An employee would be in each specialization The ISA relationship also referred to as superclass - subclass relationship

37. 6.37 Specialization/Generalization Design Constraints Which entities can be in a given lower-level entity set.  condition-defined. E.g. all customers over 65 are members of senior_citizen entity set.  user-defined Whether or not entities may belong to more than one lower-level entity set.  disjoint an entity can belong to only one lower-level entity set noted in E-R diagram by writing disjoint next to the ISA triangle  overlapping an entity can belong to more than one lower-level entity set Completeness – whether an entity in the higher-level entity set must belong to at least one of the lower-level entity sets.  total: an entity must belong to one of the lower-level entity sets  partial: an entity need not belong to one of the lower-level entity sets

38. 6.38 Aggregation Suppose we have a ternary relationship works_on and want to record managers for tasks performed by an employee at a branch

39. 6.39 Aggregation (Cont.) works_on and manages represent redundant information  every manages relationship corresponds to a works_on relationship  some works_on relationships may not correspond to any manages So we can’t discard works_on  eliminate this redundancy via aggregation The diagram represents:  an employee works on a particular job at a particular branch  an employee, branch, job combination may have an associated manager

40. 6.40 Another Aggregation Example Loan customers may be advised by a loan_officer. How do we relate the customer/loan with the loan_officer?

41. 6.41 E-R Diagram for a Banking Enterprise

42. 6.42 Reduction Relation Schemas An E-R diagram for a database can be represented by a collection of relation schemas. Each entity set  schema (table) with same name Each relationship  schema with same name Each schema has attributes Process: E-R diagram  relation schemas  relational database.

43. 6.43 Example: customer(customer_id, customer_name, customer_street, customer_city) account(account_number, balance) depositor(customer_id, account_number, access_date)

44. 6.44 What about this one? Option 1: account(account_number, balance, branch_name) branch (branch_name, branch_city, assets) account_branch (account_number, branch_name) Option 2: account (account_number, balance, branch_name) branch(branch_name, branch_city, assets) (Many-to-one and one-to-many relationship sets that are total on the many-side can be represented by adding the primary key of the one side to the many side)

45. 6.45 This one? Option 1: customer (customer_id, customer_name, customer_street, customer_city), loan (branch_name, branch_city, assets), borrower (account_number, branch_name) Option 2: customer (customer_id, customer_name, customer_street, customer_city, branch_name, branch_city, assets) Why?

46. 6.46 Representing Weak Entity Sets The strong entity becomes a schema with all its attributes. The weak entity includes a column for the primary key of the identifying strong entity set. loan( loan_number, amount) payment(loan_number, payment_number, payment_date, payment_amount)

47. 6.47 Composite Attributes Composite attributes are flattened out by creating a separate attribute for each component attribute customer(customer_id,..., name.first_name, name,middle_initial, name,last_name, address.street.street_number,...)

48. 6.48 Multivalued Attributes Multivalued attribute M of entity E is represented by a separate schema EM with attributes corresponding to the primary key of E and multivalued attribute M Suppose a customer has multiple names customer(customer_id, customer_name, customer_street, customer_city) becomes customer(customer_id, customer_street, customer_city) names(customer_id, customer_name)

49. 6.49 Representing Generalization as Schema Method 1: A schema for the higher-level entity(person) A schema for each lower entity set with the primary key of the generalized entity set. person(name, street, city) employee(name, salary) customer(name, credit_rating) employer(name, salary) officer(name, office_number)... Drawback: getting information about, a customer requires accessing two or more relations, the one corresponding to the low-level schema and the one corresponding to the high-level schema

50. 6.50 Representing Generalization as Schema Method 2: A schema for each lower entity set with all attributes of the generalized entity set. officer(name, street, city, salary, office_number) customer(name, street, city, credit_rating)... If specialization is total, the schema for the generalized entity set (person) not required to store information Drawback: street and city may be stored redundantly for people who are both customers and officers Why might one be preferable?

51. 6.51 Relations Corresponding to Aggregation Create a table containing 1. primary key of the aggregated relationship, 2. primary key of the associated entity set, 3. any descriptive attributes manages(employee_id, branch_name, title, manager_name). works_on is redundant if we are willing to store null values for attribute manager_name in table manages

52. 6.52 UML (Unified Modeling Language) Notation See CS 310 Chapter 7, slide 13

53. 6.53 UML Class Diagram Notation (Cont.) *Note reversal of position in cardinality constraint depiction *Generalization can use merged or separate arrows independent of disjoint/overlapping overlapping disjoint

54. 6.54 E-R Diagram for Exercise 6.11

55. 6.55 E-R Diagram for Exercise 6.21