Using Dimension as a fact

Question

I have a scenario:
let me create that with simple Prod/Cus/Ord tables so that everyone can understand (instead of using my business terms).
Product table:
prod id
prod name
Staff table:
staff id
staff name
Customer Table:
cust no
customer name
staff id ---> This is the staff who created this customer or assisted this customer (before placing an order) (joined to staff table by staf id)
Order Fact table:
prod id --> Joined to Products table by prod id
cust no --> Joined to customer table by cust no
staff id --> Joined to staff table by staff id
ord no
ord date
qty
amount
I am joining staff id to customer (instead of going thorugh Order fact table) as a customer is created by one staff but actual order is created by another staff. So, my clients would need to who know created the customer and who created his orders.
My question is, is this a proper design? because with this design tools are not able to understand how to formulate a query. Cognos query studio just takes which ever path it likes (not sure if there is a way to change that) and BO creates a loop and looks for Contexts (our customers don't like context as these scenarios are plenty in our database)
another eg:-
there could be dates that is common in both Customer and Order fact tables:
customer created date,modified date and order created date, order modified date. analysts would need to know customer created date/order modified date etc..
Hope you understood my question..
Thanks,.

Answer 1

Firstly, you need to look at why your customers don't like contexts. They are one of the best parts of universe design. How else do they expect you to avoid chasm traps, with a separate universe for each fact table? Believe me, I've heard about some poor universe designers doing this because they didn't understand contexts!
However, what you have here sounds like a candidate for aliases.
This is because you have two different uses for the staff table:
1/ Staff create orders
2/ Staff create customers
So, create one alias of staff as a_cust_create_staff (the a_ to denote that it's an alias) and one as a_order_taker_staff
Join a_cust_create_staff to customer and join a_order_taker_staff to the order fact table.
You will now need to create two different objects for the staff to reflect their two different roles.
Same applies with your dates. Create aliases for each use of date - if you use just one date table you will only get rows back where the order is created and modified on the same date that a customer is created and modified!
If you only have one fact table then you don't need to use contexts - if none are defined it assumes that all joins can be used together. If you have more than one fact and all your joins are one-to-many, then you can choose to detect contexts and accept the suggested contexts.
Regards,
Mark