4/2/2014 Structured Query Language/Print version - Wikibooks, open books for an open world

-- occurred since last COMMIT or ROLLBACK

ROLLBACK WORK; -- reverts all previous INSERT, UPDATE and DELETE commands, which
-- occurred since last COMMIT or ROLLBACK

The keyword 'WORK' is optional.

AUTOCOMMIT
The feature AUTOCOMMIT automatically performs a COMMIT after every write operation (INSERT, UPDATE or DELETE). This feature is not part of the
SQL standard, but is implemented and activated by default in some implementations. If we want to use the ROLLBACK command, we must deactivate the
AUTOCOMMIT. (After an - automatic or explicit - COMMIT command a ROLLBACK command is syntactically okay, but it does nothing as everything is
already committed.) Often we can deactivate the AUTOCOMMIT with a separate command like 'SET autocommit = 0;' or 'SET autocommit off;' or by clicking
an icon on a GUI.

To test the following statements it is neccessary to work without AUTOCOMMIT.

COMMIT
Let us insert a new person into the database and test the COMMIT.

-- Store a new person with id 99.

INSERT INTO person (id, firstname, lastname, date_of_birth, place_of_birth, ssn, weight)
VALUES (99, 'Harriet', 'Flint', DATE'1970-10-19', 'Dallas', '078-05-1120', 65);

-- Is the new person really in the database? The process who executes the write operation will see its results,
-- even if they are actually not committed. (One hit expected.)
SELECT *
FROM person
WHERE id = 99;

-- Try COMMIT command

COMMIT;

-- Is she still in the database? (One hit expected.)

SELECT *
FROM person
WHERE id = 99;

Now we remove the person from the database.

-- Remove the new person

DELETE
FROM person
WHERE id = 99;

-- Is the person really gone away? Again, the process who performs the write operation will see the changes, even
-- if they are actually not committed. (No hit expected.)
SELECT *
FROM person
WHERE id = 99;

-- Try COMMIT command

COMMIT;

-- Is the person still in the database? (No hit expected.)

SELECT *
FROM person
WHERE id = 99;

So far, so boring.

ROLLBACK
The exciting command is the ROLLBACK. It restores changes of previous INSERT, UPDATE or DELETE commands.

We delete and restore Mrs. Hamilton from our example database.

DELETE
FROM person
WHERE id = 3; -- Lisa Hamilton

-- no hit expected
SELECT *
FROM person

http://en.wikibooks.org/wiki/Structured_Query_Language/Print_version 25/110
4/2/2014 Structured Query Language/Print version - Wikibooks, open books for an open world
WHERE id = 3;

-- ROLLBACK restores the deletion

ROLLBACK;

-- ONE hit expected !!! Else: check AUTOCOMMIT

SELECT *
FROM person
WHERE id = 3;

The ROLLBACK is not restricted to one single row. It may affect several rows, several commands, different kind of commands and even several tables.

-- same as above
DELETE
FROM person
WHERE id = 3;
-- destroy all e-mail adresses
UPDATE contact
SET contact_value = 'unknown'
WHERE contact_type = 'email';

-- verify modifications
SELECT * FROM person;
SELECT * FROM contact;

-- A single ROLLBACK command restores the deletion in one table and the modifications in another table
ROLLBACK;

-- verify ROLLBACK
SELECT * FROM person;
SELECT * FROM contact;

Exercises
Supose the hobby table contains 9 rows and the person table 10 rows. We execute the following operations:
add 3 hobbies
add 4 persons
commit
add 5 hobbies
add 6 persons
rollback

Whow many rows are in the hobby table?

Click to see solution

12

Whow many rows are in the person table?

Click to see solution

14

Structured Query Language/INSERT Structured Query Language/UPDATE Structured Query Language/DELETE

Daily Operations

Data should be stored in a way, that no redundant information exists in the database. If more than one person indulge a hobby, for example, we avoid storing
information about hobbies (designation, remarks, ...) within each affected persons row as this would double the hobbies information. And we avoid storing
information about persons (name, ssn, ...) within each affected hobby row for the same reason. Instead we create independent person and hobby tables and point
from one to the other. This technic of grouping data items redundancy-free into separate tables is called database normalization. As a result, information about
complex objects is scattered across multiple tables. And we need a opportunity to reassemble the whole, original situation. This reverse technic is called a 'JOIN
operation'.

The Idea
In our example database there are the two tables person and contact. The contact table contains the column person_id, which correlates with the Primary Key
column id of the person table. By evaluating the column values we can join contacts and persons together.

http://en.wikibooks.org/wiki/Structured_Query_Language/Print_version 26/110