CS3402

Database Systems
Teaching Staff’s Information
 Lecturer: Dr. LIAO Jing (Week 1-8)
Email: [email protected]
Phone: 3442-8619
Office: G6413

 Lecturer: Dr. HUANG Heqing (Week 9,10,12,13)

Email: [email protected]
Phone: 3442-8504
Office: G6429
 Teaching Staff’s Information
 Tutorial Teaching:
 TA1/TC1: Mr. WANG Can [email protected]
 TA2/TC2 : Mr. DU Hao [email protected]
 TA3/TC3 : Mr. ZHANG Jingbo [email protected]
 TA4/TC4 : Mr. HUANG Zhitong [email protected]

 Other TAs:
---Homework and midterm grading
 Mr. WAN Ziyu [email protected]
 Ms. ZHANG Peiying [email protected]
 Mr. WU Ronghuan [email protected]
 Mr. ZHANG Zhiyuan [email protected]
Course Overview
 Course Format:
Lecture
Time: Monday 12:00pm - 2:50pm
Venue: YEUNG LT-2
Delivery mode: Face-to-Face

Tutorial
Time: Week 6-13 (2 Q&A and 6 Labs)
Venue: MMW 2450
Delivery mode: Face-to-Face
Assessment
 Coursework -- 40% :
Mid-term -- 25%
Date: Week 7, Mon （Mar. 4th）
Time: Lecture time
Format: Face-to-face, Open-book exam
Homework assignments (3 times) -- 15%
Lab attendance (At least 5 of the 6 labs) -- 3% bonus
(such that coursework is capped to 40%)

 Final examination (open-book)-- 60%

Get 30 out of 100 to pass
Course Materials
 Text books
“Fundamentals of Database Systems”, 6th
edition (or later), by R. Elmasri, S.B. Navathe,
Addison-Wesley.
“Database System Concepts”, 5th edition (or
later), by A. Silberschatz, H. Korth, S.
Sudarshan, McGraw-Hill Companies Inc.

 Notations may vary in different books. Please stick

to the ones used in this lecture notes!
Database is everywhere
 You cannot avoid it and it’s everywhere!
 You can say it actually makes the current society and
your life work!
 Banking/Credit card /Social Security Info…
 Online shopping/booking…
Motivating Example
Data: in Computer system, Data is any sort of
information which is stored in computer memory.

Student ID Student name Course Course Name Grade

50000000 Peter Wong CS3402 Database Systems B+
50000000 Peter Wong CS2302 Data Structures A
50000001 Mary Tsui CS3402 Database Systems A-
50000002 Bob Lee CS3402 Database Systems B

 This way of storing data good?

 How to improve?
Introduction to DB Systems
 Motivations
 File-processing Systems
permanent records stored in various files
application programs written to extract & add records
 Disadvantages of traditional file-processing systems
data redundancy & inconsistency
difficulty in accessing data
data isolation & different data formats
concurrent access anomalies
security problem
integrity problem
Introduction to DB Systems
 What is a Database (DB)?
 A non-redundant, persistent collection of logically-related data
that are structured to support various processing and retrieval
needs.

 Database Management System (DBMS)

 A set of software programs for creating, storing, updating, and
accessing the data of a DB.
 E.g.: Oracle, Mysql，Oceanbase
Database Management System

Database Systems: Design, Implementation, & Management: Rob & Coronel

- manages interaction between end users and database

16
Database Management System
 Difference between DBMS & other programming
systems
 the ability to manage persistent data
 primary goal of DBMS: to provide an environment that is
convenient, efficient, and robust to use in retrieving & storing
data
 Other DBMS capabilities
 data modeling
 high-level languages to define, access and manipulate data
 transaction management & concurrency control
 access control
 recovery
 Database System

 Hardware
 Software
- OS
- DBMS
- Applications

 People
 Procedures
 Data

 Database System
 an integrated system of hardware, software, people, procedures,
and data
 that define and regulate the collection, storage, management,
and use of data within a database environment 18
 DB System Architecture
Interactive Appl. Prog’er
Naïve user user DBA
Application Application
(SQL) query DB schema
interfaces programs

