DBMS Fundamentals

DBMS Fundamentals

Dr. E.Grace Mary KanagaAssociate Professor / CSE

Karunya University

17-09-2014 Database Management Systems - Placement Training

Agenda

• Introduction• DDL• DML• DCL• TCL• ER Design• Normalization


Introduction


Data Facts and statistics collected together for reference or analysis

DatabaseIt is an organized collection of data that is organized so that it can easily be accessed, managed, and updated

Database SystemsDatabase system is a system to achieve an organized, store a large number of dynamical associated data, facilitate for multi-user accessing to computer hardware, software and data, that it is a computer system with database technology

Introduction


Database Management Systems• They are specially designed software applications

that interact with the user, other applications, and the database itself to capture and analyse data.

• A general-purpose DBMS is a software system designed to allow the definition, creation, querying, update, and administration of databases.

Data Model• It is a specification describing how a database is

structured and used

Data Model - Types


• Flat model: This may not strictly qualify as a data model..

• Hierarchical model: In this model data is organized into a tree-like structure

• Network model: This model organizes data using two fundamental constructs, called records and sets.

• Relational model: is a database model based on first-order predicate logic.

Database Management Systems • MySQL• MariaDB• PostgreSQL• SQLite• Microsoft SQL

Server• Microsoft Access• Oracle• IBM DB2

• SAP• HANA• dBASE,• LibreOffice Base• FileMaker Pro• InterSystems Caché• FoxPro


Database Objects

Object DescriptionTable Basic unit of storage; composed of rows

and columns

View Logically represents subsets of data from one or more tables

Sequence Numeric value generator

Index Improves the performance of some queries

Synonym Gives alternative names to objects


DDL- Data Definition Language

Statement Description

CREATE TABLE Creates a table

ALTER TABLE Modifies table structures

DROP TABLE Removes the rows and table structure

RENAME Changes the name of a table, view, sequence, or synonym

TRUNCATE Removes all rows from a table and releases the storage space

COMMENT Adds comments to a table or view


Naming Rules

Table names and column names:• Must begin with a letter• Must be 1–30 characters long• Must contain only A–Z, a–z, 0–9, _, $,

and #• Must not duplicate the name of another

object owned by the same user• Must not be an Oracle server reserved

word17-09-2014 Database Management Systems -

Placement Training

The CREATE TABLE Statement

• You must have:– CREATE TABLE privilege– A storage area

• You specify:– Table name– Column name, column data type, and

column size

CREATE TABLE [schema.]table (column datatype [DEFAULT expr][, ...]);


Tables in the Oracle Database

• User Tables:– Are a collection of tables created and

maintained by the user– Contain user information

• Data Dictionary:– Is a collection of tables created and

maintained by the Oracle Server– Contain database information


Data TypesData Type Description

VARCHAR2(size) Variable-length character data

CHAR(size) Fixed-length character data

NUMBER(p,s) Variable-length numeric data

DATE Date and time values

LONG Variable-length character data up to 2 gigabytes

CLOB Character data up to 4 gigabytesRAW and LONG RAW Raw binary data

BLOB Binary data up to 4 gigabytes

BFILE Binary data stored in an external file; up to 4 gigabytes

ROWID A 64 base number system representing the unique address of a row in its table.


DML COMMANDS


• The acronym DML represents Data Manipulation Language

• Data Manipulation Language (DML) statements are used to define the data in the database

• The Data Manipulation Language (DML) is used to retrieve, insert and modify database information.

• These commands will be used by all database users during the routine operation of the database

– INSERT– SELECT– UPDATE– DELETE

DML:• Insert

The INSERT command in SQL is used to add records to an existing table. Syntax:INSERT INTO table name(field name1 data type, field name2 data type ……. field name n data type);

EXAMPLESQL> insert into stud1(st_name,st_num,st_dob,sub1,sub2,tot) values

('&st_name',&st_num,&st_dob,&sub1,&sub2,&tot);

SQL> /Enter value for st_name: charlesEnter value for st_num: 1Enter value for st_dob: '20 may 2000'Enter value for sub1: 90Enter value for sub2: 80Enter value for tot: 170


http://databases.about.com/library/glossary/bldef-record.htm

http://databases.about.com/library/glossary/bldef-table.htm

• Update The UPDATE command can be used to modify

information contained within a table, either in bulk or individually.

Syntax1.UPDATE tablename SET fieldname=new value;2. UPDATE table name SET fieldname=new value where

