Tutorial — EXPRESS Language Foundation

Abstract entity

The abstract entity was introduced in EXPRESS Edition 2, as an ENTITY that can only be instantiated via its SUBTYPEs.

It has to be instantiated (e.g., appear in a Part 21 file) via a SUBTYPE in which the specific type of each attribute is specified.

ENTITY general_approval ABSTRACT;
  approved_items : SET OF GENERIC_ENTITY;
  status         : approval_status;
END_ENTITY;

The model here says that a general_approval has a status which is of type approval_status (whatever that is), and approved_items (which is a SET of (unnamed) ENTITY).

An instantiable SUBTYPE would have to replace GENERIC_ENTITY by a named entity, say plan (whatever that might be), to have a set of approved plans.

Note that:

GENERIC_ENTITY stands for any ENTITY
All attributes must have specific types before instantiation is possible.
An attribute type can be re-declared to a more specific kind in a SUBTYPE

IS-A relationship

The database world talks about IS-A relationships, for instance,

THIS IS-A THAT, or
A CAR IS-A (kind of) VEHICLE.

In EXPRESS:

a SUBTYPE IS-A (more special kind of its) SUPERTYPE(s);
a SUPERTYPE IS-A (more general kind of its) SUBTYPE(s).

EXPRESS supports the IS-A relationship via subtyping.

For example, Entities S1, S2, … can be declared to be SUBTYPES of entity E. This also effectively declares E to be a SUPERTYPE of S1, S2, etc.

That is, S1 is-a E, S2 is-a E, etc. Also, E may-be an S1, E may-be an S2.

An entity may be both a SUB- and a SUPERTYPE.
An entity may be a SUBTYPE of more than one entity.
SUPER/SUBTYPING may be used for many purposes.

SUBTYPEs

The ‘meaning’ of SUBTYPE:

A Subtype is a specialization of its Supertype(s).
New attributes may be added.
New constraints may be added.
Attributes may be ‘retyped’ (i.e their domains may be specialized in a compatible manner).

The following example includes examples of the last 3 elements in the list.

Example 1. Example showing attribute re-declaration, adding attributes and constraints

ENTITY circle;
  radius : NUMBER;
  center : point;
END_ENTITY;

ENTITY specialised_circle
  SUBTYPE OF (circle);
  SELF\circle.radius : REAL;    -- retyped
  shade  : colour; -- additional attribute
WHERE
  SELF\circle.radius > 3.0; -- add constraint
END_ENTITY;

This example shows:

Attribute re-declaration
Adding attribute(s)
Adding constraint(s)

Inheritance

A SUBTYPE is a special kind of its SUPERTYPE(s). There are fewer instances of a SUBTYPE than of its SUPERTYPE. For example, there are fewer CARS than there are VEHICLES.

A SUBTYPE inherits all the attributes and constraints of its SUPERTYPE(s).

A SUBTYPE can have additional attributes and constraints.

Example 2. Example of using SUBTYPE to replace WHERE rule

Given the original information model:

ENTITY person;
  first_name : STRING;
  last_name  : STRING;
  nickname   : OPTIONAL STRING;
  ss_no      : INTEGER;
  gender     : sex;
  spouse     : OPTIONAL person;
  children   : SET [0:?] OF person;
UNIQUE
  un1 : ss_no;
WHERE
  w1 : (EXISTS(spouse) AND
        gender <> spouse.gender)
       OR NOT EXISTS(spouse);
END_ENTITY;

This following revised person model eliminates the original WHERE rule about spouses being of opposite sex. We can also talk about a person without having to identify the person’s gender.

ENTITY person;
  first_name : STRING;
  last_name  : STRING;
  ss_no      : INTEGER;
  children   : SET [0:?] OF person;
UNIQUE
  un1 : ss_no;
END_ENTITY;

ENTITY male
  SUBTYPE OF (person);
  wife : OPTIONAL female;
END_ENTITY;

ENTITY female
  SUBTYPE OF (person);
  husband : OPTIONAL male;
END_ENTITY;

Subtype instance constraints

General

In general, an instance of a Supertype may involve instances of zero or more of its Subtypes.

If this is not the required behaviour, then the ‘instance set’ can be constrained.

Example 3. EXAMPLE of SUBTYPE instance constraints

ENTITY person;
  ...
END_ENTITY;

ENTITY employee
  SUBTYPE OF person;
  ...
END_ENTITY;

ENTITY student
  SUBTYPE OF person;
  ...
END_ENTITY;

We can use this model to talk about:

A person
A person who is an employee
A person who is a student
A person who is an employee and who is also a student

SUBTYPE_CONSTRAINT

The SUBTYPE_CONSTRAINT construct was introduced in EXPRESS Edition 2.

In Edition 1, the constraint specification was lexically embedded in the definition of the Supertype entity. If a new subtype was introduced in a different Schema that imported the Supertype there was no convenient method, apart from changing the original Supertype definition, of constraining the use of the new Subtype.

In general, an instance of a Supertype can involve any of its Subtypes.

The constraints are used to eliminate certain combinations of Subtypes.

Multiple SUBTYPE_CONSTRAINTs can be applied to a Supertype. The constraints are additive. (In EXPRESS you cannot eliminate a constraint).

