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          else if number          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.