Explanation:

A referential join in SAP HANA is used to inherit the complete join definition from a pre-modeled relationship established in a source object like an Attribute View or another Calculation View. It reuses the specific join columns, cardinality, and referential integrity constraints, eliminating redundant configuration and ensuring consistency. The optimizer leverages these known integrity rules for potential performance gains, often executing it as an efficient inner join if foreign key compliance is guaranteed.

Why other options are incorrect:

A (Automate cardinality):
Cardinality is reused, but this is a subset of reusing the entire join configuration.

C (Series of linked joins):
Describes join chaining, a structural pattern possible with any join type, not the specific purpose of a referential join.

D (Ignore unnecessary sources):
Describes join pruning, a runtime optimization that can result from a well-defined referential join but is not its primary design intent.

Reference:
The SAP HANA Modeling Guide states the purpose is to base the join on "a referential integrity relationship that is defined in the source objects," directly enabling reuse (SAP Help Portal, "Creating a Calculation View"). SAP Learning Hub course HA300 emphasizes this as a method to avoid redefining joins.

Explanation:

Shared hierarchies in SAP HANA are reusable hierarchy objects created in the analytic privilege layer, independent of specific models. They enable consistent drilldown behavior across different analytical models.

A. Provide reusable hierarchies for drilldown in a CUBE with star join:
This is correct. A CUBE with star join (a Calculation View of type CUBE that uses a Star Join node) can directly consume a shared hierarchy object for drilldown navigation and hierarchy-aware filtering.

C. Provide reusable hierarchies for drilldown in a CUBE without star join:
This is also correct. A standard CUBE (without a Star Join node) can also utilize shared hierarchies for drilldown operations, as the hierarchy definition is applied at the consumption layer (e.g., in an analytic application or BI tool) rather than being embedded in the model's join structure.

Why the other options are incorrect:

B. Access hierarchies created in external schemas:
This is incorrect. Shared hierarchies are native SAP HANA metadata objects created and managed within the HANA repository. They cannot reference hierarchies defined purely in external database schemas.

D. Enable SQL SELECT statements to access hierarchies:
This is incorrect. Shared hierarchies are metadata objects for analytic consumption (e.g., in SAP Analytics Cloud, Analysis for Office, or SAP BW/4HANA). They are not accessible via standard SQL SELECT statements on database tables or views.

Reference:
SAP HANA Modeling Guide, specifically the sections on "Creating Hierarchies" and "Using Hierarchies in Calculation Views." The documentation confirms that shared hierarchies are repository objects designed for reuse in analytical models (both with and without star schema joins) to provide consistent hierarchy operations.

Explanation:

The Transparent Filter property is used in SAP HANA calculation view nodes (typically in Aggregation or Projection nodes) to enable filter push-down through stacked calculation views. When enabled, filters applied at a higher-level (consuming) calculation view are propagated ("pushed down") to the lower-level (source) calculation view. This is critical for performance, as it allows the filter to be applied as early as possible in the execution plan at the source view's level, reducing the amount of data processed upstream.

The primary use case is in a stacked scenario, where one calculation view (the "top" view) uses another calculation view (the "bottom" view) as its data source. Enabling Transparent Filter on the source node in the top view ensures filters flow through the stack efficiently.

Why the other options are incorrect:

A. Incorrect. The property does not directly prevent incorrect aggregations; that is the role of Corrected Aggregate measures or proper modeling of semantics (e.g., defining attributes).

B. Incorrect. While it improves overall query performance via push-down, it is not specific to the Join Node. It is a property of Aggregation, Projection, and Union nodes.

D. Incorrect. Hidden columns are not intended for filtering by end users. The property does not control this; its purpose is propagation, not ignoring filters.

Reference:
The SAP HANA Modeling Guide ("Optimizing Calculation Views") specifies that the Transparent Filter property "allows filters to be pushed down to the underlying calculation view" in layered modeling scenarios. SAP Notes (e.g., 3231658) and expert modeling documentation reinforce this as the key mechanism for efficient filter propagation in complex view stacks.

Explanation:

To display summarized data by PRODUCT_ID and a calculated column (QUANTITY * PRICE), you must use an Aggregation Node. This node is specifically designed to:
Group data by defined attributes (here, PRODUCT_ID).
Perform aggregations on measures (e.g., SUM(QUANTITY), SUM(PRICE)).

