U2_ER_upto_map_relations.pdf

Database System Concepts, 6th Ed.
©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
Database Design
and
Entity-Relationship (E-R) Model

7.2
Database System Concepts - 6th Edition
Design Phases
 The initial phase of database design is to characterize fully the
data needs of the 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. The
focus at this point is on describing the data and their
relationships.
 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.

7.3
Design Phases (Cont.)
 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.
The process of moving from an abstract data model to the
implementation of the database, proceeds in two final design
phases.

7.4
Design Approaches
 Entity Relationship (ER) Model
 Models an enterprise as a collection of entities and
relationships
Entity: a thing or object in the enterprise that is
distinguishable from other objects.
– Described by a set of attributes
Relationship: an association among several entities
 Represented diagrammatically by an entity-relationship
diagram:
 Normalization Theory
 Formalize what designs are bad, and test for them

7.5
Outline of the ER Model

7.6
ER model -- Database Modeling
 The ER data model was developed to facilitate database design by
allowing specification of an enterprise schema that represents the
overall logical structure of a database.
 The ER model is very useful in mapping the meanings and
interactions of real-world enterprises onto a conceptual schema.
 The ER data model employs three basic concepts:
 entity sets
 relationship sets
 attributes.
 The ER model also has an associated diagrammatic
representation, the ER diagram, which can express the overall
logical structure of a database graphically.

7.7
Entity Sets
 An entity is an object that exists and is distinguishable from other
objects (often corresponds to a row in a table).
 Example: specific person, company, event, plant
 An entity set is a set of entities of the same type that share the
same properties (often corresponds to a table).
 Example: set of all persons, companies, trees, holidays
 An entity is represented by a set of attributes; i.e., descriptive
properties possessed by all members of an entity set. (often
corresponds to a column in a table)
 Example: Instructor = (ID, name, street, city, salary)
 Each entity has a value for each of its attributes.
Example: Instructor = (ID value is “12121”, name value is “Wu” etc)
 A subset of the attributes form a primary key of the entity set; i.e.,
uniquely identifying each member of the set.

7.8
Entity Sets -- instructor and student
instructor_ID instructor_name student-ID student_name
 A database includes a collection of entity sets, each of which
contains any number of entities of the same type.
 Figure below shows part of a university database that consists of
two entity sets: instructor & student.

7.9
Relationship Sets
 A relationship is an association among several entities.
Example: a relationship advisor associates instructor Einstein
with student Peltier.
i.e. Einstein is an advisor to student Peltier.
ID – Name ID - Name
44553 (Peltier) advisor 22222 (Einstein)
student entity relationship set instructor entity
 A relationship set is a mathematical relation among n  2
entities, each taken from entity sets
{(e1, e2, … en) | e1  E1, e2  E2, …, en  En}
where (e1, e2, …, en) is a relationship

7.10
Relationship Set advisor

7.11
Relationship Sets (Cont.)
 An attribute can also be associated with a relationship set
(descriptive attributes).
 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

7.12
Degree of a Relationship Set
 The degree of a relationship set is the number of participating
entity sets.
 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.
Example: students work on research projects under the
guidance of an instructor.
relationship proj_guide is a ternary relationship between
instructor, student, and project

7.13
Mapping Cardinality (Ratios)
 Cardinality of a set is the total number of unique elements
in a set.
 Cardinality ratios, express the number of entities to which another
entity can be associated via a relationship set.
 Most useful in describing binary relationship sets.
 For a binary relationship set the mapping cardinality must be one of
the following types:
 One to one
 One to many
 Many to one
 Many to many

7.14
Mapping Cardinalities
One-to-one: An entity in A is associated with at most one entity in B,
and an entity in B is associated with at most one entity in A. (FIG-a)
One-to-many: An entity in A is associated with any number (zero or
more) of entities in B. An entity in B, however, can be associated
with at most one entity in A. ( Figure-b)
Note: Some elements in A and B may not be mapped to any elements
in the other set

7.15
Mapping Cardinalities
Many-to-one. An entity in A is associated with at most one entity in B.
An entity in B, however, can be associated with any number (zero or
more) of entities in A. (Figure – a)
Many-to-many. An entity in A is associated with any number (zero or
more)of entities in B, and an entity in B is associated with any number
(zero or more) of entities in A. (Figure – b)
Note: Some elements in A and B may not be mapped to any elements
in the other set

7.16
Participation Constraints
Total Participation: The participation of an entity set E in a
relationship set R is said to be total if every entity in E participates in
at least one relationship in R.
Partial Participation : If only some entities in E participate in
relationship set R, the participation of entity set E in relationship set
R is said to be partial.
(A is partial, B is Total) (Both A,B Total)

