Applying next generation object-oriented DBMS to finite element analysis

SUMMARYIntegration of data from autonomous, distributed and heterogeneous data sources poses several technical challenges. This paper overviews the data integration system AMOS II based on the wrapper-mediator approach. AMOS II consists of: (i) a mediator database engine that can process and execute queries over data stored locally and in several external data sources, and (ii) object-oriented (OO) multi-database views for reconciliation of data and schema heterogeneities among sources with various capabilities. The data stored in different types of data sources is translated and integrated using OO mediation primitives, providing the user with a consistent view of the data in all the sources. Through its multi-database facilities many distributed AMOS II systems can interoperate in a federation. Since most data reside in the data sources, and to achieve high performance, the core of the system is a main-memory DBMS having a storage manager, query optimizer, transactions, client-server interface, disk backup, etc. The AMOS II data manager is optimized for main-memory access and is extensible so that new data types and query operators can be added or implemented in some external programming language. The extensibility is essential for providing seamless access to a variety of data sources.

show abstract

“…• (G) is a stand-alone embedded AMOS II system which provides database facilities for an application, e.g. for Finite Element Analysis [20].…”

Section: Architecturementioning

confidence: 99%

Distributed data integration by object‐oriented mediator servers

Risch

Josifovski

2001

Concurrency and Computation

View full text Add to dashboard Cite

show abstract

“…Note that the types of all arguments participate in type resolution to select which resolvents of the multiplication operator to use from all the possible multiplication operators in Eqs. [2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18][19]. Contrast this with a pure object-oriented data model without multi-argument functions where the system cannot select the correct resolvent when the type of another argument than the first one has to be considered.…”

Section: Declare K As Symmetricmatrix; Declare F As Columnmatrix;mentioning

confidence: 99%

“…We have built a system [19,20,21] for finite-element analysis (FEA) storing numerical data in the functional DBMS Amos II [22]. The performance requirements on numerical data access in an FEA model are very high, and several special methods have been developed for efficient representation of, e.g., matrices used in FEA where different methods are useful depending on the context.…”

Section: Introductionmentioning

confidence: 99%

Representing Matrices Using Multi-Directional Foreign Functions

Orsborn

Risch

Flodin

2004

The Functional Approach to Data Management

Self Cite

View full text Add to dashboard Cite

New application areas for database technology such as computer-aided design and analysis systems require a semantically rich data model, high performance, extensibility, and application oriented queries. We have built a system for finite element analysis using a functional database management system to represent multiple matrix representations. The functional data model is well suited for managing the data complexity and representation needs of such applications. Our application domain needs multiple customized numerical data representations, user-defined (foreign) functions, multiply inherited types, and overloading of multiargument functions. Type inheritance and overloading requires the support for late binding of function calls in queries. Furthermore, queries may use functions as relationships which means that the system needs to process inverses of both tabulated and foreign functions, multi-directional functions. It is shown how to model matrix algebra operators using multidirectional foreign functions and how to process queries to these functions.

show abstract

“…The DQL is capable of querying the analysis results together with invoking certain postprocessing computation. Combining general query language constructs with domain-related representations provides a more problemoriented communication [36]. The defined DQL and the programmed procedures have at least two features:…”

Section: Data Query Languagementioning

confidence: 99%

An engineering data access system for a finite element program

Peng

Liu

Law

2003

Advances in Engineering Software

View full text Add to dashboard Cite

This paper describes a prototype implementation of an engineering data access system for a finite element analysis program. The system incorporates a commercial off-the-shelf (COTS) database as the backend to store selected analysis results; and the Internet is utilized as the communication channel to access the analysis results. The objective of using an engineering database is to provide the users the needed engineering information from readily accessible sources in a ready-to-use format for further manipulation. Three key issues regarding the engineering data access system are discussed, including data modeling, data representation, and data retrieval. The engineering data access system gives great flexibility and extendibility to the data management in finite element programs and can provide additional features to enhance the applicability of finite element analysis software.

show abstract

Applying next generation object-oriented DBMS to finite element analysis

Cited by 9 publications

References 12 publications

Distributed data integration by object‐oriented mediator servers

Distributed data integration by object‐oriented mediator servers

Representing Matrices Using Multi-Directional Foreign Functions

An engineering data access system for a finite element program

Contact Info

Product

Resources

About