...
...
...
...
...
...
...
...
...
...
...
...
...
...
EXPRESS Schema
An EXPRESS Schema is defined according to ISO 10303-11. It defines information requirements and defines the database structure with constraints. In EXPRESS Data Manager™ it is also denoted as the Underlying Schema. EXPRESS Schemas are defined by a majority of industrial data standards, and are generally freely available. EXPRESS models can also be defined in a text editor or by a case tool such as _EDMvisualExpress.
EXPRESS-X Query Schema
The QUERY Schema is defined in EXPRESS-X and always connected to an underlying EXPRESS Schema. The purpose is:
...
Many QUERY Schemas can be connected to one EXPRESS Schema.
EXPRESS-X Map Schema
The MAP Schema is defined in EXPRESS-X and defines its own dictionary model. It is a specification at the EXPRESS Schema level, how to map data between different databases:
- to copy a dataset from many source databases to a new target database (EDMmodel)
- to merge dataset into an existing database including all business logic to reject, modify or create instances.
EXPRESS-X Rule Schema
he RULE Schema is defined in EXPRESS-X and always connected to an underlying EXPRESS Schema. It can be used to define any kind of rules and constraints to the underlying schema:
- Any business rule
- Rules defined by industry organizations, government authorities, countries
- Rules defined for data exchange, data merge, and data consolidation.
Many RULE Schemas can be connected to one EXPRESS Schema
The rule schema concept enables you to define additional rules and constraints for existing EXPRESS schemata. This means, for example, that after you have validated the use of the basic rules in the schema, you can separately validate any additional rules. This can be useful, for instance, when validating business rules or engineering rules.
The rule schema can validate a complete model in one call. It can also check all entity instances of a particular type for all applicable rules and constraints. At the lowest level you can check an entity instance against one specific rule or constraint. Validation reports can be presented on the screen, and if desirable, written to a user-specified file.
An ontological model that focuses on extensibility and longevity is different to a business object model that focuses on support of a current process. It makes sense to separate these concepts, and a rule schema is one that interfaces to a generic product model schema adding business process specific constraints. Data instances are stored according to the product model schema, but validated against one or more rules schema. Rule schemas can also interface with each other in a network as shown in Figure 9.
Examples of the use of rule schemas are:
- Multiple design & manufacturing code support
- Multi-discipline product application (interoperability)
- Consolidation of product data from multiple sources to one repository
- Customized data quality checking
Figure 9: Rule Schema architecture
...