Neo4j Basic Terminology

1. Node

  • Definition: A data entity in your graph — like a row in RDBMS, but more flexible.

  • Represents: A person, place, product, project, application, etc.


  • Example:

    (User {name: "Alice"})

    Here, the node is User with a name property.

2. Relationship

  • Definition: A connection between two nodes.

  • Direction: Always has a start node and an end node (can be one-way or effectively two-way if you create two relationships).

  • Represents: How entities are connected — e.g., WORKS_ON, FRIENDS_WITH, OWNS.

  • Example:

    (Alice)-[:WORKS_ON]->(ProjectX)

    Meaning: Alice works on ProjectX.

3. Properties

  • Definition: Key-value pairs that store information inside a node or relationship.

  • Purpose: Add details to your entities or their connections.

  • Example:

    (User {name: "Alice", role: "Developer"})
(Alice)-[:WORKS_ON {since: 2023}]->(ProjectX)

    • Node property: name, role

    • Relationship property: since

4. Labels

  • Definition: Tags assigned to nodes to categorize them.

  • Purpose: Helps organize nodes and speed up queries.

  • Example:

    (:User {name: "Alice"})
(:Project {name: "Apollo"})

    • Label User means this node represents a user.

    • Label Project means this node represents a project.

5. Relationship Types

  • Definition: Names that define the kind of connection between nodes.

  • Purpose: Makes queries clear and precise.

  • Example:

    (Alice)-[:WORKS_ON]->(ProjectX)
(Alice)-[:HAS_ACCESS_TO]->(ApplicationY)

    • WORKS_ON and HAS_ACCESS_TO are relationship types.

📌 Putting It All Together (Example use case)

(:User {name: "Alice", role: "Developer"})
-[:WORKS_ON {since: 2023}]->
(:Project {name: "Apollo"})
-[:HAS_ACCESS_TO]->
(:Application {name: "TimeTracker"})

  • Nodes: Alice, Apollo, TimeTracker

  • Labels: User, Project, Application

  • Relationships: WORKS_ON, HAS_ACCESS_TO

  • Properties: name, role, since

1. Shift Your Thinking

In relational databases (RDBMS), you think in tables and joins.
In graphs, you think in entities (nodes) and connections (relationships).

Instead of asking:

“Which tables should I create, and how will I join them?”

You ask:

“What are my real-world things (nodes), and how are they related (relationships)?”

2. The Core Building Blocks

  1. Identify Entities → Nodes

    • People, products, projects, applications, locations, etc.

  2. Identify Relationships

    • How entities are connected: WORKS_ON, OWNS, HAS_ACCESS_TO, FRIENDS_WITH.

  3. Add Properties

    • Attributes of nodes (e.g., name, role, email).

    • Attributes of relationships (e.g., since, permission_level).

3. Design Steps

Step 1: Understand the Domain

  • Gather your business requirements.

  • Write down nouns (likely nodes) and verbs (likely relationships).

Example from your use case:

  • Nouns (nodes): User, Project, Application

  • Verbs (relationships): WORKS_ON, HAS_ACCESS_TO

Step 2: Define Labels and Relationship Types

  • Labels group similar nodes (e.g., User, Project).

  • Relationship Types define connection meaning (e.g., WORKS_ON, HAS_ACCESS_TO).

Step 3: Add Properties Where They Matter

  • Node Properties → Details about the entity.

  • Relationship Properties → Details about the connection (date assigned, role, access level).

Step 4: Avoid Over-Modeling

  • Don’t turn every detail into a node — only make a node if it could connect to something else or be searched independently.

  • Keep simple attributes as properties.

Example:
✅ User {name: "Alice", role: "Developer"} → Properties
❌ Making Role a separate node unless you need relationships between roles.

Option 1 – Role as a property on the User node ✅

Use this if roles are just attributes of the user and you don’t need to connect roles to other entities.

(:User {name: "Alice", role: "Developer"})

  • Simple and lightweight.

  • Good when roles are only used for filtering (e.g., WHERE role = "Developer").

  • No extra complexity.

Option 2 – Role as a separate node ❌ (only if unnecessary)

Make it a node only if you need to store more information about the role or connect it to other things.

(:User {name: "Alice"})
-[:HAS_ROLE]->
(:Role {name: "Developer"})

You’d do this only if:

  • Roles have their own properties (e.g., description, permissions, hierarchy).

  • You need to query relationships between roles (e.g., “Developer” inherits from “Engineer”).

  • You want to link many users to the same role node to avoid duplication.

Step 5: Think About Queries Early

Design the model so common queries are fast:

  • “Which projects can this user access?”

  • “Who has access to this application?”

  • “What applications are linked to Project X?”

4. Example: Your Use Case in Graph Thinking

(:User {name: "Alice", role: "Developer"})
-[:WORKS_ON {since: 2023}]->
(:Project {name: "Apollo"})
-[:HAS_ACCESS_TO {level: "read"}]->
(:Application {name: "TimeTracker"})

  • Nodes: User, Project, Application

  • Labels: User, Project, Application

  • Relationships: WORKS_ON, HAS_ACCESS_TO

  • Properties:

    • Node: name, role

    • Relationship: since, level

Comments

Post a Comment