Datasheet

that the DBMS is unaware of whether rows are “checked out” at any given time, which makes it impos-

sible to implement pessimistic concurrency control. There are, however, ways in which optimistic con-

currency control can be implemented, as you will see later in the book.

Transactions

It is often essential to perform multiple database operations together, in particular where it is vital that

all operations succeed. In these cases, it is necessary to use a transaction, which comprises a set of opera-

tions. If any individual operation in the transaction fails, all operations in the transaction fail. In transac-

tion terminology, the transaction is committed if, and only if, every operation succeeds. If any operations

fail, the transaction is rolled back — which also means that the result of any operation that has already

succeeded is rolled back.

For example, imagine you have a database with a table representing a list of bank accounts and balances.

Transferring an amount from one account to another involves subtracting an amount from one account

and adding it to another (with perhaps a three-day delay if you are a bank). These two operations must

be part of a transaction because if one succeeds and one fails, then money is either lost or appears from

nowhere. Using a transaction guarantees that the total of the money in the accounts remains unchanged.

There are four tenets of transactions that must be adhered for them to perform successfully; they can be

remembered with the acronym ACID:

❑ Atomicity: This refers to the preceding description of a transaction: that either every operation

in a transaction is committed, or none of them are.

❑ Consistency: The database must be in a legal state both before the transaction begins and after

it completes. A legal state is one in which all the rules enforced by the database are adhered to

correctly. For example, if the database is configured not to allow foreign key references to non-

existent rows, then the transaction cannot result in a situation where this would be the case.

❑ Isolation: During the processing of a transaction, no other queries can be allowed to see the

transient data. Only after the transaction is committed should the changes be visible.

❑ Durability: After a transaction is committed, the database should not be allowed to revert to the

state it was in before the transaction started. For example, any data added should not subse-

quently be removed, and any data removed should not suddenly reappear.

For the most part, you are unlikely to come across a DBMS that violates these rules, so it isn’t something

that you need to worry about. Transaction support in the .NET Framework is also good, and this is

something you’ll be looking at later in the book.

Remote Access

A good DBMS allows remote access across an intranet and, if required, the Internet. Again, this is some-

thing that most databases permit, although some configuration (of both the DBMS and firewalls) may be

necessary. It is not, however, always the best option, especially when communicating with a database

across the Internet.

Later in the book you’ll see how an intermediary (specifically, a web service) can be used to control

remote access.

Database Fundamentals

44063c01.qxd:WroxBeg 9/12/06 10:31 PM Page 13