Intro
Changed Requirements for modern Data Warehouse Systems mean that aspects such as Simplicity, Flexibility and Agility are becomming more important and therefore should be considered in the architecture and modeling of such systems.
With its data warehouse product, SAP BW4 / HANA, SAP offers the possibility of implementing such modern architectures beyond a rigid and outdated Layered Scalable Architecture (LSA). SAP recommends an architecture that is based on the LSA ++. This new layer approach is particularly characterized by the focus on virtual objects. Virtualization means that fewer copies of data are required between layers of architecture, making their design simpler, smaller and faster. The data warehouse architecture should be designed as lean and simple as possible.
See also: Agile Data Warehousing with SAP BW/4 HANA
Virtualization of master data
An essential factor in the design of such a flexible architecture is the modeling and use of master data.
The classic modeling in the BW environment of master data as InfoObjects (used directly in the persistent transaction data) ensured a high level of reuse and consistency, but also means that the semantics in the evaluation are already firmly linked to the transaction data (“Classic Star Schema “). Flexibility and agility are therefore much more difficult to achieve.
With HANA and the composite provider, the “Dynamic flexible Star Schema” has come. The semantics of the data for the evaluation can be defined independently of the source in the composite provider. The star schema is no longer defined by persistent objects, but only virtually by a composite provider or OpenODS view (the underlying Info Provider maybee even only consist of fields instead of Info Objects). InfoObjects, i.e. further descriptive information and semantics, can be added virtually (“associated”) if required.
Another variant is to replace InfoObjects with OpenODS Views (OOV). The master data can be virtualized through the OOV. The master data, which is provided via an OOV, can be modeled field-based – info objects are not necessary. In addition to BW own (aDSO) and HANA native sources (HANA Calculation View), sources of an OOV can also be systems connected via Smart Data Access (SDA). In this case, the SAP BW itself does not hold any master data.
The “Dynamic flexible Star Schema” changes the modeling of a SAP BW significantly. It is now possible to (dynamically) add further information to the star schema as required without having to completely model dimensions and master data from the scratch. Instead, a data model can be iteratively and demand-oriented (further) developed, which significantly increases the agility and flexibility of such a data warehouse.
In this article, the possibilities and restrictions for virtual master data modeling and use (via association in the composite provider) are to be examined in more detail.
Modeling Master Data
In the dynamic flexible star schema there are several options for modeling the master data:
1) Modeling of the master data as (capsuled) InfoObjects
The InfoObject represents a (maybe only part of) business entity that is self-contained, capsuled and reusable by the InfoObject. In principle, the InfoObject models an independent dimension in the Star schema.
Such an InfoObject has the following properties:
- Models a full dimension of the star schema
- Provides different semantics for a key value: descriptive attributes, texts, hierarchies
- Has few or no links to other dimensions
2) Modeling of the master data as satellite Info Objects with a link Info Object (“Snowflaking”)
The possibility of using transitive navigation attributes makes it possible to model master data as satellite Info Objects.
Here, similar to modeling in the Data Vault model, separate facts are also modeled separately, and only connected to one another by a link Info Object. Instead of, for example, pressing all the descriptive characteristics of a customer into an InfoObject “customer” (and accepting that some attributes are sparsely occupied or that keys have to be harmonized to a common data type), modeling as individual satellites would be “industrial customers” and “Private customers” are conceivable, each of which has different, individual attributes and is only connected via a “customer base” link object. Different data types for the primary keys of industrial and private customers are not a problem (as long as there is overall uniqueness).
Such an InfoObject has the following properties:
- Models and connects several dimensions in the star scheme (“Snowflaking”)
- Provides different semantics for a key value: descriptive attributes, texts, hierarchies
- Link object can be flexibly expanded to include additional satellites. The “removal” of a satellite, on the other hand, is only possible with difficulty (remove the transitive attribute “industrial customers” from the link info object)
- Satellites can be flexibly expanded to include additional attributes, but cannot themselves contain satellites again (more than 2-level transitive attributes cannot be mapped with InfoObjects)
3) Modeling of the master data as openODS Views
Modeling of master data as (field-based) OpenODS views does not require an InfoObject. This means that any data can be made available quickly and easily as a reusable master data dimension. In the simplest case, the OOV refers 1:1 to an aDSO and is linked to it. Master data connected remotely can also be modeled in SAP BW in this way.
In my opinion, however, the full potential only arises through mixed modeling, in which the OOV is based on a HANA calculation view. Complex snowflaking across several levels and any satellites (more than 2-level transitive attributes) are possible through the use of HANA calculation views (to join the corresponding basic data). In addition, OpenODS views offer the option of making the same master data available for association via different key values without redundant persistence.
Such an OpenODS view has the following properties:
- Models and flexibly connects several dimensions in the star schema (“Snowflaking”)
- Field-based, no need to create InfoObjects
- Provides different semantics: descriptive attributes, texts
- Provides the same master data flexibly via several keys
- Can be flexibly expanded to include additional attributes and satellites, via calculation views in any depth (more than 2-level transitive attributes). Virtualization also makes you more flexible if attributes are to be removed.
These master data are used in each case via association with the corresponding transaction data. This is done in the composite provider.
Association with Composite Provider – Opportunities and Limits
In BW / 4HANA 2.0, version SPS01 (in newer SPs the behavior might be different), some restrictions must be observed for such master data models:
- In the case of an association with InfoObjects, only those attributes of the InfoObject are available in the generated calculation view of the composite provider that have already been declared as “navigation attributes” in the InfoObject.
The use of display attributes from InfoObjects is only possible on the BW side via association in a field-based data model, but not on the HANA side – in this case the InfoObject must be used directly in the persistence layer (as in the classic star schema modeling). - No 2-level association – a Nav-attribute entered via association cannot itself be associated with something again.
Even the modeling UI in Eclipse does not even offer the possibility of a further association for navigation attributes.
However, this can be avoided (at least for the provision on the BW side) by first associating the transaction data with the master data with an OpenODS view of the “Facts” type.
If this OpenODS view is used in a composite provider, the attributes (entered via the fact OOV) can also be associated with InfoObjects again.
However, this does not work if HANA CalcViews are then generated on the composite provider for HANA-side consumption (warning RS2HANA_VIEW151: “Navigation attribute is excluded from the external SAP HANA view”). The fields obtained via this indirect association are then not included in the generated CalcView. - The BW reporting preview on the composite provider in Eclipse does not display the navigation attributes recorded via association.
However, they are available in the BW Cockpit preview and via the front-end tool (AfO, SAC). - The data type must be exactly compatible, otherwise the association fails at the time of activation (error message) or at runtime (no data). This includes the basic data type (CHAR, NUMC, …), the length and the alpha conversion.
- Association with compound InfoObjects is only possible to a limited extent. Basically, an association can only be carried out using a unique field; composite keys are not possible. This applies to OpenODS views as well as InfoObjects. As an exception, however, a compound InfoObject (e.g. 0COSTCENTER) can also be associated if the compounded object (here: 0CO_AREA) is already available as an InfoObject at the moment of association (i.e. in the composite provider or a fact OOV). This exception is not possible for an OpenODS view.
- For the association, you can generally choose between “direct use” and “system-wide unique name” (for both InfoObjects and OpenODS views).Basically:With direct use, the name of the OOV or InfoObject that is associated with is used as the technical name:
Original field name KST, associated with InfoObject 0COSTCENTER → technical name in the composite: 0COSTCENTER
Therefore only a single field can be associated with the OOV or InfoObject.
For example, if the data model contains the fields “Sending cost center” (SKST) and “Receiving cost center” (EKST), it is not possible to associate both directly with 0COSTCENTER, as this would result in double technical names.When using the “system-wide unique name” an artificial technical name is generated which contains the name of the composite provider and the field:
Original field name KST, associated with InfoObject 0COSTCENTER, composite ZTEST → technical name in the composite: 4ZTEST-KST
This means that several fields can be associated with the same InfoObject or OpenODS View.
In that case, however, there would be potential name collisions with the navigation attributes, since the same attributes can then be used via both associations, for example 0COMP_CODE.
The technical names of the navigation attributes are therefore added: 0COMP_CODE, 0COMP_CODE_0, 0COMP_CODE_1 etc. This can be confusing and confusing, especially in the HANA-side CalcView, if no further distinction is made using the description!Special Info Objects:
InfoObjects with navigation attributes can usually be easily associated with both direct use and unique names.
InfoObjects with transitive navigation attributes (“Link InfoObject with satellites”) can only make their transitive attributes available if:
A) The link info object is already included as an info object in the transaction data. In this case, the transitive navigation attributes of the satellites are available in CalcView on both the BW side and the HANA side.
B) The link info object is associated in the composite proivder. In this case, however, the transitive navigation attributes of the satellites are only available on the BW side. The attributes are not available in the HANA-side CalcView.
C) The link info object is first associated in a fact OpenODS view, which then flows into a composite provider. In this case, the transitive navigation attributes of the satellites are available both on the BW side in the composite provider and on the HANA side in CalcView.
Special OpenODS views:
Master data OpenODS views can cause problems when using the unique name. This manifests itself in the error message “Navigation attributes are not supported” during activation.
In this case, use via “direct use” is mandatory.
This restriction already exists on the BW side, i.e. it is independent of whether the consumption takes place via the HANA-side calculation view or via the BW Composite provider.
→ As a consequence, this means that an OpenODS view can only be associated with a composite provider once.
This restriction has probably no longer existed since the SPS02 of BW / 4 2.0; an association using the unique name is usually also possible with OpenODS Views, so that scenarios such as “Sending Kst” / “Receiving Kst” with multiple associations with the the same OpenODS view can be implemented.
The association with fact OpenODS views is generally not possible.
- Master data OOV with semantics “Text” when consuming in HANA CalcViews.
Master data OOVs can provide text as well as navigation attributes.The field associated with such an OOV then has semantics comparable to that of an InfoObject, i.e. In reporting, you can toggle between displaying the field content as “key”, “text” and “key + text”.
Initially, however, this only works on the BW side when reporting to the composite provider directly, or using a query on the composite provider. The generated HANA Calculation View does not have these semantics, i.e. the added value of the association with the text OOV is lost in the case of consumption on the HANA side.
As a workaround, however, it is possible to give the OpenODS view the attribute semantics in addition to the text semantics and to add the corresponding text field as an (additional) navigation attribute for the association. Subsequently, an assignment of the text field to the key field is necessary on the HANA side (“label”). This means that you can dynamically switch between display as text and key in the Analytics Frontend on the HANA CalcView.
CONCLUSION
A modern architecture is essential for the enablement of agile data warehousing. The flexible master data modeling using the Dynamic Flexbile Star schema and techniques such as snowflaking using link-and-satellite modeling are indispensable tools.
However, this makes the world of BW-centric data warehouse modeling a bit more complex, and the range of possible variants increases. It is correct that with BW / 4HANA the topic of “simplification” is cited as a major benefit on the part of SAP. In terms of simplifying the number of objects to a few, this is also true. However, there is significantly more freedom in use and thus opportunities in implementation.
It is therefore more important to consider the basic architecture and modeling approaches at an early stage in the design process, to know exactly the effects and restrictions and to evaluate which best fit to the requirements.
It is important to note here that no approach (InfoObject-based modeling, InfoObject-based link satellite modeling, field-based modeling with Snowflaking CalcViews and OpenODS Views) is fundamentally superior to another, and therefore there is also no serious general recommendation for or against a modeling – the opportunities and limitations differ from scenario to scenario and are to be assessed individually, ideally with the assistance of a solution architect.
This article has also been published in german under this link.
Okumaya devam et...