Engineering Databases

Contents

Part I : Advanced Databases for Engineering Applications
1. Introduction
1.1 Conventional product engineering
1.2 Design tools
1.3 Issues in engineering databases

2. Database technologies for engineering applications
2.1 Object-oriented database
2.2 Active database
2.3 Constraint management in database

Part II : Review on Engineering Database Applications
3. Modeling for complex design objects
3.1 Taxonomy for a part data
3.2 Object-oriented class schema for assembly product
3.3 Object-oriented class schema for CSG modeling

4. Verification and maintenance of the engineering constraint
4.1 Characteristics of engineering constraints
4.2 Engineering constraint and conflict resolution
4.3 Virtual class for constraint definition and management

5. Long duration transaction
5.1 Nested transaction
5.2 Session and hypothetical transaction
Contents

6. Versioning design objects
6.1 Conventional version control
6.2 Version control using prototypical objects

7. Engineering information system
7.1 GLIDE (Graphical Language for Interactive DEsign)
7.2 ROSE
7.3 SDM (Shared Design Manager)

8. Product data exchange standard
8.1 PDES/STEP history
8.2 PDES/STEP overview
8.3 EXPRESS formal specification language

1. Introduction

Conventional product engineering

1. determination of product specifications
2. conceptual design
3. engineering design and analysis
4. detailed design and blueprint review
5. manufacturing process planning
6. quality assurance planning, MRP, and production planning
7. production/quality assurance
8. assembling the products
9. 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 Database [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 -&GT 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-&GT 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 - &GT 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

2. Database Technologies
for Engineering Applications

Basic Concepts of Object-Oriented Database

• object - all conceptual entities
• attribute - some private memory that hold object's state
• method - procedures encapsulate the behavior of objects
• message - a medium through which an object can communicate with one another
• class - a set of similar objects; all the objects described by the same set of attributes and methods
• inheritance -
• domain - the domain of attributes can be other classes

Schema Evolution in Object-oriented Database

• Schema - the class definitions and the inheritance structure of the class lattice
• Conventional databases (e.g. SQL/DS) provide dynamic creation and deletion of relation and addition of new columns in a relation without requiring system shutdown
• Program language oriented databases have deficiencies for schema change
• Taxonomy of schema change and invariant

Taxonomy of schema change and invariant

• Changes to the contents of a node
  Changes to an attribute
  Changes to a method
  Changes to an edge
  Changes to a node
• Invariance
  Class lattice invariant
  Distinct name invariant
  Domain compatibility invariant

Transaction Management in Object-oriented Database

• Serializable transaction
• Session - a sequence of transactions
• Long duration transactions as a set of transactions, rather than a sequence of transactions
• Any active transaction of a session will compete for resource with those of all other session
• Normal and Hypothetical transaction - a transaction which always aborts.
• Experimenting with the effects of 'what-if' changes to the database

Event-Condition-Action Rule[Urban1994]

• The event specifies an operation or situation to be monitored
• When event occurs, the condition is then evaluated
• If the condition is true, the action is triggered automatically by database systems
• Alter, Trigger, Integrity Maintenance Rule (IMR)
• Alter - no action only send message to the user
• Trigger - causes a specific database or application action
• IMR - specifically developed to maintain constraints

An Active Database Model[Beeri1993]

• In active databases operations can act as triggers that cause the execution of other operations.
• Its advantages include, among others, code reuse, and centralization of code storage and management.
• model of nested transactions in which transactions can have sub transactions, thus allowing for a hierarchical organization of processing.
• Object-oriented database supports the representation of data processing in the form of code.
• Active Database, OODB, nested transactions

What an active database model needs

• How are triggers specified;
• When are triggers enabled and executed;
• How is the environment of trigger execution specified and implemented;
• How do we specify and concurrently enabled triggers.

The Database Model

• Object, Methods, Classes and Encapsulation
• Encapsulation : An object encapsulates both data(its state) and behavior(its methods) and can only be manipulated using the(external) methods associated with it.
• Postulate that the methods are the triggering events.
• The triggered operations are methods.
• OODB's allow redefinition(overriding) of methods in subclass, even redefining methods for individual objects in a class.
• In the nested transaction model a transaction may execute both operations and sub transactions.

Methods and Triggered Actions

• TYPE method = [ m-name, m-code]
• extension for triggers
• TYPE method = [m-name, m-code, {triggered-action}]
• triggered-action is name of an action.
• An Example
• Database stores information about customers account and calculate total balance of a customer's account.

Triggered Actions Scheduling

• When should the trigger be executed?
• In HIPAC ; immediate, deferred, and decuple execution
• execution interval: in which triggered action should be executed
• example: update-account before get-balance
• TYPE execution-interval = [start-event, end-event]
• Two observations; execution in appropriate time, possibility of defining interval.

Failures

• transaction management sub language: used in triggered action definition for specifying what should be done in the various failure case
• Triggering Method Failure
• Either case; roll back of triggered action, execution as planned (log system example)
• HIPAC's decoupling mechanism
• Independent from top transaction (ignore, abort)
• Failure in execution interval specification

Triggered Action Failure

• example of recalculation of balance
• If recomputation(triggered-action) is fail,
  1) roll back the balance update that triggered it
  2) retry to execute and block retrievals of the total balance
