The Impact of Database Technology on Multidisciplinary Design Optimization

David L. Herendeen*, Mark R. Ludwig**, and Jeffery San Marcoe** Universal Analybcs, Inc., Torrance, California 90503

The database management requirements of multidisciplinary design optimization are two orders of magnitude greater than those traditionally required for the much simpler analysis task. This paper looks at these requirements and the manner in which they are being addressed by today's sofhvare systems. It then outlines a new database approach that will address the deficiencies of the current systems while providing an extensible framework for scientific software development in the com- ing years.

Introduction This paper defines the interrelationship of two impor-

tant technologies: multidisciplinary design optimization (MDO) and scientific database management. This defini- tion allows the impact of database management on the design task to be quantified, and an approach to solving the database management problem to be formulated.

Multidisciplinary Design Optimization

Over the last decade, a number of structural optimiza- tion systems have made tlieir appearance. In the United States, the current state-of-the-art in full multidisciplinary design optimization is represented by the Air Force Struc- tural Optimization System, ASTROS, described in Heren- deen et al.' and Neil1 et a1.' In addition to this system, a number of other organizations, especially those in the aerospace industry, are developing similar systems which they hope will address their specific needs. In Europe, the MBB/LAGRANGE system and ELFINI, developed by Dassault Systemes, are also intended to perform general structural optimization.

Database Management Systems

The database requirements encountered in the design, development and implementation of the complex software systems used for solving "industrial strength" design opti- mization problems are different from those most often ad- dressed in the commercial marketplace. This paper ex- plains the relationship of scientific databases to software development in general and to the multidisciplinary de- sign optimization task in particular.

Software systems without well developed database technology will find that the implementation of a fully general automated design capability is very inefficient and, in some cases, nearly impossible. There are several reasons for this. Firstly, the finite element systems devel- oped using 1960s technology are based on sequential file systems that make it very inefficient to modify small quan- tities of data, such as node point locations or element thicknesses, which are embedded in a large file. Secondly,

Copyright 63 1992 by Universal Analytics, Inc. Published by the American Institute of Aeronautics and Astronautics, Inc., with permission.

'Vice President and Senior Scientist **Senior Member of the Technical Staff "'Senior Scientist

the volume of intermediate and final analysis results, al- ready large for simple structural analysis, becomes larger bv two orders of mamitude. It is im~ossible for a devel- " oper to anticipate all of the possible ways in which a de- signer might wish to peruse and report this data. New solutions must be found.

One solution to the growing mass of data is the avail- ability of general database query tools which allow users to d e c t and sort data in any manner. This approach has been employed in ASTROS by the Interactive CADDB En- vironment, ICE. This additional program provides an ex- tended SQL-like interface to a CADDB database. The wide range of capabilities offered by ICE are described in Her- endeen and ~ u d w i ~ ~ . This approach has been extended to an even more powerful database called BASE.^,^

Multidisciplinary Design Optimization

FEM -The nucleus of MDO systems

The heart of the MDO system is the Finite Element Method, FEM. FEM has become the principal tool for structural engineering analysis over the past three dec- ades. The axioms and capabilities of FEM are well known and will not be described here. FEM software, which is mature and has stood the test-of-time, provides a powerful nucleus of computational capabilities which form the basis of, and must be integrated into, MDO software. The meth- ods for doing this are described in the next section.

Multidisciplinary analysis

Nearly all mechanical systems must satisfy environ- mental criteria that arise from different engineering disci- plines. It is therefore mandatory for an MDO system to provide multidisciplinary analysis. For example, the AS- TROS system includes the following analytical disciplines:

Static Stress Analysis Natural Frequency Analysis Steady Aeroelastic Analysis Aeroelastic Stability Analysis Dynamic Response Analyses

All but the last of these, which includes both time and frequency domains, may be used during the optimization process. Similarly, all except the aerodynamic disciplines have their basis in FEM. Aerodynamic analyses are per- formed using other types of mathematical modeling, such

