Can we link two universes built on two RDMBS systems.
The requirement is
Some tables exists in Oracle and some tables exists in DB2. But there is one field common in one of the tables in Oracle and DB2 that links the values. That meant, the field acts the Primary Key <-> Foriegn key relation in both the systems.
Now I have to build two universes and link each other so the reports can be generated on the linked universes.
Please advise if any one in the forum encountered this requirement or have any suggestion that you can share.
A universe can only use one connection at a time, so if you are trying to link two different universes coming from different database connections i beleive the best approach would be to create two different queries at report level with the help of two different universes and then merge them based on common dimensions objects instead of linking the universe.
However for linking the universes i am not very much sure but i beleive it is possible.
Prior to BI 4.0 the answer was either “No” or “You have to use Data Federator” or some other means to pull both data sources into a single location, whether physically or virtually. In BI 4.0 the federator product has been integrated into the semantic layer design, so you can build a universe on more than one source.
Linked Universes needs to have same database connection. So merging dimensions might help you to some extent.
I can think of one solution but I am not sure how feasible it is. You can create a view or table using DB Links in one database and use that connection in the Universe.
Another solution would be creating a small datamart that get feeds from multiple databases. I guess you might not be interested in this solution
I agree with you Mark.
Datamart solution will definitely provide better flexibility and also other systems can access the reporting tables. But that approach itself would be like another project. So, people who have to meet tight deadlines may not go with this approach. I can not think of any other solution other than DB links.
If we use Data Federator, only Business Objects systems can access those Federated views.
Also the new Information Designer Tool user guide says that the Universes built using Data Federator can not be converted automatically. I am not really sure what it means… I thought Data Federator is integrated to IDT in BI4.0!!
I wouldn’t see that as an issue. It could be retained as a .unv rather than making it a .unx file anyway. Then longer term it could be built from scratch from IDT with the original .unv as a benchmark.
I want to know how Data Federator handles multiple queries on backend. How different the technique is when compared to report level merging. I came across several Data Quality issues, maintenance issue etc while working with Merge dimensions feature at the report level. It is very hard to debug the reporting issues if it is developed against multiple databases and we are missing the very important flexible ad-hoc feature. I couldnt find a way to handle such issues in a better way. I had to put lot of effort even for making minor changes to reports. Let me know if somebody has any suggestions for me regarding this.
Merging dimensions can be very slow in many cases. Web-I can only merge the data only after getting the results for all the queries. I am not sure how Business Objects server handles parallel queries. But generally this approach is very slow. I guess Data Federator must have some server side grouping or parallel query processing technique to handle this issue in a better way.
The Data federator can pull data from multiple sources. The logic behind that is when you fire a query on a Universe that is based on the data Federator, it creates a subquery for each of the data source. The DF then send the sub query to each of the datasource , the query gets executed on th individual database &results are returned back to the DF Query Server. The DF Query Srever then combine the results from the individual Queries & then combines the data & send the data back to the BO reports.
(BOB member since 2007-04-02)
(BOB member since 2002-06-06)
