Using Semantic PartitioningLocate this document in the navigation structure

Context

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:

    The larger the data volume, the longer the runtimes required for standard DataStore objects and standard InfoCubes. Semantic partitioning means that the data sets are distributed over several data containers. This means that runtimes are kept short even if the data volume is large.

  • 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 several 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:

Notes on updating deltas:

If the semantically partitiioned object is made up of InfoCubes, deltas can be updated to the target InfoProvider using DTPs without any restrictions.

If the source is a semantically partitioned object that is made up of DataStore objects, only full DTPs can be created. If you want to update using deltas, you have to select the partitions of the semantically partitioned object as the source, rather than the semantically partitioned object itself.

If the target is a semantically partitioned object, you can perform the DTPs using the target semantically partiioned object's wizard. The source of the DTPs would then have to be the outbound InfoSource of the source semantically partitioned object rather than the semantically partitioned object itself.

Note on analysis:

If you update the entire semantically partitioned object to another InfoProvider, the navigation attributes cannot be used in the 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.

Note on query performance:

Due to Partition Pruning, the data is processed quickly - with or without the use of a BW accelerator. With Partition Pruning, only those partitions are read that contain the data requested in the query.

Procedure

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

    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

Results

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.