This article describes the method of integrating information systems of an aircraft factory with the production capacity planning system based on the ontology merging. The ontological representation is formed for each relational database (RDB) of integrated information systems. The ontological representation is formed in the process of analyzing the structure of the relational database of the information system (IS). Based on the ontological representations merging the integrating data model is formed. The integrating data model is a mechanism for semantic integration of data sources.
As part of the work on automating the process of production capacity of the aircraft factory, it is necessary to take into account the presence of heterogeneous information systems in the aircraft factory that automates various business processes [1]. Data consistency can be realized by integrating the production capacity planning system with existing information systems of the aircraft factory. Data integration means the integration of data from di erent sources and the providing of data to users in a uni ed way. The main di culties of data integration are: (i) Data models heterogeneity. (ii) Independence of information systems of the aircraft factory from each other. (iv) Di erent data formats. (vi) Loss of data relevance by one of the data sources. (i) Creating an integrating data model. Integrating data model is the basis of a single user interface in the integration system. (ii) Development of methods for building onological representations for speci c models of various data sources. (iii) Development of methods for building integrating data model for speci c models of various data sources. (iv) Solving the problem of data sources heterogeneity. (v) Development of mechanisms for semantic integration of data sources.
The proposed information interaction algorithm consists of the following steps: (i) Extracting metadata from the RDB schema for automatic generation of ontologies for the source and target RBDs. (ii) Ontology merging to con gure correspondence between objects, attributes, and relationships of integrated ISs. Creation of metaontology. (iii) Using the metaontology to perform the interaction procedure on a schedule or event.
The metaontology is the settings contains correspondences between data models (tables and columns) of integrated ISs.
Ontology is a model knowledge representation of a speci c problem area [10]. An ontology contains a set of classes, individuals, properties, and relations between them. An ontology is based on the dictionary of terms which re ecting the concepts of a problem area. Also, the dictionary contains a set of rules (axioms). Terms can be combined to construct a set of statements about the state of the problem area based on a set of axioms.
At the moment, a lot of researchers use the ontological approach for extracting metadata from the RDB schema: (i) The Relational.OWL [11] currently supporting only MySQL and DB2 database management systems (DBMS). The generated ontology contains classes: Database, Table, Column, and PrimaryKey, and properties: has, hasTable, hasColumn, isIndenti edBy, references, scale, length. The main disadvantage of ontology generated by Relational.OWL is the presence of limited coverage of the domain, not considering, for instance, data type, foreign keys, and constraints. (ii) The OWL-RDBO [12, 13] currently supporting only MySQL, PostegreSQL and DB2 DBMSs. The generated ontology contains classes: DatabaseName, RelationList, Relation, AttributeList, Attribute, and properties: hasRelations, hasType, referenceAttribute, referenceRelation. ,The main disadvantage of ontology generated by OWL-RDBO is the presence of concepts external to the domain, such as RelationList to group a set of Relation, and AttributeList to group a set of attributes. (iii) Other approaches, such as [14, 15] extract the real world relations from the RDB structure, and unable to reconstruct the original schema of the RDB.
The relational data model can be represented as the following expression:
RDM = hE; H; Ri; (1) where E = fE1; E2; : : : ; Epg is a set of RDB entities (tables); Ei = (name; Row; Col) is the i-th RDB entity that contains the name, set of rows Row and columns Col; Colj = (name; type; constraints) is the j-th column of the i-th RDB entity that contains
Hj = EiD (x) Ek;
F (x) Rl = Ei G (x) Ek;
O = hC; P; L; Ri; properties: the name, the type and set of constraints; H = fH1; H2; : : : ; Hqg is a hierarchy of RDB entities in the case of using the table inheritance function: where Ei and Ek are RDB entities; D (x) is a 'parent-child' relation between Ei and Ek; R = fR1; R2; : : : ; Rrg is a set of RDB relations: where F (x) is an RDB relation between Ei and Ek; G (x) is an RDB relation between Ek and Ei.
Functions F (x) and G (x) can take values: U is a single relation and N is multiple relations. The ontological representation of the RDB data model is: (2) (3) (4) (5) where C = fC1; C2; : : : ; Cng { is a set of data model ontology classes; P = fP1; P2; : : : ; Pmg { is a set of properties of data model ontology classes; L = fL1; L2; : : : ; Log { is a set of data model ontology constraints; R is a set of data model ontology relations:
R = fRC ; RP ; RLg; where RC is a set of relations de ning the hierarchy of data model ontology classes; RP is a set of relations de ning the 'class-property' data model ontology ties; RL is a set of relations de ning the 'property-constraint' data model ontology ties.
The following function is used to map the RDB structure (ex. 1) to the ontological representation (ex. 4):
F (RDM; O) : fERDM ; HRDM ; RRDM g ! ! fCO; P O; LO; ROg; (6) where fERDM ; HRDM ; RRDM g is a set of RDB entities and relations between them (eq. 1); fCO; P O; LO; ROg is a set of ontology entities (eq. 4).
The process of mapping the RDB structure into an ontological representation contains several steps: (i) Formation of ontological representation classes.
A set of ontological representation classes C is formed based on the set of RDB entities C Ei ! Ci. The number of classes of the ontological representation must be equal to the number of RDB entities. (ii) Formation of properties of ontological representation classes.
A set of properties P of the i-th ontological representation class Ci is formed based on the set of columns Col of the i-th RDB entity Ei Colj ! Pj . The number of properties of the i-th ontological representation class Ci must be equal to the number of columns of the i-th RDB entity Ei. The name of the j-th property Pj is the name of the j-th column Colj of the RDB entity. (iii) Formation of ontological representation constraints.
A set of constraints L of the properties of the i-th ontological representation class Ci is formed based on the set of columns Col of the i-th RDB entity Ei Colk ! L^. The number of constraints of the i-th ontological representation class Ci must be equal to the number of constraints of the i-th RDB entity Ei. However, there are limitations to this approach due to the di culty of mapping constraints if their presents as triggers or stored procedures. (iv) Forming hierarchy of ontological representation classes.
It is necessary to form a set of ontology relationships RC between all the child and parent classes corresponding to the hierarchy of RDB entities if table inheritance uses in RDB H ! RC . The domain of the j-th ontological representation relationship RCj is indicated by the reference to the parent class Cparent. The range of the j-th ontological representation relationship RCj is indicated by the reference to the child (or a set) class Cchild. (v) Formation of relations between classes and properties of classes of ontological representation.
A set of ontological representation relationships RP is formed based on the set of columns Col of the i-th RDB entity Ei and the set of RDB relations R. Two types of relationships are formed for each j-th ontological representation property Pj : (a) The relationship 'class-property'. The domain of the ontological representation relationship is indicated by the reference to the i-th class Ci to which the j-th property belongs, and the range to the j-th property reference Pj . (b) The relationship 'property-data type class'. The domain of the k-th ontological representation relationship is indicated by the reference to the j-th property Pj . The range is indicated by the reference to the l-th class Cl corresponding to the l-th RBD entity El, or the reference to the m-th ontology class Cm corresponding to the data type of the j-th RBD column Colj . (vi) Formation of relations between properties of classes and constraints of properties of classes of ontological representation.
A set of relations RL of ontological representation is formed based on the set of columns Col of the i-th RDB entity.The domain of the j-th ontological representation relationship RLj is indicated by the reference to the k-th property Pk. The range of the j-th ontological representation relationship RLJ id indicated by the reference to the k-th constraint Col ! RL.
It is necessary to form an integrating data model based on the ontological representations that obtained after mapping the RDB structure of each of the integrated information systems into the ontological representation. The de nition of an ontological system is used as a formal representation of an integrating data model:
O X = hOMET A; OIS; M i; (7) where OMET A is the integrating data model ontology (metaontology); OIS = fO1IS; O2IS; : : : ; OgISg is a set of ontological representations of information systems that must be integrated; M is a model of reasoner.
The following steps are necessary to form an integrating data model based on the set of ontological representations of the information systems that must be integrated: (i) Formation of the universal concept dictionary for the current domain.
The process of forming an integrating data model OMET A is based on the presence of common terminology. Ontological representations of all information systems that must be integrated OIS should be built from a single concept dictionary. The concept dictionary is formed by the expert based on the analysis of the obtained ontological representations. (ii) Formation an integrating data model OMET A.
At this step, the set of top-level classes CMET A are added to the integrating data model OMET A. The set of top-level classes CMET A describes systems that must be integrated and is used as the basis for ontology merging. (iii) Formation of class hierarchy of integrating data model OMET A.
At this step, the integrating data model establishes a correspondence between the class hierarchies COiIS of ontological representations OIS of information systems that must be integrated. (iv) Formation of class properties of the integrating data model OMET A.
At this step, the integrating data model establishes a correspondence between the properties P OiIS of ontological representations OIS of information systems that must be integrated. The expert decides which class properties of ontological representations OIS should be included in the integrating data model OMET A. (v) Formation of axioms of classes and properties, checking the integrating data model OMET A for consistency.
At this step, constraints LOIS are applied to the properties P OIS and classes COIS of the integrating data model OMET A based on the constraints presents in the ontological representations OIS . After that, the resulting integrating data model OMET A should be checked for internal consistency using the reasoner M . However, the development of methods for checking the conditions of constraints is required, since the existing reasoners do not support working with such objects.
The proposed method is allowed to con gure the correspondence between tables and elds of two RDBs. The main problem is the need for ontology merging. However, that problem can be solved due to the use of specialized tools to automate the ontology merging process. Also, specialized tools allow dividing the developer and domain expert roles. The main advantage of the proposed method is the ability to dynamically generate the necessary SQL queries for select and insert data from/to the RBD based on metaontology.
Let see the following example of the ontological representation formation.
Table 1 shows the structure of the "Equipment and Tools" table of the aircraft factory IS.
Thus, the ontological representation of the "Equipment and Tools" entity (tab. 1) can be represented as: O = h
C = f Equipment and Tools (E&T), CHAR, NUMBER, BLOB, DATE g, P = f t2 ob, t2 ng , t2 nn, t2 r1, t2 r2, t2 r3, t2 p1, t2 z1, t2 p2, t2 z2, t2 p3, t2 z3, t2 gm, t2 p3, t2 z3, t2 gm, up dt, up us, t2 dc, t2 vid, t2 doc, t2 prim, t2 yyyy g L = f nullable, h length, 2 i, h length, 4 i, h length, 8 i, h length, 32 i, h length, 100 i, h length, 200 i, h length, 255 i, h precision, 5 i, h precision, 6 i g RP = f h E&T, t2 ob, CHAR i, h E&T, t2 ng, NUMBER i, h E&T, t2 nn, NUMBER i, h E&T, t2 r1, CHAR i, h E&T, t2 r2, CHAR i, h E&T, t2 r3, CHAR i, h E&T, t2 p1, CHAR i, h E&T, t2 z1, CHAR i, h E&T, t2 p2, CHAR i, h E&T, t2 z2, CHAR i, h E&T, t2 p3, CHAR i, h E&T, t2 z3, CHAR i, h E&T, t2 gm, CHAR i, h E&T, up dt, DATE i, h E&T, up us, CHAR i, h E&T, t2 dc, BLOB i, h E&T, t2 vid, CHAR i, h E&T, t2 doc, CHAR i, h E&T, t2 prim, CHAR i, h E&T, t2 yyyy, CHAR i g RL = f h E&T, t2 ob, h length, 200 i i, h E&T, t2 ng, h precision, 5 i i,
h E&T, t2 nn, h precision, 6 i i, h E&T, t2 p1, h length, 2 i i,
h E&T, t2 p1, nullable i, h E&T, t2 z1, h length, 8 i i, h E&T, t2 z1, nullable i, h E&T, t2 p2, h length, 2 i i, h E&T, t2 p2, nullable i, h E&T, t2 z2, h length, 8 i i, h E&T, t2 z2, nullable i, h E&T, t2 p3, h length, 2 i i, h E&T, t2 p3, nullable i, h E&T, t2 z3, h length, 8 i i, h E&T, t2 z3, nullable i, h E&T, up us, h length, 32 i i, h E&T, t2 vid, h length, 4 i i, h E&T, t2 doc, h length, 100 i i, h E&T, t2 prim, h length, 100 i i, h E&T, t2 doc, nullable i, h E&T, t2 yyyy, h length, 4 i i g
As you can see from this example, the resulting ontology representation O has some sets of objects: (i) A set of classes C contains the "Equipment and Tools" table and some data types: CHAR, NUMBER, BLOB, DATE. The OWL representation of ontology O uses Class signature to represent the table. (ii) A set of properties P contains all columns of the "Equipment and Tools" table. The OWL representation of ontology O uses built-in data types to represent RDB data types (xsd:string, xsd:double, xsd:dateTime, xsd:base64Binary ), and Class signature to represent RDB relationships. (iii) A set of constraints L contains all variants of restrictions for columns of the "Equipment and Tools" table. This set is not translated to OWL representation directly. (iv) A set of relations between classes and properties RP contains ties between table and columns that belong to this table. The OWL representation of ontology O uses ObjectProperties and DataProperties signatures to represent a set of relations RP . ObjectProperties signatures are used to represent foreign keys. DataProperties signatures are used to represent columns that contain a value. (v) A set of relations between properties and constraints RL contains a tie between column and constraints of this column. OWL datatype restrictions are used for constraints speci cation. For example: DatatypeRestriction( xsd:integer xsd:minInclusive "5"^^xsd:integer xsd:maxExclusive "10"^^xsd:integer ) .
Thus, the ontological approach is commonly used to solve the methodological problem of building an integrating data model of information systems.
This article presents the implementation of the method of integrating the information systems of the aircraft factory with the production capacity planning system. The principles of ontological engineering allows mapping database structure of each information system that must be integrated into ontological representation. From the proposed methodology, an integrated data model is formed based on the obtained ontological representations for each information systems that must be integrated.
The proposed method allows organizing information interaction without the participation of developers in contrast to the traditional approach of consolidation, based on the method of direct data exchange. The only requirement of the proposed method is the presence of metaontology. The disadvantages of the proposed method implementation currently are: (i) The need for implementation of the data type casting algorithms in case of their mismatch for each DBMS. (ii) The need for adapting the proposed method implementation to the SQL dialect of DBMS involved in the exchange process. Random DBMS cannot be supported by this implementation.