Chapter 1: Introduction

Chapter 1: Introduction
Purpose of Database Systems

Database Languages

Relational Databases
Database Design

Data Models

Database Internals

Database Users and dministrators

!"erall Structure

#istory of Database Systems

Database Management
System $D%MS&
D%MS contains information about a particular enterprise
Collection of interrelated data
Set of programs to access the data
n en"ironment that is both convenient and efcient to use
Database pplications:
%an'ing: all transactions
irlines: reser"ations( schedules
Uni"ersities: registration( grades
Sales: customers( products( purchases
!nline retailers: order trac'ing( customi)ed recommendations
Manufacturing: production( in"entory( orders( supply chain
#uman resources: employee records( salaries( ta* deductions
Databases touch all aspects of our li"es
Purpose of Database Systems
In the early days( database applications +ere built directly on
top of ,le systems

Dra+bac's of using ,le systems to store data:

Data redundancy and inconsistency

Multiple ,le formats( duplication of information in

di-erent ,les
Di.culty in accessing data

/eed to +rite a ne+ program to carry out each ne+ tas'

Data isolation 0 multiple ,les and formats

Integrity problems
Integrity constraints $e1g1 account balance 2 3& become
4buried5 in program code rather than being stated
e*plicitly

#ard to add ne+ constraints or change e*isting ones

Purpose of Database Systems
$Cont1&

Dra+bac's of using ,le systems $cont1&

tomicity of updates

6ailures may lea"e database in an inconsistent state +ith

partial updates carried out

7*ample: 8ransfer of funds from one account to another

should either complete or not happen at all

Concurrent access by multiple users

Concurrent accessed needed for performance

Uncontrolled concurrent accesses can lead to inconsistencies

7*ample: 8+o people reading a balance and updating it

at the same time
Security problems
#ard to pro"ide user access to some( but not all( data

Database systems o-er solutions to all the abo"e problems

Le"els of bstraction

Physical level: describes ho+ a record $e1g1( customer& is

stored1

Logical level: describes data stored in database( and the

relationships among the data1
type customer 9 record
customer_id : string:
customer_name : string:
customer;street : string:
customer_city : string:
end:

View level: application programs hide details of data types1

<ie+s can also hide information $such as an employee=s salary&
for security purposes1
<ie+ of Data
An architecture for a database system
Instances and Schemas
Similar to types and "ariables in programming languages
Schema > the logical structure of the database
7*ample: 8he database consists of information about a set of customers and
accounts and the relationship bet+een them&
nalogous to type information of a "ariable in a program
Physical schema: database design at the physical le"el
Logical schema: database design at the logical le"el
Instance > the actual content of the database at a particular point in time
nalogous to the "alue of a "ariable
Physical Data Independence > the ability to modify the physical schema
+ithout changing the logical schema
pplications depend on the logical schema
In general( the interfaces bet+een the "arious le"els and components should
be +ell de,ned so that changes in some parts do not seriously in?uence
others1
Data Models
#ierarchical model

/et+or' model

Relational model
#I7RRC#ICL M!D7L

!ne of the oldest data model

8ree li'e structure

!ne of the hierarchical database model is IMS

!rgani)es the data in the tabular ro+s

Di-erent operation +ere:@

Insert
Update
Delete
Retrie"al of data
d"antages

simlicity

Data integrity

7.ciency
Disad"antages

Implementation comple*ity

Lac' of structural independency

Implementation limitations

Program comple*ity
/et+or'

/et+or' model replaces the hierarchical tree +ith a graph

ble to handle di-erent relations

!peration :@
Insert
Update
Dalete
Retrie"al
ad"antages

Capable to handle di-erent relationships

7ase in data access

Data integrity

Database standards

Data independence
disad"antages

System comple*ity

!perational anomalies

bsence of structural independence

Relational Model

7*ample of tabular data in the relational model

Attributes
Sample Relational Database
8he 7ntity@Relationship Model

Models an enterprise as a collection of entities and relationships

7ntity: a 4thing5 or 4obAect5 in the enterprise that is
distinguishable from other obAects
Described by a set of attributes
Relationship: an association among se"eral entities

Represented diagrammatically by an entity-relationship diagram:

!ther Data Models

!bAect@oriented data model

!bAect@relational data model
!bAect@Relational Data Models

7*tend the relational data model by including obAect orientation

and constructs to deal +ith added data types1

llo+ attributes of tuples to ha"e comple* types( including non@

atomic "alues such as nested relations1

Preser"e relational foundations( in particular the declarati"e

access to data( +hile e*tending modeling po+er1

Pro"ide up+ard compatibility +ith e*isting relational languages1

DML@modify( insert(delete(retri"e

DCL@C!MMI8(R!LL %CB

DDL@Create(alter(drop(grant
Data Manipulation Language
$DML&

Language for accessing and manipulating the data organi)ed by

the appropriate data model

DML also 'no+n as Cuery language

8+o classes of languages
Procedural > user speci,es +hat data is reCuired and ho+ to
get those data
Declarative (nonprocedural) > user speci,es +hat data is
reCuired +ithout specifying ho+ to get those data
SDL is the most +idely used Cuery language
SDL

SQL: +idely used non@procedural language

7*ample: 6ind the name of the customer +ith customer@id 1EF@GH@

IJKL
select customer.customer_name
from customer
wherecustomer.customer_id 9 M1EF@GH@IJKL=

7*ample: 6ind the balances of all accounts held by the customer

+ith customer@id 1EF@GH@IJKL
select account.balance
from depositor( account
where depositor.customer_id 9 M1EF@GH@IJKL= and
depositor.account_number = account.account_number

pplication programs generally access databases through one of

Language e*tensions to allo+ embedded SDL

pplication program interface $e1g1( !D%CNOD%C& +hich allo+ SDL

Cueries to be sent to a database
PML: 7*tensible Mar'up
Language
De,ned by the QQQ Consortium $QHC&
!riginally intended as a document mar'up language not a
database language
8he ability to specify ne+ tags( and to create nested tag
structures made PML a great +ay to e*change data( not Aust
documents

PML has become the basis for all ne+ generation data
interchange formats1

+ide "ariety of tools is a"ailable for parsing( bro+sing and

Cuerying PML documentsNdata
Database Design
8he process of designing the general structure of the database:
Logical Design > Deciding on the database schema1 Database design
reCuires that +e ,nd a 4good5 collection of relation schemas1
%usiness decision > Qhat attributes should +e record in the databaseR
Computer Science decision > Qhat relation schemas should +e ha"e
and ho+ should the attributes be distributed among the "arious
relation schemasR
Physical Design > Deciding on the physical layout of the database


Data Independence
the ability to modify the schema +ithout changing the other schema
In general( the interfaces bet+een the "arious le"els and components
should be +ell de,ned so that changes in some parts do not seriously
in?uence others1

Logical data independence:@indicate that logical schema can be

changed +ithout a-ecting the e*ternalN"ie+ schema 1the logical data
Independence also insulates application programs from operations such as
combining t+o records into one or splitting an e*isting record into t+o or
more records1this may reCuire a change in the "ie+Nlogical mapping as it
lea"e the "ie+ schema unchanged1

Physical data independence:@indicates that the physical storage

structure or de"ice can be changed +ithout a-ecting logical schema1 8he
physical data independence is achie"ed by the mapping from logical to
physical le"el1
Database pplication
rchitectures
(web browser)
Old
Modern
Database Management
System Internals

Storage management
Duery processing

8ransaction processing
Storage Management

Storage manager is a program module that pro"ides the

interface bet+een the lo+@le"el data stored in the database and
the application programs and Cueries submitted to the system1
8he storage manager is responsible to the follo+ing tas's:

Interaction +ith the ,le manager

7.cient storing( retrie"ing and updating of data

Issues:

Storage access
6ile organi)ation
Inde*ing and hashing
Duery Processing
11 Parsing and translation
F1 !ptimi)ation
H1 7"aluation
8ransaction Management
transaction is a collection of operations that performs a
single logical function in a database application

ransaction!management component ensures that the

database remains in a consistent $correct& state despite system
failures $e1g1( po+er failures and operating system crashes& and
transaction failures1
"oncurrency!control manager controls the interaction
among the concurrent transactions( to ensure the consistency
of the database1
!"erall System Structure
#istory of Database Systems
1EL3s and early 1EK3s:
Data processing using magnetic tapes for storage
8apes pro"ide only seCuential access
Punched cards for input
Late 1EK3s and 1EI3s:
#ard dis's allo+ direct access to data
/et+or' and hierarchical data models in +idespread use
8ed Codd de,nes the relational data model
Qould +in the CM 8uring +ard for this +or'
I%M Research begins System R prototype
UC %er'eley begins Ingres prototype
#igh@performance $for the era& transaction processing
#istory $cont1&
1EG3s:
Research relational prototypes e"ol"e into commercial systems
SDL becomes industry standard
Parallel and distributed database systems
!bAect@oriented database systems
1EE3s:
Large decision support and data@mining applications
Large multi@terabyte data +arehouses
7mergence of Qeb commerce
F333s:
PML and PDuery standards
utomated database administration
Increasing use of highly parallel database systems
Qeb@scale distributed data storage systems
Database Users
#sers are di-erentiated by the +ay they e*pect to interact +ith
the system

$pplication programmers > interact +ith system through DML

calls
Sophisticated users > form reCuests in a database Cuery
language
Speciali%ed users > +rite speciali)ed database applications that
do not ,t into the traditional data processing frame+or'
&a've users > in"o'e one of the permanent application programs
that ha"e been +ritten pre"iously
7*amples( people accessing database o"er the +eb( ban'
tellers( clerical sta-
Database dministrator

Coordinates all the acti"ities of the database system

has a good understanding of the enterprise=s information
resources and needs1
Database administratorSs duties include:
Storage structure and access method de,nition

Tranting users authority to access the database

%ac'ing up data

Monitoring performance and responding to changes

Database tuning
Database rchitecture
8he architecture of a database systems is greatly in?uenced by
the underlying computer system on +hich the database is
running:

Centrali)ed
Client@ser"er

Parallel $multiple processors and dis's&

Distributed
6igure 11J
6igure 11I