Hello team! I have a question on which logic is behind some data fields are not available in Analyzer. I have an Expense which can have multiple Approvers. (1:N) First, when I add an Approver to the grid, the metrics of the Expense are not available - until I add the PK to the Expense table. The other way around, when adding the Expense metric first, Approver is available. But Analyzer now displays: SORRY, WE CAN'T DISPLAY THIS INSIGHT. I didn't quite get it from the documentation...

Hello Hans, As stated under the detail of your dataset edge(relationship), this connection allows you to slice and filter facts from Approver datasets by attributes of Expanse datasets. Not the opposite way. Could you share some metric example with me, please? And how exactly are you adding the PK to the table, please? As a slicer?

This mechanism is there to protect you from slicing metric like “Total Expense” by Approver and double count expenses with multiple approvers. It helps users to navigate which attributes/metrics are usable in given context and eliminate options which have weak relation and its use could lead to misinterpretation of results or double counting issues. You may however overcome this by declaring edge in data model as many to many edge (double sided arrow). Simple rule is that attribute will be usable for breakdowns of metric if there is oriented path from them to the facts. Double-sided arrow will help. You can create double sided arrow by dragging relation from Approver to Expense in LDM modeler. See more in an article about many-to-many relations in the GD Platform documentation: https://help.gooddata.com/doc/enterprise/en/data-integration/data-modeling-in-gooddata/many-to-many-in-logical-data-models/

Hi Jakub, thanks for your reply. There can be multiple approvers per Expense. From your explanation, I understand that in case of a (1-M) relation, it removes the facts on the 1-side so that in case of a sum for instance it wouldn't multiply the occurrence in the M-side with that fact on the 1-side. I believe I will keep the current relation, as it prevents my users to make mistakes.

Hi Hans, yes, exactly - a standard 1-M relation (arrow) in the GoodData Logical Data Model represents a simple hierarchy where

A --> B

means: • for each

A

there can be zero or more Bs and each

B

has exactly one

A

• any fact/numerical value in

A

can not be effectively broken by any attribute in

B

because there can be many B-rows for the same A-row and there is no information how to distribute the single value among them • the other way around, it is allowed, since multiple values from

B

can be easily aggregated into a single value from

A

If you can have multiple approvers per expense and want to for example filter expenses by approver, it is an ideal candidate for the M-N relationship (make the arrow bi-directional). This will also allow slicing of facts in expenses by approvers and only in this case would show the same value from expense next to all its approvers.

Hi Michal, that's clear. Currently there are no requests to filter expenses by approver. To prevent mistake in an overview on company scale, I'll keep it 1-M for now, as this is keeps it simple: I will have to explain less, support less.