7.17
Complex Attributes
 Domain – the set of permitted values for each attribute
 An attribute, in the E-R model, can be characterized by the following
1) Simple (Can not be divided into subparts) and
composite (can be divided into subparts) attributes.

7.18
Complex Attributes
2) Single-valued (single value for a particular entity) and
Multi-valued (set of values for a speciﬁc entity) attributes.
Example: Single-valued : Student_ID
Multi-valued attribute: phone_numbers
3) Stored (value is present ) and
Derived attributes
Can be computed from other attributes
Example: age from given date_of_birth
 An attribute takes a null value when an entity does not have a
value for it.
The null value may indicate “not applicable”—that is, that the value
does not exist for the entity.

7.19
Keys
 A super key of an entity set is a set of one or more attributes
whose values uniquely determine each entity.
 A candidate key of an entity set is a minimal super key
 ID is candidate key of instructor
 course_id is candidate key of course
 Although several candidate keys may exist, one of the candidate
keys is selected to be the primary key.

7.20
Keys for Relationship Sets
 The combination of primary keys of the participating entity sets
forms a super key of a relationship set.
 (s_id, i_id) is the super key of advisor
 NOTE: this means a pair of entity sets can have at most
one relationship in a particular relationship set.
 Must consider the mapping cardinality of the relationship set
when deciding what are the candidate keys.
 Need to consider semantics of relationship set in selecting the
primary key in case of more than one candidate key.

7.21
Redundant Attributes
 When we design a database using the E-R model, we
usually start by identifying those entity sets that should be
included, then we must choose the appropriate attributes,
then relationship sets among the various entities are
formed.
 These relationship sets may result in attributes in the
various entity sets that are redundant and need to be
removed.

7.22
Redundant Attributes
 Suppose we have entity sets
 instructor, with attributes (ID, name, dept_name, salary)
 Department, with attributes (dept_name, building, budget)
and a relationship
 inst_dept relating instructor and department
 Attribute dept_name in entity instructor is redundant since
there is an explicit relationship inst_dept which relates
instructors to departments.
 The attribute replicates information present in the
relationship, and should be removed from instructor.
 A good entity-relationship design does not contain
redundant attributes.

7.23
E-R Diagrams
 Rectangles divided into two parts represent entity sets.
First part: Name of the entity set
Second part: Names of all attributes of the entity set
 Diamonds represent relationship sets.
 Lines link entity sets to relationship sets.
 Attributes listed inside entity rectangle
 Underline indicates primary key attributes

7.24
Relationship Sets with Attributes
Dashed lines link attributes of a relationship set to the relationship
set.
“date” (descriptive attribute) attached to the relationship set advisor
to specify the date on which an instructor became the advisor.

7.25
Cardinality Constraints
 We express cardinality constraints by drawing either a directed
line (), signifying “one,” or an undirected line (—), signifying
“many,” between the relationship set and the entity set.
 One-to-one relationship:
 A student is associated with at most one instructor via the
relationship advisor
 A student is associated with at most one department via the
relationship stud_dept

7.26
One-to-One Relationship
 one-to-one relationship between an instructor and a student
 an instructor is associated with at most one student via
advisor
 and a student is associated with at most one instructor via
advisor

7.27
One-to-Many Relationship
 one-to-many relationship between an instructor and a student
 an instructor is associated with several (including 0) students
via advisor
 a student is associated with at most one instructor via
advisor,
We draw a directed line from the relationship set advisor to the
entity set instructor and an undirected line to the entity set student

7.28
Many-to-One Relationships
 In a many-to-one relationship between an instructor and a
student,
 an instructor is associated with at most one student via
advisor,
 and a student is associated with several (including 0)
instructors via advisor
We draw a directed line from the relationship set advisor to the
entity set student and an undirected line to the entity set instructor.

7.29
Many-to-Many Relationship
 An instructor is associated with several (possibly 0) students via
advisor
 A student is associated with several (possibly 0) instructors via
advisor

7.30
Alternative Notation for Cardinality Limits
 Cardinality limits can also express participation constraints.
 1..1, meaning the minimum and the maximum cardinality are
both 1. That is, each student must have exactly one advisor.
 0..∗ on the line between advisor and instructor indicates that an
instructor can have zero or more students.
Double lines indicate total participation of an entity in a relationship set
one-to-many
Total
Partial

7.31
Participation of an Entity Set in a
Relationship Set
 Total participation (indicated by double line): every entity in the
entity set participates in at least one relationship in the relationship
set
 E.g., participation of student in advisor
 every student must have an instructor as advisor
 Partial participation: some entities may not participate in any
relationship in the relationship set
 Example: participation of instructor in advisor is partial

7.32
Entity With Composite, Multivalued, and Derived
Attributes
 Composite attribute name,
