Jump over left menu
EASE Database Workshop
Professor M Save
3-5 December 1987
Workshop on Support for Database Systems Cosener's House Abingdon, December 3 - 5, 1987
This workshop was the second of a series initiated by CFTAG to study the computing needs of research groups funded by The Engineering Board of SERC. The workshop was attended by delegates from academia and industry and represented both engineering and computing interests.
Outline of conclusions and costs
- The liaison between the engineering community and the database community should be greatly improved by "educational exercises" such as workshops and joint product reviews (0.5my and £25K).
- A consultancy service should be established to assist engineering projects with the adoption and use of database techniques (1.0my/yr and #163;25K/yr).
- There is no existing database management system which fully satisfies the needs of engineers. Attempts should be made to define suitable engineering interfaces and ~ encourage their implementation by vendors (0.5my and #163;10K).
- A regular review should be maintained of database products relevant to engineers 0.5my/yr and £15K/yr).
- Some current research projects such as POSTGRES and PRODABAS offer a wide range of data types and greater functionality than existing systems. Their progress should be monitored carefully, vendors influenced where possible and the position reviewed by a workshop/conference approximately 2 - 3 years hence. Despite their limitations, support should be given as standards in the interim to INGRES and the SQL interface (0.5my and £15K).
- More use should be made of project management tools, including pilot projects involving tools such as PMW, PROMPT and ARTEMIS; the National Computing Centre should be contacted about their recent survey.
- The varied sources of data involved in engineering projects, and their dynamic nature, should be administered with the aid of a "control database" handling the meta-data. A demonstration system should be established (1.0-my and £20K) .
This is a report of the second of a series of four workshops set up by the Computing Facilities Technical Advisory Group (CFTAG). The aims of the workshop series are to assist CFTAG in identifying the computing needs of research groups funded by the Engineering Board of SERC, to consider whether appropriate software or hardware is currently available in the commercial market to meet the perceived needs, and to discuss steps which can be taken by CFTAG to assist the research community by increasing their awareness of existing opportunities or by encouraging new commercial developments.
The second workshop of the series was concerned with software for the support of database systems, and was held at Cosener's House, Abingdon, from December 3 - 5, 1987. It was attended by 43 delegates, 19 from academia (representing both computer science and engineering interests), 11 from industry and 13 from Rutherford Appleton Laboratory. All the delegates came by invitation and an important objective in issuing invitations was to obtain a reasonable balance between academics and representatives of industry, between consumers and producers of software, and between computing and engineering expertise.
2 Structure of the workshop
The time available was divided approximately equally between a series of lectures and discussions in four parallel working groups.
2.1 Lecture programme
The lectures were designed to provide background material and support for the working groups. They were well received and a number of useful points emerged directly from the lectures. They will simply be listed briefly as the main focus of this report is placed on the final recommendations of the workshop.
Professor Stocker (UEA) gave an overview of current database practice, indicating areas where users must make policy decisions, and describing some outstanding problems.
Mr M Wallis (RTI Ltd) described the development of INGRES as a commercial implementation of the relational database model, and outlined the features (now and forthcoming) of INGRES/Star, the distributed version of the system.
Professor M Atkinson (Glasgow) considered the special characteristics of engineering data and suggested new features, not available in current database management systems (DBMS), which the engineering community would be likely to need.
Dr T W Olle (consultant) in a talk based on very wide experience spoke of the practical design considerations required in specifying large databases.
Dr R P Jones (Warwick) and Mr A J Holt (Lucas) described their collaboration on CAD for automotive control systems - a very good example of the benefits and problems arising for research teams in the areas covered by the workshop.
Dr C J Angus (Prosys Technology) described projects undertaken by his company in engineering consultancy, including very impressive work on PRODABAS, an advanced tool for information management with a very rich set of data structures and associated operations.
Dr Chalmers (STC) spoke on the development of a data model for use in an industrial environment, a talk which identified the use by engineers of models for data transmission as distinct from the data design aspects more commonly discussed by computer scientists.
Finally Dr K G Jeffery (RAL) summarised the features of existing commercially available DBMS and reviewed a number of aspects of engineering practice which had by then emerged in working group discussions.
2.2 Working Groups
The delegates were divided into four working groups to provide the maximum opportunities for discussion, and to concentrate attention on four important aspects of database use and support. The four areas identified for this purpose were:
- modelling tools
- interfacing tools
- project management tools
- database administration tools.
The groups had about 10 members each and met three times before presenting their reports as the closing session of the workshop.
At their first meeting each group was given a list of eight questions to focus their debate:
- What software is currently available in the area under discussion?
- What software is currently in use?
- What are the weaknesses of currently available software?
- What strengths/benefits can be gained from or claimed for existing software?
- What new software tools and components are needed for the area under discussion?
- How feasible are the objectives identified in (5)? What time scales are involved?
- What are the costs, actual or in development, of the software proposed?
- Can any long term needs and opportunities be foreseen as a result of new directions in research or new developments in software?
Before the final group sessions, Professor Atkinson followed up these questions by suggestions that each group should report possible actions in relation to three timescales:
- What can and should be done now
- What directions should be followed in the medium-term, say, the 1-3 years
- What long-term strategies should be adopted.
3. Major Points Arising in Working Group Discussions
(Matters raised in several groups are reported only once, except where they differ)
Engineering data does not fit neatly into the modelling schemata as developed by the database community. However engineers have found a practical need to transmit data from one form of CAD system to another, e.g. from a design system to a finite element analysis system and back again. Thus data interchange formats have been designed which are a form of modelling. Examples are EDIF (Electronic Data Interchange Format), and CAD*I for mechanical data. The formats which have been used differ widely and translation between related formats has been difficult. Languages are now being developed to describe these concepts better, such as EXPRESS and the Esprit project AIDA an attempt to define a standard modelling language.
To undertake modelling for design as used by computer scientists, engineers need database systems which encompass more complex physical or conceptual objects, such as a crankshaft or a matrix. A joint evaluation by engineers and computer scientists of the PRODABAS package would be worthwhile. An alternative might be STROBE, a language developed with Alvey funding.
Engineers also need a better environment for modelling. Present CAD systems often hide the database from the user and thus it cannot be used in other applications. It was suggested that the concept of a specialist engineering workstation should be extended from control engineering to mechanical and electronic CAD. This would need a database at its heart and easy interfaces to other design tools.
Engineers have not been accustomed to the use of design tools in the early stages of a project. The use of tools such as AUTOMATE could be expected to encourage people to think more clearly about the structure of a problem as well as providing good documentation of the design. Some training courses (at a cheaper price than commercial rates) would be useful.
Five aspects of interfacing with databases were identified:
- host program
- other systems
- fourth generation languages
It was recognised that in several of these areas there was overlap with others of the working groups. The group surveyed existing products and compared them against the facilities being sought for each interface.
Although SQL was acknowledged to be inadequate for engineers, it is widely available and in use. Experience in the high energy physics community showed that standardisation on SQL would provide a platform for file and program interchange through the SQL DML/DDL interface even if sites used different DBMS.
In some cases non-SQL products have been chosen for projects because they offer different functionality needed by the project. These products should be studied in more detail to see whether SQL vendors can and should be persuaded to include the new features in their future releases.
The success achieved by the Warwick University/Lucas joint project was cited as an example of the benefit which can be obtained from consultation with the Information Management Group at RAL. Opportunities for wider exchange of information on database problems and database technology should be encouraged.
3.3 Project Management
Engineers have generally made little use of project management (PM) tools, but the broad structure of their projects has much in common with commercial projects - work breakdown structure, resource estimation, plan/ scheduling and monitoring. PM tools should be seen as supplementing other tools which may already be employed such as database software, a query language, a mailer or an expert system.
NCC has been studying PM tools and advantage should be taken of their knowledge. Other information should be sought from projects supported by SERC, Alvey, Esprit etc., and a 1-day project presentation could be arranged. A small number of PM tools should then be chosen for use in pilot projects. Since the packages vary widely in scope and cost, the selection should reflect different types, needs and potential. PMW, PROMPT and ARTEMIS (in increasing sophistication) might form a suitable set. The pilot studies must of course be followed by appropriate seminars/workshops.
3.4 Administration Tools
In view of the widely varying engineering data environments, in many of which current DBMS are inapplicable, the group decided that they should consider data administration, looking at a wider context than DBMS alone. It was recognised that this meant that their discussions might overlap with those of other groups, for example project management. However it also shows that the issues of data or database administration cannot be clearly separated from questions about database use. What is needed ideally is a database which can be used as a means of storing the meta-data about program and data relationships - this could be described as a "control database".
The traditional model of data implied by the traditional database schemata is inappropriate for engineering applications. Ideas and techniques taken from process control may be useful in developing a new approach, in which the database is seen as a dynamic structure (which may interact with other data sources) and the DBA is analogous to a control engineer.
Besides the usual "system administration" tasks such as back-up, user control etc, a number of necessary characteristics can be readily identified:
- there should be a friendly user interface
- the DBA should use the same interface as the user
- performance information should be collected
- design and restructuring should be based on high-level descriptions of database structure
- performance tuning must be possible.
The group agreed that a demonstration control database should be established, using a current relational DBMS and fourth generation language tools. This should be able to manipulate a conceptual dictionary, and automatically update a data dictionary. Its tools should include version control, access control, a documentation facility, and data distribution management.
There was also discussion of a number of current products which have some objectives in common with the control database PRODABAS, PS/Algol and METIS. It could be useful to evaluate their DBA facilities on a user trial basis.
On the theme of education more generally, this group, like others, recommended a series of seminars on the use of databases in engineering, and the establishment of a consultancy service, probably based on RAL, to give help with project management using control databases.
4. Conclusions and Recommendations
4.1 General Conclusions
It was agreed that there is no DBMS currently available which can provide all the facilities required for engineering applications. Specifically, they do not permit the definition and manipulation of complex objects such as matrices (except by breaking them down into atomic components), nor do they provide adequate support for version control and other temporal aspects. In engineering applications, complexity of data is typically more troublesome than contention over access, and transactions are lengthy rather than frequent. Thus they do not match well with the most efficient and highly optimised aspects of commercial DBMS.
Despite these strictures it was universally agreed that the engineering community should not attempt to develop its own DBMS. Any such attempt would be likely to prove costly, ill-judged, repetitive of previous development, difficult to support and very probably unproductive.
Instead, efforts should be made to alert existing research teams in computing to the characteristics of engineering databases, and attempt to influence the directions of development to take account of the needs of engineers as a consequence of these characteristics. PROBE and POSTGRES were cited as examples of current DBMS research projects which offer some of the facilities sought by the workshop.
There was also general agreement on the need for education within the engineering community to give more awareness of the scope and benefits for engineering projects of modelling tools, project management tools and database administration tools as commonly used for commercial databases. This educative process could be informed by arranging for trial use of software for some selected projects.
Finally, on broad policy, it was accepted that existing standards should be adopted as much as possible to maximise the ability of the community to profit from the interchange of data and, at a very different level, of expertise. It was recognised that this will mean adopting standards, such as the SQL query language, which are not ideal. Just sufficient flexibility of practice should be permitted to allow the community to become aware of promising new developments, and consider adopting them as standards if appropriate.
To support the needs of engineers for efficient data interchange between one form of modelling and another, close attention should be paid by CFTAG to the development of Esprit's AIDA and to its data interchange products. Further projects of this nature could be encouraged through participation in standardisation activities.
4.2 Specific Recommendations
4.2.1 Short Term
- S1 Attempt a significant improvement in liaison between information engineers and others by "educational exercises", for example:
- short courses on general modelling principles and packages such as AUTOMATE
- similar courses on project management tools, following recommendation (S6)
- joint assessment of simple and extended modelling packages.
- S2 Set up a consultancy service to assist engineering projects with the adoption of database techniques and to give help with data/program management.
- S3 Accept SQL as a standard interface to database systems and encourage its use.
- S4 Support the Computer Board initiative establishing favourable terms for the purchase of INGRES.
- S5 Strongly discourage the purchase of any relational DBMS for which no modelling module is in prospect. (Counter example: Oracle's SOD).
- S6 Obtain information from the NCC about their evaluation of project management software; establish the current usage of such tools in projects supported by Alvey, Esprit, etc, and the needs of users.
- S7 Evaluate the DBA facilities of new software developments such as PRODABAS, PS/Algol, METIS, KEE. Construct a "control database" as a demonstrator project using a current RDBMS and 4GL software.
4.2.2 Medium Term
- Ml Select pilot projects for trial use of project management tools such as PMW, PROMPT and ARTEMIS, following recommendation (S6).
- M2 Maintain a regular product review process for new and existing products which have engineering components. In particular, monitor and evaluate non-SQL products to identify features of value to the engineering community which vendors of SQL products could be encouraged to incorporate.
4.2.3 Long Term
- L1 Organise a conference/workshop to discuss the development of database initiatives currently at the research stage, example: POSTGRES, PROBE and press for the functionality required by engineers especially in the light of experience gained in the 2 years following the present CFTAG initiative.
- L2 Provide support for the development of "engineering" interfaces to existing SQL-based systems.
- L3 If or when a reliable well-supported DBMS becomes available which provides for a wider range of data types and greater functionality, urgent consideration should be given to making it available without delay.
- L4 Advise UK industry of the findings of the workshops proposed in this programme, and encourage them to become involved in the development of the software needed by engineers.
Geoff Lambert of RAL undertook all the detailed planning of this workshop, and gave invaluable advice and help to the Chairman of the organising committee. Cosener's House provided very comfortable accommodation. The convenors of the working groups and their rapporteurs carried out difficult tasks most willingly, and did a great deal to focus the very diverse interests and wide-ranging debates within their groups.
Their summaries were of the greatest value to the author in drawing up this report of the workshop.