Read Anytime Anywhere Easy Ebook Downloads at ebookmeta.

com

Practical Graph Structures in SQL Server and Azure

SQL: Enabling Deeper Insights Using Highly
Connected Data 1st Edition Louis Davidson

https://ebookmeta.com/product/practical-graph-structures-in-
sql-server-and-azure-sql-enabling-deeper-insights-using-
highly-connected-data-1st-edition-louis-davidson-2/

OR CLICK HERE

DOWLOAD EBOOK

Visit and Get More Ebook Downloads Instantly at https://ebookmeta.com

 Recommended digital products (PDF, EPUB, MOBI) that
you can download immediately if you are interested.

Practical Graph Structures in SQL Server and Azure SQL:

Enabling Deeper Insights Using Highly Connected Data 1st
Edition Louis Davidson
https://ebookmeta.com/product/practical-graph-structures-in-sql-
server-and-azure-sql-enabling-deeper-insights-using-highly-connected-
data-1st-edition-louis-davidson/
ebookmeta.com

Pro SQL Server 2022 Wait Statistics: A Practical Guide to

Analyzing Performance in SQL Server and Azure SQL
Database, 3rd Edition Thomas Larock
https://ebookmeta.com/product/pro-sql-server-2022-wait-statistics-a-
practical-guide-to-analyzing-performance-in-sql-server-and-azure-sql-
database-3rd-edition-thomas-larock-2/
ebookmeta.com

Pro SQL Server 2022 Wait Statistics: A Practical Guide to

Analyzing Performance in SQL Server and Azure SQL
Database, 3rd Edition Thomas Larock
https://ebookmeta.com/product/pro-sql-server-2022-wait-statistics-a-
practical-guide-to-analyzing-performance-in-sql-server-and-azure-sql-
database-3rd-edition-thomas-larock/
ebookmeta.com

Flat Earth FAQ 1st Edition Eric Dubay

https://ebookmeta.com/product/flat-earth-faq-1st-edition-eric-dubay/

ebookmeta.com
Let Us Create First Edition Bishop Kendrick Nkole Kunda

https://ebookmeta.com/product/let-us-create-first-edition-bishop-
kendrick-nkole-kunda/

ebookmeta.com

Plant Based Comfort Food Classics Simple and Nourishing

Vegan Dishes Sandra Vungi

https://ebookmeta.com/product/plant-based-comfort-food-classics-
simple-and-nourishing-vegan-dishes-sandra-vungi/

ebookmeta.com

Personal Sustainability Exploring the Far Side of

Sustainable Development 1st Edition Oliver Parodi (Editor)

https://ebookmeta.com/product/personal-sustainability-exploring-the-
far-side-of-sustainable-development-1st-edition-oliver-parodi-editor/

ebookmeta.com

A Guide to UX Design and Development : Developer's Journey

Through the UX Process 1st Edition Tom Green

https://ebookmeta.com/product/a-guide-to-ux-design-and-development-
developers-journey-through-the-ux-process-1st-edition-tom-green/

ebookmeta.com

Modern Physics Kenneth S. Krane

https://ebookmeta.com/product/modern-physics-kenneth-s-krane/

ebookmeta.com
Using Understanding by Design in the Culturally and
Linguistically Diverse Classroom 1st Edition Amy J.
Heineke
https://ebookmeta.com/product/using-understanding-by-design-in-the-
culturally-and-linguistically-diverse-classroom-1st-edition-amy-j-
heineke/
ebookmeta.com
Louis Davidson

Practical Graph Structures in SQL

Server and Azure SQL
Enabling Deeper Insights Using Highly Connected
Data
Louis Davidson
Cleveland, TN, USA

ISBN 978-1-4842-9458-1 e-ISBN 978-1-4842-9459-8

https://doi.org/10.1007/978-1-4842-9459-8

© Louis Davidson 2023

This work is subject to copyright. All rights are solely and exclusively
licensed by the Publisher, whether the whole or part of the material is
concerned, specifically the rights of translation, reprinting, reuse of
illustrations, recitation, broadcasting, reproduction on microfilms or in
any other physical way, and transmission or information storage and
retrieval, electronic adaptation, computer software, or by similar or
dissimilar methodology now known or hereafter developed.

The use of general descriptive names, registered names, trademarks,

service marks, etc. in this publication does not imply, even in the
absence of a specific statement, that such names are exempt from the
relevant protective laws and regulations and therefore free for general
use.

The publisher, the authors, and the editors are safe to assume that the
advice and information in this book are believed to be true and accurate
at the date of publication. Neither the publisher nor the authors or the
editors give a warranty, expressed or implied, with respect to the
material contained herein or for any errors or omissions that may have
been made. The publisher remains neutral with regard to jurisdictional
claims in published maps and institutional affiliations.

This Apress imprint is published by the registered company APress

