Key Concepts Refresher

In Chapter 4, we looked at modeling concepts, and in Chapter 5, we examined SAP HANA modeling tools. Now, it’s time to put them together, implementing the modeling concepts with the tools to create SAP HANA information views.

There are three types of SAP HANA information views, which we briefly covered in Chapter 4. First are dimension views, the master data in the system. Second, star join views let you build cube-like information models. Third, calculation views of type cube let you build enhanced multidimensional data structures and information models.

[»] Reminder!

We refer to calculation views of type dimension as dimension views and to calculation views of type cube with star join as star join views. The last category is called calculation views of type cube.

The older SAP HANA systems had attribute views (for dimension views), analytic views (for star join views), and calculation views.

The last category can cause some confusion, because many people and web pages still refer to the last category simply as calculation views.

In this book, we use the latest official name—calculation views of type cube—because that’s what they’re referred to in the SAP HANA SPS 11 certification exam. We use the name calculation views to refer to all three types of calculation views.

In this chapter, we start by briefly reviewing the different types of data sources that can be used be information views. We then dive into the creation process for the different calculation views before discussing the various types of nodes you’ll encounter, including the semantic node. We then review and compare attribute views and calculation views of type dimension and analytic views and calculation views of type cube with star join. We round out the section by walking through the migration tools available in SAP HANA SPS 11 for attribute and analytic views.

Data Sources for Information Views

SAP HANA information views can use data from a wide variety of sources. We will discuss some of the data sources in later chapters, so don’t worry if you don’t yet know what all of them are. The main data sources are as follows:

Calculation Views: Type Dimension, Type Cube, and Type Cube with Star Join

As of SAP HANA SPS 10, you’ll mostly create calculation views. Attribute and analytic views are only used in a few exceptional cases for functionality that is not yet available in the calculation views.

Existing attribute and analytic views will still work as they always did, but it is not recommended to use them in any new SAP HANA modeling work. As you’ve seen, the SAP HANA web-based development workbench only supports graphical editing of calculation views.

The aim is to do as much modeling work as possible with graphical calculation views. As SAP HANA has matured, there has been less emphasis on writing code when creating information models. The new focus typically is on keeping the entire modeling process graphical.

As previous discussed in Chapter 4, there are now three different types of calculation views:

In this section, we will walk through the steps for creating these calculation views.

Creating Calculation Views

You create calculation views in the Content area of the Systems tab in SAP HANA studio. Select the package or subpackage in which you want to create the calculation view and right-click it. You’ll see a context menu like the one shown in Figure 6.1.

Figure 6.1 Context Menu for Creating SAP HANA Calculation View

Figure 6.1 Context Menu for Creating SAP HANA Calculation View

Click New and select Calculation View.

[»] Note

You can create attribute views and analytic views via the same context menu if needed.

The options for creating different types of calculation views appear in the popup dialog box, as shown in Figure 6.2.

Figure 6.2 Creating Calculation View in SAP HANA StudioSAP HANA studiocreate calculation view

Figure 6.2 Creating Calculation View in SAP HANA Studio

At the top of the dialog box, give the calculation view a Name and a Label (description). You can choose to make a copy of another calculation view with the Copy From selection.

From SAP HANA SPS 10 on, always select the Graphical option in the Type dropdown list. The SQLScript option is no longer used, and in SAP HANA SPS 11 any existing SQLScript calculation views can be migrated to table functions, as will be discussed in Chapter 8.

[»] Script-based vs. Graphical Calculation Views

Script-based calculation views are used to create views using SQLScript. Graphical calculation views avoid the need for code by creating views graphically.

Use the Data Category dropdown list and the With Star Join checkbox to create the different types of calculation views. (Note the information below these dropdown selection lists, which indicates the default view node for each type of calculation view. We’ll discuss default nodes shortly.)

The following instructions explain how to create each type of calculation view:

If you select the Blank option in the Data Category dropdown list, you will create a dimension view. This type of calculation view can only be used internally in SAP HANA. An external client tool—for example, a reporting tool—will not be able to see this calculation view.

Click the Finish button to create the calculation view.

Creating Time Dimensions

You can also change the Subtype of the calculation view (in the middle of the dialog screen) to create a time-based calculation view. When you set the Subtype to Time, the dialog screen changes as shown in Figure 6.3.

Figure 6.3 Creating Time-Based Calculation ViewsTime-based calculation views in SAP HANA Studio

