Introduction

Knowledge graphs (KGs) model the data of a given domain as a set of entities or objects connected through a rich network of relationships [1]. Similarly, the conceptual model usually conceived when designing a relational database defines the types of entities that will inhabit the database and the types of relationships in which they can participate.

As most data is stored in relational databases, we propose leveraging their conceptual model to capture the underlying semantics and define a mapping procedure that produces a KG from its data. Such a mapping can be useful to be able to apply richer querying [2] and analytics [3] over the mapped data and, further, the mere definition of the mapping can allow for a virtual graph view of the relational data which can be accessed employing query translation.

In this poster, we present progress on the development of such a mapping that transforms a relational database into either an RDF/RDF-star graph or a property graph (PG), using the conceptual model of the input database. We leverage the ERDoc language [4] used to define Entity-Relationship Diagrams (ERDs) [5], which are a common way to design and communicate conceptual models. Our mapping, differently from Stoica et al. [6], is not direct (it requires extra input) but considers the semantics embedded in the conceptual model, yielding a semantically more accurate graph. For instance, in N-to-N relationships, [6] would create a node for each tuple in the table storing the relationship, whereas our approach translates such tuples directly to edges. Similarly, multivalued attributes would each be mapped to a node by [6], whereas our approach produces multivalued properties. Differently from Barret et al. [7], we assume that the conceptual model is part of the input of our mapping, and we shall focus on the formal definition of the mapping and its properties (e.g., information and query preserving [8]).

Conceptual Models

The conceptual model, defined as ERDs by Chen [5], aims to provide a unified view of data that allows to interoperate the relational model [9] and the network model [10]. As such, it also can allow us to leverage it to interoperate with RDF graphs [11], RDF-star graphs [12] or PGs [13].

ERDoc is a scripting language designed to specify ERDs. The idea for our mapping is to receive an input database along with the ERDoc document that codifies its conceptual model. To formalize our mapping, we provide semantics to a fragment of ERDoc [4]. An example of an ERD can be found in Figure 1b, where Person and Bank are Entities, Account is a Weak Entity depending on Bank via relationship ofBank (which means that the primary key of Account is unique only for a given Bank), and hasAccount is an N-to-N relationship.

Mapping Relational Databases to Knowledge Graphs

Our mapping ℳ is such that, given a relational database D with primary and foreign keys Σ (following the definition of Sequeda et al. [8] over a domain of values 𝒱), and an ERD 𝒞, ℳ(D, 𝒞) returns a PG 𝐺 = (𝑉, 𝐸, 𝜎, 𝜑, 𝜆) (following the definition of Angles [13]). RDF graphs can also be produced later on (e.g., by using the mapping of [14]). We assume that D is in BCNF [15].

Non-weak Entities E{𝐾 1 , ... , 𝐾 𝑛 }{𝐴 1 , ... , 𝐴 𝑚 } are mapped to a relation 𝑅 E ∈ D, such that the attributes of 𝑅 E are 𝑎𝑡𝑡(𝑅 E ) = {𝐾 1 , ... , 𝐾 𝑛 , 𝐴 1 , ... , 𝐴 𝑚 }, and 𝑅 E [𝐾 1 , ... , 𝐾 𝑛 ] is a primary key. To map such a relation to a graph, we take each tuple 𝑡 ∈ 𝑅 E , where 𝑡 = (𝐾 1 : 𝑣 1 , ... , 𝐾 𝑛 : 𝑣 𝑛 , 𝐴 1 : 𝑣 𝑛+1 , ... , 𝐴 𝑚 : 𝑣 𝑛+𝑚 ), with 𝑣 1 , ... , 𝑣 𝑛 ∈ 𝒱 and 𝑣 𝑛+1 , ... , 𝑣 𝑛+𝑚 ∈ 𝒱 ∪ {null}, and map it to a node 𝜂 = 𝑓 𝑛 (𝑣 1 , ... , 𝑣 𝑛 ), where 𝑓 𝑖 : 𝒱 𝑖 → 𝒱 is a function that returns identifiers . Then, we extend the property assigning function 𝜎 to contain 𝜎(𝜂, 𝑝) = 𝑣 for each 𝑝 : 𝑣 ∈ 𝑡. Finally, we extend the label assigning function 𝜆 to include 𝜆(𝜂) = 𝑅 E . It can be seen that if 𝑓 𝑖 is bijective, this mapping is reversible, and thus information preserving [8].

The mapping of relationships to the relational model is more nuanced. It depends on the number of participating entities, the presence or absence of attributes, and even the cardinalities and participation constraints. We will summarize two acceptable mappings that preserve BCNF. Let us consider the generic relationship R⟨(E 1 , 𝐶 1 ), ... , (E n , 𝐶 𝑛 )⟩{𝐴 1 , ... , 𝐴 𝑚 }.

