Epicentre and POSC/CAESAR, Part Two of Three (March 1999)

Nigel Goodwin of Essence Associates continues his analysis of upstream data modeling with a look at the concept of inheritance

What is inheritance? As we concluded in last month's article, the data modeling world distinguishes two types of inheritance. Epicentre and POSC/Caesar both use variants of the EXPRESS data definition language which lets the programmer define inheritance of attributes and relationships. This is inheritance at the entity-type level.

A simple example of entity type inheritance from Epicentre is the entity-type 'activity', and the sub entity-type 'well activity'. 'Well activity inherits all the attributes and relationships of 'activity', but in addition it has a relationship to 'well', so you can say which well the activity is being performed on. Standard relational database management systems do not support inheritance. Indeed, it appears that even Oracle 8i does not support inheritance either. Implementing entity-type level inheritance requires modern technology, such as provided by PrismTech, or by "projecting" the data model and implementing in more traditional relational DBMS’s.

data level

The second type of inheritance is at the data level. In POSC/Caesar, there is a class of equipment called ‘pump’ and another called ‘centrifugal pump’. These are held as data in the equipment class entity type. A centrifugal pump is a special case of a pump. Everything we can say about pumps (e.g. they usually have a maximum flow rate) can also be said about centrifugal pumps. Inheritance can be used to manage this information in a more compact form, we don’t have to repeat the fact that all subclasses of pump may have a maximum flow rate, we just define it for the superclass ‘pump’.

Express lacking

This is inheritance at the data level, and surprisingly, there is no capability in EXPRESS to achieve this, because Express, like SQL is dealing with the entity-type level. Data level inheritance is common knowledge amongst the POSC/Caesar community, although it is not explicitly mentioned in the specification.

When implementing POSC/Caesar in old technology, inheritance at the entity type level can be catered for by performing methods equivalent to the Epicentre relational projection, although POSC/Caesar do not at present (and have no plans to) define a relational projection. Inheritance at the data level must be managed using other tricks such as managing data inheritance ‘on the fly’ or using caching techniques which can be quite successful because the reference data library, by nature, does not change frequently.

business domains

The wellbore and its associated activities and equipment is one business domain where Epicentre and POSC/Caesar meet up. A current POSC project WIME, has just released version 1.0 of its specifications (www.essence.co.uk/essence/WIME). WIME defines drilling and well operations activity and equipment types. The project used concepts from both Epicentre and POSC/Caesar although leans more to the latter. The results are being integrated into the next version of Epicentre.

Oracle 8?

PDM has already touched upon the object extensions available in Oracle 8 which are to be deployed in project Synergy (PDM Vol 4 N 2). How much will be gained from the new technology depends on whether Oracle 8 can handle inheritance at the data level, whether it can manage documents, (both as binaries and broken down into their graphical elements), and whether it can provide units of measure utilities. If the move is from a traditional SQL-type DDL to something similar to EXPRESS, then the benefits are not likely to be great. However, if it is a move towards a full engineering DBMS, including units of measure handling and inheritance at the data level, then this would aid application developers to bring their products to market more rapidly.


A good data model should be implementable for performance and should cater for a range for implementation technologies. It must model the business needs of the domain adequately and should be flexible enough to cater for changing business needs - including expansion. It should not be any more complex than necessary and should be suitable for ad-hoc queries by computer literate end users. Finally, the model should be coherent, unambiguous, and have common style throughout the model.

Click here to comment on this article

If your browser does not work with the MailTo button, send mail to pdm@oilit.com with PDM_V_3.3_9903_14 as the subject.

© Oil IT Journal - all rights reserved.