INTRODUCTION

TO
DATABASE
L E A R N B Y E X A M P L E S
HIGH LEVEL
DATABASE
Instructor
MODEL
: Nguyễn Trọng Tài,
MS Computer Science
 Objectives

 Understand concepts of:

I2DB: Design Theory for Relational Databases

 The database design process

 Conceptual, logical design

 Entity relationship diagram

 Database Design Process
I2DB: Design Theory for Relational Databases

Relational
Getting
High-Level Database Relational
User
Design Schema DBMS
Requirement
Design

ER diagram Relational Database Schema

Figure 4.1: The database modeling and implementation process
I2DB: Design Theory for Relational Databases

Database Design Process

 Database Design Process

 High-level design describes exactly the information

I2DB: Design Theory for Relational Databases

needs of the business

 Logical design is process of constructing a model of
information used in an enterprise based on a specific
data model, but independent of a particular DBMS or
other physical considerations
 Physical design is process translating the logical
description of the data into technical specifications for
storing and retrieving data
 Database Design Process

 Several options for high level design

I2DB: Design Theory for Relational Databases

 The first and oldest method is the Entity Relationship

Model
 A more recent trend is Unified Modeling Language
 4.1 The Entity Relationship
Model

 Represent the structure of data

I2DB: Design Theory for Relational Databases

 Not include the operations on data

 Principle components
 Entity(thực thể) sets

 Attributes

 Relationships(mối liên hệ)

 There are many notation to represent the

components. Chen notation is a first choice
Comparison of E-R Modeling
notations

8
 The Entity Relationship
Diagrams
I2DB: Design Theory for Relational Databases

name address

title year
Stars Stars-in

name Movies

Studios Owns length genre

address
Figure 4.2: An entity relationship diagram for the movie database
 Multiplicity of Binary E/R
Relationships
 A binary relationship can connect any member of one of its entity sets to any
I2DB: Design Theory for Relational Databases

number of members of the other entity set

 Suppose R is a relationship connecting entity sets E and F
• Each entity in E can be connected by R to at most one entity in F, and each entity in F can be
connected to many entities in E, then R is many-one from E to F
• Similarity, if an entity of F can be connected by R to at most one entity in E, then R is many-
one from F to E (equivalently, one-many from E to F)
• Show a many-one relationship by an arrow pointing to the one side
 If R is both many-one from E to F and many-one from F to E, then we say
that R is one-one
• Show a one-one relationship by an arrows entering both entity sets
 If R is neither many-one from E to F or from F to E , then we say R is many-
many
 Multiplicity of Binary E/R
Relationships

• Example: many-one, one-one and many-many

I2DB: Design Theory for Relational Databases

relationships(Bội Số)

Movies Owns Studios

Studios Runs Presidents

Stars Stars-in Movies

 Multi-way Relationships
I2DB: Design Theory for Relational Databases

Stars Contracts Movies

Studios
 Roles in Relationships

 Consider a relationship Sequel-of between the

I2DB: Design Theory for Relational Databases

entity set Movies and itself

Original

Movie
Sequel-of
s

Sequel
 Roles in Relationships

 Consider the Contracts relationship involves two

I2DB: Design Theory for Relational Databases

studios, a star, a movie

Stars Contracts Movies

Studio Producing
of star studio

Studios
 Attributes on Relationships

 Consider the contracts between a star and studio

I2DB: Design Theory for Relational Databases

for a movie. We wish to record the salary

associated with this contract. How can we do
that?
 Attributes on Relationships
I2DB: Design Theory for Relational Databases

name address title year

Salary

Stars Contracts Movies

length genre

Studios

name address
 Attributes on Relationships

Salary
I2DB: Design Theory for Relational Databases

name address Salaries title year

Stars Contracts Movies

length genre

Studios

name address
 Converting Multi-way
Relationships to Binary

 Consider the Contracts relationship involves two

I2DB: Design Theory for Relational Databases

studios, a star, a movie

Stars Contracts Movies

Studio Producing
of star studio

Studios
 Converting Multi-way
Relationships to Binary
 Consider the Contracts relationship involves two studios, a star, a movie
