Database Systems Database Applications Examples

 DBMS contains information about a particular enterprise  Enterprise Information

• Collection of interrelated data • Sales: customers, products, purchases
• Set of programs to access the data • Accounting: payments, receipts, assets
• An environment that is both convenient and efficient to use • Human Resources: Information about employees, salaries, payroll
taxes.
 Database systems are used to manage collections of data that are:
• Highly valuable  Manufacturing: management of production, inventory, orders, supply
chain.
• Relatively large
 Banking and finance
• Accessed by multiple users and applications, often at the same
time.
• customer information, accounts, loans, and banking transactions.
 A modern database system is a complex software system whose task
• Credit card transactions
is to manage a large, complex collection of data. • Finance: sales and purchases of financial instruments (e.g., stocks
and bonds; storing real-time market data
 Databases touch all aspects of our lives
 Universities: registration, grades

Database System Concepts - 7th Edition 1.1 ©Silberschatz, Korth and Sudarshan Database System Concepts - 7th Edition 1.2 ©Silberschatz, Korth and Sudarshan

Database Applications Examples (Cont.) Purpose of Database Systems

 Airlines: reservations, schedules In the early days, database applications were built directly on top of file
 Telecommunication: records of calls, texts, and data usage, generating systems, which leads to:
monthly bills, maintaining balances on prepaid calling cards
 Data redundancy and inconsistency: data is stored in multiple file
 Web-based services formats resulting induplication of information in different files
• Online retailers: order tracking, customized recommendations  Difficulty in accessing data
• Online advertisements • Need to write a new program to carry out each new task
 Document databases  Data isolation
 Navigation systems: For maintaining the locations of varies places of • Multiple files and formats
interest along with the exact routes of roads, train systems, buses, etc.
 Integrity problems
• Integrity constraints (e.g., account balance > 0) become “buried”
in program code rather than being stated explicitly
• Hard to add new constraints or change existing ones

Database System Concepts - 7th Edition 1.3 ©Silberschatz, Korth and Sudarshan Database System Concepts - 7th Edition 1.4 ©Silberschatz, Korth and Sudarshan

Purpose of Database Systems (Cont.) University Database Example

 Atomicity of updates  In this text we will be using a university database to illustrate all the
concepts
• Failures may leave database in an inconsistent state with partial
updates carried out  Data consists of information about:
• Example: Transfer of funds from one account to another should either • Students
complete or not happen at all • Instructors
 Concurrent access by multiple users • Classes
• Concurrent access needed for performance  Application program examples:
• Uncontrolled concurrent accesses can lead to inconsistencies • Add new students, instructors, and courses
 Ex: Two people reading a balance (say 100) and updating it by • Register students for courses, and generate class rosters
withdrawing money (say 50 each) at the same time
• Assign grades to students, compute grade point averages (GPA) and
 Security problems generate transcripts
• Hard to provide user access to some, but not all, data

Database systems offer solutions to all the above problems

Database System Concepts - 7th Edition 1.5 ©Silberschatz, Korth and Sudarshan Database System Concepts - 7th Edition 1.6 ©Silberschatz, Korth and Sudarshan

1
 View of Data Data Models
 A database system is a collection of interrelated data and a set of  A collection of tools for describing
programs that allow users to access and modify these data. • Data
 A major purpose of a database system is to provide users with an abstract • Data relationships
view of the data. • Data semantics
• Data models • Data constraints
 A collection of conceptual tools for describing data, data  Relational model
relationships, data semantics, and consistency constraints.  Entity-Relationship data model (mainly for database design)
• Data abstraction  Object-based data models (Object-oriented and Object-relational)
 Hide the complexity of data structures to represent data in the
 Semi-structured data model (XML)
database from users through several levels of data abstraction.
 Other older models:
• Network model
• Hierarchical model

Database System Concepts - 7th Edition 1.7 ©Silberschatz, Korth and Sudarshan Database System Concepts - 7th Edition 1.8 ©Silberschatz, Korth and Sudarshan

Relational Model A Sample Relational Database

 All the data is stored in various tables.

 Example of tabular data in the relational model

Columns

Rows

Ted Codd
Turing Award 1981

Database System Concepts - 7th Edition 1.9 ©Silberschatz, Korth and Sudarshan Database System Concepts - 7th Edition 1.10 ©Silberschatz, Korth and Sudarshan

Levels of Abstraction View of Data

 Physical level: describes how a record (e.g., instructor) is stored. An architecture for a database system
 Logical level: describes data stored in database, and the relationships
among the data.
type instructor = record
ID : string;
name : string;
dept_name : string;
salary : integer;
end;
 View level: application programs hide details of data types. Views can
also hide information (such as an employee’s salary) for security
purposes.

Database System Concepts - 7th Edition 1.11 ©Silberschatz, Korth and Sudarshan Database System Concepts - 7th Edition 1.12 ©Silberschatz, Korth and Sudarshan

2
 Instances and Schemas Physical Data Independence

 Similar to types and variables in programming languages  Physical Data Independence – the ability to modify the physical
schema without changing the logical schema
 Logical Schema – the overall logical structure of the database
• Applications depend on the logical schema
• Example: The database consists of information about a set of
customers and accounts in a bank and the relationship between them • In general, the interfaces between the various levels and
components should be well defined so that changes in some parts
 Analogous to type information of a variable in a program
do not seriously influence others.
 Physical schema – the overall physical structure of the database
 Instance – the actual content of the database at a particular point in time
• Analogous to the value of a variable

Database System Concepts - 7th Edition 1.13 ©Silberschatz, Korth and Sudarshan Database System Concepts - 7th Edition 1.14 ©Silberschatz, Korth and Sudarshan

Data Definition Language (DDL) Data Manipulation Language (DML)

 Specification notation for defining the database schema  Language for accessing and updating the data organized by the
Example: create table instructor ( appropriate data model
ID char(5), • DML also known as query language
name varchar(20),  There are basically two types of data-manipulation language
dept_name varchar(20),
salary numeric(8,2)) • Procedural DML -- require a user to specify what data are needed
and how to get those data.
 DDL compiler generates a set of table templates stored in a data
dictionary • Declarative DML -- require a user to specify what data are needed
without specifying how to get those data.
 Data dictionary contains metadata (i.e., data about data)
 Declarative DMLs are usually easier to learn and use than are procedural
• Database schema DMLs.
• Integrity constraints  Declarative DMLs are also referred to as non-procedural DMLs
 Primary key (ID uniquely identifies instructors)  The portion of a DML that involves information retrieval is called a query
• Authorization language.
 Who can access what

Database System Concepts - 7th Edition 1.15 ©Silberschatz, Korth and Sudarshan Database System Concepts - 7th Edition 1.16 ©Silberschatz, Korth and Sudarshan

SQL Query Language Database Access from Application Program

 SQL query language is nonprocedural. A query takes as input several  Non-procedural query languages such as SQL are not as powerful as a
tables (possibly only one) and always returns a single table. universal Turing machine.
 Example to find all instructors in Comp. Sci. dept  SQL does not support actions such as input from users, output to
select name displays, or communication over the network.
from instructor  Such computations and actions must be written in a host language, such
where dept_name = 'Comp. Sci.' as C/C++, Java or Python, with embedded SQL queries that access the
 SQL is NOT a Turing machine equivalent language data in the database.
 To be able to compute complex functions SQL is usually embedded in  Application programs -- are programs that are used to interact with the
some higher-level language database in this fashion.
 Application programs generally access databases through one of
• Language extensions to allow embedded SQL
• Application program interface (e.g., ODBC/JDBC) which allow SQL
queries to be sent to a database

Database System Concepts - 7th Edition 1.17 ©Silberschatz, Korth and Sudarshan Database System Concepts - 7th Edition 1.18 ©Silberschatz, Korth and Sudarshan

3
 Database Design Database Engine

The process of designing the general structure of the database:  A database system is partitioned into modules that deal with each of the
responsibilities of the overall system.
 Logical Design – Deciding on the database schema. Database design
requires that we find a “good” collection of relation schemas.  The functional components of a database system can be divided into
• Business decision – What attributes should we record in the • The storage manager,
database? • The query processor component,
• Computer Science decision – What relation schemas should we • The transaction management component.
have and how should the attributes be distributed among the
various relation schemas?
 Physical Design – Deciding on the physical layout of the database

Database System Concepts - 7th Edition 1.19 ©Silberschatz, Korth and Sudarshan Database System Concepts - 7th Edition 1.20 ©Silberschatz, Korth and Sudarshan

Storage Manager Storage Manager (Cont.)

 A program module that provides the interface between the low-level data  The storage manager implements several data structures as part of the
stored in the database and the application programs and queries physical system implementation:
submitted to the system.
• Data files -- store the database itself
 The storage manager is responsible to the following tasks:
• Data dictionary -- stores metadata about the structure of the
• Interaction with the OS file manager database, in particular the schema of the database.
• Efficient storing, retrieving and updating of data • Indices -- can provide fast access to data items. A database index
 The storage manager components include: provides pointers to those data items that hold a particular value.
• Authorization and integrity manager
• Transaction manager
• File manager
• Buffer manager

Database System Concepts - 7th Edition 1.21 ©Silberschatz, Korth and Sudarshan Database System Concepts - 7th Edition 1.22 ©Silberschatz, Korth and Sudarshan

Query Processor Query Processing

 The query processor components include: 1. Parsing and translation

• DDL interpreter -- interprets DDL statements and records the 2. Optimization
definitions in the data dictionary. 3. Evaluation
• DML compiler -- translates DML statements in a query language into
an evaluation plan consisting of low-level instructions that the query
evaluation engine understands.
 The DML compiler performs query optimization; that is, it picks
the lowest cost evaluation plan from among the various
alternatives.
• Query evaluation engine -- executes low-level instructions generated
by the DML compiler.

Database System Concepts - 7th Edition 1.23 ©Silberschatz, Korth and Sudarshan Database System Concepts - 7th Edition 1.24 ©Silberschatz, Korth and Sudarshan

4
 Transaction Management Database Architecture

 A transaction is a collection of operations that performs a single logical  Centralized databases

function in a database application • One to a few cores, shared memory
 Transaction-management component ensures that the database  Client-server,
remains in a consistent (correct) state despite system failures (e.g.,
power failures and operating system crashes) and transaction failures. • One server machine executes work on behalf of multiple client
machines.
 Concurrency-control manager controls the interaction among the
concurrent transactions, to ensure the consistency of the database.  Parallel databases
• Many core shared memory
• Shared disk
• Shared nothing
 Distributed databases
• Geographical distribution
• Schema/data heterogeneity

Database System Concepts - 7th Edition 1.25 ©Silberschatz, Korth and Sudarshan Database System Concepts - 7th Edition 1.26 ©Silberschatz, Korth and Sudarshan

Database Architecture
(Centralized/Shared-Memory) Database Applications

Database applications are usually partitioned into two or three parts

 Two-tier architecture -- the application resides at the client machine,
where it invokes database system functionality at the server machine
 Three-tier architecture -- the client machine acts as a front end and
does not contain any direct database calls.
• 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.

Database System Concepts - 7th Edition 1.27 ©Silberschatz, Korth and Sudarshan Database System Concepts - 7th Edition 1.28 ©Silberschatz, Korth and Sudarshan

Two-tier and three-tier architectures Database Users

Database System Concepts - 7th Edition 1.29 ©Silberschatz, Korth and Sudarshan Database System Concepts - 7th Edition 1.30 ©Silberschatz, Korth and Sudarshan

5
 Database Administrator History of Database Systems

A person who has central control over the system is called a database  1950s and early 1960s:
administrator (DBA). Functions of a DBA include: • Data processing using magnetic tapes for storage
 Schema definition  Tapes provided only sequential access
 Storage structure and access-method definition • Punched cards for input
 Schema and physical-organization modification  Late 1960s and 1970s:
 Granting of authorization for data access • Hard disks allowed direct access to data
 Routine maintenance • Network and hierarchical data models in widespread use
 Periodically backing up the database • Ted Codd defines the relational data model
 Ensuring that enough free disk space is available for normal  Would win the ACM Turing Award for this work
operations, and upgrading disk space as required  IBM Research begins System R prototype
 Monitoring jobs running on the database  UC Berkeley (Michael Stonebraker) begins Ingres prototype
 Oracle releases first commercial relational database
• High-performance (for the era) transaction processing

Database System Concepts - 7th Edition 1.31 ©Silberschatz, Korth and Sudarshan Database System Concepts - 7th Edition 1.32 ©Silberschatz, Korth and Sudarshan

History of Database Systems (Cont.) History of Database Systems (Cont.)

 1980s:  2000s
• Research relational prototypes evolve into commercial systems • Big data storage systems
 SQL becomes industrial standard  Google BigTable, Yahoo PNuts, Amazon,
• Parallel and distributed database systems  “NoSQL” systems.
 Wisconsin, IBM, Teradata • Big data analysis: beyond SQL
• Object-oriented database systems  Map reduce and friends
 1990s:  2010s
• Large decision support and data-mining applications • SQL reloaded
• Large multi-terabyte data warehouses  SQL front end to Map Reduce systems
• Emergence of Web commerce  Massively parallel database systems
 Multi-core main-memory databases

Database System Concepts - 7th Edition 1.33 ©Silberschatz, Korth and Sudarshan Database System Concepts - 7th Edition 1.34 ©Silberschatz, Korth and Sudarshan