as panel methods, which then interact with FEM through matrix operations which modify the equations of motion to incorporate the aerodynamic behavior.

Data Organization

The high-level management of engineering design data is closely related to the management and performance of the actual design process. Data is created and used within limited, well-defined domains. These include such areas as CAD Models, Structural Analysis, Shock and Vibration, Master Dimensions, Loads Analysis, Propulsion Systems, Performance Requirements, and many more. Typically, data is named and structured in ways which relate to the specific domain. When an engineering task has been suc- cessfully completed, the data is released by the responsible engineering management. This process represents a natu- ral hierarchy that results from the decomposition of a com- plex process into its simpler components.

As an example, consider an aircraft manufacturer whose products include one airplane called FIGHTER. A simpli- fied model of an organizational structure for the design, analysis and testing data for this product is pictured in Figure 1. An engineering data management system must accommodate such an organization of data if it is to be integrated into the product development cycle with mini-

Database Management Systems

Background

In recent years, the relational model has prevailed as the superior alternative for information management. The software that supports the database is called the Database Management System, or DBMS. While there are many commercially available DBMS products which have suc- cessfully satisfied the needs of typical corporate data han- dling, they are not designed for, nor do they offer the nec- essary functions for, the support of scientific data handling and software development.

FIGHTER 0 / CAD ! I PERFORMANCEJ

MODELS REQUIREMENTS

1 F] ANALYSIS

1 'ZF 1 1 %Z ] DYNAMICS INTERACTION

FI VIBRATION T U N N E L

p q 1 DYNAMICS

PROPULSION

Figure 1 Typical engineering data hierarchy

The history of database management systems for use in the scientific environment is shorter than those for com- mercial applications and the attempts to satisfy the needs of the scientific community have been less than successful. Although file management systems for scientific software can be found in the early 1960s, it was not until the mid- 1970s that the importance of data management became evident to the technical community. In 1978, one re-

6 searcher wrote:

"The need for systematizing the management of data structures was first felt in the field of business proc- essing ... The development of centralized database management software for supporting scientific pro- grams has not been so spectacular ..."

One early system, begun around 1976, was called RIM, the Relational Informational Manager. This database was developed under the auspices of NASA~. A more interest- ing and comprehensive database, developed as an adjunct to the Automated Structural Optimization System, AS- TROS, sponsored by the U.S. Air Force is the Computer i Automated Design Database, CADDB . CADDB, devel- oped in 1983, is a multischematic database than supports the most frequently used engineering data structures in a unified manner. The meaning of the term multischematic is described later in this paper.

These forerunners have led to the design and creation of a new product, called eBASE, developed by Universal Analytics, Inc. This database provides a variety of tools for comprehensive data modeling, the need for transactional database capabilities, and theneed for a higher level soft- ware development tool.

Data Manipulation Requirements

Often there is confusion as to why a commercially avail- able DBMS cannot be used to integrate engineering data. There are two major reasons that such a DBMS is inade- quate for this purpose. Firstly, the typical commercial da- tabase application is used to represent very simple nu- meric data such as emvlovee number, salarv, and so forth.

1 i ,' On the other hand, geometric surface representations, complex double precision matrices and other engineering data have complicated mathematical relationships that cannot be decomposed into the simple data types sup- ported in current relational DBMS and furthermore, their ;epresentation often depends upon the computer where the database resides.

Secondly, most business databases are transactional in nature. This means that their principal application is the continual retrieval, addition, modification and deletion of data by many end-users. Although the database may be very large, each transaction usually acts upon a very small quantity of data. ~ x a m ~ l e s of this include order entry sys- tems, airline reservation systems, and lottery ticket proc- essing.

Also note that although an interactive interface to an engineering DBMS has great usefulness, as will be dis- cussed later in this paper, the overriding DBMS need is for the efficient storage and retrieval of much larger volumes of data.

Relational vs. Multischematic.

The purely relational database model is not adequate for efficiently representing engineering data. The efficient

