On the external level, this approach supports, among other things, concurrency, inter-operability, data exchange and transformation, data and operator sharing, data distribu-tion among applicadistribu-tions and data sources in the EIS environment as illustrated in Figure 18. Different AMOS mediators can be combined for locating, translating, and integrating data in various data sources for the applications. Ultimately, the DBMS can decide how and where to execute a query, using query optimization techniques. By pro-viding several mediators with the same application package, as illustrated by the matrix package in Figure 19, it will be possible to decide where the execution should take place.
Figure 18. A mediator-based EIS architecture that illustrates how a combination of different types of mediators (AMOS DBMSs) is used to mediate data among applications and data sources. Each application is equipped with an embedded DBMS.
Figure 18 shows an example of how an EIS environment could be extended with data management capabilities by taking advantage of the mediator approach. Each applica-tion can have its own embedded DBMS (E-AMOS) that can communicate with other mediators. For example, an integrator (I-AMOS) and possible translators (T-AMOS), can support the FEA application to retrieve analysis data that reside in a relational da-tabase (RDB) or in a STEP import file. The CAD application can provide geometric
FEA E-AMOS
PDM E-AMOS
NS-AMOS
T-AMOS RDB I-AMOS
S-AMOS STEP file
T-AMOS T-AMOS
OODB
CAD E-AMOS
CAx E-AMOS
data through its own mediator to a database server (S-AMOS). An OO database (OODB) can be used for long-term storage of FEA data. A product data management (PDM) system can be used for administrating product data in the EIS system. The name server (NS-AMOS) is used to locate where data is stored. The domain models that cover the different applications are parts of the global schema of the mediator system.
Figure 19. A possible client-server architecture for working with applications coupled to AMOS. The fast-path interface (FIF) and the embedded AMOSQL (EQL) can be used to communicate with the DBMS by applications with an embedded DBMS. AMOS also includes a foreign data source (FDS) interface for integrating foreign data and operator representations.
It is of vital importance for the application to preserve the execution efficiency while adding functionality to the system. There are several factors that influence the overall performance in database systems where conventional engineering applications are
com-CIF
AMOS Server
Matrix pac.
TRINITAS
FIF EQL
Embedded AMOS
Matrix pac.
FDS interface
FDS interface SIF
bined with DBMSs. In the present approach execution efficiency is supported by main-memory processing, query optimization, and extensibility. Most important is the ability to have an embedded main-memory database where the application can access and up-date data through a fast-path interface using precompiled and preoptimized database functions.
Generally, execution efficiency is also supported by the query processor that has the ability to optimize access paths and operator ordering. This is especially important in complex modelling situations where the optimizer automatically can choose a good ex-ecution order. This simplifies the design of the database and frees the programmer from specifying the exact execution order which can be stated in higher-level terms. By pro-viding the application with general and efficient data representations in the DBMS, these become directly available to the application and need not be re-implemented.
The AMOS extensibility with foreign data sources, i.e. packages of specialised data representations and operations, makes it possible to provide efficiency for critical activ-ities. For instance, FEA involves large amounts of numerical data that must be repre-sented and processed effectively. This requires data representations that are tuned for numerical operations, such as compact matrix representations.
Furthermore, specialised representations and operations in the DBMS are also required to avoid unnecessary duplication and transformation of data. If suitable data represen-tations and operations are not available, data must be moved, and maybe transformed, to and from the DBMS for processing. Hence, the location of data and processing and data representation can be critical for processing efficiency, as also indicated in Stone-braker and Moore [6].
Three basic situations can be identified that reveals the problems of data and processing location:
1. Both data and operations are located in the application. This is one of the extreme cases where no DBMS is engaged and, accordingly, there are no DBMS capabilities and the location problem has no relevance.
2. Data is located in the database but the operations are located in the application. In a conventional R DBMS, where data is stored in tables, data might need both to be transformed to a suitable format and duplicated into the application. By using an ex-tensible DBMS, the data transformation can be avoided but data must still be dupli-cated into the application for processing. The same holds for the opposite case and direction, but this case is probably not so common, where data is located in the ap-plication and the operations are available in the DBMS.
3. Both data and operations are located in the database. If appropriate data representa-tions are available, data duplication and transformation can be avoided.
It should be noted, that the DBMS can provide indexing techniques that speed up data access. In general, it is also wise to make data reductions, such as filtering, within the
database before data is transferred to the application. Hence, to take full advantage of the DBMS capabilities might require that certain parts of the application-specific oper-ations should be performed by the DBMS. If this were solved for existing applicoper-ations, it might imply a severe redesign of the application logic.
The size and number of data items must also be considered in evaluating where to locate data and operations. These kind of decisions, of where the processing should take place, could also be supported by the query processor. By defining appropriate cost measures for operators at different locations, the execution can directed to the one (or even sev-eral) of the servers in a network that is most cost-effective.
In FEAMOS, a manipulation of an application object through the TRINITAS user in-terface, or by an application procedure, implies an immediate update of the database.
For example, when a point is moved on the screen it is a database point object that is updated. Thus, since application data is only stored in one place, data redundancy and inconsistency can be avoided.
With the availability of the query language it is further possible to query the contents in the database through the query language interface of the database. For example, we are currently using a www-interface in AMOS to connect a www-browser to the DBMS for interactive query access.