Corporate Memory 
The corporate memory contains the complete history of the loaded data.
This displays an intermediate layer. The data is posted to other DataStore objects (advanced) that serve as architected data marts. It is filled separately from the update in the architected data marts. The template for the corporate memory is used to create a DataStore object (advanced) with InfoObjects or fields. Fields are useful if you load data from external sources or if you want flexible modeling and you only want to assign InfoObjects at a higher point in the data flow.
No properties are selected under Modeling Properties:
The requests are loaded into the inbound table and also extracted from it. The data is not aggregated. When a query is executed, the inbound table is accessed. As the corporate memory mainly serves as a source for reconstructions, we advise against performing reporting on this object. The query accesses the data in the inbound table, which does not provide suitable data for reporting because of the technical key.
This type of modeled object corresponds to a write-optimized DataStore object (classic):
Under Modeling Properties, the Activate/Compress Data property is selected:
The requests are also loaded into the inbound table here. The data is stored at granular level.
. Therefore you first need to update all the data (from the inbound queue) using delta, before you activate the data. Here you should pay particular attention to compression. You should compress data if you are certain that the data is consistent. This is because without a change log, you can only delete data selectively after compression. Request-based deletion is not possible.
If the data is not required with this level of detail, it can be compressed in order to save space. Before you compress the data, make sure that all the data has been updated from the inbound table using delta and that all the data is consistent. During compression, the data is aggregated in accordance with the semantic key and is written to the active data table. In the query, you will then only see the data that has been compressed. To save memory space, the change log is not filled. Therefore you cannot perform request-based deletion of data from the DataStore object. You can only delete data selectively.
When a query is executed, the active table is accessed:
Under Settings, the Keep Inbound Data, Extract from Inbound Table property is also selected:
This type of object also stores data at granular level. The data can be compressed, but is stored redundantly in the inbound table in order to prevent the detailed information from being lost. This also makes it possible to delete the data from the active table and to create it again from the inbound table.
The data is only extracted from the inbound table. When a query is executed, the active table is accessed:
