The Entity-Relationship Model

421B: Database Systems - ER Model 2 Overview of Database Design q Conceptual Design -- A first model of the real world (using ER modeling) I What are the entities and relationships in the enterprise? I What information about these entities and relationships should we store in the database? I What are the integrity constraints or business rules that hold? I A database “schema” in the ER Model can be represented pictorially (ER diagrams) I An ER schema should be understandable by non- computer scientists. I We can map an ER diagram into a relational schema

421B: Database Systems - ER Model 3 ER Model Basics q Entity: Real-world object distinguishable from other objects. An entity is described using a set of attributes. q Entity Set: A collection of similar entities, e.g., all employees (similarity to a “class” in OO) I All entities in an entity set have the same attributes (until we consider ISA hierarchies later…). An attribute describes a property of the entity set. I Each entity set has a key: l Minimum set of attributes whose values uniquely identify an entity in the set I Each attribute has a domain: l Integer, 20-character string Employees eid name lot Entity set = rectangle, Attribute = oval

421B: Database Systems - ER Model 4 ER Model Basics (Contd.) q Relationship: Association among two or more entities. E.g. Miller works in Pharmacy department. q Relationship Set: Collection of similar relationships I An n-ary relationship set R relates n entity sets E1…En; each relationship in R involves entities e1  E1, …. en  En Same entity set could participate in different relationship sets, or in different roles in the same set. Employees eid name salary Works_in Departments did dname budget since eid did since

421B: Database Systems - ER Model 5 ER Model (contd.) Employees eid name salary Reports_To supervisor subordinate Employees with different roles in a relationship 3-ary relationship Works_in Departments did dname budget since Employees eid name salary Location address capacity Role indicator: supervisor/subordinate

421B: Database Systems - ER Model 6 Multiplicity: Many-to-many q Works_In: I An employee can work in several departments; department has several employees I Many-many relationship between departments and employees Employees eid name salary Departments diddname budget Works_In Many to many

421B: Database Systems - ER Model 7 Multiplicity: one-to-many,many-to-one q Manages: I One employee can manage several departments; each department is managed by only one employee; I One-to-many relationship between employee and department I Many-to-one relationship between department and employee; I The condition “each department is managed by only one employee” is called a key constraint on Manages and depicted with arrow from Departments to Manages Employees eid name salary Manages Departments diddname budget since One to many

421B: Database Systems - ER Model 8 Multiplicity: one-to-one q Manages-2: I Each employee can only manage one department; each department is managed by only one employee; I One-to-one relationship between Employees and Departments I Key constraints in both directions One to one Employees eid name Manages Departments diddname budget since salary

421B: Database Systems - ER Model 9 Participation Constraints q Manages-3: I Each department must have a manager: the participation constraint requires that the participation of Departments in Manages is total (vs. partial) (depicted with a thick line) Employees eid name Manages Departments diddname budget since salary

421B: Database Systems - ER Model 10 Weak Entities q A weak entity can be identified uniquely only by considering the primary key of another (owner) entity. I Owner entity set and weak entity set must participate in a supporting one-to-many relationship set (one owner, many weak entities). I Weak entity set must have total participation in this identifying set. Employees eid name salary Policy cost Dependants pname dateofbirth

421B: Database Systems - ER Model 11 ISA (“is a”) Hierarchies: Subclasses q Subclass = special case = fewer entities = more properties q “A ISA B”, then every A entity is also a B entity I Key only in B. q Reasons for using Subclasses: I Additional descriptive attributes specific for a subclass I Identification of a subclass that participates in a relationship q Where do the entities reside: I E/R-viewpoint: An entity has a component in each entity set to which it logically belongs. Its properties are the union of these entity sets. I Contrast OO-viewpoint: An object belongs to exactly one class. The subclass inherits the attributes of its superclass. Employees eid name ISA Hourly_Emps hourly_wages hours_worked Contract_Emps Contract_id salary?

421B: Database Systems - ER Model 12 ISA Hierarchies (Contd.) q Overlap Constraint: Can an entity be in more than one subclass? (allowed/disallowed) q Covering Constraint: Must every entity of the superclass be in one of the subclasses? (yes/no) q Developing Class Hierarchies I Specialization: Identifying subsets of an entity set (the superclass) that share some distinguishing characteristic. Represents top-down design: superclass is first, then subclasses are defined and specific attributes and relationships are set. I Generalization: Several entity sets are generalized into a common entity set. Represents bottom-up design: common characteristics of a collection of entity sets are identified, a superclass entity set is built with these characteristics as attributes. q Theoretically multiple inheritance possible, in practice not used

421B: Database Systems - ER Model 13 Aggregation q Aggregation allows us to treat a relationship set R as an entity set so that R can participate in (other relationships). q Aggregation vs. ternary relationship: I Monitors is a distinct relationship with a descriptive attribute I Can provide additional multiplicity constraints Employees eid name salary Monitors until Projects pid Started_on pbudget Sponsors since Departments diddname budget

