software vtesting

1. Database Management
Systems -20ISE43A

2. TEXT BOOKS:
1. Abraham Silberschatz, Henry F. Korth, S. Sudharshan,
“Database System Concepts”, Sixth Edition, Tata McGraw
Hill, 2013.
2. Ramez Elmasri, Shamkant B. Navathe, “Fundamentals
of Database S y s t e m s” , Sixth Edition, Pearson /
Addison - Wesley, 7th Edition 2017
REFERENCES:
1. Raghu Ramakrishnan, “Database Management
Systems”, Third Edition, McGraw Hill, 2013.

3. MODULE 1-Introduction: Introduction, An example, Characteristics of
Database Approach. Database Applications: Need for data
management, Advantages of using DBMS approach. Data models &
Database Architecture: Data models, schemas and instances, Three-
schema architecture and data independence, Centralized and client-
server architectures.
MODULE 2-ER Diagrams: Entity Types, Entity Sets, Attributes and Keys,
Relationship types, Roles and Structural Constraints, Weak Entity Types,
ER Diagrams.
MODULE 3-Relational Model: ER to Relational Mapping, Constraints,
Keys Dependencies. Functional Dependencies: Normalization First,
Second, Third & Fourth Normal Forms, BCNF.

4. MODULE 4-Relational Algebra: Update Operations, Unary Relational
Operations: SELECT and PROJECT, Relational Algebra Operations from
Set Theory, Binary Relational Operations: JOIN and DIVISION;
Additional Relational Operations; Examples of Queries in Relational
Algebra; Relational Database Design Using ER- to-Relational Mapping.
MODULE 5-Advanced SQL & Transaction Management : Embedded
& Dynamic SQL , Stored procedures, More complex SQL Queries,
Transaction concepts, Transaction state, Implementation of Atomicity
& Durability, Concurrent executions, Seializability

5. CO1
Understand the database concepts, different database models, and
database management systems and design database schema
CO2
Develop the ER structures for real world examples using the concept
of Entity Relationship models with constraints and cardinalities.
CO3
Understand the concepts of Normalization and design database
which possess no anomalies.
CO4
Apply the concepts of relational database theory to manage
relational database management system.
CO5
Apply the concepts of triggers, embedded and dynamic SQL.
CO6
Implement database applications in SQL.

6. Engineered for Tomorrow
Advanced SQL & Transaction Management :
Embedded & Dynamic SQL , Stored procedures, More complex SQL
Queries, Transaction concepts, Transaction state, Implementation of
Atomicity & Durability, Concurrent executions, Seializability

7. Embedded SQL

11. Cursors

18. Dynamic SQL

19. Static (embedded) SQL:
1.In static SQL how database will be accessed is predetermined in the
embedded SQL statement.
2.It is more swift and efficient.
3.SQL statements are compiled at compile time.
4.Parsing, validation, optimization, and generation of application plan
are done at compile time.
5.It is generally used for situations where data is distributed
uniformly.
6.EXECUTE IMMEDIATE, EXECUTE and PREPARE statements are not
used.

20. Dynamic (interactive) SQL:
1.In dynamic SQL, how database will be accessed is determined at run
time.
2.It is less swift and efficient.
3.SQL statements are compiled at run time.
4.Parsing, validation, optimization, and generation of application plan
are done at run time.
5.It is generally used for situations where data is distributed non-
uniformly.
6.EXECUTE IMMEDIATE, EXECUTE and PREPARE statements are used.
7.It is more flexible.

21. Database Stored Procedures and Functions
• The machine where the program is executing is different from the machine on
which the database server— and the main part of the DBMS software package—is
located. Although this is suitable for many applications, it is sometimes useful to
create database program modules—procedures or functions— that are stored and
executed by the DBMS at the database server.
• These are historically known as database stored procedures, although they can be
functions or procedures.
• The term used in the SQL standard for stored procedures is persistent stored
modules because these programs are stored persistently by the DBMS, similarly to
the persistent data stored by the DBMS.

