About Relationships

In a Board Data model, Relationships are always hierarchical: a Relationship defines a many-to-1 relationship between 2 Entities. Those Entities are therefore referred to as the parent Entity and the child Entity. This is the reason why Relationships can also be called hierarchies or trees, in a typical Board scenario.

For example, the Entities "State" and "City" are clearly part of a parent-child relationship, as a city can only be in one state and a state usually includes multiple cities.

Entities and hierarchies provide views on Cubes at various levels of aggregation, as they are used as dimensions in the Cube structures. In a Sales Cube, for example, you may want to see Sales data by State or by City, which is obtained by dynamically changing the aggregation level of the Cube using the Drill down feature or by replacing Entities in the Axes area of the Layout editor.

Two Entities in a parent-child relationship are also often referred to as less-aggregate (child) or more-aggregate (parent) Entities: a view at the parent Entity level is the aggregation of data from the child Entity level.

Board supports multiple parallel hierarchies, which means that an Entity can have multiple rollup paths. For example, the Entity "Customer" could rollup into the Entities "City" and "State", and that can be referred to as the first branch of the hierarchy. However, the same Entity could independently rollup into the Entities "Salesman" and "Area Manager" - another parallel branch - and also into the Entity "Channel" - a third parallel branch.

The following illustration shows the "Customer" hierarchy described above, with its 3 parallel branches.

Creating all necessary hierarchies is one of the 3 key steps in building a multidimensional Data model in Board.

Hierarchies must provide a truthful representation of the business model or the organization you are modeling. A Relationship between 2 Entities should only be defined if there is an organizational rule or some kind of requirement that enforces it.

For example, for the "State" and "City" Entities, it appears quite obvious that a hierarchical relationship should be defined between the most-aggregate, the State Entity (parent), and the less-aggregate Entity, the City Entity (child).

Sometimes the scenario is not so obvious. If we consider for example the Entities "Customer" and "Salesman", the definition of the hierarchical relationship Customer→Salesman implies that a customer can only be related to a single salesman. If this is always true within an organization, then it makes sense to define a Customer→Salesman relationship, but if a salesman manages multiple customers, then those two Entities should remain unrelated.

To access the Relationships section of a Data model, access the designer space of the desired Data model and click on the Relationships tile or use the contextual navigation panel that appears when the mouse pointer hovers over the light blue icon in the upper left side of the page.

In the Relationships page, you can see all existing Entities in the Data model and their relationships with each other in a tree view: the first Entity at the top of the tree is the least-aggregate (child), while those nested and indented down along the tree are more-aggregate (parents).

You can also see each hierarchy in a graphical view, to better understand its structure: to do so, simply click on the graphical view icon beside each Relationship tree. For example, the graphical view of the Branch hierarchy shown above is the following:

You can perform different actions on one Relationship at a time, as described in the Creating a Relationship and Managing Relationships topics in this manual.