condition;EXAMPLEupdate emp1 set emp_sal = emp_sal + 500 where

emp_bpay > 5000;


DELETE :• To delete data from the database.

DELETE [FROM] table[WHERE condition];

SELECT:• To retrieve the data from the database.

SELECT *|{[DISTINCT] column|expression [alias],...}FROM table;SELECT *|{[DISTINCT] column|expression [alias],...}FROM table[WHERE condition(s)];A where clause is used to restrict the rows returned.


The select Clause


• The select clause list the attributes desired in the result of a query– corresponds to the projection operation of the relational

algebra• Example: find the names of all branches in the loan

relation:select branch_namefrom loan

• In the relational algebra, the query would be: branch_name (loan)

• NOTE: SQL names are case insensitive (i.e., you may use upper- or lower-case letters.) – E.g. Branch_Name ≡ BRANCH_NAME ≡ branch_name– Some people use upper case wherever we use bold font.

The select Clause (Cont.)


• SQL allows duplicates in relations as well as in query results.

• To force the elimination of duplicates, insert the keyword distinct after select.

• Find the names of all branches in the loan relations, and remove duplicates

select distinct branch_namefrom loan

• The keyword all specifies that duplicates not be removed.

select all branch_namefrom loan

The select Clause (Cont.)


• An asterisk in the select clause denotes “all attributes”

select *from loan

• The select clause can contain arithmetic expressions involving the operation, +, –, , and /, and operating on constants or attributes of tuples.

• E.g.: select loan_number, branch_name, from loan

The where Clause


• The where clause specifies conditions that the result must satisfy– Corresponds to the selection predicate of the relational

algebra. • To find all loan number for loans made at the

Perryridge branch with loan amounts greater than $1200.

select loan_numberfrom loanwhere branch_name = 'Perryridge' and

amount > 1200• Comparison results can be combined using the

logical connectives and, or, and not.

The from Clause


• The from clause lists the relations involved in the query– Corresponds to the Cartesian product operation of the

relational algebra.• Find the Cartesian product borrower X loan

select from borrower, loan

Find the name, loan number and loan amount of all customers having a loan at the Perryridge branch.

select customer_name, borrower.loan_number, amount from borrower, loan where borrower.loan_number = loan.loan_number and branch_name = 'Perryridge'

The Rename Operation


• SQL allows renaming relations and attributes using the as clause:

old-name as new-name• E.g. Find the name, loan number and loan

amount of all customers; rename the column name loan_number as loan_id.

select customer_name, borrower.loan_number as loan_id, amountfrom borrower, loanwhere borrower.loan_number = loan.loan_number

String Operations


• SQL includes a string-matching operator for comparisons on character strings. The operator “like” uses patterns that are described using two special characters:

– percent (%). The % character matches any substring.– underscore (_). The _ character matches any character.

• Find the names of all customers whose street includes the substring “Main”.

select customer_namefrom customerwhere customer_street like '% Main%'

• Match the name “Main%”like 'Main\%' escape '\'

• SQL supports a variety of string operations such as– concatenation (using “||”)– converting from upper to lower case (and vice versa)– finding string length, extracting substrings, etc.

Ordering the Display of Tuples


• List in alphabetic order the names of all customers having a loan in Perryridge branch

select distinct customer_namefrom borrower, loanwhere borrower loan_number =

loan.loan_number and branch_name = 'Perryridge' order by customer_name

• We may specify desc for descending order or asc for ascending order, for each attribute; ascending order is the default.– Example: order by customer_name desc

Set Operations


• Find all customers who have a loan, an account, or both:

(select customer_name from depositor)except(select customer_name from borrower)

(select customer_name from depositor)intersect(select customer_name from borrower)

Find all customers who have an account but no loan.

(select customer_name from depositor)union(select customer_name from borrower)

Find all customers who have both a loan and an account.

DCL

• Grant• Revoke


TCL

• Save Point • Roll Back• Commit


• This is the process which allows you to winnow out redundant data within your database.

• This involves restructuring the tables to successively meeting higher forms of Normalization.

• A properly normalized database should have the following characteristics– Scalar values in each fields– Absence of redundancy.– Minimal use of null values.– Minimal loss of information.

Normalization


• Levels of normalization based on the amount of redundancy in the database.

