CP 224: Database Management Systems

Instructors:
Ms. Gloriana Monko
Office No: A3, Administration Block Ground
Floor
Email:gmonko24@gmail.com
Mr. Diwani Salmin
Office No: Administration Block Ground Floor

1
 Course Description……..(9 Credits)
Course Aim
This course is about database management systems. It covers data
organization, query processing, transactions and advanced database
concepts.

Learning Outcomes
After successful completion of the course, students will be able to:

• Assess established and upcoming technologies in the field of

databases critically.
• Transform conceptual diagrams into logical database schemata
• Normalize and de-normalize logical database schemata and
implement logical database schemata in the industry-standard
SQL in order to define, manipulate and query data according to
best practice
• Declare complex database queries in relational calculus
 Learning Outcomes……..

• Exploit SQL to execute semantically sound database

queries and updates
• Apply relational algebra to optimize the evaluation of
database queries
• Adjust database designs to evolving requirements by
using suitable evaluation strategies and physical data
structures that help achieve good performance
• Understand transactions as a foundation for the
concurrent execution of database programs and the
recovery from system failures
 Learning Strategies
Acquisition
Peer to peer teaching and learning
Critical thinking

 Discussion
Revers brain storming

 Practice
Scenario analysis
Problem scenario

 Collaboration
Authentic group projects

 Production
Authentic group projects
 Mode of Assessment

Attendance 90% of lectures……………………............ 5 Marks

Assignment………………………………………………..5 Marks
Practical……………………………………………….......5 Marks
Project…................………………………………………10 Marks
Tests…………………………………………………........15 Marks
Sub Total…………………………………………………40 Marks
Final Exam……………………………………………......60 Marks
Sub Total…………………………………………………60 Marks

Cumulative CA + Final…………………………...........100 Marks

 Databases Are Everywhere
• Data- Facts that can be recorded
• Information- Meaningful/processed data
• Database = a large (?) collection of related data
• Classically, a DB models a real-world organisation
(e.g., enterprise, university)
– Entities (e.g., students, courses)
– Relationships (e.g., “Martin is taking IDS in 2010/11”)
• Changes in the organisation = changes in the database
• Examples:
– personnel records
– banking 6

– airline reservations
 Scientific Databases (Examples)
• Biology:
e.g., DNA sequences of genes, amino-acid sequences
of proteins, genes expressed in tissues
(up to several Gigabytes)
• Astronomy:
e.g., location and spectra of astronomic objects
(up to several
Terabytes)
• Physics:
e.g., sensor measurements in particle physics
experiments
(up to several
Petabytes) 7
 DB Tendencies
• Sensors record data
€ DBs grow in size
€ DBs become more widespread
€ date may be less reliable, i.e., uncertain
• Multimedia data
€ Requirements for larger storage
€ New query operations
(e.g., find a song by humming the melody,
find pictures with a given face)
• Data on the Web
€ Accessed/changed by many people (Facebook,
…)
€ Speed up access, loosen consistency (NoSQL) 8
 Operations with Databases
• Design
– Define structure and types of data
• Construction
– Create data structures of DB, populate DB with data
• Manipulation of Data
– Insert, delete, update
– Query: “Which department pays the highest salary?”
– Create reports:
“List monthly salaries of employees, organised
by department, with average salary and total
sum of salaries for each dept”

9
 An Ideal DB Implementation
Should Support:
• Structure • Performance
– data types – retrieve and store data
– data behaviour quickly
• Persistence • Data Integrity
– store data on • Sharing
secondary storage – concurrency
• Retrieval • Reliability and resilience
– a declarative query • Large data volumes
language
– a procedural database
programming language
1
0
Database Management System (DBMS)
• A DBMS is a software package designed
to store and manage databases
• A DBMS provides generic functionality (see
previous slide) that otherwise would have to be
implemented over and over again
€ Reduced application development time
• Several brands, e.g.,
– Oracle Xi/Yg (Oracle), DB2 (IBM), SQL Server, Access
(Microsoft), MySQL, PostgreSQL, HSQLDB, SQLite
(open source)

1
1
 Database Actors

Database Application
“on the scenes”
Designers Programmers

Database End Users

Administrator • sophisticated
• casual
(DBA) • ‘parametric’ or
‘canned’ transactions

Database

DBMS developers Operators and Maintenance

Tool Developers
Personnel “behind the scenes”

Database Management System 8

File System: A Physical Interface

Student Year
Student Admin Lists
Data

Course Timetable
Scheduler
Data

Lecturer Money
Data Payroll
Transfer

13
Sharing Data: Replication € Redundancy

Student
Admin

Lab Student Data

Timetable
Course Data
Tutorials
Lecturer
Data
Scheduler

Teaching

Schedule
Payroll

14
Sharing Data and Operations

Student Admin
Student Data

Lab Timetable

Course Tutorials
Data
Scheduler

Teaching
Lecturer
Data
Schedule
Payroll

15
 DBMS: A Logical Interface

University Database Lab

Data Timetable

Database
course Management Teaching
student System
Schedule
lecturer

Tutorials
Data Dictionary
or
System
Catalog
University
?QUERIES
Database
Metadata

16
 File System Approach

• Uncontrolled redundancy
• Inconsistent data
• Inflexibility
• Limited data sharing
• Poor enforcement of standards
• Low programmer productivity
• Excessive program maintenance
• Excessive data maintenance

17
 DBMS Approach
• Controlled redundancy • Services & controls
– consistency of data & – security & privacy
integrity constraints controls
• Integration of data – backup &
– self-contained recovery
– represents semantics – enforcement of
of application standards
• Data and operation • Flexibility
sharing – data
– multiple independence
interfaces – data
accessibility
18
– reduced program
development
maintenance
 Database Architecture

Database applications are usually partitioned into two or three

parts.
In a two-tier architecture, the application resides at the client machine, where it
invokes database system functionality at the server machine through query language
statements
Application program interface standards like ODBC and JDBC are used for interaction
between the client and the server.

In contrast, in a three-tier architecture, the client machine acts

as merely a front end and does not contain any direct database
calls.
Instead, the client end communicates with an application server, usually through a
forms interface. The application server in turn communicates with a database
system to access data.
The business logic of the application, which says what actions to carry out
under what conditions, is embedded in the application server, instead of being
distributed across multiple clients.
Three-tier applications are more appropriate for large applications, and for
applications that run on the WorldWideWeb.
Database Architecture
 Data Warehousing, Data Mining and Information
Retrieval
The term data mining refers loosely to the process of semi
automatically analyzing large databases to find useful patterns.

Like knowledge discovery in artificial intelligence (also called

machine learning) or statistical analysis, data mining
attempts to discover rules and patterns from data. However, data
mining differs from machine learning and statistics in that it deals
with large volumes of data, stored primarily on disk.
That is, data mining deals with “knowledge discovery in
databases.”

Large companies have diverse sources of data that they need to

use for making business decisions.
However.... Summary:

If an application is • In a file system, data is

• simple physically accessed and
• stringent real-time not integrated
• single user
• static, • In a DBMS, data is
logically accessed and
files are the option of choice integrated:
– query language
DBMS downside: – data dictionary
• more expensive
• more complex
• general 15