Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
kpsauer
Product and Topic Expert
Product and Topic Expert
The Analytical Dataset semantic usage is now deprecated since release 2023.13 but can continue to be used. For all new modelling we recommend that you use the new Fact semantic usage instead.

This blog gives you more details on what this change is all about and the effect on your implementation project.

 

What is the new semantic usage Fact and what are its benefits?


Facts allow you to model data in all the ways familiar from analytical datasets; the modelling experience in the editor as well as all modelling guidelines are exactly identical. There’s one crucial difference between the two though and that is that Facts are not intended to be consumed directly in SAP Analytics Cloud.

Instead, the preferred way to expose data to SAP Analytics Cloud is now to identify your measures in a table or view with a semantic usage of Fact and then to use this fact in one or more analytic models, each of which can be consumed by one or more stories.


 

This new workflow provides the following benefits:

























Feature Analytical Dataset Fact + Analytic Model
Aggregations Standard aggregations only, such as SUM, COUNT.

Standard and post-aggregation measures (calculated measures, restricted measures, and count distinct measures), including support for exception aggregations.

Move post-aggregation measures from your SAP Analytics Cloud stories into your analytic models to benefit from real-time previewing of results and to promote re-use.
Measures and attribute selection All measures and attributes and first-level dimension always exposed to SAP Analytics Cloud. More remote dimensions cannot be included. Model as many measures, attributes, and associations to dimensions as appropriate in a fact, and then choose to expose only those that you need in each analytic model. You can select attributes from any dimension that is associated with the fact, whether it is a first-level dimension (directly associated with the fact) or any dimension that can be reached by following further associations.
Data viewer Relational data viewer shows lists of records Rich analytic viewer, based on the SAP Analytics Cloud Data Analyzer, supports measure and attribute selection, filtering and pivoting, and hierarchy support.

When you previously set the Semantic Usage of a view to Analytical Dataset, we now recommend that you choose Fact and then use your fact and its associated dimensions as sources for an analytic model.

 

What is the motivation for introducing Facts and deprecating Analytical Datasets?


The Analytical Dataset played a hybrid role: on the one side it provides a relational model representing a normal database table or view; on the other side, it also had an analytical representation for the usage with analytical tools like SAP Analytics Cloud. To this end, the system made assumptions about what to expose (all measures, all first-level dimensions).

As both of these aspects were done at the same time in the same editor, the editor could not cater well to provide all aspects at the same time, thus leading to a suboptimal user experience. The modelling architecture & reuse capabilities also suffered and most importantly, some highly requested analytical features could not be provided within the same design-time object.

For this reason, we decided to introduce a clear separation between the relational part of the modelling in the form of graphical or SQL views and the analytical part of the modelling in analytic models. The analytic model offers many more degrees of freedom in the design of the analytic object like rich measure modelling, selection of measure, attributes and any of the reachable dimensions, a rich analytical data preview and much more.

Because of this separation, the dual nature of Analytical Datasets are really no longer required and instead the relational part spells out what it does – it’s a Fact – and the analytical part is taken over by another object – the analytic model.

The following illustration explains in more detail what happens with the design-time artifacts during deployment and which runtime objects are created based on their definition.


 

Do I have to remodel all my existing Analytical Datasets immediately?


No. The Analytical Dataset semantic usage is deprecated, but existing views can continue to be consumed, at present, by SAP Analytics Cloud.

However, we recommend that you use the new Fact semantic usage instead for new models you create going forward. We also encourage you to migrate your analytical datasets to facts.

 

How do I migrate my Analytical Datasets to Facts?


You turn an Analytical Dataset into a Fact by just changing the semantic usage of it and hitting Deploy. The bigger part of the migration is to ensure that your SAP Analytics Cloud stories that use the analytical aspect of the Analytical Dataset do not break. To that end, they need to be rewired to a newly created Analytic Model that is structurally identical to the former analytical part of the Analytical Dataset, thus containing all its measures, all its attributes and all first-level dimensions. Once the rewiring has been done successfully, you can enhance the Analytic Model to your liking to benefit of its modelling richness.

If your analytical dataset is consumed by one or more SAP Analytics Cloud stories, you can use these steps to minimize disruption:

  1. Open your analytical dataset and click Create Analytic Model under the Semantic Usage property to create an analytic model with all the same measures, attributes, and associated dimensions as your view.

  2. Save and deploy your analytic model.

  3. In your SAP Analytics Cloud story, add your analytic model as a new data source.

  4. Copy relevant pages of your story to work on.

  5. For each affected chart or table on your copied page, switch the measure and attribute references to those provided by your analytic model.

  6. Compare the charts and tables between the original and copied pages and, once everything is the same, delete the original page.

  7. When all of your stories that consume a particular analytical dataset are fully converted:


