Many seasoned users of traditional databases and data frameworks find themselves at a crossroads when transitioning from a familiar relational database to the realm of graph databases. The time and effort invested in learning graph query commands do not necessarily ease this early challenge of seamlessly migrating data to a graph database.
For users grappling with the complexity of managing hundreds of data fields scattered across numerous relational tables, the task of data migration proves to be an incredibly daunting challenge:
- Inappropriate Distinction of Nodes and Edges
The nomenclature of data tables often presents all tables as distinct entities in the real world. This can lead to confusion when users try to discern which tables represent authentic entities and which ones depict relationships between these entities.
- Excessive Redundant Fields Lingering in Schemas
The idea of 'redundant fields,' intended for addressing the inefficiency of SQL’s table JOIN queries, lingers in users' minds. This makes the removal or replacement of these fields challenging, especially when dealing with the design of graph data.
- Insufficient Restructuring of the Table Framework
After numerous iterations of modifications to the table structures, the final graph model may, at times, deviate significantly from the original table structure. Embarking on such major transformation is a task very few beginners are willing to undertake.
Blurt out Truth
Whether the user's data is structured in tables or not, it often cannot be directly converted into graph data. Graph data adheres to specific requirements: nodes must possess unique IDs serving as their identity cards, while edges must have designated FROM and TO, both referencing node IDs within the graph. Only then can we truly appreciate the beauty of an edge, "a magnificent bridge linking nodes together!"
An illustration of node’s ID and edge’s FROM, TO
 primary key foreign key
Tables in SQL Server
foreign key primary key
(Feel free to interchange the FROM and TO of the edge as long as the edge's meaning remains coherent. For instance, setting PATIENT's _id as FROM and BED's _id as TO signifies 'patient check-in to a bed', while the reverse suggests 'bed receives a patient'.)
- In DEPARTMENT.csv, PATIENT.csv, DOCTOR.csv and BED.csv, rename headers of columns containing primary keys to '_id'.
- In IMPATIENT.csv, rename header 'PNO' to '_from', rename header 'RBNUM' to '_to', and delete the entire column 'RNUM'.
- In DIAGNOSIS.csv, rename header 'PNO' to '_to', rename header 'DNAME' to '_from', and replace the data under 'DNAME' with the corresponding data from the '_id' column in DOCTOR.csv.
- Create BELONGTO.csv with headers '_from' and '_to'.
- Copy the data under '_id' and 'DEPART' in DOCTOR.csv to '_from' and '_to' in BELONGTO.csv, ensuring the corresponding relationships of data in the same row are maintained. Then, delete the entire 'DEPART' column in DOCTOR.csv.
- Create ROOM.csv with header '_id'. Copy the unique values under 'RNUM' in BED.csv to the '_id' column in ROOM.csv.
- Copy the data under '_id' and 'RNUM' in BED.csv to '_from' and '_to' in BELONGTO.csv, ensuring the corresponding relationships of data in the same row are maintained.
- Copy the unique combined values under 'RNUM' and 'DEPART' in BED.csv to '_from' and '_to' in BELONGTO.csv, ensuring the corresponding relationships of data in the same row are maintained. Then delete the entire 'RNUM' and 'DEPART' columns in BED.csv.
Multiple approaches are available to import graph data into a designated graphset within the Ultipa graph system. Such as upload CSV files individually through Ultipa Manager, a user-friendly visualization tool for managing the Ultipa Graph system, or bulk import all files at once via the command-line utility, Ultipa Importer.