handling of engineering data types, such as floating point numbers in single or double precision, vectors, and matri- ces, cannot be accommodated by the relational model. However, the importance of the database schema to engi- neering is profound. A schema is the key to integrating software systems and in sharing data among many com- puters within an organization.

The obvious conclusion drawn from this discussion is that the engineering data storage and handling require- ments are different from those of commercial data. In no uncertain terms, it is not practical to insert the square peg of engineering data into the round hole of a commercial DBMS.

Components of DBMS

A complete DBMS generally has three major compo- nents. The first is the database kernel. The kernal is the software that implements the actual physical database on the computing system. The second, built using the kernal as a tool kit, is the applications programming interface. This library of higher level utilities allows end-users to embed the DBMS in their own software systems. The third component is an interactive program, or shell, which al- lows users to query, or select, data from the database. When taken together, these three facets of the DBMS pro- vide a powerful framework for MDO software develop- ment and use. A final im~ortant feature of the DBMS is its ability to create database: which are portable between dif- ferent computers. To accomplish this, data interchange for- mats such as the IEEE-754 Binary Floating-Point Arithme- tic Standard must be supported.

Relat ionship of M D O to Databases

Each new product line developed in today's industrial environment is more complex than its predecessor. This growing complexity increases the need for efficient com- munication between the many engineering disciplines that must work together. Virtually all of these engineering dis- ciplines have automated their tasks with computer soft- ware tools. These tools, in many organizations, form what has been picturesquely called islands ofatitomatioiz. Unfor- tunately, this evolutionary approach has created a signifi- cant problem: there is often little consideration for the need to communicate, control and manage data beyond each island. If the product development cycle is to be shortened and its cost reduced, this situation must be im- proved in a significant manner. This problem is succinctly stated in a recent survey of next-generation database sys- tems, where Silberschatz et al.' observe:

'The cooperation among different organizations on common scientific, engineering, and commercial problems will require lake-scale, heterogeneous, dis- tributed databases. Verv difficult uroblems lie ahead in the areas of inconsistent databases, security, and massive scale-up of distributed DBMS technology."

The teclmology for solving this problem exists today. The solution is the use of a single, unified software system for the total management of engineering data. Such a soft- ware product must uniquely address the issues that differ- entiate the needs of engineering data management from those of business data management. The remainder of this paper explains the specific problems of engineering data

Figure 2 Database directory structure

management, particularly those of MDO, why these prob- lems cannot be solved by business-oriented databases, and how a DBMS, such as eBASE, solves them.

Meeting the Database Requirements

To address the needs which have been outlined, a DBMS is required that allows a hierarchical organization of data which reflects a company's way of doing business. Within this hierarchy, . a multischematic data repre- sentation is required. A similar blend of hierarchical and relational databases called the semantic model has recently been described9. In the following sections, the manner in which eBASE addresses these issues is discussed.

Directory Hierarchy

Figure 2 illustrates a typical way in which an eBASE hierarchy may be defined. The eBASE, A: in the figure, contains three Directories. A directory might contain the engineering data for a specific product line, or it might contain a subset of such data for a large and complex product. Each directory may, in turn, be composed of one or more Subdirectories containing related data. Each direc- tory or subdirectory may contain different data Entities. These Entities may be organized in as many additional levels of directories as needed to fully categorize the data. In Figure 2, the white boxes represent directory hierarchy levels, while the shaded boxes represent actual data stored in the database.

Note that there may be many other uses and interpreta- tions of these levels which are limited only by the imagina- tion of the designer.

Entity Classes

As introduced earlier, eBASE is a collection of data which is organized into entity classes. An entity is simply a group of related data that is stored together. Unlike purely relational databases which store tables of data, eBASE has four different data structures which are treated in a unified manner. This type of database is called multischematic.

The four entity classes which may comprise an eBASE database are:

RELATIONAL entities MATRIX entities

0 FREEFORM entities STREAM entities

Each of these entity classes is briefly described in the following sections.

Relational Entities

