Victor Lee Ph.D - Graph-Powered Analytics and Machine Learning with TigerGraph: Driving Business Outcomes with Connected Data

• 2021-04-12: First Release
• 2021-09-29: Second Release
• 2022-02-22: Third Release
• 2022-04-21: Fourth Release
• 2022-05-19: Fifth Release
• 2022-08-24: Sixth Release
• 2022-10-06: Seventh Release

With Early Release ebooks, you get books in their earliest formthe authors raw and unedited content as they writeso you can take advantage of these technologies long before the official release of these titles.

This will be the 2nd chapter of the final book.

If you have comments about how we might improve the content and/or examples in this book, or if you notice missing material within this chapter, please reach out to the editor at gobrien@oreilly.com.

In Chapter 1, we showed the potential of graph analytics and machine learning applied to human and business endeavors, and we proposed to present the details in three stages: the power of connected data, the power of graph analytics, and the power of graph machine learning. In this chapter, we will take a deep dive into the first stage: the power of connected data.

Before we delve into the power of connected data, we need to lay some groundwork. We start by introducing the concepts and nomenclature of the graph data model. If you are already familiar with graphs, you may want to skim this section to check that were on the same page with regard to terminology. Besides graphs themselves, well cover the important concepts of a graph schema and traversing a graph. Traversal is how we search for data and connections in a graph.

And along the way we talk about the differences between graph and relational databases and how we can ask questions and solve problems with graph analytics that would not be feasible in a relational database.

From that foundational understanding of what is a graph, we move on to present examples of the power of a graph by illustrating six ways that graph data provides you with more insight and more analytical capability than tabular data.

After completing this chapter, you should be able to:

1. Use the standard terminology for describing graphs

2. Know the difference between a graph schema and a graph instance

3. Create a basic graph model or schema from scratch or from a relational database model

4. Apply the traversal metaphor for searching and exploring graph data

5. Understand six ways that graph data empowers your knowledge and analytics

6. State the entity resolution problem and show how graphs resolve this problem

Graph Structure

In Chapter 1, we introduced you to the basic idea of a graph. In this section, we are going to go deeper. First we will establish the terminology that we will be using for the rest of this book. Then we will talk more about the idea of a graph schema, which is the key to having a plan and awareness of your datas structure.

Graph Terminology

Suppose youre organizing data about movies, actors, and directors. Maybe you work for Netflix or one of the other streaming services, or maybe youre just a fan.

Lets start with one movie, Star Wars: A New Hope, its three main actors and its director. If you were building this in a relational database, you could record this information in a single table, but the table would grow quickly and rapidly become unwieldy. How would we even record details about a movie, the fact that 50 actors appeared in it, and the details of each of those actors careers, all in one table?

Best practice for the design of relational databases would suggest putting actors, movies and directors each into a separate table, but that would mean also adding in cross-reference tables to handle the many-to-many relationships between actors and movies and between movies and directors.

So in total youd need five tables just to represent this example in a relational database, as in .

Separating different types of things into different tables is the right answer for organizing the data, but to see how one record relates to another we have to rejoin the data. A query asking which actors worked with which directors would involve building a temporary table in memory called a join table that includes all possible combinations of rows across all the tables youve called which satisfy the conditions of the query. Join tables are expensive in terms of memory and processor time.

Figure 1-1. Diagram of relational tables for a simple movie database

Figure 1-2. Temporary table created from relational database query showing how three actors are linked to George Lucas via the movie Star Wars

As we can see from , there is a lot of redundant data in this table join. For very large or complex databases, you would want to think of ways to structure the data and your queries to optimize the join tables.