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 efficient 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 file systems Dra+bac's of using file systems to store data: Data redundancy and inconsistency Multiple file formats( duplication of information in different files Difficulty in accessing data ,eed to +rite a ne+ program to carry out each ne+ tas' Data isolation - multiple files and formats Integrity problems Integrity constraints $e.g. account balance / 0& become 1buried2 in program code rather than being stated e*plicitly #ard to add ne+ constraints or change e*isting ones

Purpose of Database Systems $Cont.&

Dra+bac's of using file systems $cont.& tomicity of updates 3ailures may lea"e database in an inconsistent state +ith partial updates carried out 4*ample: 5ransfer 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 4*ample: 5+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 offer solutions to all the abo"e problems

Le"els of bstraction
Physical level: describes ho+ a record $e.g.( customer& is stored. Logical level: describes data stored in database( and the relationships among the data. type customer 6 record customer_id : string7 customer_name : string7 customer8street : string7 customer_city : string7 end7 View level: application programs hide details of data types. 9ie+s can also hide information $such as an employee:s salary& for security purposes.

9ie+ 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 4*ample: 5he 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 defined so that changes in some parts do not seriously influence others.

Data Models
#ierarchical model
,et+or' model Relational model

#I4R RC#IC L M!D4L

!ne of the oldest data model 5ree li'e structure !ne of the hierarchical database model is IMS !rgani)es the data in the tabular ro+s Different operation +ere:<
Insert Update Delete Retrie"al of data

d"antages

simlicity Data integrity 4fficiency

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 different relations !peration :<
Insert Update Dalete Retrie"al

ad"antages
Capable to handle different relationships 4ase in data access Data integrity Database standards Data independence

disad"antages
System comple*ity !perational anomalies bsence of structural independence

Relational Model
4*ample of tabular data in the relational model

Attributes

Sample Relational Database

5he 4ntity<Relationship Model

Models an enterprise as a collection of entities and relationships 4ntity: a 1thing2 or 1ob=ect2 in the enterprise that is distinguishable from other ob=ects Described by a set of attributes Relationship: an association among se"eral entities Represented diagrammatically by an entity-relationship diagram:

!ther Data Models

!b=ect<oriented data model !b=ect<relational data model

!b=ect<Relational Data Models

4*tend the relational data model by including ob=ect orientation and constructs to deal +ith added data types. llo+ attributes of tuples to ha"e comple* types( including non<atomic "alues such as nested relations. Preser"e relational foundations( in particular the declarati"e access to data( +hile e*tending modeling po+er. Pro"ide up+ard compatibility +ith e*isting relational languages.

 DML<modify( insert(delete(retri"e DCL<C!MMI5(R!LL % C> 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 ?uery language 5+o classes of languages Procedural ; user specifies +hat data is re?uired and ho+ to get those data Declarative (nonprocedural) ; user specifies +hat data is re?uired +ithout specifying ho+ to get those data S@L is the most +idely used ?uery language

S@L
SQL: +idely used non<procedural language 4*ample: 3ind the name of the customer +ith customer<id 1AB<CD<EFGH select customer.customer_name from customer where customer.customer_id 6 I1AB<CD<EFGH: 4*ample: 3ind the balances of all accounts held by the customer +ith customer<id 1AB<CD<EFGH select account.balance from depositor( account where depositor.customer_id 6 I1AB<CD<EFGH: and depositor.account_number = account.account_number pplication programs generally access databases through one of Language e*tensions to allo+ embedded S@L pplication program interface $e.g.( !D%CJKD%C& +hich allo+ S@L ?ueries to be sent to a database

LML: 4*tensible Mar'up Language Defined by the MMM Consortium $MDC&

!riginally intended as a document mar'up language not a database language 5he ability to specify ne+ tags( and to create nested tag structures made LML a great +ay to e*change data( not =ust documents LML has become the basis for all ne+ generation data interchange formats. +ide "ariety of tools is a"ailable for parsing( bro+sing and ?uerying LML documentsJdata

Database Design
5he process of designing the general structure of the database: Logical Design ; Deciding on the database schema. Database design re?uires that +e find a 1good2 collection of relation schemas. %usiness decision ; Mhat attributes should +e record in the databaseN Computer Science decision ; Mhat relation schemas should +e ha"e and ho+ should the attributes be distributed among the "arious relation schemasN 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 defined so that changes in some parts do not seriously influence others.

Logical data independence:<indicate that logical schema can be changed +ithout

affecting the e*ternalJ"ie+ schema .the 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 records.this may re?uire a change in the "ie+Jlogical mapping as it lea"e the "ie+ schema unchanged.

Physical data independence7<indicates that the physical storage structure or de"ice

can be changed +ithout affecting logical schema. 5he physical data independence is achie"ed by the mapping from logical to physical le"el.

Database pplication rchitectures

(web browser)

Old

Modern

Database Management System Internals

Storage management @uery processing 5ransaction 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 ?ueries submitted to the system. 5he storage manager is responsible to the follo+ing tas's: Interaction +ith the file manager 4fficient storing( retrie"ing and updating of data Issues: Storage access 3ile organi)ation Inde*ing and hashing

@uery Processing
1. Parsing and translation B. !ptimi)ation D. 4"aluation

5ransaction 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 $e.g.( po+er failures and operating system crashes& and transaction failures. "oncurrency!control manager controls the interaction among the concurrent transactions( to ensure the consistency of the database.

!"erall System Structure

#istory of Database Systems

1AH0s and early 1AG0s: Data processing using magnetic tapes for storage 5apes pro"ide only se?uential access Punched cards for input Late 1AG0s and 1AE0s: #ard dis's allo+ direct access to data ,et+or' and hierarchical data models in +idespread use 5ed Codd defines the relational data model Mould +in the CM 5uring +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 $cont.&
1AC0s: Research relational prototypes e"ol"e into commercial systems S@L becomes industry standard Parallel and distributed database systems !b=ect<oriented database systems 1AA0s: Large decision support and data<mining applications Large multi<terabyte data +arehouses 4mergence of Meb commerce B000s: LML and L@uery standards utomated database administration Increasing use of highly parallel database systems

Database Users
#sers are differentiated by the +ay they e*pect to interact +ith the system $pplication programmers ; interact +ith system through DML calls Sophisticated users ; form re?uests in a database ?uery language Speciali%ed users ; +rite speciali)ed database applications that do not fit 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 4*amples( people accessing database o"er the +eb( ban' tellers( clerical staff

Database dministrator
Coordinates all the acti"ities of the database system has a good understanding of the enterprise:s information resources and needs. Database administratorOs duties include: Storage structure and access method definition Pranting users authority to access the database %ac'ing up data Monitoring performance and responding to changes Database tuning

Database rchitecture
5he architecture of a database systems is greatly influenced by the underlying computer system on +hich the database is running: Centrali)ed Client<ser"er Parallel $multiple processors and dis's& Distributed

3igure 1.F

3igure 1.E