Next, a look at how this group of metrics maps to the actual raw data is needed. It's common to find more than one database in a business and we often see disparate data stores with no unified data warehouse for analysis. A good understanding of database technologies is helpful and it's always preferential to work with a client's database team, as they usually know their data better than we do!
Frequently, we recommend the client consolidate their databases into one centralized storage location for the reasons of performance and maintainability. These options are usually presented:
In the end, either the client's or our database team will then provide a data access API. This data access layer will simplify and streamline the pulling of data from the consolidated data source generated for the application.
On a side note, it should be stated here that we've recommended many clients go with stored procedures - or concepts of stored procedures - whenever possible. This separates the application from the data sources in a maintainable manner, e.g., there are no database query strings in the application code. While there are times when it makes sense to mix the business logic into the stored procedure, most of our projects usually handle the business logic from the application side. (Business logic refers to the functional algorithms that manipulate data into a consumable form for the U.I.) With all this in mind, we're now ready to get on with the dashboard.