Ch7 1
Ch7 1
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
Database System Concepts - 6th Edition 7.4 ©Silberschatz, Korth and Sudarshan
Entity Sets instructor and student
Database System Concepts - 6th Edition 7.5 ©Silberschatz, Korth and Sudarshan
Relationship Sets
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
Database System Concepts - 6th Edition 7.8 ©Silberschatz, Korth and Sudarshan
Attributes
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
Database System Concepts - 6th Edition 7.14 ©Silberschatz, Korth and Sudarshan
Mapping Cardinalities
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
Database System Concepts - 6th Edition 7.17 ©Silberschatz, Korth and Sudarshan
Keys for Relationship Sets
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
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
Database System Concepts - 6th Edition 7.23 ©Silberschatz, Korth and Sudarshan
One-to-One Relationship
Database System Concepts - 6th Edition 7.24 ©Silberschatz, Korth and Sudarshan
One-to-Many Relationship
Database System Concepts - 6th Edition 7.25 ©Silberschatz, Korth and Sudarshan
Many-to-One Relationships
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
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
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
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.)
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.