SCM Portal

SCM Knowledge Base

SCM knowledge base represents a hierarchy of XML documents located in one or several root directories, specified with SCM_ROOT environment variable. The root element of a document is “SCM”. The full name of the document file, starting from a root directory, is considered as a name of an appropriate application domain. All objects defined in the file are defined within this application domain. Any other applications domain can refer to these objects by means of their dot-separated full name.

For example, consider two application domains “Production.Material Unit” and “Production.Indiscrete”. The application domains are described in files:

Production\Indiscrete.scm

Production\Material Unit.scm

Let the application domain “Production.Material Unit” declare concept “Material Unit”:

To use the concept, the application domain “Production.Indiscrete” imports it using the concept full name:

<conceptimp>Production.Material Unit.Material Unit</conceptimp>

</import>

Importing allow to use the concept further by last component of its full name. The application domain may not import the concept and use it by full name each time. Each application domain file is to have the extension “scm”. If an application domain has both nested application domains and objects, then this application domain is to be represented both as a directory and as a “*.scm” file. Application domains and objects of each type are to have unique names within an application domain.

SCM Model Definition

Definition of SCM model by means of textual notation is described in [Ov04-4, Ov04-3]. As an example, consider the following short SCM model being the part of a model of a Manufacturing Execution System of an indiscrete production:

Material Unit has a Thickness ®

Material Unit has a Width ®

Material Unit has a Mass ®

Mass Transition is from a Consumed Material Unit ®

Mass Transition is to a Produced Material Unit ®

Mass Transition has a Mass ®

Consumed Material Unit is a Material Unit º

Produced Material Unit is a Material Unit º

Each phrase is a declaration of a connection based on a set of concepts marked with capital first letters. Three types of constrains are used here: the mandatory constraint by underlining, the functional constraint by the symbol ‘®’, and the equivalence constraint by the symbol ‘º’. For detailed discussion of the notation please refer to [Ov04-4, Ov04-3]. Consider definition of the SCM model in the knowledge base. Any application domain can contain a document part used for model definition with the following DTD:

