The following post concludes the series with a list of all databases seen in the example for the fully flexible architecture.

The following post outlines an architectural design of intermediate complexity for DeepSee. As in the previous example, this implementation includes separate databases for storing the DeepSee cache, DeepSee implementation and settings. This post introduces two new databases: the first to store the globals needed for synchronization, the second to store fact tables and indices.

I am planning to implement Business Intelligence based on the data in my instances. What is the best way to set up my databases and environment to use DeepSee?

In part 1, part 2, and part 3 of this series we set up three user types. In this part of the tutorial we see how to secure model elements (such as DeepSee cubes) and DeepSee items (such as a folder containing pivot tables and dashboards in the DeepSee User Portal).

In part 1 we started working on a security model for DeepSee and create a user type having privileges typical of end users. In this part we are going to create a second user type with ability to edit and create DeepSee pivot tables and dashboards.

How are we doing THIS year versus the same period LAST year?
This is a common need in Business Intelligence. In fact, many design specifications for reports make use of a comparison between a selected period (year, quarter, etc) up to a certain date (for example November 15th, 2016) and a summary of the same information for the previous year (i.e. up to November 15th, 2015).
This post shows how to implement this in DeepSee.