If 𝑛 = 2, {𝐴 1 , ... , 𝐴 𝑚 } = ∅, and either 𝐶 1 or 𝐶 2 are one and only one cardinalities, the first mapping applies. W.l.o.g., we assume that 𝐶 2 is one and only one, and that the participating entities are E 1 {𝐾 1 , ... , 𝐾 𝑛 1 }{𝐵 1 , ... , 𝐵 𝑚 1 } and E 2 {𝐽 1 , ... , 𝐽 𝑛 2 }{𝐹 1 , ... , 𝐹 𝑚 2 }, which are mapped to relations 𝑅 E 1 and 𝑅 E 2 respectively. To map this relationship, we extend 𝑅 E 2 so that att(𝑅 For any other case of relationship R (e.g., 𝑛 > 2 or {𝐴 1 , ... , 𝐴 𝑚 } ̸ = ∅), a relation 𝑅 R for the relationship is created and it contains foreign keys referencing all the relations mapping the participating entities. The primary key of 𝑅 R depends on the cardinalities and participation constraints [5]. Each tuple 𝑡 ∈ 𝑅 R can be mapped to an edge only if 𝑛 = 2. Otherwise, 𝑡 should be mapped to a node, and an edge for each foreign key must be created, as is done in [6].

E 2 ) ← att(𝑅 E 2 ) ∪ {𝐾 1 , ... , 𝐾 𝑛 1 } and 𝑅 E 2 [𝐾 1 , ... , 𝐾 𝑛 1 ] REF 𝑅 E 1 [𝐾 1 , ... , 𝐾 𝑛 1 ]

Weak entities W⟨(E 1 , R 1 ), ... , (E l , R l )⟩{𝑃 1 , ... , 𝑃 𝑛 }{𝐴 1 , ... , 𝐴 𝑚 } are mapped into a relation 𝑅 W , similar to the first relationship case, as the cardinality with which W participates in every R i is one and only one. 𝑅 W has attributes att(𝑅 W ) = 𝒦 ∪ {𝑃 1 , ... , 𝑃 𝑛 , 𝐴 1 , ... , 𝐴 𝑚 }, where 𝒦 is the set of all the prime attributes of all the relations 𝑅 E i of each E i . 𝑅 W has therefore foreign keys referencing to each 𝑅 E i . Each tuple 𝑡 ∈ 𝑅 W is mapped to a node 𝜂 with id 𝑓 |𝒦|+𝑛 (𝑡[𝒦 ∪ {𝑃 1 , ... , 𝑃 𝑛 }]), label 𝜆(𝜂) = W, and each foreign key is mapped to an edge without properties and the label of the respective relationship R i going from 𝜂 to the respective node representing the referenced tuple in 𝑅 E i .

Example. In Figure 1a, we present 4 relations that follow the ERD of Figure 1b. These are Person(SSN, name), Bank(SWIFT, name), Account(number, SWIFT, name), and HasAc-count(SSN, number, SWIFT). Note that Account is a weak entity and HasAccount is an N-to-N relationship. The tuples in Figure 1a are translated to the graph of Figure 1c, following the rules of each case. See how, for instance, the tuple (number: 333, SWIFT: TTQCL, type: checking) from relation Account is mapped to a node with id 𝜂 = 𝑓 1 (333), label 𝜆(𝜂) = "Account", properties 𝜎(𝜂, number) = 333 and 𝜎(𝜂, type) = "checking", and to and edge 𝑒, such that 𝜑(𝑒) = (𝜂, 𝑓 1 ("TTQCL")) and 𝜆(𝑒) = "ofBank". This mapping is similar to [6]. However, we can extract the appropriate label for 𝑒 from the conceptual model. Our mapping presents its difference particularly when mapping the relation HasAccount. The tuple (SSN: 111, number: 333, SWIFT: TTQCL) is mapped, according to [6], to a node with label "HasAccount", with one edge to the node mapping the person with ID 𝑓 1 (111), and another to the node of the Account with ID 𝑓 2 (333, TTQCL). Our mapping simply creates one edge 𝑒 ′ , with 𝜆(𝑒 ′ ) = "HasAccount", and 𝜑(𝑒 ′ ) = (𝑓 1 (111), 𝑓 2 (333, TTQCL)). This is not only more semantically accurate but also implies the use of fewer joins when querying the resulting graph.

Conclusion and Future Directions

In this poster, we present initial progress on a formal mapping that, given a relational database and its conceptual model, produces a knowledge graph that behaves differently from [6]. Initially, we consider property graphs, but RDF and RDF-star graphs can also be produced. Further, we provide semantics for a fragment of the ERDoc language and a formalization of the elements present in an ERD. We are currently defining the translations of the rest of the ERD constructs (class hierarchies, aggregations, multivalued attributes, etc.) and studying the general properties of information and query preservation [8] of the mapping. We note that in the future, we may leverage the work by Barret et al. [7] to automatically obtain the conceptual model for the mapping. We are also working on a mapping algorithm and a tool implementation. Furthermore, we can explore using the conceptual model to generate SHACL constraints [16] to validate the mapping output.