1. 1 CSE 480: Database Systems Lecture 3: Entity-Relationship Diagram Reference: Read Chapter 3 (5 th Edition) or 7 (6 th edition)

2. 2 Review l ER diagram –Entity types, attributes, and their constraints  Key, domain, and null constraints –Relationship types l Today’s lecture –Relationship constraints –Weak entity types –Ternary relationship types l Announcement: homework 1 is posted!

3. 3 Constraints on Relationship Types Constraint on the number of times an entity participates in a relationship type

4. 4 Constraints on Relationship Types l Two types of constraints: –Cardinality Ratio (specifies maximum participation) –Participation constraint (specifies minimum participation) PROJECT EMPLOYEE WORKS_ON –Examples:  Can an employee work on more than one project?  Can a project have more than one employee?  Must every employee work on a project?  Must a project have at least one employee?

5. 5 Cardinality Ratios for Binary Relationships l Possible cardinality ratios: –1:1 (one-to-one) –1:N (one-to-many) –N:1 (many-to-one) –M:N (many-to-many) 11 1 N 1N MN

6. 6 Cardinality Ratios for Binary Relationships l 1:1 (one-to-one) –An employee manages at most 1 department –Each department has at most 1 manager 11 EMPLOYEE DEPARTMENT MANAGES

7. 7 Cardinality Ratios for Binary Relationships l 1:N (one-to-many) N:1 (many-to-one) –A department can have more than one employees –An employee works for at most 1 department N1 EMPLOYEE DEPARTMENT WORKS_FOR Be careful where you put the 1 and N!!

8. 8 Cardinality Ratios for Binary Relationships l 1:N (one-to-many) N:1 (many-to-one) –An employee can supervise many subordinates –An employee has at most one supervisor SUPERVISION 1 N Roles: 1: supervisor 2: subordinate

9. 9 Cardinality Ratios for Binary Relationships l M:N (many-to-many) –An employee can work on more than one project –A project can have more than one employee working on it MN EMPLOYEE PROJECT WORKS_ON

10. 10 Participation Constraints l Specifies the minimum cardinality constraint –This also determines whether the existence of an entity depends on it being related to another entity via the relationship type l Two types: –Total participation (also called existence dependency) –Partial participation R E RE Every entity must participate in at least 1 relationship Some entities do not participate in any relationship

11. 1 Participation Constraint & Cardinality Ratio –Every employee must work for at least one department –Each department must have at least one employee EMPLOYEEDEPARTMENT WORKS_FOR EMPLOYEEDEPARTMENT WORKS_FOR N 1 –Each employee works for exactly one department –Each department has at least one employee

12. 12 Participation Constraint & Cardinality Ratio –Some employees do not manage any department –Every department must have at least one manager EMPLOYEEDEPARTMENT MANAGES EMPLOYEEDEPARTMENT MANAGES 1 1 –Some employees manages a department and others don’t –Every department has exactly one employee managing it

13. 13 Participation Constraint & Cardinality Ratio –Some employees are not supervisors –Some employees are not subordinates –Some employees supervise one or more employees; others do not –Some employees have a supervisor; others do not SUPERVISION 1 N

14. 14 (min, max) notation l Specify the minimum and maximum participation of an entity type in a relationship type EMPLOYEEDEPARTMENT WORKS_FOR N 1 is equivalent to: l Default(no constraint): min=0, max=n (signifying no limit)

15. 15 (min,max) notation EMPLOYEEDEPARTMENT MANAGES 1 1 is equivalent to:

16. 16 (min,max) notation is equivalent to: SUPERVISION 1 N (0,1) (0,N)

17. 17 COMPANY ER Diagram using (min, max)

18. 18 Strong vs Weak Entity Types DEPARTMENTPROJECT CONTROLS 1 N EMPLOYEEDEPENDENT DEPENDENTS_OF 1 N –Every project must have a controlling department –Every dependent must be a dependent of an employee Strong entity type Weak entity type –If a department “dissolves”, project info may still exist –If an employee leaves, dependent info no longer exists

19. 19 Weak Entity Types l A weak entity must participate in an identifying relationship type with its owner or identifying entity type l A weak entity type does not have a key attribute. It is identified by the combination of: –A partial key of the weak entity type –The key attributes of the entities it is related to in the identifying entity type l Example: –A DEPENDENT entity is identified by the dependent’s first name and the specific EMPLOYEE with whom the dependent is related –Name of DEPENDENT is the partial key –DEPENDENT is a weak entity type –EMPLOYEE is its identifying entity type via the identifying relationship type DEPENDENT_OF

20. 20 Weak Entity Type EMPLOYEEDEPENDENT DEPENDENTS_OF 1 N SSN Name Sex Birth_date Relationship Weak entity type Identifying Relationship Partial key Key for Dependent entity is (SSN, Name) Owner entity type Total participation

21. 21 Strong Entity Type DEPARTMENTPROJECT CONTROLS 1 N SSN Number Name Location Strong entity type Key for Project entity is either Project Name or Project Number key

22. 2 Summary of notation for ER diagrams

23. 23 Exercise l You have been hired to develop a social networking Web site that allows users to meet and make friends with other users. The Web site records the personal profile of each user including full name, email address, year of birth, hometown, and interests (both in music and movies). Each user is identified by a unique user id. A privacy setting is provided for each user. If the privacy setting is low (which is the default setting), their full profile (with the exception of password) will be accessible by all other users. If privacy setting is high, only those who are friends with the user may view the full profile. l Each user has a blog, which has a URL and contains zero or more blog postings. A blog posting has a timestamp and a text message. A user may add comments to the blog postings of another user only if the blogger’s privacy setting allows the user to view his/her postings. The database keeps track of the timestamp of each comment l A user can send request to be friends with other users. Once the request has been sent, the recipient must accept the request in order to establish a “friendship” relation. l Users can post announcements of events. Each event is characterized by a unique event id, a time and place where the event will be held, and a short description of the event.

24. 24 Exercise

25. 25 Relationships of Higher Degree l So far, we’ve looked at binary relationship types l Relationship types of degree 3 are called ternary l Relationship types of degree n are called n-ary

26. 26 Example of a ternary relationship SUPPLY relationship instance: (s,j,p) A supplier s supplies part p to project j

27. 27 Ternary vs Binary Relationship Types Suppose (s,j), (j,p), and (s,p) participate in the relationships SUPPLIES, USES, and CAN_SUPPLY, respectively Is this equivalent to the instance (s,j,p) in ternary relationship? 3 binary relationships

28. 28 Example of a ternary relationship SupplierProjectPart AceR1T1 AceR2T2 AcmeR1T2 AcmeR2T1 LowesR1T1 LowesR2T2 SupplierProject AceR1 AceR2 AcmeR1 AcmeR2 LowesR1 LowesR2 ProjectPart R1T1 R1T2 R2T1 R2T2 SupplierPart AceT1 AceT2 AcmeT2 AcmeT1 LowesT1 LowesT2

29. 29 Ternary Relationships TAUGHT_DURING and OFFERED_DURING are redundant, but CAN_TEACH is not redundant 3 binary relationships may represent different info than a single ternary relationship

30. 30 Cardinality Ratio of Ternary Relationships 1 M N There is 1 supplier for every (project, part) combination A supplier can supply same part to more than 1 project A supplier can supply more than 1 part to a project