This document provides an overview of key concepts in database and database management systems (DBMS). It defines what a database is, different data models, database languages like DDL and SQL, types of database users, and the core functions and structure of a DBMS like storage management, transaction management, and query optimization. It also discusses database applications, levels of abstraction in database design, and common database architectures.

1. Chapter 1: Introduction
Databases & Database Management Systems (DBMS)
Levels of Abstraction
Data Models
Database Languages
Types of Users
DBMS Function and Structure
Read Chapter 1, including the historical notes on pages 28 and 29.
1.1 ©Silberschatz, Korth and Sudarshan

2. What is a Database?
According to the book:
 Collection of interrelated data
 Set of programs to access the data
 A DBMS contains information about a particular enterprise
 DBMS provides an environment that is both convenient and efficient to use.
Another definition:
 A database is a collection of organized, interrelated data, typically relating to
a particular enterprise
 A Database Management System (DBMS) is a set of programs for managing
and accessing databases
1.2 ©Silberschatz, Korth and Sudarshan

3. Some Popular
Database Management Systems
Commercial “off-the-shelf” (COTS):
 Oracle
 IBM DB2 (IBM)
 SQL Server (Microsoft)
 Sybase
 Informix (IBM)
 Access (Microsoft)
 Cache (Intersystems – nonrelational)
Open Source:
 MySQL
 PostgreSQL
Note: This is not a course on any particular DBMS!
1.3 ©Silberschatz, Korth and Sudarshan

4. Some Database Applications
Databases touch all aspects of our lives:
 Banking – accounts, loans, customers
 Airlines - reservations, schedules
 Universities - registration, grades
 Sales - customers, products, purchases
 Manufacturing - production, inventory, orders, supply chain
 Human resources - employee records, salaries, tax deductions
Anywhere there is data, there could be a database.
Course context is an “enterprise” that has requirements for:
 Storage and management of 100’s of gigabytes or terabytes of data
 Support for 100’s or more of concurrent users and transactions
 Traditional supporting platform, e.g, Sun Enterprise server, 4GB RAM, 50TB
of disk space
1.4 ©Silberschatz, Korth and Sudarshan

5. Purpose of Database System
Prior to the availability of COTS DBMSs, database applications were built
on top of file systems – coded from the ground up.
 Sometimes this approach is still advocated.
Drawbacks of this approach:
 Data redundancy and inconsistency
 Multiple files and formats
 A new program is required to carry out each new task
 Integrity constraints (e.g. account balance > 0) become embedded
throughout program code
 Plus others…
1.5 ©Silberschatz, Korth and Sudarshan

6. Purpose of Database Systems (Cont.)
Database systems offer solutions for the above problems.
Database systems also support:
 Atomicity of updates
 Concurrent access by multiple users
 Data security, etc.
Recoding this functionality from scratch is not easy!
So when should we code from scratch, and when do we buy a DBMS??
1.6 ©Silberschatz, Korth and Sudarshan

7. Levels of Abstraction
Physical level: defines low-level details about how data item is stored on
disk.
Logical level: describes data stored in a database, and the relationships
among the data.
type customer = record
name : string;
street : string;
city : integer;
end;
View level: defines how information is presented to users. Views can
also hide details of data types, and information (e.g., salary) for security
purposes.
1.7 ©Silberschatz, Korth and Sudarshan

8. View of Data, Cont.
In general, the interfaces between the three levels should be defined so
that changes in some parts do not seriously influence others.
Carefully defining the interfaces helps enhance physical data
independence, which is the ability to modify the physical schema without
changing the logical or view levels.
1.8 ©Silberschatz, Korth and Sudarshan

9. Instances vs. Schemas
Similar to types and variables in programming languages
A database schema defines the structure or design of a database
 Analogous to type information of a variable in a program
 For example, a database might consists of information about a set of customers
and accounts and the relationship between them
More precisely:
 A logical schema defines a database design at the logical level
 A physical schema defines a database design at the physical level
An instance of a database is the combination of the database and its’
contents at one point in time
 Analogous to a variable and its’ value
1.9 ©Silberschatz, Korth and Sudarshan

