0% found this document useful (0 votes)
9 views39 pages

Ch7 1

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views39 pages

Ch7 1

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 39

Chapter 7: Entity-Relationship Model

Database System Concepts, 6th Ed.


©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
Chapter 7: Entity-Relationship Model

 Design Process
 Modeling
 Constraints
 E-R Diagram
 Design Issues
 Weak Entity Sets

Database System Concepts - 6th Edition 7.2 ©Silberschatz, Korth and Sudarshan
Overview of Database Design
 The initial phase: characterize fully the data needs of the prospective database users. The
outcome of this phase is a specification of user requirements.
 The conceptual-design phase: 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.
 What are the entities and relationships in the enterprise?
 What information about these entities and relationships should we store in the
database?
 What are the integrity constraints or business rules that hold?
 Specification of functional requirements: For fully developed conceptual schema also
indicates the functional requirements of the enterprise.
 Users describe the kinds of operations (or transactions) that will be performed on the data
(i.e. modifying or updating data, searching for and retrieving specific data, and deleting
data..).
 At this stage of conceptual design, the designer can review the schema to ensure it meets
functional requirements.
 Logical-design phase: mapping the conceptual schema defined using the entity-relationship
model into a relation schema.
 Physical Design phase: the physical features of the database are specified. (the form of file
organization and choice of index structures)

Database System Concepts - 6th Edition 7.3 ©Silberschatz, Korth and Sudarshan
The Entity-Relationship Model

 A database can be modeled as:


 a collection of entities,
 properties of entities called attributes,
 relationship among entities.
 Entity: is an object that exists and is distinguishable from other
objects(are primary things of a problem domain about which
users need to record data.).
 Example: specific person, company, event.
 Attributes: are properties of entities or relationships.
 Example: people have names and addresses
 Entity set: is a set of entities of the same type that share the
same properties.
 Example: set of all persons, companies, trees, holidays

Database System Concepts - 6th Edition 7.4 ©Silberschatz, Korth and Sudarshan
Entity Sets instructor and student

instructor_ID instructor_name student-ID student_name

Database System Concepts - 6th Edition 7.5 ©Silberschatz, Korth and Sudarshan
Relationship Sets

 Relationship: is an association among several entities


 Relationship: relates two or more relations with a specific meaning.
Examples:
instructor 22222 (Einstein) advisor Student 44553 (Peltier)

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


 Example:
(44553,22222)  advisor

Database System Concepts - 6th Edition 7.6 ©Silberschatz, Korth and Sudarshan
Relationship Set advisor

Database System Concepts - 6th Edition 7.7 ©Silberschatz, Korth and Sudarshan
Attributes

 An attribute can also be property of 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

Database System Concepts - 6th Edition 7.8 ©Silberschatz, Korth and Sudarshan
Attributes

 An entity is represented by a set of attributes, that is descriptive


properties possessed by all members of an entity set.
 Example:
instructor = (ID, name, street, city, salary )
course= (course_id, title, credits)
 Domain – the set of permitted values for each attribute
 Attribute types:
 Simple and composite attributes.
 Example: composite attribute: name, address.
 Single-valued and multivalued attributes
 Example: multivalued attribute: phone_numbers
 Derived attributes
 Can be computed from other attributes
 Example: age, given date_of_birth

Database System Concepts - 6th Edition 7.9 ©Silberschatz, Korth and Sudarshan
Composite Attributes

Database System Concepts - 6th Edition 7.10 ©Silberschatz, Korth and Sudarshan
Degree of a Relationship Set
 Binary relationship
 involve two entity sets (or degree two).
 most relationship sets in a database system are binary.
 Non-binary relationship
 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

Database System Concepts - 6th Edition 7.11 ©Silberschatz, Korth and Sudarshan
Constraints
 An E-R enterprise schema may define
certain constraints to which the
contents of a database must conform.
1. Mapping Cardinality Constraints
2. Participation Constraints
3. Keys

Database System Concepts - 6th Edition 7.12 ©Silberschatz, Korth and Sudarshan
Mapping Cardinality Constraints
 Cardinality expresses the maximum number of entities
that can be associated with another entity via a relationship.
 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

Database System Concepts - 6th Edition 7.13 ©Silberschatz, Korth and Sudarshan
Mapping Cardinalities

One to one One to many


For entities customer and account
One-to-one: one customer can have at most one account and one
account cannot be owned by more than one customer.
One-to-many: one customer can have many accounts, but one account
cannot be owned by more than one customer.

Database System Concepts - 6th Edition 7.14 ©Silberschatz, Korth and Sudarshan
Mapping Cardinalities

Many to one Many to many

Many-to-one: one customer can have at most one account, but one
account may be owned by many customers.
Many-to-many: one customer can have many accounts and one
account may be owned by many customers.

Database System Concepts - 6th Edition 7.15 ©Silberschatz, Korth and Sudarshan
Participation Constraints
 Participation expresses the minimum number of entities that can be
associated with another entity via a relationship.
 Total participation : every entity in the entity set participates in at least one
relationship in the relationship set
 Example: participation of section in sec_course is total
 every section must have an associated course
 Partial participation: some entities may not participate in any relationship
in the relationship set
 Example: participation of instructor in advisor is partial

Database System Concepts - 6th Edition 7.16 ©Silberschatz, Korth and Sudarshan
Keys for Entity Sets

 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.