with component attributes
ﬁrst_name, middle_initial, and
last_name.
 Multivalued attribute phone
number, denoted by
{ phone number }
 Derived attribute age,
depicted by age ()

7.33
Roles
 Entity sets of a relationship need not be distinct.
 Each occurrence of an entity set plays a “role” in the
relationship
 The labels “course_id” and “prereq_id” are called roles.

7.34
E-R Diagram with a Ternary Relationship

7.35
Cardinality Constraints on Ternary
Relationship
 We allow at most one arrow out of a ternary (or greater degree)
relationship to indicate a cardinality constraint.
 E.g., an arrow from proj_guide to instructor indicates each student
has at most one guide for a project
 If there is more than one arrow, there are two ways of defining the
meaning.
 E.g., a ternary relationship R between A, B and C with arrows to
B and C could mean
1. each A entity is associated with a unique entity from B and C
or
2. each pair of entities from (A, B) is associated with a unique C
entity, and each pair (A, C) is associated with a unique B
 Each alternative has been used in different formalisms
 To avoid confusion we prohibit more than one arrow

7.36
Weak Entity Sets
 An entity set that has a primary key is termed a strong entity set.
 An entity set that does not have a primary key (its own attribute)
is referred to as a weak entity set.
 The existence of a weak entity set depends on the existence of a
strong entity set (identifying entity set/ owner entity set).
 The relationship between strong entity set and weak entity set is
called identifying relationship, depicted using a double
diamond.
 Weak entity set must relate to the strong entity set via a total,
one-to-many relationship set from the strong entity set to the
weak entity set.
 The identifying relationship set should not have any descriptive
attributes.

7.37
Weak Entity Sets (Cont.)
 Although a weak entity set does not have a primary key, we need a
means of distinguishing among all those entities in the weak entity
set that depend on one particular strong entity.
 The discriminator (or partial key) of a weak entity set is the set
of attributes that distinguishes among all the entities of a weak
entity set.
 The primary key of a weak entity set is formed by the primary key of
the strong entity set on which the weak entity set is existence
dependent, plus the weak entity set’s discriminator.

7.38
 We underline the discriminator of a weak entity set with a
dashed line.
 We put the identifying relationship of a weak entity in a double
diamond.
 Primary key for section – (course_id, sec_id, semester, year)

7.39
 A weak entity set can participate in normal relationships other than
the identifying relationship.
 A weak entity set may participate as owner entity set in an
identifying relationship with another weak entity set.
 It is also possible to have a weak entity set with more than one
owner entity set.
 Then the primary key of the weak entity set would consist of the
union of the primary keys of the owner entity sets, plus the
discriminator of the weak entity set.

7.40
Summary of Symbols Used in E-R Notation

7.41

7.42
E-R Diagram Exercise-1
Construct an E-R diagram for a hospital with a set of patients
and a set of medical doctors. Associate with each patient a log
of the various tests conducted by the doctors.

7.43
E-R Diagram Exercise-2
 Construct an E-R diagram for a car insurance company
whose customers own one or more cars each.
Each car has associated with it one to any number of
recorded accidents.
It is possible that there is an accident report where the
participating car is unknown.
Each insurance policy covers one or more cars, and has
one or more premium payments associated with it.
Each premium payment is for a particular period of
time, and has an associated due date, and the date
when the payment was received.

7.44
E-R Diagram car insurance company

7.45
Reduction to Relational Schemas

7.46
Conceptual to Relational
Conceptual Model:
Relational Model:
PERSON
BUYS
PRODUCT
name
price name ssn

7.47
Reduction to Relation Schemas
 We can convert an E-R design into a relational database
(consisting of relations/tables) design.
 A database which conforms to an E-R diagram can be
represented by a collection of schemas.
 Entity sets and relationship sets can be expressed uniformly as
relation schemas that represent the contents of the database.
 For each entity set and relationship set there is a unique schema
that is assigned the name of the corresponding entity set or
relationship set.
 Each schema has a number of columns (generally
corresponding to attributes), which have unique names.

7.48
Representing Strong Entity Sets With Simple
Attributes
 A strong entity set reduces to a relation schema with the same
attributes.
 The primary key of the entity set serves as the primary key of the
resulting schema.
 The entity set student has three attributes: ID,
name, tot_cred.
 We represent this entity set by a relation
schema (Table) called student with three
attributes (Columns):
student (ID, name, tot_cred)
Since student ID is the primary key of the entity set, it is also the
primary key of the relation schema.

7.49
Representing Strong Entity Sets With
Composite Attributes
 Composite attributes are compressed out by
creating a separate attribute for each
component attribute.
 Example: given entity set instructor with
