A database design method for finite element analysis

Computers & Strucrures Vol. 44, No. 4, pp. 91 l-914, F’rintcd in GreatBritain.

co45-7949192 smo + 0.00 Pergmon Press Lid

1992

TECHNICAL A DATABASE

DESIGN

NOTE

METHOD FOR FINITE ANALYSIS

ELEMENT

YANG XINGIIAN Computing Technique Institute, P.O. Box 90, Xian, P.R. China (Received 24 January 1991; revised 21 May 1991) Abstract-Recently, many application programs have been applied in design and analysis disciplines. With the increase in the numbers of programs, the absence of standardization and lack of coordination among software developers have resulted in difficulty in data communication from one program to another. The result is often manual transfer of data with the associated manpower loss, time delay, and potential for error. Therefore, the efficiency of design studies is often more dependent on the coordination programs and their data interchange requirements than on the processing speed of the computer. CIEM (computer integrated engineering and manufacturing system) was organized to realize a common need to integrate many standalone engineering analysis programs into a coordinated efficient design system. In order to integrate many programs, such as CAD/CAM, aeronautical and structural programs, a central database is used for data communication to all separated programs. To extract shareable information among programs, a data exchange specification was defined. By means of the specification, some support tools and automated procedures are developed to aid the database design process. These utilities are used to construct a data dictionary and database schema, generate the subroutines to read from or write to the database, and incorporate the analysis into the database.

1. INTRODUCTION

Two interfaces have been proposed by the CIEM project. The first of these is a specified set of subroutines to translate the input or output files of the programs into UF. The second interface is a common set of subroutines to translate UF into the database configured to aid FEM modeling operations. The translator system is shown in Fig. 1.

Some programs for FEM have been integrated into CIEM. In order to extract information for the FEM field, a data exchange specification was defined; by means of the specification, the programs can communicate with a database. A data analysis technique for finite element database was introduced. In order to maintain the integrity of the database. some criteria for constructing the data model were used. Using these techniques, a fin& element database has been created and implemented in CIEM. As an example a simple data model of the finite element database is given. 2. INTEGRATION

FOR FEM PROGRAMS

3. TRANSLATIONBETWEEN MODELING

DIFFERENT FEM DATA

The data translation between different FEM programs is shown in Fig. 2. The FEM modeling data for program A are translated to UF by pre-processor
IN CIEM

Some FEM programs were integrated into CIEM as a subsystem. With the increase in the number of integrated FEM programs, there is a desire for increased mobility of data both internally within the subsystem and externally to and from other subsystems. The translation of data from the format of program x to that of program y is necessary. When only two programs are involved then only two translators are needed (x to y and y to x). but when the number of programs increase the number of translators required is large [for n programs, a(- 1)/Z translators are needed]. From the point of view of support and maintenance, this large number of translators becomes unmanageable. To overcome this problem some sort of standard format is needed so that for each program only two translators are required (program x format to standard and standard to programx format). Most data translated between different FEM programs are shareable, such as node, element, physical property, material property, etc. A standard file format for these data, called the universal file (UF), is defined. The UF. like the universal file for SUPERTAB. is coded in ASII, with 80 characters per record and appears logically as a card deck. 911

Pro.,rams for FEM

Input or output file for the programs Translators l/O file to UF

Universal file

Translator UF to DB

6 FEM

Database for FEM

DB

Fig. 1. Block diagram of translator system.

912

Technical Note

FEM program

A

Preprocessor

according

Postprocessor

-

-

FEM program

B

lfpF

_

t UF/DB processor

I

;I” FEM DB

Fig. 2. Principle of data exchange via UF. can use post-processor to translate the data that are obtained from FEM database by UF/DB processor. The UF defines a shareable entity set for FEM model that is stored in the FEM database.

4. MODELING

OF DATA FOR FEM DATABASE

