2

Introduction to
Database Management Systems
(DBMS)
4
Database Management
System (DBMS)
Definitions:

 Data: Known facts that can be recorded and
that have implicit meaning
 Database: Collection of related data
 Ex. the names, telephone numbers and addresses
of all the people you know
 Database Management System: A
computerized record-keeping system
5
DBMS (Contd.)
 Goals of a Database Management System:
 To provide an efficient as well as convenient
environment for accessing data in a database
 Enforce information security: database security,
concurrence control, crash recovery
 It is a general purpose facility for:
 Defining database
 Constructing database
 Manipulating database
6
Benefits of database approach
 Redundancy can be reduced
 Inconsistency can be avoided
 Data can be shared
 Standards can be enforced
 Security restrictions can be applied
 Integrity can be maintained
 Data independence can be provided
7
DBMS Functions
 Data Definition
 Data Manipulation
 Data Security and Integrity
 Data Recovery and Concurrency
 Data Dictionary
 Performance

8
Database System
Stored Data Defn.
Stored Database
Software to access stored data
Software to process queries/programs
DBMS
Software


Application Programs/Queries
Users
DATABASE
SYSTEM
(META-DATA).
9
Database System
user
query Q1
Database
scheme
Application
program query
Q2
Query processor DDL compiler
Database manager
File manager
Physical
database
Compiled query
Q2
Database
description
10
Categories of Data Models
Conceptual Physical Representational
Data Model
 A set of concepts used to describe the structure of a
database
 By structure, we mean the data types, relationships,
and constraints that should holds for the data

11
Database Architecture
Internal level
(storage view)
Conceptual level
(community user view)
External level
(individual user
views)
Database
12
An example of the three levels
SNo FName LName Age
Salary
SNo FName
LName

Age

Salary
SNo LName
BranchNo
struct STAFF {
int staffNo;
int branchNo;
char fName[15];
char lName[15];
struct date dateOfBirth;
float salary;
struct STAFF *next;
/* pointer to next Staff record
*/
};
index staffNo; index branchNo;
/* define indexes for staff */

BranchNo
Conceptual View
External View1
External View2

Internal
View

13
Schema
 Schema: Description of data in terms of a data
model
 Three-level DB Architecture defines following
schemas:
 External Schema (or sub-schema)
 Written using external DDL
 Conceptual Schema (or schema)
 Written using conceptual DDL
 Internal Schema
 Written using internal DDL or storage structure definition
14
Data Independence
 Change the schema at one level of a database
system without a need to change the schema at
the next higher level
 Logical data independence: Refers to the immunity
of the external schemas to changes in the conceptual
schema e.g., add new record or field
 Physical data independence: Refers to the immunity
of the conceptual schema to changes in the internal
schema e.g., adding new index should not void
existing ones
15
HIERARCHICAL
NETWORK
RELATIONAL
TABLE
ROW
COLUMN
VALUE
TYPES OF DATABASE MODELS
16
DATA ANALYSIS
Entities - Attributes - Relationships - Integrity Rules
LOGICAL DESIGN
Tables - Columns - Primary Keys - Foreign Keys
PHYSICAL DESIGN
DDL for Tablespaces, Tables, Indexes
DATABASE DESIGN PHASES
Introduction to
Relational Databases:
RDBMS
18
Definition : RDBMS
 It is a system in which, at a minimum :
 The data is perceived by the user as tables ( and
nothing but tables ); and
 The operators at the user’s disposal - e.g., for data
retrieval - are operators that generate new tables
from old, and those include at least SELECT,
PROJECT, and JOIN.
19
Features of an RDBMS
 The ability to create multiple relations (tables)
and enter data into them
 An interactive query language
 Retrieval of information stored in more than
one table
 Provides a Catalog or Dictionary, which itself
consists of tables ( called system tables )
20
Some Important Terms
 Relation : a table
 Tuple : a row in a table
 Attribute : a Column in a table
 Degree : number of attributes
 Cardinality : number of tuples
 Primary Key : a unique identifier for the table
 Domain : a pool of values from which specific attributes
of specific relations draw their values
21
Properties of Relations (Tables)
 There are no duplicate rows (tuples)
 Tuples are unordered, top to bottom
 Attributes are unordered, left to right
 All attribute values are atomic ( or scalar )
 Relational databases do not allow repeating
groups
22
Keys
 Key
 Super Key
 Candidate Keys
 Primary Key
 Alternate Key
 Secondary Keys

23
Keys and Referential Integrity
sid cid grade
53666 carnatic101 C
53688 reggae203 B
53650 topology112 A
53666 history105 B
sid name age
53666 Jones 18
53688 Smith 18
53650 Smith 19
gpa
3.4
3.2
3.8
login
Jones@cs
Smith@eecs
Smith@math
Enrolled
Student
Primary key
Foreign key referring to
sid of STUDENT relation
24
Relational Algebra
26
Relational Query Languages
 Query languages: Allow manipulation and
retrieval of data from a database.
 Relational model supports simple, powerful
QLs:
 Strong formal foundation based on logic.
 Allows for much optimization.
 Query Languages != programming languages!
27
Example Instances
sid bid
22 101
58 103
day
10/10/99
11/12/99
sid sname age
22 Deepa 45.0
31 Laxmi 55.5
58 Roopa 35.0
rating
7
8
10
sid sname age
28 Yamuna 35.0
31 Laxmi 55.5
44 Geeta 35.0
rating
9
8
5
58 Roopa 35.0 10
R1
S1
S2
28
Relational Algebra
 Basic operations:
 Selection (o )
 Projection (t)
 Cross- product ( X)
 Set- difference ( –)
 Union ( )

29
Projection
sname
Yamuna
Laxmi
Geeta
rating
9
8
5
Roopa 10
age
35.0
t
sname, rating
(S2)
t
age
(S2)
55.5
30
Selection
sid sname age
28 Yamuna 35.0
rating
9
58 Roopa 35.0 10
o
rating > 8
(S2)
sname
Yamuna
rating
9
Roopa 10
t
sname, rating
(S2) (o
rating > 8
(S2))
31
Union, Intersection, Set
Difference
sid sname age
22 Deepa 45.0
31 Laxmi 55.5
58 Roopa 35.0
rating
7
8
10
44 Geeta 35.0
28 Yamuna 35.0
5
9
sid sname age
22 Deepa 45.0
rating
7
sid sname age
31 Laxmi 55.5
58 Roopa 35.0
rating
8
10
S1 S2
S1 ÷ S2
S1 · S2
32
Cross- Product
(sid) bid
22 101
58 103
day
10/10/99
11/12/99
(sid) sname age
22 Deepa 45.0
22 Deepa 45.0
31 Laxmi 55.5
rating
7
7
8
31 Laxmi 55.5
58 Roopa 35.0
58 Roopa 35.0
8
10
10
22 101 10/10/99
58 103 11/12/99
22 101 10/10/99
58 103 11/12/99
33
Joins
Condition Join :
(sid) bid
22 101
58 103
day
10/10/99
11/12/99
(sid) sname age
22 Deepa 45.0
31 Laxmi 55.5
rating
7
8
34
Equi-Join
bid
101
103
day
10/10/99
11/12/99
(sid) sname age
22 Deepa 45.0
58 Roopa 35.0
rating
7
10
35
Division
sno pno
s1 p1
s1 p2
s1 p3
s1 p4
s2 p1
s2 p2
s3 p2
s4 p2
s4 p4
A
pno
p2
pno
p1
p2
p4
pno
p2
p4
B1
B2
B3
sno
s1
s2
s3
s4
sno
s1
s4
sno
s1
A/B1 A/B2 A/B3
•Not supported as a primitive operator, but useful for
expressing queries like:
•Find sailors who have reserved all boats .
36
Introduction to Query
Optimization
38
Processing A High-level
Query
Query in a high level language
Intermediate form of query
Execution plan
Code to execute the query
SCANING, PARSING AND VALIDATING
QUERY OPTIMIZER
QUERY CODE GENERATOR
Result of query
RUNTIME DATABASE PROCESSOR

Typical steps
when processing
a high level
query.
39
Two Main Techniques for Query
Optimization
 Heuristic Rules: A heuristic is a rule that works well
in most of cases, but not always. General Idea:
 Many different relational algebra expressions (and thus
query trees) are equivalent.
 Transform the initial query tree of a query into an
equivalent final query tree that is efficient to execute.
 Cost based query optimization
 Estimate the cost for each execution plan, and choose the
one with the lowest cost.
 Can we get the best execution plan?
40
Motivating Example
select *
from R1, R2, R3
where R1.r2no=R2.r2no
and R2.r3no=R3.r3no
and R1.a=5000

NLJ
SS(R2) SS(R3)
NLJ
SS(R1, “a=5000”)
41
Alternative Plans 1(No Indexes)
select *
from R1, R2, R3
where R1.r2no=R2.r2no
and R2.r3no=R3.r3no
and R1.a=5000