• Various levels of normalization are:– First Normal Form (1NF)– Second Normal Form (2NF)– Third Normal Form (3NF)– Boyce-Codd Normal Form (BCNF)– Fourth Normal Form (4NF)– Fifth Normal Form (5NF)– Domain Key Normal Form (DKNF)

Levels of Normalization

Redundancy

Num

ber o

f Tab

les

Most databases should be 3NF or BCNF in order to avoid the database anomalies.

Com

plex

ity


Levels of Normalization

Each higher level is a subset of the lower level

DKNF

1NF

2NF3NF

4NF

5NF


A table is considered to be in 1NF if all the fields contain

only scalar values (as opposed to list of values). Example (Not 1NF)

First Normal Form (1NF)

Author and AuPhone columns are not scalar

0-321-32132-1 Balloon Sleepy, Snoopy, Grumpy

321-321-1111, 232-234-1234, 665-235-6532

Small House 714-000-0000 $34.00

0-55-123456-9 Main Street Jones, Smith

123-333-3333, 654-223-3455

Small House 714-000-0000 $22.95

0-123-45678-0 Ulysses Joyce 666-666-6666 Alpha Press 999-999-9999 $34.00

1-22-233700-0 Visual Basic

Roman 444-444-4444 Big House 123-456-7890 $25.00

ISBN Title AuName AuPhone PubName PubPhone Price


1. Place all items that appear in the repeating group in a new table

2. Designate a primary key for each new table produced.

3. Duplicate in the new table the primary key of the table from which the repeating group was extracted or vice versa.

Example (1NF)

1NF - Decomposition

0-321-32132-1 Balloon Small House 714-000-0000 $34.00

0-55-123456-9 Main Street Small House 714-000-0000 $22.95

0-123-45678-0 Ulysses Alpha Press 999-999-9999 $34.00


Big House 123-456-7890 $25.00

ISBN Title PubName PubPhone Price

ISBN AuName AuPhone

0-123-45678-0 Joyce 666-666-6666

1-22-233700-0 Roman 444-444-4444

0-55-123456-9 Smith 654-223-3455

0-55-123456-9 Jones 123-333-3333

0-321-32132-1 Grumpy 665-235-6532

0-321-32132-1 Snoopy 232-234-1234

0-321-32132-1 Sleepy 321-321-1111


1. If one set of attributes in a table determines another set of attributes in the table, then the second set of attributes is said to be functionally dependent on the first set of attributes.

Example 1

Functional Dependencies

0-321-32132-1 Balloon $34.00

0-55-123456-9 Main Street $22.95

0-123-45678-0 Ulysses $34.00


$25.00

ISBN Title Price Table Scheme: {ISBN, Title, Price}Functional Dependencies: {ISBN}

{Title} {ISBN}

{Price}


Example 2

Functional Dependencies

1 Big House 999-999-9999

2 Small House 123-456-7890

3 Alpha Press 111-111-1111

PubID PubName PubPhone Table Scheme: {PubID, PubName, PubPhone}

Functional Dependencies: {PubId} {PubPhone}

{PubId} {PubName}

{PubName, PubPhone} {PubID}

AuID AuName AuPhone

6 Joyce 666-666-6666

7 Roman 444-444-4444

5 Smith 654-223-3455

4 Jones 123-333-3333

3 Grumpy 665-235-6532

2 Snoopy 232-234-1234

1 Sleepy 321-321-1111

Example 3

Table Scheme: {AuID, AuName, AuPhone}Functional Dependencies: {AuId}

{AuPhone} {AuId}

{AuName} {AuName, AuPhone}

{AuID}17-09-2014 Database Management Systems -

Placement Training

FD – ExampleDatabase to track reviews of papers submitted to an academic conference. Prospective authors submit papers for review and possible acceptance in the published conference proceedings. Details of the entities

– Author information includes a unique author number, a name, a mailing address, and a unique (optional) email address.

– Paper information includes the primary author, the paper number, the title, the abstract, and review status (pending, accepted,rejected)

– Reviewer information includes the reviewer number, the name, the mailing address, and a unique (optional) email address

– A completed review includes the reviewer number, the date, the paper number, comments to the authors, comments to the program chairperson, and ratings (overall, originality, correctness, style, clarity)


FD – ExampleFunctional Dependencies

– AuthNo AuthName, AuthEmail, AuthAddress

– AuthEmail AuthNo– PaperNo Primary-AuthNo, Title, Abstract,

Status– RevNo RevName, RevEmail, RevAddress– RevEmail RevNo– RevNo, PaperNo AuthComm, Prog-Comm,