Figure 6.3 Creating Time-Based Calculation Views in SAP HANA Studio

The time-based calculation view adds a time dimension to information views. Remember that dimensions contain attributes that describe a transaction. If we add a time and date when the transaction happens, we have added another (time) attribute. These time attributes are stored in a time dimension.

You can set the calendar to the standard Gregorian calendar or to the Fiscal (financial) calendar. You can also set the Granularity to Year, Month, and all the way down to Second.

If you use this option, you will need to generate time data in SAP HANA. You can do this from the Quick View menu in the Modeler perspective.

If you have tables T009 and T009B from your SAP ERP system available in SAP HANA, you can use these tables to define the Fiscal calendar.

Working with a Calculation View

A calculation view includes different working areas. A calculation view of type dimension is shown in Figure 6.4 in SAP HANA studio. Work from left to right in this layout.

Figure 6.4 Working with Calculation Views

Figure 6.4 Working with Calculation Views

In the left work area, called the Scenario area, you’ll see different nodes. The top node is always the Semantics node. In the semantics node, you can rename fields to give them more meaning (i.e., semantics). You can also create hierarchies in the semantic node. (In Chapter 7, we’ll discuss adding hierarchies to SAP HANA views.)

The node below the semantics node is called the default view node. The default node is the top-most node used for modeling in the view. Figure 6.5 illustrates the default nodes for the different types of calculation views. You can add other types of nodes below the default node; for example, Figure 6.4 shows two join nodes below the default Projection node of the dimension view.

Figure 6.5 Default View Nodes for Different Types of Calculation ViewsCalculation viewsdefault nodes

Figure 6.5 Default View Nodes for Different Types of Calculation Views

[+] Tip

Always work bottom-up when building SAP HANA information views: Start at the nodes at the bottom and work your way up to the default node. The output of each node becomes the input of the node above it. The final output of the view, which is the output of the default node, is shown in the semantics node.

When you select a node in the Scenario section, the information for the selected node is shown in the Details area in the middle. In Figure 6.4, we selected the second join node. In the Details area, you can see the tables in this join node and how they are joined together.

On the right-hand side of the screen in Figure 6.4, you can see all the selected Output fields, and directly below that, the Properties of whatever field or join you have currently selected from the Details or Output area. You can also see the properties in the bottom working area, in the Properties tab.

Adding Nodes

You can add new nodes to the SAP HANA information view by selecting a node type from the Palette on the left side and dropping it onto the Scenario work area. Drag the node around on the work area to align it with other nodes. When the node lines up with another node, an orange line indicates that the node is aligned (see Figure 6.6). Link the nodes by dragging from the circle on top of the node block to the circle at the bottom of the node above it.

Figure 6.6 Adding and Aligning Join NodeJoinsnode to the Dimension View

Figure 6.6 Adding and Aligning Join Node to the Dimension View

Adding Data Sources

Once you’ve added a node to the work area, you can add data sources to it. There are two ways of adding data sources:

  1. Hover the mouse cursor over the node. A popup overlay menu with a green plus sign Icon and a tooltip (Add Objects) will appear. Click on the plus sign. A dialog box will appear and ask you which data source(s) you want to add to the data foundation. Type a few characters of the table’s name to search for any data sources in the entire SAP HANA system that match those characters. Then, select the data source(s), and click on OK to add them to the node.
  2. Drag and drop tables from the Systems tab. Open the Tables folder in the schema in the Catalog area, then simply drag and drop the name of the table or data source onto the node.

Both methods are shown in Figure 6.7.

Figure 6.7 Two Methods of Adding Data Sources to Nodes

Figure 6.7 Two Methods of Adding Data Sources to Nodes

Creating Joins

After you’ve added the data sources to the data foundation, you’ll want to join the data sources together. Create a join by taking the field from one table and dropping it onto a related field of another table. Figure 6.8 shows what this looks like in SAP HANA studio.

Figure 6.8 Creating a Join in SAP HANA Studio and Setting Its Properties

Figure 6.8 Creating a Join in SAP HANA Studio and Setting Its Properties

Go to the Properties area to select the Join Type from the dropdown, and set the Cardinality. Make sure you have the join (the line between the tables) selected as illustrated; otherwise, the properties will not show the correct information.

[+] Tip

When you create a join, get into the habit of always dropping the field from the main table onto the related field of the (smaller) lookup table.

