Show TOC

Procedure documentationUsing Semantic Partitioning Locate this document in the navigation structure

 

A semantically partitioned object is an InfoProvider that consists of several InfoCubes or DataStore objects with the same structure.

Semantic partitioning is a property of the InfoProvider. You specify this property when creating the InfoProvider. Semantic partitioning divides the InfoProvider into several small, equally sized units (partitions).

A semantically partitioned object offers the following advantages compared to standard InfoCubes or standard DataStore objects:

  • Better performance with mass data:

    For DataStore objects, we recommend that you do not save more than 20 million data records. Otherwise the activation process takes considerably longer. For InfoCubes, we recommend that you do not save more than 200-400 million data records. Otherwise the compression and reconstruction of aggregates takes too long. The semantically partitioned object does not have these implicit restrictions, as the data quantity is distributed between several data containers.

  • Close data connection:

    Error handling is better. If a request for a region ends with an error, for example, the entire InfoProvider is unavailable for analysis and reporting. With a semantically partitioned object, the separation of the regions into different partitions means that only the region that caused the error is unavailable for data analysis.

  • Working with different time zones:

    EDW scenarios usually involve time zones. With a semantically partitioned object, the time zones can be separated by the partitions. Data loading and administrative tasks can therefore be scheduled independently of the time zone.

Analysis and reporting

You can use the semantically partitioned object for reporting and analysis, as you can with any other InfoProvider. You can also choose to only update selected partitions in an InfoCube, for example, or include selected partitions in a MultiProvider and use them for analysis, as shown in the following graphic:

This graphic is explained in the accompanying text.

Note Note

If you update the entire semantically partitioned object in another InfoProvider, the navigation attributes are not available for analysis. This is because the InfoSource that compiles the individual partitions for the update does not support navigation attributes. If you only update some of the partitions, this restriction does not apply.

End of the note.

Note on query performance:

If the semantically partitioned object consists of InfoCubes, the performance is good. Due to Partition Pruning, the data is processed quickly - with or without the use of a BW accelerator. With Partition Pruning, only the partitions are read that contain the data requested in the query.

If the semantically partitioned object consists of DataStore objects, all partitions in the query are read, which leads to performance problems.

Procedure

  1. Create a DataStore object or an InfoCube with the property Semantically Partitioned.

    More information: Creating a Semantically Partitioned Object

  2. Create a transformation.

  3. Create a data transfer process.

    More information: Creating a DTP for a Semantically Partitioned Object

  4. Create a process chain.

    More information: Creating Process Chains for a Semantically Partitioned Object

Result

You have now created a semantically partitioned object with a data flow. In the editing screen of the semantically partitioned object, choose Display Monitor to see an overview of the status of your partitions and the DTPs. The displayed requests statuses tell you whether the requests are active and whether all the data is up to date. This last point means that the system checks whether the last request to be retrieved in every partition is the same, or whether one of the partitions contains a newer request than in the other partitions.