A Relation is viewed simply as a table of data. eBASE tables have rows, which are called Entries, and columns, which are called Attributes. A particular data value at a given entry and attribute location is called a Field. These attributes, taken together with the characteristics of the data which they contain, form the Schema of the Relation. The attribute characteristics, or Schema Components, of a Relation are defined when it is created. These charac- teristics include the attribute name, data type and, in some cases, length. A typical relation is then defined using:

RELATION re1 'Typical Relational Schema' { attl Integer 'First Attribute', att2 Real 'Second Attribute' , att3 Char(l2) 'Thlrd Attrlbute', att4 Complex 'Last Attribute' )

The well-defined schema of a Relation results in total portability because are of the numeric types are known and are an explicit part of the database structure.

Matrices form the second Entity class in an eBASE data- base. Matrices are arrays of numbers used in mathematical formulae typically encountered in engineering and physi- cal science software applications and which form the basis of FEM-based MDO software. A Matrix Entitv is defined in the standard mathematical manner as an array of n Rows and m Columns. Each value in the Matrix, Aij, is called a Term. The subscripts i and j indicate the row and column location of the term. Matrices also have schema components. These include the Orientation, the Storage Mode, the Numeric Types of their terms, and their general topological Shape. As with Relations, tlie schema is de- fined when the Matrix is created. A Matrix which is cre- ated column-wise has a Column-maior orientation and one which is created by rows has a Row-major orientation. The Shape of a Matrix represents its general topology such as square or rectangular. The Numeric type of a Matrix speci- fies the type of data defining its terms. For example, the terms can be real or complex. Finally, there are two possi- ble Storage Modes for the Matrix. The first mode is Un- compressed in which case all of the Matrix terms are stored on the database. To improve efficiency, eBASE uses an optional technique to minimize the disk storage re- quirements of matrices by storing them in the compressed mode. Unlike the Uncom~ressed Matrix, onlv the non-zero

' 2

terms of Compressed matrices are stored along with a small amount of control information.

Freeform Entities

Freeform Entities are a form of internal data repre- sentation that can sometimes be used to improve the per- formance of software applications. They are collections of data with only a local and transient purpose. Most often, they are used for temporary storage in a software applica- tion. Freeform Entities are similar to Fortran direct access files which have variable length Records. They are defined with a single Schema Component that defines the records to be comprised either of a homogeneous data type or of mixed heterogeneous data types. The former, called Sche- matic Freeform Entities, have excellent portability charac- teristics, while the latter do not.

Stream Entities

A Stream Entity is a continuous Stream of Data Values, each of which has a Position within the Entity. Each Data Value may be directly and randomly addressed by refer- ence to its Position. This type of entity as a low-level Unix file structure. A Stream Entity also has a very simple schema with a single Schema Component - it may con- tain mixed data types, or it may contain a single numeric data type. Again, such Schematic Streams have good port- ability characteristics.

Scientific Data Types

One of the most important eBASE features is that, unlike commercial database management systems that are di- rected toward financial or business applications, it pro- vides full support for the numeric data types found in scientific and engineering software environments. The eBASE entity classes support: integer data; real and com- plex data in both single and double precision; and charac- ter strings

Subscripted Entities

Each directory or subdirectory may contain one or more actual database entities. These are, naturally, defined by their name. However, eBASE allows another flexibility in that several entities may have the same basic name but a different subscript number. This is useful, for example, if several sets of analysis results are going to be correlated.

The concept of subscripts is a very powerful generaliza- tion. They can be used to implement the version concept found on some computers by simply incrementing tlie subscript each time the data in an Entity is changed. Or, whole arrays of database Entities may be created directly with their subscripts. This provides additional capability to better organize, access, and manipulate the information on the database.

Data Modeling Data modeling, sometimes called database design (from

an end-user point-of-view), is the process of defining the relationships of the data within a software application. This process is an art in that all data may be represented in many different ways. The following factors are generally considered when modeling data:

Matrices are also totally portable because all required information describing them is also an explicit part of the database structure.

0 Computational Efficiency Data Locality