• &QUOT Try to run the action at lease 5 times and if they all fail try to run t instead. If t also fails, abort the transaction&QUOT

The Triggered Action Description

• should include action and target object
• TYPE triggered-action-description =
  [triggered-action,
  act-to-perform(location, parameters),
  execution-interval,
  scheduling-information,
  triggered-action-fail, trigger-fail]
• triggered-action :- name of the trigger
• act-to-perform :- name of the action to be taken
• scheduling-information :- priority and etc.

Active Objects

• structure used for storing information about triggered actions until executed.
• for each action waiting for execution
• TYPE active-action =
  [triggered-action(parameters),
  triggering-method-identity(location),...]
• location describes the object where the triggering method executed

Methods for Handling The Active Part

• inserting, retrieving and executing, and deleting active-actions
• use for every triggered-action

An Execution Model

• So far what information and how it is recorded
• method processor
• General Execution Plan
• set of actions
  T1 : do not use any of parameter off M or do
  T2 : Scheduled after m terminates

Sub Transactions

• When m is invoked method processor contains 5 sub-transactions
  1) insert-start-m : inserts records of T1 into the active part of the object
  2) execute-start-m : execute actions before m
  3) executes the method m
  4) insert-end-m
  the values of output parameters of m are well defined
  5) execute-end-m

Notifications and Subtransactions

• notification about success or failure
• determines the course of action
• actions triggered by other methods can be sub transaction
• they are almost identical( execute-start-m)
• maintenance - examine execution intervals, mark start event happened, mandatory
• choose - a set of actions is chosen for execution
• execute - parallel or serial execution execute-start-m, triggered-action-fail

The general Multi Object Model

• Concurrence Control, Failures, and Recovery
• if an action is fail the execution m may delay
• key word 'independent'
• concurrence is applied to active part of object
• The general Multi Object Model
• The triggering method and triggered actions may operate on different objects
• Event mentioned in the execution interval may occur in other object
• Where the triggered actions be stored?
• How the process in a object know about event occurs in other object ?

Notification and Time Events

• The Notification Mechanism
• decompose the triggered action into a notification action
• send-notification, receive -notification
• receive-notification is a method and is executed by the method processor
• Time Events
• active object ,timer
• triggered action contains a time event
• the time event contains a triggered action to send notification when the time arrives.

Constraint Management in Database[Urban1992]

• The database research community unanimously aggress that rules will become a major feature in future database systems
• deductive rules, production rules, integrity constraints
• deductive rules -&GT derived class (view)
• production rules -&GT trigger (premise, action)
• integrity constraint -&GT restrict the set of valid state of the database
• the declarative representation of integrity constraints in an OODB and the use of active database rules for the maintenance of constraints

Integrity Maintenance Production Rule: Constraint Analysis

• an approach to the declarative representation and analysis of schema semantics
• 
  1) the constraints associated with semantic schema:
  sub class relationship, inverse properties, required properties, one to one relationships, and disjoint constraints
  2) explicit constraints in a logic-based constraint language
  -&GT IMPR (with triggers)
• CONTEXT : a tool for the explanation of constraints
  

Ship Schema Example(1)