A database of FEM is a collection of non-redundant data shareable between different finite element analysis systems, A better approach of the collection is known as entityrelationship modeling of data. The sequence of operation is: (a) select the entity (such as elements, node and load), and the relationships between them, which are shareable to different application systems for FEM, (b) assign attributes to these entities and relationships in such a way that a set of well-normalized tables is obtained. We have applied a relational DBMS (database management system) to process the data model for FEM. In relational system entities and relationships are represented as tables. The table contains some columns each headed by the name of an attribute type. The intersection of each row and column in the table contains an attribute occurrence. Having these tables, we can use a relational database language known as SQL to create and to manipulate them. The entire information content of the database is represented as explicit values. This method of representation (as explicit values in column position within rows of tables) is the only method available in a relational database. Specifically, there are no ‘links’ or pointer connecting one table to another. In relational systems foreign-to-primarykey matches represent references from one table to another. They are the ‘glue’ that holds the database together. A primary key is one of the candidate identifiers. An identifier for a table is an attribute (or attribute combination) which can never have duplicate values within a table occurrence, and whose value is therefore always sufficient to identify a row. A composite identifier may not contain any superfluous attributes. None of the component attributes of an identifier may have null values. In general, a foreign key is an attribute (or attribute combination) in one table B whose values are required to match those of the primary key of some table A (A and B not necessarily distinct).

5. ENTITY-RELATIONSHIP

MODELING

We will now discuss the relationship between entities. 5.1. Entity-relationship diagrams One of the methods which represents the relationship between entities is the entity-relationship type diagram (known as E-R diagram). Figure 3 gives an example of E-R diagram between node and load types. The conventions which will be used in drawing an E-R diagram are that entity types will be represented by rectangles and relationship types by a name above the connecting line between two entities. The connecting line shows the association between entity types. Each entity type is named. The relationship degree is represented beside entities. The relationship degree may be 1: I, 1: N, N: M. 5.2. Membership class If every occurrence of an entity participates in the relationship, the membership for the entity is obligatory, otherwise, if some occurrences of an entity are allowed to exist independently, the membership is non-obligatory. The notation will be used to represent membership class on the E-R diagram. A blob outside an entity symbol means that the entity’s membership class is obligatory, otherwise it is non-obligatory. Knowledge of the membership classes of entities is important, and it may help us to design foreign-toprimary-key matches for data models. For example every load must apply on a node, but not every node must have loads in Fig. 4(a). The fact that node has non-obligatory membership means that attributes of load are not attributes of node in general, but are attributes only of certain nodes. To include all node and load attributes in a single entity table type would have the drawback that some entity occurrences (rows in the table) would have null value for the load attributes [Fig. 4(e)]. To overcome the drawback, the table will be separated into two tables, so that each new table will contain those attributes

I

I

1 I

Node

,

Fig. 3. An entity-relationship

I

I

1-1

Load I

type diagram.

1 I

913

Technical Note

(b) If membership of the ‘many’ entity type is nonobligatory, define three table types, one for each entity and one for the relationship. For a many :many relationship the rule is as follows: (a)

(a) Regardless of membership class, define three types, one for each entity and one for the relationship.

A simple finite element structure.

6. FURTHER

Node (b)

1

p

1

N-L’

Load

