DBMS

Raghu Ramakrishnan, Johannes Gehrke

ISBN 0071230572

Chapter 01: Introduction to Database Systems

Note: all credits for contents goes to the original author.

Summarized by Wawan Setiawan (winanci@gmail.com)
 Data & Database
● Data is important, but today data is too much to handle.
● Data needs to be managed.
● Data is usually inside Database. ==> Database needs to
be managed too.
● A database: a collection of data, typically describing the
activities of one or more related organizations.
● Keywords: Entity & Relationship.
● For example, database for University data.
● Entity: Classrooms, Students, Courses
● Relationship: Students enroll in courses which are using
classrooms. Summarized by winanci@gmail.com 2
 Database & DBMS
● DBMS: software designed to assist in
maintaining and utilizing large collections of data.
● From now:
✔ Database = DB
✔ Database Management System = DBMS

Summarized by winanci@gmail.com 3
 Focus
● DB Design: Describing a real-world (e.g. university) in
terms of the data & the factors must be considered on
how to organize the stored data?
● Data Analysis: Answering user's questions about the
enterprise by querying data.
● Concurrency & Robustness: The number of users
allowed to to access data concurrently & data
protection in the event of system failures.
● Efficiency & Scalability: Storing large datasets and
data efficiency.

Summarized by winanci@gmail.com 4
 A Little Bit of History
● Let's skip this for now, OK? :D

Summarized by winanci@gmail.com 5
 File System (not DB)
E.g.: Company has 500GB data.
Using file system:
● no memory of 500GB
● no direct reference to file >4GB (32bits)
● complex program to get data from file
● concurrent access can cause inconsistent data
● data restoration won't be easy
● security: only using password. Not sufficient.
Summarized by winanci@gmail.com 6
 DB (not File system)
E.g.: Company has 500GB data.
Using DB, better in (because it's optimized for):
● Data independence (from application & storage)
● Efficient data access
● Data integrity & security
● Data administration
● Concurrent access & data recovery
● No complex program: reduced development
time Summarized by winanci@gmail.com 7
 Data in DBMS
● Data model: a collection of high-level data
description constructs that hide many low-level
storage details.
● Semantic data model: more abstract & high
level.
● ER model: a type of semantic data model.

Summarized by winanci@gmail.com 8
 Relational Model
● Relation: a set of records. (like a table)
● Schema: a description of data or a template.
● Schema for a relation specifies: name, name of
field/attribute/column, the type of field.
● Each row describes a student or a record.
● Integrity constraints (optional, but important): certain
conditions for a record/row. E.g.: sid must be unique.

Summarized by winanci@gmail.com 9
 Other Data Model
● Hierarchical model: IBM's IMS DBMS
● Network model: IDS and IDMS
● Object-oriented model: Objectstore & Versant
● Object-relational model: also used in some RDBMS.
● Last 2 models are gaining acceptance.
● The dominant model: relational model.

Summarized by winanci@gmail.com 10
 Level of Abstractions
● Three: Conceptual, physical & external schemas.
● Information about the conceptual, external, & physical
schemas is stored in system catalogs.
● Data definition language (DDL): to define external and
conceptual.
● Most DBMS provide SQL for physical, but not part of
SQL-92.

Summarized by winanci@gmail.com 11
 Conceptual Schema
● Also called: Logical schema
● Schema in slide 9 is conceptual one.
Students(sid: string, name: string, login: string, age: integer, gpa:
real)
Faculty(d: string, fname: string, sal: real)
Courses(cid: string, cname: string, credits: integer)
Rooms(rno: integer, address: string, capacity: integer)
Enrolled(sid: string, cid: string, grade: string)
Teaches(d: string, cid: string)
Meets In(cid: string, rno: integer, time: string)
Summarized by winanci@gmail.com 12
 Physical & External Schema
● Physical: Storage details.
● E.g.: store all tables in certain file.
● External: a view (similar to relation/table) of
combined relations/table.
● E.g.: Courseinfo(cid: string, fname: string,
enrollment: integer) ==> not exist in conceptual,
thus not stored, computed as needed. Usally
called View

Summarized by winanci@gmail.com 13
 Data Independence
● Application is using External schema.
● If Conceptual schema is changed, External schema
can be kept the same.
● E.g.: if Faculty is split into 2:
Faculty public(d: string, fname: string, oce: integer)
Faculty private(d: string, sal: real)
● Courseinfo not affected & application using it is not
affected. (Logical data independence)
● Physical data independence: physical schema can
be changed without affected application.
Summarized by winanci@gmail.com 14
 Queries
Queries = questions by application.
1. What is the name of the student with student id 123456?
2. What is the average salary of professors who teach the course
with cid CS564?
● To get the answer from DB: using query language
● Query language using relational calculus &
relational algebra (this later needs explanation!)
● Data manipulation language (DML): create, modify,
and query data. Query language is part of DML.

Summarized by winanci@gmail.com 15
 Transactions
● People book ticket on the same flight. Empty seats
info might change because concurrency.
● If system crash while user booking, booking made
should be stored, but if booking in progress but not
completed, it should not be stored.
● Transaction: any one execution of a user program in
a DBMS.
● Partial transaction is not allowed.
● A group of transaction: a series execution of
transactions
Summarized by winanci@gmail.com 16
 Concurrent Transactions
● Different transactions can be done on the same time,
BUT
● If one transaction relates to the other transactions,
one has to be completed ==> Locking
● E.g.: Empty seat info is locked, meaning if one user
update, the other cannot update.
● Two type locking: shared (usually read) & exclusive
(usually write)
● Note: locking is a TOUGH concept in DBMS

Summarized by winanci@gmail.com 17
Incomplete Transactions & System
Crash
● Refer back to slide 16
● Writing transaction flow: completed transaction =>
write to Log=> write from Log to DB
● Called: WAL (Write-Ahead Log)
● Writing from Log => DB, called Checkpoint.
● Recovery flow: recover from DB (fast) => recover
from Log (slow)
● Checkpoint is usually periodical to ensure data
recovery faster after crash.

Summarized by winanci@gmail.com 18
DBMS Architecture(1)

Summarized by winanci@gmail.com 19
 DBMS Architecture (2)
● DBMS accepts SQL commands, parsed, optimized,
evaluated & executed.
● Optimizer: uses information about how the data is
stored to produce an efficient execution plan for
evaluating the query.
● Execution plan: blueprint for evaluating a query &
usually represented as a tree of relational operators.
● Buffer manager: from disk to memory, for reading
● Disk space manager: allocate, deallocate, read, and
write pages
Summarized by winanci@gmail.com 20
 People Dealing with DBMS
● It's you!
● DB implementor: usually is a DBA too, who build DBMS
software
● End user: using DBMS
● DB application programmer: develop packages that
facilitate data access for end user
● DBA:
✔ Design of the conceptual and physical schemas
✔ Security and authorization
✔ Data availability and recovery
Summarized by winanci@gmail.com 21
✔ DB tuning
 Q&A
● Anyone?

Summarized by winanci@gmail.com 22