• Required Property Constraint:
• ship(S) -&GT country-of-registry(S,fc(S))
• Unique Property Constraints:
  ship(S1)&AMPship(S2)&AMPnot-equal(S1,S2)&AMPsname(S1,N)&AMPsname(S2,N)-&GT.
• IMPR:
  EVENT: insert ship(S)
  COND: not country-of-registry(S,fc(S))
  ACTION: select o1 from country
  modify country-of-registery(S,o1)

Example (2)

• Explicit Constraints
• All S in ship IMPLIES(S.conutry-of-registry=S.commander.officer-assigned.citizen-of);
• IMPR
  EVENT: modify country-of-registry(S,C)
  COND: not (commander(S,ff(S,C))and
  officer-assigned(ff(s,c),fg(S,C))and
  citizen-of(fg(S,C),C))
  ACTION: select o1 from officer where citizen-of(o1,C)
  insert o2 in assignment
  modify commander(S,o2)
  modify officer-assigned(o2,o1)
  

Example (3)

• Level 1- Inverse Property Constraint
  EVENT: delete ships-registered-here(C,S)
  COND: if country-of-registry(S,C)
  ACTION: delete conutry-of-registry(S,C)

• Lebel2- Constriant ec0
  EVENT: delete country-of-registry(S,C)
  COND: if commander(S,A) and officer-assigned(A,O)
  and citizen-of(O,C)
  ACTION: delete citizen-of(O,C)

• level3 - Inverse Constraint
  EVENT : insert country-of-registry(S,C)
  ACTION : insert ships-registered-here(C,S)

3. Modeling for Complex Objects

Taxonomy of part informationl

A engineering database conside ring CAD, FEM, NC, Production Plan System machine parts
fixed characteristics
variable characteristics
organizational data
security control data

Taxonomy of part information

fixed characteristics: classification - class of part mode - assembly or a single part designation - addressing the machine part id number date material
variable characteristics: measurement
organizational data: organizational hierarchy

Object- oriented class schema for assembly product

describe complex product relationship with:
· class inheritance
· class composition
· aggregation types
· method
· encapsulation

Types of Versions [Kim90] ·

Transient version
- can be updated by the user who create it
- can be deleted
- derive new transient version, promoted

Working version
- stable, cannot be updated
- can be deleted by its owner
- explicit and implicit promption Binding object with other objects· Static
- reference to an object includes the full name of the object, the object ident ifier and the version number
· Dynamic
- object identifier
- useful as transient or working versions that are referenced may be deleted, n ew version created Implementation·

generic version attri butes
- default version number
- next version number
- version count
- version descriptions
· control informaiton
- the version number of the version
- the identifier of the version object
- a list of references to the descriptors of child versions
- version number, version type, generic object id

Concepts f or Version Management [Ahmed89]

· Distinct snapshots of a design object in different states and share some identifiab le common characteristics
· When two instances of the same type are different objects and when they are merely different versions of the same object
· intrinsic and non intrinsic attributes Version of an object
· Different versions of a design object share the same interface but may have different intern al assemblies
· Interface defines the functionality of the object and is visible to the external world
· Changes in the internal assembly (type and instance level) of object are not visible to the external world and may thus warrant creation of only a different version

Generic, Versioned and Unversioned Objects
l Three types are mutually exclusive
l Invariant properties are invariant over the version set
l Generic object is characterized by its invariant external features
l There is only one generic object for each version set
l All versions have identical interface attributes Version Graph
· A version graph captures the evolution history of version objects
· Disconnected, directed, cyclic graph
· The edges represent the successor/predecessor relationship

Versioning at the Type and Instance Levels
· Versioning should be allowed both at the type and instance levels
· Versioning at the instance level implies that different versions of the same object differ only in the values of some of their properties
· Versioning at the type level means that different versions of an object can have different assigned types Classification of Version Attributes
· Invariant, version-significant and non version-significant
· Version-significant attribute - modifications in these attributes create a new version (mutation)
· Non version-significant attribute - always be modified without causing a ny mutation
· invariant - can not be modified at the version level, value acquired fro m the generic object Version State
l Non atomic update
l Validated
- No modification
- All the constituent references in a validated version are either unversioned or validated version
- New versions enable Version State (Stable, Transient)l Stable
- Version significant attribute can not be modified
- Non version significant attribute can be modified
- New version enable
l Transient
- All new created and derived version begins in the transient state
- All noninvariant attributes can be modified
- New version disable Version Operations
l Promote - from transient or stable to stable or validate
l Create - from generic to transient (version no, no content)
l Derive - from stable or validate to transient (version no, copy contents)
l Convert - from unversioned to transient (add generic type) Version Operations (fig)

