I’d like to discuss the complexities in High-level Universe designing in Business Objects. What r the precautionary measures to take to avoid traps and loops in designing.
I’ve 10 subject areas and around 20 Fact tables with 300 Dim tables.
If I’ve to design a single big Universe , I may not accomplish a security to the best, hope I may create one universe to each subject area and I’d like to know how & what r the reasons for creating the Linked Universes and what are the limitations of total number of conformed dimensions to be used in the Universe design.
Also can anyone help me in providing the Functional Specification Document (FSD) for Universe designing.
There used to be a Universe Best Practices doc on the BO support site, although I don’t know whether it is there. It is quite an old doc, but the theory still stands…
The two links sent by you are not working and please help me in getting detail understanding of Universe designing.
I’d appreciate if you can urgently reply to this ASAP as I’ve to rush with High-level design and I need to understand the following things which are as follows:
I know that I can have a Universe with multiple fact tables linked with conformed dimensions but clarify me whether in such Universe can we Isolate a single Fact table which is not connected to any other fact tables but of course have some dimensions connected to it so that it can be used to pull some reports out of it.
What are the situations where the designer needs to have Linked universes and are they same as derived universes.
Any constraint/limitation of having some number of conformed dimensions in a single universe and how they may impact at physical level implementation of Universe designing and how can we presume that no traps could give rise to occur.
Which is better approach in designing the universe as the following options available:
. Based on Subject areas (which includes fact tables from other
subject areas also – hope linking has to happen here)
. Based on each Fact table (some fact tables acting independently to pull some specific reports and some are used by different subject areas)
At the max, how many conformed dimensions can be available/practically accepted in a single universe.
At this juncture (High-level Universe design), I think that I need to give the following:
. total number of Subject areas if designed on that basis
. total number of Universes
. total number of linked universes
. total number of dimensions in each Universe
. total number of conformed dimensions in each Universe
. total number of reports with their details giving which Universe it will use to pull the corresponding reports
. Defining the Hierarchies used in the Universe for Drilling purpose.
. Grain of each fact table used.
Please suggest me if any other details/points have to be included in FSD of Universe.
After studying the data model as of now in my project, some details are as follows:
. Total 8-subject areas.
. Total 20 fact tables but 18-fact tables are included in the above . subject areas.
. Around 200 dimension tables in total.
. Around 300 reports to be generated (some sample excel reports from their MIS system are provided to us).
. Fact tables are in max in Daily grain, some are MTD (month to date) and few are YTD.
. I think monthly and yearly fact tables are considered to be aggregate tables.
. No other specific aggregate tables are found.
Also send me the sample copy of FSDs for universe/reporting.
With lots of positive responses . I’m eagerly looking for answers …
I prefer not to used linked versions at all, although some have had success with this method - depends on your situation.
Do a search on linked, master and kernal approaches to universe deveopment and you will see the differences described in a better way than I have the time to do now…
Not that I know of, but the more objects you have in one universe may make it difficult for the user to navigate. You would take car of chasm and fan traps by the use of alias and contexts.
I - personally - like business subject areas, you can take care of different grains of facts by the use of aggaregate aware. Although one fact table and its associated conformed dimensions is also a valid method, it depends on your situation.
I know of no restrictions.
The rest of your assumptions seem fine, I am hoping you have a powerful calendar table.
You are correct in that MTD and YTD are your aggregate tables, these can be used in conjunction with conformed linked dimensions, contexts, the use of aggregate aware measures and incompatabilities set for the various dimensional attributes.
Infact your model sounds much better than my current one 8).
I have sent a few docs to your Hotmail address - good luck!
Thanks a lot and points included in the documents are really useful for my designing.
I request you that please provide me a sample of “Functional Specification Document” which should accomplish the high-level Universe Design Document.
Also request you anyone among this Forum, that this is the first experience I’m involved in High-Level Universe Design and being novice I’m little worried and not that confident for the same and hence request you all to help me with any document or tips and tricks for Disigning Universe successfully.
Regards,
achary.
Unsure of exactly what you mean here? The functionality should be dictated by, firstly, fixed reporting requirements and any adhoc functionality that should be built in as defined by the business.
As for designing universes successfully, I’m afraid there is no short cut apart from experience and reading as much as possible.
This forum is a wealth of information on the subject, I can honestly say that I have learnt more here than any documentation has ever taught me… 8)
ThankU MAk … for your answers which helped me to explore the required information.
As per my project Universe designing, I see that I need to go for the creation of 7-Universes and among them few Universes are having 4-5 Fact tables.
And above all I’d like to clarify that among those 4-5 Fact tables in a single Universe does they can accomplish to be inside a Universe without connected to any other fact table though there may be same dimesion tables in both the Fact tables. This situation has arised as there are some reports which can be puuled from one fact table itself.
Also I’ve certain reports which need to get data from current Daily Fact Table and other Universes which are like Summarised/aggregated fact tables, what type of approach is needed in this scenario i.e. MAster or Kernel Approach, to the best of my knowledge I may go only for Kernal approach. Also update me if there are any other specific situations/reasons in real time to link different Universes. And how many Universes can be linked at one instance to the max.
Yes, you link your common dimensions to your facts and then allocate contexts to ensure the correct join path as well as making common measures, in both or more facts, aggregate aware.
Why can’t you put the aggregations in the same universe as the daily table, link and use aggregate aware and contexts?
Thanks a lot for kindly arranging the document u sent me.
I’ve gone thro’ ur sent document and learnt that it works well in the development and also whenever there is any changes made to the universe.Can you provide me a High-level conceptual Universe Design for BOXIR2.
After joining we take care of contexts and see for the joins.
But what if u’ve few Fact tables independently put in a sigle Universe but not conected to each other, then no joins & no contexts,please make it clear.
Next, how can I change the thigs like putting a daily-grain Fact table in one Universe and how u can bring the fact table with monthly & yearly level Fact tables and create the navigation to the aggregate aware tables .
Please suggect me anyone.
There is a demo universe that comes with the product called, I think, e shopping which provides a good example of the use of aggregate awareness and free standing aggregates.
If you look at this - albeit simple - example it should provide you with a few ideas…
Unfortunately, I don’t know of one. Some of the best materials can, however, be found on the Integra website.
Please clarify the following things:
1.How will I conclude to keep a degenerated dimensions in Universe, means any special procedure available.
2.How can a non-key dimension(not a part of primary key in Fact table) affect the fact table w.r.t. joining different dimensions.
3.can I group 10 independent Fact tables in a single Universe without any link among them as every report generated using only single fact table.
4.Can I accomodate a universe for the data model having star schema, but at one Subject area is snow-flaked schema.
5.How self join dimension table be accomodated in a universe as this is not linked to any other tables in the universe.
No special procedure as far as I am aware, how is this modelled in terms of your data? What is expected of that degenerated dim in terms of reporting?
If this means you have a snowflake connecting to your dimension this should not prove to be a problem, just add this join to the relevant context, the join will only be invoked when items are selected from the snowflaked dimension. You may want to alias this, as appropriate.
You can and this is often what you should do. Do these fact tables have shared, conformed dimensions? Ten may be an unwieldy amount, however, and make the universe difficult to use. Are these ten all part of the same subject area?
This matters not a bit, just incorporate the joins from your snowflaked dimensions into the appropriate contexts.
Whats this used for? Its fine to have free standing tables but you should make all other the objects incompatable with this table - if there is no relationship - as if it is unjoined you will get a cartesian product.
if this table is unjoined and is a copy of another dim to enable subqueries, max, min, e.t.c - e.g. calendar - then you may not have to make it incompatable.
Quote:
3.can I group 10 independent Fact tables in a single Universe without any link among them as every report generated using only single fact table.
You can and this is often what you should do. Do these fact tables have shared, conformed dimensions? Ten may be an unwieldy amount, however, and make the universe difficult to use. Are these ten all part of the same subject area?
replying above qst?
In my project I’ve total 10 fact tables:
i) among which 4fact tables have around 24 conformed dimensions and still if I go little deeper 5 corporate dimnesion tables are shared by all the 4Fact tables and reamining are shared by 3 fact tables and sometimes 2 fact tables. Problem over here is the reports which includes measures from above fact tables are in some typical permutation & combinations.
ii) next 4 fact tables same as above.
iii) last 2 fact tables are independent and no conformed dimensions but have some souple of reports pulled from them.
iv) Above all all the above fact tables fall under single Subject Area as of now.
Also suggest me how can it be feasible to accomodate the designing of the Universe if I’ve some changes approved & done in Global Data Model later. Why I’m worried is there is a possibilty of some changes discovered by the Modeller and I need to again map all the reports to the fact tables and subjects areas though they may look like minor changes.
Please suggest me.
Once you have your universe in place, it is usually easy to implement any changes it depends upon the actual situation.
The reports aren’t pointed aren’t pointed to the fact tables but the universe as a whole.
If you make the changes to the universe in the correct way, do not delete objects, joins, contexts e.t.c but amend what you have already.
The changes will, if applied correctly will trickle down to the reports once the universe has been exported…
But please suggest me that as I’ve a Universe with 3-fact tables and around 30 Conformed Dimensions and atleast 20-22 are minimum common dims found from each fact…is there any other way to minimise these Conformed Dims/ can we combine these fact table and will it make any sense ?
Adding to the above also please suggest me how can I make good ground for getting best performance of the universe at this High-level designing.
You can combine the fact tables, as long as they are at the same grain. As far as performance is concerned index your tables and partition either via software or hardware depending on the volumes of data involved.
, there is a wealth of info on this sort of thing…
(BOB member since 2005-01-06)
(BOB member since 2006-02-24)
(BOB member since 2006-08-02)