For some join types, it makes no difference in which direction you do the drag and drop. With a text join, however, it matters.

The join types that are available in calculation views are as follows:

Referential joins and full outer joins are available in join nodes as of SAP HANA SPS 11. Previously, referential joins were only available in star join nodes.

Selecting Output Fields

The next step is to select output fields. There are two ways to do this:

  1. In the context menu of a field name in the table, select the Add to Output option.
  2. A quicker way is clicking the round dot next to the field name. The dot will turn orange when the field appears as an output column.

Both methods are shown in Figure 6.9.

Figure 6.9 Selecting Fields for Node Output

Figure 6.9 Selecting Fields for Node Output

Figure 6.10 shows what a list of output fields looks like in SAP HANA studio.

Figure 6.10 List of Output Fields for Selected Node

Figure 6.10 List of Output Fields for Selected Node

When you select one of the fields in the output columns, you can see the properties of that field in the Properties tab underneath the Output area. (See the overview screen in Figure 6.4.) You can see the name of the column in Figure 6.11. You can change column names to make them more meaningful for end users. The Mapping property ensures that SAP HANA knows what the original field is.

Figure 6.11 Properties of Output Field

Figure 6.11 Properties of Output Field

You can also change the data type and specify whether the attribute is a key attribute or if the field should be hidden or not.

[+] Tip

Even though you can set the different properties in the Property area in the node, we find it easier to set many of these in the Semantics node. Changing the name or the label, setting a key attribute, and setting an attribute as hidden are much easier to do in the Semantics node. We will discuss the Semantics node later in the chapter.

Often, you’ll want to select all the fields coming from a lower node as the output fields of the node. In this case, right-click the top bar of the data source and select the Add All to Output, as shown in Figure 6.12.

Figure 6.12 Selecting All Fields from Lower Node as Output Fields

Figure 6.12 Selecting All Fields from Lower Node as Output Fields

Finalizing the Calculation View

In Chapter 4, we discussed how to build SAP HANA information views in layers, with each node building on the previous ones.

Once you’ve finished building the calculation view, there are two final steps to follow:

  1. Click the Save and Activate Icon button on the toolbar above the Output area (see Figure 6.13). We’ll discuss the activation process in Chapter 11, but for now, just think of it as a step you need to take before you can run your calculation view.
  2. Preview your data by clicking the button on the toolbar. We discussed the preview functionality in Chapter 5.
Figure 6.13 Save and Activate the Information View

Figure 6.13 Save and Activate the Information View

Congratulations! You now know how to create calculation views in SAP HANA.

Working with Nodes

In Chapter 4, we looked at the modeling concepts of joins, star joins, projection, ranking, aggregation, and union.

All of these options are available in calculation views as nodes. You can add these nodes from the Palette on the left of the Scenario work area, as shown in Figure 6.6. These are the basic building blocks to use in the different layers of calculation views.

Let’s take a quick look at the available nodes, working in alphabetical order.

Aggregation Node

The aggregation node in calculation views can calculate single summary values from a large list of values; for example, you can create a sum (single summary value) of all the values in a table column. These summary values are useful for high-level reporting, dashboards, and analytics. (The functionality is similar to the GROUP BY statement in SQL.) The aggregation node in calculation views also supports all the usual functions: sum, count, minimum, maximum, average, standard deviation, and variance.

The last three functions (average, standard deviation, and variance) are new as of SAP HANA SPS 11. For performance reasons, we recommend not using these three functions when you have very large stacked calculation views.

You normally calculate aggregates of measures, but in the latest versions of SAP HANA you also can create aggregates of attributes, which basically creates a list of unique values.

Join Node

The earlier examples shown in Figure 6.4 and Figure 6.12 used a join node. Join nodes are used at the bottom layers to get data sources in to the view. Join nodes have only two inputs, so if you want to add five tables in the calculation view, you’ll need four join nodes. Because of this, joins tend to be highly stacked. (You can see an example in Figure 6.21.)

Projection Node

Projection nodes can be used to remove some fields from a calculation view. If you do not send all the input fields to the output area, the fields that are not in the output area will not appear to client tools.

You can also use projection nodes to rename fields, filter data, and add new calculated columns to a calculation view. (We’ll discuss filter expressions and calculated columns in Chapter 7.)

Rank Node

