Professional Documents
Culture Documents
E-R Model
E-R Model
E-R Model
E-R Model
Overview of the Design Process
The Entity-Relationship Model
Complex Attributes
Mapping Cardinalities
Primary Key
Removing Redundant Attributes in Entity Sets
Reducing ER Diagrams to Relational Schemas
Extended E-R Features
Entity-Relationship Design Issues
Alternative Notations for Modeling Data
Other Aspects of Database Design
Slide 2
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.
Slide 3
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
Slide 4
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.
Slide 5
Design Approaches
Slide 6
Outline of the ER Model
Slide 7
ER model -- Database Modeling
Slide 8
Entity Sets
Slide 9
Entity Sets -- instructor and student
Slide 10
Representing Entity sets in ER Diagram
Slide 11
Relationship Sets
Slide 12
Relationship Sets (Cont.)
Slide 13
Representing Relationship Sets via ER Diagrams
Slide 14
Relationship Sets (Cont.)
Slide 15
Relationship Sets with Attributes
Slide 16
Roles
Slide 17
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
Slide 18
Non-binary Relationship Sets
Slide 19
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
Slide 20
Composite Attributes
Slide 21
Representing Complex Attributes in ER Diagram
Slide 22
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
Slide 23
Mapping Cardinalities
Slide 24
Mapping Cardinalities
Slide 25
Representing Cardinality Constraints in ER Diagram
Slide 26
One-to-Many Relationship
Slide 27
Many-to-One Relationships
Slide 28
Many-to-Many Relationship
Slide 29
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
Slide 30
Notation for Expressing More Complex Constraints
Slide 31
Cardinality Constraints on Ternary Relationship
We allow at most one arrow out of a ternary (or greater degree) relationship to
indicate a cardinality constraint
For example, 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.
For example, 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
Slide 32
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
Slide 33
Primary key for Entity Sets
Slide 34
Primary Key for Relationship Sets
Slide 35
Choice of Primary key for Binary Relationship
Slide 36
Weak Entity Sets
Slide 37
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.
Slide 38
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.
Slide 39
Expressing Weak Entity Sets
Slide 40
Redundant Attributes
stud_dept
The attribute dept_name in student below replicates information present in the
relationship and is therefore redundant
and needs to be removed.
BUT: when converting back to tables, in some cases the attribute gets reintroduced, as we
will see later.
Slide 41
E-R Diagram for a University Enterprise
Slide 42
Reduction to Relation Schemas
Slide 43
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.
Slide 44
Representing Entity Sets
A weak entity set becomes a table that includes a column for the primary key of the
identifying strong entity set
Slide 45
Representation of Entity Sets with Composite Attributes
Slide 46
Representation of Entity Sets with Multivalued Attributes
Slide 47
Representing Relationship Sets
Slide 48
Redundancy of Schemas
Many-to-one and one-to-many relationship sets that are total on the many-
side can be represented by adding an extra attribute to the “many” side,
containing the primary key of the “one” side
Example: Instead of creating a schema for relationship set inst_dept, add
an attribute dept_name to the schema arising from entity set instructor
Example
Slide 49
Redundancy of Schemas (Cont.)
For one-to-one relationship sets, either side can be chosen to act as the “many”
side
• That is, an extra attribute can be added to either of the tables corresponding
to the two entity sets
If participation is partial on the “many” side, replacing a schema by an extra
attribute in the schema corresponding to the “many” side could result in null
values
Slide 50
Redundancy of Schemas (Cont.)
The schema corresponding to a relationship set linking a weak entity set to its
identifying strong entity set is redundant.
Example: The section schema already contains the attributes that would appear in
the sec_course schema
Slide 51
Extended E-R Features
Slide 52
Specialization
Slide 53
Specialization Example
Overlapping – employee and student
Disjoint – instructor and secretary
Total and partial
Slide 54
Representing Specialization via Schemas
Method 1:
• Form a schema for the higher-level entity
• Form a schema for each lower-level entity set, include primary key of
higher-level entity set and local attributes
Slide 55
Representing Specialization as Schemas (Cont.)
Method 2:
• Form a schema for each entity set with all local and inherited attributes
• Drawback: name, street and city may be stored redundantly for people
who are both students and employees
Slide 56
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.
Slide 57
Completeness constraint
Slide 58
Completeness constraint (Cont.)
Slide 59
Aggregation
Slide 60
Aggregation (Cont.)
Slide 61
Aggregation (Cont.)
Slide 62
Reduction to Relational Schemas
Slide 63
Design Issues
Common Mistakes in E-R Diagrams
Example of erroneous E-R diagrams
Slide 65
Common Mistakes in E-R Diagrams (Cont.)
Slide 66
Entities vs. Attributes
Use of phone as an entity allows extra information about phone numbers (plus
multiple phone numbers)
Slide 67
Entities vs. Relationship sets
Slide 68
Binary Vs. Non-Binary Relationships
Slide 69
Converting Non-Binary Relationships to Binary Form
Slide 70
Converting Non-Binary Relationships (Cont.)
Slide 71
E-R Design Decisions
Slide 72
Summary of Symbols Used in E-R Notation
Slide 73
Symbols Used in E-R Notation (Cont.)
Slide 74
Alternative ER Notations
Slide 75
Alternative ER Notations
Slide 76
Other Aspects of Database Design
Functional Requirements
Data Flow, Workflow
Schema Evolution
Slide 77
Summary
Database design mainly involves the design of the database schema. The entity relationship
(E-R) data model is a widely used data model for database design. It provides a convenient
graphical representation to view data, relationships, and constraints.
The E-R model is intended primarily for the database-design process. It was developed to
facilitate database design by allowing the specification of an enterprise schema. Such a
schema represents the overall logical structure of the database. This overall structure can be
expressed graphically by an E-R diagram.
An entity is an object that exists in the real world and is distinguishable from other objects.
We express the distinction by associating with each entity a set of attributes that describes
the object.
Slide 78
A relationship is an association among several entities. A relationship set is a
collection of relationships of the same type, and an entity set is a collection of entities
of the same type.
The terms superkey, candidate key, and primary key apply to entity and relationship
sets as they do for relation schemas. Identifying the primary key of a relationship set
requires some care, since it is composed of attributes from one or more of the related
entity sets.
Mapping cardinalities express the number of entities to which another entity can be
associated via a relationship set.
An entity set that does not have sufficient attributes to forma primary key is termed a
weak entity set. An entity set that has a primary key is termed a strong entity set.
Slide 79
The various features of the E-R model offer the database designer numerous choices in how
to best represent the enterprise being modeled. Concepts and objects may, in certain cases,
be represented by entities, relationships, or attributes.
Aspects of the overall structure of the enterprise may be best described by using weak entity
sets, generalization, specialization, or aggregation. Often, the designer must weigh the merits
of a simple, compact model versus those of a more precise, but more complex one.
Slide 80
Specialization and generalization define a containment relationship between a higher-level entity
set and one or more lower-level entity sets. Specialization is the result of taking a subset of a
higher-level entity set to form a lower-level entity set. Generalization is the result of taking the
union of two or more disjoint (lowerlevel) entity sets to produce a higher-level entity set. The
attributes of higher-level entity sets are inherited by lower-level entity sets.
Aggregation is an abstraction in which relationship sets (along with their associated entity sets)
are treated as higher-level entity sets, and can participate in relationships.
Care must be taken in E-R design. There are a number of common mistakes to avoid. Also, there
are choices among the use of entity sets, relationship sets, and attributes in representing aspects
of the enterprise whose correctness may depend on subtle details specific to the enterprise.
Slide 81