The article describes the ontology compilation from the relational database. The process is based on the model called initial. The model is applicable for the design and redesign of existing software products and tuning of the final ontology, including its size reduction. The described model allows obtaining data from a relational schema. The data can be subsequently used for other more flexible formalizations. Moreover, the model can be extended by new parameters which cannot be derived from the schema but be quite useful for design tasks. The paper brings in a short overview of diferent approaches to ontology compilation based on relational data sources. Additionally, two extra strategies are presented. Finally, the article contains an example of these strategies implementation which is measured by performance tests on two diferent data sources.
the need appears and the initial data required for the compilation of ontology lies in the
relational data storage. Thus, relational storage can be converted to ontological resource due to the
need of resolving contradictions within the redesign process. However, the conversion might
be complicated due to the variability between the initial data source and the result [
The data extraction of a subject domain from a relational database is high-loaded for large information systems and represents an additional dificulty.
Therefore, to simplify the redesign process by ontological analysis, it is recomended to define the model that provides several abilities of: • The model transformation into an ontological resource; • The generation of other formalizations besides ontology; • The independence of the implementations of relational databases; • The exclusion of some entities and other elements of a relational data schema without losing model consistency; • Supplementation of the relational model with additional properties that may be useful for the compilation of an ontological resource.
This model is called an initial because it is a base for further ontology compilation of subject domain.
There are many strategies for transforming relational schemas into an ontology (e.g. the
concept of direct mapping [
W3C develops another technology named as R2RML [
There are also works describing the transformation of relational data schemas in ontology,
and not just in RDF metadata. For example, [
The following entity types can be distinguished according to [
The categories can be used for the correct definition of transformation rules. For instance, the entities that have not foreign keys can be converted into ordinary ontology classes.
It is also necessary to take into account the constraints of entities. For example, the NOT
NULL constraint can be specified by MinCardinality in OWL notation, the UNIQUE constraint
can be assigned by InverseFunctionalProperty [
Some transformation algorithms from relational DBMS to ontology (e.g. [
The initial data model for ontology compilation is denoted as . Thus, the model can be expressed as:
=< , > = { 1, 2, … , } - entities of relational schema = { 1, 2, … , } - the relations between entities - the number of entities - the number of relations (1)
The entity can be described as: - the number of attributes of entity = { 1, 2, … , } = { 1, 2, … , } - many attributes of entity - many constraints of entity The entity attribute can be presented as: = ( , ,
) = ( , , , ) is an ordered number of attribute i within the cortege of entity attributes - the name of attribute which must be unique within the entity = [ , , , ℎ , , = { 1, 2, … , } - many additional attribute properties ] - data type Additional attribute properties may be as follows: • maximum length (for string fields); • maximum number of digits (for integer and decimal numbers); • number of decimal places (for decimal numbers); • text description.
The constraint of entity can be written as:
= ( ) - many attributes that constraint was applied to - the function that defines the type of constraint
The constraints can be described as follows: • is a primary key constraint; • is a NOT NULL constraint; • is a unique constraint; (2) (3) (4) • is a foreign key constraint.
The entity relations can be described as: = ( ,
, , , ) is a function that describes the type of relation; is a foreign key constraint of entity ; is a primary key constraint of entity ; = { 1, 2, … , }
- many of auxiliary parameters of relation.
The conclusion that is based on (2), (3) and (5) states the definition of the R relation can be = ◦ ∶ { , } ⊆ ◦ is the operation of binding entities and .
It is proposed to record the resulting model using the XML markup language using the fol
There are two proposed options for the ontology compilation: 1. Filling the basic ontology of a relational data warehouse by individuals. 2. Ontology creation with entity classes and subsequent filling by individual records.
The first approach is the simplest but least flexible. In this case, there is a basic ontology with the classes “entity”, “relationship”, “entity field”, “procedure”, “procedure argument”, “presentation”, etc. Object relations are set for the classes. For example, the basic transitive object property “is part” is defined, which is used for relationships between entities and their fields, as well as procedures with their own arguments.
The particular elements of the relational schema are filled into the ontology as individuals (individuals) with the axioms of class membership (Class Assertion).
This approach has a significant ability to represent any relational schema while expanding the initial ontology. This strategy allows for making similar ontologies from software products of the same subject domains. Thus, they will difer only by sets of individuals and related class axioms. Finally, that helps to simplify the further analysis for integration systems design.
The main drawback of this approach appears while expanding the basic ontology. In other words, a software update is required to provide new individuals in accordance with the initial schema. Moreover, this approach does not support all the opportunities provided by ontologies. For example, it is dificult to search for contradictions because the relationships between entities are represented as individuals, and not as object properties with their attributes.
The second proposed strategy difers from the first that the initial data model is used as a base for a separate ontology resource that is not associated with any basic one. In this case, the ontology classes are entities, procedures, and other elements of the initial relational schema. The entity relations convert into object properties, the fields of entities, and procedure arguments are into the data properties. There is also possible to use relational data records to fill the ontology that are used as individuals for conducting an ontological resource solvability.
The vantage of this strategy is the flexibility and application of the entire ontological tools. Although the relational schema does not support all required data for the ontology compilation, this can be achieved by initial schema extension. For example, it is possible to define the attributes (e.g. transitivity, symmetry, etc.) of object properties for the initial schema. The resulting ontology will most fully describe the domain already at the initial stage of compilation.
The disadvantage of this strategy is the need to supplement the initial schema after it is obtained from the relational database or to refine the resulting ontology after it is get.
Since the chosen strategies include two stages (the formation of the initial model and the compilation of the ontology), the implementation was also divided into two stages.
Firstly, a generator and designer of the initial data model have been developed with Visual C# and Windows Forms technology that allows rapid UI development. Microsoft SQL Server 2012 was chosen as a data management tool based on the relational data paradigm. The DBMS allows easy access to the description of the data schema. However, the choice of a particular DBMS was up to the experience of the authors, rather than the significant advantages of the current DBMS system over analogues. The serialization of the initial model is performed using the XML language with an attributive approach to the description of the properties of elements. That also helped to simplify the processes of work with the data model and reduced size of serialized data.
Java and OWL API libraries were used for the generation of ontologies. The choice is justified by the prevalence, simplicity, and open-source type. The software helps to deserialize the initial models and generates, based on settings, the ontology in OWL XML. The format was chosen due to its readability, prevalence, and convenient debugging and overview tools (protégé and others).
The basic ontology must be opened for the implementation of the first strategy. It is done using the following code: OWLOntologyManager manager =
OWLManager.createOWLOntologyManager(); OWLOntology ontology = manager.loadOntologyFromOntologyDocument( new File("sql-base-ontology-1.0.0.owl")); OWLDataFactory df = manager.getOWLDataFactory();
The following are the main classes of the basic ontology (parts of duplicated code omitted): final String ontologyIRI = "urn:vladdy-moses.sql-base-ontology"; OWLClass entityTableType = df.getOWLClass(ontologyIRI + "#Table"); // ...
OWLDataProperty schemaDataProp = df.getOWLDataProperty(
ontologyIRI + "#schema_name"); // ...
A named individual is created for each entity of relational storage and the following set of axioms is applied to it:
is used to determine the data schema and entity name; • is used to assign an entity to an ontology class (for example, an entity can be a table, view, or procedure).
A named individual is created for each entity field and the following set of axioms is determined on it:
is used to determine the data schema and name of the is used to assign the relationship to an ontology class; • • • • •
the entity; • is used to describe whether a relation belongs to an entity field on the one hand and to the primary key of an external entity on the other.
The new resource will be created in a similar way as in the case with the secondly proposed strategy.
The class with axiom DeclarationAxiom is instantiated for each entity.
Each entity’s property is converted to the data property and supports the next axioms: is used to determine the domain of the data property.
Each relationship of the relational model is converted into an object property with the following axioms:
is used to determine the domain of an object property. is used to associate a record with a specific class that describes
is used for foreign keys; is used for the calculation of each non-null field.
This strategy allows generating individuals for each database record based on this relational schema. In this case, each record has an individual with the following axioms:
The early presented strategies saving procedures coincide with the saving of the ontology and occurs as follows: OWLOntologyManager manager
= OWLManager.createOWLOntologyManager(); OWLDocumentFormat documentFormat = new OWLXMLDocumentFormat(); manager.saveOntology(ontology, documentFormat,
IRI.create(new File("result.owl")));
It is necessary to take several databases from various subject areas to test the operability of the proposed ontology strategies compilation from a relational data schema.
The data of addresses and houses from the Russian Federal Information Address System, Ulyanovsk Oblast (denoted as 1) and data of overhaul in Ulyanovsk region (denoted as 2) will be used. Both relational storages correspond to 3rd normal form. Therefore, there would not be any dificulties with the compilation of ontologies. The characteristics of relational storages are presented in table 1.
After the initial data received, the schemas 1 and 2 are formed and based on 1 and 2 respectively. Their serialized sizes are 35 Kb and 86 Kb respectively.
The 1 and 2 strategies were used to generate ontologies and the results are in table 2.
As it is seen, the size of the compiled ontology many times more than data in DBMS format (varying from 1.33 to 1.6). Firstly, it depends on the OWL XML format that keeps each of the axioms as an element of XML language and stores parameters as nested elements. However, other formats were not capable to minimize the size of the final ontology.
Obviously, the 2 strategy (assumes generation of entity classes and individual records) increases the ontology compilation time more than the 1. It is due to the fact that data extraction from the relational database requires additional time for setting up a connection and execution of SQL requests. The saving time stays linear to the size of ontology.
The proposed data model based on ontologies is useful for software products redesign. The model does not rely on the physical implementation of data storage. Moreover, it owns such properties as unity and flexibility which help to build ontologies on its base.
The described strategies that are used for ontology compilation from a relational database helps to set up this process for systems based on relational data storage. The strategies are both applicable for the implementation of systems’ interfaces and for ontology compilation. The ontology can help to find contradictions within schema and data of the database.