Intraday & Historic Reporting

[niktherussian]

Good morning guys & girls,

I've been tasked with a new project for our business whereby we have a new system in place which they would like reported both live (intraday reporting - would look at live data from last 2 days) & aggregated/historic data [looking at MOM/YOY etc].

Has anyone created a dashboard which features this kind of functionality? Would it be possible to create parts that have to be reloaded every 15 mins from SQL (for the intraday/live reporting), whilst the historic data can run/reloaded off stored down data in QVDs (which are updated overnight for instance)?

Currently the thought process is to create 2 dashboards for the requests - one for historic and one for intraday, however in my minds eye creating one big dashboard may be more efficient (not definitely - this is just an idea currently). It's simply whether there's a way of facilitating what I've stated above. (very obscure I appreciate).

If anyone has any input please let me know. Alternatively if there are any questions that I can answer I will - please remember this project is business sensitive thus I cannot give much information surrounding it. 

Cheers ears!

[edwin]

if historical is huge,you may not want to reload that every 15 mins.  

you can binary load historical data and reload the incremental into it.  thus you can reload your historical once a day and your 2nd stage every 15 mins after that.

[edwin]

i just realized that depending on your architecture, you may not want to have two datamodels.  in which case, an alternative is to save the historical tables in QVDs and consume the QVDs in your DM that runs every 15 mins.  you create the QVDs only once a day.

[niktherussian]

Hi Edwin,

That seems logical to me. The historical data would be stored down in QVDs which would refresh overnight. Meanwhile the in-day data would be pulling direct from SQL, at the end of each day this data would ideally store down into the QVD to be encompassed within the historical data. The historical data would have a max range of up to 25/26 rolling months.
What I'm thinking currently is one big dashboard for the historic data with section access for those who would need to see the in-day reporting. The in-day reporting is the priority so will be building around that first and then building the historical extracts etc.

If I stagger this approach (i.e at a lower level create the historical reporting) & then binary load the historical, followed by the live/in-day load from SQL - does this (in your minds eye) sound like it should work?

[edwin · Accepted solution]

what confuses me is why section access is a factor here.  why would different users have different rights to same data but different dates.

regardless you do have both options that will work:
single dashboard data divided by dates and section access enabled. 
2 dashboards, different dates, different reload times, and different sets of users

i suggest that the 2nd option would be more efficient both in reload times, no section access required, and simpler to maintain both in script and in QMC