C06 E-R Model
C06 E-R Model
Database System Concepts - 7th Edition 6.2 ©Silberschatz, Korth and Sudarshan
Design Phases
▪ Initial phase -- characterize fully the data needs of the prospective database
users.
▪ Second phase -- choosing a data model
• Applying the concepts of the chosen data model
• Translating these requirements into a conceptual schema of the
database.
• A fully developed conceptual schema indicates the functional
requirements of the enterprise.
▪ Describe the kinds of operations (or transactions) that will be
performed on the data.
Database System Concepts - 7th Edition 6.3 ©Silberschatz, Korth and Sudarshan
Design Phases (Cont.)
▪ Final Phase -- Moving from an abstract data model to the implementation of the
database
• 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
Database System Concepts - 7th Edition 6.4 ©Silberschatz, Korth and Sudarshan
Design Alternatives
▪ In designing a database schema, we must ensure that we avoid two major pitfalls:
• Redundancy: a bad design may result in repeat information.
▪ Redundant representation of information may lead to data inconsistency
among the various copies of information
• Incompleteness: a bad design may make certain aspects of the enterprise
difficult or impossible to model.
▪ Avoiding bad designs is not enough. There may be a large number of good
designs from which we must choose.
Database System Concepts - 7th Edition 6.5 ©Silberschatz, Korth and Sudarshan
Design Approaches
Database System Concepts - 7th Edition 6.6 ©Silberschatz, Korth and Sudarshan
ER model -- Database Modeling
Database System Concepts - 7th Edition 6.7 ©Silberschatz, Korth and Sudarshan
Entity Sets
Database System Concepts - 7th Edition 6.8 ©Silberschatz, Korth and Sudarshan
Entity Sets -- instructor and student
Database System Concepts - 7th Edition 6.9 ©Silberschatz, Korth and Sudarshan
Representing Entity sets in ER Diagram
Database System Concepts - 7th Edition 6.10 ©Silberschatz, Korth and Sudarshan
Relationship Sets
Database System Concepts - 7th Edition 6.11 ©Silberschatz, Korth and Sudarshan
Relationship Sets (Cont.)
Database System Concepts - 7th Edition 6.12 ©Silberschatz, Korth and Sudarshan
Representing Relationship Sets via ER Diagrams
Database System Concepts - 7th Edition 6.13 ©Silberschatz, Korth and Sudarshan
Relationship Sets (Cont.)
Database System Concepts - 7th Edition 6.14 ©Silberschatz, Korth and Sudarshan
Relationship Sets with Attributes
Database System Concepts - 7th Edition 6.15 ©Silberschatz, Korth and Sudarshan
Roles
Database System Concepts - 7th Edition 6.16 ©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.
▪ 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 - 7th Edition 6.17 ©Silberschatz, Korth and Sudarshan
Non-binary Relationship Sets
Database System Concepts - 7th Edition 6.18 ©Silberschatz, Korth and Sudarshan
Complex Attributes
▪ Attribute types:
• Simple and composite attributes.
• Single-valued and multivalued attributes
▪ Example: multivalued attribute: phone_numbers
• Derived attributes
▪ Can be computed from other attributes
▪ Example: age, given date_of_birth
▪ Domain – the set of permitted values for each attribute
Database System Concepts - 7th Edition 6.19 ©Silberschatz, Korth and Sudarshan
Composite Attributes
Database System Concepts - 7th Edition 6.20 ©Silberschatz, Korth and Sudarshan
Representing Complex Attributes in ER Diagram
Database System Concepts - 7th Edition 6.21 ©Silberschatz, Korth and Sudarshan
Mapping Cardinality Constraints
▪ 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
Database System Concepts - 7th Edition 6.22 ©Silberschatz, Korth and Sudarshan
Mapping Cardinalities
Database System Concepts - 7th Edition 6.23 ©Silberschatz, Korth and Sudarshan
Mapping Cardinalities
Database System Concepts - 7th Edition 6.24 ©Silberschatz, Korth and Sudarshan
Representing Cardinality Constraints in ER Diagram
Database System Concepts - 7th Edition 6.25 ©Silberschatz, Korth and Sudarshan
One-to-Many Relationship
Database System Concepts - 7th Edition 6.26 ©Silberschatz, Korth and Sudarshan
Many-to-One Relationships
Database System Concepts - 7th Edition 6.27 ©Silberschatz, Korth and Sudarshan
Many-to-Many Relationship
Database System Concepts - 7th Edition 6.28 ©Silberschatz, Korth and Sudarshan
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
Database System Concepts - 7th Edition 6.29 ©Silberschatz, Korth and Sudarshan
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.
▪ Example
Database System Concepts - 7th Edition 6.30 ©Silberschatz, Korth and Sudarshan
Primary Key
▪ Primary keys provide a way to specify how entities and relations are
distinguished. We will consider:
• Entity sets
• Relationship sets.
• Weak entity sets
Database System Concepts - 7th Edition 6.31 ©Silberschatz, Korth and Sudarshan
Primary key for Entity Sets
Database System Concepts - 7th Edition 6.32 ©Silberschatz, Korth and Sudarshan
Primary Key for Relationship Sets
Database System Concepts - 7th Edition 6.33 ©Silberschatz, Korth and Sudarshan
Weak Entity Sets
Database System Concepts - 7th Edition 6.34 ©Silberschatz, Korth and Sudarshan
Weak Entity Sets (Cont.)
▪ An alternative way to deal with this redundancy is to not store the attribute
course_id in the section entity and to only store the remaining attributes
section_id, year, and semester.
• However, the entity set section then does not have enough attributes to
identify a particular section entity uniquely
▪ To deal with this problem, we treat the relationship sec_course as a special
relationship that provides extra information, in this case, the course_id, required to
identify section entities uniquely.
▪ A weak entity set is one whose existence is dependent on another entity, called its
identifying entity
▪ Instead of associating a primary key with a weak entity, we use the identifying
entity, along with extra attributes called discriminator to uniquely identify a
weak entity.
Database System Concepts - 7th Edition 6.35 ©Silberschatz, Korth and Sudarshan
Weak Entity Sets (Cont.)
▪ An entity set that is not a weak entity set is termed a strong entity set.
▪ Every weak entity must be associated with an identifying entity; that is, the weak
entity set is said to be existence dependent on the identifying entity set.
▪ The identifying entity set is said to own the weak entity set that it identifies.
▪ The relationship associating the weak entity set with the identifying entity set is
called the identifying relationship.
▪ Note that the relational schema we eventually create from the entity set section
does have the attribute course_id, for reasons that will become clear later, even
though we have dropped the attribute course_id from the entity set section.
Database System Concepts - 7th Edition 6.36 ©Silberschatz, Korth and Sudarshan
Expressing Weak Entity Sets
Database System Concepts - 7th Edition 6.37 ©Silberschatz, Korth and Sudarshan
E-R Diagram for a University Enterprise
Database System Concepts - 7th Edition 6.38 ©Silberschatz, Korth and Sudarshan
Reduction to Relation Schemas
▪ Entity sets and relationship sets can be expressed uniformly as relation schemas
that represent the contents of the database.
▪ A database which conforms to an E-R diagram can be represented by a collection
of schemas.
▪ 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.
Database System Concepts - 7th Edition 6.39 ©Silberschatz, Korth and Sudarshan
Representing Entity Sets
▪ A weak entity set becomes a table that includes a column for the primary key of
the identifying strong entity set
Database System Concepts - 7th Edition 6.40 ©Silberschatz, Korth and Sudarshan
Representation of Entity Sets with Composite Attributes
Database System Concepts - 7th Edition 6.41 ©Silberschatz, Korth and Sudarshan
Representation of Entity Sets with Multivalued Attributes
Database System Concepts - 7th Edition 6.42 ©Silberschatz, Korth and Sudarshan
Representing Relationship Sets
Database System Concepts - 7th Edition 6.43 ©Silberschatz, Korth and Sudarshan
Extended E-R Features
Database System Concepts - 7th Edition 6.44 ©Silberschatz, Korth and Sudarshan
Specialization
▪ Top-down design process; we designate sub-groupings within an entity set that are
distinctive from other entities in the set.
▪ These sub-groupings become lower-level entity sets that have attributes or
participate in relationships that do not apply to the higher-level entity set.
▪ Depicted by a triangle component labeled ISA (e.g., instructor “is a” person).
▪ Attribute inheritance – a lower-level entity set inherits all the attributes and
relationship participation of the higher-level entity set to which it is linked.
Database System Concepts - 7th Edition 6.45 ©Silberschatz, Korth and Sudarshan
Specialization Example
▪ Overlapping – employee and student
▪ Disjoint – instructor and secretary
▪ Total and partial
Database System Concepts - 7th Edition 6.46 ©Silberschatz, Korth and Sudarshan
Generalization
▪ A bottom-up design process – combine a number of entity sets that share the
same features into a higher-level entity set.
▪ Specialization and generalization are simple inversions of each other; they are
represented in an E-R diagram in the same way.
▪ The terms specialization and generalization are used interchangeably.
Database System Concepts - 7th Edition 6.47 ©Silberschatz, Korth and Sudarshan
Aggregation
Database System Concepts - 7th Edition 6.48 ©Silberschatz, Korth and Sudarshan
Aggregation (Cont.)
Database System Concepts - 7th Edition 6.49 ©Silberschatz, Korth and Sudarshan
Aggregation (Cont.)
Database System Concepts - 7th Edition 6.50 ©Silberschatz, Korth and Sudarshan
E-R Design Decisions
Database System Concepts - 7th Edition 6.51 ©Silberschatz, Korth and Sudarshan
Summary of Symbols Used in E-R Notation
Database System Concepts - 7th Edition 6.52 ©Silberschatz, Korth and Sudarshan
Symbols Used in E-R Notation (Cont.)
Database System Concepts - 7th Edition 6.53 ©Silberschatz, Korth and Sudarshan
End of Chapter 6
Database System Concepts - 7th Edition 6.54 ©Silberschatz, Korth and Sudarshan