Although most loads are on a daily – weekly or monthly basis, a year end procedure can help because the parameters of the loads of master and / or transactional data have to be changed. This is due to: • Some loads are limited until the previous year. The data of the next year will not be loaded. • Some loads are refreshing of data that is not anymore supposed to change (data of two years ago). This has a negative influence on the load performance. • Some data are divided in a cube for the actual year and in a cube for previous years. This is to improve the performance of the loads and queries. These data have to be reorganized or a multiprovider to be adapted. Therefore it is helpful to check the process chains of what is loaded and to examine the following points: * Loading of data of next year. Are the selection criteria in the Info packages selecting the data of the next year also? In the case of a full load, the selection criteria are sometimes due to be adapted. In the case of a delta load, an additional initialization run is needed. * Logical splitting up of InfoCubes. For performance reasons, some InfoCubes can be split in several InfoCubes. This can be done by creating an InfoCube "actual" and an InfoCube "previous years". The queries can run on a multiprovider that points to both InfoCubes. In this case the data of the previous year can be transferred from the "actual" InfoCube to the InfoCube of the "previous years". This requires the creation of an export datasource, loading selectively the data and a selective deletion in the "actual" InfoCube. The creation of an InfoCube by year is another way of organizing the logical split of data is. A multiprovider can also point to the several InfoCubes "year x”, "year x+1", .... In this case the creation of a new InfoCube is needed. This new InfoCube has to be added to the relevant infoproviders of the multicube. And the update rules for the new InfoCube "year x+1" can be based on the update rules for the previous cube "year x". The targets in the Infopackages have also been changed. * Freeze data that is due not to be changed. Some data are regularly refreshed. This happens often with full loads towards an InfoCube or a data storage object because there is no valid delta process working in the source system. The refreshed data contains often rather old data that is due not to be changed anymore. Therefore the selection in the Infopackage can be adapted, so that these stable data are not refreshed anymore. This is a gain of load time. To freeze the data, the way of working depends of the infoprovider. For a data storage object, the data is present and does not have to be overwritten anymore. Of course, a complete deletion of the data content before the load is not anymore possible. When an InfoCube is used, the data that has to be frozen can be loaded once and compressed. The new refreshing loads do not contain anymore the frozen data. These are a couple of ideas concerning the year end procedure in Business Intelligence. I presume there are still other ideas that can be added to these.