We can use rank nodes to create top N or bottom N lists of values to sort results. In the Details area of a rank node, you can access extra properties to specify the rank node behavior.

Figure 6.14 shows the Rank Node area. The Sort Direction field specifies if you want a top N or bottom N list. The Order By field specifies what you want to sort the list by.

Figure 6.14 Rank Node

Figure 6.14 Rank Node

The Threshold field specifies how many entries you want in the list. If you specify a Fixed value of 10, you’ll produce a top 10 or bottom 10 list. You can also choose to set this value from an Input Parameter, which means that the calculation view will ask for a value each time it’s run. (We’ll discuss input parameters in Chapter 7.)

You can tell the rank node to create an additional generated field with the rank values. By setting the Generate Rank Column flag, the additional field is generated with the name provided in the field. You can use this generated field to sort the results in ranking order—for example, in a reporting tool. The generated field is created with a BIGINT data type.

Star Join Node

The star join node is used only to join a data foundation with fact tables to dimension views. The join types available in the star join node are the same as the normal joins in a join node. It’s what they’re joining that differs.

Figure 6.15 shows a star join node. The left data source in the Details area is the data foundation, which comes from a join node with two fact tables. The right data source is a calculation view of type dimension.

Figure 6.15 Star Join Node

Figure 6.15 Star Join Node

[»] Note

Only calculation views of type dimension are supported as the dimension data sources in the star join node of a calculation view.

The star join node is the default node of calculation views of type cube with star join. Use join nodes, as shown in Figure 6.15, to join all the transactional tables together. The upper-most join node contains all the measures. The output from this last join node becomes the data foundation for the star join node. Figure 6.15 only has one join node for the data foundation.

Then, drag and drop the required dimension views (which have to be calculation views of type dimension) into the star join node and join them to the data foundation.

Union Node

In Chapter 4, we explained the difference between a standard union and a union with constant values. Figure 6.16 shows a standard union with two data sources in the Source area. These sources are combined into a list of output fields on the right side.

[+] Tip

Union nodes in SAP HANA can have more than two data sources.

Figure 6.16 Union Node

Figure 6.16 Union Node

From the context menu of a field in the list of Target fields on the right, you can select the Manage Mappings option to open the Manage Mappings dialog screen, where you can edit the current mappings. You can also set up a Constant Value for one of the data sources. In this case, we’ll change the standard union to a union with constant values.

SAP HANA SPS 11 includes some performance enhancements for the union node. You can make unions run even faster by using a pruning configuration table. In this table, you can specify pruning conditions (like filters) to be applied to some columns. For example, a pruning condition can specify that the year must be 2016 or later. This filters the data and complies with our first modeling guideline: Limit (filter) the data as early as possible. You can specify the Pruning Configuration Table in the Advanced area of the Semantics node. (An example is shown in Figure 6.19.)

Semantics Node

Semantics is the study of meaning. In the semantics node, you can give more meaning to the data itself. One basic example is renaming fields: Some database fields have really horrible names—but in the semantics node, you can change the names of these fields to make them more meaningful for end users. This is especially useful when users have to create reports. If you have a reporting background, you’ll know that a reporting universe can fulfill a similar function.

The semantics node includes four different tabs, as shown in Figure 6.17. We’ll only discuss the first two tabs in this chapter; the other two tabs will be discussed in Chapter 7.

Figure 6.17 Tabs in Semantics Node

Figure 6.17 Tabs in Semantics Node

Columns Tab

The first tab in the semantics node is the Columns tab (see Figure 6.18).

Figure 6.18 Columns Tab in Semantics Node

Figure 6.18 Columns Tab in Semantics Node

Renaming fields is easy. In the Columns tab, click the Name of the field and type the new name. The same rule applies for the Label. The label is used, for example, when creating SAP HANA XS (HTML5) applications, or in some reporting tools. Next to the name of the field, you’ll see a checkbox indicating whether this is a Key field or not.

You might want to hide fields if you don’t want to show the original field to the end user. Even if a field is hidden, it can be still used in a formula or a calculation; the field will still be available internally in SAP HANA for the calculation view, but will not be shown to the end users.

View Properties Tab

The next tab in the semantic node is the View Properties tab. Here, as shown in Figure 6.19, you can change the properties of the entire calculation view.

Figure 6.19 View Properties Tab in Semantics Node

Figure 6.19 View Properties Tab in Semantics Node

