OLAP Cube Considerations. Restricting the archiving process to ROLAP DW implementations has important implications for the question of OLAP cube storage. In the ROLAP model, as noted above, by default the OLAP cube is not generated as a separate entity from the FACT and DIMENSION tables, i.e. it is a ‘virtual’ cube, the required elements of which are only generated at query time by the OLAP engine. If the SQL query containing the OLAP extensions is then stored as a view, this creates the appearance of a stored cube for the user, but the relevant OLAP cube cell values are still only computed at query time. For performance reasons, a further step, to create ‘materialised views’ may be undertaken. In this case, computed values are indeed stored separately from the original FACT and DIMENSION tables, but additional DW infrastructure is then required to ensure that these materialised views remain current with the latest versions of data in the FACT table, if new data are being added to the latter over time. In the archiving context, when the DW data will only be used on an occasional basis rather than for near real-time decision support, there does not appear to be any justification for storing materialised views. Conversely, the case for archiving stored OLAP queries as VIEWS seems to be very strong, as this helps retain aspects of the business logic associated with the main uses of the original DW system. It should also be noted that the original CWM structure had no provision for ‘the concept of pre-calculated aggregations’, i.e. the storage of the results of OLAP queries, and it is proposed that the EARK project adopts the same stance. Should there be a need to archive certain specific aggregated OLAP query results, e.g. census output tables, they can be stored as standard relational tables, subject to the usual SIARD 2.0 processing for archival processing, since the result of every OLAP SQL query, as with every SQL query, has the form of a table, albeit not necessarily a very convenient form for later post-DIP processing. A second approach, which is expected to gain further traction with governmental organisations in future, is to store such pre-calculated aggregations in the SDMX interchange format used by EUROSTAT and other European Census and Statistical Organisations. This route is therefore recommended for those organisations that require this type of functionality.