Prevention of Version Proliferation
l Uncontrolled propagation of updates can proliferate to the top of composite object
l Version equivalence and interchangeablity
l Different versions of a constituent object without having to create a new ver sion of its composite object Example
Example
4. Verification and Maintenance of Engineering Constraint
Characteristics of engineering constraints
·

Large number of complex rules

Several levels of local and global rules

Checking and/or enforcing rules at arbitrary points in time, often under external control
·

Arbitrary reactions in case of rule violation
·

Declarative and algorithmically rule definition
·

Integration of existing programs and action plans
·

Dynamic definition of rules Constraint Management using the HVC


• Control Architecture
  Engineering Information Systems
  
• GLIDE
  
  Graphical Language for Interactive DEsign
  · C-MU, 1980, Building Description System embedded in a general programmin g language
  · allowing schema extension, integrity management, exploration of design a lternatives
  · project database module, System Invoked Routines (SIR), Checkpoint files
• ROSE
  · Handwick, CAD database
  · translates constraints specified in EXPRESS into two types of methods in an application.
  · The first is database methods that are always associated with objects,
  · the second is application methods that exist as database applications. Iterative Constraint Administrator
  
• Iterative Constraint Administrator· Management of engineering constraint
  Based on active object oriented database
  Support the backward propagation
  Constraint management with database-supported resources
  Support integration of various database applications without additional facilities for constraint checking Conclusion
  Problems of database application for engineering domain
• complex design ob jects, constraint management, version control, long duration transaction, integration of applications
  Try to provide resolution paradigms, techniques, systems, and ideas for the p roblems
  Uncovered topics - multi database, warehouse(meta data), and C/S in engineeri ng applications
  Integrated system architecture - c.f. SDM [Urban94]
  

7. Introduction to PDES/STEP
EXPRESS Language Overview

EXPRESS is a formal information modeling language used to specify the information re quirements of STEP

EXPRESS is specified in the ISO 10303-11 standard

Both humans and computers can interpret the language, although it is not a pr ogramming language.

Though it has been specifically developed for the specification of both integ rated resources and application protocols of STEP standards

It may be used as a general modeling method in its own right Constructors for Integrity Constraints

EXPRESS has three kinds of constructors for integrity co nstraints, called rules

EXPRESS rules can be classified into two categories according to the scope of each rule.

The first category, Local rule, concerns constraints within an entity . Thes e kinds of rules include Unique rule and Domain rule.

The second category, Global rule, defines constraints over several entities., Rule is a Global constructor in EXPRESS. Unique rulel The Unique rule in EXPRES S which follows the UNIQUE keyword is similar to the unique statement of SQL

It can specify either a single attribute or a list of two or more attributes to be associated with a unique instance of the entity type.

ENTITY torus;
ID : STRING;
IN_RADI : NUMBER;
UNIQUE ID;
END_ENTITY;

Domain rulel The Domain rule that follows the WHERE keyword de fines another kind of the Local rule.

It can be applied to instances of only one entity type.

The Domain rule restricts the value of attributes within constraints defined by a logical expression that follows the

WHERE keyword

ENTITY torus;
IN_RADI : NUMBER;
OUT_RADI : NUMBER;
WHERE IN_RADI &LT OUT_RADI;
END_ENTITY;

Rulel It permits the definition of constraints which apply to the a ttribute values of the different entity types.

It is similar to a database application procedure.

The Rule can also contain a where clause which constrains attribute values of the entities.

Rule Example

RULE max_radi FOR (torus)
LOCAL; a_torus : torus; END_LOCAL;
a_torus = QUERY(temp&LT*torus | temp.ID = *torus #1*);
WHERE a_torus.OUT_RADI &LT 100;
END_RULE;