Database Management System (DBMS)

Chapter 1: Introduction

DBMS contains information about a particular enterprise

Purpose of Database Systems

Collection of interrelated data

View of Data

Set of programs to access the data

Database Languages

An environment that is both convenient and efficient to use

Database Applications:

Relational Databases
Database Design

Banking: all transactions

Object-based and semi-structured databases

Airlines: reservations, schedules

Data Storage and Querying

Universities: registration, grades

Transaction Management

Sales: customers, products, purchases

Database Architecture

Online retailers: order tracking, customized recommendations

Database Users and Administrators

Manufacturing: production, inventory, orders, supply chain

Overall Structure

Human resources: employee records, salaries, tax deductions

Databases touch all aspects of our lives

History of Database Systems

1

Purpose of Database Systems

Purpose of Database Systems

In the early days, database applications were built directly on top of

file systems

Data redundancy and inconsistency

Difficulty in accessing data

Multiple

Need

may leave database in an inconsistent state with partial

updates carried out
Transfer of funds from one account to another should
either complete or not happen at all

to write a new program to carry out each new task

Data isolation multiple files and formats

Integrity problems
Integrity
Hard

Example:

file formats, duplication of information in different files

Atomicity of updates
Failures

Drawbacks of using file systems to store data:

Concurrent access by multiple users

Concurrent

accessed needed for performance

Uncontrolled

concurrent accesses can lead to inconsistencies

Example: Two people reading a balance and updating it at the

same time

constraints

to add new constraints or change existing ones

Security problems
Hard

to provide user access to some, but not all, data

Database systems offer solutions to all the above problems

View of Data
Levels of Abstraction
An architecture for a database system
Physical level: describes how a record (e.g., customer) is stored.
Logical level: describes data stored in database, and the relationships

among the data.

View level: application programs hide details of data types. Views can

also hide information (such as an employees salary) for security

purposes.

Data Models

Instances and Schemas

Similar to types and variables in programming languages

Schema the logical structure of the database

Data
Data relationships
Data semantics
Data constraints

Example: The database consists of information about a set of customers and

accounts and the relationship between them

Analogous to type information of a variable in a program

Physical schema: database design at the physical level

Relational model

Logical schema: database design at the logical level

Entity-Relationship data model (mainly for database design)

Object-based data models (Object-oriented and Object-relational)

Instance the actual content of the database at a particular point in time

A collection of tools for describing

Semi-structured data model

Analogous to the value of a variable

Physical Data Independence the ability to modify the physical schema without
changing the logical schema

Applications depend on the logical schema

In general, the interfaces between the various levels and components should
be well defined so that changes in some parts do not seriously influence others.

Other older models:

Network model
Hierarchical model

Data Manipulation Language (DML)

Data Definition Language (DDL)

Specification notation for defining the database schema

Language for accessing and manipulating the data organized by the

appropriate data model

Example:

create table account (

account-number char(10),
balance
integer)
DDL compiler generates a set of tables stored in a data dictionary

DML also known as query language

Two classes of languages

Procedural user specifies what data is required and how to get

those data

Declarative (nonprocedural) user specifies what data is

required without specifying how to get those data

Data dictionary contains metadata (i.e., data about data)

Database schema

Data storage and definition language

Integrity constraints

Specifies

SQL is the most widely used query language

Domain

the storage structure and access methods used

constraints

Referential

integrity (references constraint in SQL)

Assertions

Authorization

Relational Model

10

A Sample Relational Database

Attributes

Example of tabular data in the relational model

11

12

SQL

Database Design
The process of designing the general structure of the database:

SQL: widely used non-procedural language

Example:
select
from
where

Find the name of the customer with customer-id 192-83-7465

customer.customer_name
customer
customer.customer_id = 192-83-7465

Example: 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

Logical Design Deciding on the database schema. Database design

requires that we find a good collection of relation schemas.

Business decision What attributes should we record in the

database?

Computer Science decision What relation schemas should we

have and how should the attributes be distributed among the various
relation schemas?

Physical Design Deciding on the physical layout of the database

13

14

The EntityEntity-Relationship Model

Storage Management

Models an enterprise as a collection of entities and relationships

Entity: a thing or object in the enterprise that is distinguishable

from other objects

Relationship: an association among several entities

Described

Storage manager is a program module that 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:

by a set of attributes

Represented diagrammatically by an entity-relationship diagram:

Interaction with the file manager

Efficient storing, retrieving and updating of data

Issues:

15

Storage access

File organization

Indexing and hashing

16

Query Processing

Query Processing

Alternative ways of evaluating a given query

1. Parsing and translation

2. Optimization

Equivalent expressions

3. Evaluation

Different algorithms for each operation

Cost difference between a good and a bad way of evaluating a query can

be enormous
Need to estimate the cost of operations

Depends critically on statistical information about relations which the

database must maintain

Need to estimate statistics for intermediate results to compute cost of

complex expressions

17

18

Transaction Management

Database Users

A transaction is a collection of operations that performs a single

Users are differentiated by the way they expect to interact with

logical function in a database application

the system

Transaction-management component ensures that the database

Application programmers interact with system through DML calls

remains in a consistent (correct) state despite system failures (e.g.,

power failures and operating system crashes) and transaction failures.

Sophisticated users form requests in a database query language

Specialized users write specialized database applications that do

Concurrency-control manager controls the interaction among the

not fit into the traditional data processing framework

concurrent transactions, to ensure the consistency of the database.

Nave users invoke one of the permanent application programs that

have been written previously

19

Examples, people accessing database over the web, bank tellers,

clerical staff

20

Database Administrator

Overall System Structure

Coordinates all the activities of the database system; the

database administrator has a good understanding of the

enterprises information resources and needs.
Database administrator's duties include:

Schema definition

Storage structure and access method definition

Schema and physical organization modification

Granting user authority to access the database

Specifying integrity constraints

Acting as liaison with users

Monitoring performance and responding to changes in

requirements

21

22

History of Database Systems

History

1950s and early 1960s:

Tapes

1980s:

Data processing using magnetic tapes for storage

Research relational prototypes evolve into commercial systems

Parallel and distributed database systems

Object-oriented database systems

provide only sequential access

SQL

Punched cards for input

Late 1960s and 1970s:

becomes industrial standard

1990s:

Hard disks allow direct access to data

Network and hierarchical data models in widespread use

Large decision support and data-mining applications

Ted Codd defines the relational data model

Large multi-terabyte data warehouses

High-performance transaction processing

Emergence of Web commerce

2000s:

23

XML and XQuery standards

Automated database administration

24