Correctly calculate aggregated expressions: Since QUANTITY and PRICE are individual measures, the calculation PRODUCT_TOTAL = QUANTITY * PRICE must be defined as a calculated column within the Aggregation node itself (or after aggregation) using the aggregated values. If you calculate QUANTITY * PRICE at a row level (e.g., in a Projection) and then sum the result, you would get a mathematically incorrect total if multiple rows exist per product. The correct approach is to sum QUANTITY and sum PRICE separately, then multiply the aggregated results, or use the SUM(QUANTITY * PRICE) expression inside the Aggregation node.

Why the other options are incorrect:

A. Projection:
A Projection node selects, renames, or creates simple row-level calculated columns. It cannot group or aggregate data, so it cannot produce summarized results by PRODUCT_ID.

B. Union:
A Union node is used to combine multiple data sources with similar structures vertically. It does not perform grouping, aggregation, or calculations across rows.

D. Join:
A Join node combines data horizontally from different sources based on a key. It does not perform grouping or aggregation.

Reference:
SAP HANA Modeling Guide, section “Working with Calculation Views.” The Aggregation node is explicitly described as the node used to “define aggregations and groupings for columns.” The rule for calculated measures (like multiplying two summed quantities) must be handled at the aggregated level to ensure accuracy, as emphasized in SAP training materials (e.g., HA300) for calculation view design.

Explanation:

In a CUBE calculation view, join performance is heavily influenced by how effectively the HANA query optimizer can create an execution plan.

A. Specify the join cardinality:
This is correct. Explicitly defining cardinality (e.g., 1..N, 1..1) provides critical metadata to the optimizer. It informs the engine about the expected row relationships, allowing it to choose more efficient join algorithms (like converting an outer join to an inner join) and better execution order.

D. Use an inner join:
This is correct. An inner join is typically more performant than outer joins (left, right, or full). It reduces the result set early by returning only matching rows, allows for more flexible join order optimization, and often enables more efficient join algorithms like hash joins.

Why the other options are incorrect:

B. Limit the number of joined columns:
While limiting the selected output columns in a projection can improve overall query performance, simply limiting the number of columns used in the join condition itself does not inherently speed up the join operation. The join performance primarily depends on the indexed join keys and cardinality, not the count of joined columns.

C. Define join direction in a full outer join:
The concept of "join direction" (left, right) is inherent in left/right outer joins but ambiguous in a full outer join, which by definition returns all rows from both tables regardless of matches. Specifying direction for a full outer join is not a standard optimization technique in SAP HANA; the optimizer handles its execution plan.

Reference:
SAP HANA Modeling and Performance Optimization guides consistently recommend:
Always specify correct cardinality for joins (SAP Help: "Defining Joins in Calculation Views").
Prefer inner joins over outer joins for performance unless business logic explicitly requires non-matching rows (SAP Note 2142945 – "HANA Performance: Join Best Practices").

Explanation:

In SAP HANA modeling, a restricted measure is a specialized calculated measure that applies a fixed, dynamic filter on a base measure using the values of one or more attributes from the model. The filter condition is defined once and becomes an intrinsic part of the new measure's logic. For example, from a base measure Total Revenue, you can create a restricted measure Europe Revenue by applying the filter Region = 'Europe'. This allows analysts to work with logically filtered measures without manually applying the filter in every query, streamlining reporting and enabling side-by-side comparisons (e.g., Europe Revenue vs North America Revenue) within the same view.

The restriction is typically defined in the Semantics node of a Calculation View (type CUBE) or within an Analytic View. It leverages the underlying model’s dimensional structure and is evaluated at query runtime, ensuring the filter is consistently applied regardless of how the measure is used in a visualization or query.

Why the other options are incorrect:

A. Incorrect.This describes authorization-based restrictions governed by analytic privileges. While analytic privileges can restrict data access for users, a restricted measure is a modeling object that defines a business calculation, not a security object.

C. Incorrect. While restricted measures are most commonly used in CUBE-type Calculation Views, they are not inherently restricted from being referenced in or by dimensions. Their usability depends on the model’s structure, not a rule about consumption type.

