Function Before Integration or Integration Before Function
The preceding figure compares the traditional InfoObject based modeling approach with a field-based modeling approach. The main idea of the field-based modeling approach is that you do not have to create SAP BW/4HANA InfoObjects for all fields of your data sources.
The left-hand side of the figure shows the classical, InfoObject-based SAP BW/4HANA philosophy, where integration occurs before business functions are applied. Integration means the assignment of InfoObjects, which are used to harmonize and integrate data from different sources, and to add meaning (also known as semantics) to the data. These semantics are defined by the InfoObject's list of possible values, key definition, or attributes, or by referenced units or currencies.
Then, after assigning the InfoObjects, you model functions such as applying a filter, or calculating new values. For example, you can read from the master data of an InfoObject in a transformation or apply a currency conversion in a Query. This guarantees both high-quality data and a high level of standardization.
The right-hand side of the figure shows the simplified, immediate modeling used in the field-based approach (where function modeling occurs before integration). This approach is based on defining a minimal amount of meaning (semantics) for the data. You can execute a Query immediately without creating any InfoObjects, staging, and so on. This minimalist approach allows you to apply business functions to raw data before integration, and provides immediate answers to urgent questions. However, the quality of the data depends on your source. The central object for field-based modeling is the Open ODS View and its persistent version, the DataStore Object (advanced).
However, the CompositeProvider, the DataStore Object (advanced), and the Open ODS View allow you to mix the field-based approach (where modeling occurs before integration) and the InfoObject-based approach (where integration occurs before function modeling). SQL views always follow the field-based approach.
Considerations:
InfoObjects are required for:
- InfoObject attributes or hierarchies.
- Validity characteristics of non-cumulative key figures.
- Key figure exception aggregation.
- Planning scenarios.
Modeling InfoObjects brings more effort, but offers several advantages such as attributes, hierarchies, texts, analysis and authorizations.
When deciding to model with fields rather than with InfoObjects, consider how much of the flexibility of fields you really need, and which InfoObject functions you can do without.
For the reporting on the DataStore Object (advanced) or CompositeProvider, fields are directly visible only under certain conditions. For details see SAP Note 2185212.
Fields are displayed in the CompositeProvider or Query with the generated name 4<InfoProvider>-<field name>.
Recommendations:
Model central master data objects using persistent InfoObjects. With many OLAP functions, this offers you advantages in terms of reusability and performance.
In the entry layer in the data warehouse however, where there is little need for OLAP functions, using fields only can enhance the flexibility and range of the data warehouse. See also SAP Note 2949412.