You’ve seen that when working with SAP data you sometimes have to set the default client. In Chapter 5, we explained how to set the default client for SAP HANA studio. You can also specify a default client for this calculation view, as shown in the Default Client dropdown list in Figure 6.19. If you select the Cross Client option, data from all the SAP clients will be shown; it will not filter the data to a specific client. The Session Client option will filter the data to display only data from a specific SAP client. Instead of using one of these two options, you can also enter the SAP client number that you want to display data for—for example, “800”. This setting takes precedence over the SAP HANA studio preferences.

Many of the features in the View Properties tab are new as of SAP HANA SPS 10, including new security options, the Deprecate checkbox, the Translate checkbox, and the ability to add comments. The Pruning Configuration Table field is new as of SAP HANA SPS 11. (We discussed this feature in the Union Node section.)

For the security settings, you can choose between Classical Analytic Privileges or SQL Analytic Privileges. (We’ll discuss these options in more detail in Chapter 13 when discussing security.) We recommend always using SQL Analytic Privileges. In SAP HANA SPS 11, there is a migration tool that migrates older classical analytic privileges to SQL analytic privileges.

Setting the Deprecate checkbox doesn’t mean that the calculation view will not work any longer; it will merely warn people that this calculation view has now been succeeded by a newer version somewhere in the system and that they should use the newer version, because this one will disappear someday in the future. When you add this calculation view in another data model, you’ll see a warning in SAP HANA studio that says, This model is deprecated. The calculation view will still work as usual, however.

When you select the new Translate checkbox, more functionality opens up in the tab’s work area. You can translate field names and labels into different languages. This is useful if you need to create an SAP HANA HTML5 (XS) application for users in different countries.

Finally, take note of the Comments feature. By clicking on any of the Comments icons Icon scattered throughout the calculation view, you can create comments about the calculation view. Use this functionality for internal notes to yourself, for notes to your modeling team members, or to remind yourself why you changed something.

In the Advanced section, you can set the Execution In to SQL Engine. You’ll only set this preference when developing SAP HANA Live calculation views. More information on SAP HANA Live calculation views can be found in Chapter 12.

Attribute Views and Calculation Views of Type Dimension

Currently, you can access two types of dimension views in SAP HANA. The older dimension views are called attribute views, and the newer dimension views are calculation views of type dimension. SAP HANA SPS 11 provides a migration tool to convert attribute views to calculation views of type dimension. You can use these information views as data sources for other calculation views.

In Figure 6.20, you can compare the same information model created as an attribute view (left) to the equivalent calculation view of type dimension (right).

Figure 6.20 Comparing an Attribute ViewAttribute viewsvs. calculation view of type dimension with the Equivalent Calculation View of Type DimensionCalculation view of type dimension

Figure 6.20 Comparing an Attribute View with the Equivalent Calculation View of Type Dimension

The attribute view always contains only one node (except for the semantics node). The data foundation node is always the bottom node. You can join multiple tables in the data foundation.

The calculation view of type dimension has a default projection node at the top (below the semantics node). However, you have the flexibility to add any of the calculation view nodes below it. In this case, we used a join node with the same tables to achieve the equivalent of the “data foundation.”

The disadvantage of a join node is that it accepts only two inputs. The impact of this is illustrated in Figure 6.21, in which you can see the highly stacked model on the right.

Figure 6.21 Disadvantage of a Join Node

Figure 6.21 Disadvantage of a Join Node

[+] Tip

Attribute views have a single data foundation node because dimension views only work with attributes. Even numeric values will be treated as attributes. You also do not use fact tables with attribute views, so you don’t need an additional star join node.

Calculation views of type dimension have many advantages over attribute views—for example:

There are some reasons to use attribute views, however, such as the following:

Let’s look a little closer at the concept of derived attribute views. Think about shortcuts on your Windows or Mac desktop, or even the icons on the home screen of your phone or tablet. These shortcuts point to a program somewhere else on your computer or mobile device. When you tap the shortcut, the machine knows how to access the actual program. You can even rename the shortcut to something more meaningful for you; the program that it points to stays the same.

Derived attribute views are like shortcuts to attribute views. You create a derived attribute view when you want to reuse the same attribute view multiple times in an analytic view, but each time for slightly different purposes.

