Thanks @Pavel_Duchovny ! I’ve already gone through the links you’ve provided above. And, I agree that the pattern provided in the first link is very simple and makes much sense.
So let me be more specific here, the goal is not to copy or migrate an existing star schema from a relational DB to NoSQL - MongoDB, instead to design a data model pattern in MongoDB that is as efficient as a star schema and which also enables to do “self-service” analytics kind of reporting.
Let’s assume, if we want to process and store the historical data for reporting like a periodic snapshot fact tables like weekly, monthly, quarterly and yearly with some “conformed” dimension tables around like - Date, Geography, Customer, Products etc. There could be several dimensional attributes related to each dimensions and their associated measures, which could make a document very long and bulky (w.r.t document size) and at the same time we also need to ensure the hierarchies are maintained within each dimension like for example:- Date (i.e. Day, Week, Month, Qtr, Year) and Geography (i.e. Region, Country, State, City, County).
Also, the user can try to analyze just the sales by customer and/or just the sales by product and time. But a single document would still fetch all the dimensional attributes of other dimensions everytime.
Considering all these, would you still recommend to have all the dimensions, associated hierarchies etc embedded - like in the first link you provided ? Or, would it make sense to have separate collections created at different granularity level like - one for weekly, one for monthly and one for quarterly etc. However, in this approach then how do we handle the reporting context - meaning - if a user wants to see or analyze only the “monthly” sales, how do we change the context during runtime that instead of weekly collection, select/use the “monthly” collection for reporting. This might require it to be handled programmatically though, it seems.
I guess for such situations instead of just a bucket pattern, what we may need could be a combination of computed and bucket (in separate collections for each period - week, month, qtr, year)?