lecture2.pdf
- 3. Common Data Models • We have standard techniques for translating between data models. UML/OO ER Relational class entity type relation/table object entity tuple/row attribute attribute attribute/column association relationship foreign key key attribute primary key inheritance inheritance foreign key
- 4. Common Data Models • UML and ER have graphical notations • very good for conceptual design • very expressive: capture more application semantics • Relational model is an implementation model • not good for conceptual design • not very expressive: many concepts map to same notation
- 5. Entity Types • Entity types àboxes Weak entity type à double box EMPLOYEE Entity DEPENDENT Weak Entity
- 6. Entity Types • Entity types are similar to classes, they describe potential objects (entities) that will appear in the database. • Weak entity types describe dependent entities, entities that depend on other entities for identity. EMPLOYEE Entity DEPENDENT Weak Entity
- 7. Attributes and Keys • Attributes àovals • Key attributes à underlined name • Partial key attributes àdotted underlined name Age Attribute Key Attribute SSN Partial Key Attribute Date
- 8. Attributes and Keys • Key attributes must be unique for each entity • Keys are used to identify particular entities • Partial keys are only partially unique • used for weak entity types Age Attribute Key Attribute SSN Partial Key Attribute Date
- 9. Entity Types and Attributes • Attributes are connected to entity types by lines EMPLOYEE Phone EID Name DEPENDENT Age Name
- 10. Entity Types and Entities • Entities are instances of an entity type.
- 11. Entity Types and Keys • All regular entity types must have a key attribute or set of key attributes • Weak entity types must have partial keys • Weak entities get part of their key (and part of their identity) from some related entity.
- 12. Sets and Derived Attributes • Multivalued attributes à double lined oval • multivalued = set valued • that there may be more than one value for the attribute. • Derived attributes à dashed line ovals • the attribute is computed from other data Locations Multivalued Attribute NumEmployees Derived Attribute
- 13. Composite Attributes • Composite attributes à tree • composed of other attributes. • used for a set of related attributes, when the set is not a conceptual entity • the composite doesn’t have identity … it doesn’t have a key Composite Attribute ZipCode State Address Street City
- 15. Relationships • Relationships à diamonds • Identifying relationship à double diamond WorksOn Relationship Identifying Relationship DependentOf
- 16. Relationships • Relationships indicate a meaningful connection between two entity types • Relationships may have attributes, but they cannot have key attributes. • Identifying relationships connect a weak entity type to some other entity type • indicates where the weak entity gets a key to complete its own partial key WorksOn Relationship Identifying Relationship DependentOf
- 18. Participation and Cardinality • Participation and cardinality define constraints on relationships • Participation indicates whether an entity is required to take part in a relationship • Cardinality ratios and structural constraints place limits on the number of entities that may participate in a relationship
- 19. Participation Constraints • Total participation à double or thick line • indicates required participation • Partial participation à thin line • indicates optional participation WorksFor Total Participation EMPLOYEE DEPARTMENT WorksOn Partial Participation EMPLOYEE PROJECT
- 20. Participation Constraints • Arrowheads can be used to indicate an upper bound of 1 for participation • (not used in our textbook) R X must participate in exactly one R X Y R X may participate in at most one R X Y
- 21. Cardinality Ratios • Cardinality ratios specify the maximum number of relationship instances that an entity may participate in Manages 1:1 ratio EMPLOYEE DEPARTMENT 1 1 WorksFor n:1 ratio EMPLOYEE DEPARTMENT n 1 WorksOn n:m ratio EMPLOYEE PROJECT n m
- 22. Structural Constraints • Structural constraints specify the minimum and maximum number of relationship instances that an entity may participate in WorksFor An employee must work for exactly 1 department. A department must have at least 4 employees. EMPLOYEE DEPARTMENT (1,1) (4,n) Manages An employee may manage at most 1 department. A department must have exactly 1 manager. EMPLOYEE DEPARTMENT (0,1) (1,1)
- 23. Participation and Cardinality • There’s generally numerous ways to express a relationship constraint. (0,N) optional participation in any number of relationships optional participation in at most one relationship required participation in at least one relationship required participation in exactly one relationship (0,1) (1,N) (1,1)
- 24. Equivalent Notations • An employee can manage at most one department. • A department must have exactly one manager. Manages EMPLOYEE DEPARTMENT (0,1) (1,1) Manages EMPLOYEE DEPARTMENT 1 1 Manages EMPLOYEE DEPARTMENT
- 25. Equivalent Notations • An employee must work for exactly one department. • A department must have at least one employee. WorksFor EMPLOYEE DEPARTMENT (1,1) (1,n) n WorksFor EMPLOYEE DEPARTMENT 1 WorksFor EMPLOYEE DEPARTMENT
- 26. Relationship Instances WorksFor EMPLOYEE DEPARTMENT (1,1) (1,n) Each EMPLOYEE instance is connected to exactly one WORKS_FOR instance. Each DEPARTMENT instance is connected to at least one WORKS_FOR instance.
- 27. Relational Roles • It is sometimes convenient to name an entity’s role in a relationship. • particularly useful in recursive relationships • removes ambiguity in direction of relationship (0,N) (0,1) EMPLOYEE Supervision supervisor supervisee
- 28. Recursive Relationship (0,N) (0,1) EMPLOYEE Supervision supervisor supervisee 1 = supervisor 2 = supervisee
- 29. Notation Summary
- 32. Equivalent Schema defined in UML
- 35. Design an ER schema for the following enterprise: