Degree Centrality

Introduction

The Degree Centrality algorithm can be used to find popular nodes within a graph. The degree centrality measures the number of incoming or outgoing (or both) relationships from a node, which can be defined by the orientation of a relationship projection. If a projection contains directed relationships, only outgoing relationships of a node are counted (the out-degree). For more information on how relationship orientations influence the algorithm result, see the setting an orientation section.

It can be applied to either weighted or unweighted graphs. In the weighted case the algorithm computes the sum of all positive weights of adjacent relationships of a node, for each node in the graph. Non-positive weights are ignored.

It can be applied to heterogenous graphs, however the algorithm will not calculate degree centrality per relationship type. Instead it will treat the graph as homogenous, as indicated by the algorithm traits.

For more information on this algorithm, see:

Use-cases

The Degree Centrality algorithm has been shown to be useful in many different applications. For example:

  • Degree centrality is an important component of any attempt to determine the most important people in a social network. For example, in BrandWatch’s most influential men and women on Twitter 2017 the top 5 people in each category have over 40m followers each, which is a lot higher than the average degree.

  • Weighted degree centrality has been used to help separate fraudsters from legitimate users of an online auction. The weighted centrality for fraudsters is significantly higher because they tend to collude with each other to artificially increase the price of items. Read more in Two Step graph-based semi-supervised Learning for Online Auction Fraud Detection

Syntax

This section covers the syntax used to execute the Degree Centrality algorithm.

Run Degree Centrality.
CALL Neo4j_Graph_Analytics.graph.degree(
  'CPU_X64_XS',                    (1)
  {
    ['defaultTablePrefix': '...',] (2)
    'project': {...},              (3)
    'compute': {...},              (4)
    'write':   {...}               (5)
  }
);
1 Compute pool selector.
2 Optional prefix for table references.
3 Project config.
4 Compute config.
5 Write config.
Table 1. Parameters
Name Type Default Optional Description

computePoolSelector

String

n/a

no

The selector for the compute pool on which to run the Degree Centrality job.

configuration

Map

{}

no

Configuration for graph project, algorithm compute and result write back.

The configuration map consists of the following three entries.

For more details on below Project configuration, refer to the Project documentation.
Table 2. Project configuration
Name Type

nodeTables

List of node tables.

relationshipTables

Map of relationship types to relationship tables.
Table 3. Compute configuration
Name Type Default Optional Description

mutateProperty

String

'degree'

yes

The node property that will be written back to the Snowflake database.

relationshipWeightProperty

String

null

yes

Name of the relationship property to use as weights. If unspecified, the algorithm runs unweighted.

orientation

String

'NATURAL'

yes

The orientation of the relationships. Can be 'NATURAL', 'REVERSE', or 'UNDIRECTED'.
For more details on below Write configuration, refer to the Write documentation.
Table 4. Write configuration
Name Type Default Optional Description

nodeProperty

String

'degree'

yes

The node property that will be written back to the Snowflake database.

Examples

In this section we will show examples of running the Degree Centrality algorithm on a concrete graph. The intention is to illustrate what the results look like and to provide a guide in how to make use of the algorithm in a real setting. We will do this on a small social network graph of a handful nodes connected in a particular pattern. The example graph looks like this:

Visualization of the example graph
The following SQL statement will create the node and relationship data for our example graph:
CREATE OR REPLACE TABLE EXAMPLE_DB.DATA_SCHEMA.USERS (NODEID STRING);
INSERT INTO EXAMPLE_DB.DATA_SCHEMA.USERS VALUES
  ('Alice'),
  ('Bridget'),
  ('Charles'),
  ('Doug'),
  ('Mark'),
  ('Michael');

CREATE OR REPLACE TABLE EXAMPLE_DB.DATA_SCHEMA.FOLLOWS (SOURCENODEID STRING, TARGETNODEID STRING, SCORE DOUBLE);
INSERT INTO EXAMPLE_DB.DATA_SCHEMA.FOLLOWS VALUES
  ('Alice', 'Doug', 1.0),
  ('Alice', 'Bridget', -2.0),
  ('Alice', 'Charles', 5.0),
  ('Mark', 'Doug', 1.5),
  ('Mark', 'Michael', 4.5),
  ('Bridget', 'Doug', 1.5),
  ('Charles', 'Doug', 2.0),
  ('Michael', 'Doug', 1.5);

With the node and relationship tables in Snowflake we can now project it as part of an algorithm job. In the following examples we will demonstrate using the Degree Centrality algorithm on this graph.

To run the queries in this section, there is a required setup of grants for the application, your consumer role and your environment. Please see the Getting started page for more on this.

We also assume that the application name is the default Neo4j_Graph_Analytics. If you chose a different app name during installation, please replace it with that.

Run job

Running a Degree Centrality job involves the three steps: Project, Compute and Write.

The following will run a Degree Centrality job:
CALL Neo4j_Graph_Analytics.graph.degree('CPU_X64_XS', {
    'defaultTablePrefix': 'EXAMPLE_DB.DATA_SCHEMA',
    'project': {
        'nodeTables': [ 'USERS' ],
        'relationshipTables': {
            'FOLLOWS': {
                'sourceTable': 'USERS',
                'targetTable': 'USERS'
            }
        }
    },
    'compute': {
        'relationshipWeightProperty': 'SCORE'
    },
    'write': [{
        'nodeLabel': 'USERS',
        'outputTable': 'USERS_CENTRALITY'
    }]
});
Table 5. Results
JOB_ID JOB_START JOB_END JOB_RESULT

job_fbf4a243f3ed46c2895f5d1673911a4b

2025-04-29 11:41:43.604000

2025-04-29 11:41:50.077000

 
 {
   "degree_1": {
     "centralityDistribution": {
       "max": 6.000030517578124,
       "mean": 2.8333396911621094,
       "min": 0,
       "p50": 1.5,
       "p75": 6.000022888183594,
       "p90": 6.000022888183594,
       "p95": 6.000022888183594,
       "p99": 6.000022888183594,
       "p999": 6.000022888183594
     },
     "computeMillis": 14,
     "configuration": {
       "concurrency": 2,
       "jobId": "c70c50fd-6cb1-4c43-b92a-1ce283073aac",
       "logProgress": true,
       "mutateProperty": "degree",
       "nodeLabels": [
         "*"
       ],
       "orientation": "NATURAL",
       "relationshipTypes": [
         "*"
       ],
       "relationshipWeightProperty": "SCORE",
       "sudo": false
     },
     "mutateMillis": 2,
     "nodePropertiesWritten": 6,
     "postProcessingMillis": 75,
     "preProcessingMillis": 10
   },
   "project_1": {
     "graphName": "snowgraph",
     "nodeCount": 6,
     "nodeMillis": 334,
     "relationshipCount": 8,
     "relationshipMillis": 633,
     "totalMillis": 967
   },
   "write_node_property_1": {
     "exportMillis": 2325,
     "nodeLabel": "USERS",
     "nodeProperty": "degree",
     "outputTable": "EXAMPLE_DB.DATA_SCHEMA.USERS_CENTRALITY",
     "propertiesExported": 6
   }
 }

The returned result contains information about the job execution and result distribution. Additionally, the centrality score for each of the seven nodes has been written back to the Snowflake database. We can query it like so:

SELECT * FROM EXAMPLE_DB.DATA_SCHEMA.USERS_CENTRALITY;

Which shows the computation results as stored in the database:

Table 6. Results
NODEID SCORE

Alice

6.0

Bridget

1.5

Charles

2.0

Doug

0.0

Mark

6.0

Michael

1.5

Here we can see that the Alice and Mark nodes have the highest degree centrality, which means that the total weight of the outgoing relationships from these nodes is the highest.

Setting an orientation

By default, node centrality uses the NATURAL orientation to compute degrees. For some use-cases it makes sense to analyze a different orientation, for example, if we want to find out how many users follow another user. In order to change the orientation, we can use the orientation configuration key. There are three supported values:

  • NATURAL (default) corresponds to computing the out-degree of each node.

  • REVERSE corresponds to computing the in-degree of each node.

  • UNDIRECTED computes and sums both the out-degree and in-degree of each node.

The following will run the algorithm with the reverse orientation:
CALL Neo4j_Graph_Analytics.graph.degree('CPU_X64_XS', {
    'defaultTablePrefix': 'EXAMPLE_DB.DATA_SCHEMA',
    'project': {
        'nodeTables': [ 'USERS' ],
        'relationshipTables': {
            'FOLLOWS': {
                'sourceTable': 'USERS',
                'targetTable': 'USERS'
            }
        }
    },
    'compute': {
        'orientation': 'REVERSE'
    },
    'write': [{
        'nodeLabel': 'USERS',
        'outputTable': 'USERS_CENTRALITY_REVERSE'
    }]
});
SELECT * FROM EXAMPLE_DB.DATA_SCHEMA.USERS_CENTRALITY_REVERSE;
Table 7. Results
NODEID SCORE

Alice

0.0

Bridget

1.0

Charles

1.0

Doug

5.0

Mark

0.0

Michael

1.0

Here we can see that the Doug node has the highest in-degree, which means that it is followed by five other users. The Alice node has the lowest in-degree, which means that it is not followed by any other user.