Media, LLC, part of Springer Nature.
The registered company address is: 1 New York Plaza, New York, NY
10004, U.S.A.
To Val, what a life we have had so far… here’s to more of it.
Preface
I started working on my first book 23 years ago. It was on relational
database design. I had learned a little about graphs at that point from a
class I took by Dr. David Rozenshtein (his 1997 book The Essence of SQL
: A Guide to Learning Most of SQL in the Least Amount of Time was
essential). His class was very influential and taught me a lot about how
to think about SQL problems. This was a really long time ago (clearly),
but in that same class, one of the sections was on trees in SQL Server. I
was hooked on the subject.
In my 2012 edition of my database design book, I started to include
hierarchies as one of the topics. In my latest book, that came out after
SQL Server 2019 arrived, I promised a book of SQL Graph. This book in
your hands is the answer to that challenge.
This is my first programming-based book in many years. Usually I
am more interested in helping you shape a design, but in this case, I
want to show you the mechanics of building a graph database solution
using SQL Server and leave it more to you to decide what to do with it
from there. Part of this is due to the newness and relative complexity of
the topic, but also because graphs are meant to be very flexible
structures…way more flexible than the standard relational databases.
The chapters of the book are as follows:
Chapter 1: What a graph is and ways graphs can be used. I touch on
some of the underpinnings of what makes a graph a graph and a taste
of the theory that mathematicians use to describe and work with
graph data structures.
Chapter 2: How graphs are implemented and the algorithms that are
used to process them. While the basic structure of the graph is really
simple, there is some value to understanding how graph structures
are built in coding and having some idea of what you will see in the
rest of the book.
Chapter 3: The syntax that Microsoft has implemented for use with
graph data stored in SQL Server tables is similar to what you
probably already know from working with relational tables, but it is
so much more. In this chapter, I teach you how to use the syntax
provided by Microsoft to query graph tables in interesting ways.
 Chapter 4: Whereas in Chapter 3 I showed basic query techniques, in