Example 4. Example of SUBTYPE_CONSTRAINT

This model specifies SUBTYPE constraints for ENTITY ent.

SUBTYPE_CONSTRAINT sc FOR ent;
-- constraints
END_SUBTYPE_CONSTRAINT;

SUBTYPE_CONSTRAINT can be used with:

No constraints: An instance of the Supertype involves zero or more Subtype instances.
ABSTRACT SUPERTYPE: An instance of the Supertype must involve one or more Subtype instances.
TOTAL_OVER(x,y) means that every instance of the Supertype must involve an instance of at least one of the listed Subtypes.
ONEOF(x,y,z) means that one and only one of the listed Subtypes can be instanced with an instance of the Supertype.
(x ANDOR y) means that an instance of the Supertype may be accompanied by instances of the Subtypes x and/or y (the default condition).
(x AND y) means that an instance of the Supertype may be accompanied by instances of the Subtypes x and y.

ABSTRACT SUPERTYPE

An ABSTRACT SUPERTYPE can only be instantiated in conjunction with non-ABSTRACT subtype(s).

An entity does not have to declare itself to be a SUPERTYPE. It is a SUPERTYPE if it is mentioned by a SUBTYPE.
In some cases, a Supertype is not to be instantiated without one of its Subtypes. The entity can be constrained to be an ABSTRACT SUPERTYPE.

Example 5. Example for ABSTRACT SUPERTYPE

ENTITY mammal
  ...
END_ENTITY;

SUBTYPE_CONSTRAINT sc_abs FOR mammal;
  ABSTRACT SUPERTYPE;
END_SUBTYPE_CONSTRAINT;

ENTITY dog
  SUBTYPE OF mammal;
  ...
END_ENTITY;

TOTAL_OVER

This was introduced in Edition 2.

Note	I have failed to find any use for it.

It means (I think) that the listed Subtypes completely cover the domain of the Supertype. Further, every instance of the Supertype that includes Subtype instances must include an instance of one of the listed subtypes.

Example 6. Example of TOTAL_OVER

ENTITY person;
...
END_ENTITY;

SUBTYPE_CONSTRAINT adultchild FOR person;
  TOTAL_OVER(adult,child);
END_SUBTYPE_CONSTRAINT;

ENTITY child SUBTYPE OF (person);
END_ENTITY;

ENTITY adult SUBTYPE OF (person);
END_ENTITY;

ENTITY student SUBTYPE OF (person);
END_ENTITY;

In this model, every person is either a child or an adult. A student is also either a child or an adult.

ONEOF

A ONEOF constraint means that one and only ONE OF the listed subtypes can be used in an instance of the Supertype.

Example 7. Example of ONEOF

ENTITY person;
  first_name : STRING;
  last_name  : STRING;
  ss_no      : INTEGER;
  children   : SET [0:?] OF person;
UNIQUE
  un1 : ss_no;
END_ENTITY;

SUBTYPE_CONSTRAINT mf FOR person;
  ONEOF(male, female);
END_SUBTYPE_CONSTRAINT;

ENTITY male
  SUBTYPE OF (person);
  wife : OPTIONAL female;
END_ENTITY;

ENTITY female
  SUBTYPE OF (person);
  husband : OPTIONAL male;
END_ENTITY;

Here the constraint is that a person cannot be simultaneously a male and a female. Note that if the constraint was not there (as in the earlier model) it would mean that the model catered for hermaphrodites, which would introduce a new set of problems.

ANDOR

P ANDOR Q means that the following combinations of subtypes are allowed:

P only
Q only
P and Q together.

That is, P and/or Q are allowed.

The unconstrained relationship between Subtypes (the default) is ANDOR.

ENTITY person;
  first_name : STRING;
  last_name  : STRING;
  ss_no      : INTEGER;
  children   : SET [0:?] OF person;
UNIQUE
  un1 : ss_no;
END_ENTITY;

SUBTYPE_CONSTRAINT es FOR person;
  employee ANDOR student;
END_SUBTYPE_CONSTRAINT;

ENTITY employee
  SUBTYPE OF (person);
  salary : REAL;
END_ENTITY;

ENTITY student
  SUBTYPE OF (person);
  fees : REAL;
END_ENTITY;

In this example model, the constraint might as well not be there.

AND

P AND Q means that if there is an instance of P it must be accompanied by an instance of Q, and vice-versa — either both or none.

ENTITY person;
  ...
END_ENTITY;

SUBTYPE_CONSTRAINT mf_and_ca FOR person;
  ONEOF(male, female) AND
  ONEOF(citizen, alien);
END_SUBTYPE_CONSTRAINT;

ENTITY male SUBTYPE OF (person);
 ...
END_ENTITY;

ENTITY female SUBTYPE OF (person);
 ...
END_ENTITY;

ENTITY citizen SUBTYPE OF (person);
END_ENTITY;

ENTITY alien SUBTYPE OF (person);
END_ENTITY;

This example shows that the constraints may be complex (logical) expressions.

Unconstrained there are 15 possible combinations (from Person to a male, female, citizen, alien person).

With the given constraints there are only 5 (Person, (fe)male citizen, (fe)male alien).

Subtypes and Supertypes