How to organize effectively *diverse* data needed for a dashboard in SAS VA?

[sazonov-nv]

Hi,

I have to make a dashboard to monitor some business processes. Processes are quite diverse, so the data needed is not standardized. If I just loaded all the data needed to separate tables, it would be > 30 tables, and their count will grow over time.

So the question is – how to organize diverse data for a dashboard? Is there any kind of best-practice?

Considering Qlik Sense, I thought about using just one "key-value" table on an Oracle server. In this case each dashboard report could be based on a special sql-code, which takes filtered data from the table and transforms it from "key-value" to a usual table on-the-fly (this could be quite fast if the data table on a server is partitioned by a process/report name).

But we decided to build our reports in SAS VA, and it seems key-value solution is not appropriate for SAS VA because of in-memory calculation (key-value structure may increases data size) and poorer abilities to manage key-value data (not sure).

So, is there any elegant solution to organize the data?

I would appreciate any ideas.

[SASKiwi]

It is perfectly OK to have multiple data sources for one VA report. Having over 30 data sources for a single report sounds a lot. Would it make sense to split your dashboard into more than one VA report?

Also are there any similarities between some of the data sources so you can combine these? Many data sources are likely to slow down your report and if you add a lot of calculated items then that will slow it even more.

Providing good VA report performance is a balance between not overloading the report with too many objects (which are hard to understand anyway) and keeping data sources efficient with only the essential columns and calculated items.

[sazonov-nv]

@SASKiwi, thank you for your reply.

It may be a multiple-sheet report (with one main sheet for navigation) or several reports, but in this case they still have to be linked to be considered by users as one solid platform (users want simple navigation without any borders between reports). I think it's not critical, but still I hope to organize some way all the data needed to avoid problems with maintaning / updating many tables. 

Similarities are very week (one can say 'proccess name' and 'report date' are the only common fields).

[Madelyn_SAS]

We have many customers who create reports that are used to enable users to navigate to other reports. If you move forward with this plan, I would suggest creating separate reports. You can link to the reports just as easily as linking to sections in the same report, but performance should be better.

[sazonov-nv]

@Madelyn_SAS, thanks, I'll probably follow this recommendation. But still I have more concerns about not the report itself, but about data organization. Is there any best-practice to organize the data, or using a lot of separate tables is the only appropriate way?
Thanks in advance.

[SASKiwi]

If there is no commonality between the tables then I suggest keeping them separate is sensible. It is quite easy to build batch processes that load LASR tables automatically so I don't see managing a lot of tables is a problem.