What are Relational Databases?
Relational databases store their data in columns and rows. Rows are also called tuples or records. Together, the columns and rows make tables which have relationships (keys) to other tables. One table has an unique Primary Key, while the other table has a Foreign Key in a One to Many relationship.
What are Graph Databases?
Relational databases are the current most common database technology and have been for many years. However, they are not the only horse in the race. GraphDBs are the child of fellow math geeks who found uses for Graph Theory. Graph Theory is the study of the connections of vertices, nodes, or points which are connected by edges, arcs, or lines. Like a GraphDB, each of these objects can have their own properties. For example, lines can have magnitude and nodes can have weight. GraphDBs such as Neo4j, have two main objects: Nodes and Relationships (which connect the nodes).
What is the practical difference?
For Relational Databases, a statement is required to tell the RDBMS to retrieve data or "querying" the tables. This statement requires knowledge of the schema of the tables. The command is not just a request, but it actually tells how to get the data.
Consider the following query which returns all names of people in a specific department. The query is asking for all rows in the Person table who may be in the Person_Department table connected by the relationship of the Id and the PersonId. It then finds all Departments records that match the Person_Department table where the name is "IT Department". The Person_Department table is required because multiple people can belong to the same Department and a single Person could work in multiple Departments. Without this relationship table, we would have duplicated data - we would either have multiple Person records with different DepartmentIds or we would have multple Department records with different PersonIds.
For Graph Databases, the statement requires less knowledge of the schema and requires no relationship lookup. Consider the following Cypher (Neo4j), which is asking for all matching nodes from Persons to Department who's relationship is an Employee and the department's name is "IT Department". The results of that match are to return the Person's name value.
In the next blog entry in this series, we will look closer at this schema and what properties we can add to the nodes and the relationship. The key take away here is that the relationship is itself an object that can have properties much like the node can.
Relational databases store their data in columns and rows. Rows are also called tuples or records. Together, the columns and rows make tables which have relationships (keys) to other tables. One table has an unique Primary Key, while the other table has a Foreign Key in a One to Many relationship.
What are Graph Databases?
Relational databases are the current most common database technology and have been for many years. However, they are not the only horse in the race. GraphDBs are the child of fellow math geeks who found uses for Graph Theory. Graph Theory is the study of the connections of vertices, nodes, or points which are connected by edges, arcs, or lines. Like a GraphDB, each of these objects can have their own properties. For example, lines can have magnitude and nodes can have weight. GraphDBs such as Neo4j, have two main objects: Nodes and Relationships (which connect the nodes).
What is the practical difference?
For Relational Databases, a statement is required to tell the RDBMS to retrieve data or "querying" the tables. This statement requires knowledge of the schema of the tables. The command is not just a request, but it actually tells how to get the data.
Consider the following query which returns all names of people in a specific department. The query is asking for all rows in the Person table who may be in the Person_Department table connected by the relationship of the Id and the PersonId. It then finds all Departments records that match the Person_Department table where the name is "IT Department". The Person_Department table is required because multiple people can belong to the same Department and a single Person could work in multiple Departments. Without this relationship table, we would have duplicated data - we would either have multiple Person records with different DepartmentIds or we would have multple Department records with different PersonIds.
SELECT Person.name FROM Person
LEFT JOIN Person_Department
ON Person.Id = Person_Department.PersonId
LEFT JOIN Department
ON Department.Id = Person_Department.DepartmentId
WHERE Department.name = "IT Department"
For Graph Databases, the statement requires less knowledge of the schema and requires no relationship lookup. Consider the following Cypher (Neo4j), which is asking for all matching nodes from Persons to Department who's relationship is an Employee and the department's name is "IT Department". The results of that match are to return the Person's name value.
MATCH (p:Person)<-[:EMPLOYEE]-(d:Department)
WHERE d.name = "IT Department"
RETURN p.name