22. Stored procedures are useful in the following circumstances:
• If a database program is needed by several applications, it can be
stored at the server and invoked by any of the application
programs. This reduces duplication of effort and improves
software modularity.
• Executing a program at the server can reduce data transfer and
communication cost between the client and server in certain
situations.
• These procedures can enhance the modeling power provided by
views by allowing more complex types of derived data to be made
available to the database users.
• Additionally, they can be used to check for complex constraints
that are beyond the specification power of assertions and triggers.

23. In general, many commercial DBMSs allow stored procedures and functions to be
written in a general purpose programming language.
Alternatively, a stored procedure can be made of simple SQL commands such as
retrievals and updates. The general form of declaring stored procedures is as follows:
The parameters and local declarations are optional, and are specified only if needed. For
declaring a function, a return type is necessary, so the declaration form is

24. If the procedure (or function) is written in a general-purpose programming language, it is
typical to specify the language as well as a file name where the program code is stored. For
example, the following format can be used:
• In general, each parameter should have a parameter type that is one of the
SQL data types. Each parameter should also have a parameter mode, which is
one of IN, OUT, or INOUT.
• These correspond to parameters whose values are input only, output
(returned) only, or both input and output, respectively.
• Because the procedures and functions are stored persistently by the DBMS, it
should be possible to call them from the various SQL interfaces and
programming techniques.
• The CALL statement in the SQL standard can be used to invoke a stored
procedure—either from an interactive interface or from embedded SQL or
SQLJ.
• The format of the statement is as follows:

25. Transaction States
A transaction is a unit of program execution that accesses and possibly updates
various data items.

33. Seializability
Serializable Schedule
A serial schedule is always a serializable schedule because
any transaction only starts its execution when another
transaction has already completed its execution. However, a
non-serial schedule of transactions needs to be checked for
Serializability.
Note: If a schedule of concurrent ‘n' transactions can be
converted into an equivalent serial schedule. Then we can
say that the schedule is serializable. And this property is
known as serializability.

34. Testing of Serializability
To test the serializability of a schedule, we can use the
serialization graph.
Suppose, a schedule S. For schedule S, construct a graph
called as a precedence graph. It has a pair G = (V, E), where E
consists of a set of edges, and V consists of a set of vertices.
The set of vertices contain all the transactions participating
in the S schedule. The set of edges contains all edges Ti ->Tj
for which one of the following three conditions satisfy:
Create a node Ti -> Tj if Ti transaction executes write (Q)
before Tj transaction executes read (Q).
Create a node Ti -> Tj if Ti transaction executes read (Q)
before Tj transaction executes write (Q).
Create a node Ti -> Tj if Ti transaction executes write (Q)
before Tj transaction executes write (Q).

35. Schedule S:

36. If a precedence graph for any schedule contains a
cycle, then that schedule is non-serializable. If the
precedence graph has no cycle, then the schedule is
serializable.
So, schedule S is serializable (i.e., serial schedule)
because the precedence graph has no cycle

37. Precedence graph of Schedule S1

40. Types of Serializability
Conflict Serializability
View Serializability

41. Conflicting operations
The two operations are called conflicting operations, if all
the following three conditions are satisfied:
Both the operation belongs to separate transactions.
Both works on the same data item.
At least one of them contains one write operation.
Note: Conflict pairs for the same data item are:
Read-Write
Write-Write
Write-Read
Conflict Equivalent Schedule
Two schedules are called as a conflict equivalent schedule if
one schedule can be transformed into another schedule by
swapping non-conflicting operations.

42. Example of conflict serializability:

43. After all the steps, the precedence graph will be ready, and it
does not contain any cycle or loop, so the above schedule S2
is conflict serializable. And it is equivalent to a serial
schedule.