I2DB: Design Theory for Relational Databases

Stars Contracts Movies

Studio Producing
of star Studios studio

Stars Movies

Contrac Movie-of
Star-of
ts

Studio Producing
of star studio
Studios
 Subclasses in E/R Model

 Consider Cartoons and Murder Mysteries are the

I2DB: Design Theory for Relational Databases

special kinds of movies, with some special

properties
to Stars length title year genre

Voices Movies

isa isa weapon

Murder
Cartoons
Mysteries
 Summary 4.1

 Entity Sets
I2DB: Design Theory for Relational Databases

 Attributes
 Relationships
 E/R Diagrams
 Roles in Relationships
 Subclasses in the E/R Model
I2DB: Design Theory for Relational Databases

DESIGN PRINCIPLES
 Faithfulness

 The design should be faithful to the specifications

I2DB: Design Theory for Relational Databases

of the application
 Entity sets and their attributes should reflect
reality
 Faithfulness

 Consider the Movie database

I2DB: Design Theory for Relational Databases

 A relationship Stars-in between Stars and Movies

should be a many-many relationship

▪ Why?

 A relationship Teaches from Courses to Instructors

should be
▪ a many-one relationship? When? Why?

▪ a many-many relationship? When? Why?

 Avoiding Redundancy

 What is redundancy?
I2DB: Design Theory for Relational Databases

 Why we need avoid a redundancies?

 Avoiding Redundancy

 Consider a relationship Owns between movies

I2DB: Design Theory for Relational Databases

and studios
 Let studioName is an attribute of entity set
Movies
 Is it good?
name studioName

Studios Owns Movies

 Simplicity Counts

 Avoid introducing more elements into your design

I2DB: Design Theory for Relational Databases

than is absolutely necessary

 Make your design as simple as possible
 Simplicity Counts

 Consider creating entity set Holdings for the

I2DB: Design Theory for Relational Databases

ownership of single movie as below

Movies Represents Holdings Owns Studios

 Is it good?
 Simplicity Counts

 A better design without an unnecessary entity set

I2DB: Design Theory for Relational Databases

Movies Owns Studios

 Choosing the right relationships

 Entity sets can be connected in various ways by

I2DB: Design Theory for Relational Databases

relationships
 Do we use all possible relationships in our
model?
 Choosing the Right
Relationships
I2DB: Design Theory for Relational Databases

Salary
title year name addr

Movies Contracts Stars

 Do we need the relationships

length genre between Movies and Studios and
Movies and Stars directly?
Studios  What if a star can work on a movie
without there being a contract?

name addr
 Picking the Right Kind of
Element

 Do we use attributes or use entity set/relationship

I2DB: Design Theory for Relational Databases

combinations for a particular questions?

 In general, an attribute is simpler to implement
than either an entity set or a relationship
 Picking the Right Kind of
Element

 Consider the Movies database

I2DB: Design Theory for Relational Databases

 We use the name and address of studio as attributes of

movies, so we eliminate the Studios entity set

 Is it good?
 Picking the Right Kind of
Element

 An entity set should satisfy at least one of the

I2DB: Design Theory for Relational Databases

following conditions:
 It is more than the name of something; it has at least

one non-key attribute, or

 It is the many in a many-one or many-many relationship
 Summary 4.2

 Faithfulness
I2DB: Design Theory for Relational Databases

 Avoiding redundancy
 Simplicity counts
 Choosing the right relationship
 Picking the right kind of element
I2DB: Design Theory for Relational Databases

CONSTRAINTS IN E/R MODEL

 Keys in the E/R Model

 Two entities to agree on some, but not all, of the

I2DB: Design Theory for Relational Databases

key attributes
 Every entity set has key(s), one of them is
primary key
 Representing Keys in the E/R
Model
I2DB: Design Theory for Relational Databases

name address

title year
Stars Stars-in

name Movies

Studios Owns length genre

address
 Referential Integrity

 Consider a relationships between Movies,

I2DB: Design Theory for Relational Databases

Studios, and President