composite attribute name with component
attributes first_name, middle_initial and
last_name the relation schema
instructor will be with three attributes
first_name, middle_initial and
last_name.
 There is no separate attribute or schema
for name.
Instructor (first_name, middle_initial, last_name)

7.50
Composite Attributes
 Ignoring multivalued attributes, extended
instructor schema is
 instructor( ID,
first_name, middle_initial, last_name,
street_number, street_name,
apt_number, city, state, zip_code,
date_of_birth)
 Derived attributes are generally not
included in schema.

7.51
 A multivalued attribute M of an entity set E is represented by a
separate schema EM
 Schema EM has attributes corresponding to the primary key of E
as a foreign key attribute referencing primary key of E and an
attribute corresponding to multivalued attribute M.
 Example: Multivalued attribute phone_number of instructor is
represented by a schema:
instructor_phone= ( ID, phone_number)
 a primary key of the relation schema consisting of all attributes
of the schema.
Multivalued Attributes

(a) CUSTOMER
entity type with
simple
attributes
Mapping a strong entity set CUSTOMER
(b) CUSTOMER relation
52

53
(a) CUSTOMER
entity type with
composite
attribute
Mapping a composite attribute
(b) CUSTOMER relation with address detail
53

54
54
One-to-many relationship between original entity and new relation
Multivalued attribute becomes a separate relation with foreign key
(b)
Mapping a multivalued attribute
CUSTOMER
entity type
with
multivalued
attribute

7.55
Representing Weak Entity Sets With Simple
Attributes
 A weak entity set becomes a relation with attributes as defined
earlier and also includes the primary key attribute of the strong
entity set as a foreign key attribute.
 The primary key of the strong entity set and the discriminator of
the weak entity set serves as the primary key of the schema.
 A weak entity set section becomes a relation
section ( course_id, sec_id, semester, year )
 The attribute course_id referencing the primary key of the
course schema.

7.56
Representing Binary Relationship Sets
 A many-to-many relationship set is represented as a schema
with attributes for the primary keys of the two participating entity
sets, and any descriptive attributes of the relationship set.
 Union of the primary-key attributes from the participating entity
sets becomes the primary key of the relationship set.
 Example: schema for relationship set advisor ?
advisor = (student_ID, instructor_ID)

7.57
 Many-to-one and one-to-many relationship sets can be
represented by adding an extra attribute as foreign key to the
“many” side, containing the primary key of the “one” side.
(Generally total participation on the many-side)
 Example: Instead of creating a schema for relationship set
inst_dept, add an attribute dept_name to the schema instructor as
foreign key referencing department (dept_name).

7.58
 For one-to-one relationship sets, either side can be chosen to act
as the “many” side
 That is, extra attribute can be added to either of the tables
corresponding to the two entity sets.
 Generally primary key on total participation side becomes a
foreign key on partial participation side.
Course = (Rollno, CourseCode,CourseName,Duration)

7.59
Summary
Many-to-Many–Create a new relation with the
primary keys of the two entities as its primary
key.
One-to-Many(Many-to-One)–Primary key on
the one side becomes a foreign key on the
many side.
One-to-One– Primary key on total side
becomes a foreign key on partial side.
59

60
Mapping a 1:M relationship
Relationship between customers and orders
b) Mapping the relationship
Foreign key
60

62
new
intersection
relation
Foreign key
Foreign key
Composite primary key
Mapping an M:N relationship (cont.)
b) resulting relations
62

63
Mapping a binary 1:1 relationship
a) In charge relationship (1:1)
Often in 1:1 relationships, one direction is partial
63

64
b) Resulting relations
Mapping a binary 1:1 relationship
Foreign key goes in the relation on the partial side,
matching the primary key on the total side
64

7.65
E-R Diagram of Hospital

7.66
Mapping Relations of Hospital
patients (patient_ss#, name, insurance, date-admitted,
date-checked-out)
doctors (doctor_dss#, name, specialization)
test (test_id, patient-ss#,testname, date, time, result)
Dr-patient (patient-ss#, doctor-dss#)
performed_by (test_id, doctor-dss#)

7.67
E-R Diagram car insurance company

7.68
Mapping Relations of
car insurance company
customer (customer-id, name, address)
car (license_no, customer-id, model)
accident (report_id,date,place)
participated (license_no, report_id)
Policy (policy_id)
covers (policy_id,license_no)
premium_payment (policy_id, payment_no, due date,
amount,received_on)

U2_ER_upto_map_relations.pdf

Recommended

Recommended

More Related Content

Similar to U2_ER_upto_map_relations.pdf

Similar to U2_ER_upto_map_relations.pdf (20)

Recently uploaded

Recently uploaded (20)

U2_ER_upto_map_relations.pdf