Entity–
Relationship
Data Model
Slides by: Shree Jaswal
Topics:
– Conceptual Modeling of a database,
– The Entity-Relationship (ER) Model,
– Entity Types, Entity Sets,
– Attributes, and Keys, Relationship Types,
– Relationship Sets, Weak Entity Types
– Generalization, Specialization and Aggregation,
– Extended Entity-Relationship (EER) Model.
Module 2 Slides by: Shree J.
Which Chapter? Which Book?
– Chapter 7: Conceptual data modeling using entities and relations, Elmasri and
Navathe, “ Fundamentals of Database Systems”, 6th Edition, PEARSON
Education
– Chapter 2: Introduction to Database Design, Raghu Ramkrishnan and Johannes
Gehrke, “ Database Management Systems”,TMH
– Chapter 2: Introduction to Relational Model, Korth, Slberchatz,Sudarshan,
”Database System Concepts”, 6th Edition, McGraw – Hill
Module 2 Slides by: Shree J.
Overview of Database Design
Process
– Two main activities:
– Database design
– Applications design
– Focus in this chapter on database design
– To design the conceptual schema for a database application
– Applications design focuses on the programs and interfaces that access the database
– Generally considered part of software engineering
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
ER modeling
Example COMPANY Database
– We need to create a database schema design based on the following (simplified) requirements of the COMPANY Database:
– The company is organized into DEPARTMENTs. Each department has a name, number and an employee who manages the department. We keep track of the start date of the department manager. A department may have several locations.
– Each department controls a number of PROJECTs. Each project has a unique name, unique number and is located at a single location.
Module 2 Slides by: Shree J.
Example COMPANY Database
(Contd.)
– We store each EMPLOYEE’s social security number, address, salary, sex, and birthdate.
– Each employee works for one department but may work on several projects.
– We keep track of the number of hours per week that an employee currently works on each project.
– We also keep track of the direct supervisor of each employee.
– Each employee may have a number of DEPENDENTs.
– For each dependent, we keep track of their name, sex, birthdate, and relationship to the employee.
Module 2 Slides by: Shree J.
ER Model Concepts
– Entities and Attributes
– Entities are specific objects or things in the mini-world with an independent existence that are represented in the database .
– For example the EMPLOYEE John Smith, the Research DEPARTMENT, the ProductX PROJECT
– Attributes are properties used to describe an entity.
– For example an EMPLOYEE entity may have the attributes Name, SSN, Address, Sex, BirthDate
– A specific entity will have a value for each of its attributes.
– For example a specific employee entity may have Name='John Smith', SSN='123456789', Address ='731, Fondren, Houston, TX', Sex='M', BirthDate='09-JAN-55‘
– Each attribute has a value set (or data type) associated with it – e.g. integer, string, subrange, enumerated type, …
Module 2 Slides by: Shree J.
Types of Attributes
– Simple
– Each entity has a single atomic value for the attribute. For example, SSN or Sex.
– Composite
– The attribute may be composed of several components. For example:
– Address(Apt#, House#, Street, City, State, ZipCode, Country), or
– Name(FirstName, MiddleName, LastName).
– Composition may form a hierarchy where some components are themselves composite.
– Multi-valued
– An entity may have multiple values for that attribute. For example, Color of a CAR or PreviousDegrees of a STUDENT.
– Denoted as {Color} or {PreviousDegrees}.Module 2 Slides by: Shree J.
Types of Attributes
– In general, composite and multi-valued attributes may be nested
arbitrarily to any number of levels, although this is rare.
– For example, PreviousDegrees of a STUDENT is a composite
multi-valued attribute denoted by {PreviousDegrees (College,
Year, Degree, Field)}
– Multiple PreviousDegrees values can exist
– Each has four subcomponent attributes:
– College, Year, Degree, Field
Module 2 Slides by: Shree J.
Example of a composite attribute
Module 2 Slides by: Shree J.
Entity Types and Key Attributes
– Entities with the same basic attributes are grouped or typed into an entity type.
– For example, the entity type EMPLOYEE and PROJECT.
– An attribute of an entity type for which each entity must have a unique value is called a key attribute of the entity type.
– For example, SSN of EMPLOYEE.
Module 2 Slides by: Shree J.
Entity Types and Key Attributes
– A key attribute may be composite.
– VehicleTagNumber is a key of the CAR entity type with components (Number, State).
– An entity type may have more than one key.
– The CAR entity type may have two keys:– VehicleIdentificationNumber (popularly called VIN)
– VehicleTagNumber (Number, State), aka license plate number.
– Each key is underlined
Module 2 Slides by: Shree J.
Stored versus Derived Attributes
– Two (or more) attributes are related
– Example AGE and Birth_date
– Age is the derived attribute which can be derived from
the stored attribute birth_date
– Attributes can also be derived from related entities
– Eg:- Number_of_employees in a department
Module 2 Slides by: Shree J.
NULL Values
– A particular entity may not have an applicable value for
an attribute (flat number for a bungalow )
– This can be because the value is either missing or
unknown
– Unknown can either be because the value exists but is
currently missing(Height) or when the value is not
known(eg:- home_phone of a person)
Module 2 Slides by: Shree J.
Complex attributes
{Address_phone({phone(area_code,phone_number)},Addr
ess(Street_address(number,street,apartment_number),ci
ty,state,zip))}
If a person can have more than one residence and each
residence can have a single address and multiple phones
Module 2 Slides by: Shree J.
Representations of attributes
Module 2 Slides by: Shree J.
Displaying an Entity type
– In ER diagrams, an entity type is displayed in a rectangular box
– Attributes are displayed in ovals
– Each attribute is connected to its entity type
– Components of a composite attribute are connected to the oval representing the composite attribute
– Each key attribute is underlined
– Multivalued attributes displayed in double ovals
– See CAR example on next slideModule 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Entity Set
– Each entity type will have a collection of entities stored in the
database
– Called the entity set
– Previous slide shows three CAR entity instances in the entity set
for CAR
– Same name (CAR) used to refer to both the entity type and the
entity set
– Entity set is the current state of the entities of that type that are
stored in the databaseModule 2 Slides by: Shree J.
– Entity type describes the schema
– Schema is also called Intention
– For example,
– Employee(EmpNo Number(4) Not NULL, EName Char(20), Age Number(2), Dept Char(4) )
– Collection of entities of a particular entity type is grouped as entity set
– Entity set is called as Extention
– Example Relation: Employee at time= t2 after adding more records
Module 2 Slides by: Shree J.
EmpNo EmpName Age Dept
1001 Jason 23 SD
1002 William 24 HR
Initial Design of Entity Types for
the COMPANY Database Schema
– Based on the requirements, we can identify four initial entity types in the
COMPANY database:
– DEPARTMENT
– PROJECT
– EMPLOYEE
– DEPENDENT
– Their initial design is shown on the following slide
– The initial attributes shown are derived from the requirements description
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Refining the initial design by
introducing relationships
– The initial design is typically not complete
– Some aspects in the requirements will be represented as
relationships
– ER model has three main concepts:
– Entities (and their entity types and entity sets)
– Attributes (simple, composite, multivalued)
– Relationships (and their relationship types and relationship sets)
Module 2 Slides by: Shree J.
Relationships and Relationship
Types
– A relationship relates two or more distinct entities with a specific meaning.– For example, EMPLOYEE John Smith works on the ProductX PROJECT, or
EMPLOYEE Franklin Wong manages the Research DEPARTMENT.
– Relationships of the same type are grouped or typed into a relationship type.– For example, the WORKS_ON relationship type in which EMPLOYEEs and
PROJECTs participate, or the MANAGES relationship type in which EMPLOYEEs and DEPARTMENTs participate.
– The degree of a relationship type is the number of participating entity types. – Both MANAGES and WORKS_ON are binary relationships.
Module 2 Slides by: Shree J.
Relationship types, sets and
instances
– A relationship set R is a set of relationship instances ri,where each ri associates
n individual entities (e1,e2,e3,…en) and each ej in ri is a member of entity type Ej,
– Each of the entity types E1,E2,…En participates in R
Module 2 Slides by: Shree J.
nj 1
Relationship instances of the WORKS_FOR
N:1 relationship between EMPLOYEE and
DEPARTMENT
Module 2 Slides by: Shree J.
Relationship instances of the M:N
WORKS_ON relationship between
EMPLOYEE and PROJECT
Module 2 Slides by: Shree J.
Relationship type vs.
relationship set
– Relationship Type:
– Is the schema description of a relationship
– Identifies the relationship name and the participating entity types
– Also identifies certain relationship constraints
– Relationship Set:
– The current set of relationship instances represented in the database
– The current state of a relationship type
Module 2 Slides by: Shree J.
Relationship type vs.
relationship set
– Previous figures displayed the relationship sets
– Each instance in the set relates individual participating entities –
one from each participating entity type
– In ER diagrams, we represent the relationship type as follows:
– Diamond-shaped box is used to display a relationship type
– Connected to the participating entity types via straight lines
Module 2 Slides by: Shree J.
Relationship Degree, Role
Names, recursive relationships
– Degree:- Number of participating entity types.
WORKS_FOR is Binary relationship
– Supplier selling parts for a product is ternary relationship
– The University might need to record which teachers taught
which subjects in which courses.
Module 2 Slides by: Shree J.
Refining the COMPANY database
schema by introducing relationships
– By examining the requirements, six relationship types are identified
– All are binary relationships( degree 2)
– Listed below with their participating entity types:
– WORKS_FOR (between EMPLOYEE, DEPARTMENT)
– MANAGES (also between EMPLOYEE, DEPARTMENT)
– CONTROLS (between DEPARTMENT, PROJECT)
– WORKS_ON (between EMPLOYEE, PROJECT)
– SUPERVISION (between EMPLOYEE (as subordinate), EMPLOYEE (as supervisor))
– DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Discussion on Relationship
Types– In the refined design, some attributes from the initial entity types
are refined into relationships:
– Manager of DEPARTMENT -> MANAGES
– Works_on of EMPLOYEE -> WORKS_ON
– Department of EMPLOYEE -> WORKS_FOR
– In general, more than one relationship type can exist between the same participating entity types
– MANAGES and WORKS_FOR are distinct relationship types between EMPLOYEE and DEPARTMENT
– Different meanings and different relationship instances.Module 2 Slides by: Shree J.
Recursive Relationship Type
– An relationship type participates in entity type with distinct roles
– Example: the SUPERVISION relationship
– EMPLOYEE participates twice in two distinct roles:
– supervisor (or boss) role
– supervisee (or subordinate) role
– Each relationship instance relates two distinct EMPLOYEE entities:
– One employee in supervisor role
– One employee in supervisee role
Module 2 Slides by: Shree J.
Displaying a recursive
relationship
– In a recursive relationship type.
– Both participations are same entity type in different roles.
– For example, SUPERVISION relationships between EMPLOYEE (in role of supervisor or boss) and (another) EMPLOYEE (in role of subordinate or worker).
– In ER diagram, need to display role names to distinguish participations.
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Cardinality ratios for binary
relationship
– Specifies the maximum number of relationship
instances that an entity can participate in.
Module 2 Slides by: Shree J.
Constraints on Relationships
– Constraints limit the possible combinations of entities that may participate in the corresponding relationship set.
– Constraints on Relationship Types
– (Also known as ratio constraints)
– Cardinality Ratio (specifies maximum participation)
– One-to-one (1:1) MANAGES EMPLOYEE:DEPARTMENT
– One-to-many (1:N) or Many-to-one (N:1) EMPLOYEES:DEPARTMENT
– Many-to-many (M:N) EMPLOYEE:PROJECTS
Module 2 Slides by: Shree J.
Many-to-one (N:1) Relationship
Module 2 Slides by: Shree J.
Many-to-many (M:N)
Relationship
Module 2 Slides by: Shree J.
Participation Constraints and
Existence Dependencies
– Specifies whether the existence of an entity depends on its being related to another entity via the relationship type. (minimum cardinality constraint)
– There are two types
– Total:- every entity in employee set must be related to department via works_for
– Partial:- some or part of employee entities are related to department via manages.
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Attributes of Relationship types
– A relationship type can have attributes:
– For example, HoursPerWeek of WORKS_ON
– Its value for each relationship instance describes the number of hours per week that an EMPLOYEE works on a PROJECT.
– A value of HoursPerWeek depends on a particular (employee, project) combination
– Most relationship attributes are used with M:N relationships
– In 1:N relationships, they can be transferred to the entity type on the N-side of the relationship
Module 2 Slides by: Shree J.
Weak Entity Types
– An entity that does not have a key attribute
– A weak entity must participate in an identifying relationship type with an owner or identifying entity type
– Entities are identified by the combination of:
– A partial key of the weak entity type
– The particular entity they are related to in the identifying entity type
– 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
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Notation for Constraints on
Relationships
– Cardinality ratio (of a binary relationship): 1:1, 1:N, N:1, or M:N
– Shown by placing appropriate numbers on the relationship edges.
– Participation constraint (on each participating entity type): total (called existence dependency) or partial.
– Total shown by double line, partial by single line.
– NOTE: These are easy to specify for Binary Relationship Types.
Module 2 Slides by: Shree J.
Example
Design an E-R schema for a database to store info about professors, courses and course sections indicating the following:
– The name and employee ID number of each professor
– The salary and email address(es) for each professor
– How long each professor has been at the university
– The course sections each professor teaches
– The name, number and topic for each course offered
– The section and room number for each course section
– Each course section must have only one professor
– Each course can have multiple sectionsModule 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
University DB Case Study
– Maintain the following information about undergrad
students:
– Name, address, student number, date of birth, year of
study, degree program (BA, BSc, BCS), concentration
(Major, Honours, etc) and department of concentration.
– Note: An address is composed of a street, city, province
and postal code; the student number is unique for each
student
Module 2 Slides by: Shree J.
University Case Study (cont’d)
– Maintain information about departments
– Name, code (CS, Phy), office phone, and faculty members
– Maintain information about courses:
– Course number (3753), title, description, prerequisites.
– Maintain information about course sections:
– Section (A, B, C), term (X1), slot #, instructor
Module 2 Slides by: Shree J.
University Case Study (cont’d)
– Maintain information about faculty:
– Name, rank, employee number, salary, office number,
phone number and email address.
– Note: employee number is unique
– Maintain a program of study for the current year for each
student:
– i.e. courses that each student is enrolled in
Module 2 Slides by: Shree J.
– Students are enrolled for sections
– 1 course has many sections
– Teacher can teach any number of sections
– Courses can be prerequisite for other courses
– A faculty heads a department. Department has any
number of faculties.
University Case Study (cont’d)
Module 2 Slides by: Shree J.
SectionNumber
Term
Slot
Number
Title
Description
Course
Student
Number
Name
DOB
Address
Enrolled
Street
Postal Code
Province
City
Dept
Code
Name
Phone
Faculty Number
Office
Phone
Name
Rank
Head Member
Offer
TeachesHas
Prereq
N
1
N
M
N
N
N M
1
N
1
1
1
1
Start Date
End Date
Salary
Module 2 Slides by: Shree J.
Alternative (min, max) notation for
relationship structural constraints:
– Specified on each participation of an entity type E in a relationship type R
– Specifies that each entity e in E participates in at least min and at most max relationship instances in R
– Default(no constraint): min=0, max=n (signifying no limit)
– Must have minmax, min0, max 1
– Derived from the knowledge of mini-world constraints
– Examples:
– A department has exactly one manager and an employee can manage at most one department.– Specify (0,1) for participation of EMPLOYEE in MANAGES
– Specify (1,1) for participation of DEPARTMENT in MANAGES
– An employee can work for exactly one department but a department can have any number of employees.– Specify (1,1) for participation of EMPLOYEE in WORKS_FOR
– Specify (0,n) for participation of DEPARTMENT in WORKS_FORModule 2 Slides by: Shree J.
The (min,max) notation for
relationship constraints
Read the min,max numbers next to the entity
type and looking away from the entity type
Module 2 Slides by: Shree J.
Discussion of n-ary relationships (n > 2)
– In general, 3 binary relationships can represent different
information than a single ternary relationship
– If needed, the binary and n-ary relationships can all be
included in the schema design
– In some cases, a ternary relationship can be represented
as a weak entity if the data model allows a weak entity
type to have multiple identifying relationships
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Example of a
ternary
relationship
Module 2 Slides by: Shree J.
EER Modelling
EER Modelling
– The enhanced entity–relationship (EER) model
(or extended entity–relationship model) in computer
science is a high-level or conceptual data model
incorporating extensions to the original entity–
relationship (ER) model, used in the design of databases.
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Types of Constraints on
Specialization and Generalization
– Constraints on sub classes
– Attribute defined
– User defined
– Disjointness constraints
– Disjoint
– Overlap
– Completeness constraints
– Partial specialization
– Total specialization
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Constraints on Specialization and
Generalization
– We have four types of specialization/generalization:
– Disjoint, total
– Disjoint, partial
– Overlapping, total
– Overlapping, partial
– Note: Generalization usually is total because the superclass is derived from the subclasses.
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Specialization / Generalization
Hierarchies, Lattices and Shared
Subclasses– A subclass may itself have further subclasses specified on it
– Forms a hierarchy or a lattice
– Hierarchy has a constraint that every subclass has only one superclass (called single inheritance)
– In a lattice, a subclass can be subclass of more than one superclass (called multiple inheritance)
– In a lattice or hierarchy, a subclass inherits attributes not only of its direct superclass, but also of all its predecessor superclasses
– A subclass with more than one superclass is called a shared subclass
Module 2 Slides by: Shree J.
Specialization & generalization
hierarchies and lattices
Module 2 Slides by: Shree J.
Specialization / Generalization
Hierarchies, Lattices and Shared
Subclasses– Can have specialization hierarchies or lattices, or generalization
hierarchies or lattices
– In specialization, start with an entity type and then define subclasses of the entity type by successive specialization (top down conceptual refinement process)
– In generalization, start with many entity types and generalize those that have common properties (bottom up conceptual synthesis process)
– In practice, the combination of two processes is employed
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Categories (UNION TYPES)
– All of the superclass/subclass relationships we have seen thus far have a single superclass
– A shared subclass is subclass in more than one distinct superclass/subclass relationships, where each relationships has a single superclass (multiple inheritance)
– In some cases, need to model a single superclass/subclass relationship with more than one superclass
– Superclasses represent different entity types
– Such a subclass is called a category or UNION TYPE
Module 2 Slides by: Shree J.
Categories (UNION TYPES)
– Example: Database for vehicle registration, vehicle owner can be a person, a bank (holding a lien on a vehicle) or a company.
– Category (subclass) OWNER is a subset of the union of the three superclasses COMPANY, BANK, and PERSON
– A category member must exist in at least one of its superclasses
– Note: The difference from shared subclass, which is subset of the intersection of its superclasses (shared subclass member must exist in all of its superclasses).
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Aggregation Consider the ternary relationship works_on
Suppose we want to record managers for tasks performed by an employee at a branch
Module 2 Slides by: Shree J.
Aggregation (Cont.)
– Relationship sets works_on and manages represent overlapping information
– Every manages relationship corresponds to a works_on relationship
– However, some works_on relationships may not correspond to any manages relationships
– So we can’t discard the works_on relationship
Module 2 Slides by: Shree J.
– Eliminate this redundancy via aggregation
– Treat relationship as an abstract entity
– Allows relationships between relationships
– Abstraction of relationship into new entity
– Without introducing redundancy, the following diagram represents:
– An employee works on a particular job at a particular branch
– An employee, branch, job combination may have an associated manager
Module 2 Slides by: Shree J.
E-R Diagram With Aggregation
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.
Module 2 Slides by: Shree J.