Database System Concepts - 6th Edition 7.17 ©Silberschatz, Korth and Sudarshan
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.
 Example: if we wish to track multiple meeting dates
between a student and her advisor, we cannot assume
a relationship for each meeting. We can use a
multivalued attribute though
 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

Database System Concepts - 6th Edition 7.18 ©Silberschatz, Korth and Sudarshan
Redundant Attributes
 Suppose we have entity sets
 instructor, with attributes including dept_name
 department
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
 BUT: when converting back to tables, in some cases
the attribute gets reintroduced, as we will see.

Database System Concepts - 6th Edition 7.19 ©Silberschatz, Korth and Sudarshan
Redundant Attributes (cont.)
 The Entity sets
 classroom: with attributes (building, room number, capacity).
 department: with attributes (dept name, building, budget).
 course: with attributes (course id, title, credits).
 instructor: with attributes (ID, name, salary).
 section: with attributes (course id, sec id, semester, year).
 student: with attributes (ID, name, tot cred).
 time slot: with attributes (time slot id, {(day, start time, end time) }).
 The relationship sets:
 Inst_dept: relating instructors with departments.
 Stud_dept: relating students with departments.
 teaches: relating instructors with sections.
 takes: relating students with sections, with a descriptive attribute grade.
 Course_dept: relating courses with departments.
 Sec_course: relating sections with courses.
 Sec_class: relating sections with classrooms.
 Sec_time slot: relating sections with time slots.
 advisor: relating students with instructors.
 prereq: relating courses with prerequisite courses.

Database System Concepts - 6th Edition 7.20 ©Silberschatz, Korth and Sudarshan
E-R Diagrams

 Rectangles represent entity sets.


 Diamonds represent relationship sets.
 Attributes listed inside entity rectangle
 Underline indicates primary key attributes

Database System Concepts - 6th Edition 7.21 ©Silberschatz, Korth and Sudarshan
Relationship Sets with Attributes

Database System Concepts - 6th Edition 7.22 ©Silberschatz, Korth and Sudarshan
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
stud_dept

Database System Concepts - 6th Edition 7.23 ©Silberschatz, Korth and Sudarshan
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

Database System Concepts - 6th Edition 7.24 ©Silberschatz, Korth and Sudarshan
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,

Database System Concepts - 6th Edition 7.25 ©Silberschatz, Korth and Sudarshan
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

Database System Concepts - 6th Edition 7.26 ©Silberschatz, Korth and Sudarshan
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

Database System Concepts - 6th Edition 7.27 ©Silberschatz, Korth and Sudarshan
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 section in sec_course is total
 every section must have an associated course
 Partial participation: some entities may not participate in any
relationship in the relationship set.
 Example: participation of instructor in advisor is partial

Database System Concepts - 6th Edition 7.28 ©Silberschatz, Korth and Sudarshan
Alternative Notation for Cardinality Limits

 Cardinality limits can also express participation constraints

Database System Concepts - 6th Edition 7.29 ©Silberschatz, Korth and Sudarshan
Entity With Composite, Multivalued, and Derived
Attributes

Database System Concepts - 6th Edition 7.30 ©Silberschatz, Korth and Sudarshan
Roles

 The entity’s role: is the function that an entity plays in a relationship.


 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.

 Since entity sets participating in a relationship set are generally distinct, roles are
implicit and are not usually specified.
 Explicit role names are useful when the entity sets of a relationship set are
not distinct; that is, the same entity set participates in a relationship set more
than once, in different roles.
 This type of relationship set is called a recursive relationship set.
Database System Concepts - 6th Edition 7.31 ©Silberschatz, Korth and Sudarshan
Ternary Relationship

Database System Concepts - 6th Edition 7.32 ©Silberschatz, Korth and Sudarshan
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 outlaw more than one arrow

Database System Concepts - 6th Edition 7.33 ©Silberschatz, Korth and Sudarshan
Weak Entity Sets

 A weak entity is an entity that depends on the existence of another


entity. In more technical terms it can defined as an entity that cannot
be identified by its own attributes.
 It does not have a primary key.
 It uses a foreign key combined with its attributed to form the primary
key.
 The existence of a weak entity set depends on the existence of a
identifying entity set
 It must relate to the identifying entity set via a total, one-to-many
relationship set from the identifying to the weak entity set
 Identifying relationship depicted using a double diamond
 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.

Database System Concepts - 6th Edition 7.34 ©Silberschatz, Korth and Sudarshan
Weak Entity Sets (Cont.)
 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)

Database System Concepts - 6th Edition 7.35 ©Silberschatz, Korth and Sudarshan
Weak Entity Sets (Cont.)

 Note: the primary key of the strong entity set is not


explicitly stored with the weak entity set, since it is
implicit in the identifying relationship.
 If course_id were explicitly stored, section could
be made a strong entity, but then the relationship
between section and course would be duplicated
by an implicit relationship defined by the attribute
course_id common to course and section

Database System Concepts - 6th Edition 7.36 ©Silberschatz, Korth and Sudarshan
E-R Diagram for a University Enterprise

Database System Concepts - 6th Edition 7.37 ©Silberschatz, Korth and Sudarshan
Alternative Notations for Modeling Data

Database System Concepts - 6th Edition 7.38 ©Silberschatz, Korth and Sudarshan
How about doing an ER design
interactively on the board?
Suggest an application to be modeled.

Database System Concepts, 6th Ed.


©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use

You might also like