Dynamic restrictions have to deal with state transitions of data. We can distinguish insert and update restrictions.

**Insert restrictions**

This kind of restrictions only applies to the moment an insertion is executed. For example, the amount of an invoice line has to calculated using the actual article price. Later updates of an article price may not affect the value of invoiceline its amount:

*type* invoiceline = invoice, article, number, amount.

*init* invoiceline its amount = number * article its price.

Another solution for the same consistency problem applies both a dynamic and a static constraint and can be applied if we redefine invoice line by adding invoice line its article_price:

*type* invoiceline = invoice, article, article_price, number.

*init* invoiceline its article_price = article its price.

*assert* invoiceline its amount = number * article_price.

If it frequently occurs that the number of articles per invoice line is one then the following default command can fasten data insertions by assuming 1 as the number of articles:

*init default* invoiceline its number = 1.

It is also possible to specify conditional restrictions. For example, we could apply a price reduction percentage (of course we first have to add the attribute invoiceline its reduction to the model):

*init* invoiceline its reduction = if number < 10 then 0

else if number < 100 then 10

else 20.

After extending the definition of invoiceline with the attribute reduced_price, a DBMS can calculate this reduced price at insertion time, using:

*init* invoiceline its reduced_price = (100 Ã¢â¬â reduction) * article its price / 100.

*init* invoiceline its amount = number * reduced price.

Another possibility is to apply reductions to distinct articles instead of the previous one related to the number of sold articles:

*init* invoiceline its reduction = case article of

1234: 10;

7538: 15;

default: 0.

**Update restrictions**

This kind of dynamic restrictions has to deal with the modification of attribute values. An example is related to the following data model related to the registration of the phase of practical work of students for a course. During time the phase of practical work in some organization may only change from not started to busy followed by finished or not finished:

*type* student = name, address, town, birth_date, faculty.

*type* course = subject, lecturer.

*base* phase (A20) = not started, busy, not finished, finished.

*type* practical = student, course, organization, phase.

*init default* practical its phase = not started.

*check* practical its phase = case of

not started: busy,

busy: finished,

busy: not finished.

**Delete restrictions**

Since we cannot compare the state of a data item before its deletion with the empty state after that deletion, explicit delete restrictions make no sense. Of course this does not mean that a deletion is always allowed: a deletion conflicting with referential integrity may not be executed.

For further examples we refer to the books of Johan ter Bekke.