Movies Owns Studios Runs President

 We say
 Movies refers to Studios

 Studios refers to President

 President refers to Studios

 Referential Integrity

 A referential integrity constraints

I2DB: Design Theory for Relational Databases

 A value appearing in one context must also appear in

another
 Degree Constraints

 How we represented every movie has at least 10

I2DB: Design Theory for Relational Databases

stars?

name address title year

>=10
Stars Stars-in Movies

length genre
 Summary 4.3

 Keys in the E/R model

I2DB: Design Theory for Relational Databases

 Referential Integrity
 Degree Constraints
I2DB: Design Theory for Relational Databases

WEAK ENTITY SETS

 Weak Entity Sets

 Consider the relationship

I2DB: Design Theory for Relational Databases

number crewChief name address

Crews Unit-of Studios

Weak entity set Supporting entity set

 An entity set’s key to be composed of attributes, some

or all of which belong to another entity set. Such an

entity set is called a weak entity set.
 Requirements for Weak Entity
Sets

 R is a relationship from E to F
I2DB: Design Theory for Relational Databases

 R is called supporting relationship if

 R must be a binary, many-one relationship from E to F

 R must have referential integrity from E to F

 The attributes that F supplies for the key of E must be

key attributes of F
 Weak Entity Sets

 Example weak entity set

I2DB: Design Theory for Relational Databases

Contracts salary

Studio-of Movie-of
Star-of

Stars Studios Movies

genre
year
length
name addr title
name addr
I2DB: Design Theory for Relational Databases

FROM E/R TO RELATIONAL

 From E/R Diagrams to Relational
Design
 Entity set -> relation
I2DB: Design Theory for Relational Databases

 Attributes -> attributes

 Relationships -> relations whose attributes are only

 The keys of the connected entity sets

 Attributes of the relationship itself

 However, two rules above cover only common situations. There

are also several special situations that we need deal with
 Weak entity sets

 “ISA” relationships and subclasses

 Combination of two relations

 From Entity Sets to Relations
I2DB: Design Theory for Relational Databases

name address name address

Stars Studios

Stars(name,address) Studios(name,address)
 From E/R Relationships to
Relations
Stars-in(title,year,starName)
I2DB: Design Theory for Relational Databases

name address Owns(title,year,studioName)

Stars Stars-in title year

name Movies

Studios Owns length genre

address

 The relation for a given relationship R has attributes :

 For each entity set involved in relationship R, we take its key attributes as a part of the
schema of the relation for R
 If the relationship has own attributes, then these are also attributes of relation R
 If one entity set is involved several times in a relationship in different roles, then its key
attributes each appear as many times as there are roles
 From E/R Relationship to
Relations
I2DB: Design Theory for Relational Databases

Stars Contracts Movies

Studio Producing
of star studio

Studios

Contracts(starName, title,year, studioOfStar_name, producingStudio_name)

 Combining Relations
name address Movies(title,year,length,genre)
Owns(title,year,studioName)
I2DB: Design Theory for Relational Databases

Stars title year

Stars-in

Movie
name
s
Studio
s Owns length genre

Movies(title,year,length,genre,studioName)
address

 Suppose an entity set E and a many-one relationship R from E to F. We can

combine two relations E and R into one relation with a schema consisting of:
 All attributes of E,
 The key attributes of F,
 and all own attributes belonging to relationship R
 Handling Weak Entity Sets
numbe crewChief name address
r
I2DB: Design Theory for Relational Databases

Unit-
Crews of Studios

Studios(name,address)
Crews(number,crewChief,studioName)

 If W is a weak entity set, construct for W a relation whose schema consists of:
• All attributes of W

• All own attributes of supporting relationships for W

• For each supporting relationship for W, say a many-one relationship from W to entity
set E, all the key attributes of E
 Rename attributes, if necessary, to avoid name conflicts
 Do not construct a relation for any supporting relationship for W
I2DB: Design Theory for Relational Databases
SUBCLASS STRUCTURES TO
RELATIONS
 Converting Subclass Structures
to Relations

 How we convert this structure to relations?

I2DB: Design Theory for Relational Databases

to Stars length title year genre

