Jump to content

Multidimensional database

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by 89.132.145.10 (talk) at 13:23, 27 August 2007 (Examples). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Multidimensional databases are variously (depending on the context) data aggregators which combine data from a multitude of data sources; databases which offer networks, hierarchies, arrays and other data formats difficult to model in SQL; or databases which give a high degree of flexibility in the definition of dimensions, units, and unit relationships, regardless of data format.

Multi-dimensional databases are especially useful in a sales and marketing applications that involve time series. Large volumes of sales and inventory data can be stored to ultimately be used for logistics and executive planning. For example, data can be more readily segregated by sales region, product, or time period. While many of the major database vendors have recognized and implemented at least a partial solution, most frequently they rely upon a Star schema database design. However, The Star database design does not account for "sparse data" - basically, wasted empty space. Database strategies to manage sparse data result in the compression of large blocks of empty data elements and improves the performance of the database as a whole.

The data cube is a conceptual representation of database which can be implemented in a variety of ways, including top-down, bottom-up, and arrays. Multi-dimensional databases for time-series or other data vector analysis is preferable over relational databases. On the other hand, dimensionality becomes problematic when working with greater than four dimensions - there is often a resultant amount of sparse or empty data. Removing empty or sparse data poses risks as it can ruin the context and more specifically the vector coordinates of the data.

This is an active area of database development, in which the set of desired features is somewhat vague, but better-defined than the set of known or proposed solutions. Defining and implementing a database which allows people at each level of an organization to define tables and data formats in the way that is most useful to them, yet which supports a single clear query language and consistent infrastructure, remains an open problem.

Examples

References