Appearance
Jump to Related Data
TIP
Make sure you first read the intro to no-code exploration steps
This powerful step can be used to effectively switch between different data models. Using the example from before, we added a "Jump to Transaction" step here.
After this step has been applied, we no longer see a list of Accounts. We instead now see Transactions (because that's what we chose to "jump" to).
It's critical to understand that these are not all Transactions. Before jumping to Transactions, we had done quite a bit of narrowing down to arrive at a subset of Accounts.
After the "Jump to related data" step, we now only see Transactions belonging to Accounts whose status is "active" and whose "Number of Users" is greater than 5.
The Jump to related data step always effectively retains previous filters. It shows data that's related to the previously seen data.
To further illustrate how this works (and how it isn't like a naive database join), let's look at this example:
- We filter down to a short list of Accounts
- We switch to the Transactions of those Accounts
- We switch to the Accounts of those Transactions
- We see 21 Accounts – the exact same ones that we initially filtered down to. If we add a Count step at the end, we'll see that the number is indeed the same.
Of course, in reality, there is no point in switching back-and-forth like this. But what might be useful is the following:
- We start from filtering down to those same Accounts
- We switch to looking at all of the Transactions those Accounts have made
- We filter down to only Transactions over 999 euros in value
- We switch "back" to looking at the Accounts of those Transactions
- Notice how the number of remaining Accounts is now lower than before
TIP
People who know SQL might be tempted to try and categorize this step as a certain type of database join. We recommend you don't do it, as that would be misleading and incorrect.
Unlike joins, this step type doesn't create duplicate rows. That is, when jumping from A to B and there are multiple A rows that correspond to the same B, you will only get one of each relevant B row.
If you really must, you could think of this as a deduplicated inner join.