Mapping Foreign Keys to Object Properties

Many researches [30] claim that the similarity of two entities will be influenced by their neighbor entities. Hence, when mapping a foreign key to some possible object properties, if only considering the information foreign key itself has, there will cause a low accuracy of mapping results. Besides, since some semantic of foreign keys can be gotten by classifying tables a foreign key can have different matching level depend on the semantic it has.

Combining above mentions, two principals of mapping foreign keys to object properties are composed as follows:

• Principal 1: The similarity between two entities should be influenced by their neigh-bor entities.

• Principal 2: Foreign keys can have different level matching depend on the semantic they have.

Therefore, the principals and source of computing similarity are considered when mapping foreign keys to object properties. In the following sections, we introduce how to map various kinds of foreign keys to object properties except IS-A FKs. Because as for OWL ontologies, it does not use object properties to declare subclass and super-class relationship between super-classes but use a built-in vocabulary “owl:superClassOf” or

“owl:subClassOf” and hence IS-A FKs will be ignored in the matching process.

4.5.1 Mapping Base FKs

As defined in 4.3.5, the semantic of a base FK has explicitly expressed the fact that it can relate one table to another table and as for object properties which can link individuals each other between domain classes and range classes. Therefore, for one base foreign key and one object property, their total similarity can be combined the local similarity and the external similarity to improve the performance of mapping results. The related definitions of these similarities are defined as follows.

Definition 4.5.1 (Local Similarity for Two Entities). For two entities e_i and e_j, their local similarity can be expressed as Sim_local(e_i, e_j) which is the result using matchers to compute their local information such as names.

For a foreign key c_i, the table c_i stores in and the table c_i refers to will be the main structures for c_i. The counter parts in object property op_i are its domain classes and range classes. Hence, the external similarity of c_i and op_i can combine their domain similarity Sim_domain(c_i, op_i) and range similarity Sim_range(c_i, op_i). These two similarities are defined as follows.

Definition 4.5.2 (External Similarity of FKs and OPs). For foreign key c_i of table t_i referring to table t_j and object property op_i which has n related domain classes {dc1, dc₂, . . . , dc_n} and m related range classes {rc1, rc₂, . . . , rc_n}, the exteranl

According to the principal 2 foreign keys can have different level matching depend on the semantic they have. In this approach, two matching levels, which are level one matching and level two matching, are used. Level one matching represents the matching between entities only considers the explicit information they have. As opposed to level one matching, level two matching uses implicit information to match entities. Hence, since a base FK in this approach is regarded as an entity which has no implicit information it will be matched up to level one and its similarity is defined as follows.

Definition 4.5.3 (Similarity for Base FKs and Object Properties). For base foreign key c_i and object property op_i, the similarity between them can be computed as:

Sim_one(c_i, op_i) = Sim_local(c_i, op_i) + Sim_external(c_i, op_i) , where

• Simlocal(c_i, op_i) is the local similarity.

• Simexternal(c_i, op_i) is the external similarity.

Since for each base foreign key there are many possible object properties to match, we give the priority to the matching candidate based on the rank of their similarity. For example, the best matching candidate for base foreign key c_i can be defined as follows.

Definition 4.5.4. For base foreign key c_iand n numbers of object properties{op1, op₂, . . . , op_n}, the best matching candidate from these object properties for c_i is op_i if :

Sim(c_i, op_i) = max

1≤x≤nSim_one(c_i, op_x)

4.5.2 Mapping Part-Of FKs

For any two individuals I₁ and I₂ in OWL ontologies, if I₁ is part of I₂ and I₂ has part of I₁, I₁ and I₂ will have inverse relationship and this kind of relation can be easily claimed in the OWL ontologies as two object properties which have inverse relation. But as for the relational database schema, inverse relationship between tables can not be explicitly expressed. Because for any two tables t_i and t_j, if they have inverse relationship in the real word, database designers usually regard this kind of relationship as the common binary relationship and hence may design that t_i uses a foreign key to refer to t_j and the fact that t_j can also use a foreign key to refer to t_i would not be captured.

As mentioned above, the fact that two tables have the inverse relationship will be represented incompletely, in other words, some implicit information is not expressed in the relational database schema. Hence, extracting these implicit information is necessary to improve the performance of mapping result. For this purpose, our approach takes advantage of Part-Of FKs to find the inverse relationship between tables. Because for a table t_i and its Part-Of FK c_i referring to table t_j, the fact that t_i and t_j have inverse relationship is satisfied since both of them have the common primary key describing themselves.

Mapping a Part-Of FK to object properties can adopt a level two matching since this kind of FK has implicitly expressed the information about two tables exist an inverse relationship. In level one matching for a Part-Of FK c_i, the behavior of computing similarity between c_i and object properties is the same as the one of a base FK. But when reaching the level two matching, we will create a conceived foreign key c_j to express the implicit information of c_i. The name of c_j is the same as c_i and now c_j becomes

a foreign key of the table c_i refers to and c_j refers to the table c_i stores in. Hence, if combining level one and level two matching for c_i and n numbers of object properties, there will be 2n numbers of matching results for c_i. n numbers of them are the matching results using explicit information c_i to match and the others are the matching results using implicit information c_i to match. Now we define the best matching candidate of c_i. Definition 4.5.5. For tables t_i and t_j, if t_i has a Part-Of foreign key c_i referring to t_j and c_i will match to n numbers of object properties {op₁, op₂, . . . , op_n}, a conceived foreign key c_j of t_j referring to t_i will be created and the best matching candidate from these object properties for c_i is op_i if :

When calculating the external similarity between foreign keys and object properties, we usually take the tables foreign keys store in and domain classes of object properties as input to compute the domain similarity but as for foreign keys of relationship tables we doesn’t always do that. Because relationship tables are created to facilitate the ”many-to-many” relationship betweens tables and not to represent entities in the real word.

Furthermore, on one hand, one relationship table can represent n-arity relationship, but on the other hand, OWL ontologies can only support unary or binary relationship.

Hence for a relationship table t_i which has a set of foreign keys {c1, c₂, . . . , c_n}, when mapping these foreign key to object properties, two cases are considered as follows to capture the semantic of relationship table as far as possible.

• Case 1: If n = 2 and COL(ti) = F K(t_i), the table used to compute the domain similarity for c₁ will be the the table referred by c₂ and the table used to compute the domain similarity for c₂ will be the table referred by c₁

• Case 2: If n ≥ 2 or COL(ti) = F K(ti), every table used to compute the domain similarity for c_n will be the relationship table itself