Managed Data Mashups

Data Store to Data Store Joins
- Complex Joins Across Packages
- Creating Inherited Sources Based on Parent Dimensions and Facts in a Child Space
Joining Live Access with a Data Store
Multilevel Network BI
Examples
Next Steps

Managed Data Mashups are composite spaces that give users access to source data from more than one space.

Tip: Managed Data Mashups using Packages is an add-on feature. To see the Packages tab the account must be enabled for the feature. To enable it for your account contact your Infor Representative. For Appliances, see the Community article Birst Account Feature Provisioning.

Space Administrators can set them up and provide business users with all the data required to make informed business decisions. Use managed data mashups when:

You need to blend both centralized and decentralized data.
You need a modular approach to designing an analytics application.
You want to mix and match data that has different levels of access control and security.
Users want to share data across Birst spaces.
You are an OEM and you need a master space for your multi-tenant environment.

You can blend data residing in a shared user data store (parent space) with data in another space (child space). You assemble logical model metadata in the parent space into packages that are then shared with child spaces. Another way to think about it is that you export a view from a space that can be shared, and then import the view into other spaces and combine it with data there.

Data is not moved between spaces.

The tables in the child space must be able to join to tables in the parent space.

The child space contains the reports and dashboards that use the composite data from both spaces.

A key design principal is that nothing in the child space can alter the parent space. For example, if metadata is exported from a space to be used by other spaces, that parent space is not affected by anything that happens in a child space. Additionally, all augmenting of data should be initiated in the child space in order to keep the parent space unaltered.

Data Store to Data Store Joins

Joins are a critical component of Managed Data Mashups. A key design principle of data store to data store joins is that data from the parent space and the data from the child space are both in the same underlying database such that joins can occur at the lowest levels possible. There are two types of these joins:

A child fact joined to a parent dimension. See To join a child fact to a parent dimension and Child Fact to Parent Dimension Join Example.
A child dimension joined to a parent fact. See To join a child dimension to a parent fact and Child Dimension Joined to a Parent Fact Example.

Implementation Notes

It must be possible to create joins between the data sources. Requirements include:

Only level keys can be part of the equi-join conditions.
Data types must be the same. However, column names can be different.
Only spaces on the same database instance can be joined. To determine whether there are multiple database instances:
- If you are an Appliance customer check with your operations team.
- If you are a Cloud customer check with your Infor representative.
While ideally the parent data source requires no changes, there may be situations where you need to create keys in a parent data source to enable joins with child data.

Additional implementation notes include:

Both the parent space and child spaces must be Advanced type spaces.
A child space cannot modify the metadata imported from a parent space, it can only consume it.
The security of a Custom Subject Area in a parent space is not extended to its child space.
You can import more than one package to a child space.
For example, both a package from a Products space (containing the Products.Products dimension and Products fact) and a package from an Orders space (containing the Orders.Orders dimension and Orders fact) can be imported and joined to a child space that has the Order.Details source.
A child space that has imported a package cannot pass that package on to another child.

User group security filters and exemptions defined on the parent space are honored by the child space in a Managed Data Mashup. If the security exemption on the child space does not include a particular user, and the user does have the security exemption on the parent space, the exemption applies.

Space with Security Filter	Space Shared with Another User	Group Exemption on Space	Security Filter Applied/Exempted
Parent	Parent		Applied
Parent	Parent	Parent	Exempted
Parent	Child		Applied
Parent	Child	Parent	Exempted
Parent	Child	Child	Exempted
Parent	Parent and Child	Parent	Exempted on Parent space, Applied on Child space
Child	Child		Applied on Child space, Exempted on Parent space, Applied if Parent and Child attributes are queries
Child	Child	Child	Exempted

Complex Joins Across Packages

Joining across imported packages is a useful technique for reusing centralized or canonical data that resides in multiple parent spaces. You can import attributes or measures from multiple parent spaces and define the join between them in the child space. This functionality is supported for data store to data store joins as well as discovery source to discovery source joins.

See Parent to Parent Joins.

Creating Inherited Sources Based on Parent Dimensions and Facts in a Child Space

You can create inherited sources in the child space from warehouse dimensions or facts imported from the parent space.

The following scenarios are supported:

Importing a fact and a dimension from different parent spaces, creating inherited sources based on them and joining them using a complex join.
Importing a fact from a parent space and uploading a dimension to the child space, creating inherited sources based on them and joining them using a complex join.
Importing a dimension from a parent space and uploading a fact to the child space, creating inherited sources based on them and joining them using a complex join.

Joining Live Access with a Data Store

In addition, a Live Access source can be joined to a Birst data store (warehouse). This scenario is supported for Appliance spaces where the Live Access source is located on the same database instance as the Birst data store. See Child Data Store Source to Parent Live Access Source and Child Live Access Source to Parent Data Store Source.

Tip: Starting with 5.20.4, for Live Access sources modeled in Manage Local Sources, in the child space use Manage Local Sources – Joins – Add Join to create a join between a child dimension and parent fact, and/or between a child fact and a parent dimension.

Multilevel Network BI

With the 5.30 release, it is now possible to create networks that span beyond two levels. Prior to the 5.30.3, Network BI could only work across two levels (parent/child). A requirement to create a consumption layer that can re-use existing Parent/Child network relationships (created in existing Networked spaces) drove the development for Birst Spaces to understand how to re-use these established Parent/Child Network relationships.

You can now create a Parent dimension package in a space, and import this Parent dimension package into a Child Fact space where their relationship can then create (grained or complex joins)a dimension fact relationship. This relationship established in the child fact space can now be recognized outside in any other space (grandchild space) that imports the original Parent dimension package and the original Child Fact package.

Note: Multilevel Networking is currently available for ADR based spaces only. You cannot employ this feature in Modeler based spaces at this time. `

The following diagram helps to illustrate how this new offering works:

Examples

See the examples at:

Next Steps

To share data, use Admin - Customize Space - Packages to create a Birst package from the parent space and import it to the child space or spaces. See Creating a Package.