10. What is a Data Model?
The phrase “data model” is used in a couple of different ways.
Frequently used (use #1) to refer to an overall approach or
philosophy for database design and development.
For those individuals, groups and corporations that subscribe to
a specific data model, that model permeates all aspects of
database design, development, implementation, etc.
Current data models:
 Relational model
 Entity-Relationship model
 Object-oriented model, Object-relational model
 Semi, and non-structured data models
Legacy models:
 Network
 Hierarchical
1.10 ©Silberschatz, Korth and Sudarshan

11. What is a Data Model, Cont?
During the early phases of database design and development, a
“data model” is frequently developed (use #2).
The purpose of developing the data model is to define:
 Data
 Relationships between data items
 Semantics of data items
 Constraints on data items
In other words, a data model defines the logical schema, i.e., the
logical level of design of a database.
A data model is typically conveyed as one or more diagrams.
The type of diagrams used depends on the overall approach or
philosophy (i.e., the data model, as defined in the first sense).
This early phase in database development is referred to as data
1.11 ©Silberschatz, Korth and Sudarshan

12. Entity-Relationship Model
Example of an entity-relationship diagram:
Widely used for database modeling.
An ER model is converted to tables in a relational database.
1.12 ©Silberschatz, Korth and Sudarshan

13. Relational Model
Attributes
Example of tabular data in the relational model:
customer-id customer-name customer-street customer-city account-number
192-83-7465 Johnson Alma Palo Alto A-101
019-28-3746 Smith North Rye A-215
192-83-7465 Johnson Alma Palo Alto A-201
321-12-3123 Jones Main Harrison A-217
019-28-3746 Smith North Rye A-201
From a data modeling perspective, which approach is preferable?
The ER model, or the relational model?
1.13 ©Silberschatz, Korth and Sudarshan

14. A Sample Relational Database
Regardless of the model, the end result is the same:
1.14 ©Silberschatz, Korth and Sudarshan

15. Data Definition Language (DDL)
DDL is used for defining a (physical) database schema (see page 129
for a more complete example):
create table account (
account-number char(10),
balance integer)
Given a DDL file, the DDL compiler generates a set of tables.
A description of those tables is stored in a data dictionary:
 Contains information from the database schema
 Frequently referred to as metadata (i.e., data about data)
Data storage and definition language (DSDL?):
 Language in which the storage structure and access methods used by the
database system are specified
 Usually an extension of the data definition language
1.15 ©Silberschatz, Korth and Sudarshan

16. Data Manipulation Language (DML)
DML is used for accessing and manipulating a database
 DML is also known as a query language
Two classes of DML:
 Procedural – user specifies how to get the required data
 Non-procedural – user specifies what data is required without specifying how
to get that data
SQL is the most widely used DML (query language):
 Usually referred to as a non-procedural query language
1.16 ©Silberschatz, Korth and Sudarshan

17. SQL Examples
Find the name of the customer with customer-id 192-83-7465:
select customer.customer-name
from customer
where customer.customer-id = ‘192-83-7465’
Find the balances of all accounts held by the customer with customer-id 192-
83-7465:
select account.balance
from depositor, account
where depositor.customer-id = ‘192-83-7465’ and
depositor.account-number = account.account-number
Databases are typically accessed by:
 Users through a command line interface
 Users through a query or software editing tool
 Application programs that (generally) access them through embedded SQL or an
application program interface (e.g. ODBC/JDBC)
1.17 ©Silberschatz, Korth and Sudarshan

18. Database Users
Users are differentiated by the way they interact with the system
Naïve users invoke application programs that have been written
previously, e.g. people accessing a database over the web, bank tellers,
clerical staff, ATM users
Application programmers interact with the system by making DML calls
through an API, e.g., ODBC or JDBC from within a computer program
Sophisticated users form requests in a database query language,
typically submitted at the command-line, e.g., a database administrator
Specialized users write specialized database applications that do not fit
into the traditional data processing framework, e.g., geo-spatial or CAD
specialists
1.18 ©Silberschatz, Korth and Sudarshan

19. Database Administrator (DBA)
The DBA coordinates all the activities of the database system; has a good
understanding of the enterprise’s information resources and needs.
DBA duties:
 Granting user authority to access the database
 Acting as liaison with users
 Installing and maintaining DBMS software
 Monitoring performance and performance tuning
 Backup and recovery
According to the book, the DBA is also responsible for:
 Logical and Physical schema definition and modification
 Access method definition
 Specifying integrity constraints
 Responding to changes in requirements
These latter tasks are typically performed by a software engineer specialized in
database design, or perhaps a systems engineer
1.19 ©Silberschatz, Korth and Sudarshan

20. Transaction Management
A transaction is a collection of operations that performs a single logical
function in a database application
The backup and recovery components of a DBMS ensure that the
database remains in a consistent (correct) state despite failures:
 system, power, network failures
 operating system crashes
 transaction failures.
The concurrency-control manager in a DBMS controls the interaction
among the concurrent transactions, to ensure the consistency of the
database.
1.20 ©Silberschatz, Korth and Sudarshan

21. Storage Management
The storage manager in a DBMS provides the interface between the
low-level data stored in the database and the application programs and
queries submitted to the system.
The storage manager is responsible to the following tasks:
 interaction with the file manager
 efficient storing, retrieving and updating of data
Note that the DBMS may or may not make use of the facilities of the
operating system’s file management facilities.
1.21 ©Silberschatz, Korth and Sudarshan

22. Overall System Structure
Query Optimizer
1.22 ©Silberschatz, Korth and Sudarshan

23. Application Architectures
Architectures:
 Mainframe – client programs and DBMS reside on one platform.
 Two Tier – client programs and DBMS reside on different platforms; clients
connect to DBMS via an API such as ODBC/JDBC.
 Three Tier – client programs, application server (or other “middleware”),
and DBMS; clients connect to DBMS indirectly through the application
server (also via an API). Typically used in web-based applications.
 N Tier – generalization of 2 and 3 tier architectures.
1.23 ©Silberschatz, Korth and Sudarshan