Kingdom of Saudi Arabia
Ministry of Higher Education
Al-Imam Muhammad Ibn Saud Islamic University
College of Computer and Information Sciences
Data Modeling Using the EntityRelationship (ER) Model
IS 320: Introduction to Database
HatoonAlSagri
IS Department
Database Design
Steps in building a database for an application:
1. Understand real-world domain being captured
2. Specify it using a database conceptual model (ER)
3. Translate specification to model of DBMS (relational)
4. Create schema using DBMS commands (DDL)
5. Load data (DML)
Real-world
domain
Conceptual
model
DBMS data
model
IS Department
Create
Schema
(DDL)
Load data
(DML)
2
Entity Sets
• A database can be modeled as:
• a collection of entities,
• relationship among entities.
• An entity is an object that exists and is distinguishable
from other objects.
• Example: specific person, company, event, plant
• Entities have attributes
• Example: people have names and addresses
• An entity set is a set of entities of the same type that
share the same properties.
• Example: set of all persons, companies, trees, holidays
IS Department
3
Example COMPANY Database
• Simple example database application, called COMPANY, that
serves to illustrate the basic ER model concepts and their use in
schema design.
• The COMPANY database keeps track of a company’s
employees, department, and project.
• After the requirements collection and analysis phase, the
database designers provided the following description of the
“miniworld”-part of the company
IS Department
4
COMPANY database- Requirements
 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
location.
 Each department controls a number of projects. each project has a name,
number and is located at a single location.
 We store each employee’s name, social security number, address, salary,
