When do I use Information Objects

I am trying to find out if there is any advantage to using Information Objects as data sources for my reports.

My reports are generated using SQL on the back end. All of the tables that would be used in any queries are all in the same database.

I'm pretty good with SQL and I can write views to group and aggregate my fields. I have connected to views before with BIRT and used them when creating a report.

Am I missing any features by not using Information Objects? When my users start creating Ad Hoc reports using fields I make available to them is there anything I can do with an Information object to help them that I can't do with views?

I have read the docs about creating info objects but I think the real strong point is if you had data coming from multiple databases and wanted to create joins between them.

Any help would be greatly appreciated. Thanks.

Find more posts tagged with

Comments

johnw

Even in a single database use case such as yours, IO's can provide quite a bit of benefit.

Think of IO's as intelligent, cacheable views, or meta-data layers.

They are intelligent because they can re-design queries on the fly that will only bring back what is needed. So, lets say for example, you have 3 Maps defined in your IO, called A, B, and C respectively. You define an IO that uses these three maps, and defines optional cardinality between the tables. Now, when you go to consume that IO in a BIRT report, and you say you only need fields from tables A and C, the joins and field selections will be removed from the actual created SQL, assuming the cardinality is defined as optional. It also does some tuning if the cardinality is set to 0..1 or 1..*.

It is cacheable because you can keep the results of a IO query stored in iServer for later use. This is useful in cases where there are long running queries. This alleviates load on backend databases. It can also be a mix of cacheable results and real-time SQL results.

Both cases are applicable in the ad-hoc scenario you lay out. You don't really want power users or average users having to know SQL to work with their reports. You just want to expose the information objects they need, and let them select what fields they want to report on, letting the intelligent query generation do the rest. This alleviates you having to field every report request that comes through, and frees you up to handle special requests.

It is also useful if you want to write a query once, and be able to use it across multiple Actuate products, such as ERD Pro, Birt Spreadsheet, and BIRT Pro.

nelsont

Thanks for your reply. I guess I will start out with some broad questions and get more specific depending on what answers I get.

Lets say you have a database with three tables. People, address and issues, all linked by a common ID number.

Would you automatically add three datasets to your information object - one for each of the three tables and let the IO do the joins and the users do the grouping, etc when building the report? Or would you create views in your database joining those three tables in various ways and then make the views available to the end user creating the report?
Whatever your answer is to that, does it still hold true when you get up to dozens of tables in your database, sometimes with links that are several tables deep?

We won't be caching data for the forseeable future. It changes too much daily and we want to have the latest data available for the reports. If this is one of the main reasons to use Information Objects then that will help me decide.