BusinessObjects Universe Context vs Framework Manager

[bi4business]

Hi All,

For my customer, I have to migrate some BO Universes to Framework Manager Models.
They are using a lot context path joining tables insight Universe Designer.

I know you can create an alias for this, but then I have to create 2 Query objects.
Does anyone has a good solution how I can advise this customer?

BI4BUSINESS

[sathya084]

Hi,

Even I am in the same situation , migrating from BO 3.1 to Cognos 10.2.1 and existing model contains lots of context paths, most of our business user prefer adhoc reporting.

If I solve all the context path with alias method then I will end up with 50's + alias / query subject and it will be difficult for end user to choose the query item

For example consider if I have employee table -> department-> location->employee

now If I alias it then I need to create 2 location related query items/ query subject and it would be confusing for end users to choose.


Any suggestion to solve this issue in a better way

[MFGF]

Hi,

Even I am in the same situation , migrating from BO 3.1 to Cognos 10.2.1 and existing model contains lots of context paths, most of our business user prefer adhoc reporting.

If I solve all the context path with alias method then I will end up with 50's + alias / query subject and it will be difficult for end user to choose the query item

For example consider if I have employee table -> department-> location->employee

now If I alias it then I need to create 2 location related query items/ query subject and it would be confusing for end users to choose.


Any suggestion to solve this issue in a better way

What is the logical flow of this? Do all employees belong to locations? Do you really need employee to be referenced twice in the join path? Sometimes it's a worthwhile exercise to understand the business requirements and revisit what modeling has been done with a view to simplifying/updating it based on what the users really need. It's often the case that models (particularly old ones) are still relevant to business processes from ten years ago (or whenever the model was designed) but haven't adapted with changes in the business since then. I'd recommend you perhaps treat this migration as an opportunity to revisit the real requirements, and build a model in Cognos that suits those, rather than blindly migrating the exact BO functionality across, assuming it is an exact fit.

Good luck!!

MF.

[sathya084]

Thanks for your reply MFGF :)

In my previous comment I just explained the join condition and you are correct we do not need to alias Employee but we have to alias location, consider for an instance an employee e1 is linked to Department d1 and d1 location is xyz but employee home location is abc now in this situation we need to alias location table in order to get location details of employee / department.

Considering above scenario if we alias location table then we have to create 2 subject query for location and my presentation layer would look like below

1) Employee Details
2) Department details
3) Employee Location
4) Department Location

What I need to achieve is like below

1) Employee Details
2) Department details
3) Location details

so that adhoc users does not have any hassle in selecting the location, this is just a simple instance but we have a larger loops and context which results in duplicated Query subject and Items.
My question is straight forward how to avoid this duplication.

Yes remodeling entire data structure into fact and dimension table will definitely solve this issue but it is time consuming and in current situation that is out of scope, could you please suggest if thr is any other alternative to handle loops instead of alias.


Thanks,
Sathya