Data Modeling and the Entity-Relationship Model Chapter Four DAVID M. KROENKE’S DATABASE CONCEPTS, 2 nd Edition

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-2 Chapter Objectives Learn the basic stages of database development Understand the purpose and role of a data model Know the principal components of the E-R data model Understand how to interpret both traditional and UML-style E-R diagrams Learn to construct traditional E-R diagrams Know how to represent 1:1, 1:N, N:M, and binary relationships with the E-R model

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-3 Chapter Objectives (continued) Know how to represent recursive relationships with the E-R model Understand two types of weak entities and know how to use them Learn how to create an E-R diagram from source documents

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-4 Three Stages of Database Development Requirements Stage Design Stage Implementation Stage

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-5 The Requirements Stage Sources of requirements –User Interviews –Forms –Reports –Queries –Use Cases –Business Rules

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-6 Requirements Become the E-R Data Model After the requirements have been gathered, they are transformed into an Entity Relationship (E-R) Data Model E-R Models consist of –Entities –Attributes –Identifiers –Relationships

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-7 Entities An entity is something that users want to track –CUSTOMER –PROJECT –EMPLOYEE –STUDENT

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-8 Instance versus Classes An entity class is a description of the structure and format of the occurrences of the entity An entity instance of a specific occurrence of an entity class

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-9 Instance versus Classes CUSTOMER CustID CustName Jackson Co Smither, Inc Two Entity Instances Entity Class

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-10 Attributes Entities have attributes that describe the entity’s characteristics –ProjectName –StartDate –ProjectType –ProjectDescription Attributes have a data type and properties

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-11 Identifiers Entity instances have identifiers An identifier will identify a particular instance in the entity class –SocialSecurityNumber –StudentID –EmployeeID

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-12 Identifier Types Uniqueness –Identifiers may be unique or nonunique –If the identifier is unique, the data value for the identifier must be unique for all instances Composite –A composite identifier consists of 2 or more attributes E.g., OrderNumber & LineItemNumber are both required

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-13 Relationships Entities can be associated with one another in relationships Relationship degree defines the number of entity classes participating in the relationship –Degree 2 is a binary relationship –Degree 3 is a ternary relationship

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-14 Degree 2 Relationship - Binary LOCKEREMPLOYEE

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-15 Degree 3 Relationship - Ternary DEALERMODEL MAKE

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-16 One-to-One Binary Relationship 1:1 (one-to-one) –A single entity instance in one entity class is related to a single entity instance in another entity class

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-17 One-to-One Binary Relationship An employee may have no more than one locker; and A locker may only be accessible by one employee LOCKEREMPLOYEE 1:1

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-18 One-to-Many Binary Relationship An employee may only work for one department; and A department has several employees DEPARTMENTEMPLOYEE 1:N

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-19 Many-to-Many Binary Relationship An employee may have several skills; and A particular skill may be held by several employees SKILLEMPLOYEE N:M

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-20 One-to-Many Unary Relationship An employee may be managed by one other employee A employee may manage several employees EMPLOYEE 1:N

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-21 Cardinality Each of the three types of binary relationships shown above have different maximum cardinalities Minimum cardinalities also exist. These values typically assume a value of Mandatory (one) or Optional (zero)

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-22 One-to-One Binary Relationship with Minimum Cardinality An employee must have one locker; and A locker may be accessible by one or zero employees LOCKEREMPLOYEE 1:1 0 |

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-23 Weak Entity A weak entity is an entity that cannot exist in the database without the existence on another entity For example, an employee’s dependents cannot exist in a database without the employee existing in the database EMPLOYEE 1:N 0 | DEPENDENT

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-24 ID-Dependent Weak Entities An ID-Dependent weak entity is a weak entity that must include the identifier of its parent entity as part of its composite primary key BUILDING 1:N 0 | APARTMENT

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-25 Weak Entity Identifier: Non-ID-dependent A non-ID-dependent weak entity may have a single or composite identifier, and the identifier of the parent entity will be a foreign key PATIENT 1:N 0 | PERSCRIPTION

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-26 Weak Entity Identifier: ID-Dependent An ID-dependent weak entity has a composite identifier –The first part of the identifier is the identifier for the strong entity –The second part of the identifier is the identifier for the weak entity itself PROJECT 1:N 0 | ASSIGNMENT

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-27 Weak Entity Relationships The relationship between a strong and weak entity is termed an identifying relationship if the weak entity is ID-dependent The relationship between a strong and weak entity is termed a non- identifying relationship if the weak entity is non-ID-dependent

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-28 Unified Modeling Language Entity-Relationship Diagrams Unified Modeling Language (UML) is a set of structures and techniques for modeling and designing object- oriented programs (OOP) and applications

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-29 Unified Modeling Language Entities ENTITY_NAME List of Attributes Identifier

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-30 Unified Modeling Language Relationships * 1..* 1..1Mandatory One Optional One Optional Many Mandatory Many

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-31 UML E-R Diagram Example An employee must report to one department; and A department may have zero or many employees EMPLOYEE EmployID EmployName Phone EmployID is identifier DEPARTMENT DeptID DeptName Location DeptID is identifier 0..* 1..1

DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall 4-32 UML Weak Entity EMPLOYEE EmployID EmployName Phone EmployID is identifier DEPENDENT DepSSN DepName DepAge DepSSN is identifier 1 0..N

Data Modeling and the Entity-Relationship Model End of Presentation on Chapter Four DAVID M. KROENKE’S DATABASE CONCEPTS, 2 nd Edition