This chapter provides an overview of InterSystems IRIS Business Intelligence and the implementation tools and process.
Be sure to consult the online InterSystems Supported Platforms document for this release for information on system requirements for Business Intelligence.
Purpose of Business Intelligence
The purpose of InterSystems Business Intelligence 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 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. The system also generates a set of level tables. All the tables are maintained dynamically.
Depending on your configuration and implementation, the system detects changes in your transactional tables and propagates them to the fact tables as appropriate.
The system 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 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 the system 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. The system provides a set of standard actions, and you can define custom actions.
Business Intelligence Components to Add to Your Application
To add Business Intelligence 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 Business Intelligence 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, the system 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 Business Intelligence.
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. The system 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 in the High Availability Guide, InterSystems generally recommends that you use mirroring as part of your high availability strategy. For any large-scale application, InterSystems recommends a mirror involving a failover pair, an async reporting member, and at least one async disaster recovery member.
Analytics applications can consume all available processing power on an instance during their run time; by providing Analytics functionality through a reporting async member, the failover members of the mirror are better able to maintain high transaction volume.
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 async reporting member.
So that the system can access the application data, copy some or all of the application classes and other code to the reporting async member as well.
It is not generally necessary to mirror the application code.
On the reporting async member, create a database to contain the cube definitions and (optionally) data.
Optionally create another database to store the Business Intelligence fact table and other large-volume Business Intelligence data. The following chapter provides information on the globals that the system uses.
On the async reporting member, define a namespace in which to run Business Intelligence. In this namespace, define mappings to access the application data, application code, cube definitions, and Business Intelligence 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 Business Intelligence disaster recovery, see Business Intelligence and Disaster Recovery.
Main Implementation Steps
The implementation process includes the following steps:
If the namespace in which you want to use Business Intelligence does not yet define a web application, define a web application for it. See the chapter “Performing the Initial Setup.”
Optionally map the Business Intelligence 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 Architect, Studio, or both.
Build the cubes. Here you use the Architect or the Terminal.
Use the 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 Models for InterSystems Business Intelligence.
For information on using the Analyzer, see Using the Analyzer.
Optionally create KPIs. See the Advanced Modeling for InterSystems Business Intelligence.
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 InterSystems IRIS® classes for easier deployment.
See the chapter “Packaging Business Intelligence 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 Business Intelligence.”
You use the following tools during the implementation process:
Tools available from the Business Intelligence 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.
MDX 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 an InterSystems IRIS 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.
Business Intelligence Logs — Use this to see the Business Intelligence build log for this namespace.
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 Business Intelligence, and to examine the Business Intelligence fact tables if wanted.
The data connector class (%DeepSee.DataConnectorOpens in a new window) — Use this to make arbitrary SQL queries available for use in cubes and listings.
The result set API (%DeepSee.ResultSetOpens in a new window) — Use this to execute MDX queries programmatically and access the results.
Accessing the Samples Shown in This Book
Most of the samples in this book are part of the Samples-BI sample (https://github.com/intersystems/Samples-BIOpens in a new window) or the Samples-Aviation sample (https://github.com/intersystems/Samples-AviationOpens in a new window).
InterSystems recommends that you create a dedicated namespace called SAMPLES (for example) and load samples into that namespace. For the general process, see Downloading Samples for Use with InterSystems IRIS.
These samples include cube definitions, subject areas, KPIs, data connectors, and plug-ins. They also include sample pivot tables and dashboards.