Introduction to Engineering Databases
since 25 June, 1998, last modified 25 June, 1998

---

Conventional product engineering and design tools are reviewed. The current issues on engineering database are also discussed in this section

Conventional product engineering

• determination of product specifications
• conceptual design
• engineering design and analysis
• detailed design and blueprint review
• manufacturing process planning
• quality assurance planning, MRP, and production planning
• production/quality assurance
• assembling the products
• packing and shipping

Design Tools

• mathematical calculation/formulas
• hand sketches
• CAD system, finite element analysis (FEA), visualization/simulation programs,
• heuristic, reasoning from an individual's of company's knowledge
• decision/selection method
• tables or catalogues ( engineering handbooks )
• technical charts/graphs
• previous designs ( designer notebooks )
• engineering analysis programs-maybe linked to a CAD package
• codes and standards
• test data/performance records

Why engineering databases? [EASTMAN 1980]

• Reduce costs of preparing data for application programs
• Reduce cost of producing the final specifications
• Improved consistency management with machine readable model
• Provides opportunities for further automation

Current Limitations of database systems [Eastman, 1980]

Their static structure :

• Distinguish and separate the data definition language (DDL) from the data manipulation language (DML)
• alternation of the schema forces re-compilation of the database and its application programs
• Test design alternatives -> need schema change
• solution: the first - developing union of all probable design technology; the 2nd - merging the DDL with the
• DML incremental compilation with runtime extension runtime linking of applications

Limited speed of access mechanism:

• surface-> solid - wide bandwidth needed

Lack of tools to aid integrity management:

• provide very limited facilities for managing integrity in large data structures.
• The design is due to the rich set of relations and constrains that any artifact embodies
• These range from physical laws, laws of gravity, Hooks law, Ohms law, Kinematics, to engineering good
• practices, *The simpler the better*
• If these criteria are not satisfied them the information describing the design is logically of functionally inconsistent - > In database terminology, lacks of integrity
• Some means to centralize or modularize the responsibility of integrity management is called for CODASYL and ANSI standard include procedural attributes

Lack of support for multiple alternatives:

• The nature of design is that it is tentative and iterative Subschema

Issues in engineering databases

• data modeling for complex design objects: complex objects, method modeling, or schema design
• verification and maintenance of design constraint: active database and other intelligent database
• versions for iterative design process : virtual class as a tool for version
• extended transaction processing for long duration of design process: extended transaction models such as nested transaction
• integration of design data for heterogeneous nature of the design data multi-database and product data standards

---

Korean Engineering Databases ¨Ï copyright Namchul Do, 1998