The E-R diagram between node and load. Node (N#;**) ...N#) Load (L#, - Lx, Ly,

L Posted

(c)

identifier

The table type Node

Load L#

Lx

Ly

N#

1

0

500

1

NORMALIZATION

As already indicated in a previous example [Fig. 4(d)], when each table contains information about one entity type and one entity type only, the design will be easier to understand, easier to use, and easier to extend when new information is added to the database later on, than a design in which information about multiple entity types is bundled together into a single table. Having an existing design, we can use normalization theory to check the design. The overall purpose of the normalization is to eliminate redundancies in tables. A better design is that each attribute in a table directly depend on its candidate identifier. A table which obeys this rule is said to be in Boyce/codd normal form (BCNF). We consider that a table which obeys the Boyce/codd rule is a wellnormalized table and it is good enough to describe the engineering problem. 7. AN EXAMPLE FOR A SIMPLE DATA MODEL OF FINITE ELEMENT DATABASE

(d)

Separate table occurrence for node and load

N#

1 X 1 Y 1 L# 1 L, 1 L, 1

An E-R diagram for a subset of the data model of finite element database is given in Fig. 5. It includes some entity types for statistical analysis field. It will be convenient to start by building a skeleton E-R model in which the table types contain only identifier and foreign key. The attributes of these tables are respectively described as follows: (a) The table of element Element (E # , Phyref, Phy, Matref, Mat, . .)

(e)

A single table for all attributes of node and load

Fig. 4. One-to-one relationship. Membership obligatory for only one entity type. which are directly dependent on its primary key. The relationship can be represented most simply by posting the primary key of node into the load type, as shown in Fig. 4(c). The primary key of the table type will be denoted by an underscore in Fig. 4(c). An entity or relationship type which is not represented by its own table type will be marked with an asterisk in Fig. 4(b). Notice that the posted primary key forms a logical link between a node occurrence and a load occurrence. The attribute N # is a foreign key in table load.

E#

Element number Phyref Reference number of physical properties Phy Physical property ID Matref Reference number of material properties Mat Material property ID. (b) The table of node Node (N # , Coor # , . . .) N # Node number Coor # Coordinate system number (c) The table of coordinate system Coordinate (Coor # , .) E-Mat’

Mat-property

- E-Phy’

:

= Element

=

- Phy-property

1

M,

M

1

1

5.3. The rules offoreign-to-primary-key matches For a 1: 1 relationship the rules are as follows:

(4 09

(4

If membership is obligatory for both entity types, put all attributes into a single table type. If membership is obligatory for only one entity type, define two table types, one for each entity, post the primary key of the non-obligatory entity into the obligatory entity’s table type. If membership is non-obligatory for both entity types, define three table types, one for each entity and one for the relationship.

E-N

N-Res

Restraint

-

M

.

t

_

Node N

N-LD

,N

Load-set

M

For a 1: many relationship the rules are as follows: (a) If membership of the ‘many’ entity type is obligatory, ddine two table types, one for each entity, post the primary key of the ‘1’ entity into the ‘many’ entity’s table type.

Fig. 5. An E-R diagram for a simple data model of finite element database.

914

Technical Note 11002 MOFlLEi

1 25 POINT

86A MPCEQT

Fig. 6. The E-R diagram for FEM subsystem. (d) The table of physical property Phy-property (Phyref, Phy, . .) (e) The table of material property Mat-property (Matref, Mat, (f)

The table of load set Load-set (Ldst # ,N # ,

Ldst # Load set label (g) The table of restraint Restraint (Rst N # , - # ,~

,)

,)

.)

Rst # Restraint set table (h) The relationship between element and node E-N (E -~ # , N # , .) (i) (j)

The relationship between load and node N-LD (Ldst -~ # , N # , .) The relationship between restraint and node N-Res (Rst # , N # , . .)

8. E-R

DIAGRAM FOR FEM SUBSYSTEM IN CIEM

Figure 6

shows the E-R diagram for a FEM subsystem. The entity names are: MOFILE MODEL NODES COORS POINT LINE ARC SPLINE SIDE SURFAC RD32 DISP LD35 LOAD VOLUME NDAC ELAC ENAC ELMNT PHYF’R PHYVA MATPR

relationship between models FEM models nodes coordinate systems points lines areas splines edges surfaces restraint set restraint values load set load values volumes analysis data at nodes analysis data on elements analysis data at nodes on elements elements physical property value entries physical property values material property value entries

MATVA MPCSET MPCEQT MPC Others

material property values multipoint constraint set multipoint constraint equations multipoint constraint values relationships between entities 9. CONCLUSION

The FEM systems currently available differ not only in their different application aims and performance levels, but also in data structure and data format on which each internal ‘FEM model’ is based. The data from one internal representation in a FEM system are not converted directly into another representation, but first into a common, system-independent data format. Conversion into any other format is done in two steps. This method requires a standardized data interface which is the basis for all processing operations. With the exception of special applications, the exchange of data via a standardized interface is certainly the only economical and sensible alternative in the long run. A standardized interface, called UF, has been developed for FEM subsystem in CIEM. The UF is based on the common set of shareable entities and their relationships for different FEM programs. These entities are stored into FEM database to aid FEM modeling operations, such as INSERT, DELETE and UPDATE. In order to reduce data redundancy and to maintain data consistency, a data base design method is introduced. REFERENCES

1. C. J. Date, An Introduction to Database Sysrems, Vol. 1, 4th Edn (1986). 2. C. J. Date, Relational Database: Selected Writings. Addison-Wesley (1986). 3. J. Martin, Computer Darn Base Organizalion. PrenticeHall, Englewood Cliffs, NJ (1977). 4. D. R. Howe, Data Analysis for Data Base Design. Edward Arnold, London (1983). 5. P. Chen, The Entity-Relationship Approach to Logical Data Base Design. Q.E.D. Information Science (1977). 6. J. Encamacao, R. Schuster and E. Voge, Product Data Inferfaces in CAD/CAM Applicarions. Springer, Berlin (1986). 7. W. D. Engelke, How to Integrale CAD/CAM Syslems. Marcel Dekker (1987).