NLJ
SS(R1, “a=5000”) SS(R2)
NLJ
SS(R3)
42
Alternative Plans 2 (With
Indexes)
select *
from R1, R2, R3
where R1.r2no=R2.r2no
and R2.r3no=R3.r3no
and R1.a=5000

NLJ
IS(R1, “a=5000”) SS(R2)
NLJ
SS(R3)
43
Conceptual Design
Using the
Entity- Relationship
Model
45
Overview of Database Design
 Conceptual design : (ER Model is used at this
stage.)

 Schema Refinement : (Normalization)

 Physical Database Design and Tuning
46
E R Modeling
 Conceptual Schema Design
 Relational Calculus
- Formal Language for Relational D/B.
Relational Calculus
Predicate Calculus Domain Calculus
SQL / Tuple Based
Query By Examples
47
Design Phases…
Requirements Collection
& Analysis
Data Requirements
Functional Requirements Conceptual Design
Logical Design
Physical Design
User Defined Operations
Data Flow Diagrams
Sequence Diagrams, Scenarios
Entity Types, Constraints , Relationships
No Implementation Details.
Ensures Requirements
Meets the Design
Data Model Mapping – Type of Database is identified
Internal Storage Structures / Access Path / File Organizations
48
E-R Modeling
 Entity
 is anything that exists and is distinguishable
 Entity Set
 a group of similar entities
 Attribute
 properties that describe an entity
 Relationship
 an association between entities
49
Notations
ENTITY TYPE ( REGULAR )
WEAK ENTITY TYPE
RELATIONSHIP TYPE
WEAK RELATIONSHIP TYPE
50
CREATE TABLE Employees
(ssn CHAR (11),
name CHAR (20),
lot INTEGER,
PRIMARY KEY (ssn))
Employee
ssn name
lot
SSN NAME LOT
123- 22- 3666 Attishoo 48
231- 31- 5368 Smiley 22
131- 24- 3650 Smethurst 35
Entity
Entity Set
Attributes
51
52
ER Model
Department
did dname budget
since
Works_in
Employee
ssn name
lot
Reports_To
supervisor
Sub-
ordinate
53
CREATE TABLE Works_ In(
ssn CHAR (11),
did INTEGER,
since DATE,
PRIMARY KEY (ssn, did),
FOREIGN KEY (ssn)
REFERENCES Employees,
FOREIGN KEY (did)
REFERENCES Departments)
SSN DID SINCE
123-22-3666 51 1/1/91
123-22-3666 56 3/3/93
231-31-5368 51 2/2/92
ER Model (Contd.)
Works_ In
54
Manages
Department
did dname budget
since
Employee
ssn name
lot
Key Constraints
55
Key Constraints for Ternary Relationships
Department
did dname
since
Works_in
Employee
ssn name
lot
budget
Location
capacity
address
56
Participation Constraints
Department
did dname budget
since
Manages
Employee
ssn name
lot
Works_in
since
57
policy
Dependent
pname
age
cost
Employee
ssn name
lot
Weak Entities
58
ISA („is a‟) Hierarchies
Employee
ssn name
lot
Hourly_Emp
Hrs_worked
Hrly_wages
Contract_Emp
contractid
IsA
59
Employee
ssn
name
lot
monitors
project
pid pbudget
Started on
department
did dname
budget
sponsors
until
Aggregation
60
Works_ In does not allow an employee to work in a department
for two or more periods (why?)
Entity vs. Attribute
Works_in
Department
did dname budget
from
Employee
ssn
name
lot
to
61
Entity vs. Attribute (Contd.)
Works_in
Department
did dname budget
from
Employee
ssn
name
lot
to Duration
62
manages
Department
did dname budget
since
Employee
ssn
name
lot
DB
DB - Dbudget
Entity vs. Relationship
63
manages
Department
did dname
budget
since
Employee
ssn
name
lot
DBudget
Mgr_appt
Appt num
Entity vs. Relationship
64
Dependent
pname
age
cost
Employee
ssn name
lot
covers
Policy
policyid
Binary vs. Ternary Relationships
65
Dependent
pname
age
cost
Employee
ssn name
lot
Beneficiary
Policy
policyid
Better Design
purchaser
Binary vs. Ternary Relationships
66
• Some constraints cannot be captured in ER diagrams:

• Functional dependencies

• Inclusion dependencies

• General constraints

Constraints Beyond the ER Model
67
E-R Diagram
DEPARTMENT
DEPT_
EMP
EMPLOYEE
EMP_
DEP
DEPENDENT
PROJ_
WORK
PROJ_
MGR
PROJECT
SUPPLIER
SUPP_
PART_
PROJ
PART
PART_
STRUC
TURE
SUPP_
PART
M
M
M
M
M
M
M
M
M M
M
M
1
1 1
68
Example to Start with ….
 An Example Database Application called
COMPANY which serves to illustrate the ER
Model concepts and their schema design.

The following are collection from the Client.
69
Analysis…
 Company :
Organized into Departments, Each Department
has a name, no and manager who manages the
department. The Company keeps track of the
date that employee managing the department. A
Department may have a Several locations.
70
Analysis…
 Department :
A Department controls a number of Projects each of
which has a unique name , no and a single Location.
 Employee :
Name, Age, Gender, BirthDate, SSN, Address, Salary.
An Employee is assigned to one department, may work
on several projects which are not controlled by the
department. Track of the number of hours per week is
also controlled.
71
Analysis….
 Keep track of the dependents of each employee
for insurance policies : We keep each dependant
first name, gender, Date of birth and
relationship to the employee.
72
Now to our Company…
DEPARTMENT
( Name , Number , { Locations } , Manager, Start Date )

PROJECT
( Name, Number, Location , Controlling Department )


