Graph Database for Collaborative Communities - Community-Built Databases: Research and Development - page 222

9.4.1 Converting Relational Database into Hypernode Database

Having a graph database instead of a relational database will provide a clearer view
of existing entities in the initial database. Indeed, all these entities will be presented
in the form of nodes, and the relations between them will be outlined, which
facilitates the further step of selecting the desired entities. Also, nodes in a graph
database can encapsulate all the attributes of entities in the same node and give
us a simple graph of entities. From this graph of entities, a social network can be
extracted. Using the comparison between existing graph database models
(Table 9.1 ), we have chosen to work with the hypernode model [ 25 ] because the
hypernode database with its nested graphs can provide an efficient support to
represent every real-world object as a separate database entity.
The transformation of a relational database into a graph database includes
schema translation and data conversion [ 37 ]. The schema translation can turn the
source schema into the target schema by applying a set of mapping rules. In our
work, we propose a translation process, which directly transforms the relational
schema into a hypernode schema. A data conversion process converts data from the
source to the target database based on the translated schema. Data stored as tuples
(rows) in the relational database are converted into nodes and edges in the graph
database. This involves unloading and restructuring relational data and then reload-
ing them into a target database in order to populate the schema generated during
the translation process. In what follows, we will detail these two steps.

9.4.1.1 Schema Translation

The first step consists of extracting the relational database schema using the schema
metadata of the relational database management system (information about tables
and columns), which is extracted using SQL queries. The idea is to identify the
primary key, composite key(s), and foreign key(s) of each relation. This informa-
tion is then used to design the new schema (hypernodes and relations within and
between them). This process is performed by the following steps.
Step1: Relational schema extraction . In this step, information from the relational
database is extracted using SQL queries. In our approach, a relational schema is
represented as a set of relations (tables)

, where:

¼ TR n TR: ¼ r n ; A ; K p;F

l r n denotes the name of TR.
l A denotes a set of attributes of TR and gives information about each attribute
integrity constraints, A

, where a n is an attribute
name, t is its type, ce states whether or not a is a foreign key, cp states whether or
not a is a primary key, n states whether or not a can be null, and d is a default
value if one is available.
l K p, F denotes a set of key of TR and gives information about each key integrity
constraints, K p;F :¼ b j b :¼h

:¼ f a n a :¼h a n ; t ; ce ; cp ; n ; d i g

represents a key (an
attribute which can be a key or a part of a composed key), kr is the name of a key

f kr ; ce ; cp ; re ; f a i g , where b