Voices Movies

isa isa weapon

Murder
Cartoon
Mysteri
s
es
 Converting Subclass Structures
to Relations

 The principal conversion strategies

I2DB: Design Theory for Relational Databases

 Follow E/R viewpoint

▪ For each entity set E in the hierarchy, create a relation that includes the key
attributes from the root and any attributes belong to E

 Treat entities as object-oriented

▪ For each possible subtree that includes the root, create one relation, whose
schema includes all the attributes of all the entity sets in the subtree

 Use null values

▪ Create only one relation with all attributes of all entity sets in the hierarchy.
Each entity is represented by one tuple, and that tuple has a NULL value for
whatever attributes the entity does not have
 E/R Style Conversion
I2DB: Design Theory for Relational Databases

to Stars length title year genre

Voices Movies

isa isa weapon

Murder
Cartoons
Mysteries

Movies(title,year,length,genre)
MurderMysteries(title,year,weapon)
Cartoons(title,year)  remove
Voices(title,year,starName)
 An Object-Oriented Approach
I2DB: Design Theory for Relational Databases

to Stars length title year genre

Voices Movies

isa isa weapon

Murder
Cartoons
Mysteries

Movies(title,year,length,genre)
MoviesC(title,year,length,genre)
MoviesMM(title,year,length,genre,weapon)
MoviesCMM(title,year,length,genre,weapon)
 Using Null Values
I2DB: Design Theory for Relational Databases

to Stars length title year genre

Voices Movies

isa isa weapon

Murder
Cartoons
Mysteries

Movie(title,year,length,genre,weapon)
 Unified Modeling Language

 Introduction
I2DB: Design Theory for Relational Databases

 UML is designed to model software in an object-

oriented style, but has been adapted as a database

modeling language
 UML offers much the same capabilities as the E/R

model, with the exception of multi-way relationships,

only binary relationships in UML.
 UML vs. E/R Model
(self studying)

UML E/R Model

I2DB: Design Theory for Relational Databases

Class Entity Set

Association Binary relationship
Association class Attributes on a relationship
Subclass is-a hierarchy
Aggregation Many-one relationship
Composition Many-one relationship with
referential integrity

Figure 4.34: Comparison between UML and E/R terminology

 UML Classes
I2DB: Design Theory for Relational Databases

Movies Class’ name

title PK
State
year PK
length
genre

init()
Behavior modify()
 Associations

 Consider an associations between Movies, Stars,

I2DB: Design Theory for Relational Databases

and Studios in UML

Studios
0..1
name
PK Owns Movies
address 0..* title PK
year PK
Stars 0..* length
name 0..* Stars-in genre
PK
address
 Associations

 Comparison with E/R Multiplicities

I2DB: Design Theory for Relational Databases

E/R UML
0..* 0..*

0..* 0..1

0..* 1..1
 Self-Associations

 An association can have both ends at the same

I2DB: Design Theory for Relational Databases

class; such an association is called a self-

association
 Example
Movies 0..1 theOriginal
title PK
year PK
length
genre 0..* theSequel
 Association Classes
I2DB: Design Theory for Relational Databases

Movies
Stars 0..* Stars-in 0..* title PK
name year PK
PK
length
address
genre
Compensatio
n
salary
residuals
 Subclasses in UML

 Consider Movies and its three subclasses

I2DB: Design Theory for Relational Databases

Movies
title PK
year PK
length
genre

Murder Cartoons Cartoon-

Mysterie Murder
s Mysterie
s
weapon
weapon
Figure 4.40: Cartoons and murder mysteries as disjoint subclasses of movies
 Aggregations and Compositions

MovieExec
I2DB: Design Theory for Relational Databases

s
cert# PK
name
address
networth
Movies
title PK Studios Presiden
year PK 1..* name 0..1 ts
0..1 PK 1..1
length
address
genre

Figure 4.41: An aggregation from Movies to Studios and

a composition from Presidents to Studios
 UML-to-Relations Basics

 Classes to Relations
I2DB: Design Theory for Relational Databases

 For each class, create a relation