a) Open your analytical dataset view and change the semantic usage to Fact.
b) Deploy your view.
c) Deploy your analytic model.


Now you can benefit from all the advantages of the analytic model:

  • Enhance your analytic model by removing unnecessary measures and dimensions and adding analytic measures as needed.

  • Move post-aggregation measures from your SAP Analytics Cloud stories into your analytic models to benefit from real-time previewing of results and to promote re-use.

  • Create additional analytic models on your fact as needed.


 

How long will the Analytical Datasets (Deprecated) be available?


SAP has no plans to remove Analytical Datasets from SAP Datasphere for the time being.

At the same time, note that all investments for analytic modelling will solely flow into the Analytic Model. These investments are paying of already today with a modelling experience and feature richness in which Analytic Models largely exceed Analytical Datasets as you see in the list of benefits above. This list will grow even more as new features are constantly being added to the Analytic Model – like e.g. the upcoming constant selection or external hierarchies with directories –, thus widening the feature gap even more.

Additionally, Analytic Models can fully be consumed in SAP Analytics Cloud, add-in for Microsoft Office which is the strategic office integration for SAP Analytics Cloud and SAP Datasphere. More information about the usage Microsoft office front ends.

We strongly suggest you adopt Analytic Models as your core analytical consumption entity for your own benefit and slowly but surely move away from Analytical Datasets. Once you reached a point where all your Analytical Datasets do is feed into Analytic Models and the Analytical Datasets are themselves not consumed directly by SAP Analytics Cloud, you should really go the last mile also and change the semantic usage of those Analytical Datasets to Fact. Because literally you do not need their analytical aspect anymore, just its fact part. And then you should also make this explicit.

 

Summary


Let me try to summarize some important points:

  • The Fact model is not a 1:1 replacement of the Analytical Dataset.

  • It replaces the relational SQL part, but not multi-dimensional cube structure consumed by SAP Analytics Cloud, hence SAP Analytics Cloud cannot consume Fact models directly.

  • The Analytic Model provides that multi-dimensional cube structure for SAP Analytics Cloud.

  • The Analytical Dataset is still available and can be used further. However, we recommend that you use the new Fact semantic usage instead for new models you create going forward. We also encourage you to migrate your analytical datasets to facts. The necessary steps are documented above or here.


 


Find more information and related blog posts on the topic page for SAP Datasphere. You will find further product information on our Community with various subpages about Getting StartedBusiness Content, the SAP BW Bridge as well as content for Best Practices & Troubleshooting and the FAQ for SAP Datasphere.
12 Comments
tim_huse
Advisor
Advisor
Great Blog 🙂
hudupa
Explorer
Very informative! Thank you for the blog Klaus-Peter!
Lothar_Köder
Participant
Hello!

Thanks for the blog, really interesting!

I'm wondering about the usage of Analysis for Office (AfO). Analytical datasets can be consumed there since version 2.8 SP14. Views with semantic "fact" can't be consumed with AfO. It's the same with Analytical Models. So it's currently necessary to have analytical datasets for usage with AfO in addition to analytic models for usage in SAC.

Using SAP Analytics Cloud add-in for Microsoft Office is currently not an option.

Best regards

Lothar
kpsauer
Product and Topic Expert
Product and Topic Expert
Hello,

as I wrote in the blog above, the Fact model is not a 1:1 replacement of the Analytical Dataset. It replaces the relational SQL part, but not multi-dimensional cube structure consumed by SAP Analytics Cloud, hence SAP Analytics Cloud or the Office add-in cannot consume Fact models directly. The same applies for SAP Analysis for Microsoft Office.

The Analytical Dataset is still available and can be used further. There is currently no plan to remove Analytical Datasets from SAP Datasphere.

Best regards
KP Sauer
Hi Klaus, Great blog!

Thanks. Is there a plan to make the Analytical Model available in AFO?  This is quite important for our customers.

Best Regards,

Rose
kpsauer
Product and Topic Expert
Product and Topic Expert
0 Kudos
Hi Rose,

the Analytic Model will only be supported with Office 365 and not Analysis for Office. Thereby we follow the product strategy of SAP Analytics Cloud  for the add-ins.

Beyond there will be also enhancements coming that cannot be supported by Analysis for Office which would cause disruptions and non-predictable behaviour.