Date, Rating1, Rating2, Rating3, Rating4, Rating5


For a table to be in 2NF, there are two requirements– The database is in first normal form – All nonkey attributes in the table must be functionally

dependent on the entire primary keyNote: Remember that we are dealing with non-key attributes

Example 1 (Not 2NF) Scheme {Title, PubId, AuId, Price, AuAddress}

1. Key {Title, PubId, AuId}2. {Title, PubId, AuID} {Price}3. {AuID} {AuAddress}4. AuAddress does not belong to a key5. AuAddress functionally depends on AuId which is a

subset of a key

Second Normal Form (2NF)


Example 2 (Not 2NF) Scheme {City, Street, HouseNumber, HouseColor, CityPopulation}

1. key {City, Street, HouseNumber}2. {City, Street, HouseNumber} {HouseColor}3. {City} {CityPopulation} 4. CityPopulation does not belong to any key.5. CityPopulation is functionally dependent on the City which is a

proper subset of the key

Example 3 (Not 2NF) Scheme {studio, movie, budget, studio_city}

1. Key {studio, movie}2. {studio, movie} {budget}3. {studio} {studio_city}4. studio_city is not a part of a key 5. studio_city functionally depends on studio which is a proper subset

of the key

Second Normal Form (2NF)


1. If a data item is fully functionally dependent on only a part of the primary key, move that data item and that part of the primary key to a new table.

2. If other data items are functionally dependent on the same part of the key, place them in the new table also

3. Make the partial primary key copied from the original table the primary key for the new table. Place all items that appear in the repeating group in a new table

Example 1 (Convert to 2NF) Old Scheme {Title, PubId, AuId, Price, AuAddress}New Scheme {Title, PubId, AuId, Price}New Scheme {AuId, AuAddress}

2NF - Decomposition


Example 2 (Convert to 2NF) Old Scheme {Studio, Movie, Budget, StudioCity}New Scheme {Movie, Studio, Budget}New Scheme {Studio, City}

Example 3 (Convert to 2NF) Old Scheme {City, Street, HouseNumber, HouseColor,

CityPopulation}New Scheme {City, Street, HouseNumber, HouseColor}New Scheme {City, CityPopulation}

2NF - Decomposition


This form dictates that all non-key attributes of a table must be functionally dependent on a candidate key i.e. there can be no interdependencies among non-key attributes.

For a table to be in 3NF, there are two requirements– The table should be second normal form– No attribute is transitively dependent on the primary key

Example (Not in 3NF)Scheme {Title, PubID, PageCount, Price }

1. Key {Title, PubId}2. {Title, PubId} {PageCount}3. {PageCount} {Price}4. Both Price and PageCount depend on a key hence 2NF5. Transitively {Title, PubID} {Price} hence not in 3NF

Third Normal Form (3NF)


Example 2 (Not in 3NF) Scheme {Studio, StudioCity, CityTemp}

1. Primary Key {Studio}2. {Studio} {StudioCity}3. {StudioCity} {CityTemp}4. {Studio} {CityTemp}5. Both StudioCity and CityTemp depend on the entire key hence

2NF6. CityTemp transitively depends on Studio hence violates 3NF

Example 3 (Not in 3NF) Scheme {BuildingID, Contractor, Fee}

1. Primary Key {BuildingID}2. {BuildingID} {Contractor}3. {Contractor} {Fee} 4. {BuildingID} {Fee}5. Fee transitively depends on the BuildingID6. Both Contractor and Fee depend on the entire key hence 2NF

Third Normal Form (3NF)

BuildingID

Contractor Fee

100 Randolph

1200150 Ingersoll 1100200 Randolp

h120

0250 Pitkin 1100300 Randolp

h120

0


1. Move all items involved in transitive dependencies to a new entity.

2. Identify a primary key for the new entity.3. Place the primary key for the new entity as a foreign

key on the original entity.

Example 1 (Convert to 3NF) Old Scheme {Title, PubID, PageCount, Price }New Scheme {PubID, PageCount, Price}New Scheme {Title, PubID, PageCount}

3NF - Decomposition


Example 2 (Convert to 3NF) Old Scheme {Studio, StudioCity, CityTemp}New Scheme {Studio, StudioCity}New Scheme {StudioCity, CityTemp}

Example 3 (Convert to 3NF) Old Scheme {BuildingID, Contractor, Fee}New Scheme {BuildingID, Contractor}New Scheme {Contractor, Fee}