DQL DDL compiler

DML compiler
processor

Application Database
programs manager
object code DBMS

File manager

Data files DB
Data dict.
disk storage
 DB System Architecture
 Database Users
Naive Users:
Running application programs
Interactive Users:
Using query languages
Application Programmers
Writing embedded DML in a host language
 DB System Architecture
 Database Administrator (DBA)
DBA is the person who has central control over the DB
Main functions of DBA:
schema definition
storage structure and access method definition
schema and physical organization modification
granting of authorization for data access
integrity constraint specification
 DB System Architecture
 Data Query Language (DQL)
- a language used to make queries in databases
- e.g. search records with giving conditions
(sex=“Female”)
 Data Manipulation Language (DML)
- a language that enables users to manipulate data
- e.g. insert or delete records
 Data Definition Language (DDL)
- a language for defining DB schema
- e.g., create, modify, and remove database objects such
as tables, indexes, and users.
Data Abstraction: 3-level architecture
 Data Abstraction
 Data Abstraction
 Abstract view of the data
simplify interaction with the system
hide details of how data is stored and manipulated
 Levels of abstraction
Physical/internal level: internal schema uses a physical data
model and describes the complete details of data storage and
access paths for the database.
Conceptual level: conceptual schema describes the structure of
the whole database for a community of users and hides the details
of physical storage structures.
View/external level: external schema describes the part of the
database that a particular user group is interested in and hides the
rest from that group.
Data Independence
 the ability to modify a schema definition in one level without
affecting a schema in the next higher level
 there are two kinds (a result of the 3-level architecture):
physical data independence
-- the ability to modify the physical schema without
altering the conceptual schema and thus, without
causing the application programs to be rewritten
logical data independence
-- the ability to modify the conceptual schema without
causing the application programs to be rewritten
Data Abstraction: 3-level architecture
 Data Models
 Data Model (conceptual level)
 A collection of conceptual tools for describing data, data
relationships, operations, and consistency constraints
 the “core” of a database
The Entity-Relationship Model
 Preliminaries
Proposed by P. Chen in 1976
Direct, easy-to-understand graphical notation
Translates readily to relational schema for database
design
Ideas/requirem E/R Relational Relational
ents design schema database
 Three basic concepts:
Entity, Attribute, Relationship
ER Model Concepts
 Entity
 a distinguishable object with an independent
existence
Example: John Chan, CityU, HSBC, …
 Entity Set
a set of entities of the same type
Example: Student, University, Bank, ...
ER Model Concepts
 Attribute(Property) -- a piece of information describing
an entity
Example: Name, ID, Address, Sex are attributes
of a student entity

 Each attribute can take a value from a domain

Example: Name  Character String,
ID  Integer, ...
Types of Attributes
 Simple
 Each entity has a single atomic value for the attribute. For
example, SSN or Sex, name…
 Composite
 The attribute may be composed of several components. For
example:
Address(Flat, Block, Street, City, State, Country)
Composition may form a hierarchy where some components
are themselves composite
 Multi-valued
 An entity may have multiple values for that attribute. For
example, Color of a CAR or PreviousDegrees of a STUDENT
Denoted as {Color} or {PreviousDegrees}
E.g., {{BSc, 1990}, {MSc, 1993}, {PhD, 1998}}
Example of a composite attribute
Types of Attributes
 In general, composite and multi-valued attributes may be nested to
any number of levels

 For example, PreviousDegrees of a STUDENT is a composite

multi-valued attribute denoted by {PreviousDegrees (Degree,
Year)}

 Multiple PreviousDegrees values can exist

 Each has two subcomponent attributes:

Year, Degree
Key Attributes
Key: attribute to uniquely identify an entity in an entity set

Example:
studentID is a key of the STUDENT entity set: since there
are no two students having the same value on studentID.
HKID is another key of the STUDENT entity set: since there
are no two students having the same value on HKID.
Name is not a key of the STUDENT entity set: since two
students may have the same name.
ER Model Concepts
 Relationship -- an association among several entities
