RGMapping¶
What is RGMapping?¶
GART facilitates seamless conversion between data models, enabling the transformation of data updates from relational databases into corresponding graph data constructs as per customized model mapping rules, termed RGMapping. The versatility of GART lies in its provision for database administrators (DBAs) to articulate a variety of data model conversion principles.
The illustration below serves as an example of the RGMapping process within GART in a fraud detection example. It delineates how users can establish mapping directives that link relational data constructs to their graph-based counterparts. GART processes these mapping instructions, methodically applying them to the relational data, subsequently ensuring the relational and graph data sets are in sync. Users are empowered to interrogate the graph data using graph-specific query languages, such as Cypher or Gremlin.
An overview of RGMapping in GART.¶
Tip
On the left side, there’s a representation of a relational OLTP (Online Transaction Processing) database with a traditional relational model. This indicates that data, likely involving participant IDs and the method of transaction, is being added to a table named TRANSACTION.
The middle section shows the definition of transformation rules (RGMapping) through an example in Python code. Functions named def_vertex and add_edge are defined, which are used to convert relational model data—related to persons (Person) and transactions (Trans)—into vertices and edges in a graph model. P_ID1 and P_ID2 represent individual IDs, and HOW represents the transaction mode, and these are used to create corresponding elements in the graph.
On the right side is a graph-based OLAP (Online Analytical Processing) model, where data is presented in graph form. There is a routine named FRAUD_DETECTION, which performs queries on the graph such as using the findCycle function to identify potential cycles within transactions (Trans). Identifying such cycles could be useful for detecting fraudulent activities.
Overall, the image illustrates a process where relational data is transformed into graph data through mapping rules (RGMapping), allowing database administrators (DBAs) to define rules for such conversions and enabling advanced analytic operations like fraud detection using a graph database.
Interface of RGMapping¶
In the fraud detection example, the user can define rules for RGMapping as described below. This model transformation rule includes the user’s definition of the graph structure and how the information in the relational data is mapped to the vertices, edges, and attributes in the graph.
Tip
See this section for a specific semantic explanation.
SQL/PGQ¶
1CREATE PROPERTY GRAPH ldbc
2VERTEX TABLES (
3 "PERSON"
4 KEY ( "p_id" )
5 LABEL "person" PROPERTIES ( p_id AS "p_id", name AS "p_name" )
6)
7EDGE TABLES (
8 "TRANSFER"
9 SOURCE KEY ( "P_ID1" ) REFERENCES "PERSON"
10 DESTINATION KEY ( "P_ID2" ) REFERENCES "PERSON"
11 LABEL "transfer" PROPERTIES ( t_data AS "t_date" )
12)
The RGMapping rule can be written in SQL/PGQ. It creates a graph named ldbc, which contains a type of vertices PERSON and a type of edges TRANSFER (it ignores the label name which is the same as the table name). It shows the correspondence between the vertices, edges and their properties in the graph and the columns in the table.
YAML¶
1!!gart.pgql.GSchema
2graph: ldbc
3database: ldbc
4enableRowStore: false
5vertexMappings:
6 vertex_types:
7 - type_name: person
8 dataSourceName: PERSON
9 idFieldName: p_id
10 mappings:
11 - property: p_id
12 dataField:
13 name: P_ID
14 - property: p_name
15 dataField:
16 name: NAME
17edgeMappings:
18 edge_types:
19 - type_pair:
20 edge: transfer
21 source_vertex: person
22 destination_vertex: person
23 dataSourceName: TRANSFER
24 sourceVertexMappings:
25 - dataField:
26 name: P_ID1
27 destinationVertexMappings:
28 - dataField:
29 name: P_ID2
30 dataFieldMappings:
31 - property: t_date
32 dataField:
33 name: T_DATA
The RGMapping rule can also be written in YAML. It defines the graph schema for the graph named ldbc. It specifies the mapping between the vertices, edges and their properties in the graph and the columns in the table.
The examples we give are equivalent conversion conditions to those described above for SQL/PGQ.