3NF - Decomposition

BuildingID

Contractor

100 Randolph150 Ingersoll

200 Randolph250 Pitkin

300 Randolph

Contractor Fee

Randolph

1200Ingersoll 1100Pitkin 1100


• BCNF does not allow dependencies between attributes that belong to candidate keys.

• BCNF is a refinement of the third normal form in which it drops the restriction of a non-key attribute from the 3rd normal form.

• Third normal form and BCNF are not same if the following conditions are true:– The table has two or more candidate keys– At least two of the candidate keys are composed of more than one attribute– The keys are not disjoint i.e. The composite candidate keys share some attributes

Example 1 - Address (Not in BCNF)Scheme {City, Street, ZipCode }

1. Key1 {City, Street }2. Key2 {ZipCode, Street}3. No non-key attribute hence 3NF4. {City, Street} {ZipCode}5. {ZipCode} {City}6. Dependency between attributes belonging to a key

Boyce-Codd Normal Form (BCNF)


Example 2 - Movie (Not in BCNF)Scheme {MovieTitle, MovieID, PersonName, Role, Payment }

1. Key1 {MovieTitle, PersonName}2. Key2 {MovieID, PersonName}3. Both role and payment functionally depend on both candidate keys

thus 3NF4. {MovieID} {MovieTitle}5. Dependency between MovieID & MovieTitle Violates BCNF

Example 3 - Consulting (Not in BCNF)Scheme {Client, Problem, Consultant}

1. Key1 {Client, Problem}2. Key2 {Client, Consultant} 3. No non-key attribute hence 3NF4. {Client, Problem} {Consultant}5. {Client, Consultant} {Problem}6. Dependency between attributess belonging to keys violates BCNF

Boyce Codd Normal Form (BCNF)


1. Place the two candidate primary keys in separate entities

2. Place each of the remaining data items in one of the resulting entities according to its dependency on the primary key.

Example 1 (Convert to BCNF) Old Scheme {City, Street, ZipCode }New Scheme1 {ZipCode, Street}New Scheme2 {City, Street}

• Loss of relation {ZipCode} {City}Alternate New Scheme1 {ZipCode, Street }Alternate New Scheme2 {ZipCode, City}

BCNF - Decomposition


1. If decomposition does not cause any loss of information it is called a lossless decomposition.

2. If a decomposition does not cause any dependencies to be lost it is called a dependency-preserving decomposition.

3. Any table scheme can be decomposed in a lossless way into a collection of smaller schemas that are in BCNF form. However the dependency preservation is not guaranteed.

4. Any table can be decomposed in a lossless way into 3rd normal form that also preserves the dependencies.• 3NF may be better than BCNF in some cases

Decomposition – Loss of Information

Use your own judgment when decomposing schemas


Example 2 (Convert to BCNF) Old Scheme {MovieTitle, MovieID, PersonName, Role, Payment }New Scheme {MovieID, PersonName, Role, Payment}New Scheme {MovieTitle, PersonName}

• Loss of relation {MovieID} {MovieTitle}New Scheme {MovieID, PersonName, Role, Payment}New Scheme {MovieID, MovieTitle}

• We got the {MovieID} {MovieTitle} relationship back

Example 3 (Convert to BCNF)Old Scheme {Client, Problem, Consultant}New Scheme {Client, Consultant}New Scheme {Client, Problem}

BCNF - Decomposition


• Fourth normal form eliminates independent many-to-one relationships between columns.

• To be in Fourth Normal Form, – a relation must first be in Boyce-Codd Normal Form. – a given relation may not contain more than one multi-

valued attribute.

Example (Not in 4NF)Scheme {MovieName, ScreeningCity, Genre)Primary Key: {MovieName, ScreeningCity, Genre)1. All columns are a part of the only candidate key, hence

BCNF2. Many Movies can have the same Genre 3. Many Cities can have the same movie4. Violates 4NF

Fourth Normal Form (4NF)

Movie ScreeningCity

GenreHard Code Los Angles ComedyHard Code New York Comedy

Bill Durham Santa Cruz Drama

Bill Durham Durham Drama

The Code Warrier

New York Horror17-09-2014 Database Management Systems - Placement Training

Example 2 (Not in 4NF) Scheme {Manager, Child, Employee}

1. Primary Key {Manager, Child, Employee}2. Each manager can have more than one child 3. Each manager can supervise more than one employee4. 4NF Violated