0 Software Engineering Characteristics 0 Required Access Methods

The MDO process is dominated by the solution of FEM- based linear or piecewise-linear algebraic equations. As such, computational efficiency is extremely important. These efficiency requirements are addressed by high per- formance matrix utility modules which take advantage of the sparsity of many of the matrices used in the problem formulation. Beyond this, however, the main criteria for the MDO system should be the accessibility of the infor- mation on the database. There are numerous reasons for this which are demonstrated in the remainder of the pa- per.

A Design Example

Description

A typical multidisciplinary design optimization to per- form the preliminary design of a full airplane model and a survey of its database requirements is presented in this section. The structural and aerodynamic models were de- veloped for the right half of the plane. Details of these models, which were designed by a major aerospace com- pany using the ASTROS program, as well as the design information, are described in the following sections.

The Structural Model

The structural model is composed of 1000 grid points and 3000 finite elements. About 1500 elements are used to model the airplane skin. These elements are fabricated from laminated composite panels having from 4 to 9 layers each. The other 1500 elements are used to models stringers and spars in the plane.

The Aerodynamic Models

The unsteady aeroelastic model uses 200 boxes and 25 m-k pairs. The static aerodynamic model includes 400 boxes which modeled the primary lifting surface with split trailing edge flaps and a full flying horizontal stabilizer for both symmetric and antisymmetric maneuvers.

The Design Model

The design model includes 12000 physical design vari- ables which represent primarily the thickness of the com- posite plies in the skin elements. Design variable linking is used to reduce the design space to 200 variables. The link- ing is used to simulate manufacturing constraints. The de- sign constraints include 27000 strain constraints, 1000 local panel buckling constraints, more than 600 flutter con- straints, and several limits on flexible stability derivatives.

The Disciplines

The optimization is performed simultaneously for three disciplines: static strength, static aeroelasticity, and flutter. The first two of these are solved for both symmetric and antisymmetric boundary conditions using a variety of loading conditions which correspond to ultimate maneu- ver loads such as 3g pull-up, -3g push-over, and so forth. The flutter analysis is performed at 3 Mach numbers at

two altitudes each for 7 or 8 velocities over a range of 15 normal modes.

Database Quantification

Table 1 indicates the size of the database required to store the information generated during this multidiscipli- nary design optimization. It has been categorized in four groups: structural and aerodynamic modeling data; struc- tural response results; aerodynamic response results; and design iteration data. Naturally, the modeling data repre- sents a very small fraction of the database because it is invariant during the design process. The analytical re- sponse quantities, which include the design sensitivity co- efficients, form the greatest portion of the database.

The Database

Shown in Table 2 are the schemas for several relations that might appear in an MDO software system. Note that these are abbreviated for simplicity and each would have many more attributes in a real implementation. The first, weight, represents modeling data. The next two, quad4-s t res s and flutter, represent analytical re- sponses that would result during the design process. The other three, phys-dv, design-constraint, and his- tory, are those which contain information about the auto- mated design process.

Using the Query Language

The designer may, using the query language of eBASE, extract any desired data. There are three classes of data that are useful. The first is the analytical data which are needed to validate the quality of the model. The second are design data required to validate the results of the MDO process. The final class are those data which allow the designer to gain insight into the design process result- ing from MDO. Each of these classes is easily accommo- dated using the database. Examples of each, drawn from the schemas in Table 2, are given below.

1. Analytical Results -What QUAD4 elements have Von Mises stresses greater than 2 . 5 ~ 1 0 ~ psi and what are the actual values of the stress? SELECT e i d , van-mises FROM quad4-stress

WHERE von_mises>2.5E+5;

This query illustrates how selected data are easily qualified using a WHERE clause.

Table 1 Design database size

Data Type Disk Space, MBytes

Modeling data < 1

Structural response results 185

Aerodynamic response results 49

Design iteration data 28

Total 263

Table 2 Representative MDO Relational Schemas