EMPLOYEE
(Name (Fname, Lname) , SSN , Gender, Address, Salary
Birthdate, Department , Supervisor , (Workson ( Project , Hrs))

DEPENDENT
( Employee, Name, Gender, Birthdate , Relationship )
73
Example …
 Manage:
 Department and Employee
 Partial Participation
 Relation Attribute : StartDate.
 Works For:
 Department and Employee
 Total Participation

74
Example…
 Control :
 Department , Project
 Partial Participation from Department
 Total Participation from Project
 Control Department is a RKA.
 Supervisor :
 Employee, Employee
 Partial and Recursive

75
Example …
 Works – On :
 Project , Employee
 Total Participation
 Hours Worked is a RKA.
 Dependants of:
 Employee , Dependant
 Dependant is a Weaker
 Dependant is Total , Employee is Partial.
76
One Possible mapping of the Problem
Statement
Work
s For
Department
Name No
Loc
Control
s
Project
Name
No
Loc
Work
sOn
manage
s
Sdate
Hours
Depend On
Name Sex
Bdate
Relationship
Supe
rvise
s
Employee
Address
Fname
Sex
SSN
Name
Bdate
Sal
Lname
Dependent
77
78
79
80
Schema Refinement
and
Normalization
82
Normalization and Normal
Forms
 Normalization:
 Decomposing a larger, complex table into several
smaller, simpler ones.
 Move from a lower normal form to a higher Normal
form.
 Normal Forms:
 First Normal Form (1NF)
 Second Normal Form (2NF)
 Third Normal Form (3NF)
 *Higher Normal Forms (BCNF, 4NF, 5NF ....)
 In practice, 3NF is often good enough.
83
Why Normal Forms
 The first question to ask is whether any
refinement is needed!
 If a relation is in a certain normal form (BCNF,
3NF etc.), it is known that certain kinds of
problems are avoided/ minimized. This can be
used to help us decide whether decomposing the
relation will help.

84
The Evils of Redundancy
 Redundancy is at the root of several problems
associated with relational schemas
 More seriously, data redundancy causes several
anomalies: insert, update, delete
 Wastage of storage.
 Main refinement technique: decomposition
(replacing ABCD with, say, AB and BCD, or
ACD and ABD).
85
Refining an ER Diagram - Before
Department
did dname budget
since
Works_in
Employee
ssn
name
lot
86
Refining an ER Diagram - After
Works_in
since
Employee
ssn
name
lot
Department
did dname budget
87
First Normal Form
 A table is in 1NF, if every row contains exactly one
value for each attribute.
 Disallow multivalued attributes, composite attributes
and their combinations.
 1NF states that :
 domains of attributes must include only atomic (simple,
indivisible) values and that value of any attribute in a
tuple must be a single value from the domain of that
attribute.
 By definition, any relational table must be in 1NF.
88
Functional Dependencies (FDs)
 Provide a formal mechanism to express
constraints between attributes
 Given a relation R, attribute Y of R is
functionally dependent on the attribute X of R
if & only if each X-value in R has associated
with it precisely one Y-value in R.
89
Full Dependency
 Concept of full functional dependency
 A FD x ÷ y is a full functional dependency if
removal of any attribute A from X means that the
dependency does not hold any more.
90
Partial Dependency
 An F.D. x ÷ y is a partial dependency if there is
some attribute A e X that can be removed
from X and the dependency will still hold.
91
Example: Constraints on Entity Set
123- 22- 3666 Attishoo
231- 31- 5368
131- 24- 3650
434- 26- 3751
612- 67- 4134
Smiley
Smethurst
Guldu
Madayan
48
22
35
35
35
8
8
5
5
8
10
10
7
7
10
40
30
30
32
40
S N L R W H
5
8
7
10
R W
123- 22- 3666 Attishoo
231- 31- 5368
131- 24- 3650
434- 26- 3751
612- 67- 4134
Smiley
Smethurst
Guldu
Madayan
48
22
35
35
35
S N L
40
30
30
32
40
H
8
R
8
5
5
8
92
Second Normal Form (2NF)
 A relation schema R is in 2NF if:
 it is in 1NF and
 every non-prime attribute A in R is fully functionally
dependent on the primary key of R.
 2NF prohibits partial dependencies.

93
2NF: An Example
 Emp{Eno, Dept, ProjCode, Hours}
 Primary key: {Eno, ProjCode}
 {Eno} -> {Dept}, {Eno, ProjCode} -> {Hours}
 Test of 2NF
 {Eno} -> {Dept}: partial dependency.
 Emp is in 1NF, but not in 2NF.
 Decomposition:
 Emp {Eno, Dept}
 Proj {Eno, ProjCode, Hours}
94
Transitive Dependency
 An FD X ÷ Y in a relation schema R is a
transitive dependency if
 there is a set of attributes Z that is not a subset of
any key of R, and
 both X ÷ Z and Z ÷ Y hold.
95
Third Normal Form
 A relation schema R is in 3NF if
 It is in 2NF and
 No nonprime attribute of R is transitively dependent
on the primary key.
 3NF means that each non-key attribute
value in any tuple is truly dependent on
the Primary Key and not even partially on
other attributes.
 3NF prohibits transitive dependencies.

96
3NF: An Example
 Emp{Eno, Dept, Dept_Head}
 Primary key: {Eno}
 {Eno} -> {Dept}, {Dept} -> {Dept_Head}
 Test of 3NF
 {Eno} -> {Dept} -> {Dept_Head}: Transitive dependency.
 Emp is in 2NF, but not in 3NF.
 Decomposition:
 Emp {Eno, Dept}
 Dept {Dept, Dept_Head}
97
Boyce –Codd Normal Form
 The intention of BCNF is that- 3NF does not
satisfactorily handle the case of a relation
processing two or more composite or
overlapping candidate keys
98

BCNF ( Boyce Codd Normal
Form)
 A Relation is said to be in Boyce Codd Normal
Form (BCNF) if and only if every determinant
is a candidate key.

99
Decomposition of a Relation
Scheme
 Suppose that relation R contains attributes A1 ...
An. A decomposition of R consists of replacing
R by two or more relations such that:
 Each new relation scheme contains a subset of the
attributes of R (and no attributes that do not appear
in R), and
 Every attribute of R appears as an attribute of one of
the new relations.
100
101
102
103
104
105
106
Transaction,
Concurrency Control
and Recovery
108
Transaction
 A sequence of many actions which are
considered to be one atomic unit of work.
 Read, write, commit, abort
 Governed by four ACID properties:
 Atomicity, Consistency, Isolation, Durability
 Has a unique starting point, some actions
and one end point
109
The ACID Properties
 A tomicity: All actions in the transaction
happen, or none happen.
 C onsistency: If each transaction is
consistent, and the DB starts consistent, it
ends up consistent.
 I solation: Execution of one transaction is
isolated from that of other transactions.
 D urability: If a transaction commits, its
effects persist.
110
Automicity
 All-or-nothing, no partial results. An event either happens and is
committed or fails and is rolled back.
 e.g. in a money transfer, debit one account, credit the other.
Either both debiting and crediting operations succeed, or
neither of them do.
 Transaction failure is called Abort
 Commit and abort are irrevocable actions. There is no undo for
these actions.
 An Abort undoes operations that have already been executed
 For database operations, restore the data’s previous value
from before the transaction (Rollback-it); a Rollback
command will undo all actions taken since the last commit
for that user.
 But some real world operations are not undoable.
Examples - transfer money, print ticket, fire missile

111
Consistency
 Every transaction should maintain DB consistency
 Referential integrity - e.g. each order references an
existing customer number and existing part numbers
 The books balance (debits = credits, assets =
liabilities)
 Consistency preservation is a property of a transaction,
not of the database mechanisms for controlling it
(unlike the A, I, and D of ACID)
 If each transaction maintains consistency,
then a serial execution of transactions does also

112
Isolation
Intuitively, the effect of a set of transactions should
be the same as if they ran independently.
 Formally, an interleaved execution of transactions is
serializable if its effect is equivalent to a serial one.
 Implies a user view where the system runs each user’s
transaction stand-alone.
 Of course, transactions in fact run with lots of
concurrency, to use device parallelism – this will be
covered later.
 Transactions can use common data (shared data)
 They can use the same data processing mechanisms
(time sharing)

113
Durability
 When a transaction commits, its results will survive
failures (e.g. of the application, OS, DB system … even
of the disk).
 Makes it possible for a transaction to be a legal
contract.
 Implementation is usually via a log
 DB system writes all transaction updates to a log file
 to commit, it adds a record “commit(Ti)” to the log
 when the commit record is on disk, the transaction is
committed.
 system waits for disk ack before acknowledging to
user

114
Transaction processing
Can be automatic (controlled by the RDBMS) or
programmatic (programmed using SQL or other
supported programming languages, like
PL/SQL)

115
Why Have Concurrent Processes?
 Better transaction throughput
 Improved response time
 Done via better utilization of resources:
 While one processes is doing a disk read,
another can be using the CPU or reading
another disk.
116
Typical situations requiring
concurrency control
 Exclusive access to an external device or shared
service (e.g., managing printer queues)
 Coordination of applications which process
parallel data (e.g. parallel DB servers)
 Disabling or enabling execution of the client
programs in a specific moment (typically for
database administration - e.g. database backups,
enforcing resource occupation, etc.)
 Detection of transaction ends when managing
multiple sessions for connection to the database
(client/server architectures, Web access)


117
Problems with Concurrency (in absence
of locking)
 Lost Update problem - losing values due to
intervention of write operation from other
overlapping transactions
 Temporary Update problem - discarding
previous changes made by overlapping
transaction after rollback
 Incorrect Summary problem - overwriting of
certain
values used for calculation by write operations
from other transactions


118
Lost Update Problem
Time
T
0
Transaction A
Transaction B Value
Start A 6
T
1
Read Value (6)
6
T
2
Add 2 (6+2=8) Read Value
(6)
6
T
3
Write Value (8) Add 3 (6+3=9) 8
T
4
End A Write Value (9) 9
Start B
 What should the final Order Value be?
 Which Update has been lost?
T
5
End B 9
119
Temporary Update Problem
Time
T
0
Transaction A Transaction B Value
Start A 6
T
1
Read Value (6)
6
T
2
Add 2 (8) 6
T
3
Write Value (8) 8
T
4
Failure: Rollback! 8 Read Value (8)
Start B
T
5
Write Value (6) Add 3 (8+3=11) 6
Write Value (11) T
6
End A
11
 What should the final Order Value be?
 Where is the temporary update?
T
5
End B 11
120
Incorrect Summary Problem
Time
T
0
Transaction A
Transaction B Values
T
1
Read 1
st
Value (6)
6
3
T
2
Add 2 (6+2=8)
6
3
T
3
Write 1
st
Value (8)
8
3
T
4
8
3
T
5
Add 2 (3+2 = 5)
8
3
Write 2
nd
Value (5)
8
5
Read 2
nd
Value (3) Read 1
st
Value (8)
Read 2
nd
Value (3)
Total Sum = 11
 What should the total Order Value be?
 Which order was accumulated before update, and which
after?
121


3.1 Database State and Changes
D1, D2 - Logically consistent states of the database data
T - Transaction for changing the database
t1, t2 - Absolute time before and after the transaction
122


active
partially
committed
committed
aborted
terminated
BEGIN

READ
,
WRITE
END

ROLLBACK
ROLLBACK
COMMIT
3.2 Transaction State and Progress
A transaction reaches its commit point when all
operations accessing the database are completed
and the result has been recorded in the log. It then
writes a [commit, <transaction-id>] and terminates.
When a system failure occurs, search the log file for entries
[start, <transaction-id>]
and if there are no logged entries [commit, <transaction-id>]
then undo all operations that have logged entries
[write, <transaction-id>, X, old_value, new_value]
123
Schedules
T1 T2
R(A)
W(A)
R(B)
W(B)
R(C)
W(C)
• Schedule: Actions of transactions as seen by the DBMS

124
Serializable Schedule
 A schedule whose effect on the DB “state” is
the same as that of some serial schedule
 All serial schedules are serializable
 But the reverse may not be true
125
Serializability Violations
T1 T2
R(A)
W(A)
R(A)
W(A)
R(B)
W(B)
commit
R(B)
W(B)
commit
Database is
inconsistent!
Transfer
Rs.10,000
from A to B
Add 6%
interest to A
& B
126
Cascading Aborts
T1 T2
R(A)
W(A)
R(A)
W(A)
abort
127
Recoverable Schedules
T1 T2
R(A)
W(A)
R(A)
W(A)
commit
abort
T1 T2
R(A)
W(A)
R(A)
W(A)
commit
commit
Unrecoverable Schedule Recoverable Schedule
128
Locking
 The concept of locking data items is one of the main techniques
for controlling the concurrent execution of transactions.
 A lock is a variable associated with a data item in the database.
 Generally there is a lock for each data item in the database.
 A lock describes the status of the data item with respect to
possible operations that can be applied to that item
 used for synchronising the access by concurrent transactions
to the database items.
 A transaction locks an object before using it
 When an object is locked by another transaction, the requesting
transaction must wait

129
Locking Granularity
 A database item which can be locked could be
 a database record
 a field value of a database record
 the whole database
 Trade-offs
 coarse granularity
 the larger the data item size, the lower the degree of
concurrency
 fine granularity
 the smaller the data item size, the more locks to be
managed and stored, and the more lock/unlock
operations needed.



130
Locking: A Technique for
Concurrency Control
-- S X
-- \ \ \
S \ \
X \
Compatibility matrix for lock types X and S
S: Shared lock
X: Exclusive lock
-- No lock
•Locks are automatically obtained by DBMS.
•Guarantees serializability!

131
Two- Phase Locking (2PL)
Strict 2PL:
– If T wants to read an object, first obtains an S lock.
– If T wants to modify an object, first obtains X lock.
– Hold all locks until end of transaction.
– Guarantees serializability, and recoverable schedule, too!
also avoids WW problems!
2PL:
– Slight variant of strict 2PL
– transactions can release locks before the end (commit or
abort)
But after releasing any lock it can acquire no new locks
– Guarantees serializability
132
Handling a Lock Request
Lock Request (XID, OID, Mode)
Currently Locked?
Empty Wait Queue?
Currently X-locked?
Put on Queue
Grant Lock
Mode==X
Mode==S
No
No
No
Yes
Yes
Yes
133
134
Recovery
 Occurs in case of transaction failures.

 Database (DB) is restored to the most
recent consistent state just before the time
of failure.

 To do this, the DB system needs
information about changes applied by
various transactions. It is the system log.
135
Recovery: Motivation
T1
T2
T3
T4
T5
crash
•Atomicity: Undoing actions of transaction that do not
commit
•Durability: Making sure all actions of committed
transactions survive system crashes
•The Recovery Manager guarantees Atomicity & Durability.

136
Recovery Outline
 Restore to most recent “consistent” state
just before time of failure
 Use data in the log file
 Catastrophic Failure
 Restore database from backup
 Replay transactions from log file
 Database becomes inconsistent (non-
catastrophic errors)
 Undo or Redo last transactions until
consistent state is restored

137
Logging
 Record REDO and UNDO information, for
every update, in a log.
– Sequential writes to log (put it on a separate disk).
– Minimal info (diff) written to log, so multiple
updates fit in a single log page.
138
Handling the Buffer Pool
Desired
Trivial
• When is buffer written back to disk?
• Steal/No-steal
Can it be written before commit? (steal)
Or does it have to wait till after commit? (no-steal)
• Force/No-force
Is it written “immediately” after commit? (force)
Or can it remain in memory? (no-force)

NoSteal Steal
NoForce
Force
139
Write- Ahead Logging (WAL)
 The Write- Ahead Logging Protocol:
 Must force the log record for an update before the
corresponding data page gets to disk.
 Must write all log records for a transaction before
commit .
 What goes into log:
 BFIM needed for UNDO type algorithms
 AFIM needed for REDO type algorithms


140
Checkpoints in the System Log
 Checkpoint record written in log when all updated DB
buffers written out to disk
 Any committed transaction occurring before checkpoint
in log can be considered permanent (won’t have to be
redone after crash)
 Actions
 suspend execution of all transactions
 force-write all modified buffers to disk
 write checkpoint entry in log and force write log
 resume transactions
 Fuzzy checkpointing
 resume transactions as soon as buffers written

141
142
143
BY :

ABURAFEY AZMI
Contact me on
Aburafey.blogspot.com
Gr8knowledge.blogspot.com
rafey111@rediffmail.com



2

Introduction to
Database Management Systems

(DBMS)

the names. telephone numbers and addresses of all the people you know  Database Management System: A computerized record-keeping system 4 .Database Management System (DBMS) Definitions:   Data: Known facts that can be recorded and that have implicit meaning Database: Collection of related data  Ex.

)  Goals of a Database Management System:  To provide an efficient as well as convenient environment for accessing data in a database Enforce information security: database security. concurrence control. crash recovery   It is a general purpose facility for:    Defining database Constructing database Manipulating database 5 .DBMS (Contd.

Benefits of database approach        Redundancy can be reduced Inconsistency can be avoided Data can be shared Standards can be enforced Security restrictions can be applied Integrity can be maintained Data independence can be provided 6 .

DBMS Functions       Data Definition Data Manipulation Data Security and Integrity Data Recovery and Concurrency Data Dictionary Performance 7 .

Database System Users DATABASE SYSTEM DBMS Application Programs/Queries Software Software to process queries/programs Software to access stored data Stored Data Defn. Stored Database 8 . (META-DATA).

Database System Application program query Q2 user query Q1 Query processor Database scheme DDL compiler Compiled query Q2 Database manager Database description File manager Physical database 9 .

we mean the data types.Data Model   A set of concepts used to describe the structure of a database By structure. and constraints that should holds for the data Categories of Data Models Conceptual Physical Representational 10 . relationships.

Database Architecture External level (individual user views) Conceptual level (community user view) Internal level (storage view) Database 11 .

index branchNo. View int branchNo. float salary. char lName[15]. char fName[15]. struct STAFF *next. struct date dateOfBirth.An example of the three levels SNo FName LName Age Salary BranchNo struct STAFF { Internal int staffNo. index staffNo. /* define indexes for staff */ Conceptual View SNo FName LName External View1 Age Salary SNo LName BranchNo External View2 12 . /* pointer to next Staff record */ }.

Schema   Schema: Description of data in terms of a data model Three-level DB Architecture defines following schemas:  External Schema (or sub-schema)  Written using external DDL  Conceptual Schema (or schema)  Written using conceptual DDL Written using internal DDL or storage structure definition 13  Internal Schema  .

adding new index should not void existing ones  14 .g.Data Independence  Change the schema at one level of a database system without a need to change the schema at the next higher level  Logical data independence: Refers to the immunity of the external schemas to changes in the conceptual schema e..g. add new record or field Physical data independence: Refers to the immunity of the conceptual schema to changes in the internal schema e..

TYPES OF DATABASE MODELS HIERARCHICAL NETWORK COLUMN ROW VALUE TABLE RELATIONAL 15 .

Primary Keys .Columns .Relationships .Attributes .Foreign Keys PHYSICAL DESIGN DDL for Tablespaces. Tables. Indexes 16 .Integrity Rules LOGICAL DESIGN Tables .DATABASE DESIGN PHASES DATA ANALYSIS Entities .

Introduction to Relational Databases: RDBMS .

for data retrieval . and The operators at the user’s disposal . PROJECT. at a minimum :  The data is perceived by the user as tables ( and nothing but tables ). and those include at least SELECT. and JOIN.g..e. 18 .are operators that generate new tables  from old.Definition : RDBMS  It is a system in which.

which itself consists of tables ( called system tables ) 19 .Features of an RDBMS     The ability to create multiple relations (tables) and enter data into them An interactive query language Retrieval of information stored in more than one table Provides a Catalog or Dictionary.

Some Important Terms    Relation : a table Tuple : a row in a table Attribute : a Column in a table     Degree : number of attributes Cardinality : number of tuples Primary Key : a unique identifier for the table Domain : a pool of values from which specific attributes of specific relations draw their values 20 .

Properties of Relations (Tables)
    

There are no duplicate rows (tuples) Tuples are unordered, top to bottom Attributes are unordered, left to right All attribute values are atomic ( or scalar ) Relational databases do not allow repeating

groups
21

Keys

Key


Super Key
Candidate Keys

Primary Key
Alternate Key

Secondary Keys

22

Keys and Referential Integrity
Enrolled
sid 53666 53688 53650 53666 cid grade carnatic101 C reggae203 B topology112 A history105 B sid

Student
name login Jones@cs age 18 gpa 3.4

53666 Jones

53688 Smith
53650 Smith

Smith@eecs
Smith@math

18
19

3.2
3.8

Foreign key referring to sid of STUDENT relation

Primary key

23

24 .

Relational Algebra .

 Allows for much optimization.Relational Query Languages    Query languages: Allow manipulation and retrieval of data from a database. Query Languages != programming languages! 26 . Relational model supports simple. powerful QLs:  Strong formal foundation based on logic.

0 55.0 27 .5 35.5 35.Example Instances sid bid 101 103 day 10/10/99 11/12/99 sid sname rating age R1 22 58 S1 22 31 58 Deepa Laxmi Roopa sid 7 8 10 sname 45.0 rating age S2 28 31 44 58 Yamuna Laxmi Geeta Roopa 9 8 5 10 35.0 35.0 55.

product ( ) Set.difference ( –) Union ( ) 28 .Relational Algebra  Basic operations:      Selection ( ) Projection () Cross.

0 55. rating(S2) Roopa 10 age 35.Projection sname Yamuna Laxmi Geeta rating 9 8 5 sname.5 age(S2) 29 .

0 35.Selection sid 28 58 sname Yamuna Roopa rating 9 10 age 35. rating(S2) (rating > 8(S2)) 30 .0 rating > 8(S2) sname rating Yamuna Roopa 9 10 sname.

Set Difference sid 22 31 58 44 28 sname Deepa Laxmi Roopa Geeta Yamuna rating 7 8 10 5 9 age 45.0 .0 55.5 35.0 35.0 S1  S2 sid 31 58 sname Laxmi Roopa rating 8 10 age 55.5 35.0 35. Intersection.0 S1  S2 S1  S2 31 sid 22 sname Deepa rating 7 age 45.Union.

5 35.0 35.5 55.Cross.0 45.0 55.0 (sid) 22 58 22 58 22 58 bid 101 103 101 103 101 103 day 10/10/99 11/12/99 10/10/99 11/12/99 10/10/99 11/12/99 32 .Product (sid) 22 22 31 31 58 58 sname Deepa Deepa Laxmi Laxmi Roopa Roopa rating 7 7 8 8 10 10 age 45.

Joins Condition Join : (sid) 22 31 sname Deepa Laxmi rating 7 8 age 45.5 (sid) 22 58 bid 101 103 day 10/10/99 11/12/99 33 .0 55.

0 bid 101 103 day 10/10/99 11/12/99 34 .Equi-Join (sid) 22 58 sname Deepa Roopa rating 7 10 age 45.0 35.

but useful for expressing queries like: •Find sailors who have reserved all boats .Division •Not supported as a primitive operator. sno s1 s1 s1 s1 s2 s2 s3 s4 s4 pno p1 p2 p3 p4 p1 p2 p2 p2 p4 pno p2 B1 sno s1 s2 s3 s4 A/B1 pno p2 p4 B2 pno p1 p2 A p4 B3 sno s1 A/B3 35 sno s1 s4 A/B2 .

36 .

Introduction to Query Optimization

Processing A High-level Query
Query in a high level language SCANING, PARSING AND VALIDATING Intermediate form of query QUERY OPTIMIZER Execution plan QUERY CODE GENERATOR Code to execute the query
RUNTIME DATABASE PROCESSOR

Typical steps when processing a high level query.

Result of query

38

Heuristic Rules: A heuristic is a rule that works well in most of cases, but not always. General Idea:
Many different relational algebra expressions (and thus query trees) are equivalent.  Transform the initial query tree of a query into an equivalent final query tree that is efficient to execute.

Two Main Techniques for Query Optimization

Cost based query optimization

Estimate the cost for each execution plan, and choose the one with the lowest cost.
39

Can we get the best execution plan?

R2.r3no and R1.r2no=R2.Motivating Example select * from R1.a=5000 NLJ NLJ SS(R1. R3 where R1.r2no and R2.r3no=R3. “a=5000”) SS(R2) SS(R3) 40 .

R3 where R1. R2.Alternative Plans 1(No Indexes) select * from R1.r2no=R2. “a=5000”) SS(R2) 41 .r2no and R2.r3no and R1.a=5000 NLJ NLJ SS(R3) SS(R1.r3no=R3.

a=5000 NLJ NLJ SS(R3) IS(R1.Alternative Plans 2 (With Indexes) select * from R1.r2no=R2. R3 where R1.r3no and R1.r3no=R3.r2no and R2. R2. “a=5000”) SS(R2) 42 .

43 .

Relationship Model .Conceptual Design Using the Entity.

Overview of Database Design  Conceptual design : (ER Model is used at this stage.) Schema Refinement : (Normalization) Physical Database Design and Tuning   45 .

Formal Language for Relational D/B.E R Modeling   Conceptual Schema Design Relational Calculus . Relational Calculus Predicate Calculus SQL / Tuple Based Domain Calculus Query By Examples 46 .

Constraints . Ensures Requirements Meets the Design Logical Design Data Model Mapping – Type of Database is identified Physical Design Internal Storage Structures / Access Path / File Organizations 47 . Relationships No Implementation Details. Scenarios Conceptual Design Entity Types.Design Phases… Requirements Collection & Analysis Data Requirements Functional Requirements User Defined Operations Data Flow Diagrams Sequence Diagrams.

E-R Modeling  Entity  is anything that exists and is distinguishable  Entity Set  a group of similar entities properties that describe an entity an association between entities 48  Attribute   Relationship  .

Notations ENTITY TYPE ( REGULAR ) WEAK ENTITY TYPE RELATIONSHIP TYPE WEAK RELATIONSHIP TYPE 49 .

3666 Attishoo 231. PRIMARY KEY (ssn)) 50 .22.31. lot INTEGER.3650 Smethurst LOT 48 22 35 CREATE TABLE Employees (ssn CHAR (11).24.5368 Smiley 131. name CHAR (20).Entity Attributes ssn name lot Employee Entity Set SSN NAME 123.

51 .

ER Model ssn name lot since did dname budget Employee supervisor Works_in Subordinate Department Reports_To 52 .

since DATE. did).) Works_ In SSN DID 123-22-3666 51 123-22-3666 56 SINCE 1/1/91 3/3/93 CREATE TABLE Works_ In( ssn CHAR (11).ER Model (Contd. did INTEGER. FOREIGN KEY (did) REFERENCES Departments) 53 231-31-5368 51 2/2/92 . FOREIGN KEY (ssn) REFERENCES Employees. PRIMARY KEY (ssn.

Key Constraints ssn name lot since did dname Department budget Employee Manages 54 .

Key Constraints for Ternary Relationships ssn name lot since did dname budget Employee Works_in Department Location address capacity 55 .

Participation Constraints ssn name lot since did dname budget Employee Manages Department Works_in since 56 .

Weak Entities ssn name lot cost pname age Employee Dependent policy 57 .

ISA („is a‟) Hierarchies ssn name lot Employee Hrly_wages Hrs_worked IsA contractid Contract_Emp 58 Hourly_Emp .

Aggregation ssn name Employee monitors until lot pid pbudget Started on did dname budget project sponsors department 59 .

Entity vs. Attribute Works_ In does not allow an employee to work in a department for two or more periods (why?) ssn name lot from to did dname Department budget Employee Works_in 60 .

) ssn name lot did dname Department budget Employee Works_in from Duration to 61 . Attribute (Contd.Entity vs.

Dbudget 62 . Relationship ssn name lot since DB did dname Department budget Employee manages DB .Entity vs.

Relationship ssn name lot did dname budget Employee manages Department since Appt num Mgr_appt DBudget 63 .Entity vs.

Ternary Relationships ssn name lot pname age Employee covers Dependent Policy policyid cost 64 .Binary vs.

Binary vs. Ternary Relationships Better Design ssn name lot pname age Employee Dependent purchaser Beneficiary policyid Policy cost 65 .

Constraints Beyond the ER Model • Some constraints cannot be captured in ER diagrams: • Functional dependencies • Inclusion dependencies • General constraints 66 .

E-R Diagram DEPARTMENT 1 SUPPLIER DEPT_ EMP M EMPLOYEE 1 EMP_ DEP M DEPENDENT 1 M M PROJ_ WORK M PROJECT PROJ_ MGR M M M SUPP_ PART_ PROJ M PART M PART_ STRUC TURE M SUPP_ PART M 67 .

The following are collection from the Client. 68 .Example to Start with ….  An Example Database Application called COMPANY which serves to illustrate the ER Model concepts and their schema design.

The Company keeps track of the date that employee managing the department. no and manager who manages the department. 69 . A Department may have a Several locations. Each Department has a name.Analysis…  Company : Organized into Departments.

An Employee is assigned to one department. BirthDate. Address. Track of the number of hours per week is also controlled. Gender. Salary. Employee : Name. SSN. no and a single Location. Age. may work on several projects which are not controlled by the department.Analysis…   Department : A Department controls a number of Projects each of which has a unique name . 70 .

71 . gender. Date of birth and relationship to the employee.  Keep track of the dependents of each employee for insurance policies : We keep each dependant first name.Analysis….

Start Date ) PROJECT ( Name. Hrs)) DEPENDENT ( Employee. (Workson ( Project . Department . Number . Gender. Number. Location . Address. Manager. Name. Gender. Salary Birthdate. Controlling Department ) EMPLOYEE (Name (Fname. Relationship ) 72 .Now to our Company… DEPARTMENT ( Name . Lname) . Birthdate . { Locations } . Supervisor . SSN .

Example …  Manage:    Department and Employee Partial Participation Relation Attribute : StartDate. Department and Employee Total Participation  Works For:   73 .

Project  Partial Participation from Department  Total Participation from Project  Control Department is a RKA. Employee  Partial and Recursive  74 .   Supervisor : Employee.Example…  Control : Department .

Example …  Works – On : Project . Employee  Total Participation  Hours Worked is a RKA. Dependant  Dependant is a Weaker  Dependant is Total .  75 . Employee is Partial.   Dependants of: Employee .

Lname Fname One Possible mapping of the Problem Statement Name No Sal Sex SSN Address Work s For Department Loc Name Employee Bdate Hours Sdate Control s manage s Project Name Depend On Dependent Name Sex Bdate Loc Supe rvise s Work sOn No Relationship 76 .

77 .

78 .

79 .

80 .

Schema Refinement and Normalization .

Normalization and Normal Forms

Normalization:
Decomposing a larger, complex table into several smaller, simpler ones.  Move from a lower normal form to a higher Normal form.

Normal Forms:
First Normal Form (1NF)  Second Normal Form (2NF)  Third Normal Form (3NF)  *Higher Normal Forms (BCNF, 4NF, 5NF ....)

In practice, 3NF is often good enough.
82

Why Normal Forms

The first question to ask is whether any refinement is needed! If a relation is in a certain normal form (BCNF, 3NF etc.), it is known that certain kinds of problems are avoided/ minimized. This can be used to help us decide whether decomposing the relation will help.
83

The Evils of Redundancy

 

Redundancy is at the root of several problems associated with relational schemas More seriously, data redundancy causes several anomalies: insert, update, delete Wastage of storage. Main refinement technique: decomposition (replacing ABCD with, say, AB and BCD, or ACD and ABD).
84

Refining an ER Diagram .Before ssn name lot since did dname budget Employee Works_in Department 85 .

After ssn name since did dname budget lot Employee Works_in Department 86 .Refining an ER Diagram .

indivisible) values and that value of any attribute in a tuple must be a single value from the domain of that attribute. if every row contains exactly one value for each attribute. composite attributes and their combinations. 87  By definition. any relational table must be in 1NF. Disallow multivalued attributes.   1NF states that :  domains of attributes must include only atomic (simple.First Normal Form  A table is in 1NF. .

 88 .Functional Dependencies (FDs)  Provide a formal mechanism to express constraints between attributes Given a relation R. attribute Y of R is functionally dependent on the attribute X of R if & only if each X-value in R has associated with it precisely one Y-value in R.

Full Dependency  Concept of full functional dependency  A FD x  y is a full functional dependency if removal of any attribute A from X means that the dependency does not hold any more. 89 .

D.Partial Dependency  An F. x  y is a partial dependency if there is some attribute A  X that can be removed from X and the dependency will still hold. 90 .

31.26.24.4134 Madayan 35 H 40 30 30 32 40 R 8 8 5 5 8 R 8 8 5 5 8 W 10 10 7 7 10 H 40 30 30 32 40 R W 5 7 8 10 91 .Example: Constraints on Entity Set S N L 123.5368 Smiley 22 131.5368 Smiley 22 131.67.4134 Madayan 35 S N L 123.67.3666 Attishoo 48 231.22.3650 Smethurst 35 434.31.3666 Attishoo 48 231.26.3751 Guldu 35 612.3650 Smethurst 35 434.24.3751 Guldu 35 612.22.

Second Normal Form (2NF)  A relation schema R is in 2NF if:   it is in 1NF and every non-prime attribute A in R is fully functionally dependent on the primary key of R. 92 .  2NF prohibits partial dependencies.

but not in 2NF. Emp {Eno.2NF: An Example  Emp{Eno. ProjCode. ProjCode} {Eno} -> {Dept}. Hours} 93  Test of 2NF    Decomposition:   . ProjCode. Dept} Proj {Eno. Emp is in 1NF. Hours}   Primary key: {Eno. ProjCode} -> {Hours} {Eno} -> {Dept}: partial dependency. Dept. {Eno.

and both X  Z and Z  Y hold.Transitive Dependency  An FD X  Y in a relation schema R is a transitive dependency if  there is a set of attributes Z that is not a subset of any key of R.  94 .

3NF prohibits transitive dependencies.  3NF means that each non-key attribute value in any tuple is truly dependent on the Primary Key and not even partially on other attributes.Third Normal Form  A relation schema R is in 3NF if   It is in 2NF and No nonprime attribute of R is transitively dependent on the primary key. 95  .

{Dept} -> {Dept_Head}   Test of 3NF {Eno} -> {Dept} -> {Dept_Head}: Transitive dependency.3NF: An Example  Emp{Eno. Dept}  Dept {Dept.  Emp is in 2NF. but not in 3NF. Dept_Head}  96 .   Decomposition: Emp {Eno. Dept. Dept_Head} Primary key: {Eno}  {Eno} -> {Dept}.

3NF does not satisfactorily handle the case of a relation processing two or more composite or overlapping candidate keys 97 .Boyce –Codd Normal Form  The intention of BCNF is that.

BCNF ( Boyce Codd Normal Form)  A Relation is said to be in Boyce Codd Normal Form (BCNF) if and only if every determinant is a candidate key. 98 .

A decomposition of R consists of replacing R by two or more relations such that: Each new relation scheme contains a subset of the attributes of R (and no attributes that do not appear in R).. An..  99 . and  Every attribute of R appears as an attribute of one of the new relations.Decomposition of a Relation Scheme  Suppose that relation R contains attributes A1 .

100 .

101 .

102 .

103 .

104 .

105 .

106 .

Concurrency Control and Recovery .Transaction.

 Read. abort Atomicity. commit. write. Consistency. some actions and one end point 108 . Durability  Governed by four ACID properties:   Has a unique starting point. Isolation.Transaction  A sequence of many actions which are considered to be one atomic unit of work.

D urability: If a transaction commits. C onsistency: If each transaction is consistent. I solation: Execution of one transaction is isolated from that of other transactions.The ACID Properties     A tomicity: All actions in the transaction happen. and the DB starts consistent. or none happen. it ends up consistent. 109 . its effects persist.

 But some real world operations are not undoable. credit the other. Either both debiting and crediting operations succeed.  e. or neither of them do.g. An event either happens and is committed or fails and is rolled back. no partial results. There is no undo for these actions. fire missile 110 . debit one account. in a money transfer. a Rollback command will undo all actions taken since the last commit for that user. print ticket.Automicity    All-or-nothing. An Abort undoes operations that have already been executed  For database operations.transfer money.  Transaction failure is called Abort Commit and abort are irrevocable actions. Examples . restore the data’s previous value from before the transaction (Rollback-it).

then a serial execution of transactions does also 111 . each order references an existing customer number and existing part numbers  The books balance (debits = credits. not of the database mechanisms for controlling it (unlike the A. and D of ACID) If each transaction maintains consistency. assets = liabilities) Consistency preservation is a property of a transaction.Consistency    Every transaction should maintain DB consistency  Referential integrity .g. I.e.

 Formally. the effect of a set of transactions should be the same as if they ran independently.  Transactions can use common data (shared data)  They can use the same data processing mechanisms (time sharing) 112 .Isolation Intuitively.  Of course. to use device parallelism – this will be covered later. transactions in fact run with lots of concurrency. an interleaved execution of transactions is serializable if its effect is equivalent to a serial one.  Implies a user view where the system runs each user’s transaction stand-alone.

Implementation is usually via a log  DB system writes all transaction updates to a log file  to commit. it adds a record “commit(Ti)” to the log  when the commit record is on disk. OS. Makes it possible for a transaction to be a legal contract.  system waits for disk ack before acknowledging to 113 user . its results will survive failures (e.Durability    When a transaction commits. of the application. the transaction is committed. DB system … even of the disk).g.

Transaction processing Can be automatic (controlled by the RDBMS) or programmatic (programmed using SQL or other supported programming languages. like PL/SQL) 114 .

Why Have Concurrent Processes?    Better transaction throughput Improved response time Done via better utilization of resources:  While one processes is doing a disk read. 115 . another can be using the CPU or reading another disk.

Typical situations requiring concurrency control     Exclusive access to an external device or shared service (e.g. enforcing resource occupation.e.g. etc.g. managing printer queues) Coordination of applications which process parallel data (e. parallel DB servers) Disabling or enabling execution of the client programs in a specific moment (typically for database administration . database backups. Web access) 116 ..) Detection of transaction ends when managing multiple sessions for connection to the database (client/server architectures.

Problems with Concurrency (in absence of locking) Lost Update problem .overwriting of certain values used for calculation by write operations from other transactions  117 .discarding previous changes made by overlapping transaction after rollback  Incorrect Summary problem .losing values due to intervention of write operation from other overlapping transactions  Temporary Update problem .

Lost Update Problem Time T0 T1 Transaction A Start A Read Value (6) Value 6 6 Start B Transaction B T2 T3 T4 T5   Add 2 (6+2=8) Write Value (8) End A 6 8 9 9 Read Value (6) Add 3 (6+3=9) Write Value (9) End B What should the final Order Value be? Which Update has been lost? 118 .

Temporary Update Problem Time T0 T1 Transaction A Start A Read Value (6) Value 6 6 Transaction B T2 T3 T4 T5 T6 T5   Add 2 (8) Write Value (8) Failure: Rollback! Write Value (6) End A 6 8 8 6 11 11 Start B Read Value (8) Add 3 (8+3=11) Write Value (11) End B What should the final Order Value be? Where is the temporary update? 119 .

and which after? 120 .Incorrect Summary Problem Time T0 T1 T2 T3 T4 Transaction A Read 1st Value (6) Values 6 3 6 3 8 3 8 3 8 3 8 5 Transaction B Add 2 (6+2=8) Write 1st Value (8) Read 2nd Value (3) Add 2 (3+2 = 5) Read 1st Value (8) Read 2nd Value (3) Total Sum = 11 T5   Write 2nd Value (5) What should the total Order Value be? Which order was accumulated before update.

3.Absolute time before and after the transaction 121 . t2 .Logically consistent states of the database data TTransaction for changing the database t1. D2 .1 Database State and Changes D1.

X. It then writes a [commit. <transaction-id>] and if there are no logged entries [commit. old_value. BEGIN active END COMMIT partially committed ROLLBACK ROLLBACK aborted committed READ . <transaction-id>] and terminates. <transaction-id>. WRITE terminated When a system failure occurs.2 Transaction State and Progress A transaction reaches its commit point when all operations accessing the database are completed and the result has been recorded in the log. search the log file for entries [start. new_value] 122 .3. <transaction-id>] then undo all operations that have logged entries [write.

Schedules • Schedule: Actions of transactions as seen by the DBMS T1 R(A) W(A) T2 R(B) W(B) R(C) W(C) 123 .

Serializable Schedule  A schedule whose effect on the DB “state” is the same as that of some serial schedule All serial schedules are serializable   But the reverse may not be true 124 .

10.000 from A to B Add 6% interest to A &B T1 R(A) W(A) Database is inconsistent! T2 R(A) W(A) R(B) W(B) commit R(B) W(B) commit 125 .Serializability Violations Transfer Rs.

Cascading Aborts T1 R(A) T2 W(A) R(A) W(A) abort 126 .

Recoverable Schedules Unrecoverable Schedule Recoverable Schedule T1 R(A) T2 T1 R(A) T2 W(A) R(A) W(A) W(A) R(A) W(A) commit abort commit commit 127 .

 Generally there is a lock for each data item in the database. A transaction locks an object before using it When an object is locked by another transaction. A lock describes the status of the data item with respect to possible operations that can be applied to that item  used for synchronising the access by concurrent transactions to the database items. the requesting transaction must wait 128 . A lock is a variable associated with a data item in the database.Locking      The concept of locking data items is one of the main techniques for controlling the concurrent execution of transactions.

129 .Locking Granularity   A database item which can be locked could be  a database record  a field value of a database record  the whole database Trade-offs  coarse granularity  the larger the data item size. and the more lock/unlock operations needed. the lower the degree of concurrency  fine granularity  the smaller the data item size. the more locks to be managed and stored.

•Guarantees serializability! Compatibility matrix for lock types X and S -- S  X  S: Shared lock X: Exclusive lock -.Locking: A Technique for Concurrency Control •Locks are automatically obtained by DBMS.No lock S X    130 .

– If T wants to modify an object. – Hold all locks until end of transaction.Phase Locking (2PL) Strict 2PL: – If T wants to read an object. first obtains an S lock. and recoverable schedule. – Guarantees serializability. too! also avoids WW problems! 2PL: – Slight variant of strict 2PL – transactions can release locks before the end (commit or abort) But after releasing any lock it can acquire no new locks – Guarantees serializability 131 .Two. first obtains X lock.

Mode) Mode==X Mode==S Currently Locked? Yes Empty Wait Queue? No Yes Currently X-locked? No Put on Queue Yes No Grant Lock 132 . OID.Handling a Lock Request Lock Request (XID.

133 .

To do this. Database (DB) is restored to the most recent consistent state just before the time of failure. 134   .Recovery  Occurs in case of transaction failures. It is the system log. the DB system needs information about changes applied by various transactions.

135 .Recovery: Motivation crash T1 T2 T3 T4 T5 •Atomicity: Undoing actions of transaction that do not commit •Durability: Making sure all actions of committed transactions survive system crashes •The Recovery Manager guarantees Atomicity & Durability.

Recovery Outline  Restore to most recent “consistent” state just before time of failure  Use data in the log file  Catastrophic Failure Restore database from backup  Replay transactions from log file   Database becomes inconsistent (noncatastrophic errors)  Undo or Redo last transactions until consistent state is restored 136 .

– Minimal info (diff) written to log.Logging  Record REDO and UNDO information. in a log. – Sequential writes to log (put it on a separate disk). so multiple updates fit in a single log page. 137 . for every update.

Handling the Buffer Pool • When is buffer written back to disk? • Steal/No-steal Can it be written before commit? (steal) Or does it have to wait till after commit? (no-steal) • Force/No-force Is it written “immediately” after commit? (force) Or can it remain in memory? (no-force) NoSteal Force NoForce Trivial Desired 138 Steal .

Ahead Logging Protocol:  Must force the log record for an update before the corresponding data page gets to disk.Write.  Must write all log records for a transaction before commit .Ahead Logging (WAL)  The Write.  What goes into log:   BFIM needed for UNDO type algorithms AFIM needed for REDO type algorithms 139 .

Checkpoints in the System Log     Checkpoint record written in log when all updated DB buffers written out to disk Any committed transaction occurring before checkpoint in log can be considered permanent (won’t have to be redone after crash) Actions  suspend execution of all transactions  force-write all modified buffers to disk  write checkpoint entry in log and force write log  resume transactions Fuzzy checkpointing  resume transactions as soon as buffers written 140 .

141 .

142 .

com 143 .blogspot.com Gr8knowledge.BY : ABURAFEY AZMI Contact me on Aburafey.blogspot.com rafey111@rediffmail.

 .

  .

  .

  .

  .

  .

  .

:7703..38.43974 .4.3/#0.%7.07 .943  43.

943 806:03.9438 .9 4388903.:36:089..3/43003/5439   ..9438.0412.942.-479 4.438/070/94-0430.8.7935439 8420.943 :7.:394147 #0.3. 84.38.70 ..0730/-14:7574507908 942.-9    ./ 790 ..%7.4229 .

.43889039 9 03/8:5.941490797.38.798.97.98507889   .9430.97.5503 473430.43889039 .943839097.%0!74507908 942.38.3/9089...9.943 ..42298 98 0110.-91.43889039 84..9438 84.90/17429.5503 4388903.9438 :7.:9434143097.38..38.9438 .943.10.38..

9:807 :9842070.89.9438 708947090/.38.47/4507.3/.. 8570. 9 .8.-479.422.090..-0 .0390907.9.4:39 .4229 1479..55038.70..9  47  47 3493 345. .79.9.:942.9431..2508 .943 #4-.94389.422990/471..:0 1742-014709097.9.708:98 30..:90/ 47/...4:8.-0.3/:3/4. 0  3.:708.9438 %070834:3/4147 9080.3/8 .0..38..38107 /0-9430. #4-.0/-479 4229..70349:3/4.243097.-.70770..2508 97.94389.#4-.00/ 47 3090741902/4 %7.3/8740/-./-00300.94388:..4.381072430 57399.09 1702880  .0383..9438 3-479:3/4084507..804507.9438.70/934507.3/..70/9904907  907-49/0-93.

38.70/98 .00.-.08..4388903.9.8020. #0107039.:8942073:2-07.38.:9434197.807.3.4388903.97..793:2-078 %0-448-.84  .38..9432.4388903.3..39079 #0107039.88098 .97. .0797.94384:/2.39079 0  0.-908 4388903.3 0893.38.943  3494190/.4397439 :3090  .38.9438.9438/408.3828147.574507941.3/41 10...47/077010703.39.0 /0-98.570807.3/08935..  903...39.

:9434197.082 98-0 .9806:.070/.42243/..:807 8 97.94388 807.3:80908. .007090889027:380..9.81907.943884:/ -0908.0 900110.:7703.7.3828 9208.574.33/0503/039 472.:807...430 1.. 8. 94:80/0.943831..941.05.3:80.943 39:9.9.94389.907 %7.94389.20/.-01980110.4:780 97.38.38.20.38.0/00..38..807...03994.9.73  .339070.38.8094197.9438.3/ .43...70//.3/ 97. %0.088320...84.97:3949841 .430 2508.38.4..

4229 9.9 2502039.94394-0.97.4229 % 94904 0390..42298 98708:988:7..38.47/ .-9 03.0.98147/8.410 94.-01470.:7.97..38.//8.943...38..9438 .0895488-0147...340/394  :807 .03 4190/8 .943  $ 88902 0.4 889027908..97.70..4397.38..55.0 1. .90894.422990/ 88902..9438:8:.422970.943:5/.:708 0  4190.47/843/8 9097.

3-0. 5747.3:..22.943574.9.439740/-90#$ 47 5747.08 0 !.223.0883 .9. .220/:83$"474907 8:554790/5747.38.%7.:942.

$"  .

34907/8  .:77039!74./3 ./  .34907.088088/43.08 0430574./870.043.08808 0990797.0/70854380920 430..943417084:7..38.943974:5:9 2574....-09907:9.3-0:8390!&4770.

039.9.9.078 8./0.147 /./23897.0.38...9.80-.9.943 09.35739076:0:08 2.7.04.94341.80 ./23897.943 0  /..80..0/.850.3.3.. 0  5.9439490/..242039 95.9. 447/3.-.039 5747.309073.9438706:73 ..%5.9.37084:7.9434197.43.:7703.0/.943 /.9438.4330.89:.7.80. 090. 5.:9434190.:5.088 5.0 0  2.-...3 2:9508088438147.08894.55.-.0478.574.43974 .283.3..70/ 807.1.7..-.:58  03147.-34703.0807.-300.94303/8032.:8.

07..9:708 0-.088  .807.7..90.

.-803.55397.9$:22.7/3 570...90574-02 /8.7&5/.7&5/.7574-02 3..38.07.:08/:094 3907.90574-02 %02547.943.9438 %02547.94317424907 4.079.!74-028943.4770..07./0-4.03943417904507.38.90574-02 489&5/.:08:80/147.3082.943-7904507.:7703.. 3.38.:..0779341 ..9438 1742490797...9$:22.3 .9438  .7574-02 4.190774-.0 414.553 97.4770. 3.4:8.3 489&5/.90574-02 483.

90!74-02 '4 ' ' ' ' ' ' '9.5:.489&5/..9.0.3  51 .8-003489  ..90..:0-0 . %.65 &.65 .3  11   9.984:/9013.9. 7/07'.1.5:.1.3  51 '9.3  11   9. %.0.&5/.3       &..

5:. 7/07'.9.3  .65 &.3  11  9..39%633/..3  51 '9.5:.7:5/..3         &..90!74-02 '4 ' ' ' ' ' ' ' ' '9.90  .3  11   9.0.02 9. %. %.65 .%02547.1.0.7&5/.9..:0-0 070890902547.984:/9013.1.3  51 .

9$:22.90 .:.7!74-02 '4 ' ' ' ' ' ' '9. .51 .3  %.1 51..0.3.3:             %... 7/07'.1 :.65 11   9.3  '6.90/-01470:5/.3  %.:2:.8.984:/90949.3&4 '9. .:0-0 .5:.1 :. .0.4770.5:. .1 51.3/.3  .3  11   9.3  .1907  .65 %.47/07.

3/.90 $9.308 9 9 $9.-.9.80$9.90 %  . .90.

. '..5..1..:6..:. 60.:1.33065::./..

5:.. . '9./.0.: ..55..65690.1.

9..9.51.0..5:.4/69. /:63..65  .

9438 9.908  .4507.4229 97.422990/ #  #  90723..:70 4.943$9.38.-.9438.47/0/3904 9903 7908.9.90/  % .70.38...79 97.:0 30*.425090/ ..943 /( .38..4229 97.0898.80..7. %7. 4507..79.3/19070.3/90708:9..040/039708 790 97.38.422990/ #  #% .889021.90..088390/.94370..42295439 03.3/!747088 97.-4790/ 03..0  5.:0(  .943 /( .943 /  4/*.:78 80..703440/039708..38.9.9.3/90723.38.90410147039708 89.8-00370. ...943 /( 903:3/4.

9438 ..8 8003 - 90 $ % #  % #  #   .0/:08 W $.0/:0 .9438 41 97.38.$.

$07.9418420807.0/:0 807.20.8.0/:04800110.-0$.94390 89.8.90 8 908.07802.0/:0 8..0/:08.349-097:0  .70807.-0 :99070.89..

-..808 3.9.4229  .9438 %7.-9'4.$07.4229 #  .38107 #8   174294 // 390708994  % #  .43889039 % #  #  .

/3-4798 % #  % #  ..8..-479  .

0/:08 &370.07.-0$.4.-0$.07.07.4.4229  .-479 #  .4229 .0/:0 #0.4.-0$.4229 .#0.0/:0 % #  % % #  % #  .

94389..3490797.9902 :80/14783.9.38.902970850..4.9  .3 %0.43.90/9.4.9434.8.994 5488-04507.:7703900..902390/.9.34-0.0/-.43.059414.38.80  0307.550/949.9.-..9:84190/.9.9432:89.9....7..902390/.34-0.884.-.390.943 90706:0893 97./.7438390./08.8.3-0.:9434197.088-.9.7-089089.43.9438 9490/.38.43974390.-0.9..984.9.90708.36:08 147.38.9028843041902..:7703997.-.80 4../..38.9438 4.809028 97.1470.9-01470:839 03.3/.

3:.0790/.90280 9024704.70790/.7807.894-0 2./0 4118 ././..3/89470/ .9.79 /.4.79 90.43.:7703.-.37.0/.4.:041..80 %7.47/ ..9.9.3:..9.9.79 9082.8070.-.10/.8070.4:/-0 . 1307.3-04.80902.3:.-.3/9024704.3.90280 9040790/070041 .47/ 9040/.0/./0 %7.9.-.

9438300/0/  . 4507.:34.

70/4.3/$ $  b b b $ b b  b $$.:7703.9-92.4-9.. 44.36:0147 43.:8.30/-$ W:.3%0. .7.04.70.39008807.8.:942.9.43974 W4..971474.  .4.-9 425.9508.

0/:0 944 .-9  ..38.07. 1%.3.%4 %4 !.7.-08.804.34..6:7034304.8:3903/4197.3 ! $97.8 :.9.1907700.3/70.943 :..4.34-0..9 17894-9..84..3700. 4/.7.9438.39008807.7.9! 1%.39008807..38.9! 97.422947 .-479 :9..384.3$4.804.3941897.3989424/1.9 17894-9.83.34-0./.38..8-014709003/ .-9 .3989470.4/8574-028 ! $9.4.

  .0/ 4 08 !:943":0:0 4 7.#06:089 4.#06:089    4/0 4/0 4/0$ :770394.3/3.4.394..9":0:0 08 :77039 :77039 4.0/ 08 4 259.

 .

.07 .550/- ..039.:783.4.38.308.9438 9890889024  .9431..943.90:89-0147090920 411.80  87089470/94902489 70..74:897.74:897.4388903989..9..#0.38.9438 9890889024 .804197.38..:70 %4/498 9088902300/8 31472.:708 ..-.-4:9.

943 ..9 /4 349 .38:70.943841..7.07 :.07 .7..#0.38.088902.9438 41 97.-9.7.422990/ 97.8 % % % % % W942.4.94388:7.-9  ....39008 942..4229 W:7.3.0749.808 W%0 #0.9 &3/43 .943 9.9 :7.38.4.

4.9.97.390410 ..-.97.039 .9.077478 &3/447#0/4..9.4388903989.9087089470/  .38.9.38.43889039 343 343 .-.943817424 10 ..07 :930 #08947094248970.89745.390410 &80/.9.42083.90 :89-01470920411.:70 #089470/.43889039 89.38.:5 #05.8997..:70 &80/.#0.801742-...9.89745.9438:39 .943817424 #05.80-0.

4 $06:039.3/& 31472.90 3.314 /11 79903944 842:950 :5/.7.47/# .83045.43 #0.943 147 0.90/8 32.07:5/.908193.0  .7908944 5:9943.805.

.3/390:1107!44 W 03 8 -:1107 79903 -. 94 /8 W $90...

9 9 .3 9 -0 79903 -01470 . W 47..4229 34 890. 7 /408 9 .0 94 .4229 890.4 890.1907 . .0.

3 3 20247 34 147.0 447. 0870/  $90..90 .1907 .3 9 702.. .0 4$90. 47.0 %7.4229 147.0 8 9 79903 220/.4 147.0 7 .

94083944 300/0/147& 950.4229 .47708543/3/.90-0147090 .5.47928  ./43!7494.9.090470.4 :89147.47/147.943-01470 .47/8147..3:5/.38.97.47928 300/0/147# 950./43  790 %0790 %0790 0.790 0.009894/8 :89790.470.

.0 790.8 .38.:94341.7.:773-01470.3/147.9438.54398390$89024 0.5439 34.88443.24/10/-:110789 147.0.97.38.24/10/-:1107894/8 790..90/ -:11078799034:994/8 3.54393 708:2097.0...0.38.438/070/5072.094-0 70/430.3039 43 9.:5/.422990/97.5439039734.9434.1907.0.3-0..9438 147.543970.38.0 790...8-:1107879903  .07904 708:2097.9438 8:8503/00.47/799033403.9438 :.

 .

 .

 . &# 439..92043 -:7.1070/112.10 -48549 .42 7340/0 -48549 .42  .42 7.

Sign up to vote on this title
UsefulNot useful