Example 3 (Not in 4NF) Scheme {Employee, Skill, ForeignLanguage}

1. Primary Key {Employee, Skill, Language }2. Each employee can speak multiple languages3. Each employee can have multiple skills4. Thus violates 4NF

Fourth Normal Form (4NF) Manager Child

EmployeeJim Beth Alice

Mary Bob JaneMary NULL Adam

Employee

Skill Language1234 Cooking French

1234 Cooking German1453 Carpentr

ySpanish

1453 Cooking Spanish2345 Cooking Spanish


1. Move the two multi-valued relations to separate tables2. Identify a primary key for each of the new entity.

Example 1 (Convert to 3NF) Old Scheme {MovieName, ScreeningCity, Genre}New Scheme {MovieName, ScreeningCity}New Scheme {MovieName, Genre}

4NF - Decomposition

Movie GenreHard Code ComedyBill Durham Drama

The Code Warrier

Horror

Movie ScreeningCityHard Code Los Angles

Hard Code New York

Bill Durham Santa Cruz

Bill Durham Durham

The Code Warrier

New York


Example 2 (Convert to 4NF) Old Scheme {Manager, Child, Employee}New Scheme {Manager, Child}New Scheme {Manager, Employee}

Example 3 (Convert to 4NF)Old Scheme {Employee, Skill, ForeignLanguage}New Scheme {Employee, Skill}New Scheme {Employee, ForeignLanguage}

4NF - DecompositionManager Child

Jim Beth

Mary Bob

Manager EmployeeJim Alice

Mary JaneMary Adam

Employee

Language1234 French

1234 German1453 Spanish

2345 Spanish

Employee

Skill1234 Cooking1453 Carpentr

y1453 Cooking2345 Cooking


• Fifth normal form is satisfied when all tables are broken into as many tables as possible in order to avoid redundancy. Once it is in fifth normal form it cannot be broken into smaller relations without changing the facts or the meaning.

Fifth Normal Form (5NF)


• The relation is in DKNF when there can be no insertion or deletion anomalies in the database.

Domain Key Normal Form (DKNF)


Transaction

• The term transaction refers to a collection of operations that form a single logical unit of work.

• Logical unit of database processing that includes one or more access operations (read -retrieval, write - insert or update, delete).Eg., Transfer of money from one account to another is a transaction consisting of two updates, one to each account.

• Transaction consists of all operations executed between the begin transaction and end transaction.


Transaction - Example

E.g. transaction to transfer ₹ 50 from account A to account B:

Ti:1. read(A)2. A := A – 503. write(A)4. read(B)5. B := B + 506. write(B)

Granularity of data - a field, a record , or a whole disk block (Concepts are independent of granularity)


Two Basic Operations of Transaction Processing


Properties of transaction


ACID Properties

• AtomicityEnsures whether all actions of the

transaction are done or incase of failure, partially done transactions will be undone.

• Consistency Execution of a transaction in isolation

preserves the consistency of the database.


ACID Properties(cont…)

• IsolationIsolate the transaction from the effect

of other concurrent executing transaction.• Durability

Once a transaction is successfully executed, its effect must persist in the database


Transaction States


Transaction States


Active – the initial state; the transaction stays in this state while it is executing

Partially committed – after the final statement has been executed.

Failed -- after the discovery that normal execution can no longer proceed.

Aborted – after the transaction has been rolled back and the database restored to its state prior to the start of the transaction. Two options after it has been aborted:restart the transaction

can be done only if no internal logical errorkill the transaction

Committed – after successful completion.

Concurrent Executions


Multiple transactions are allowed to run concurrently in the system. Advantages are:increased processor and disk utilization, leading to

better transaction throughputE.g. one transaction can be using the CPU while another is

reading from or writing to the diskreduced average response time for transactions: short

transactions need not wait behind long ones.Concurrency control schemes – mechanisms to

achieve isolation that is, to control the interaction among the

concurrent transactions in order to prevent them from destroying the consistency of the database

Schedules


Schedule – a sequences of instructions that specify the chronological order in which instructions of concurrent transactions are executed

When transactions are executing concurrently in an interleaved fashion, the order of execution of operations from the various transactions forms what is known as a transaction schedule (or history).

A transaction that successfully completes its execution will have a commit instructions as the last statement

A transaction that fails to successfully complete its execution will have an abort instruction as the last statement

Schedule 1


