Operational semantics of transactions(9)

Mathematics is forcing towards a consistent framework of theory development. Computer Science is an engineering discipline and sometimes suffers from ad-hoc definitions. Transactions are a concept that is commonly used in the database area. It is often def

only observable in centralized environments.In dis-tributed environments,the in place setting requires sophisticated monitoring.

The states of transactions pictured in Figure4are specified as follows:

CreateOwnDB:

CurrentDB(Self,*):=undef

Transfer4Write(Self,*):=undef

LogDB(Self,*):=undef

This rule uses an explicit LogDB for recording the actions of the transaction.

PrepareMergeDB:

//do nothing here

MergeOwnDB:

//do nothing here

FreeOwnDB:

FOR ALL x∈(σT A=t(LogDB))[Location] DO StableDB(x):=LogDB(Self,x)

LogDB(Self,x):=undef

ENDDO

CurrentDB(Self,loc):=StableDB(loc) WriteOwnDB(where:Location,val:Value): WriteOwnDB()

IF LogDB(Self,loc)=undef

THEN LogDB(Self,loc):=StableDB(loc)

ENDIF

StableDB(loc):=CurrentDB(Self,loc)

Transfer4Write(t,loc):=CurrentDB(t,loc)

We obtain the equality:OwnDB=StableDB.

All activities performed are directly written to the StableDB.If the transactions abort these writes must be compensated by an undo action.All writes must be recorded in the LogDB.We use the LogDB only for a write performed by one transaction.If history of writes must be recorded the treatment of LogDB must be more sophisticated.

The integrity constraint control becomes simpler since the StableDB must be checked without consid-eration of other ASM states.

The undo action is simple as long as only one write to the LogDB is allowed.If we must record a history then monitoring or locking approaches can be used.

The next three rules are very simple since they change only the state of the transaction. Proposition4If the run of transactions t1,...,t k is applicable then the transition by the transactions t1,...,t k in the in-place setting is atomic and consis-tent.

Proposition5Durability is preserved for transac-tions in the in-place setting.

Isolation can be based on similar techniques that have already been discussed in section2.4.4Towards an Understanding of Constraint Enforcement Used in SQL’99

Integrity enforcement becomes more complex if trans-actions are considered.SQL’99(SQL1999)has intro-duced a rather confusing treatment.

SQL’99constraints can be coupled with integrity en-forcement policy in a large variety:

Checking mode:The integrity enforcement can be deferred until the end of transactions

or can be forced to an immediate control

directly at the moment a change in the

database appears.

Choice of statement or row level:The granularity of enforcement can be at the row level or at

the statement level.If row level is chosen

each modification(insert,delete or update)

of object forces application of integrity con-

trol.

Constraints may be pre-or post-conditions:

Constraints may be checked before or after

a statement or a modification is executed.

Scope conditions for reference columns allow to disable or enable the application of referen-

tial integrity constraints.

Matching conditions soften the satisfaction of ref-erential integrity constraints.The equalities

to be checked can be partially fulfilled.

Reference types are based on tuple(or object) identifiers and can be used instead of for-

eign key values.

Triggers are based on the event-condition-action paradigm of rules depending on events performed

on a class.Events are modification actions exe-

cuted on the database.Triggers have a number

of variations:

Number of triggers per events and events per trigger: Triggers can be based on exactly one or

several events.Events can be attached to

one or several triggers.

Activation time of triggers can be before or af-ter appearance of the event specified for the

trigger.Further,activation conditions may

be defined.

Conflict resolution of execution order of triggers may be based on different policies.

Order of constraint check differs.DB2checksfirst key and unique constraints,second referential con-

straints and then check constraints.Sybase,Or-

acle and Informix controlfirst check constraints,

then key constraints and last referential con-

straints.Ingres and MS SQL checkfirst keys

and uniqueness,then check constraints and last

referential constraints.

SQL’92declarative constraints are not null conditions, key conditions,check conditions,foreign key

constraints,uniqueness conditions,domain con-

straints and assertions.Although they have not

yet been completely implemented by DBMS they

are kept in the standard for SQL’99.It should

be noted,however,that the SQL’99standard

did not restrict to one semantics for these con-

straints.

This large variety must be understandable with trans-action models.We feel the urgent need for sophisti-cated transaction models with an operational seman-tics which helps in understanding which model has to be chosen in which case for which integrity constraint enforcement policy.The models proposed above en-able us in defining an operational semantics and in reasoning on the effects of the choices made by the application programmer.