The spectrum of services that an EIS must provide ranges far. We
can recognize two orthogonal dimensions:
We can, using these dimensions, view the design process as a wavefront, starting small at the origin of our plan, and widening while proceeding in parallel over all phases. The greatest effort takes place where the wavefront is widest, at the time that the design is nearly complete, but other phases of the product flow are still lagging.
Given this model, we notice that there are continuously active parallel tasks to be served by an EIS. Strict task serialization would not only extend the product development time excessively, but also inhibit the necessary feedback. Information from later phases in the product must be able to affect the design tasks before the design is completed, otherwise we are forced to use longer iterative cycles. The feedback effectively creates conflicts between the contibuing design task and the product development flow. Methods must be developed which signal possible conflicts without inhibiting cooperative parallel work.
At the stages where multiple phases are active, the data within the EIS will be viewed from very different aspects. An optimal data structure for the design phase is likely to be unwieldy for a testing phase. Distinct activities within a phase will themselves have differing requirements.
Most task specific design tools have today employ data structures
that are specifically well-suited to the task at hand, but because of
that view, the data structures chosen are rarely well suited to other
tasks. Questions to be posed in regard to the data organization
are:
Problems induced by these two aspects are information loss and locality loss. If the information is needed in phase i-1 and phase i+1, and phase i ignores that information, it must be reobtained, merged, and possibly transformed to be available in phase i+1. Similarly, structures have to be rebuilt from phase to phase.
The use of a central database with an EIS seems to have the potential of dealing with the first problem in information loss. The database provides a central resource, the tasks are limited to views. Mapping functions will have to be programmed until we have query languages that permit object construction and view update.
Locality management remains a problem, since locality and access issues are based on accessing requirements, beyond the knowledge of the database system and schema. They must be solved to provide adequate performance for engineering users.
If a database for an EIS can provide dynamic rebinding capabilities, which permit adjustment to current usage patterns, a third of the problems is solved. The remaining issues are: how does one application advise the database system of its access needs and how does the database integrate the diversity of requirements? As databases for EIS become a reality these questions will have to be addressed.