Learn, Practice, and Improve with SAP C_BW4H_2505 Practice Test Questions

Explanation:

Before a Cube (Star Join) Calculation View can reference a Dimension Calculation View, the Dimension view must exist and be activated. Only after the Dimension is built can it be included as a star join in the Cube view.

Why the other options are incorrect

B. Create and build the HDI Calculation View (Cube with Star Join): The Cube view depends on the Dimension view; creating it first would fail due to missing dependencies.

C. Create a synonym for the Cube with Star Join: Synonyms are only required for cross-container or external access; both views are in the same HDI container, so no synonym is needed first.

D. Create a synonym for the Dimension: Synonyms are only required for access from outside the container; within the same HDI container, the Cube can directly reference the Dimension view.

References:

SAP Help Portal: “SAP HANA Modeling – Calculation Views” – explains that Dimension views must be activated before being used in Star Join Cube views.
SAP Notes: HDI Container modeling best practices: Dimension views provide reusable structures for Cube/Fact views within the same container.

Explanation:

The "Data Mart DataStore Object" modeling property in an Advanced DSO (ADSO) is a specialized setting designed for staging and intermediate data storage within a data flow, particularly where you need to report on the data before activation.

Here are the two key behaviors this property enables:

A. The records are treated as if all characteristics are in the key.
This means no aggregation or consolidation happens during activation. Every record in the inbound table is treated as unique. This is crucial for data mart scenarios where you need to preserve every detail from the source for interim reporting or further processing.

B. Reporting is done based on a union of the inbound and active tables.
This is the defining feature of a Data Mart ADSO. A query on a CompositeProvider that includes this ADSO will show a real-time union of:
New data still sitting in the inbound table (not yet activated).
Historical data already in the active (reporting) table.
This provides near real-time reporting capabilities on the data flow.

Why the Other Options Are Incorrect:

C. Query results are shown only when data has been activated.
This is false and actually describes the behavior of a standard ADSO without the Data Mart property. The whole purpose of the Data Mart property is to allow reporting before activation via the union behavior.

D. The change log table will be filled only after data activation.
This is false. The change log table is filled during the activation request, not after. It records the delta (changes) that are moved from the inbound table to the active table. This behavior is consistent for all ADSO types where the change log is enabled and is not specific to the Data Mart property.

Reference:

A Data Mart ADSO acts as both a persistent staging area and a reportable object. It bridges the gap between ETL processing and business reporting.

Explanation:

A. Reference characteristic
A Reference Characteristic (e.g., using 0COSTCENTER as a template for a custom characteristic ZRESP_CC) does not have its own master data or text tables. Instead, it points to the tables of the referenced InfoObject.

Storage Benefit: Since it reuses the base InfoObject's master data, texts, and hierarchies, no additional physical storage is needed for these records.

Use Case:
Ideal when you have different business roles for the same data (like "Sold-to Party" and "Ship-to Party" both referencing "Customer").

B. Transitive attribute
A Transitive Attribute allows you to access an attribute of an attribute (e.g., Employee -> Department -> Manager) without physically storing the "Manager" directly on the "Employee" record.

Storage Benefit: It acts as a "virtual join" at runtime. You do not need to load and store the manager's ID in the Employee’s master data table; the system simply navigates from Employee to Department and then reads the Department's attributes to find the Manager.
SAP BW/4HANA Feature: This is part of the "LSA++" philosophy of reducing redundancy.

Why the others are incorrect:

C. Compounding characteristic:
Compounding actually increases the key length and complexity of the physical tables. For example, compounding "Cost Center" to "Controlling Area" ensures uniqueness, but it forces the system to store both keys in every record where that Cost Center is used. It is a logical requirement for uniqueness, not a storage-saving feature.

D. Enhanced master data update:
This is a performance and management feature introduced in later versions of BW/4HANA (supporting parallel processing, request-based loading, and rollbacks for master data). While it makes data management more efficient, its primary goal is speed and reliability of the update process, not the reduction of physical disk space.

Explanation:

A. Display attributes
✔ Correct. If an attribute is time-dependent (e.g., an employee’s department assignment changes over time), the key date determines which value is shown in the query.

