|
1 | 1 |
|
2 | 2 | [[graphdb-vs-rdbms]] |
3 | 3 | = Transition from relational to graph database |
4 | | -:description: This chapter explores the concepts of graph databases from a relational developer's point of view. |
| 4 | +:description: This page explores the concepts of graph databases from a relational developer's point of view. |
5 | 5 |
|
6 | | -== Introduction |
7 | | -The article aims to explain the conceptual differences between relational and graph database structures and data models. |
| 6 | +This page explores the conceptual differences between relational and graph database structures and data models. |
8 | 7 | It also gives a high-level overview of how working with each database type is similar or different - from the relational and graph query languages to interacting with the database from applications. |
9 | 8 |
|
10 | | - |
11 | 9 | [#relational-vs-graph] |
12 | 10 | == Relational database overview |
13 | 11 |
|
14 | | -Relational databases have been the work horse of software applications since the 80's, and continue as such to this day. |
15 | | -They store highly-structured data in tables with predetermined columns of specific types and many rows of those defined types of information. |
| 12 | +Relational databases store highly-structured data in tables with predetermined columns of specific types and rows of those defined types of information. |
16 | 13 | Due to the rigidity of their organization, relational databases require developers and applications to strictly structure the data used in their applications. |
17 | 14 |
|
18 | 15 | In relational databases, references to other rows and tables are indicated by referring to primary key attributes via foreign key columns. |
19 | 16 | Joins are computed at query time by matching primary and foreign keys of all rows in the connected tables. |
20 | | -These operations are compute-heavy and memory-intensive and have an exponential cost. |
21 | | - |
22 | | -When many-to-many relationships occur in the model, you must introduce a _JOIN_ table (or associative entity table) that holds foreign keys of both the participating tables, further increasing join operation costs. |
23 | | -The image below shows this concept of connecting a Person (from Person table) to a Department (in Department table) by creating a Person-Department join table that contains the ID of the person in one column and the ID of the associated department in the next column. |
| 17 | +These operations are compute-heavy and memory-intensive, and have an exponential cost. |
24 | 18 |
|
25 | | -As you can probably see, this makes understanding the connections very cumbersome because you must know the person ID and department ID values (performing additional lookups to find them) in order to know which person connects to which departments. |
26 | | -Those types of costly join operations are often addressed by denormalizing the data to reduce the number of joins necessary, therefore breaking the data integrity of a relational database. |
| 19 | +When many-to-many relationships occur in the model, you must introduce a _JOIN_ table (or associative entity table) that holds foreign keys of both the participating tables, further increasing join operation costs, as shown in the diagram: |
27 | 20 |
|
28 | 21 | .Relational model |
29 | | -image::relational_model.svg[role="popup-link",width=600] |
| 22 | +image::relational_model.svg[Depiction of a relational database with connecting points in each table,role=popup,width=600] |
| 23 | + |
| 24 | +The diagram shows the concept of connecting a `Person` (from the `Person` table) to a `Department` (in `Department` table) by creating a `Person-Department` join table that contains the ID of the person in one column and the ID of the associated department in the next column. |
| 25 | + |
| 26 | +This structure makes understanding the connections cumbersome, because you must know the person ID and department ID values (performing additional lookups to find them) in order to know which person connects to which departments. |
| 27 | +These types of costly join operations are often addressed by denormalizing the data to reduce the number of joins necessary, therefore breaking the data integrity of a relational database. |
30 | 28 |
|
31 | | -Although not every use case is a good fit for this stringent data model, the lack of viable alternatives and the wide support for relational databases made it difficult for alternative models to break into the mainstream. |
32 | | -However, the NoSQL era arrived in the market, filling some needs for users and businesses, but still missing the importance of the connections between data. |
33 | | -This is how graph databases were born. |
34 | | -They were designed to provide the greatest advantage in the connected world we live in today. |
| 29 | +Graph databases cater for use cases that weren't a good fit for relational data models and offer new possibilities to connect data. |
35 | 30 |
|
36 | 31 | [#relational-to-graph] |
37 | 32 | == Translating relational knowledge to graphs |
|
0 commit comments