## Fundamental concepts in network data

In this section, you'll learn about entities, entity types, relationships and relationships.

### Entity types

An entity type is a description of a type of entity. Entity types say two things: Name — the name of this entity type, and is Node or not — a true/false value that says whether a given type of entity should be treated as a node or a group.

Entities that are treated as nodes are drawn onto the screen as circles. They have many more styling properties such as radius, stroke, fill, etc.

Group-type entities are treated simply as containers. They are drawn to the screen as labels that encompass their children entities. Group-type entities can be nested. Rhumbl automatically adds an “uber group“ entity type for you — think of this entity as the overarching umbrella entity. While not strictly required, it is often natural in most use cases to have some sort of overarching parent entity.

Pro tip When thinking about what entities to model in your data, first think about which entities you want drawn on the screen as nodes. Then think about natural ways to group them.

### Entities

Entities are things in your data that need to be modeled. An entity has required properties, styling properties and other custom-defined properties.

Entity properties
Node-type entities Group-type entities
id Required Required
name Required Required
type Required Required
short name Recommended Optional
r Optional
fill Optional
stroke Optional
strokeWidth Optional
Other custom attributes Optional Optional

The id, name and type of every entity is always required. Why is the attribute short name required? Because typically, you'll want to display something on the node itself, and it's recommended to have a short name that fits neatly within the node circle.

The following styling attributes of r, fill, stroke and strokeWidth describes the radius, inner fill, outer stroke color and outer stroke width of the node respectively. These styling attributes are automatically applied when you create a node, or when you choose a general color scheme. You can also set custom style attributes; jump to the Node styling section to learn more

### Relationship types

A relationship type is a description of a type of relationship. Relationship types say 3 things: Name — the name of the relationship, is Edge or not — a true/false value that says whether a relationship is drawn as an edge on the screen, and directionality — whether it's a directed or undirected relationship.

Edge-type relationships are drawn on the screen as lines between nodes. An edge describes the relationship between two nodes. You can have multiple relationships between two nodes, if they are of different relationship types.

There is one special, non-edge relationship type — the parent-type. Parent-type relationships describe how entities are grouped under group-type entities. You cannot delete the single parent-type or add more parent-types. By default, the single parent-type has a name of HAS_PARENT_OF, but you can rename it, e.g. to "sits under".

The concept of directionality is very important, especially for a directed relationship. The relationship always points from the source entity to the target entity; thus, the way you name your relationship is critical. For example, a teacher tutors a student — the relationship here is “tutors” — but the student does not tutor the teacher. By default, directed edges are drawn pointing from the source to the target entity, although you can flip how arrows point. For undirected edges, e.g. someone “is related to” to someone else, edges are drawn with a bi-directional arrow.

### Relationships

Relationships are connections between your entities. In the previous section, we talked about parent-type relationships — these are the connections that group your entities together, and edge-type relationships — the relationships that are drawn as edges on the screen between nodes.

Edges have styling attributes.

Pro tip What are the connections that need to be drawn on the screen? Those are your edge-type relationships. Always identify your nodes and edges first, before thinking about how to group them.