Static restrictions are restrictions that apply allways. These are defined as assertions.

An assertion specifies a derivable attribute or a derivable single variable, possibly some value restriction, and the calculation of the derivable item(s). An example is that in many organizations there is only one manager per department:

assert department its managercount (1..1) = count employee where function = manager per department.

If an organization wants to guard that the number of employees is not more than 100, the following assertion using a single variable can be specified:

assert maxemployees (0..100) = count employee.

Such assertions can be the basis of active databases. For example a consequence of the first assertion is that each insertion of a new instance of department also requires the insertion of an instance of employee with the function manager within the same transaction. Similar inferable consequences are related to deleting manager data or changing the function of a manager or changing the department of a manager.

Another application of assertions is maintaining the correctness or consistency of derivable data. For example, the total amount of an invoice can be derived from the amounts of the involved invoice lines. Derivable attributes are shown between slashes. e.g. /attribute name/ :

type invoice = customer, date.

type invoice line = invoice, article, number, amount.

type article = description, price.

assert invoice its amount = total invoice line its amount per invoice.

Now the invoice type has become:

type invoice = customer, date, /amount/.

The last assertion is triggered automatically by the following events and must be followed by actions restoring the data consistency:

event: insert invoice line.
action: invoice its amount := invoice its amount + invoice line its amount.

event: delete invoice line.
action: invoice its amount := invoice its amount - invoice line its amount.

event: update invoice line amout value.
action: invoice its amount := invoice its amount -
             invoice line its amount (old) + invoice line its amount (new).

Apparently the semantic solution for static restrictions is based on controlled redundancy. However, it would not make sense to apply the following assertion:

assert invoice line its amount = number * article its price.

The reason is that the price of articles must be changeable in the future without affecting data on historical transactions. The dynamic restrictions section offers solutions for this problem.

Apparently the semantic approach makes a clear distinction between inherent (structural) constraints and explicit static constraints. In the relational approach there is not such a clear distinction between these two kinds of restrictions. See for example the following relational assertion overlapping with the earlier shown sub set constraint for a foreign key in CREATE TABLE employee:

CREATE ASSERTION emp_ref 
CHECK (NOT EXISTS (SELECT dept#
                     FROM employee
                    WHERE dept# NOT IN (SELECT dept# FROM department)));

However, this opens the possibility to specify the same restriction in two different ways or even to specify an assertion conflicting with an already specified sub set constraint! Such possible overlapping specifications create problems for system builders and could lead to a performance decrease for relational systems as well.