# Semantics-Preserving RDB2 RDF Data Transformation Using Hierarchical Direct Mapping
## 4 Hierarchical Mapping Rules
### Rules for Relational Integrity Constraints  
This section provides additional rules for transforming relational integrity constraints to prevent incorrect RDF data generation problems. Lemma 3 illustrates the feature of RDF data, using a linked graph structure. This feature acts as a major factor that prevents the generation of incorrect RDF data. Thus, this section defines Rules 6-11 for the mapping integrity constraints based on Lemma 3 (proofs are provided in the Appendix E). * Lemma 3: Suppose \(G\) is an RDF graph, \(G_{1}\) and \(G_{2}\) are the components of \(G\), there is no edge between \(G_{1}\) and \(G_{2}\), \(G_{1}\) is rooted at \(x\in R\), and \(G_{2}\) is rooted at \(y\in R\), where \(R\) is a set of semantic resources. Then, 1. If \(x\) and \(y\) have the same uniform resource identifier (URI) [36], then \(x\) is identical to \(y\). Thus, \(G_{1}\) and \(G_{2}\) can be merged into one graph. 2. If \(x\) and \(y\) have different URIs, \(x\) has a property, \(p_{1}\), and \(y\) has a property, \(p_{2}\), that has the same URI as \(p_{1}\), then \(G_{1}\) and \(G_{2}\) cannot be merged into one graph, and \(p_{1}\) can be distinguished from \(p_{2}\) using \(x\) and \(y\). * Rule 6: NonFKeyAttr(\(a\), \(r\)) \(\wedge\) subClassOf(\(r\), \(\_b\)) \(\wedge\) Card(\(a\), \(\_b\), \(1\)) \(\rightarrow\) NotNull(\(a\), \(r\))
* Rule 7: NonFKeyAttr(\(a\), \(r\)) \(\wedge\) IFP(\(a\)) \(\wedge\) subClassOf(\(r\), \(\_b\)) \(\wedge\) MaxCard(\(a\), \(\_b\), \(1\)) \(\wedge\) (\(\exists\)!\(v\)) a(\(r\), \(v\)) \(\rightarrow\) Unique(\(a\), \(r\))  
Figure 14: An example of mapping a nonidentifying relationship (Rule 5). Figure 13: An example of mapping an identifying relationship (Rule 4). * Rule 8: NonFKeyAttr(\(a\), \(r\)) \(\wedge\) IFP(\(a\)) \(\wedge\) subClassOf(\(r\), _b) \(\wedge\) Card(\(a\), _b, 1) \(\wedge\) (\(\exists!v\)) a(\(r\), \(v\)) \(\rightarrow\) PK(\(a\), \(r\))
* Rule 9: FKeyAttr(\(a\), \(r\), \(s\)) \(\wedge\) subClassOf(\(r\), _b) \(\wedge\) MinCard(\(a\), _b, 1) \(\rightarrow\) FK(\(a\), \(r\), \(s\))
* Rule 10: NonFKeyAttr(\(a\), \(r\)) \(\wedge\) subClassOf(\(r\), _b) \(\wedge\) MaxCard(\(a\), _b, 1) \(\wedge\) DefVal(\(a\), _b, 0) \(\rightarrow\) Default(\(a\), \(r\))
* Rule 11: NonFKeyAttr(\(a\), _r_) \(\wedge\) subClassOf(\(r\), _b) \(\wedge\) MaxCard(\(a\), _b, 1) \(\wedge\) CheckCond(\(a\), _b, 0) \(\rightarrow\) Check(\(a\), _r_),  
where a is an attribute of relational table, _r, \(b\) is a blank node [37], \(v\) in Rules 7 and 8 is an attribute value, \(v\) in Rule 10 is a default attribute value, and \(v\) in Rule 11 is a check condition. The predicates on the left-hand side are defined in the Appendix A, and the predicates on the right-hand side preserve the integrity constraints: not null, unique, primary key, foreign key, default, and check. Rule 6 describes the _NotNull_ constraint. It also defines a predicate, Card(\(a\), _b, 1), that restricts the cardinality of an attribute to be exactly one (Figure 15a). Rule 7 specifies a unique constraint and defines a predicate with a unique existential quantifier, (\(\exists!v\)) \(a(r\), _v_), such that there is only one attribute value, \(v\), contained in the domain of \(a(r\), _v_) (Figure 15b). Rule 8 specifies the primary key defined by Card(\(a\), _b, 1) and (\(\exists!v\)) \(a(r\), _v_), to assign an attribute, \(a\), with a primary key (Figure 16a). To define a foreign-key constraint, Rule 9 specifies a lower bound of the cardinality using MinCard(\(a\), _b, 1), because the relational tables can reference more than one other table. Rule 9 also uses FKeyAttr(\(a\), \(r\), \(s\)) to describe the semantics that the type of attribute \(a\) is an OWL object property with domain \(r\) and range s (Figure 16b). Rule 10 specifies the default constraint, and it uses a function DefVal(\(a\), _b, \(v\)) that returns a default value, \(v\), if a value of the attribute, \(a\), is omitted (Figure 17a). In Rule 11, a function CheckCond(\(a\), _b, \(v\)) is used to restrict the value range for the check constraint.