Both options mentioned by you above are absolutely valid and both of them have slightly different purposes. It basically all comes to a couple of things:
1. What are the volumes of your data?
2. You mentioned something above about granularity - so, what's your lowest granularity? If you have different granularity, it might happen that following approach 1 you would end up with duplicated rows and plenty of nulls and performing sum() or count() which require set analysis, distinctness, aggr() etc from the very beginning and it some occasions you might be adding some extra complexity to your model, which could be omitted.
3. Linking your data through link table - ask yourself a question what are the associations between your data subsets? It might happen that your only common dimension is for example time/date and/or maybe something else. Then is good to have your link table, with all dimensions used as filters in front end in it.
Btw - in situation when we were to build a report to gather data from different parts of the business where we had plenty of mutual dimension (and the same granularity in most of the occasions) we decided to have a big facts table and star schema. On the other occasion when we were asked to build a report gathering data that didn't have any similarities and different granularity - we decided to build a link table, where our key was only the time/date.
But at the end - it all depends on the business requirements of your report, so speak to your users and try to get an idea how the data is linked.
hope this help.
I always try to go for a single concatenated Fact table in the centre of a Star Schema.
- Unless the underlying facts are so different as to make concatenating silly.
- Have a look at this blog post Generic keys
p.s. If all your facts have similar granularity then you won't need to worry about Generic Keys.
See the attached file from page 15 to page 22.
It may help you.
I guess you already finished your datamodel. But should you be interested in some tools to help checking your datamodel while building it. I created a "Key check module" (a set of objects and a script subroutine) to check the links between tables. You can read a short post about the "Key Check Module" here.
Hope you find it useful.
Have fun Qlik'n, Koen