421B: Database Systems - ER Model 14 Conceptual Design with ER q Design Principles: I Keep it simple I Avoid redundancies I Capture as many constraints as possible q Design Choices I Entity or attribute? I Attributes and relationships I Identifying relationships: Binary or ternary? Aggregation?

421B: Database Systems - ER Model 15 Design Principles q Avoid redundancies and keep it simple Suppliers sname offer Parts pid Parts name pid address sname saddress name Suppliers sname offer Parts pid name Parts name pid sname Avoid Redundancy Keep it simple

421B: Database Systems - ER Model 16 Relationships and Attributes Employees eid name Manages Departments diddname budget since salary mbudget Employees eid name salary ISA Managers Manages Departments diddname budget since mbudget

421B: Database Systems - ER Model 17 Entity vs. Attribute q Should address be an attribute of Employees or an entity (connected to Employees by a relationship)? q Depends on the use and the semantics of the information I If we have several addresses for each employee, address must be an entity (since attributes cannot be set-valued). I If address represents a lodging or place of business and hence is a real object that is independent of the people who live or work there, then it should be an entity I Note, it we want to capture the structure of address (because we want to retrieve all employees in a given city), we must use several separate attributes (street, zip, city, etc.). This can happen within the Employees entity or as an extra entity.

421B: Database Systems - ER Model 18 Entity vs. Relationship Suppliers sid name Order Parts name pid Department did dname quantity Suppliers sid name Order Parts name pid Department did dname quantity oid date

421B: Database Systems - ER Model 19 Binary vs. Ternary Relationships q Situation I: I employee can own several policies I each policy can be owned by several employees I each dependent can be covered by several policies I a policy can cover several dependents q Situation II: I employee can own several policies I each policy has only one owner I each dependent is identified by its policy I a policy can cover several dependents Employees eid name salary covers Dependents pname Policies pid cost Dependents pname dob beneficiary Policies purchaser Employees eid name pid cost dob salary

421B: Database Systems - ER Model 20 Summary q Conceptual design follows requirement analysis I Yields a high-level description of data to be stored q ER model popular for conceptual design I Constructs are expressive, close to way people think about their applications q Basic constructs: entities, relationships, and attributes (of entities and relationships) q Some additional constructs: weak entities, ISA hierarchies, and aggregation q Note: there are many variations on ER model q Alternative: UML

421B: Database Systems - ER Model 21 Summary (contd.) q Several kinds of integrity constraints can be expresses in the ER model: key constraints, participation constraints, overlap/covering constraints for ISA hierarchy. Some foreign key constraints are also implicit in the definition of the relationship set q Some constraints (notably, functional dependencies) cannot be expressed in the ER model q Constraints play an important role in determining the best database design for an enterprise

421B: Database Systems - ER Model 22 Summary (contd.) q Conceptual design is subjective. There are often many ways to model a given scenario! Analyzing alternatives can be tricky, especially for a large enterprise. Common choices include I Entity vs. attribute, entity vs. relationship, binary or n-ary relationship, whether or not to use ISA hierarchies, and whether or not to use aggregation q Ensuring good database design: resulting relational schema should be analyzed and refined further. FD information and normalization techniques are especially useful

421B: Database Systems - ER Model 23

421B: Database Systems - ER Model 24 Binary vs. Ternary vs. Aggregation q Situation : I Stars play in movies and movies are produced by studios I Several constraints possible: l Each movie is only produced by one studio l A star has only a single contract for a movie (even if several studios involved) l A contract for a movie is always between a star and a single studio (even if several studios involved) Stars Movies Studios q Solution I: I Ternary relation I Each arrow would lead to a nonsense restriction I Consequence: l Each movie can be produced by several studios l But only possible if at least one star has contract with this studio for this movie

421B: Database Systems - ER Model 25 Binary vs. Ternary vs. Aggregation q Solution II: I Two binary relations I movie produced by one studio possible I A star plays now exactly once for a movie (with one contract) I But if several studios produce a movie we cannot express with which studio the contract is done q Solution III: I Aggregation I movie produced by one studio possible I Star can have one or more contracts for a movie; each with a different studio Studios produce Movies play Stars Movies stars Studios produce play

421B: Database Systems - ER Model 26 Attributes of Relationships q Given a relationship set R between entity sets E1 and E2 and its own attributes r1,…rr. If for a given instance (e1,e2) of the relationship there exist several values for the attributes r1,…rr, we have to add a new entity to the relationship Employees ssn name lot Works_in2 Departments did dname budget from to Employees ssn name lot Works_in3 Departments did dname budget from to Duration

421B: Database Systems - ER Model 27 Binary vs. Ternary Relationships (contd.) Suppliers sid name Order Parts name pid Department did dname quantity q Ternary: I Order lists the last order of company X of part Y at supplier Z IS NOT THE SAME AS q Binary I Supplier offer Parts I Companies own Parts I Company deals with Supplier Suppliers sid name offer Parts name pid Departments did name needs Parts name pid Departments cid name deal with Suppliers name sid