For example, think about business partners in a contact management system. In our company, we have two groups of people with contact details: customers and suppliers. All these people are in a certain city, are in a certain country, and have a specific zip or postal code. It doesn’t make sense to store these addresses and contact details in two separate attribute views, so the contact details are in one attribute view called Contact Details.

We can now create two derived attribute views. Both will behave like shortcuts to the original Contact Details attribute view. We’ll name one derived attribute view Customer Contact Details and the other Supplier Contact Details.

In our data model, we can then use the (derived) Customer Contact Details attribute view when we work with customers and the (derived) Supplier Contact Details attribute view when we work with suppliers.

Just as with shortcuts on your desktop computer or mobile device, the derived attributed views are dependent on the existence of the attribute view they are based on: If you delete a program, the shortcuts to that program become useless. In the same way, derived attribute views need the base attribute view to function properly. When you update the base attribute view, the derived attribute views point to the updated version and also provide the updated functionality.

Calculation views of type dimension do not yet have this functionality.

Analytic Views and Calculation Views of Type Cube with Star Join

There are two types of star join views in SAP HANA: the older star join views, called analytic views, and the newer calculation views of type cube with star join. SAP HANA SPS 11 provides a tool to migrate analytic views to calculation views of type cube with star join.

Similar to the attribute view example, in Figure 6.22 you can compare the same information model created as an analytic view (left) to the equivalent calculation view of type cube with star join (right).

Figure 6.22 Comparing an Analytic ViewAnalytic viewsvs. calculation views of type cube with star joinCalculation view of type cube with star joinvs. analytic views with the Equivalent Calculation View of Type Cube with Star Join

Figure 6.22 Comparing an Analytic View with the Equivalent Calculation View of Type Cube with Star Join

Analytic views always have two nodes (excluding the semantics node). The data foundation node is always the bottom node, and the star join node is the top node. Analytic views are built in the same bottom-up approach that you use for calculation views: First join multiple transactional tables (with measures) in the data foundation, then, in the star join node, join the data foundation to several attribute views.

The calculation view of type cube with star join has a default star join node at the top (below the semantics node). Again, you have the flexibility to add any of the calculation view nodes below it. In Figure 6.22, we used a join node with the same tables to achieve the equivalent of the data foundation.

Calculation views of type cube with star join have many advantages over analytic views—for example:

There is only one reason to still use analytic views: Analytic views are the only type of SAP HANA information view that can use temporal joins. (The temporal joins in analytic views are only available in the star join node, and only when you use inner or referential joins.)

Migrating Attribute and Analytic Views

In SAP HANA SPS 11, you can migrate attribute and analytic views to calculation views. As you’ve seen, calculation views offer far more flexibility and functionality than these older types of views. There are still two cases for which attribute and analytic views cannot be migrated yet, because calculation views do not have certain functionality yet: attribute views with fuzzy text search and analytic views with temporal joins.

To migrate your old attribute and analytic views to calculation views of type dimension and calculation views of type cube with star join, follow these steps:

  1. Start the migration tool from the Quick View menu in the Modeler perspective, as shown in Figure 6.23. Select the Migrate option. In the dialog box, select the option to migrate Attribute views and analytic views to calculation views.
  2. Next, select the attribute and analytic views you want to convert to calculation views (see Figure 6.24).
  3. Hidden columns have to be made visible during migration; otherwise, the migration tool will not include these fields as outputs in the calculation view that it will create. Therefore, enable the Make hidden columns visible option.
    Figure 6.23 Selecting Migration Options

    Figure 6.23 Selecting Migration Options

    Figure 6.24 Selecting Attribute and Analytic Views to Migrate

    Figure 6.24 Selecting Attribute and Analytic Views to Migrate

  4. You can simulate the migration by enabling the Copy and migrate option. The migration tool will not adjust or modify the original attribute and analytic views and will generate the calculation views in a package that you specify for the simulation. This is useful in order to understand the impact of the migration before you proceed with the actual migration.
  5. Next, an overview screen displays a list of the views that will be impacted (Figure 6.25). Confirm the list of impacted objects by clicking Finish.
  6. When you start the migration, it runs as a background job. When the migration has finished, you can check the log file in the Job Log View or in the folder specified in the Migration Log Path (as shown in Figure 6.23).
    Figure 6.25 Selected Attribute and Analytic Views

    Figure 6.25 Selected Attribute and Analytic Views

There are three points to note about the migration of attribute and analytic views to equivalent calculation views: