Each node in Neo4j has a set of unique labels, properties and can have any number of incoming and outgoing relationships (or none).

In order to present the contents of a node graph as a SQL database, the cmdlet models node labels as tables and relationships as read-only views.

Node Labels

Node labels are Neo4j's primary method for categorizing nodes, so they have been adapted into SQL views. Each node label is exposed as an individual table.

For example, the following query displays all nodes that contain a "Product" label:

SELECT * FROM Product

Note that, because nodes can have multiple labels, certain nodes appear in several label tables.

Insert

Nodes can be inserted to using standard SQL syntax. For example, the following query adds a new node with a "Product" label:

Note: In Neo4j, INSERTing a null value for an attribute is equivalent to not setting it at all.

INSERT INTO Product (Name) VALUES ('Television')

Update

Nodes can be updated with arbitrary filters. For example, the following query sets a new price for nodes labelled "Product" with a given name:

UPDATE Product SET Price=179.99 WHERE Name='Television'

Note: In Neo4j, a null value implies the non-existence of an attribute: if all nodes with a given label have null for an attribute, the attribute does not exist. As such, certain UPDATEs could alter the data model by erasing an attribute entirely.

Delete

Nodes can be deleted with arbitrary filters. For example, the following query deletes all nodes labelled "Product" with a given name:

DELETE FROM Product WHERE Name='Television'

Note: Neo4j does not allow deleting nodes attached to any edge. A delete can be forced in this instance by setting the DetachDelete property to true. This will remove any attachments the node has, which may impact the records present in relationship views.

Relationships

The cmdlet models each novel combination of the following as a view.

• Source node label
• Destination node label
• Relationship type (name)

The view associated with that combination takes the form of SourceName_RelationshipType_DestinationName.

For example, if there is at least one node with the label "Product" which has the relationship "Part_Of" with a node with the label "Category", you can query this relationship as follows:

SELECT * FROM Product_Part__Of_Category

Since the source and destination labels of the relationship denote its direction, bidirectional relationships are modeled as two views: A_RelationshipType_B and B_RelationshipType_A, where A and B represent unique node labels.

Note that, because nodes can have multiple relationships, certain nodes appear in several relationship views.

Properties

Properties are modeled as columns.

Node Properties

In nodes label views, properties are inherited from the nodes containing the node label, keeping their original names.

Relationship Properties

In relationship views, properties are inherited from the all instances of the source node, the destination node, and the relationship itself.

The following columns are exposed:

• A source_<PropertyName> column for each property in the instances of the source node.
• A destination_<PropertyName> column for each property in the instances of the destination node.
• A relationship_<PropertyName> column for each property in the instances of the relationship.