CSCI 5333: Database Management System
PART-3, Chapter-7
Database Design and the
Entity-Relationship Model
(ER-Data Model)
Khondker S. Hasan
Department of Computing Sciences
University of Houston – Clear Lake
Chapter 6: Entity-Relationship Model
Outline
Design Process
Modeling
Constraints
E-R Diagram
Design Issues
Weak Entity Sets
Extended E-R Features
Design of the Example Database
Reduction to Relation Schemas
Database Design
2
Database Design Phases
The initial phase of database design is to characterize fully the data
needs of the prospective database users.
Next, the designer chooses a data model and, by applying the
concepts of the chosen data model, translates these requirements
into a conceptual schema of the database.
A fully developed conceptual schema also indicates the functional
requirements of the enterprise.
In a “specification of functional requirements”, users describe the
kinds of operations (or transactions) that will be performed on the
data.
3
Design Phases (Cont.)
The process of moving from an abstract data model to the
implementation of the database proceeds in two final design phases.
Logical Design – Deciding on the database schema. Database
design requires that we find a “good” collection of relation
schemas.
Business decision – What attributes should we record in the database?
Computer Science decision – What relation schemas should we have and how
should the attributes be distributed among the various relation schemas?
Physical Design – Deciding on the physical layout of the database
4
Entity-Relationship Model
The ER data mode was developed to facilitate database design
by allowing specification of an enterprise schema that
represents the overall logical structure of a database.
Based on a perception of a real-world enterprise that consists
of a set of basic objects called entity and relationship.
ER model is an Object based logical model.
Specifies enterprise schema
represents overall logical structure of a database
Semantic of data
Constraints
maps meaning and interactions of real-world enterprises onto a
conceptual schema
5
Entities and Attributes
Entity
thing e.g. person, car, account, tree
has a set of properties that uniquely identify it
may be concrete or conceptual
Entity Set
the collection of all entities of the same type that share the
same properties e.g. customer, supplier, student
individual entities that constitute a set are said to be the
extension of the entity set
6
Entity Sets -- instructor and student
instructor_ID instructor_name student-ID student_name
7
Entities and Attributes
Attributes
the descriptive properties of each member of the entity set
customer=(cus-name, cus-address, cus-phone)
database stores similar information for each entity, but
values may differ
setof permitted values for each attribute known as the
domain or value set of the attribute
8
Entities and Attributes
Formally,an attribute of an entity set is a function that maps
from the entity set into a domain
NY ...
MD FL domain
VA
OK
cus-state
Entity Set
9
Entities and Attributes
Attribute Types
simple
not divided into subparts, e.g. cus-state
composite
can be divided into subparts
cus-name firstname, middlename, surname
help us group together related attributes
single-valued
attribute may contains a single value for each entity
e.g. customer age, birth date etc.
multi-valued
attribute may contain a set of values
e.g. dependents name, phone #
10
Entities and Attributes
null attributes
used when an entity does not have a value for an attribute
can also mean that the value is unknown
E.g., middle-name
derived
the value for this type of attribute can be derived from other attributes
e.g. total-due derived from multiple purchases from a supplier
The value of a derived attribute is not stored, but is computed when
required.
11
Entities and Attributes
Redundant Attribute:
Suppose we have entity sets:
instructor, with attributes: ID, name, dept_name, salary
department, with attributes: dept_name, building, budget
We model the fact that each instructor has an associated department using
a relationship set inst_dept
The attribute dept_name appears in both entity sets.
Since it is the primary key for the entity set department, it replicates
information present in the relationship and is therefore redundant in the
entity set instructor and needs to be removed.
BUT: when converting back to tables, in some cases the attribute gets
reintroduced, as we will see later.
12
E-R Diagram With Composite, Multivalued,
and Derived Attributes
13
Relationship Sets
A relationship is an association among two or more entities
A relationship represents an association that exists in the real-
world enterprise. e.g., depositor
Verbs are good candidates for relationships
A relationship set is a set of relationships of the same type
Formally, it is a mathematical relation on n 2 entity sets
x xy y
14
xy is a relation
Relationship Sets
If E1,…,En are entity sets, then a relationship set R is a subset of
{(e1, e2,…, en) | e1 E1, e2 E2,…,en En}
Association between entity sets is referred to as participation.
That is, the entity set E1,…,En participate in relationship set R.
15
Relationship Set advisor
16
Relationship Sets
Relationships may have descriptive attributes
access_date
customer depositor account
Most relationship sets are binary, one that involves two entity sets,
Occasionally, there may be more than two entity sets involved in a
relationship.
17
Relationship Sets (Cont.)
An attribute can also be associated with a relationship set.
For instance, the advisor relationship set between entity sets
instructor and student may have the attribute date which tracks
when the student started being associated with the advisor
18
Recursive Relationship Sets (Roles)
The function an entity plays in a relationship is called its role
The labels “manager” and “worker” are called roles; they specify how
employee entities interact via the works_for relationship set.
Roles are indicated in E-R diagrams by labeling the lines that connect diamonds
to rectangles.
Role labels are optional, and are used to clarify semantics of the relationship
If relationship set not distinct (recursive relationship), role names may be
necessary
19
Degree of a Relationship Set
Binary relationship
involve two entity sets (or degree two).
most relationship sets in a database system are binary.
Relationships between more than two entity sets are rare. Most
relationships are binary. (More on this later.)
Example: students work on research projects under the
guidance of an instructor.
relationship proj_guide is a ternary relationship between
instructor, student, and project
20
Mapping Constraints
E-R schema may specify certain constraints to which the database must
conform
Mapping cardinalities
Existence dependencies
Participation constraints
Mapping Cardinalities (cardinality ratios)
express the number of entities to which another entity can be
associated via a relationship set
For a binary relationship R between entity sets A and B, the mapping
cardinality must be one of the following...
21
Mapping Constraints
One to One
an entity in A is associated with at most one entity in B. An entity
in B is associated with at most one entity in A
a1 b1
a2 b2
a3 b3
a4 b4
22
Mapping Constraints
One to Many
an entity in A is associated with any number of entities in B.
An entity in B can be associated with at most one entity in A
A B
b1
a1 b2
a2 b3
b4
23
Mapping Constraints
Many to One
An entity in A is associated with at most one entity in B. An
entity in B can be associated with any number of entities in A
A B
a1
a2 b1
a3 b2
a4
24
Mapping Constraints
Many to Many
An entity in A is associated with any number of entities in B.
An entity in B is associated with any number of entities in A
A B
a1 b1
a2 b2
a3 b3
a4 b4
25
Existence Dependencies
If the existence of entity x depends on the existence of
entity y, then x is said to be existence dependent on y
y is dominant entity
x is subordinate entity
payment is existent dependent on loan
26
Participation Constraints
The participation of an entity set E in a relationship R is said
to be total if every entity in E participates in at least one
relationship in R (denoted by double line)
If only some entities in E participate in relationships in R, the
participation is said to be partial
27
Keys
It is necessary to specify how entities within entity sets and
relationship sets are uniquely identified
We use keys to distinguish between entities
A superkey is a set of one or more attributes, that taken
collectively, allows us to uniquely identify an entity in an entity
set
social-security-number and student-name
28
Keys
However, superkeys may contain extraneous attributes
Minimal superkeys are known as candidate keys, e.g.,
{customer-id }, {cust-name, cust-street} are candidate keys.
A primary key is the candidate key that is chosen to uniquely
identify individual entities
A primary key that consists of more than one attribute is known
as a composite key
An attribute of an entity that is the primary key in another
entity is known as a foreign key
29
Guidelines for choosing primary key
Identify all candidate keys for all entities and select
primary key based on the following guideline:
minimal set of attributes
least likely to have value changed
least likely to lose uniqueness
fewest characters
easiest to user from users perspective
30
E-R Diagrams
The overall logical structure of the database can be expressed
graphically using an E-R Diagram
Joins entities to
Entity Sets relationships and attributes
to entities
Weak Entity Attributes
Relationship
Multi-valued attributes
Sets
Identifying Derived attributes
Relationship
31
E-R Diagrams
Attributes that are primary keys are underlined
Total participation in a relationship is denoted by a double line
Partial participation in a relationship is denoted by a single line
A directed line into an entity means that entity forms the
‘One’; part of a Many to One / One to Many relationship
Non-directed lines denote Many relationships
32
E-R Diagrams
x xy y
Many to Many
x xy y One to Many
x xy y Many to One
x xy y One to One
33
Practice Problem
Construct an E-R diagram for a car insurance company whose customers
own one or more cars each.
Each car has associated with it zero to any number of recorded
accidents.
Each insurance policy covers one or more cars, and has one or more
premium payments associated with it.
Each payment is for a particular period of time, and has an associated
due date, and the date when the payment was received.
34
Weak Entity Sets
A weak entity set is an entity set that does not have sufficient
attributes to form a primary key (opp. strong entity set)
It must be associated with another entity set, called identifying or
owner entity set. That is, the weak entity set is said to be existence
dependent on the identifying set.
The relationship between weak entity set and identifying entity set is
known as identifying relationship. Must be part of a Many-to-one
relationship (from weak to identifying entity set) and participation is
total.
Discriminator of a weak entity set is a set of attributes that
distinguishes entities dependent on one particular strong entity. E.g.,
payment-number
35
Weak Entity Sets
The primary key of a weak entity set is formed by a combination of
theprimary key of the strong entity set the weak entity set
depends on
plus the weak entity sets discriminator
Weak entity set designated by double box and the corresponding
identifying relation by a double diamond
36
Extended E-R Features
Specialization
an entity set may have certain entities that are distinct in some way from
other entities e.g. extra attributes
- The process of sub grouping within an entity set is called specialization.
37
Extended E-R Features
a/c number balance
account
savings checking
interest overdraft 38
Extended E-R Features
a/c number balance
account
ISA
savings checking
interest overdraft 39
Extended E-R Features
Specialization also referred to as superclass-subclass relationship
Subclass inherits the attributes of the superclass
Top-down approach: design process is from upper-level to lower-level
40
Extended E-R Features
Generalization
same as specialization except done using a bottom-up approach, i.e. identify entities
with common features and combine them into a superclass
Simple inversion of specialization
We will apply both processes, in combination for designing ER_schema
41
Extended E-R Features
Constraints: for accurate design, DB designers may choose to place
certain constraints
condition defined
membership of lower-level entity set determined by an entity satisfying a
condition
E.g., for distinguishing Account, we can use account_type attribute.
user defined
membership defined by database user. That is, DB user assigns entities to a
given entity set.
Not automatic, user in charge
E.g., membership of an employee in a group
disjoint
entitybelong to no more than one lower-level entity set. E.g., bank account
can be either savings-account or checking-account but can’t be both. E.g.,
Savings and checking account are disjoint 42
Extended E-R Features
overlapping
may belong to more than one lower-level entity set
E.g., manager can work in multiple work group
total
each higher-level entity must belong to one lower-level entity
set
E.g., Account
partial
some higher-level entities many not belong to any lower-level
entity set. E.g., Employee in a work group
43
Extended E-R Features
Aggregation
Not possible to express relationships among relationships
It’san abstraction through which relationships are treated as
higher-level entities.
customer borrower loan
loan-
officer
44
employee
Extended E-R Features
Every customer-loan pair is repeated in loan officer. Data
redundancy
If combined into one relationship, implies that a loan officer must be
assigned to each loan.
Treat customer, loan and borrower as a high level entity
45
Extended E-R Features
customer borrower loan
loan-
officer
employee
46
Conceptual Database Design
A design methodology is a structured approach that uses
procedures, techniques, tools and documentation aids to support
and facilitate the process of design
Conceptual Database Design is the process of constructing a model
of the information used in an enterprise, independent of ALL
physical considerations
47
Step 1 - Identify Entity Types
Identity and define the main objects (entities) of the enterprise
examine user requirements
look for noun and noun-phrases
look for major objects
identify existence dependent entities (if any)
Entity, relationship or attribute?
Depends on the enterprise
Document entity types
record names and descriptions
48
Step 2 - Identify Relationships
Determine relationships that exist among the entities
sometimes recorded as verbs in user requirements
relationships may be implicit as well as explicit
relationships may be binary, ternary, recursive etc.
Examples
Customer places Order
Instructor teaches Students
Employee is assigned to Project
Author writes Books
Determine the cardinality and participation constraints
Document relationships
name, descriptions, cardinality, participation
49
Step 3 - Identify attributes & Domains
Determine the attributes of the entities and relationships
attributes are the particular piece of information we need to describe
each entity
nouns, noun phrases
what information are we required to hold?
single/composite, derived etc.
Determine the value sets for each attribute
Document the name and value type
Document attributes
name, description, aliases, data type and length, NULL? Etc.
50
Step 4 – Define Constraints
Once the relationships between entities have been defined,
cardinality and participation constraints must be defined
For each relationship, indicate the cardinality, e.g. one-to-one,
many-to-one etc.
Also indicate the participation, total or partial
51
Step 5 - Determine Candidate and Primary Keys
Identify all candidate keys for all entities and select primary key
Guidelines for choosing primary key
minimal set of attributes
least likely to have value changed
least likely to lose uniqueness
fewest characters
easiest to user from users perspective
Note if set is strong or weak
Document the key
52
Step 6 - Specialization/Generalization
Optional
depends on enterprise being modeled
Step 7 - Draw E-R Diagram
Step 8 - Review
53
Total and Partial Participation
Total participation (indicated by double line): every entity in the entity set participates
in at least one relationship in the relationship set
participation of student in advisor relation is total
every student must have an associated instructor
Partial participation: some entities may not participate in any relationship in the
relationship set
Example: participation of instructor in advisor is partial
54
Notation for Expressing More Complex Constraints
A line may have an associated minimum and maximum cardinality, shown in the form
l..h, where l is the minimum and h the maximum cardinality
A minimum value of 1 indicates total participation.
A maximum value of 1 indicates that the entity participates in at most one
relationship
A maximum value of * indicates no limit.
Instructor can advise 0 or more students. A student must have 1 advisor; cannot
have multiple advisors
55
Notation to Express Entity with Complex Attributes
56
Practice Problem #2
Design an E-R diagram for keeping track of the
activities of your favorite sports team.
You should store the matches played, the scores in
each match, the players in each match, and
individual player statistics for each match.
Summary statistics should be modeled as derived
attributes.
57
Design an E-R diagram for keeping track of the activities of your favorite sports team. You
should store the matches played, the scores in each match, the players in each match, and
individual player statistics for each match. Summary statistics should be modeled as derived
attributes.
58
Top 5 Free Database Diagram (ERD) Design Tools
dbdiagram.io
draw.io
Lucidchart
SQLDBM
SQLDBM
QuickDBD
dbdiagram.io
59
59
60
