I've never seen a model done with the relationships in the presentation layer shortcuts so I can't I don't understand why you have done that. I can't mentally picture your model in other ways either. The design of the FM model should follow Kimball's 4 rules. 1. Select the business process. 2. Declare the grain. 3. Identify the dimensions. 4. Identify the facts. You mention other things which confuse me too, such as the SQL examples, which are way off what should be expected.
The data aka query layer exists for two purposes. One is to store the metadata of the tables of the data sources. The second is to store the query plan in the form of aliases and relationships. This does not need to be in the query layer and can be modelled in the business layer.
If I remember correctly, the tradeoff between having the query plan in the query layer versus the business layer is that the latter buys control over table identification in the SQL at the price of more frequent metadata callbacks.
If you have the plan in the business layer you also need to have the relationships within a dimension (the Kimball relational thing not the thing with hierarchies and levels, which is a concept built on top of the relational thing ) planned so that ambiguity is eliminated. For role-playing you would have a model query subject pointing to a data source query subject representing the table which role-plays within dimensions for each dimension. For example if you have country table and country is used in your employee and other dimensions you would have a mqs in the employee dimension which would point to the country table and a mqs for any other dimension and a mqs for a third dimension which needs country.
If your ETL has created dimension tables the data would be in all the dimensions that it belongs to so the role-playing is built in.
You then model the determinants on the model query subjects.
The model should be, thus, able to deal with multi-fact queries without any action by a report author. The query in the report can be and should be formed by dragging the necessary query items into the report. No action to manually create a query should be necessary. The Cognos query engine should be able to coalesce the fact streams. Ordinary users' training should be fairly simple and it should not be necessary to worry about not following the rules as not following the rules should either produce a report which does not run or is not possible. The objects in a FM package should be just like bricks to them-- they throw this and that and a fact in and they get a report.
they are expected to create multiple queries -- 1 for each namespace -- and deliberately join those queries together in a way that suits their question.
I'm guessing the query creation and joining are done in reporting? Why is this seen as necessary.
Are your presentation layer objects shortcuts? If you have multiple star schema groupings and someone pulls a query item from Dimension A in ssg 1 and it is conformed to the fact table of ssg 2 then, since both shortcuts point to the same target, there should not be a problem generating a valid query.