sex, and birth date. 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, birth date, and relationship to employee.
IS Department
5
The ER Data model
for the COMPANY
database.
IS Department
6
Entity sets: attributes
• An entity is represented by a set of attributes, that is descriptive
properties possessed by all members of an entity set.
Example:
customer = (customer-id, customer-name, customer-street, customer-city)
loan = (loan-number, amount)
• Domain – the set of permitted values for each attribute
• Attribute types:
• Simple and composite attributes.
• Single-valued and multi-valued attributes
• E.g. multivalve attribute: phone-numbers
• Derived attributes
• Can be computed from other attributes
• E.g. age, given date of birth
IS Department
7
8
IS Department
ER Model - Entity and Attributes
salary
name
address
Ssn
Employee
sex
Bdate
Types of Attributes (1)
• Composite versus Simple (Atomic) Attributes
• Simple attribute: Each entity has a single atomic value for the attribute.
For example, SSN or Sex.
• Composite attribute: The attribute may be composed of several
components.
For example, Address (House#, Street, City, State, ZipCode)
Name (Fname, Mname, Lname).
• Composition may form a hierarchy where some components are themselves
composite.
IS Department
9
Example of a composite attribute
IS Department
10
11
IS Department
Composite versus Simple (Atomic) Attributes
Fname Mname Lname
Salary
Name
Address
Ssn
Employee
Sex
Bdate
Types of Attributes (2)
• Single-Value versus Multivalued Attributes
• Most attributes have a single value for a particular entity; such attributes
are called Single-valued
For example, Age of a PERSON
• An entity may have multiple values for that attribute. such attributes are
called Multivalued
For example, Color of a CAR or Tel_num of a STUDENT.
Denoted as {Color} or {Tel_num}.
• A multivalued attribute may have lower and upper bounds to constrain
the number of values allowed for each individual entity.
IS Department
12
IS Department
13
Single-Value versus Multivalued Attributes
Fname
Mname
Name
Lname
DOB
St_no
Tel_no
STUDENT
Types of Attributes (3)
• Stored versus Derived Attributes
• Derived attribute is an attribute that represents a value that is derived
from the value of a related attribute, not necessarily in the same entity
type.
For example, Age and BirthDate of a PERSON
The value of Age can be determined from the current date and the value
of that person’s BirthDate. The Age attribute called a derived attribute
is said to be derivable from the BirthDate attribute which is called a
stored attribute.
Other example, Total_cost is derived from quantity*unit_price
IS Department
14
15
IS Department
Stored versus Derived Attributes
Fname
Mname
Name
Lname
DOB
St_no
Tel_no
Age
STUDENT
Types of Attributes (4)
• Null value is a special value, In some cases a particular entity may not
have an applicable value for an attribute.
For example, The ApartmentNumber of an Address
Null value cases: Not applicable for an attribute; or exist but missing;
or not known
• In general, composite and multi-valued attributes may be nested
arbitrarily to any number of levels although this is rare. Such attributes are
called Complex Attributes
For example, PreviousDegrees of a STUDENT is a composite
multi-valued attribute denoted by
{PreviousDegrees (College, Year, Degree, Field)}.
IS Department
16
17
IS Department
Complex Attributes
LName
initial
name
FName
DOB
St_no
Area_cd
No
Tel_no
STUDENT
EX
Key Attributes
• 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.
• Candidate key (CK) is the minimal set of attributes that uniquely identifies an
entity. It cannot contain null.
For example, student_no, social_security_no, branch_no…
• Primary Key (PK) is a candidate key that is selected to uniquely identify each
entity.
• Alternate Key (AK) is a candidate key that is NOT selected to be the primary
key.
IS Department
18
Keys
• Candidate key (CK) is the minimal set of attributes that uniquely
identifies an entity. It cannot contain null.
For example, student_no, social_security_no, branch_no…
• Primary Key (PK) is a candidate key that is selected to uniquely
identify each entity.
• Alternate Key (AK) is a candidate key that is NOT selected to be the
primary key.
IS Department
19
Keys Example
Candidate Key
EMPLOYEE (Id, SSN, Full_name, DOB, Dept_no)
Primary Key
Alternate Keys
IS Department
20
Keys
A key can be:
• Simple key is a candidate key of one attribute
For example, student_no, branch_no…
• Composite key is a candidate key that consists of two or more
attributes
For example,
STUDENT (Fname, Mname, Lname)
CLASS (crs_code, section_no)
ADVERT (property_no, newspaperName, dateAdvert)
IS Department
21
Choice of PK
Choice of Primary Key (PK) is based on:
• Attribute length
• Number of attributes required
• Certainty of uniqueness
Each Primary key is underlined
IS Department
22
23
IS Department
Primary Key in ERD
LName
initial
Name
FName
DOB
St_ID
Area_cd
No
Tel_no
STUDENT
Simple Key
Section_no
Age
Name
Crs_code
Hours
EX
CLASS
Composite Key
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 location.
 Each department controls a number of PROJECTs. Each project has a
name, number and is located at a single location.
 We store each EMPLOYEE’s name, social security number, address,
salary, sex, and birth date. 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, birth date, and relationship to
employee.
IS Department
24
25
IS Department
EMPLOYEE Entity
Fname Mname Lname
name
Ssn
EMPLOYEE
Bdate
Sex
Address
Salary
IS Department
26
DEPARTMENTS Entity
• Both name and number are
Name
Number
unique for a department.
• A department may be spread
over many locations.
DEPARTMENT
• The number of employees in a
department is derivable from
the Works-for relationship.
NumberOf
Employees
Locations
IS Department
27
PROJECT Entity
Name
Number
Location
PROJECT
* Number of hours per week that an employee currently works on
each project ???
28
IS Department
DEPENDENT Entity
• Dependents are only
Ssn
EMPLOYEE
uniquely identifiable in the
context of an employee
dept. of
• weak entity type
• partial key is name
• Note the standard pattern
for weak entities.
Name
Sex
DEPENDENT
Bdate
Relationship
Initial Design of Entity Types:
EMPLOYEE, DEPARTMENT,
PROJECT, DEPENDENT
IS Department
29
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.
IS Department
30
Example relationship instances of the WORKS_FOR relationship
between EMPLOYEE and DEPARTMENT
IS Department
31
Example relationship instances of the WORKS_ON relationship
between EMPLOYEE and PROJECT
IS Department
32
Degree of Relationship Type
Degree of relationship refers to number of participating entity types in a
relationship.
• A relationship of degree two (2 entity types) are binary.
STUDENT
STUDY
COURSE
• A relationship of degree three (3 entity types) are ternary.
STUDENT
REGISTER
COURSE
STAFF
IS Department
33
Relationships and Relationship Types
• More than one relationship type can exist with the same participating
entity types.
For example,
MANAGES and WORKS_FOR are distinct relationships between
EMPLOYEE and DEPARTMENT, but with different meanings and differen
relationship instances.
MANAGES
DEPARTMENT
EMPLOYEE
WORKS-FOR
IS Department
34
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
IS Department
35
36
IS Department
Weak Entity Types
Fname Mname Lname
Ssn
Bdate
name
Relationship
Sex Address
Salary
EMPLOYEE
dept. of
Name
Sex
Bdate
DEPENDENT
Recursive Relationship Type
• We can also have a recursive relationship type.
• Recursive relationship is a relationship type where the same entity type
participates more than once in a different role. It is a unary relationship.
• 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.
IS Department
37
38
IS Department
A Recursive Relationship Supervision
EMPLOYEE
Supervisor
Supervisee
SUPERVISION
COURSE
requester
prerequisite
REQUIRE
Role indicates the purpose that each participating entity type plays
in a relationship
IS Department
39
Roles
Role can be used when two entities are associated through more
than one relationship to classify the purpose of each relationship
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.
WORKS-ON
Hours
IS Department
40
Constraints on Relationships
 ( Also known as ratio constraints )
 Cardinality Ratio (specifies maximum participation)

One-to-one (1:1)

One-to-many (1:N) or Many-to-one (N:1)

Many-to-many
 Existence Dependency Constraint (specifies minimum
participation) (also called Participation Constraint)

Zero (optional participation, not existence-dependent)

One or more (mandatory, existence-dependent)
IS Department
41
IS Department
Many-to-one (N:1) RELATIONSHIP
42
IS Department
Many-to-many (M:N) RELATIONSHIP
43
Structural Constraints
one way to express semantics of relationships
Structural constraints on relationships:
 Cardinality
ratio (of a binary relationship): 1:1, 1:N, N:1, or M:N
Shown by placing appropriate number on the link.
 Participation
constraint (on each participating entity type): total
(called existence dependency) or partial.
Shown by double lining the link
NOTE: These are easy to specify for Binary Relationship Types.
IS Department
44
IS Department
EMPLOYEE
EMPLOYEE
EMPLOYEE
EMPLOYEE
DEPARTMENT
EMPLOYEE
1
1
DEPARTMENT
MANAGES
N
N
1
1
1
45
WORKS_FOR
WORKS_ON
DEPENDENTS_OF
CONTROLS
SUPERVISION
1
M
N
N
N
DEPARTMENT
PROJECT
DEPENDENT
PROJECT
EMPLOYEE
IS Department
46
The ER Data model for the COMPANY database
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
• Must have minmax, min0, 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 (1,N) for participation of DEPARTMENT in WORKS_FOR
IS Department
47
IS Department
48
The (min,max) notation relationship constraints
IS Department
COMPANY ER Schema Diagram
using (min, max) notation
49
Kingdom of Saudi Arabia
Ministry of Higher Education
Al-Imam Muhammad Ibn Saud Islamic University
College of Computer and Information Sciences
The Enhanced Entity-Relationship
(EER) Model
IS 320: Introduction to Database
IS Department
Enhanced-ER (EER) Model Concepts
• Includes all modeling concepts of basic ER
• Additional concepts: subclasses/superclasses,
specialization/generalization, categories, attribute inheritance
• The resulting model is called the enhanced-ER or Extended ER
(E2R or EER) model
• It is used to model applications more completely and accurately if
needed
IS Department
51
Subclasses and Superclasses (1)
• An entity type may have additional meaningful sub-groupings of its
entities.
Example: EMPLOYEE may be further grouped into SECRETARY, MANAGER,
ENGINEER, TECHNICIAN, SALARIED_EMPLOYEE, HOURLY_EMPLOYEE,…
• Each of these groupings is a subset of EMPLOYEE entities
• Each is called a subclass of EMPLOYEE
• EMPLOYEE is the superclass for each of these subclasses
• These are called superclass/subclass relationships.
Example: EMPLOYEE/SECRETARY, EMPLOYEE/TECHNICIAN
IS Department
52
Subclasses and Superclasses
IS Department
53
Attribute Inheritance in Superclass / Subclass
Relationships
• An entity that is member of a subclass inherits all attributes of the
entity as a member of the superclass
• It also inherits all relationships
• The subclass can has its own specific (local) attributers and
relationships together with all the attributes and relationships it
inherits from the superclass.
For example, TypingSpeed of SECRETARY
For example, BELONGS_TO relationship types of HOURLY_EMPLOYEE
IS Department
54
Specialization
Two main reasons for including class/subclass relationship and
specializations in a data model:
• First: is that certain attributes may apply to some but not all entities
of the superclass.
• Second: is that some relationship types may be participated in only
by entities that are members of the subclass.
In summary, the specialization process allows us to do the following:
• Define a set of subclasses of an entity type.
• Establish additional specific attributes with each subclass.
• Establish additional specific relationship types between each
subclass and other entity types or other subclasses.
IS Department
55
Generalization
• The reverse of the specialization process
• Several classes with common features are generalized into a
superclass; original classes become its subclasses
Example: CAR, TRUCK generalized into VEHICLE; both CAR, TRUCK
become subclasses of the superclass VEHICLE.
• We can view {CAR, TRUCK} as a specialization of VEHICLE
• Alternatively, we can view VEHICLE as a generalization of CAR and
TRUCK
IS Department
56
Generalization (a) Two entity types, CAR and TRUCK.
(b) Generalizing CAR and TRUCK into the superclass VEHICLE.
IS Department
57
Inheritance
Shared
Attributes
Name
Superclass
Subclass
Unshared
Attributes
Dob
Address
CONTRACT
STAFF
SALES
PERSONNEL
Car
Allowance
Shared
Relationship
REQUIRE
Sales
Area
IS Department
COMPANY
CAR
Unshared
Relationship
58
Constraints on Specialization and
Generalization (1)
• Disjointness Constraint:
• Specifies that the subclasses of the specialization must be disjointed
(an entity can be a member of at most one of the subclasses of the
specialization). Specified by d (inside the circle) in EER diagram
• If not disjointed, overlap; that is the same entity may be a member of
more than one subclass of the specialization. Specified by o (inside
the circle) in EER diagram
• Completeness Constraint:
• Total specifies that every entity in the superclass must be a member
of some subclass in the specialization/ generalization. Shown in EER
diagrams by a double line
• Partial allows an entity not to belong to any of the subclasses. Shown
in EER diagrams by a single line
IS Department
59
Constraints on Specialization and Generalization (3)
• Hence, 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.
IS Department
60
Example of disjoint partial Specialization
IS Department
61
Example of overlapping total Specialization
IS Department
62
Case Study: Requirements for the part of the
UNIVERSITY database
• The database Keeps track of three types of people: employees, alumni, and
students, A person can belong to one, two, or all three of these types. Each person
has a name, SSN, sex, address, and birth date.
• Every employee has a salary, and there are three types of employees: faculty, staff,
and student assistants. Each employee belongs to exactly one of these types. For
each alumnus, a record of the degree or degrees that he or she earned at the
university is kept. Including the name of the degree, the year granted, and the major
department. Each student has a major department.
• Each faculty has a rank, whereas each staff member has a staff position. Student
assistants are classified further as either research assistants of teaching assistants,
and the percent of time that they work is recorded in the database. Research
assistants have their research project stored, whereas teaching assistants have the
current course they work on.
• Students are further classified as either graduate or undergraduate, with the
specific attributes degree program (M.S.,PH.D) and class (freshman, sophomore,
and so on), respectively.
IS Department
63
Specialization / Generalization Lattice Example (UNIVERSITY)
IS Department
64
IS Department
65
Summary of ERD notations (1)
ENTITY
ATTRIBUTE
KEY ATTRIBUTE
WEAK ENTITY
MULTI-VALUED
RELATIONSHIP
COMPOSITE
IDENTIFYING
RELATIONSHIP
DERIVED
IS Department
66
Summary of ERD notations (2)
E1
E2
R
1
(min,max)
M
TOTAL PARTICIPATION
OF E2 IN R
CARDINALITY
RATION
PARTICIPATION
CONSTRAINTS
IS Department
Summary of EER notations (2)
d
Disjoint constraint
o
Non-Disjoint constraint (Overlap)
Total Participation
Optional Participation
67