Example: Patrick and Eva are friends
Patrick is taking cs3450
 a relationship can carry attributes: properties of the relationship
 Example: Patrick takes cs3450 with a grade of B+

 Relationship Set -- a set of relationships of the same type (same

attribute，same participating entity type， same constraints）
Example: taking
John cs3450
mary cs2578
may ee4532
Constraints on relationship
Cardinality
COURSE LECTURER COURSE TA STUDENTS COURSE

One-to-
one(1:1)
One-to-many Many-to-
(1:N) many (M:N)

Participation: whether every entity in the entity set

participates in the relationship set: total v.s. partial
ER Model Diagram
 ER Diagram
 Rectangles: Entity Sets
 Oval: Attributes
 Diamonds: Relationship Sets
 Lines: Attributes to Entity/Relationship Sets
or, Entity Sets to Relationship Sets
m n
R
R
1 n
R

1 1
R
Example COMPANY Database
 We need to create a database schema (definition) based on the
following (simplified) application requirements of the COMPANY
Database:

 The company is organized into DEPARTMENTs

 Each DEPARTMENT has a unique name, unique number,
several locations, and an EMPLOYEE who manages the
DEPARTMENT
 We keep track of the start date of the department manager.
 Each DEPARTMENT may control a number of PROJECTs
 Each PROJECT has a unique name, unique number and is
located at a single location, and many EMPLOYEEs working on
it.
Example COMPANY Database
 The database will store each EMPLOYEE’s social security number
(ssn), name(first name, last name and middle init), address, salary,
sex, and birthdate
Each EMPLOYEE works for one DEPARTMENT but work on
several PROJECTs
The DB will keep track of the number of hours per week that an
employee currently works on each project
Each EMPLOYEE，except for the boss, is supervised by his/her
direct supervisor (another EMPLOYEE)

 Each EMPLOYEE may have a number of DEPENDENTs

For each dependent, the DB keeps a record of name, sex,
birthdate, and relationship to the employee
Initial Conceptual Design of Entity Sets
for the COMPANY Database Schema
 Based on the requirements, we can identify four initial entity sets in
the COMPANY database:
 DEPARTMENT
 PROJECT
 EMPLOYEE
 DEPENDENT

 The initial attributes shown are derived from the requirements

description:
Initial Design of Entity Sets:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT
Refining the initial design by introducing
relationships

 Find relationships relating two or more distinct entities/entity types

with a specific meaning

 By examining the requirements, six relationship types are identified:

 EMPLOYEE works on PROJECT
 EMPLOYEE works for DEPARTMENT
 EMPLOYEE manages DEPARTMENT
 EMPLOYEE supervises EMPLOYEE
 DEPENDENT depends on EMPLOYEE
 DEPARTMENT controls PROJECT
ER DIAGRAM – Relationship Types are:
WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION, DEPENDENTS_OF
Relationship instances of the WORKS_FOR N:1
relationship between EMPLOYEE and DEPARTMENT

N-to-1

Many
employees in
the same
department
Relationship instances of the M:N WORKS_ON
relationship between EMPLOYEE and PROJECT

M-to-n

Many employee
work on many
projects
 ER Model Diagram
 Weak Entity Set
 an entity set that does NOT have enough attributes to form a key

trans. no date amount

Acct. no balance

account log transaction

 Role Indicators

Emp. name Phone#

manager
employee Works-for
worker
ER Model Diagram
 Derived Attribute: An attribute which can be derived
from other attributes is known as derived attribute.
Summary of ER-Diagram Notation
Symbol Meaning

ENTITY TYPE

WEAK ENTITY TYPE

RELATIONSHIP TYPE

IDENTIFYING RELATIONSHIP TYPE

ATTRIBUTE

KEY ATTRIBUTE

MULTIVALUED ATTRIBUTE

COMPOSITE ATTRIBUTE

DERIVED ATTRIBUTE

E1 R E2 TOTAL PARTICIPATION OF E2 IN R
1 N
E1 R E2 CARDINALITY RATIO 1:N FOR E1:E2 IN R

(min,max) STRUCTURAL CONSTRAINT (min, max) ON

R E PARTICIPATION OF E IN R