Board 11.2 Release Notes

What's New in Board 11.2

 

 

Entities MaxItemNumber

It is now possible (optionally) to define the parameter MaxItemNumber for entities used in a cube structure. Similarly to the MaxItemNumber parameter of BOARD version 10, this parameter sets the maximum number of members (items) that an entity can contain. If you are a BOARD 10 developer, note that there are many fundamental differences as described below.

 

MaxItemNumber

 

When an entity is used in a cube structure, a MaxItemNr is automatically calculated for that entity in that structure, using an internal algorithm that optimizes compression and performance. The calculation of the MaxItemNr occurs only after entities have been populated with members (isn’t computed for empty entities) and at the first load of data in the cube (i.e. it is not defined as long as the cube is empty).

 

The algorithm analyses the entities that are part of the cube structure and depending on the numerosity of entity members, it assigns a MaxItemNr to each entity in that structure. The same entity may be assigned a different MaxItemNr for each different structure where it is present. The optimization therefore relies on the current number of members present in each entity that is part of a structure.

 

In order to automatically obtain the best possible optimization it is a good practice, before loading data in cubes, to load your database entities with a significant set of data that truly reflects the numerosity of each entity (not a subset of data) and then load the cubes data.

When it is not possible to fully load the entities, for example because only a subset of data is available, or because some entities are known to grow significantly over time, then it recommended to manually define the MaxItemNr for those entity. The value of the MaxItemNr should be set to the estimated number of entity members. Note that by default, BOARD will automatically add 20% to the given MaxItemNr so that the entity can grow 20% in excess of the given number without compromising the data integrity.

Saturation%

 

The ratio between the number of members of an entity and the MaxItemNr is the Saturation%. The Saturation% is displayed in the Entities definition (see picture below) and it should always be less than 100%.

 

max1.png

 

The MaxItemNr and Saturation% depends on the number of entities in the structure, therefore an entity used in several cubes having different structures will have a different Saturation of each structure. The cubes where the entity is used and the value of the Saturation% is displayed in the Analysis tab of the Entity definition.

 

max2.png

 

In case the saturation exceeds 100%, the integrity of data in the cubes is no longer guaranteed therefore it is necessary to clear the affected cubes then do one of the following:

 

In case the saturation of is near 100% and it is estimated to grow, it is recommended (before the saturation exceeds 100%) to perform one of the following actions:

 

Note that the MaxItemNr can be changed manually in any moment, to make the change effective, either cleared and reloaded the cubes using the entity or simply run a DB Optimize.

PreAggregated Cube Versions

It is now possible to manually define pre-aggregated versions of a cube in order to improve reporting performance.

To create a pre-aggregated version, open the cube definition, go to the Versions tab, click the Add version (+) button and set the level of aggregation of the version by choosing entities that are more aggregate than the detail version (version 0) or omitting one or more entities of the detail version. Click Save Changes to confirm, the new version is saved and aligned (i.e. populated with data from the detail version).

 

Pre-aggregated versions can only be added if the detail version is populated with data, it can’t be defined if the cube is empty.

When defining a new version, it is normal that some of the entities of the detail version may be pre-selected in the pre-aggregated version and can’t be removed. This applies to entities, generally those with a low number of members, for which a pre-aggregation would not provide performance improvements because the system is already optimized for aggregating that dimension.

 

If a pre-aggregated version is equal to the detail version but with one or more entities omitted (one or more dimensions less) then the alignment of data is always automatically maintained by the system (unlike in Board 10 and earlier versions).

If a pre-aggregated version uses an entity which is a parent of an entity in the detail version, then the alignment of data is automatically maintained only after a DataReader or a Data-entry on the detail version. If a cube containing this type of version is calculated through a DataFlow, then it is necessary to add a Cube Align action after the Dataflow calculation to reconsolidate data.

 

To remove a version, click the Delete All Versions button. Note that it is not possible to selectively remove one version only.

 

Pre-Aggregates on Time Dimensions

 

On cubes dimensioned by Day, it is possible to add one pre-aggregated version by Month by clicking the Monthly Version button. This version will have the same structure of the detail version except for the day-to-month aggregation. Other manually defined versions must all use Day as time entity.

 

version1.png

 

Deep Locker

The DeepLocker extends DataEntry functionality of the DataView object with the ability to lock DataEntry on some cells of a cube based on the value contained in another cube of the same structure or a more aggregate structure. This new function is similar to the existing LockBy (or Loack&Spread) function however it works at the physical level of the cube, therefore it allows to set a lock on cells at a more detail level than the DataView level.

For example, using this function it is possible to create a Dataview at Region and Quarter level and set a data-entry lock on one or more Cities and Months. When the user enters a value at Quarter/Region level, the value is allocated down to the physical cells proportionally however all the physical cells corresponding to locked Cities and Months remain unchanged (the new value is proportionally allocated on the free cells only).

 

To configure the DeepLocker function, go to the DataEntry section of the properties of a data.entry cube of your DataView and set the following parameters:

 deep1.png

Fixes and Minor Changes

This version includes all bug-fixes and minor changes released in version 10.6.1 and 10.6.2, please refer to the online documentation for details. Several important fixes and enhancements have been applied to the DataFlow engine providing now

 

Below the detailed list of fixes included in this version.

 

 

UPDATE (04/05/2020):

The BOARD Server Installer package has been updated. The new installers include a fix for:

- A malfunction on SAP Datareader.

- A malfunction on Datareader when entity code terminates with a dash (-)

- A malfunction in the Data flow calculation has been fixed.

- File extraction: increase the performance of writing to network drivers.

If you downloaded the version prior than 6th March 2020, please download it again and update the BOARD installation on your environments.