▪ name is the name of the class
▪ attributes are the attributes of the class

 Associations to Relations
 For each association, create a relation
▪ name is the name of that association
▪ attributes are the key attributes of the two connected classes
 UML-to-Relations Basics
I2DB: Design Theory for Relational Databases

Studios
0..1
name
PK Owns Movies
address 0..* title PK
year PK
Stars 0..* length
name 0..* Stars-in genre
PK
address
Movies(title,year,length,genre) Stars-In(movieTitle,movieYear,starName)
Stars(name,address) Owns(movieTitle,movieYear,studioName)
Studios(name,address)
 From UML Subclasses to
Relations

 We can use any of the three strategies outlined

I2DB: Design Theory for Relational Databases

for E/R to convert a class and its subclasses to

relations
 E/R-style: each subclass’ relation stores only its own

attributes, plus key

 OO-style: relations store attributes of subclass and all

super-classes
 Nulls: One relation, with NULL’s as needed
 From Aggregations and
Composition to Relation

 No relation for the aggregation or composition

I2DB: Design Theory for Relational Databases

 Add to the relation for the class at the non-

diamond end the key attribute(s) of the class at
the diamond end
 In the case of an aggregation, it is possible that these

attributes can be null

 From Aggregations and
Composition to Relation
MovieExec
I2DB: Design Theory for Relational Databases

s
cert# PK
name
address
networth
Movies
title PK Studios Presiden
year PK 1..* name 0..1 t
0..1 PK 1..1
length
genre address
MovieExecs(cert#,name,address,netWorth)
Presidents(cert#,studioName)
Movies(title,year,length,genre,studioName)
Studios(name,address)
 The UML Analog of Weak Entity
Sets

 We use the composition, which goes from the

I2DB: Design Theory for Relational Databases

weak class to the supporting class, for a weak

entity set
 Example:
Crews Studios
0..* 1..1
number PK name PK
PK address
crewChief
Studios(name,address)
Crews(number,crewChief,studioName)
 University DB

 The aim of this assignment is to develop a database system to

I2DB: Design Theory for Relational Databases

hold records for students and their training programs. The

system will be used for analyzing the students’s
performance during the training program as well as to select
students of the year based on the data entered into the system.
 Our university is organized into several departments which are
described by a name, department code, office number, office
phone, and a particular instructor who manages the department.
We keep track of the start date when that instructor began
managing the department.
 University DB

 University recruits more instructors and arranges them on each different

I2DB: Design Theory for Relational Databases

department based on their expertise. Instructors are known as the

identification number, name, birthdate, startdate, sex and qualifications.
For each qualification, they should provide information about specialized
training, training institue or university and year of graduation
 Scientific subjects are distributed on each department. Information on
subjects includes subject code, name, total credit, credits theory, practice
credits, and prerequisite subjects. Department assigns its courses for
instructors. Each instructor can teach multiple subjects from different
departments. We also keep information about when he/she started and/or
stoped teaching a particular subject.
 University DB

 Annual university enrollments 2000 students and arranges them in

I2DB: Design Theory for Relational Databases

many different classes and assigns for departments depending on

the coursework program that students sign up. Information about
the class is including class code, coursework program. Each class
has one academic supervisor from instructors of its managing
department.
 The information on students includes student’s name, student
number, social security name, current address and phone,
permanent address and phone, birth date, sex. Both social security
number and student number has unique values for each student.
 University DB

 The coursework program lasts for 4 years, with 8 semesters. The subjects are
I2DB: Design Theory for Relational Databases

arranged for classes by sections in each semester. Information on section includes

number of semester, training year, section number. The section number
distinguishes sections of the same class that are taught during the same
semester/year; its values are 1, 2, 3... up to the number of sections taught during
each semester for this class. Managing department assigns specific instructor for
each section depending on its subject.

 Student has grade report for each subject that he/she has joined. There are two
evaluation modes: grade theory and practicle grade in rating 50%-50%. One student
passes the course if grade theory is greater than 4.0 and total score is greater than
5.0. Otherwise, student must take part in a retake exam for grade theory. Finally,
he/she must rejoin the course in the next chances.