user
entity might appear in different facts describing things the user has done:
logins
fact table describing application login eventsvisits
fact table describing website visits eventscustomer
shared dimension details information per customer.orders
fact entity has per-order data, and has a relation to the ordering customer.lineitem
fact entity has the line items for each order and has a direct relationship to the ordering customer.lineitem
and customer
:
lineitem
and customer
on lineitem.customer_id = customer.id
lineitem
to orders
on order_id
and them join orders to customers on orders.customer_id = customer.id
lineitem
and customer
directly when looking at line items of a customer.lineitem
entity that relates to both customer
and supplier
.customer
and supplier
have a shared dimension called nation
.lineitem
would not know which nation
to prefer when counting revenue by nation.To resolve this situation:lineitem
that equals to the preferred nation (for example that equals to customer.c_nationkey
).nation
entity.users
entity
that takes data from the logins
fact, so it can be used later on when joining users with visits
.
logins
and visits
users
logins
has a GROUP BY (users.id)
qualifier that tells it to be calculated per user.Since user is a shared dimension between logins
and visits
, the result can be applied to a metric in visits.Note that if there are multiple shared dimensions, can connect through more than one.users
shared entity named logins_last_month
defined as
count
metric) in the last month (assuming a time
attribute), at the granularity
of a user (since the calculated attribute is part of the user entity).
See also how metrics behave in calculated attributes.
visits
called count_visits_of_recently_logged_in_users
defined as