But could a fact become a dimension ever?

[2by4]

First, forgive my ignorance, but still very new at DM.

I have two fact tables "WEB_LOGIN" and "EMAIL_SENT". They are related to each other by, among others, a "SUBSCRIBER" dimension.
Each of the facts record individual events (each time they log in into the product website and each time we send them an email about that product).

If I want to see the relationship between the # of emails we send in a time period and the # of times they log in by time
period, does it make sense to create a banded dimension for # of logins as well?

Meaning, I'd like to create a report like this:

	0-5 Logins	6-10 logins	11-20 logins	21+ logins
Avg emails sent	12	17	22	21

As you can see the heading is banded information from one of the fact tables. Is this simply a drill-across capability of BI systems
or is this best approached with a new dimension for the # of logins bands?

[LAndrews]

Typically this type of query is satisfied using the drill across capability of your BI tools. Banding only works when you have fixed interval situations (or no time interval).

If you can define a fixed interval, then you probably would consider an aggregate fact table (with total logins, total_emails etc). You may add a banding dimension to this aggregate fact if it still makes sense..

[ngalemmo]

A measure can be calculated and stored as an attribute in a dimension table. But as far as tables go, fact tables are what they are and they don't change.

A common use case are customer attributes used in loyalty and marketing analysis. Categorizations, such as 'frequent shopper', brand affiliations and stuff like that are based on behavior (sales history) with the company.

[Sponsored content]