Lecture 13-15

Database Design and the E-R Model

Outline
Design Phases
Design Approaches
ER Model
Design Phases
The initial phase of database design is to characterize fully the data needs of the
prospective database users. (requirements of system)
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.
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.
Design Phases (Cont.)
The process of moving from an abstract data model to the implementation of the
database proceeds in two final design phases.
Logical Design – Deciding on the database schema.

Business decision (What) – What attributes should we record in the database?

Computer Science decision (Why) – 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
Design Approaches
Entity Relationship Model (top down approach)
Models an enterprise as a collection of entities and relationships
Represented diagrammatically by an entity-relationship diagram:

Normalization Theory (bottom up approach)

Formalize what designs are bad, and test for them
Popular Notations
ER model -- Database Modeling
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.
Entity Sets
An entity is an object that exists and is distinguishable from other objects.
Example: specific person, company, event, plant
An entity set (entity type) is a set of entities of the same type that share the same
properties.
Example: set of all persons, companies, trees, holidays
An entity is represented by a set of attributes.
Example:
instructor = (ID, name, street, city, salary )
course= (course_id, title, credits)
Entity Sets -- instructor and student
instructor_ID instructor_name student-ID student_name
Relationship Sets
A relationship is an association among several entities
Example: 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
Example: (44553,22222)  advisor
Relationship Set advisor
Relationship Sets (Cont.)
An attribute can also be associated with 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
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.
Recursive Relationship
Relationship type where same entity type participates more than once in different
roles.
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
 Mapping Cardinalities

One to One to many

one

Note: Some elements in A and B may not be mapped to any elements in the other
set
 Mapping Cardinalities

Many to one Many to many

Note: Some elements in A and B may not be mapped to any elements in the other
set
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
Composite Attributes
Redundant Attributes
Suppose we have entity sets:
instructor, with attributes: ID, name, dept_name, salary
department, with attributes: dept_name, building, budget
We model the fact that each instructor has an associated department using a
relationship set inst_dept
The attribute dept_name appears in both entity sets. Since it is the primary key for
the entity set department, it replicates information present in the relationship and is
therefore redundant in the entity set instructor and needs to be removed.
BUT: when converting back to tables, in some cases the attribute gets reintroduced,
as we will see later.
Weak Entity Sets
An entity set that does not have sufficient attributes to form a primary key is termed a
weak entity set. An entity set that has a primary key is termed a strong entity set.
For a weak entity set to be meaningful, it must be associated with another entity set,
called the identifying or owner entity set. The weak entity set is said to be existence
dependent on the identifying entity set. The relationship associating the weak entity
set with the identifying entity set is called the identifying relationship.
ER Diagrams
Entity Sets
Entities can be represented graphically as follows:
• Rectangles represent entity sets.
• Attributes listed inside entity rectangle
• Underline indicates primary key attributes
Relationship Sets
Diamonds represent relationship sets.
Relationship Sets with Attributes
Notation to Express Entity with
Complex Attributes
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.
Entities associated through two distinct
relationships with role names
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 between an instructor and a student :
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
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,
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
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
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.
Structural Constraints
Multiplicity is made up of two types of restrictions on relationships: cardinality and
participation.

Cardinality
Describes maximum number of possible relationship occurrences for an entity
participating in a given relationship type.
Participation
Determines whether all or only some entity occurrences participate in a
relationship.
Multiplicity as cardinality and
participation constraints
Multiplicity of Staff Manages Branch (1:1) relationship
Multiplicity of Staff Oversees PropertyForRent (1:*)
relationship
Multiplicity of Newspaper Advertises PropertyForRent (*:*)
relationship
Important cardinalities
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

participation of student in advisor relation is total

every student must have an associated instructor
Partial participation: some entities may not participate in any relationship in the relationship set
Example: participation of instructor in advisor is partial
Expressing Weak Entity Sets
In E-R diagrams, a weak entity set is depicted via a double rectangle.
We underline the discriminator of a weak entity set with a dashed line.
The relationship set connecting the weak entity set to the identifying strong entity set
is depicted by a double diamond.
Primary key for section – (course_id, sec_id, semester, year)
E-R Diagram for a University
Enterprise
ER diagram of Branch user views of DreamHome
Practice Question 01
Draw an ERD containing Student and Paper entity types connected by a 1-M
relationship. The Student entity type should have attributes for StdNo (primary key),
StdFirstName, StdLastName, StdAdmitSemester, StdAdmitYear, and StdEnrollStatus
(full or part-time). The Paper entity type should have attributes for PaperNo (primary
key), PaperTitle, PaperSubmitDate, PaperAccepted (yes or no), and PaperType (first,
second, proposal, or dissertation). Add a 1-M relationship from Student to Paper.
Practice Question 02
A manufacturing company produces products.
 The following product information is stored: product name, product ID and quantity on hand.
 These products are made up of many components. Each component can be supplied by one or more
suppliers. The following component information is kept: component ID, name, description, suppliers
who supply them, and products in which they are used.
 Create an ERD to show how you would track this information.
 Show entity names, primary keys, attributes for each entity, relationships between the entities and
cardinality.
 ASSUMPTIONS
 A supplier can exist without providing components.
 A component does not have to be associated with a product. Not all components are used in products.
 A product cannot exist without components.
Summary of Symbols Used in E-R Notation
Symbols Used in E-R Notation (Cont.)
Suggested Reading
Chapter 12 of Database Systems: A Practical Approach to Design, Implementation,
and Management by Thomas Conolly 6th Edition
Chapter 7 of Database System Concepts by Abraham Silberschatz