44. PL/SQL - Basic Syntax
PL/SQL which is a block-structured language; this means that the PL/SQL programs are divided
and written in logical blocks of code. Each block consists of three sub-parts −

45. Every PL/SQL statement ends with a semicolon (;). PL/SQL blocks can be
nested within other PL/SQL blocks using BEGIN and END. Following is
the basic structure of a PL/SQL block −

46. 1
2
3
4
5
6
7
8
9
10
11
Declare
Var1 integer;
Var2 integer;
Var3 integer;
Begin
Var1:=&var1;
Var2:=&var2;
Var3:=var1+var2;
Dbms_output.put_line(var3);
End;
/
PL/SQL Program To Add Two Numbers

47. View Serializability In DBMS
• If a schedule is view equivalent to a serial schedule, then it
will be view serializable
• If the schedule is serializable via conflict, then it shall be
view serializable as well.
• The view serializable which has no conflict serializable has
blind writes.
View Equivalent
Schedules S1 and schedule S2 will; be view equivalent if the
following conditions are satisfied:

48. View Equivalent
Two schedules S1 and S2 are said to be view equivalent if
they satisfy the following conditions:
1. Initial Read
An initial read of both schedules must be the same. Suppose
two schedule S1 and S2. In schedule S1, if a transaction T1 is
reading the data item A, then in S2, transaction T1 should
also read A.
Above two schedules are view equivalent because Initial read operation
in S1 is done by T1 and in S2 it is also done by T1.

49. 2. Updated Read
In schedule S1, if Ti is reading A which is updated by Tj then in S2 also,
Ti should read A which is updated by Tj
Above two schedules are not view equal because, in S1, T3 is
reading A updated by T2 and in S2, T3 is reading A updated
by T1.

50. 3. Final Write
A final write must be the same between both the schedules. In
schedule S1, if a transaction T1 updates A at last then in S2, final
writes operations should also be done by T1.
Above two schedules is view equal because Final
write operation in S1 is done by T3 and in S2, the
final write operation is also done by T3

52. Schedule S1
First step: Last update of the data items
No need of checking that condition as there isn’t any read in
s and S1 except initial read
Second step: Initial read
T1 does the initial read in S as well as S1
Third step: Final write
T3 does the final write task in S and S1. Therefore, S1 and S
are view equivalent.
S1 meets all the conditions, and so there is no need of
checking any other schedule.
Therefore, the view equivalent schedule is
T1-T2-T3

53. shadow-copy database scheme and db_pointer with an
example(Implementation of Atomicity and Durability).
• This is the method where all the transactions are
executed in the primary memory or the shadow copy of
database. Once all the transactions completely
executed, it will be updated to the database.
• Hence, if there is any failure in the middle of
transaction, it will not be reflected in the database.
• Database will be updated after all the transaction is
complete

56. To understand concept, consider above figure. In this 2 write
operations are performed on page 3 and 5. Before start of
write operation on page 3, current page table points to old
page 3. When write operation starts following steps are
performed :
• Firstly, search start for available free block in disk blocks.
• After finding free block, it copies page 3 to free block
which is represented by Page 3 (New).
• Now current page table points to Page 3 (New) on disk
but shadow page table points to old page 3 because it is
not modified.
• The changes are now propagated to Page 3 (New) which is
pointed by current page table.

57. COMMIT Operation:
To commit transaction following steps should be done :
• All the modifications which are done by transaction which
are present in buffers are transferred to physical
database.
• Output current page table to disk.
• Disk address of current page table output to fixed
location which is in stable storage containing address of
shadow page table. This operation overwrites address of
old shadow page table. With this current page table
becomes same as shadow page table and transaction is
committed.