this chapter I show methods that can help you load and protect the
integrity of the data in your SQL Graph tables.
Chapter 5: A tree structure built using SQL Graph objects, including
code to load and manipulate those nodes in ways that you will need
when building production systems. In this chapter, you explore the
code to create and manage a tree in SQL Server, along with an
example of how it all works.
Chapter 6: In this chapter, I dig into performance. You’ll examine a
new method of implementing a tree for comparison to the SQL Graph
objects and build some objects you can use to write queries to report
on data in your trees that operate faster. You will then build some
large, random data sets and compare how these methods perform
with certain larger sized data sets.
Chapter 7: The goal of this chapter is to build a data structure that
can show some of the concerns with working with directed graphs
that are not trees. You will build a fairly simple bill of materials data
structure to demonstrate the techniques you will need when you are
working with these structures, which are similar to trees but still
quite different.
Chapter 8: In this chapter, you will do some querying of larger data
sets in SQL Server’s graph objects. To do this, you will implement a
graph structure and data generation tools to try on large sets of data
to match your expected needs. Finally, you will explore a set of
performance tips for handling graph objects.
SQL Server’s relational engine may never be acceptable as a
complete replacement for a specific graph database system like
CosmosDB, but even in its relative infancy with just a few iterations
complete in the SQL Server lifecycle, it has become a nice way to extend
your data structures inside existing relational data structures quickly
and easily.
You can find the downloads in the book in two locations. First, on
Apress’s website you will find the original code for this book and any
errata that is reported:
https://github.com/Apress/practical-graph-
structures. Second, at
https://github.com/drsqlgithub/GraphBook1 you will find
that code plus any new code and projects I create that pertain to
learning graphs until I start working on a second edition of this book
someday.
If you have any direct questions about the content, send email to
[email protected] and I will do what I can.
Any source code or other supplementary material referenced by the
author in this book is available to readers on GitHub
(https://github.com/Apress). For more detailed information, please
visit www.apress.com/source-code.
Acknowledgments
My wife, for suffering through yet another long and painful book
writing process.
The Microsoft MVP Program for all the connections it has provided
me to meet wonderful, bizarrely smart people for 18 years. And my
lead, Rie Merritt, for all she has done for me through the years; amazing
how we met so many years ago. Just meeting Bob Ward and Conor
Cunningham is thrill enough, and there have been hundreds besides
them.
Shreya Verma and Arvind Shyamsundar for their help over the past
few years as I attempted to do crazy things with the graph objects on
my local personal computer.
Dr. David Rosenstein, who first got me interested in graphs in
relational structures so many years ago. Paul Nielsen for the talks we
had on graph structures.
Kathi Kellenberger for tech editing this book. I appreciate the hard
work!
All the doctors/medical professionals who kept me alive and kicking
these past few years. (If you want to know more, just ask, if you have a
while to talk. There is a reason this book took me over two years to
write.)
My coworkers at CBN whom I left during the writing of this book. I
hope the graph objects I left you with are serving you nicely.
My new coworkers at Redgate. I have been a friend of Redgate (as
well as a member of Friends of Redgate) for many years, writing for
them. My new manager and teammates have been nothing but
awesome.
Amber Davis, for giving me the chance to be a Dollywood Insider.
Obviously being a Dollywood insider has little to do with this book, but
I just wanted to say it again (which she may never see!) as I am writing
the acknowledgements in the Dollywood Dreammore lobby. I learned a
lot from her that has been useful writing some of this book and in my
new job at Redgate as Simple-Talk editor.
Table of Contents
Chapter 1:​Introduction to Graphs
Graph Fundamentals
Definition
Summary
Chapter 2:​Data Structures and Algorithms
Basic Implementation
Acyclic Graphs
Trees
Other Acyclic Graphs
Cyclic Graphs
Non-Directed Graphs
Summary
Chapter 3:​SQL Graph Table Basics
Object Creation
Creating Data
Querying Data
Node-to-Node Querying
Traversing Variable Level Paths
Summary
Chapter 4:​SQL Graph Tables:​Extended Topics
Advanced Data Creation Techniques
Building an Interface Layer
Loading Data Using Composable JSON Tags
Heterogenous Queries
Integrity Constraints and Indexes
 Edge Constraint
Uniqueness Constraints (and Indexes)
Additional Constraints
Metadata Roundup
List Graph Objects in the Database
Types of Graph Columns
Tools for Fetching Graph Information
Summary
Chapter 5:​Tree Data Structures
Creating the Data Structures
Base Table Structures
Demo Sales Structure
Essential Tree Maintenance Code
Code To Create New Nodes
Reparenting Nodes
Deleting a Node
Tree Output Code
Returning Part of the Tree
Determining If a Child Node Exists
Aggregating Child Activity at Every Level
Summary
Chapter 6:​Tree Structures, Algorithms, and Performance
Alternative Tree Implementation
Path Technique
Helper Table
Performance Comparison
 Summary
Chapter 7:​Other Directed Acyclic Graphs
The Problem Set
The Example
Determining If a Part Is Used in a Build
Picking Items for a Build
Printing Out the Parts List for a Build
Summary
Chapter 8:​A Graph For Testing
The Example
Creating the Tables
Loading the Data
The Queries
Performance Tuning Results
Performance Tuning Roundup
Test
Index the Internal Columns
Employ a Maximum Degree of Parallelism of One
Consider Breaking Up Some Queries
The End (or Is It the Beginning?​)
Index
About the Author
Louis Davidson
has been working with databases for
more than 25 years as a corporate
database developer and architect. He is
now the editor for the Redgate Simple
Talk website. He has been a Microsoft
MVP for 18 years. In addition to this
book on graphs in SQL Server, he has
written six editions of his general-
purpose SQL Server database design
book (Apress) and has worked on
multiple other book projects over the
years.
Louis has been active in speaking about database design and
implementation at many conferences over the past 25 years, including
SQL PASS, SQL Rally, SQL Saturday events, CA World, Music City Data,
and the devLink Technical Conference. He has a bachelor’s degree in
computer science from the University of Tennessee at Chattanooga. For
more information, please visit his website at drsql.org.
About the Technical Reviewer
Kathi Kellenberger
is a Customer Success Engineer at
Redgate and a Data Platform MVP. She
has worked with SQL Server since 1998
and has authored, co-authored, or tech
reviewed over 20 technical books. Kathi
is a longtime volunteer at LaunchCode in
St. Louis where she has taught T-SQL in
the LaunchCode Women + program.
When Kathi isn’t working, she enjoys
spending time with family and friends,
cycling, singing, and climbing the stairs
of tall buildings.
© The Author(s), under exclusive license to APress Media, LLC, part of Springer
Nature 2023
L. Davidson, Practical Graph Structures in SQL Server and Azure SQL
https://doi.org/10.1007/978-1-4842-9459-8_1

1. Introduction to Graphs
Louis Davidson1
(1) Cleveland, TN, USA

With great power comes great responsibility.--Voltaire (and Spider-

Man’s Uncle Ben)
At its core, a graph data structure is simply a model representing
the connection of one thing to one other thing and then those things to
even more other things. Essentially a graph database formalizes a
database based on many-to-many relationships as the core
relationship.
Everyone who has ever modeled a relational database will either
have modeled a graph purposefully or inadvertently because many-to-
many relationships begin to appear as you add more concepts to your
data model. The vast difference you will see is that relational
implementations, ideally, are rigidly modeled.
The term frequently used to decide whether to model a many-to-
many relationship in a relational database or a graph structure is
whether the data is highly connected. With a graph database
structure, you can connect many tables to many other tables and query
that structure in a different (yet quite similar) manner to how you
query a relational database.
There are many examples of graphs, but some of the most common
examples you probably hear about are
Social networks, where you record the relationship from one person
to another
 Suggestion processing systems like online retailers use to record the
relationship between a person and the products they have looked at
and ordered and how that matches up with other people who have
similar interests
Manager-employee relationships where the employee has a manager
who also has a manager who is likely managed by someone else
With this information, you can discover interesting things about an
object based on its relationships and similarity to relationships other
entities have.
Possibly the most famous graph that most people will have heard of
is the basis of the parlor game “Six Degrees of Kevin Bacon.” This game
suggests that everyone is no more than six connections away from
anyone else, including Kevin Bacon (and not just that your favorite
breakfast meat is bacon.)
The fact that graphs are very natural data structures does not make
them easy to work with. Because they are less rigid data structures
than relational tables, the flexibility makes them quite complex to work
with (certainly in the database engine). Graph objects can represent a
very messy reality, and the more complex the data you are modeling,
the more complicated it is to work with. Of course, the reward for that
complexity is the solutions you create are often quite tremendous.
Like many computer science topics, graphs are also a fundamental
mathematical concept. Some of the insights you can get from the math
of graphs will help once we start analyzing data. So, to begin this book
on graphs, I will provide a very cursory look at some mathematical
concepts as I define what a graph is and how it can be used in software.
Note that the concepts in this chapter were gleaned from many
resources and are generally common knowledge. However, when I was
searching for resources to read for an introduction to the concepts of
graphs, including mathematical proofs (none of which will come up in
this book, so no worries!) of such concepts, one was Introduction to
Graph Theory by Richard J. Trudeau from Dover Publications in 1993. It
is far deeper than this chapter and definitely more than you need to
learn to code with SQL Server’s graph database extensions, and
mathematical proofs have always been my Kryptonite! However, I
highly recommend this as a place to ascend to the next level beyond
what I will show you.
 This chapter will be a quick, high-level overview of the many topics
you will find in this book and many other sources, plus ideas you may
wish to use in the graph table objects I will cover once you start
building objects. The book itself will be mostly focused on very
practical applications and how to write certain types of code, but I
found that knowing some of the graph fundamentals really helped me
to envision what I was attempting to accomplish.

Graph Fundamentals
While most readers will have the explicit goal of applying a graph to a
specific problem they are trying to solve, it is best to start at the
beginning and discuss what a graph is in the pure sense. (If you don’t
care, you can skip to Chapter 3 where the T-SQL code starts!) Going
through the fundamentals will help you free your mind from
preconceived notions. Perhaps, more importantly, you can ignore the
limitations of the tools and specific problem sets you may wish to solve
and just think about the whole problem set.
In math, there are the concepts of “pure” math and “applied” math.
Pure math is math for math’s sake. It is there to ask, “what can be done
with a construct?” without asking the limiting questions of, “is this
helpful code to solve my problem or, even more importantly, any
problem?” Applied math is more or less the sort of thing we typical
computer architects/programmers are typically interested in since we
have a problem and want to find something to help us with that
problem (and immediately so). Most of the time, solutions are only
interesting if they can solve the specific problems we currently know
about and have a manager riding on our back.
However, I always prefer to start just trying to see what I can
accomplish with a new tool before getting my hands dirty
(metaphorically, of course; as a programmer, my hands never get dirty
at work unless the day’s snack includes chocolate).
Some of the things I will discuss will then be familiar in
understanding what we might do when looking for patterns in the data
and eventually translating into algorithms. Some designs may not be
realistically possible due to current computing limitations in SQL
Server (or any graph database platform) or reasonable hardware
limitations at the time of writing in 2023. Having written my first book
in 2000, it astounds me how different this statement feels to me 23
years later sitting here with a computer on my desk that has more
power that medium to large corporations were running on when I first
wrote T-SQL.
In one of my sample databases you can download, I have millions of
rows in just one table, and I can process reasonable queries on my
desktop computer in mere minutes. Limitations always exist, but there
are fewer and fewer limitations for every generation of computer
architecture that passes.
My goal here in this first chapter (and to a large extent, the second
chapter) is to simply introduce some of the terms and concepts around
graphs to help you understand how graphs are shaped and, eventually,
processed.

Definition
Graphs are based on two primary data structures: nodes (or in math
terms, vertices), and edges. Nodes represent a thing that one might
care about, much like a table in a relational database. Edges establish a
connection between exactly one or two nodes (when the node count is
one, it means the node is related to itself.) A graph is defined as being a
set of nodes and a set of edges.
In a graph database, a node is like most any table with attributes
describing what the node represents. The edge is analogous to a many-
to-many relationship table with at least attributes to represent the
node that the relationship is from and which it is to. You will see that
two major things set these new concepts apart from a relational
implementation.
First, the from and the to in an edge generally can be from any node
object. Whereas a relational table column used to reference another
table value communicates that it is a foreign key from Table X and
nothing else, the from and to attributes of an edge can be from multiple
different node types if you so desire.

Tip I am fully aware that you can put any value into a column, so
every foreign key value in a column needn’t come from the same
 table. But that is not how it should be done because data where a
column can mean multiple things is very confusing in a relational
table. Graph structures work very similar to how relational tables
work. Still, they have special properties that allow two rows to
contain data from multiple sources without confusing the
user/engine.

Second, to make use of these flexible structures, a special set of

operations is enabled in a graph engine, allowing easier access to the
meaning of the relationships than we can get using SQL. More detail on
these operations and the basic algorithms are in Chapters 2 and 3.
For the first example, consider the simple graph represented in
Figure 1-1—two nodes connected by a single edge. If the type of node is
important, it will be indicated using different shapes.

Figure 1-1 Simple graph

When diagraming a graph, edges may also have a property of

direction. The direction indicates that the relationship is not reciprocal.
For example, consider Figure 1-2.

Figure 1-2 Simple directed graph

In this graph, N1 connects to N2, but N2 is not connected to N1. This

is analogous to a social media relationship such as when I follow Paul
McCartney, but Paul McCartney doesn’t follow me! It will often be very
important to understand the value of the direction because of the
unbalanced nature of some relationships. Mr. McCartney doesn’t all of
the sudden wish to get any communication about where I am speaking
at a conference, but I wish to be informed of his concerts and new
music being released.
In SQL Graph, and other graph products, edges are almost always
directed. This will become important later but will only complicate our
discussion of graphs concepts in general, so to start with, let’s ignore
the directedness of the edges.
In my first example graph in Figure 1-1, I have two nodes and a
single edge. This is a very simple graph, but it is not the simplest graph.
The simplest graph is a graph with 0 edges and 0 nodes, otherwise
referred to as the NULL graph. You can also have a graph with a single
node and no edges, and a single node with a single edge, and so on. (You
can’t have an edge without a node.)
Just like modeling a relational database, there is an inherent danger
in thinking of a graph as a drawing and not a complex data structure.
Consider a graph with the nodes and edges seen in Figure 1-3.

Figure 1-3 Graph with four edges and four nodes

This graph could be expressed as sets of nodes and edges in the

following manner:
Nodes: {N1,N2,N3,N4}; Edges: {E1:{N1,N2}; E2:{N2,N4}; E3:
{N3,N4}; E4:{N1,N3}}
By definition, all nodes and edges must be distinct, much like a table
requires distinct rows. And just like a table, the order of the items in the
sets has no importance. The following graph is the same as
diagrammed and as defined prior to this paragraph:
Nodes: {N2,N3,N1,N4}; Edges: {E2:{N2,N4}; E1:{N1,N2}; E4:
{N1,N3}; E3:{N3,N4}}
When drawing a graph as an image, there is a very similar
consideration. Every programmer with any skill has frequented a white
board to draw a diagram of a structure. If you were to draw a shape of a
circle, a triangle, and a square on the white board, instinctively you
would believe them to be different things. Even if you drew a rectangle,
square, and a rhombus (all shapes with four sides) you would not think
they were the same.
But, in graph terms (just like when diagramming tables), the two
graphs in Figure 1-4 are the same as each other and the graph in Figure
1-3, in which they are considered “equal.”

Figure 1-4 Two identical graph structures

The two graph diagrams in Figure 1-4 are copies of the same graph.
The next concept is related, in that we will look at graphs with the same
shape but different nodes. When a graph has the same node and edge
shape (meaning the same nodes and edges, not diagram shape,) the
graphs are referred to as being isomorphic graphs. For example, the
two graphs in Figure 1-5 are not equal but they are isomorphic because
they have the same shape in their set of data (regardless of whether you
draw them as a square or not).
Figure 1-5 Two isomorphic graph structures
This concept of isomorphism will be, if not actually referred to using
the exact term, interesting in your usage of graphs on occasion.
Consider the set of nodes in Figure 1-6.

Figure 1-6 Sample graphs for comparison

Now, consider that the nodes {Larry, The Who, Rolling Stones},
which form what is known as a subgraph (a set of nodes and edges
that is a part of a graph) of the more complete graph, are isomorphic to
{Fred, The Who, Rolling Stones}. It isn’t a difficult leap to see that since
Fred and Larry are both connected to two similar nodes, that an
additional edge {Fred, Beatles} might be a possibility for Fred. So, the
company may then wish to suggest “Have you heard of The Beatles (or
do you live under a rock)?” Of course, Fred may not be a fan of John,
Paul, George, and Ringo; but the goal of many graphs may be to look for
common traits and then suggest ways to make them more common.
Take this further and you may see patterns occurring from completely
different subgraphs that may indicate a repeatable pattern.
An important concept in subgraphs is a walk in a graph. This refers
to how you can traverse from node to node. For example, in the first
graph in Figure 1-6, starting at Larry you can find a walk from Larry ->
TheWho -> Rolling Stones -> Beatles -> Larry. You can also find many
other walks from any node to any node in this sample graph, since
every node in the graph is connected to every other node. Another term
for a walk is a path, which may be a bit more common since the
operator you will use in SQL Server 2019 and later to find a walk is
named SHORTEST_PATH.
You will often use this concept of a walk to determine the closest
one node is to another. For example, in the second variant of the graph,
the distance from Fred to The Who and Rolling Stones is 1 and to the
Beatles is 2. If you are a user of LinkedIn, you have seen this concept
when you see that you are a first-level connection or second or more to
other people. A second-level connection means you are connected
through one intermediate node.
A concept that is interesting if likely not particularly necessary in
programming typical graph structures is a Euler (pronounced Oiler)
Walk. An Euler Walk consists of the starting node being touched twice
and every edge in the graph touched exactly once. For example,
consider the graphs in Figure 1-7.
Figure 1-7 Graph diagrams to demonstrate walks

Note This gets a little hard to express in text!

In Figure 1-7A, you can traverse from N1 back to N1 through E1->N2-

>E2->N4->E3->N3->E4. And in 1-7B, you can go starting and ending at
N1, through E1->N2->E5->N1->E4->N3->E6->E3->N3->E7->N2->E2-
>N4->E8. However, in 1-7C, it is impossible to do this, because if you
start at N1 and start a walk such as N1->E1->N2->E5->N1->E4, you will
never be able to return to N1. It turns out that for a graph to have a
Euler Walk, all the nodes must be of an even degree (the degree of a
node indicates the number of edges connected to the node).

Note A graph such as 1-7B and 1-7C is a multigraph. A multigraph

allows that we have more than one edge between the same two
nodes. As we get more complex, we can see that an edge often
indicates a role that the nodes play in a relationship. Some edges
don’t make sense, having multiple edges between the same node;
others may make perfect sense. Remember I said earlier that edges
between nodes must be unique. These edges may not be equal, but
instead say two things about the relationship between to nodes, like
in Figure 1-7b, N1->N2 has E1 and E5. One may be a familial
relationship, the other a social network connection, which you
probably would not want to be the same edge for the reason of
traversing a specific type of edge.

Realistically the limitation will come down to the thing that all
modeling decisions come to: semantics. What does the relationship
mean and how will it be used to mean one or more relationships? For
example, you might only logically have one edge between persons
indicating that person is a biological parent to a person; on the other
hand, multiple edges between person and movie could make sense: one
for actor, one for producer, one for director, and so on.
One last bit of graph theory I want to cover is that of a connected
graph. In a connected graph, there is a walk from every node in the
graph to every other node. The graph will be in one or more pieces in a
disconnected graph. In Figure 1-8, we have the simplest connected
graph with more than one node in 1-8A and the simplest disconnected
graph in 1-8B. The graph in 1-8A is said to be in one piece, and the
graph in 1-8B is in two pieces.

Figure 1-8 Simple connected and disconnected graphs

In Figure 1-9, we have a more complex graph in three pieces.

Figure 1-9 Single graph in three pieces

When you have a connected graphs and removing an edge will cause
it to be broken into more pieces, the edge is referred to as a bridge
edge. Consider the graph in Figure 1-10.

Figure 1-10 Graph to demonstrate bridge edges

 There are two bridge edges in this graph. The most obvious is E28.
If you remove it, you will have two multi-node pieces remaining. The
one that is perhaps less obvious is E9. Removing E9 would leave S3
alone and hence one more piece to the graph. When the degree of a
node is 2, removing any edge will leave the remaining edge a bridge
edge.

Graphs In Computing/Directed Graphs

Now that I have introduced a subset of the terminology and shapes of
graphs, it is time move towards the mechanics of graphs you will be
building and using with SQL Server’s SQL Graph feature (or really any
mainstream graph product). All the aforementioned concepts still hold,
but there is one major difference. Edges in computing terms are
generally one way only. An edge that points in one direction only is
referred to as a directed edge and the whole graph as a directed
graph. I will not redefine all the previously introduced concepts in
terms of directed graphs, as the goal of covering the topics was to get
you thinking about graph structures and how they fit together. I will
discuss how they are applicable as it makes sense.
Relationships in a directed graph are in the form shown in Figure 1-
11.

Figure 1-11 Directed edge

Whereas in previous graph examples an edge between N1 and N2

represented that N1 was connected to N2 and N2 connected to N1, now
edge E1 represents only that N1 is connected to N2, not the reciprocal.
All the concepts covered previously hold, with the obvious complication
that one must consider the direction of the edge when determining if
two graphs are equal or isometric and what walks may be present. For
example, consider the graphs in Figure 1-12.
Figure 1-12 Graph examples to demonstrate equality and isomorphism with a
directed graph
1-12A and 1-12B are not equal, but 1-12B is isometric because the
edge is in a different direction, but the basic structure is two nodes
connected by a directed edge.
1-12A and 1-12D are also not equal because the nodes are different,
but they are isometric because structurally they are the same. 1-12C
and 1-12D are exactly alike so they are equal.
When specifying a directed graph, you still can use the same set
notation, except that you need to denote an ordering to the nodes. So,
Figure 1-12A could be expressed as
Nodes: {N1,N2}; Directed Edges: {E1:{N1,N2}}
You can simulate the bidirectional qualities of a non-directed graph
by always having two edges between each node:
Nodes: {N1,N2}; Directed Edges: {E1:{N1,N2}, E2:{N2,N1}}

Cyclic and Acyclic Graphs

With directed graphs comes a very important concept that will play a
major part in of all our uses of graphs in practice: cycles. A graph cycle
refers to a directional graph having a walk from a given node that can
pass through the same node twice. It is similar to the concept of a Euler
Walk, but in this case you can only traverse the graph based on the
direction of the edges.
For examples, the simplest cyclical graph is a single node with a
relationship to the same node, and the next simplest is two nodes and
two edges going from and to each edge, as in Figure 1-13.

Figure 1-13 Cyclic graph examples

This concept of cyclical graphs is important for a couple of reasons.
First, let’s consider the programming concerns. Some algorithms will
work great on acyclic graphs but will not work on cyclic graphs. The
biggest issue is in processing. Consider the two graphs in Figure 1-14.

Figure 1-14 Graph examples to demonstrate processing acyclic and cyclic directed
graph

In Figure 1-14A, an acyclic graph, you can walk the graph from N1-
>N2->N3->N4 directly using a simple algorithm of going node to node,
touching all the nodes with no problem. But in Figure 1-14B, the
algorithm of going from node to node is made difficult by N1->N2->N3-
>N1, because what to do next? Cycle through the nodes again? Or stop
processing? All the results from starting at N1 would be repeated, but
what does this mean for the graph that you are modeling? You can
remember this mentally when manually tracing through, but the
programming gets more complex if you look at millions or billions of
nodes (the programming is not impossible, just more complicated).
This ability to be able to find a simple connection/walk from two
nodes in a graph is referred to as transitive closure. Once you have
hold of this power, you can do all forms of interesting things with
graphs, such as determining if you are connected to Kevin Bacon and
what is the shortest path through the people you are connected to that
you will need to bug to get tickets to see The Bacon Brothers in concert
when they come to your town.
In a more database design-oriented concern, consider what can be
modeled with an acyclic graph versus a cyclic one. More will be covered
in Chapter 2, but if you are modeling containership, like a bill of
materials (a data structure used in packaging/assembling items, where
products that are a part of other products are modeled using a graph), a
cycle in the graph could give you odd results. Consider the graph in
Figure 1-15.

Figure 1-15 Illogically modelled bill of materials

If the tire and wheel assembly contains a wheel assembly, and it in

turn contains lug nuts, and then the lug nuts contain a tire and wheel
assembly… you can see the inherent problem here. If you are modeling
something like a social network, cycles not only make sense, but you
can find important information from them (starting with a simple
reciprocal relationship showing that two people are connected.) In
Chapter 2, I will be discussing some of the different constructs you can
model using graph structures.
Acyclic graphs such as this are generally referred to as a class of
data structures known as a hierarchy. In the case of the bill of materials
structure, it is known as a polyhierarchy. A node in a polyhierarchy
may be the “to” partner in more than one edge, but the graph must be
acyclic. In this manner, one can think of the lug nut pack as a separate
item or as a part of the wheel (and in the real world, the lug nut would
be its own individual part!) but a lug nut pack cannot have the wheel or
wheel assembly as part of its part list for obvious reasons.

Summary
In this chapter, the goal was to introduce some of the core concepts that
are used when discussing graph topics. Many of these topics may show
up all over the book, but also some may not. The goal of this chapter
was to briefly introduce concepts that will help you to envision what a
graph is and how a graph might be used as you start to solve complex
problems with graphs.
© The Author(s), under exclusive license to APress Media, LLC, part of Springer
Nature 2023
L. Davidson, Practical Graph Structures in SQL Server and Azure SQL
https://doi.org/10.1007/978-1-4842-9459-8_2

2. Data Structures and Algorithms

Louis Davidson1
(1) Cleveland, TN, USA

In this chapter, I will introduce the common graph configurations you

can create using objects in SQL Server. I will start by defining the basics
of how almost every graph structure is stored in a relational (or really,
any) database. Creating the tables to hold the graph structures is quite
straightforward; it is the processing of the data where things start to
get complicated.
For each of the data structure configurations I will cover, I will
include a high-level explanation of the algorithms you will use to
process them. This will leave later chapters to simply build the code to
process the data in the data structures.

Basic Implementation
As discussed in the previous chapter, the basic building blocks of a
graph are nodes and edges. A node is basically the same thing as any
relational database table representing some specific concept. An edge
represents a link between two rows in these tables, much like a typical
many-to-many resolution table does in a relational database.
So, say you have the graph shown in Figure 2-1.
Figure 2-1 Simple graph
You need a table to hold the N1 and N2 nodes. These nodes could be
of the same type or different types. For example, they could be one
person being the friend or family member of the other, or a person
being a fan of a certain football team. Let’s assume for this example that
they are the same type (and in the future, if I want them to be two
different types of objects, I will label the nodes as such).
For my examples, I will use data that would be at home in many
relational tables for most examples, simply because that is how you will
typically think of the data. In the following two chapters, I will establish
how SQL Server implements graph structures, but for now, just take the
data structures to be basically as you have built in SQL Server tables
before. To implement the structure in Figure 2-1, say you have the
following rows in a table to represent the two nodes:

Node
------
N1
N2

Now you need a data structure that represents the edge, like this:

FromNode ToNode
-------- -------
N1 N2

A common term for this data structure is an adjacency list. The

goal is to store a list of nodes adjacent to each other in the graph.
Except for one very specialized (and quite common) graph data
structure (a tree, which I will define later in the chapter), this is the way
to implement a graph in a database. Even Microsoft SQL Server’s graph
objects are implemented this way internally. It is common to use the
term neighbor or parent/child to describe the relationship between
nodes. Parent and child are very common for acyclic relationships, and
neighbor is for cases where you are recording that two nodes are next
to one another and the relationship allows cycles. The
child/neighbor node in a relationship is the one that is represented in
the ToNode column.
 In practice, beyond the key values, you will always have additional
columns in your node tables, and usually in your edge tables as well.
Using the edge data structures’ from and to columns, plus other
columns, you can create many different shapes of graphs by applying
one or more unique indexes on different columns, as well as using other
methods to limit the types of data that can be placed in a column. This
is what I will introduce in the rest of this chapter.
I will discuss two major types of graph configurations, acyclic and
cyclic. From Chapter 1, it is hopefully clear that the primary
differentiator between them is that one allows cycles in the edges and
the other doesn’t. Of course, the other differentiator is the type of
situations where these data structures are useful.
An acyclic graph is often useful to define something very structured,
whereas a cyclic graph is useful for more organic scenarios. This will
become clearer in each of the major sections.

Acyclic Graphs
The easiest graphs to work with in a relational database are acyclic. The
reason comes down to the method used to process graphs in a
relational setting, the breadth-first algorithm (or relational
recursion). This algorithm was created for relational processing,
because the typical recursion used to process these data structures did
not fit well with the set-based nature of a relational database.
For example, consider the graph in Figure 2-2.
Figure 2-2 Sample graph structure
Processing this using a typical recursive manner, you choose your
starting point as N1 and then see if this node has one unprocessed
child. It does, so fetch N11. See if N11 has unprocessed children. Yes,
N111. N111 has no unprocessed child nodes, so whatever you are doing
with the data of the node, you add that to an output data structure.
Then step back up to N11 and get the next child node. And keep going.
This is referred to as a depth-first algorithm.
Common operations are counting nodes, summing sales from that
node, and so on. For your example, let’s just say you are counting child
nodes. So, you recurse back to N11 and add 1 to the child count. Then
you check for more child nodes, and you have more. Over and over. You
stop when every node has been processed in the subgraph that started
with your starting point.
This works great for certain kinds of programming languages but
terrible for relational ones where set-based processing is the clearly
desired method of programming. It works with sets of data, so that is
the kind of processing that has been devised for working with graphs in
the manner that relations engines work.
 For a breadth-first algorithm, instead of digging down in the
structure, you take a starting point and then get all of the children of
that node. Then the children of those nodes, all at once. Taking that
same diagram, let’s break this down into a series of three queries on the
data, as seen in Figure 2-3.

Figure 2-3 Sample graph indicating the different levels that will be fetched in a
breadth-first query

You query for the starting point. In this case, it’s one node, but it
could be any number of nodes (in fact, that is the basis of some of the
code in this book to do things like starting at every node
simultaneously!). Your breadth-first algorithm is to query:

SELECT GraphId
FROM GraphObject
WHERE GraphId = @startingPoint --starting point =
N1

The next step is to take that set of data and query:

SELECT GraphId
FROM GraphObject
WHERE GraphId in (GraphId values from previous
query)
From the diagram, this gives you a set with N11, N12, N13. The next
query does the same join, but the GraphId from the previous query is
now these three nodes. You can sum/count/etc. during each loop
through the data. There is more to it, clearly, which will become clearer
when I implement the non-pseudo-code, but this is the gist of the
algorithm.
This process is pretty easy for an acyclic graph, but you can
probably already start to see the difficulties when working with cyclic
graph structures, in that if you have the graph in Figure 2-4, it will loop
eternally.

Figure 2-4 Sample graph with a cycle

Many operations stop making sense because you have an eternal

loop when processing this with a naïve nested loop algorithm.
One thing to note: If you have been taught repeatedly that relational
processes should avoid iterative code, this may shock you a little.
Practically all graph processing is iterative. Any code you write, and any
code that Microsoft uses to implement its graph structures, is iterative.
The trick will be to make sure the amount you iterate is the least
possible and is as efficient as possible. There are some alternative
methods of processing when dealing with tree algorithms, one of which
will be covered in Chapter 6.

Trees
By far the most common graph that has been implemented in relational
databases for many years is a tree. A tree is a structure that requires
that every node have either zero or one parent, and no more. Consider a
real tree (or in the case of Figure 2-5, a glorious reproduction of a tree
from Disney’s Animal Kingdom theme park).

Figure 2-5 A not-exactly-live tree as an analogy for a tree structure

It has one trunk that goes into the ground. Either direction out
(down to the roots or up to the branches), you can see the analogy. Any
branch can be from the trunk or another branch, but it can only be one
of these. Branches don’t grow together and reform as one. (At least not
typically, and this isn’t botany class!) Nodes that do not have any child
nodes are referred to as leaf nodes, much like the leaves on the
branches stand alone.
My breadth-first example structure was a tree, reincluded as Figure
2-6.
Figure 2-6 Example tree repeated
To represent this in an adjacency list structure, you have rows like

From To
———- ———-
N1 N11
N11 N111
N11 N112
N11 N113
N1 N12

And so on. In order to make sure that the tree is always a tree, you
need to protect one main condition: unique to values. Since a child row
can only have one parent in a tree, having a uniqueness constraint on
that column of the adjacency list ensures it is a tree.
The other thing you typically need to do is include a constraint of
some sort to make sure that the from value does not equal the to
value. This is the only cycle that the uniqueness constraint will not stop
(though a duplicated to and from value basically makes the row a root
and a leaf and would likely be discovered quickly…but one of my mottos
is that bad data doesn’t happen if you don’t let it occur at all).
 While all tree structures require a single root, a table structure such
as this could contain multiple tree structures. In some cases, a row with
NULL, N1 could be included in the structure as the starting point
when you create the tree. You can make sure there is only one using a
unique index, which only allows one NULL value. (SQL Server treats a
NULL value as distinct in indexes, unlike in comparisons, so that would
make sure that you had only one root node.). You could allow greater
than one root node by using a filtered UNIQUE index that ignores NULL
values. If you want to make sure the NULL row is never deleted, a
trigger object can be used, which is especially useful if you have users
that can delete rows in an ad-hoc manner.
If you need to model multiple tree structures, it is possible to just
create multiple edge objects, each with a distinct purpose. For example,
consider a company reporting structure. There are multiple projects
going on where a person is in the project management hierarchy, and
typically there is a hierarchy for dealing with HR type things. So, you
could create

ManagementEdge (FromEmployee, ToEmployee)

And you could also create the same table again for every project.

Project1 (FromEmployee, ToEmployee)

Project2 (FromEmployee, ToEmployee)

Alternatively, you could model this as one structure that allows for
many trees to coincide in the same structure.

ReportingHierarchy (FromEmployee, ToEmployee,

HierarchyName)

All the indexes discussed for the general tree structures would still
make sense, but you would include the HierarchyName in the object
because the uniqueness stands only for one project if an employee can
be on multiple projects.
It might just make sense to have the ManagementEdge as
modeled, but then have the project hierarchy be in its own
 Another Random Document on
Scribd Without Any Related Topics
Bandoulière.

Bartizan.

Bombs.
 Blocks and Tackles
Whip. Whip upon Whip.
Gun tackle.
Luff. Screw.
Runner.
Burton.

Bomb proof.
Back-plate.

Braquemart.
PLATE 4.
 Castle.
1, moat; 2 drawbridge; 3, wicket; 4, sally-port; 5,
portcullis; 6, outer walls; 7, parapet; 8, rampart; 9,
loop-holes; 10, escutcheon; 11, bulwark; 12, sentinel;
13, magazine; 14, a cell; 15, donjon or keep; 16,
barracks; 17, barbacan; 18, watchman; 19, turret; 20,
chapel; 21, belfry; 22, state court; 23, merlons; 24,
embrasures.
Casemate.

Créneaux.
Caligae.

Colors.
Carbine, 17th century.

Diameter.

Coat of Mail.

Cheval de frise.
Cnémides.

Clunaculum.
 Drum.

CASSE-TÊTE.

Cimeterre.
Decoration.

Dart.
 Drawbridge.

Dangerous Space.
A, B, E, F, Trajectories.
(Laidley)
Dagger.

Donjon.
Espingole.

Epaulette.

Embrasures.
Daggers.

Ecu.
Echaugette.

Device.
Dagues.
PLATE 5.
 Catapult.

Canteen.

Chapeau Bras.
Coat of Mail.

Cartridge-box.

Cartridge.
Chain shot.

Cuirass.

Carreau.
 Cutlass.

Castellated.

Candjiar turc.
Casque.

Colletin.

Canister.
 Caltrop.

Head-piece.

Crow’s Foot.