RELATION welght 'Model Weight' { lter-num INT 'Iteration Number', X 0 RSP 'X Value of C.G.', Y 0 RSP 'Y Value of C.G.', Z 0 RSP 'Z Value of C.G.' 1

RELATION quad4-stress { iter-num INT 'Iteration Number', eid INT 'Element ID Number', sigma-x RDP 'Normal-x Stress', sigma-y RDP 'Normal-y Stress', tau-xy RDP 'Shear Stress', von-mises RDP 'Von Mises Stress' )

RELATION flutter { iter-nurn INT 'Iteration Number', mach-num RSP 'Mach Number', rho RSP 'Density', velocity RSP 'Velocity', mode-num INT 'Natural Mode Number', lambda CDP 'Complex Eigenvalue', sarrma RSP 'Damping Value' 1

RELATION phys-dv 'Physical Design Varlable Values'

( iter-num IPJT 'Iteration Number', elem-type CHARl8) 'Element Type', elem-id INT ' Element ID Number ' , t RSP 'Element Thickness' 1

RELATION design-constraint 'Design Constraint History'

{ iter-num INT 'Iteration Number', con-type CHAR(8) 'Constraint Type', con-value RSP 'Constraint Value' elem-type CHAR(8) 'Element Type', elem-id INT 'Element ID Number' 1

RELATION history 'Objective Function History'

{ iter-num INT 'Iteration Number', objective RSP 'Objective Value', converged INT 'Convergence Indicator' 1

Note: INT, RSP, RDP, CDP, and CHAR represnt Integer, Real Single-Precision, Real Double-Precision, Complex Double- Precision, and Character type data, respectively.

Analytical Results - Plot the vg flutter curve for the fourth design iteration at Mach number 1.5 and density 0.0015 for the first natural mode. XYPLOT velocity,gamma FROM flutter

WHERE iter_num=4 AND mach-numl.5 AND rho=C. 0015 AND mode-num=l;

Note that it is assumed that the XYPLOT command is a SELECT where the results are plotted using the first attribute as the x-axis and the second as the y-axis.

Analytical Results - Plot the root locus flutter curve for the tenth design iteration at Mach number 1.25 and density 0.0012 for the first natural mode. XfPLOT REAL ( lambda 1 , IMA'2 ( lahda'

FPOM flutter WHERE iter-nurn=l0 AND

rnach-:ium=l. 25 AND rho=(). 9012 AND mode-num=l;

Mathematical relationships (here the functions R W L and IMAG) can be imposed when selecting data.

Design Results - Plot the objective function design history.

Design Results - Plot the history of the constraint on the Von Mises stress for element 201. XYPLOT it er-num, cval FROM

design-constraint WHERE elem_id=201;

Design Insight - Plot the objective function history as a function of the value of the thckness design variable for element 101. X Y I , G T t, objective

FROM phy-dv, history

WHERE elem_ld=201 AND phys-dv.iter-num=history.iterInwn;

This query joins the entries of the pnys-dv and his- t o r y relations on their common attribute it er-num.

7. Design Insight - Study the affect of the design itera- tions on the location of the x location of the center of gravity by plotting the objective function history as a function of the location. XYPLOT x0,objective FROM welght,history WHERE weight.iter-num=hlstory.l:er-~um;

Another example of the join of two relations.

Flexibility

While the casual observer might think that all of these specific queries could easily be implemented in the MDO system, as they well could, the importance of the query language is its infinite flexibility. Once the MDO data has been modeled, a designer is free to formulate any query against a data entity or jointly among enti- ties. The use of such queries against the masses of data shown in Table I is crucial because complete, unre- stricted views of the data are not possible, and any a priori selection of data may prove erroneous.

Additional Features

Software Integration

While this paper has been devoted to describing the in- terrelationship of database technology to MDO, it has fo- cused primarily on data representation and queries. As indicated earlier, eBASE also provides an application pro- gramming interface w h c h can be used as a framework for integrating software applications. Figure 3 illustrates how software islands can be enveloped by a common database and software engineering tool.

APPLICATION PROGRAM

Figure 3 Integrating applications software

Data Portability

By using mature database technology, the portability of data is substantially enhanced. This is because the well-de- fined, consistent, and self-contained schema of the data- base entities allows the creation of files which may be ex- ported across both homogeneous and heterogeneous com- puter networks. For example, eBASE provides this capabil- ity using the IEEE standard for floating point data repre- sentation to export a database that may then be imported on a different cbmputer.

Parallel and Distributed Processing

The widespread use of distributed computing and both modestly and massively parallel architectures will most certainly occur in this decade. Database technology must be extensible to these environments. Many issues impact- ing DBMS are discussed by DeWitt and ray" and are beyond the scope of this paper. Because MDO is a prime candidate to take advantage of such powerful computa- tional engines, database design must include the necessary provisions to support this technology transfer.

Summary

This paper has described the relationship between two technologies of major importance in the product develop- ment cycle: multidisciplinary design optimization and da- tabase management systems. It has identified the special needs of scientific databases in general and those required by MDO in particular.

It has used a new database, called eBASE, to illustrate the features most needed for scientific software. An MDO

example for an aircraft system which shows both the great volume of MDO data and how the relational database can be used to model and access such data to improve the insight into the design process was shown. Finally, other important database features which enhance data manage- ment facilities now and in the future have been discussed.

Acknowledgments The authors would like to acknowledge Mr. D.J. Neill,

formerly of Northrop, who has recently joined UAI. His valuable insight into the aircraft design process and expe- rience in MDO has been welcomed. They would also like to thank Dr. V.B. Venkayya of the U S . Air Force Wright Research and Development Center (WRDC), Flight Dy- namics Laboratory, for his energetic support of MDO soft- ware development in general, and ASTROS in particular, for many years.

References '~erendeen, D.L.; Hoesly, R.L.; Johnson, E.H.; and Venkayya,

V.B., "Astros - An Advanced Software Environment for Auto- mated Design," Proceedings of the 27th Structures, Structural Dy- namics, and Materials Conference, San Antonio, TX, 1986, pp. 59- 66.

2 Neill, D.J.; Johnson, E.H.; Canfield, R., "Astros - A Multidisci- plinary Automated Structural Design Tool.", Journal of Aircraft, Vol. 27, No. 12, 1990, pp. 1021-1027.

3~erendeen, D.L., and Ludwig, M.R., "Interactive Computer Automated Design Database (CADDB) Environment User's Man- ual." Report AFWAL-TR-88-3060, Wright Research and Develop- ment Center, August 1988.

4~erendeen, D.L., Ludwig, M.R., and San Marco, J. "eSHELL the eBASE Interactive Interface User's Manual." Publication eB- 001, Universal Analytics, Inc., May 1992.

5~erendeen, D.L., Ludwig, M.R., Hoesly, R.L., and San Marco, J. "eBASE:APPLIB The eBASE Applications Programming Inter- face Programmer's Manual Version 2.0." Publication eB-003, Uni- versal Analytics, Inc., May 1992.

6~elippa, C.A. "Database Management in Scientific Compting - 1. General Description." Trends in Computerized Structural Analp- sis and Synthesis, A.K. Noor and R.J. Hayduk, eds.,Pergamon Press Ltd.,1985.

7 h o n . , " ~ ~ ~ RIM Relational Informational Management Sys- tems. Version 6.0 User's Guide.", Boeing Computer Services Com- pany, 1983.

'~ilberschatz, A,, Stonebraker, M., and Ullman, J.A., eds.,"rlata- base Systems: Achievements and Opportunities," Comrnunimtions of the ACM, Vol. 34, NO. 10, 1991, pp. 110-120.

'~avis , J.M. "Database Requirements for the CASE Enbiron- ment." Database Programming & Design, Vol.1, No. 10,October 1988, pp. 62-71.

l0IIeWitt, D., and Gray, J., "Parallel Database Systems: The Fu- ture of High Performance Database Systems," Communications of the ACM, Vol. 35, No. 6,1992, pp. 85-98.