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.
Mak 1 
(BOB member since 2005-01-06)
Combination of docs too big…
YGM.
Mak 1 (BOB member since 2005-01-06)
Please give me the docs regarding any performance tuning during Universe Designing and also please explain how can we combine the daily fact table data and Aggregate table’s data in a single report.
You also told that for performance tuning we need to index the fact table and could you please clarify me that this job is done at Physical Data Modelling or Universe Designing. I don’t think that a Universe designer has to do anything with these indexing and memory partitioning.
regards,
achary.
ap.achary (BOB member since 2006-11-29)
[quote:57758a12ac=“ap.achary”]I don’t think that a Universe designer has to do anything with these indexing and memory partitioning.
[/quote]
That is what a real DBA is for.
Andreas 
(BOB member since 2002-06-20)
Agreed. Get your DBA to analyse your queries and apply indexes accordingly.
Mak 1 (BOB member since 2005-01-06)
Please post some points how to redirect/navigate the report to connect to Aggregated table to pull the pre-calculated values in that when it is present in the universe but not connected to any of the other tables.
Regards,
achary
ap.achary (BOB member since 2006-11-29)
Take a look at the @Aggregate_Aware function in Designer and aggregate navigation.
Andreas (BOB member since 2002-06-20)
As I stated earlier in this thread:-
I did get the name wrong, it is efashion - this demo universe uses aggregate_aware and free standing aggregate tables…
Mak 1 (BOB member since 2005-01-06)
Hi Mak,
Your mail is not readable.Pls. edit and send your message.
Nextly,
please suggest me whether there is any possibility to connect a daily fact table and a monthly grain aggregated fact table directly without any conformed dims.
For Example: I’ve 2 fact tables, one Bill Fact (Monthly Aggregated - Bill key as PK) and second Bill-Charge Fact (Daily/Detail Fact – Bill Charge Key and Bill Key as composite PK). Now please confirm me if we can directly join the above fact tables and a report can be possible to pull the data to view the Bill with charge details.
Please need ur suggestion.
regards,
achary.
ap.achary (BOB member since 2006-11-29)
I’m wondering how you can join both the tables when they are sharing different granularity as mentioned by you, as in Monthly Vs Dailly.
To what I assume, Bill to be the Header/Master table, in line with Bill Charge as detail(line items), holding each segment of the Bill.
If this is the case, I would apply Aggregate_Awareness in case of objects requiring Bill Charge details along with Bill summary, else use the Bill Fact table just for summary.
e.g.
@Aggregate_Aware(SUM(BillFact.TotalBillAmount), SUM(BillChargeFact.LineAmount))setting BillChargeFact table Incompatible with all objects of BillFact table.
– Luckys.
Luckys 
(BOB member since 2006-08-02)
Sorry, I’m unsure what you mean here :?
Luckys post should put you on the right lines… again, I suggest looking at the efashion demo form Business Objects, as this universe has freestanding aggregates at different grains and may illustrate what you need…
Mak 1 (BOB member since 2005-01-06)
Hi,
Please give me suggestion for the following:
1.How can we have the security of information to be taken care for the universe having 3-4 fact tables with perspective to the users accessing the Universe.
2.If as per the Business Requirement and the analysis of the available current MIS Reports, I came to know that no report is generated out of the combination of two fact tables except one or two.Hence the arguement here is my client want the Universe to have only 1 fact table each, does this a right way/approach. As I have 20-Fact tables, they want 20 Universes, but as a designer I consolidated certain fact tables in a single Universe depending on the Business Process and decided to have around 7-Universes. So what shall I do, shall I redisign the conceptual Universe Designing, if so give me reasons and if not please also give me reasons ??
Urgently Need experts valuable solution for the above queries.
Regards,
Achary.
ap.achary (BOB member since 2006-11-29)
I’m unsure whether you wish to apply restrictions per fact or per row.
This post illustrates row level security using supervisor:-
https://bobj-board.org/t/46143
You can also do this with less of a maintenance overhead if you put a security table into your database and join this into your warehouse - there are a number of posts here on how to implement this.
My opinion is you should stick to your guns and design around the business processes.
The larger amount of universes the greater the maintenance overhead.
The key word here is current, what happens when the needs change in the future?
Mak 1 (BOB member since 2005-01-06)
Hi,
There are 3-points I need to get clarified:
2.Please put some points to be taken care in migration of the reports from BO5.0 to BO6.5. How shall we migrate the Universes for the same.
Thanks,
Achary.
ap.achary (BOB member since 2006-11-29)
Please clarify me the above doubts ASAP.
ap.achary (BOB member since 2006-11-29)
They key is the join cardinalty between the involved tables, if both fact tables have a 1:1 join cardinality then you can join them, if not you will be running into a fan trap, which must be resolved using alias tables and universe contexts.
Look in the Supervisor FAQ thread here on BOB, there is an entry on how to unlock the General Supervisor ID.
Andreas (BOB member since 2002-06-20)
Hi Mak 1,
Can you please share those documents with me… I am also going through a tough time with universe design.
my email id is [Email address removed]
Advance Thanks,
Sam
sam2056 (BOB member since 2006-10-05)
I’m not sure which “documents” you’d like Mak 1 to share with you – he’s provided a hyperlink to another post here on BOB.
That’s what we’d prefer – we’d prefer that items to be shared be posted here on BOB, rather than secretly shared via email – unless the documents are Copyrighted – in which case they should neither be posted nor emailed around – but instead should be gotten from the owner (such as BusinessObjects tech support).
Anita Craig 
(BOB member since 2002-06-17)
Hi Anita,
Thanks for your post…
what I mentioned is one of his post in 2nd page of this post… he told that the combination of this documents is big to post in this forum…so that I told him to send as email to me…nothing esle…I think you uncerstood what I mean…
Posted: 21 Dec 2006 15:10
Post subject: Re: High-level Universe designing in Business Objects
--------------------------------------------------------------------------------
Quote:
The documents that you mailed, can they be shared on this thread itself, if the size is big can you please email to luckysharma@gmail.com also.
Combination of docs too big..
YGM.
Thanks,
Sam.
sam2056 (BOB member since 2006-10-05)
Hi Sam, Sorry I have been offline for a while.
I’m afraid the docs are subject to Business Objects copyright, so it seems I can’t post or mail them.
The document is a very old one from 2001, The name is ‘Reporter and Designer Best Practices’ and it is a word doc.
Searching on tech support may help you locate it…
Mak 1 (BOB member since 2005-01-06)