BI Models

Indicee BI Modeling

Indicee’s powerful BI modeling platform allows data and data processes to be modeled in a fine-grained, extensible way. A useful analogy is to consider how recipes combine:

ingredients to produce preparations such as sauces which are used to create complete dishes.

In Indicee, you combine:

data to produce BI Assets such as fields and measures which are used to create reports and dashboards.

New ingredients and combining techniques can easily be added to the Indicee platform to enable it to describe new kinds of output. Unlike most other platforms, many new kinds of capability can be added without having to rebuild the whole product – Indicee is fine-grained and designed for such extensibility.

Indicee Model Overview

The Indicee model consists of a variety of BI Objects that can be combined together to describe an actual BI process or solution such as the generation of a report. The overall architecture is one of assembly or Composable BI.

Each type of BI Object, once defined, is a sharable resource. Sharing and reusability is the main driver for improving the economics of building BI systems and solutions.

The Indicee BI Model can be broken down into Data Objects that can be consumed to build BI Assets

Each step in the Indicee Data Model consolidates the underlying source data and adds business context to the data. This allows business users to build reports and dashboards without having to understand the organization of the source data. This works as follows:

Tables and Columns define the Source Data

At the lowest level of data abstraction, the Indicee Data Model can describe Data Sets (tables), each with a number of Columns. A Data Set can contain multiple tables, in the same way that a spreadsheet can contain more than one sheet. Within each table, a Data Set records which of the Columns are in use by the model, and assigns a primitive type (NUMBER, TEXT, DATE…) to the Column that defines how the data in the column should be interpreted.

Clearly, the data in a Column will have a particular meaning, but at the Column level, all Indicee records in the model is the very basic data type, sufficient merely to load data values correctly.

The Indicee model allows you to define calculated table Columns (called Projection Columns). These are calculated objects that create new values for each row of the table such as a combined name (from first and last name Columns), or a sales total (from units sold and price Columns).

Fields add Semantics to the Data

A Field is the Indicee model object that captures the lowest level of semantic knowledge about data. It describes the meaning of a single type of data that might be found in a Column.  A Field can stand for any particular use of a simple set of data values, and should be given an appropriately meaningful name and description. All Columns in a Data Library that represent the same meaning should be mapped to the single Field in the model that represents that meaning. In this way several Columns in a Data Set can be unified and made to be equivalent. This will eventually allow the Indicee engine to join data and allow the construction of Questions that apply across Data Sets.

Besides mapping Fields to Columns, it is also possible to create a Calculated Field whose value will be based on other Fields and not mapped directly to columns.

Numeric Fields carry a property that determines the default aggregation function that will be applied when the field is used in a grouping context. For instance, if a Sales Field is required to be calculated grouped by Country for months in a year, then the default aggregation function is likely to be SUM, so that values are added together for each country and for each month.

Terms add Business Context to the Fields

A Term is the Indicee model object with the highest level of semantic knowledge about data. It describes the meaning of collections of data at a business level and the roles that data can play as Subjects (dimensions), Measures (values) and indicators of Time in a report. Terms are used to construct Questions, and have a real-world meaning with regard to data such as  people, places, things, facts and time. Every Term is constructed from one or more Fields in the model. A Subject Term, such as “Employee”, would have at least one “key” Field that identifies its uniqueness (e.g. Employee IDs or social insurance numbers). Subject Terms may also have one or more property fields specified that can produce data appropriate to each instance, such as an Employee’s first name, last name and join date. Finally one Field can be designated as the “caption” of the Subject, providing a suitable display name. In the case of an Employee this might be a calculated field that creates a “full name” from “first name” and “last name” Fields.