MODELS OF DATABASE AND DATABASE DESIGN INTRODUCTION TO ENTITY RELATIONSHIP DIAGRAMS 26/03/2013 T.G.ZHOU

The Entity-Relationship Model- Lecture Overview The Entity - Relationship Model (E-R Model) is a high-level conceptual data model developed by Chen in 1976 to facilitate database design. Conceptual Modeling is an important phase in designing a successful database. A conceptual data model is a set of concepts that describe the structure of a database and associated retrieval and updation transactions on the database. A high level model is chosen so that all the technical aspects are also covered. The E-R model is shown diagrammatically using Entity-Relationship (E-R) diagrams which represent the elements of the conceptual model that show the meanings and the relationships between those elements independent of any particular DBMS and implementation details The slides for this text are organized into chapters. This lecture covers Chapter 2. Chapter 1: Introduction to Database Systems Chapter 2: The Entity-Relationship Model Chapter 3: The Relational Model Chapter 4 (Part A): Relational Algebra Chapter 4 (Part B): Relational Calculus Chapter 5: SQL: Queries, Programming, Triggers Chapter 6: Query-by-Example (QBE) Chapter 7: Storing Data: Disks and Files Chapter 8: File Organizations and Indexing Chapter 9: Tree-Structured Indexing Chapter 10: Hash-Based Indexing Chapter 11: External Sorting Chapter 12 (Part A): Evaluation of Relational Operators Chapter 12 (Part B): Evaluation of Relational Operators: Other Techniques Chapter 13: Introduction to Query Optimization Chapter 14: A Typical Relational Optimizer Chapter 15: Schema Refinement and Normal Forms Chapter 16 (Part A): Physical Database Design Chapter 16 (Part B): Database Tuning Chapter 17: Security Chapter 18: Transaction Management Overview Chapter 19: Concurrency Control Chapter 20: Crash Recovery Chapter 21: Parallel and Distributed Databases Chapter 22: Internet Databases Chapter 23: Decision Support Chapter 24: Data Mining Chapter 25: Object-Database Systems Chapter 26: Spatial Data Management Chapter 27: Deductive Databases Chapter 28: Additional Topics 1

LECTURE OBJECTIVES By the end of the lecture students should be able to: Learn about the components that make up an Entity Relationship Diagram (ERD) using the Chen’s notation

Describe the relationship between entity sets and relationship sets Identify the participation and key constraints in a given scenario Describe the parent/child concept

Overview of Database Design Conceptual design: (ER Model is used at this stage.) What are the entities and relationships in the enterprise? What information about these entities and relationships should we store in the database? What are the integrity constraints or business rules that hold? A database `schema’ in the ER Model can be represented pictorially (ER diagrams). Can map an ER diagram into a relational schema. 2

ER Model Basics Employees ssn name lot Entity: Real-world object distinguishable from other objects. An entity is described (in DB) using a set of attributes. Entity Set: A collection of similar entities. E.g., all employees. All entities in an entity set have the same set of attributes. (Until we consider ISA hierarchies, anyway!) Each entity set has a key. Each attribute has a domain. A key can be a (minimal) set of attributes 3

ER Model Basics (Contd.) name ssn lot Employees since name dname super-visor subor-dinate ssn lot did budget Reports_To Employees Works_In Departments Relationship: Association among two or more entities. E.g., Attishoo works in Pharmacy department. Relationship Set: Collection of similar relationships. An n-ary relationship set R relates n entity sets E1 ... En; each relationship in R involves entities e1, ..., en. Same entity set could participate in different relationship sets, or in different “roles” in same set. 4

Key Constraints since lot name ssn dname did budget Manages Consider Works_In: An employee can work in many departments; a dept can have many employees. In contrast, each dept has at most one manager, according to the key constraint on Manages. Employees Departments Examples: 1-1 -> Dep, Manager 1-many -> Dep, Employees Many-1 -> Employees, Dep Many-Many -> Customers, Items 1-to-1 1-to Many Many-to-1 Many-to-Many 6

Participation Constraints Does every department have a manager? If so, this is a participation constraint: the participation of Departments in Manages is said to be total (vs. partial). Every did value in Departments table must appear in a tuple of the Manages relation. since since name name dname dname ssn lot did did budget budget Employees Manages Departments Works_In since 8

Weak Entities A weak entity can be identified uniquely only by considering the primary key of another (owner) entity. Owner entity set and weak entity set must participate in a one-to-many relationship set (one owner, many weak entities). Weak entity set must have total participation in this identifying relationship set. name cost ssn pname lot age Employees Policy Dependents 10

ISA (`is a’) Hierarchies name ISA (`is a’) Hierarchies ssn lot Employees As in C++, or other PLs, attributes are inherited. If we declare A ISA B, every A entity is also considered to be a B entity. hourly_wages hours_worked ISA contractid Hourly_Emps Contract_Emps Overlap constraints: Can Joe be an Hourly_Emps as well as a Contract_Emps entity? (Allowed/disallowed) Covering constraints: Does every Employees entity also have to be an Hourly_Emps or a Contract_Emps entity? (Yes/no) Reasons for using ISA: To add descriptive attributes specific to a subclass. To identify entities that participate in a relationship. Examples: hourly wages are specific to hourly employees “motor vehicles” participates in “licenses” relationship; see also managers in slide “entity vs. relationship” 12

Aggregation Aggregation vs. ternary relationship: name Aggregation ssn lot Employees Used when we have to model a relationship involving (entity sets and) a relationship set. Aggregation allows us to treat a relationship set as an entity set for purposes of participation in (other) relationships. Monitors until started_on since dname pid pbudget did budget Projects Sponsors Departments For the second point, need to be able to draw an arrow from Monitors to Employees -> key constraint. Aggregation vs. ternary relationship: Monitors is a distinct relationship, with a descriptive attribute. (i.e., until) Also, can say that each sponsorship is monitored by at most one employee. 2