This chapter provides an overview of DeepSee and the implementation tools and process. It discusses the following topics:
Be sure to consult the online InterSystems Supported Platforms document for this release for information on system requirements for DeepSee.
Purpose of DeepSee
The purpose of InterSystems DeepSee is to enable you to embed business intelligence (BI) into your applications so that your users can ask and answer sophisticated questions of their data. Your application can include dashboards, which contain graphical widgets. The widgets display data and are driven by pivot tables and KPIs (key performance indicators). For a pivot table, a user can display a listing, which displays source values.
Pivot tables, KPIs, and listings are queries and are executed at runtime:
A pivot table can respond to runtime input such as filter selections made by the user. Internally it uses an MDX (MultiDimensional eXpressions) query that communicates with a DeepSee cube.
A cube consists of a fact table and its indices. A fact table consists of a set of facts (rows), and each fact corresponds to a base record. For example, the facts could represent patients or departments. DeepSee also generates a set of level tables. All the tables are maintained dynamically.
Depending on your configuration and implementation, DeepSee detects changes in your transactional tables and propagates them to the fact tables as appropriate.
DeepSee generates an MDX query automatically when a user creates the pivot table in the Analyzer.
A KPI can also respond to runtime user input. Internally, it uses either an MDX query (with a DeepSee cube) or an SQL query (with any table or tables).
In either case, you create the query manually or copy it from elsewhere.
A listing displays selected values from the source records used for the rows of the pivot table that the user has selected. Internally, a listing is an SQL query.
You can specify the fields to use and let DeepSee generate the actual query. Or you can specify the entire query.
Dashboards can include buttons and other controls that launch actions. Actions can apply or set filters, refresh the dashboard, open other dashboards or other URLs, run custom code, and so on. DeepSee provides a set of standard actions, and you can define custom actions.
DeepSee Components to Add to Your Application
To add DeepSee to an application, you add some or all of the following components:
Data connector classes. A data connector enables you to use an arbitrary SQL query as the source of a cube or a listing.
Cube definition classes. A cube defines the elements used within DeepSee pivot tables, and controls the structure and contents of the corresponding fact table and indices.
A cube definition points to the transactional class (or the data connector) that it uses as its basis.
You can have any number of cubes, and you can use a given class as the basis of multiple cubes.
For each cube, DeepSee generates and populates a fact table class and other classes.
Subject area classes.
A subject area is primarily a filtered cube. (It includes a filter and overrides for different parts of the cube definition, as wanted.) You can use cubes and subject areas interchangeably in DeepSee.
KPI definition classes.
You define KPIs when you need custom queries, particularly queries that are determined at runtime based on user input.
You also define KPIs when you need custom actions, because actions are contained in KPI classes.
Pivot tables, which you create by drag and drop. DeepSee generates the underlying MDX queries.
Dashboards, which display pivot tables and KPIs by running the underlying queries and displaying the results.
The User Portal, which displays pivot tables and dashboards.
As noted elsewhere, InterSystems generally recommends that you use mirroring as part of your high availability strategy. For any large-scale application, InterSystems recommends that you base your DeepSee cubes on the application data that is on the mirror server, as shown in the following figure:
Define your application so that the code and the data are in separate databases. This is not required, but is a typical architecture.
Set up mirroring so that the application data is mirrored to the mirror server.
So that DeepSee can access the application data, copy some or all of the application classes and other code to the mirror server as well.
It is not generally necessary to mirror the application code.
On the mirror server, create a database to contain the DeepSee cube definitions and (optionally) data.
Optionally create another database to store the DeepSee fact table and other large-volume DeepSee data. The following chapter provides information on the globals that DeepSee uses.
On the mirror server, define a namespace in which to run DeepSee. In this namespace, define mappings to access the application data, application code, DeepSee cube definitions, and DeepSee data on this server.
Note that for small-scale applications or demos, all the code and data can be in the same database.
For recommendations on DeepSee disaster recovery, see DeepSee and Disaster Recovery.
Main Implementation Steps
The implementation process includes the following steps:
If the namespace in which you want to use DeepSee does not yet define a web application, define a web application for it. See the chapter “Performing the Initial Setup.”
Optionally map the DeepSee globals from other databases, for performance.
See the chapter “Performing the Initial Setup.”
Create the cubes and optional subject areas. This process includes the following steps, which you iterate as needed:
Define one or more cubes. In this step, you use either the DeepSee Architect, Studio, or both.
Build the cubes. Here you use the Architect or the Terminal.
Use the DeepSee Analyzer to view the cubes and validate them.
After the cubes are defined, define any subject areas based on those cubes.
For information on creating cubes and subject areas, see Defining DeepSee Models.
For information on using the Analyzer, see Using the DeepSee Analyzer.
Optionally create KPIs. See the Advanced DeepSee Modeling Guide.
Optionally create custom actions. See the chapter “Defining Custom Actions.”
Make changes as needed to keep the cubes current. The way that you do this depends on how current the data must be, as well as any performance considerations.
See the chapter “Keeping the Cubes Current.”
Package the pivot tables and dashboards into Caché classes for easier deployment.
See the chapter “Packaging DeepSee Elements into Classes.”
Create links from your application to dashboards. See “Accessing Dashboards from Your Application.”
At the appropriate points during this process, you may also have to do the following:
Create data connectors — See “Defining Data Connectors.”
Configure settings — See “Configuring Settings.”
Perform localization — See “Performing Localization.”
Define custom portlets for use in dashboards — See “Creating Portlets for Use in Dashboards.”
Perform other development tasks — See “Other Development Work.”
Set up security – See “Setting Up Security for DeepSee.”
You use the following tools during the implementation process:
Tools available from the DeepSee section of the Management Portal:
Architect — Use this to define cubes and subject areas. Here you can also compile and build cubes (and compile subject areas).
Analyzer — Use this to examine cubes and subject areas when validating your model. Later you use it to create pivot tables.
User Portal — Use this to define dashboards.
Query Tool — Use this to create MDX queries and view their query plans.
Folder Manager — Use this primarily to export pivot tables and dashboards so that you can package their definitions within a Caché class.
You can also use it to associate resources with folders.
Settings option — Use this to specify the appearance and behavior of the User Portal, and to define variables that can be used in dashboards.
DeepSee Logs — Use this to see the DeepSee build log for this namespace.
Studio — Use this to define advanced cube features, any methods or routines used by cube elements, and any callback methods in the cube classes. You also use this to define KPIs.
Terminal — You can use this to rebuild cubes and to test methods.
MDX shell (running in the Terminal) — Use this to examine cubes and subject areas and to create custom MDX queries and see their results.
Other sections of the Management Portal — Use these to map globals, define resources, roles, and users for use with DeepSee, and to examine the DeepSee fact tables if wanted.
The data connector class (%DeepSee.DataConnector) — Use this to make arbitrary SQL queries available for use in DeepSee cubes and listings.
The result set API (%DeepSee.ResultSet) — Use this to execute MDX queries programmatically and access the results.
The SAMPLES database includes two DeepSee samples, in the HoleFoods and Patients packages. These samples include cube definitions, subject areas, KPIs, data connectors, and plugins. They also include sample pivot tables and dashboards.