Best regards
KP Sauer
TuncayKaraca
Active Contributor

It makes more sense now, thank you, Klaus.

PhilMad
Participant
0 Kudos
Hi Klaus-Peter, I had a look at the column view of an Analytical model and it "only" includes unfortunately the direct columns of the model, but not the associated fields. Is there a chance to generate a second view in which the associations would be included automatically? This would be very nice for e.g. ML with the HANA ML Python client. One single view to rule it all :-). Kind regards, Philipp
PhilMad
Participant
0 Kudos
Of course, work around is to create such a structure manually, but it is what it is, manually created....
jan_fetzer
Advisor
Advisor

Hi Philipp, your problem is fully solved via the SQL view of the fact source of the Analytic Model, so you don't need to go via the column view of the Analytic Model (which you shouldn't use anyway, since it's really only there for SAC-side consumption during query time). The fact source view does include the associations under the their technical names. E.g. for the example model at https://blogs.sap.com/2023/03/20/sap-datasphere-analytic-model-series-data-model-introduction/, the fact source V_MCT_OpportunityItems_v2 is deployley with this statement:

-- V_MCT_OpportunityItems_v2 (1/1)

CREATE OR REPLACE VIEW "SOME_SCHEMA"."V_MCT_OpportunityItems_v2" AS SELECT

"MCT_OpportunityItems_0"."ItemID"AS"ItemID",

"MCT_OpportunityItems_0"."Opportunity"AS"Opportunity",

"MCT_OpportunityItems_0"."Product"AS"Product",

"MCT_OpportunityItems_0"."Quantity"AS"Quantity",

"MCT_OpportunityItems_0"."Value"AS"Value",

"MCT_OpportunityItems_0"."Unit"AS"Unit",

"MCT_OpportunityItems_0"."Currency"AS"Currency",

"MCT_OpportunityItems_0"."FactAttr"AS"FactAttr",

"MCT_OpportunityItems_0"."FactAttrLabel"AS"FactAttrLabel",

"MCT_OpportunityItems_0"."ItemStatus"AS"ItemStatus",

"MCT_OpportunityItems_0"."ControllingArea"AS"ControllingArea",

"MCT_OpportunityItems_0"."SendingCostCenter"AS"SendingCostCenter",

"MCT_OpportunityItems_0"."ReceivingCostCenter"AS"ReceivingCostCenter",

TRUE AS "BooleanColumn"

FROM "MCT_OpportunityItems" AS "MCT_OpportunityItems_0"

WITH ASSOCIATIONS (

MANY TO ONE JOIN "MCT_Products" AS "_MCT_Produ" ON ("Product" = "_MCT_Produ"."ID"),

MANY TO ONE JOIN "MCT_ControllingArea" AS "_MCT_Contr" ON ("ControllingArea" = "_MCT_Contr"."ID"),

MANY TO ONE JOIN "MCT_Opportunities" AS "_MCT_Oppor" ON ("Opportunity" = "_MCT_Oppor"."OpportunityID")

);
Because the association definitions are indeed deployed, you can leverage them by e.g. querying via
select _MCT_Produ.* from V_MCT_OpportunityItems_v2
If the product dimension itself has associations also (cp. below for employee who is responsible for the product), you can totally leverage those nested dimensions as well:
Product view is deployed as
-- MCT_Products (1/2)

CREATE TABLE "MCT_Products" (

"ID"NVARCHAR(5000) NOT NULL,

"Name"NVARCHAR(5000),

"ProductCategory"BIGINT,

"ProductGroup"BIGINT,

"ProductManager"BIGINT,

PRIMARY KEY("ID")

) WITH ASSOCIATIONS (

MANY TO ONE JOIN "MCT_Employees" AS "to_employee" ON ("ProductManager" = "to_employee"."ID"),

MANY TO ONE JOIN "MCT_ProductCategories" AS "_MCT_Produ" ON ("ProductCategory" = "_MCT_Produ"."ID"),

MANY TO ONE JOIN "MCT_ProductGroupTexts" AS "_MCT_Prod1" ON ("ProductGroup" = "_MCT_Prod1"."ID")

);

Therefore you can request the details on the responsible of the product via

select _MCT_Produ.to_employee.* from V_MCT_OpportunityItems_v2

Hope this helps. Cheers, Jan

PhilMad
Participant
0 Kudos
Hi Jan, Cool, thanks for the quick response... Will immediately check it out :-). Kind regards, Phil
laesap
Explorer
Excellent post, thank you!