Let T1 transfer ₹ 50 from A to B, and T2 transfer 10% of the balance from A to B.

A serial schedule in which T1 is followed by T2 :

Schedule 2


A serial schedule where T2 is followed by T1

Schedule 3


Let T1 and T2 be the transactions defined previously. The following schedule is not a serial schedule, but it is equivalent to Schedule 1.

In Schedules 1, 2 and 3, the sum A + B is preserved.

Schedule 4


The following concurrent schedule does not preserve the value of (A + B ).

Serializability


Basic Assumption – Each transaction preserves database consistency.

Thus serial execution of a set of transactions preserves database consistency.

A (possibly concurrent) schedule is serializable if it is equivalent to a serial schedule. Different forms of schedule equivalence give rise to the notions of:1. conflict serializability2. view serializability

Simplified view of transactionsWe ignore operations other than read and write instructionsWe assume that transactions may perform arbitrary computations on

data in local buffers in between reads and writes. Our simplified schedules consist of only read and write instructions.

Conflicting Instructions


• Instructions li and lj of transactions Ti and Tj respectively, conflict if and only if there exists some item Q accessed by both li and lj, and at least one of these instructions wrote Q. 1. li = read(Q), lj = read(Q). li and lj don’t conflict. 2. li = read(Q), lj = write(Q). They conflict. 3. li = write(Q), lj = read(Q). They conflict 4. li = write(Q), lj = write(Q). They conflict

• Intuitively, a conflict between li and lj forces a (logical) temporal order between them. – If li and lj are consecutive in a schedule and they do not conflict,

their results would remain the same even if they had been interchanged in the schedule.

Conflict Serializability

• If a schedule S can be transformed into a schedule S´ by a series of swaps of non-conflicting instructions, we say that S and S´ are conflict equivalent.

• We say that a schedule S is conflict serializable if it is conflict equivalent to a serial schedule


Conflict Serializability (Cont.)


• Schedule 3 can be transformed into Schedule 6, a serial schedule where T2 follows T1, by series of swaps of non-conflicting instructions.

– Therefore Schedule 3 is conflict serializable.

Schedule 3 Schedule 6

View Serializability


Let S and S´ be two schedules with the same set of transactions. S and S´ are view equivalent if the following three conditions are met, for each data item Q,

1. If in schedule S, transaction Ti reads the initial value of Q, then in schedule S’ also transaction Ti must read the initial value of Q.

2. If in schedule S transaction Ti executes read(Q), and that value was produced by transaction Tj (if any), then in schedule S’ also transaction Ti must read the value of Q that was produced by the same write(Q) operation of transaction Tj .

3. The transaction (if any) that performs the final write(Q) operation in schedule S must also perform the final write(Q) operation in schedule S’.

As can be seen, view equivalence is also based purely on reads and writes alone.

View Serializability (Cont.)


A schedule S is view serializable if it is view equivalent to a serial schedule.

Every conflict serializable schedule is also view serializable.

Below is a schedule which is view-serializable but not conflict serializable.

Every view serializable schedule that is not conflict serializable has blind writes.

Concurrency Control

Need for Concurrency Control • The Lost Update Problem

– This occurs when two transactions that access the same database items have their operations interleaved in a way that makes the value of some database item incorrect.

• The Temporary Update (or Dirty Read) Problem – This occurs when one transaction updates a database

item and then the transaction fails for some reason – The updated item is accessed by another transaction

before it is changed back to its original value.


Concurrency Control

• The Incorrect Summary Problem– If one transaction is calculating an

aggregate summary function on a number of records while other transactions are updating some of these records, the aggregate function may calculate some values before they are updated and others after they are updated.


Concurrency Control


A database must provide a mechanism that will ensure that all possible schedules are either conflict or view serializable, and are recoverable and preferably cascadeless

A policy in which only one transaction can execute at a time generates serial schedules, but provides a poor degree of concurrency

Testing a schedule for serializability after it has executed is a little too late!

Goal – to develop concurrency control protocols that will assure serializability.

Levels of Consistency in SQL

Serializable — defaultRepeatable read — only committed records to

be read, repeated reads of same record must return same value. However, a transaction may not be serializable – it may find some records inserted by a transaction but not find others.

Read committed — only committed records can be read, but successive reads of record may return different (but committed) values.

Read uncommitted — even uncommitted records may be read.


THANK YOU


DBMS Fundamentals

Documents

Transcript of DBMS Fundamentals