Value of the Graph Database #2.
We sometimes add new features in response to customer feedback to improve customer services.
What if we need to add new attributes in the database due to the newly-added features, while running a service?
In the existing relational database environment, there are so many things to be considered that relevant development cannot be done quickly.
Graph database provides flexibility in data operation through a schema-less data structure.
In this the second posting on the value of graph database, we would like to introduce the work flexibility that can be realized with a “schema-less” structure.
A huge volume of data (from SNSs, geographic information systems, or IoT devices) spews out relentlessly in the modern society and spreads in various, unstructured forms. In addition, in response to rapidly-changing market conditions and customer needs these days, what we need is a flexible development environment.
What do you think is the difference between a graph database and a relational database with a structured data structure (e.g. schema)?
Flexibility in data operations enabled by graph database and a schema-less structure!
Unlike relational database (RDB), graph database (GDB) stores each data as an object, rather than inserting it into a structured-format table. Therefore, the table schema used by RDB does not exist in GDB.
Such absence of a schema gives you flexibility in data operations, which means “no problem” even if the data volume increases or the type of input varies. Since a large volume of data in a variety of forms is stored in the database as they are entered, and each object can be independent or aggregate, GDB features excellent operability in both single-server and distributed-data environments.
GDB represents the relationship between each data object as a line (edge or relationship). The data relationship can be easily expressed by simply adding an attribute to a table as RDB does, or by connecting a relationship line between data objects (vertices or nodes) without having to scan the entire table; this allows users to change the data more easily. At the end of the day, thanks to these features, the GDB users can store, process, and modify unstructured data and real-time input data in a more flexible manner.
Anyone who has ever used an existing RDB would understand adding a column to a particular table in the database requires multiple confirmations and a lot of work, as shown in the figure above.
When you have to add a value with a new attribute to an existing table in an RDB, you should first add a column corresponding to the new attribute, check the foreign key table for interoperation, add a column to the target table, and reset the constraints.
A series of these tasks require an understanding on the overall database design and may cause problems such as denormalization of the data model, consistency issues, unnecessary null generations in the table, and application modifications.
On the other hand, when you add a value with a new attribute in GDB, all you have to do is create a point (vertex or node) with a new property on the graph, and then connect different points (vertices or nodes) with a line (edge or relationship). That’s it! You can also assign one or more labels to nodes for easier data management.
In such a rapidly changing market environment, GDB offers flexibility, adaptability, and thereby convenience to a service development environment.