Conclusion - Data Warehouse Systems: Design and Implementation - page 568

interval and including one version for a fact and one version for each
dimension associated with a fact. Whenever changes to dimensions or facts
occur at the schema level, a new star version is created. A similar approach
was taken by Wrembel and Bebel [ 230 ], where each change at the schema
or instance level results in the creation of a new schema version even
though that version has the same structure as the original one in the case
of changes at the instance level. Other proposals on this topic are, for
example, [ 31 , 140 , 208 , 231 ]. The subtle interrelationship between temporal
data warehouses and multiversioning still needs to be investigated. For
example, a schema update of a source table may trigger a change in the data
warehouse schema, hence a new data warehouse version is created. However,
it would not be reliable to create a new data warehouse version each time
an instance changes. For this, timestamping the association between levels
would clearly be a better option. On the other hand, if the data source were
a temporal database, a temporal data warehouse that accounts for instance
and schema changes appears natural.
In spite of the progress made in the field, temporal databases have not been
adopted by database practitioners, and as a consequence, the same occurs in
the data warehouse field. This is the main reason why we did not include
temporal data warehouses in this topic. However, it is worth noting that the
last version of the SQL standard released in 2011 has temporal facilities.
Further, current database management systems such as Oracle, Teradata,
and DB2 also provide temporal support. The availability of such features
implies that temporal data warehouse systems will become a reality in the
near future, but for that to happen, temporal databases need to become more
used than they have been so far.

15.2 3D/4D Spatial Data Warehouses

In our study of spatial and spatiotemporal data warehouses (Chaps. 11
and 12 ), we had not addressed their extension to manage three- and four-
dimensional (3D/4D) objects, which would lead to 3D/4D spatial data
warehouses .
Many modern applications require the integration of 2D and 3D spatial
data (see a comprehensive review in [ 20 ]). For example, applications such
as facility management and disaster management in cities require not only
information about the locations but also information about the interior of
buildings. In cadastral surveys and insurance, the volume of a building might
also be of interest. In spite of the need of such integration between the 2D
and 3D worlds, typically the 2D world is digitally represented as a map and
the 3D world as a 3D model, both being implemented in completely different
data models and minimally integrated. However, nothing should prevent to