Author: Matthew West, Shell Services International
Date: April 1999
Status: Approved
The purpose of this document is to communicate from WG10 SC4 Data Architecture Project to WG11 requirements on EXPRESS to support the modelling requirements for the PWI for a Data Integration Architecture.
The following requirements have been identified:
These are not necessarily all the requirements on EXPRESS 2, and it is appreciated some of these requirements may already be met through the ignorance of the author. These requirements are elaborated below.
At present one EXPRESS entity data type can be a member of another EXPRESS entity, but there is no way of recording this information. For example, if I have the three entities equipment, equipment_type, and pump, I can show that pump is a subtype of equipment, but I can't show that pump is a member of equipment_type.
The issue for an integration model is that modelling classes as EXPRESS entities can lead to a loss of information. In order not to loose this information you can model classes as instances of more abstract EXPRESS entities. However, this results in very abstract data models that can be difficult to understand and to use. For this reason it is preferred to have the ability to model the class member relationship between EXPRESS entities so that the level of abstraction of a model is not an issue.
Below is an example of how these requirements could be met. It is meant solely as an illustration of requirements.
ENTITY equipment
SUPERTYPE OF ONEOF (pump, valve, vessel, ...)
MEMBER OF equipment_type
END ENTITY
ENTITY equipment_type
HAS MEMBERS equipment, pump
END ENTITY
ENTITY pump
SUBTYPE OF equipment
MEMBER OF equipment_type
END ENTITY
An intersection subtype is one where a subtype with multiple supertypes
contains all the members that are members of both supertypes. The subtype
relationship is not sufficient to do this. For example, red_vans is a subtype
of both vehicles, and red_things, but not all things that are both vehicles
and red
things are red_vans. It is therefore necessary to be able to assert that
a subtype is the intersection of some set of supertypes.
It is understood that this requirement can be met by EXPRESS V2 CD, but it does not seem to be well defined.
ENTITY blue_object
END ENTITY
ENTITY car
END ENTITY
ENTITY object_manufactured_by_Ford
END ENTITY
ENTITY blue_Ford_cars
CONOTATIONAL INTERSECTION SUBTYPE OF (blue_object, car, object_manufactured_by_Ford)
END ENTITY
A union of some classes is the membership of all the constituting classes. Subtype/supertype can be used to do this, but it cannot be conveyed that the union is constructed (derived) from its subtypes. Another possibility is to consider that a select is equivalent to a union, but it is not clear that this is the intention.
ENTITY a;
END ENTITY;
ENTITY b;
END ENTITY;
ENTITY c;
UNION SUPERTYPE OF (a,b);
END ENTITY
It is possible to indicate that a set of subtypes are disjoint, by the ONEOF constraint. However, it is not possible (or clear how) to assert that all members of the supertype are a member of one of the subtypes. It is possible that TOTALOVER could be used for this.
ENTITY a;
SUBTYPE OF (c)
END ENTITY;
ENTITY b;
SUBTYPE OF (c)
END ENTITY;
ENTITY c;
SUPERTYPEOF ONE OF COMPLETEPARTITION (a,b);
END ENTITY;
To be able to model instances of an EXPRESS entity within EXPRESS in such a way that they can be referenced from other objects and can reference other objects.
Instances shall be members of an entity.
Currently instances can only be declared as e.g. members of an enumerated type. As such they cannot make references to other instances or entity types.
ENTITY country;
name:STRING;
END ENTITY;
INSTANCE #1;
MEMBER OF country;
name: "USA";
END INSTANCE;
The things that we often refer to as relationships (or roles or attributes)
in EXPRESS are really classes of relationship. That is to say, they do not
indicate a relationship between one entity and another, but that a member
of one entity may (or must) be related to a member of another entity. This
is different from a specific relationship, which identifies a direct relationship
between two objects, such as a connection between a pump and a pipe which
you would find in a Part 21 file.
A use of this capability includes, but is not limited to, the ability to
reference instances of one entity in a constraint on the membership of another
entity.
This example is for a relationship between two entity instances.
ENTITY equipment
END ENTITY
ENTITY connection
connection_1:equipment
connection_2:equipment
END ENTITY
ENTITY pump
SUBTYPE OF equipment
END ENTITY
INSTANCE #1
MEMBER OF pump
END INSTANCE
ENTITY pipe
SUBTYPE OF equipment
END ENTITY
INSTANCE #2
MEMBER OF pipe
END INSTANCE
INSTANCE #3
MEMBER OF connection
connection_1:#1
connection_2:#2
END INSTANCE
EXPRESS schemas currently assume that the model is fixed and will not change with time. As a result, no facilities for managing change currently exist in EXPRESS. It has been clearly demonstrated that this assumption is not true. Therefore, a presumption for the data integration architecture is that whatever we develop may need to undergo change. There are a number of reasons why change may be necessary. These include:
In any of these cases it may be necessary to change the integration model. In order to be able to do this in an upward compatible manner, it is necessary to be able to tell a processor when it is receiving data according to an old version of the schema what to do with data for which there are no longer valid constructs.
Requirements that result to manage change to EXPRESS schemas include the ability to:
EXPRESS V1 is not able to meet these requirements, and it is important that EXPRESS V2 does.
A number of requirements on EXPRESS 2 have been identified which are critical to the successful use of EXPRESS within the Data Integration Architecture project. WG10 requests WG11 to address these requirements within the development of EXPRESS 2 and to assist WG10 in formulating appropriate issues against the EXPRESS V2 CD to ensure these requirements are met.