Dashboard performs less on Oracle database than on in-cognos Datasets

[moos_93]

Good morning!

As the title says: I have made a number of datasets in Cognos, and connected them logically in a data module. On this module I built a dashboard that performs perfectly.

To save the local cognos server, I asked our local ETL specialist to recreated the datasets with ETL, and to write them off in an Oracle database. These tables I have then connected again in a data module, in the exact same way as I did with the datasets. On this module I built an identical dashboard as well. The performance of this dashboard is absolutely horrable, and most visualisations time-out on loading.

The fact table in question is a table with about 130.000 records, using several foreign keys for which dimensions were built. Most of these dimensions are 1:N to the fact table, but I also built a date dimension that is N:N, covering the time between START_DATE and END_DATE. When using this dimension, the number of records increases to 170 million.

Am I doing something wrong, or is the discrepancy in performance between the Oracle-database and the Datasets to be expected?

Thanks for your insights!

[dougp]

That is expected.  The dashboard that gets data from the database must perform these tasks for every visualization every time the user touches something.
write SQL
connect to the database server
run a query that involves joins between multiple tables
get a response back
update the viz

Put another way, when you are connecting to the database:
Cognos must write a more complex query.
Cognos spends time communicating with the db server.
the database server must perform lookups and filters across joins.
Cognos spends more time communicating with the db server.
Cognos waits for the data to be downloaded across the network.

In contrast, using a Cognos dataset means
write SQL
get data from a single table
update the viz

Choosing to use a Cognos dataset involves considering the tradeoffs between size and speed.  For most cases, a dataset will perform much faster than a direct database connection.


This is the same as using Power BI and comparing Import vs. Direct Query.

[bus_pass_man]

Yes I think you're doing something wrong.  You don't mention a bridge table for your N:N relationship, which you probably would want to have for any legitimate bridge table scenario but I really don't think this is one of them. 

covering the time between START_DATE and END_DATE.

Can you clarify what you mean by this.  Is this a duration?  What are you trying to do here?

Also is the N:N in the time dimension or the relationship between it and the fact table?  You are unclear.


I can not comment about possible other modelling problems because I have not seen your model and all the information I have is what you have chosen to reveal.



One very big problem with data sets is that you can't define data security on them, unlike tables in a loaded schema.