<!DOCUMENT SCM [

<!ELEMENT connection (conceptref+, copula*, rcopula*)>

<!ATTLIST connection equivalent CDATA “false”

biequivalent CDATA “false”>

<!ELEMENT concept (conceptref*)>

<!ATTLIST concept name CDATA #REQUIRED>

<!ELEMENT conceptref (#PCDATA)>

<!ATTLIST conceptref mandatory CDATA “false”

determinant CDATA “false”>

<!ELEMENT copula (#PCDATA)>

<!ELEMENT rcopula (#PCDATA)>

<!ELEMENT import (conceptimp | serverimp | queryimp)+>

<!ELEMENT conceptimp (#PCDATA)>

...

#PCDATA of conceptref element is a full name of a concept, or its last component if the concept is imported. A full name of a concept is a full name of an appropriate application domain, a dot, plus a name of the concept. Mandatory and functional constraints are defined as Boolean attributes of a conceptref element nested to a connection element. If the attribute “mandatory” has the value “true”, the appropriate concept is considered as mandatory within the connection. If the attribute “determinant” has the value “true”, the appropriate concept is considered to be determinant in the connection’s functional constraint. If the connection has the attribute “equivalent” with the value “true”, the connection is considered to be equivalently constrained on two groups of concepts: one group is of determinant concepts, and another group is of non-determinant concepts.

Copula and rcopula elements contains direct and reverse verbal copulas of a connection textual notation. According to SCM properties [Ov04-4] there are additional constraints on this DTD part: each connection has at least two concepts; there is no a connection based on concept set being proper subset of concepts of another connection. Nesting of concepts to other concepts, biequivalence of connections, and importing of servers are used for SCM-RM mapping definition and are not essential for SCM model definition per se.

The given part of DTD allows to define any SCM model with XML. Let the SCM model described above be defined in three application domains: “Production.Material Unit”, “Production.Indiscrete”, “General.Phisical Object”. Consider the first application domain “Production.Material Unit”. First of all, the application domain is to import used concepts of other application domains. The concepts “Thickness”, “Width”, and “Mass” are defined in the application domain “General.Physical Object” to share them in various application domains.

<scm>

<conceptimp>General.Physical Object.Geometry.Thickness</conceptimp>

<conceptimp>General.Physical Object.Geometry.Width</conceptimp>

<conceptimp>General.Physical Object.Gravity.Mass</conceptimp>

</import>

Then the concept “Material Unit” contained in the application domain and connections based on it are to be defined:

<conceptref mandatory="true" determinant="true">Material Unit</conceptref>

<rcopula>characterizes</rcopula>

<conceptref>Thickness</conceptref>

</connection>

<conceptref mandatory="true" determinant="true">Material Unit</conceptref>

<rcopula>characterizes</rcopula>

<conceptref>Width</conceptref>

</connection>

<conceptref mandatory="true" determinant="true">Material Unit</conceptref>

<rcopula>chracterizes</rcopula>

</connection>

</scm>

See full definition of the SCM model example.

SCM-RM Mapping Definition

Before defining SCM-RM mapping rules, we need to create a relational model reflecting the SCM model. Figure 1 presents the ER model created on basis of the SCM model example described above. During ER model creation we have taken some decisions. We have decided to represent our connections with two entities: “Material Unit” and “Mass Transition”. The concept “Material Unit”, functionally determining “Thickness”, “Width”, and “Mass”, becomes the prototype for primary key attribute of the appropriate entity. “Thickness” and “Width” have been grouped to one attribute with the type “GEOMETRY”. “Consumed Material Unit” and “Produced Material Unit” of “Mass Transition” become the prototypes for dependent relationships of the “Mass Transition” entity. Mandatory constraints have been reflected by mandatory constraints of the appropriate attributes, and function constraints have been reflected by primary key constraints and dependent relationships of the ER model. So, the created ER model is equivalent to the initial SCM model. The decisions can be taken automatically from SCM model structure. The appropriate tool of ER model generation will be created in future.

Figure 1. ER Model of Manufacturing Execution System Part

A relational model (relational schema) generated from the ER model is represented at the figure 2. Here, the attributes “Consumed Material Unit” and “Produced Material Unit” have been named according to their senses.

Figure 2. Relational Model of Manufacturing Execution System Part

SCM-RM mapping rules are of two categories: connection-to-relation (connection-to-table) mapping rules and attribute-to-concept (field-to-concept) mapping rules. In our example, the following connections are mapped to the table “Material Unit”:

Material Unit has a Thickness ®

Material Unit has a Width ®

Material Unit has a Mass ®

And the rest of connections is mapped to the table “Mass Transition”. Attributes are mapped to concepts according to their names: all the attributes “Mass” are mapped to the concept “Mass”, the attribute “Thickness” is mapped to the attribute field “Geometry.Thickness” (since the attribute “Geometry” is of the object type “GEOMETRY”), etc.

Definition of SCM-RM mapping rules in the SCM knowledge base is performed according to the following DTD. This DTD is continuation of the knowledge base DTD started above.

<!DOCUMENT SCM [

...

<!ELEMENT table (field+, connectionref*)>

<!ATTLIST table name CDATA #REQUIRED

serverref CDATA #REQUIRED>

<!ELEMENT field (field | conceptref)*>

<!ATTLIST field name CDATA #REQUIRED

pk CDATA “false”>

<!ELEMENT connectionref (conceptref)+>

<!ELEMENT server (#PCDATA)>

<!ATTLIST server name CDATA #REQUIRED

connect_string CDATA #REQUIRED>

<!ELEMENT serverimp (#PCDATA)>

...

Definition of an underlying relational model and SCM-RM mapping is to be done together. The table element contains both field descriptions and enumeration of reflected connections. If a field is of an object type, it contains its constituent fields, otherwise it contains reference to a reflected concept. Since a concept set identifies a connection unambiguously [Ov04-4], a connection reference is a set of concept references simply. SCM-RM mapping requires that each connection not being calculated one is to be based on concepts reflected to all primary key fields of the appropriate table. Primary key fields are marked with the “pk” attribute having the value “true”.

Each table is to have a reference to a server holding it. A server is declared with the help of the server element. The element is to have the attributes “name” and “connect_string”. The attribute “name” is used for referencing to the server. To import a server to an application domain, the serverimp element is used. #PCDATA of the element is a server’s full name. For referencing to a server, its name is to be used if it is imported, and otherwise its full name is to be used. The attribute “connect_string” is a standard JDBC connect string.

In our example, let SCM-RM mapping be defined in the separate application domains “Production Implementation.ISCO_MES.Material Unit” and “Production Implementation.ISCO_MES.Mass Transition”. First of all, a server is to be declared. We declare it in the application domain “Production Implementation.ISCO_MES” to share it between nested application domains.

<scm>

</scm>

Consider the application domain “Production Implementation.ISCO_MES.Material Unit”. Its import part imports the server and the used concepts.

<scm>

<serverimp>Production Implementation.ISCO_MES.ISCO_MES</serverimp>

<conceptimp>General.Physical Object.Geometry.Thickness</conceptimp>

<conceptimp>General.Physical Object.Geometry.Width</conceptimp>

<conceptimp>General.Physical Object.Gravity.Mass</conceptimp>

<conceptimp>Production.Material Unit.Material Unit</conceptimp>

</import>

Then the table “Material Unit” and its mapping to the SCM model are to be defined.

<field name="MATUNIT_ID" pk="true"><conceptref>Material Unit</conceptref></field>

<field name="THICKNESS"><conceptref>Thickness</conceptref></field>

<field name="WIDTH"><conceptref>Width</conceptref></field>

</field>

<conceptref>Material Unit</conceptref>

<conceptref>Thickness</conceptref>

</connectionref>

<conceptref>Material Unit</conceptref>

<conceptref>Width</conceptref>

</connectionref>

<conceptref>Material Unit</conceptref>

</connectionref>

</table>

</scm>

See full definition of the example of SCM-RM mapping rules.

Named SCQL Queries Definition

The last part of SCM knowledge base DTD serves for creation named SCQL queries on basis of a SCM model. A SCQL query is a tree of selection operations of the types: connection selection, transformation, composition, union, minus, and logical selection. A connection selection is always a tree leaf. It selects data of a connection indicated by a set of concepts. After selecting data, each concept can get a role it plays in the query. So, the result signature of a connection selection is a set of role concepts, where each role concept is a concept plus its role.

A transformation operation serves for changing signature of a subquery. A subquery is a tree of selection operations that is nested to the transformation operation. A signature of the subquery is a signature of its root selection operation. Signature change process can include projection, grouping and role concept calculations at the same time. Actually, each transformation determines a set of result role concepts and the way of their calculation on basis of role concepts of a nested selection operation. A result role concept can be included immutably, or it can be calculated using an algebraic formula. The last operation of the formula can be an aggregate function. Grouping of data is applied implicitly if at least one aggregate function is used. In this case, grouping is done on those result role concepts that are not used in aggregate functions.

A composition operation is an analogue for a join operation. The main distinction is absence of an explicit join criterion. A composition operation is based on a set of nested selection operations of any type. No any additional information is specified for it. Nested selection operations are composed according to role concepts identity. The result signature does not contain identical role concepts repeatedly.

A union and a minus are analogues for relational union and minus. The main difference is possibility to apply these operations to nested operations having different signatures and arities. The operations are performed not according to column alignment, but according to role concepts identity. So, a union operation is equivalent to relational full outer join in the case of different signatures of nested operations.

A logical selection operation is another leaf operation. This operation can be nested to a composition only and represents a logical predicate. Result data of a composition are filtered according to all logical selections nested to it. A query as a whole, like SQL query, can define ordering of the result data according to role concepts ascending or descending.

The detailed description of SCQL can be found at [Ov04-3]. Some new features not included to that paper will be discussed in a separate paper. The knowledge base part concerning SCQL queries has the following DTD according to the description given above.

<!DOCUMENT SCM [

...

<!ATTLIST query name CDATA #REQUIRED>

<!ELEMENT order (roleconcept)>

<!ATTLIST order type CDATA “ASC”>

<!ELEMENT connection (roleconcept)+>

<!ELEMENT queryref (#PCDATA)>

<!ELEMENT roleconcept (function | roleconcept)>

<!ATTLIST roleconcept concept CDATA #IMPLIED

role CDATA #IMPLIED>

<!ELEMENT function (function | roleconcept)*>

<!ATTLIST function type CDATA #IMPLIED

constant CDATA #IMPLIED>

<!ELEMENT predicate ((function | roleconcept)* | predicate*)>

<!ATTLIST predicate type CDATA #REQUIRED >

<!ELEMENT queryimp (#PCDATA)>

<!ELEMENT natural (#PCDATA)>

<!ELEMENT formal (#PCDATA)>

SCQL features require imposing additional restrictions on the DTD. A connection element and a composition element are to have at least two nested elements. Role concept elements nested to a connection element cannot have nested elements since they serves for referencing a connection only. A role concept element nested to another role concept element or a function cannot have nested elements since it serves as function variable. Concept attribute of a role concept element is to refer to a declared concept. Union and minus elements must have exactly two nested elements. #PCDATA of a queryref element is to refer to a declared query. Queries can be imported similar to concepts and servers with the queryimp element. We intentionally have separated DTD of the connection element on two parts: used for SCQL query and SCM model definition, to emphasize that application of the element differs significantly depending on context.

Each function element is to have either type or constant attribute. Type of the predicate element is to comply with types of nested elements: comparison operations are applicable to function or role concept elements and logical operations are applicable to predicate elements. Consider an example of SCQL query definition.

<natural>Material units having thickness more than 0.5</natural>

<formal>(Material Unit-(Thickness>0.5))</formal>

</connection>

</predicate>

</composition>

</query>

In this example, material units having thickness more than 0.5 are selected. The connection (Material Unit, Thickness) is filtered according to the predicate “Thickness > 0.5”. The following query uses an aggregate function to calculate summary mass of all outcoming mass transitions from each material unit.

<natural>A material unit outcoming mass is a sum of its outcoming transitions' masses </natural>

<formal>(Material Unit-Consumed Material Unit-Mass Transition-Mass).(Material Unit, SUM(Mass) ~Mass)</formal>

</function>

</roleconcept>

</connection>

</connection>

</connection>

</composition>

</transformation>

</query>

The result of the query is material units with their outgoing masses. See more queries for the example of SCM model.