D. Incorrect. A restricted measure can be referenced by a calculated column or another calculated measure. For instance, you could create a calculated measure Revenue Growth that references a restricted measure Prior Year Revenue.

Reference:
The SAP HANA Modeling Guide (SAP Help Portal, "Creating Measures in Calculation Views") explicitly defines restricted measures as "key figures that are calculated with filter conditions on characteristics." This aligns with the classic SAP BW concept of a "Restricted Key Figure." SAP's training curriculum for the C_HAMOD_2404 exam, specifically in the modeling units, reinforces that a restricted measure applies a static filter on attributes to a base measure.

Explanation:

In an SAP HANA XS Advanced (XSA) project, the .hdiconfig file is used to define which HDI (HANA Deployment Infrastructure) plug-ins are enabled for an HDI container.

HDI plug-ins determine what types of database artifacts (for example, tables, views, calculation views, procedures, synonyms, etc.) can be deployed into the container. Each artifact type is handled by a specific plug-in. If a required plug-in is not enabled in .hdiconfig, deployment of the corresponding artifact will fail.

In short, .hdiconfig controls the capabilities of the HDI container by enabling or disabling specific deployment plug-ins.

❌ Why the Other Options Are Incorrect

A. To specify in which space the container should be deployed
This is incorrect because Cloud Foundry spaces and deployment targets are defined in files like mta.yaml and managed by the platform, not by .hdiconfig.

B. To specify an external schema in which calculation views will get their data
External schemas and cross-container access are defined using HDI containers, service bindings, and synonyms (often via .hdbgrants or .hdbsynonym), not in .hdiconfig.

D. To specify the namespace rules applicable to the names of database objects
Namespace rules are defined in the .hdinamespace file, which controls how object names are prefixed or structured within the HDI container. This is a different configuration file with a distinct purpose.

References
SAP Help Portal – HANA Deployment Infrastructure (HDI)
SAP Help Portal – HDI Container Configuration Files

Explanation:

In SAP HANA calculation views, the parameter mapping feature allows you to map input parameters from a source calculation view to input parameters of a target calculation view. For the parameters of calculation view B to be proposed as source parameters, the parameter mapping TYPE must be set correctly (for example, Input Parameter → Input Parameter).

If the wrong mapping type is selected (such as mapping a variable or column instead of an input parameter), the editor will not display the input parameters of calculation view B as available source parameters. This is a common modeling issue and is directly related to how parameter mapping types control parameter visibility in the calculation view editor.

❌ Why the Other Options Are Incorrect

A. The names of the input parameters do not match.
Parameter names do not need to match for mapping. You can map parameters with completely different names as long as the data types are compatible.

C. Your source calculation view is of type DIMENSION.
Calculation views of type DIMENSION can still expose and consume input parameters. The view type does not prevent parameters from being proposed during parameter mapping.

D. You already mapped the input parameters in another calculation view.
Input parameters can be reused and mapped in multiple calculation views. Existing mappings elsewhere do not block parameters from appearing in the mapping editor.

References
SAP Help Portal – SAP HANA Calculation Views: Input Parameters
SAP Documentation – Parameter Mapping in Calculation Views

Explanation:

The Keep Flag property in an aggregation node is used to force the inclusion of a specific column (typically an attribute or a measure used in a calculation) in the result set of the aggregation, even if the query does not explicitly request that column. This ensures that any dependent calculations, filters, or downstream logic that rely on that column will work correctly.

The primary use case is when you have a calculated column in the aggregation node (e.g., Profit = Revenue - Cost) that depends on two or more base measures (Revenue and Cost). If a query only selects the calculated column Profit, the optimizer might exclude the base measures Revenue and Cost to improve performance. However, this would break the calculation. Setting the Keep Flag on Revenue and Cost forces them to be included in the intermediate result so Profit can be computed accurately.

Why the other options are incorrect:

A. This is the opposite of the Keep Flag’s purpose. The property includes columns, it does not exclude them. Excluding unnecessary columns is standard optimization behavior.

B. This describes a Fixed property or aggregation type setting, not the Keep Flag. The Keep Flag does not lock aggregation behavior; it controls column retention.

