TABLE OF CONTENTS - DW Overview --------Architecture --------Back-end Tools - Intro to OLAP --------Codd's 12 Rules --------FASMI - MD Data Structures - OLAP Server - OLAP Operations - OLAP Architectures --------MOLAP: Part I --------MOLAP: Part II --------ROLAP: Part I --------ROLAP: Part II --------HOLAP --------DOLAP - Data Explosion - OLAP Criteria - Glossary - References ### Multidimensional Data Structures

Multidimensional databases can present their data for an application using two types of cubes: hypercube and multicubes. In a hypercube, as shown in Figure 1, all data appears logically as a single cube. All parts of the manifold represented by this hypercube have identical dimensionality. Each dimension belongs to one cube only. A dimension is owned by the hypercube. This simplicity makes easy for users to understand.

Designing a hypercube model is a top-down process with three major steps. One, you decide which process of the business you want to capture in the model, such as sales activity. Two, you identify the values that you want to capture, such as sales amounts. This information is always numeric. Last, you identify the granularity of the data, meaning the lowest level of detail at which you want to capture. These elements are the dimensions. And time, geography, product, and customer are some common dimensions. For example, a single cell in a cube could refer to the sales amount of Sony TVs in the first quarter of the year, in PA, USA. Figure 1. Hypercube

In the multicube model, data is segmented into a set of smaller cubes, each of which is composed of a subset of the available dimensions, as shown in Figure 2. They are used to handle multiple fact tables, each with different dimensionality. A dimension can be part of multiple cubes. Dimensions are not owned by any one cube, like under the hypercube model. Rather, they are available to all cubes, or there can be some dimensions that do not belong to any cube. This makes it much more efficient and versatile. It is also a more efficient way of storing very sparse data, and it can reduce the pre-calculation database explosion effect, which will be covered in a later section. The drawback is that this is less straightforward than hypercube and can carry steeper learning curves. Some systems use the combined approach of hypercube and multicubes, by separating the storage, processing, and presentation layers. It stores data as multicubes but presents as a hypercube. Figure 2. Multicubes