Universe on an OLTP database

[Former Member]

Hi All,

I am using BO XIR2.

I wanted to know what is the best way/approach to create a universe on an OLTP database.

The database is highly normalized.

I pulled in the required tables and added joins. In order to resolve loops I uncluded contexs and some aliases.

Now when I create a test report, it results in mostly all incompatible objects.

I think the approach i am using to create the universe is that of a datawarehouse(denormalised) database.

And thus is resulting in a bad structure.

Can anyone help me on the approach to be followed to create a universe on a highly normalised database?

Are there any restirctions in such a universe for reporting?

Please help. '

Thanks in advance,

Edited by: BO User on Sep 16, 2009 10:58 PM

Edited by: BO User on Sep 16, 2009 10:58 PM

[Former Member]

Hi,

• The objects in a context should be under the same class.
• Since you are using OLTP database, you will not have a proper data model as we have in a datawarehouse.
• Try to include the necessary joins for your reports and remove unnecessary joins as it will lead to more loops.
• Try to use views wherever needed.
• Avoid using more derived tables in your Universe as it will lead to performance issues. Use derived tables when you are not able to acheive something in the normal join approach and when you need a quick solution.

Regards,

Santhosh

[Former Member]

hello guys,

i too creating universe on oltp db but looking at the report requirements, universe doesnt seem complete...

issue whch i am facing is-

i got 2 tables(e.g)

in 1 report there is inner join between these 2 tables for other report, it requires left join so on n so forth.

is there any way, we can sort such issues out.

[Former Member]

Hi,

To avoid large number of aliases and contexts, there are alternative solutions such as derived tables or shortcut joins.

Last you can also create views on the database if you are authorized.

If you cannot limit the number of contexts, you can also split your WebI queries in multiple queries.

Didier