B. Basic key figures
❌ Incorrect. Key figures (like sales amount, revenue, quantity) are not directly affected by the key date. They are transactional values and are aggregated based on filters, not validity periods.

C. Time characteristics
❌ Incorrect. Time characteristics (like calendar year, fiscal period) are structural elements. They are not influenced by the key date; instead, they are used to slice or filter data.

D. Hierarchies
✔ Correct. Time-dependent hierarchies (e.g., organizational structures that change over time) are evaluated based on the key date. The query shows the hierarchy valid at that date.

E. Navigation attributes
✔ Correct. Like display attributes, time-dependent navigation attributes (e.g., region of a customer valid at a certain date) are controlled by the key date.

Reference:
SAP BW/4HANA Query Designer documentation explains that the key date affects time-dependent attributes and hierarchies, ensuring queries reflect the correct values valid at that point in time. See SAP Help Portal: Key Date in Queries (help.sap.com in Bing) (bing.com in Bing).

Explanation:
The start process initiates the execution of a process chain. Each process chain can have only one start process, and it is the only process that can be scheduled independently, without requiring a predecessor process to trigger it.

Why the other options are incorrect:

B. It can be a successor of another process: This is incorrect because the start process is always the first process and cannot have predecessors.

D. It can be left out when the process chain is embedded in a meta chain: Incorrect because even in meta chains, the start process is required to trigger the embedded chain; it cannot be omitted.

References
SAP Help Portal: “SAP BW/4HANA Process Chains – Overview and Best Practices” – describes the start process as mandatory, unique, and schedulable without predecessors.
SAP Press, “Data Warehousing with SAP BW/4HANA”, Chapter 8: highlights the special role of the start process in initiating process chains.

Explanation:

In SAP S/4HANA (and earlier SAP ECC systems), generic DataSources are custom extractors that use an extraction structure and a user-defined ABAP function module to fetch data. For delta (change data capture) functionality, specific technical fields are required to track and identify new or changed records.

The three standard delta-specific fields for generic DataSources are:

B. Request ID
– A unique identifier for the data extraction request. It helps track which records belong to which load cycle.

C. Numeric pointer
– A sequential number (like a high-water mark) that tracks the last extracted record, ensuring the next delta extraction picks up only new or changed records.

E. Time stamp
– Records the exact date and time a record was created or changed. This is often used as a delta mechanism by comparing the timestamp against the last extraction time.

Why the Other Options Are Incorrect:

A. Calendar day
– This is a standard date field that can be part of the extraction structure, but it is not a system-defined, delta-specific technical field. It is business data.

D. Record mode
– While this sounds like a delta-relevant field (indicating insert, update, delete), it is not one of the standard delta-specific fields for a generic DataSource. In certain BW/4HANA or SAP BW contexts, a "Record Mode" field is used in transformations or data transfer processes, but it is not a standard delta field at the S/4HANA generic DataSource extraction level.

Reference
Generic DataSources rely on these delta fields to manage incremental data loads.
The delta mechanism must be explicitly programmed in the ABAP function module to populate these fields correctly.

Explanation:

A. Transaction RSORBCT (Data Warehousing Workbench: BI Content) in the SAP BW/4HANA system

❌ Incorrect. RSORBCT is used in the BW system to install BI Content objects (InfoObjects, InfoCubes, etc.). It does not activate ERP-side DataSources.

B. Transaction RSA5 (Installation of DataSource from Business Content) in the SAP ERP system
✔ Correct. RSA5 is the transaction used to activate standard (Business Content) DataSources in the ERP system. For example, the FI_GL_14 DataSource is delivered but inactive by default — RSA5 is where you activate it.

C. Transaction RSA2 (DataSource Repository) in the SAP ERP system
✔ Correct. RSA2 allows you to check and manage active DataSources in the ERP system. After activation in RSA5, you can verify and maintain them in RSA2.

D. Transaction RSDS (DataSource Repository) in the SAP BW/4HANA system
❌ Incorrect. RSDS is used in BW/4HANA to manage DataSources inside BW, but it cannot activate ERP-side DataSources.

Reference:
SAP documentation confirms that RSA5 is used to activate delivered DataSources from Business Content, while RSA2 is used to display/manage active DataSources in ERP. See SAP Help Portal: DataSource Management in ERP (help.sap.com).