D. While it helps maintain correct behavior in stacked views by ensuring required columns are present, the specific purpose is forcing column inclusion, not directly retaining "aggregation behavior."

Reference:
The SAP HANA Modeling Guide (section “Optimizing Calculation Views – Using the Keep Flag”) explicitly states: “The Keep Flag ensures that a column is retained in the output of the node, even if it is not requested in the query. This is useful for calculated columns that depend on other columns.” This is a standard performance and accuracy technique in SAP HANA calculation view design.

Explanation

In SAP HANA calculation views, the property “Ignore multiple outputs for filters” is used to handle situations where a filter condition may be evaluated multiple times because a calculation view node produces more than one output (for example, multiple joins, unions, or shared sub-nodes).

When this property is enabled, SAP HANA ensures that filters are applied in a semantically correct way, avoiding unintended or ambiguous filter behavior caused by multiple output paths. This is especially important in complex models where the same filter could otherwise be applied inconsistently, leading to incorrect analytical results.

In short, the setting exists to preserve the correct business semantics of filters, not to optimize layout or hide data.

❌ Why the Other Options Are Incorrect

B. To avoid duplicate rows in the output
Duplicate rows are typically caused by join cardinality issues or union logic, not by filter evaluation across multiple outputs. This property does not perform deduplication.

C. To force filters to apply at the lowest node
Filter push-down behavior is managed automatically by the optimizer and by node-level filter definitions. This property does not control where filters are physically applied in the execution plan.

D. To hide columns that are not required
Column visibility is controlled in the Semantics node (hidden columns, attributes, measures). The filter property has nothing to do with column exposure.

📚 References
SAP Help Portal – SAP HANA Calculation View Properties
SAP HANA Modeling Guide – Filter Processing in Calculation Views

Explanation:

When you create a new CUBE-type calculation view in the SAP HANA Modeler (either graphical or in the web-based Calculation View editor), the default and top-most node automatically generated is a Projection node. This initial Projection node serves as the entry point and primary interface for the view's semantics. All subsequent nodes (joins, unions, aggregations) are placed underneath this default Projection node. The final output structure, including measures, attributes, and hierarchies, is defined in the Semantics layer, which sits logically above this top Projection node.

Why the other options are incorrect:

B. UNION:
A Union node is used to merge multiple data sources, but it is not the default starting node.

C. HIERARCHY:
A Hierarchy node is explicitly added to create or consume hierarchies; it is never the default top node.

D. AGGREGATION:
While a CUBE view is analytical and typically includes aggregation, the default top node is a Projection, not an Aggregation. Aggregation nodes are added manually as needed under the Projection.

Reference:
This is standard behavior documented in the SAP HANA Modeling Guide and observed in the SAP Web IDE for SAP HANA / SAP Business Application Studio. The interface automatically creates a Projection node as the root when selecting "CUBE" as the view type. SAP training materials for data modeling (e.g., HA300) confirm that the graphical editor defaults to a Projection node at the top of the node pane for CUBE views.

Explanation:

A. Break up large statements by using variables
Using variables in SQLScript helps improve readability, maintainability, and debugging of complex logic used inside calculation views (for example, in table functions or scripted calculation view nodes). Breaking large statements into smaller logical steps makes the code easier to understand and optimize, which is a recommended best practice in SAP HANA modeling.

D. Choose declarative language instead of imperative language
SAP strongly recommends using a declarative SQL style (set-based operations like SELECT, JOIN, UNION) rather than imperative constructs. Declarative SQL allows the HANA optimizer to determine the most efficient execution plan, leading to better performance and scalability, especially when SQLScript is consumed by calculation views.

❌ Why the Other Options Are Incorrect

B. Use dynamic SQL
Dynamic SQL prevents the optimizer from fully analyzing and optimizing the execution plan at design time. It also reduces performance predictability and is not recommended for calculation views unless absolutely necessary.

C. Control the flow logic using IF-THEN-ELSE conditions
While SQLScript supports control-flow logic, heavy use of imperative constructs like IF-THEN-ELSE can limit optimization and reduce performance. SAP recommends minimizing such logic in favor of declarative, set-based processing.

📚 References
SAP Help Portal – SQLScript Best Practices
SAP HANA Developer Guide – Declarative vs Imperative SQLScript