58. • A database pointer will be always pointing to the consistent copy of
the database, and copy of the database is used by transactions to
update. Once all the transactions are complete, the DB pointer is
modified to point to new copy of DB, and old copy is deleted.
• If there is any failure during the transaction, the pointer will be still
pointing to old copy of database, and shadow database will be
deleted. If the transactions are complete then the pointer is changed
to point to shadow DB, and old DB is deleted.
• DB pointer is always pointing to consistent and stable database. This
mechanism assumes that there will not be any disk failure and only
one transaction executing at a time so that the shadow DB can hold
the data for that transaction.
• It is useful if the DB is comparatively small because shadow DB
consumes same memory space as the actual DB.
• Hence it is not efficient for huge DBs. In addition, it cannot
handle concurrent execution of transactions. It is suitable for one
transaction at a time.

60. Advantages of concurrent execution of a transaction
Decrease waiting time or turnaround time.
Improve response time
Increased throughput or resource utilization.
Concurrency problems
Several problems can occur when concurrent transactions are
run in an uncontrolled manner, such type of problems is
known as concurrency problems.
1. Lost update problem (Write – Write conflict)
2. Dirty read problem (W-R conflict)
3. Unrepeatable read (R-W Conflict)

61. 1. Lost update problem (Write – Write conflict)
This type of problem occurs when two transactions in database access
the same data item and have their operations in an interleaved
manner that makes the value of some database item incorrect.
If there are two transactions T1 and T2 accessing the same data item
value and then update it, then the second record overwrites the first
record.

62. • Here,
• At t1 time, T1 transaction reads the value of A i.e., 100.
• At t2 time, T1 transaction deducts the value of A by 50.
• At t3 time, T2 transactions read the value of A i.e., 100.
• At t4 time, T2 transaction adds the value of A by 150.
• At t5 time, T1 transaction writes the value of A data item
on the basis of value seen at time t2 i.e., 50.
• At t6 time, T2 transaction writes the value of A based on
value seen at time t4 i.e., 150.
• So at time T6, the update of Transaction T1 is lost
because Transaction T2 overwrites the value of A without
looking at its current value.
• Such type of problem is known as the Lost Update
Problem

63. Dirty read problem (W-R conflict)
This type of problem occurs when one transaction T1
updates a data item of the database, and then that
transaction fails due to some reason, but its updates are
accessed by some other transaction.
Example: Let's take the value of A is 100

64. • Here,
• At t1 time, T1 transaction reads the value of A i.e., 100.
• At t2 time, T1 transaction adds the value of A by 20.
• At t3 time, T1transaction writes the value of A (120) in the
database.
• At t4 time, T2 transactions read the value of A data item i.e., 120.
• At t5 time, T2 transaction adds the value of A data item by 30.
• At t6 time, T2transaction writes the value of A (150) in the
database.
• At t7 time, a T1 transaction fails due to power failure then it is
rollback according to atomicity property of transaction (either all or
none).
• So, transaction T2 at t4 time contains a value which has not been
committed in the database. The value read by the transaction T2 is
known as a dirty read.

65. Unrepeatable read (R-W Conflict)
It is also known as an inconsistent retrieval problem. If a transaction
T1 reads a value of data item twice and the data item is changed by
another transaction T2 in between the two read operation. Hence
T1 access two different values for its two read operation of the same
data item.
Example: Let's take the value of A is 100

66. • At t1 time, T1 transaction reads the value of A i.e., 100.
• At t2 time, T2transaction reads the value of A i.e., 100.
• At t3 time, T2 transaction adds the value of A data item
by 30.
• At t4 time, T2 transaction writes the value of A (130) in
the database.
• Transaction T2 updates the value of A. Thus, when
another read statement is performed by transaction T1,
it accesses the new value of A, which was updated by T2.
Such type of conflict is known as R-W conflict.

67. Consider the following transactions with data items P and
Q initialized to zero:
T1: read(P);
read(Q);
If P=0 then Q:=Q+1;
write(Q);
T2: read(Q);
read(P);
If Q=0 then P:=P+1;
write(P);
Evaluate any non-serial interleaving of T1 and T2 for
concurrent execution leads to a serializable schedule or
non serializable schedule. Justify the answer?