aanpassingen

Databases/Neo4j/Graph Data Modeling Fundamentals.md

@@ -26,15 +26,15 @@ The Neo4j components that are used to define the graph data model are:
 
 Here are the steps to create a graph data model:
 
-1.  Understand the domain and define specific use cases (questions) for the application.
-2.  Develop the initial graph data model:
+1. Understand the domain and define specific use cases (questions) for the application.
+2. Develop the initial graph data model:
     a. Model the nodes (entities).
     b. Model the relationships between nodes.
-3.  Test the use cases against the initial data model.
-4.  Create the graph (instance model) with test data using Cypher.
-5.  Test the use cases, including performance against the graph.
-6.  Refactor (improve) the graph data model due to a change in the key use cases or for performance reasons.
-7.  Implement the refactoring on the graph and retest using Cypher.
+3. Test the use cases against the initial data model.
+4. Create the graph (instance model) with test data using Cypher.
+5. Test the use cases, including performance against the graph.
+6. Refactor (improve) the graph data model due to a change in the key use cases or for performance reasons.
+7. Implement the refactoring on the graph and retest using Cypher.
 
 Graph data modeling is an iterative process. Your initial graph data model is a starting point, but as you learn more about the use cases or if the use cases change, the initial graph data model will need to change. In addition, you may find that especially when the graph scales, you will need to modify the graph (refactor) to achieve the best performance for your key use cases.
 
@@ -67,7 +67,7 @@ When performing the graph data modeling process for an application, you will nee
 The data model describes the labels, relationships, and properties for the graph. It does not have specific data that will be created in the graph.
 
 Here is an example of a data model:
-![0e5c55b7a519831b5ba0393544641782.png](../../_resources/0e5c55b7a519831b5ba0393544641782.png)
+![0e5c55b7a519831b5ba0393544641782.png](../../images/0e5c55b7a519831b5ba0393544641782.png)
 
 There is nothing that uniquely identifies a node with a given label. A graph data model, however is important because it defines the names that will be used for labels, relationship types, and properties when the graph is created and used by the application.
 
@@ -141,11 +141,13 @@ The main risk about fanout is that it can lead to very dense nodes, or supernode
 
 ## Properties for relationships
 
-Properties for a relationship are used to enrich how two nodes are related. When you define a property for a relationship, it is because your use cases ask a specific question about how two nodes are related, not just that they are related.
+Properties for a relationship are used to enrich how two nodes are related.
+When you define a property for a relationship, it is because your use cases ask a specific question about how two nodes are related, not just that they are related.
 
 # Testing the Model
 
 You use the **use cases** to design the data model:
+
 - includes labels for nodes
 - relationship types and direction
 - properties for the nodes and relationships.
@@ -160,15 +162,18 @@ More data for testing is OK => test **scalability**
 The Cypher code used to test the use cases needs to be carefully reviewed for correctness.
 
 # Refactoring the Graph
+
 ## Refactoring
 
 changing the data model and the graph.
 three reasons why refactor:
+
 - The graph as modeled does not answer all of the use cases.
 - A new use case has come up that you must account for in your data model.
 - The Cypher for the use cases does not perform optimally, especially when the graph scales
 
 Steps (must) for refactoring:
+
 1. Design the new data model.
 2. Write Cypher code to transform the existing graph to implement the new data model.
 3. Retest all use cases, possibly with updated Cypher code.
@@ -180,6 +185,7 @@ Limit the number of labels to 4
 What is the primary reason to add labels to nodes is reduce the number of data accessed at runtime.
 
 ## Retesting After Refactoring
+
 - After refactoring the graph, revisit all queries for all use cases.
 - Rewrite any Cypher queries for use cases that are affected by the refactoring.
 
@@ -193,8 +199,9 @@ What is the primary reason to add labels to nodes is reduce the number of data a
 
 - avoid duplicating data in your graph
 - elilimnate duplication -> improve query performance
-	- In order to perform the query, all nodes must be retrieved to match a property.
-	- example refactoring list property to nodes
+  - In order to perform the query, all nodes must be retrieved to match a property.
+  - example refactoring list property to nodes
+
 ```
 MATCH (m:Movie)
 UNWIND m.languages AS language
@@ -211,7 +218,8 @@ SET m.languages = null
 ## Eliminating Complex Data in Nodes
 
 Storing complex data in the nodes like this may not be beneficial for a couple of reasons:
-- Duplicate data. 
+
+- Duplicate data.
 - Queries related to the information in the nodes require that all nodes be retrieved.
 
 # Using Specific Relationships
@@ -237,13 +245,13 @@ It has a **apoc.merge.relationship** procedure that allows you to **dynamically
 
 a relationship that connects more than two nodes. Mathematics allows this, with the concept of a hyperedge. Impossible in Neo4j.
 
+![69b4c46435ed52c1fe5be0ba6a074be5.png](../../images/69b4c46435ed52c1fe5be0ba6a074be5.png)
 
-![69b4c46435ed52c1fe5be0ba6a074be5.png](../../_resources/69b4c46435ed52c1fe5be0ba6a074be5.png)
 Email is new intermediate node
 
-![ae805ac0f184fdb6cf93d6b038af28a9.png](../../_resources/ae805ac0f184fdb6cf93d6b038af28a9.png)
+![ae805ac0f184fdb6cf93d6b038af28a9.png](../../images/ae805ac0f184fdb6cf93d6b038af28a9.png)
 
-- Intermediate nodes deduplicate information. 
+- Intermediate nodes deduplicate information.
 - Connect more than two nodes in a single context.
 - Share data in the graph.
 - Relate something to a relationship.