ADVANCED CONCEPT IN DATABASE

Term Paper

On

Multi-Dimensional Database and DBMSs

Submitted to: Submitted By:

Prof. Shubhamay Dey Shrawan Kumar Trivedi

Content

Topic s Page no.

Introduction 2

Multidimensional database 3

Multi-Dimensional Database System 5

Evaluation of multidimensional database model 12

Advantages of Multidimensional DBMS 12

Multi-Dimensional Database System – Where not to Use? 14

Features of Multi-Dimensional Database Systems 16

Conclusion 17

1

Introduction

For introducing the concept of multi-dimension database and its management first of all we have to know that what are the importance of the multi-dimensional database and how it is advantageous over other database system. The information industry has witnessed a steady evolution in database power and flexibility. From flat file and hierarchical to relational and distributed relational technologies, data structures have evolved to match more closely the way people visualize and work with data.

After the evaluation of the several data structure it has been proved that there is no single "best" data structure for all applications within an enterprise. Many companies are, therefore, abandoning their search for the holy grail of the globally applicable database and are instead selecting the most appropriate data structure on a case-by-case basis from a palette of "standard" database structures.

The latest step in the evolution of databases is the multidimensional database. Springing from econometric research conducted at MIT in the 1960s, the multidimensional database has matured into the database engine of choice for data analysis applications. This application category is widely recognized today as OLAP (On Line Analytical Processing). The central reason for the multidimensional database's rise to corporate necessity is simple: it facilitates flexible, high performance access and analysis of large volumes of complex and interrelated data–even when that data spans several applications in different parts of the organization. Today's corporate computing environments require powerful database applications optimized for analysis.

Aside from its inherent ability to integrate and analyze large volumes of enterprise data, the multidimensional database offers a good conceptual fit with the way end-users visualize business data. Most business people already think about their businesses in multidimensional terms. These are some reasons which lead the importance of multi-dimensional database.[1,Kenan Systems Corporation]

2

Multidimensional database

A multidimensional database is a computer software system designed to allow for the efficient and convenient storage and retrieval of large volumes of data that is (1) intimately related and (2) stored, viewed and analyzed from different perspectives. These perspectives are called dimensions. .[1,Kenan Systems Corporation]

Relational databases store data in a two dimensional format, where tables of data are presented as rows and columns. Multi-dimensional database systems offer an extension to this system to provide a multi-dimensional view of the data (Rand). For example, in multi-dimensional analysis, data entities such as products, regions, customers, dates etc. may all represent different dimensions.

Relational Vs Multi-Dimensional Database Structures

The relational database model uses a two-dimensional structure of rows and columns to store data, in tables of records corresponding to real-world entities. Tables can be linked by common key values. E.F. Codd first designed this model in 1970, while working for IBM, and its simplicity revolutionized database usage at the time. Codd's work was in many ways ahead of its time, as computing power could not support the overheads of his database system [2,Hasan].

In the 1980s the power of computers had grown to the point where these overheads were no longer a problem, and today relational database management systems (DBMS) are available on local desktops, as well as large organizational database management servers.

The techniques of entity-relationship (ER) modeling and the structuring of data in normalized tables have become popular with trained database administrators and designers, who routinely use relational DBMS to store huge volumes of organizational data with very high transaction rates.

Although deceptively simple to design and operate, relational database simplicity for the end-user does fall down when it comes to running queries. Accessing data from relational databases may require complex joins of many tables and is distinctly non-trivial for untrained end-users, who may be forced to hire IT professionals to structure such queries in a query language, such as SQL. When queries of a writing nature are run, such as INSERT, DELETE and ALTER TABLE, the consequences of getting it wrong are greatly increased when they are employed on a live system environment.

3

Fig-1 A typical 3D hypercube

Multi-Dimensional Database System

In a multi-dimension database system, the data is presented to the user in such a way as to represent a hypercube, or multi-dimensional array, where each individual data value is contained within a cell accessible by multiple indexes. A simple example is given in the previous diagram, Figure 1, where a fictional student exam result database is presented. This database contains three dimensions, namely Result, Student Name and Exam. In this example, an individual student (represented by Student Name) may have their exam results for several exams compared over a period of time, for example a four-year undergraduate course. This ability to present data in such a top level view is unique to multi-dimensional systems, and shows just how powerful these systems can be. Of course a multi-dimensional system is not limited to three dimensions as in the previous example, but when we go beyond that amount, it becomes more difficult to present such structures in a pictorial view. If we stick with the previous example presented in Figure 1; let us now add a fourth dimension called Subject. Let us assume our students study computer science, with subjects in Databases, Programming and Software Engineering. If we imagine this new dimension as being a box containing our previous three dimensions, then we would have three such boxes, namely one for each subject that our students were tested on, as shown in Figure-2

4

Fig-2 subject wise 3D hyper cube

Evaluation of multidimensional database model

Multidimensional models categorize data either as facts with associated numerical measures or as textual dimensions that characterize the facts. In the case of a retail business, a purchase would be a fact and the purchase amount and price would be measures; the type of product being bought and the purchase time and location would be dimensions. Queries aggregate measure values over a range of dimension values to provide results such as total sales per month of a given product. Multidimensional data models have three important application areas within data analysis.

Data warehouses are large repositories that integrate data from several sources in an enterprise for analysis.

Online analytical processing (OLAP) systems provide fast answers for queries that aggregate large amounts of detail data to find overall trends.

Data mining applications seek to discover knowledge by searching semi automatically for previously unknown patterns and relationships in multidimensional databases.

Academic researchers have proposed formal mathematical models of multidimensional databases, while industry has implicitly specified proposals via the concrete software tools that implement them.[3,T.B. Pedersen, C.S. Jensen, and C.E. Dyreson,,4,P. Vassiliadis and T.K. Sellis,] The “Multidimensional Database History” sidebar describes the evolution of

5

the multidimensional data model and how it has benefited from the use of semantic as well as scientific and statistical data model.

SPREADSHEETS AND RELATIONS

A spreadsheet such as that shown in Table 1 is a useful tool for analyzing sales data such as product sold, number of purchases, and city of sale. A pivot table is a two-dimensional spreadsheet with associated subtotals and totals that supports viewing more complex data by nesting several dimensions on the x-axis or y-axis and displaying data on multiple pages. Pivot tables generally support interactively selecting data subsets and changing the displayed level of detail.

Spreadsheets are an inadequate tool for managing and storing multidimensional data because they tie data storage too tightly to the presentation—they do not separate the structural information from the desired views of the information. Thus, adding a third dimension such as time or grouping the data into higher-level product types requires a considerably more complex setup. The obvious solution is to use a separate spreadsheet for each dimension, but this will work only to a limited extent because analyzing the additional values of the extra dimension quickly becomes unwieldy.

Using a Structured Query Language database management system offers considerable flexibility in structuring data. However, formulating many desirable computations such as cumulative aggregates (sales in year to date), combining totals and subtotals, or determining rankings such as the top 10 selling products is difficult if not impossible in standard SQL. Also, transposing rows and columns requires manually specifying and combining multiple views. Although SQL extensions such as the data cube operator [5,J. Gray et al.,] and query windows[6,A. Eisenberg and J. Melton,] will remedy some of these problems, the SQL-based relational model does not handle hierarchical dimensions satisfactorily. Spreadsheets and relational databases provide adequate support for a small volume of data that has only a few nonhierarchical dimensions, but they do not fully support the requirements for advanced data analysis. The only robust solution is to use database technology that offers inherent support for the full range of multidimensional data modeling.

6

CUBES

Multidimensional databases view data as cubes that generalize spreadsheets to any number of dimensions. In addition, cubes support hierarchies in dimensions and formulas without duplicating their definitions. A collection of related cubes comprises a multidimensional database or data warehouse. Because dimensions in a cube are first-class, built in concepts with associated domains, cubes can easily manage the addition of new dimension values. Although the term implies three dimensions, a cube can theoretically have any number of dimensions; in fact, most real-world cubes have four to 12 dimensions.[ 7,R. Kimball, ,8,E. Thomsen,] Current tools often experience performance problems when a so-called hypercube contains more than 10 to 15 dimensions. Combinations of dimension values define a cube’s cells. Depending on the specific application, the cells in a cube range from sparse to dense. Cubes tend to become sparser as dimensionality increases and as the dimension values’ granularities become finer. Figure 3 shows a cube capturing the sales for the two Danish cities in Table 1 with the additional dimension of time. The corresponding cells store the number of sales. The example has a fact—a nonempty cell that contains a number of associated numerical measures—for each combination of time, product, and city where at least one sale was made. The cells store numerical values associated with a fact—in this case, the number of sales is the only measure. Generally, a cube supports viewing only two or three dimensions simultaneously, but it can show up to four low-cardinality dimensions by nesting one dimension within another on the axes. Thus, cube dimensionality is reduced at query time by projecting it down to

Fig-3 Sample cube capturing sales data. Data cubes support viewing of up to four low-cardinality dimensions simultaneously. In this case, the cube generalizes the spreadsheet from Table 1 to three dimensions.

7

2D or 3D by aggregating the measure values in the projected- out dimensions, resulting in higher-level measure values for the desired data view. For example, to view sales by city and time, we aggregate over the entire product dimension for each combination of city and time. Thus, in Figure 1, adding 127 and 211 yields the total sales for Copenhagen in 2001.

DIMENSIONS

Dimensions are an essential and distinguishing concept in multidimensional databases. An important goal of multidimensional modeling is to use dimensions to provide as much context as possible for facts.[7,R. Kimball], In contrast to relational databases, controlled redundancy is generally considered appropriate in multidimensional databases if it increases the data’s information value. Because multidimensional cube data is often derived from other sources—for example, a transactional relational system—rather than being “born” in the multidimensional cube, the redundancy problems related to updates can be managed more readily.[7, R. Kimball,]

There is usually no redundancy in the facts, only in the dimensions. Dimensions are used for selecting and aggregating data at the desired level of detail. A dimension is organized into a containment-like hierarchy composed of numerous levels, each representing a level of detail required by the desired analyses. Each instance of the dimension, or dimension value, belongs to a particular level.

It is sometimes advantageous for multidimensional models to define multiple hierarchies for a dimension— for example; the model can define time as both fiscal year and calendar year. Multiple hierarchies share one or more common lowest levels—for example, day and month—and the model groups them into multiple levels higher up—fiscal quarter and calendar quarter—to allow easy reference to several ways of grouping. To avoid duplicating definitions, the cub or multidimensional database metadata defines the dimension hierarchy. Figure 4 shows the schema and instances of a sample location dimension for the sales data in Table 1. Of the location dimension’s three levels, City is the lowest. City-level values are grouped into country-level values— for example, Aalborg and Copenhagen are in Denmark. The T level represents all of a dimension. In some multidimensional models, a level has a number of associated properties that hold simple, nonhierarchical information. For example, the package size can be a level property in the product dimension. A package-size dimension could also capture this information. Using the level property does not increase the cube’s dimensionality. Unlike the linear spaces used in matrix algebra, multidimensional models typically do not include ordering or distance metrics for the dimension values. Rather, the only ordering is that higher-level values contain lower-level values. However, for some dimensions such as time, an ordering of the dimension values is used to calculate cumulative information such as total sales to date.

8

Most models require dimension hierarchies to form balanced trees—the hierarchy must have uniform height everywhere, and each non top value has precisely one parent.

Fig-4 Sample schema and instances of the location dimension. Every dimension value is part of the T value

FACTS

Facts represent the subject—the interesting pattern or event in the enterprise that must be analyzed to understand its behavior. In most multidimensional data models, facts are implicitly defined by their combination of dimension values; a fact exists only if there is a nonempty cell for a particular combination of values. However, some models treat facts as first-class objects with a separate identity. Most multidimensional models also require mapping each fact to one value at the lowest level in each dimension, but some models relax this mapping requirement.[3,T.B. Pedersen, C.S. Jensen, and C.E. Dyreson,] Each fact has a certain granularity determined by the levels from which its combination of dimension values is drawn—for example, the fact granularity of the cube in Figure 1 is year by product by city. Granularities consisting of higher- or lower-level dimension values than a given granularity—such as year by type by city and day by product by city—are coarser or finer, respectively. Data warehouses commonly include three types of facts: [7, R. Kimball,]

Events at least at the finest granularity, typically model real-world events, with one fact representing the same instance of an underlying phenomenon.

Examples include sales, clicks on a Web page, or movement of goods in and out of a warehouse.

Snapshots model an entity’s state at a given point in time, such as store and warehouse inventory levels and the number of Web site users. The same instance of the underlying real-world phenomenon— such as a specific can of beans on a shelf— may occur in several facts at different points in time.

9

Cumulative snapshots handle information about activity up to a certain moment. For example, the total sales up to and including the current month this year can be easily compared to the figure for the corresponding month last year. Because they support complementary classes of analyses, a given data warehouse often contains all three types of facts. Indeed, the same base data—for example, the movement of goods in a warehouse—can be included in three different types of cubes: warehouse flow, inventory, and flow in year to date.

MEASURES

A measure consists of two components:

A fact’s numerical property, such as the sales price or profit; and A formula, usually a simple aggregation function such as sum, that can combine several

measure values into one.

In a multidimensional database, measures generally represent the properties of the fact that the user wants to optimize. Measures then take on different values for various dimension combinations. The property and formula are chosen to provide a meaningful value for all combinations of aggregation levels. Because the metadata defines the formula, the data is not replicated as in a spreadsheet. Most multidimensional data models have measures, but some rely on using dimension values to make computations at the expense of user friendliness.[3, T.B. Pedersen, C.S. Jensen, and C.E. Dyreson,]

Three classes of measures behave quite differently in computations:

Additive measures can be meaningfully combined along any dimension. For example, it makes sense to add total sales for the product, location, and time because this causes no overlap among the real-world phenomena that generated the individual values.

Semi additive measures cannot be combined along one or more dimensions. For example, summing inventory across products and warehouses is meaningful, but summing inventory levels across time does not make sense because the same physical phenomenon could be counted several times.

Non additive measures cannot be combined along any dimension, usually because the chosen formula prevents combining lower-level averages into higher-level averages. Additive and non-additive measures can occur for any kind of fact, while semi-additive measures generally occur for snapshot or cumulative snapshot facts.

10

QUERYING

A multidimensional database naturally lends itself to certain types of queries:

Slice-and-dice queries make selections to reduce a cube. For example, we can slice the cube in Figure 2 by considering only those cells that concern bread, and then further reduce this slice by considering only the cells for the year 2000. Selecting a single dimension value reduces the cube’s dimensionality, but more general selections are also possible.

Drill-down and roll-up queries are inverse operations that use dimension hierarchies and measures to perform aggregations. Rolling up to its top value corresponds with omitting the dimension. For example, rolling from City to Country in Figure 3 aggregates the values for Aalborg and Copenhagen into a single value— Denmark.

Drill-across queries combine cubes that share one or more dimensions. In relational algebraic terms, this operation performs a join.

Ranking or top n/bottom n queries [8, E. Thomsen,] can return only those cells that appear at the top or bottom of the specified order—for example, the 10 bestselling products in Copenhagen in 2000.

Rotating a cube allows users to see the data grouped by other dimensions. Drill-down and roll-up queries can be combined with slice-and-dice queries.

Implementation

Multidimensional database implementations take two basic forms:

Multidimensional online analytical processing (MLOAP) stores data on disks in specialized multidimensional structures. MOLAP systems typically include provisions for handling sparse arrays and apply advanced indexing and hashing to locate the data when performing queries.[6 E. Thomsen,]

Relational OLAP (ROLAP) systems [7,R. Kimball,]use relational database technology for storing data, and they also employ specialized index structures, such as bit-mapped indices, to achieve good query performance. MOLAP systems generally provide more space-efficient storage as well as faster query response times.

11

Advantages of Multidimensional DBMS

The performance advantages offered by multidimensional technology facilitate the development of interactive decision support applications that can be impractical in a relational environment. It must be noted that any data manipulation action possible with a multidimensional database is also possible using relational technology. Multidimensional databases offer several advantages, however:

Ease of Data Presentation and Navigation: Intuitive spreadsheet-like data views are the natural output of multidimensional databases. Obtaining the same views in a relational world requires the end user to either write complex SQL queries or use an SQL generator against the relational database to convert the table outputs into a more intuitive format. Even for end users well skilled in SQL, some forms of output, such as ranking reports (i.e. top ten, bottom 20%), simply cannot be performed with SQL at all!

Ease of Maintenance: Multidimensional databases are characterized by extreme ease of maintenance. Because data is stored in the same way as it is viewed (i.e. according to its fundamental attributes), no additional overhead is required to translate user queries into requests for data. To provide this same level of intuitiveness, relational databases use indexing and sophisticated joins which require significant maintenance and storage.

Performance: Multidimensional databases achieve performance levels that are difficult to match in a relational environment. These high performance levels enable and encourage OLAP applications. Comparable performance levels can be approached in a relational environment through database tuning (indexing and keys), but the database cannot be tuned for all possible ad hoc queries. Performance is query specific, resulting in lost flexibility. Tuning also requires the resources of an expensive Database Specialist

Multi-Dimensional Database System – Where not to Use?

At this stage, given the previously stated advantages, we might be forgiven for thinking that all databases should be converted to multi-dimensional systems. There are examples where this is not required, however, or may not even make any sense at all. Take the example of the students, suppose our fictional college keeps a table of student personal information, like this one below:

12

Lastname Firstname Student No Age Course

Collins John 111 25 Comp Science

Wall Larry 222 55 Comp Science

Torvalds Linus 333 26 Comp Science

Table 2 student name, age and course

Let is imagine a two-dimensional view or slice of this information, as generated by a multi-dimensional system, where Last-name and First-name are the dimensions, and Age is contained within the cell values, as below

Two-Dimensional Array of Student Age

Table 3 two dimensional view

As we can see, we end up with a sparsely populated array, as opposed to the array we would have obtained from Table 2 if we would have taken Student Name and Exam as dimensions, where we would have a fully populated array of exam results as presented in that diagram.

Our slice above yielded a 3x3 array containing 9 cells, but only 3 of these cells actually contain an age value, leaving 6 empty! If the dataset where larger, which in all likelihood it would be, then our two-dimensional array would be mostly empty.

The dataset in the student personal information table is not multi-dimensional, as there is no inherent relationship between the elements of the different records. No last name is matched to more than one student number, while no age is matched to more than one course, or indeed is the any logical relationship between the two elements. This example produced a sparsely populated multi-dimensional array, whereas our first example in Table 2 presented a fully populated 3x3 multi-dimensional array, where all dimensions of that array intersected neatly on an exam result.

13

Collins 25

Lastname Wall 55

Torvalds 26

Linus Larry John

For performance reasons, it would also be unwise to store such a dataset in a multi-dimensional system. In relational form, a search would require 3 comparisons, whereas in multi-dimensional form a search would require 9 comparisons (3x3), thereby reducing efficiency.

Apart from performance considerations, there is no inherent value in storing non-multi-dimensional data in a multi-dimensional database. Multi-dimensional databases are designed to ease the manipulation and analyzing of complex database structures, which are structures that have large amounts of inter-relationships. In the student personal information example, a user accessing this information would not require that kind of analytical power, they simply want to view or edit a particular student's record. Because there are a limited number of meaningful relationships between the data elements of the dataset, and the information content of this database resides in the informational context of the individual data records, it is not a suitable candidate for a multi-dimensional database system.

This raises a fundamental observation: multi-dimensional database technology is a complementary technology to relational database technology, not a direct replacement.

A further observation can be made for the business application of multi-dimensional systems at this stage [9,Kenan]: The greater the number of inherent inter-relationships between the elements of a dataset, the more likely it is that a study of those inter-relationships will yield business information of value to the company.

It is clear that where these inter-relationships exist, especially in a commercial environment, that such relationships have a real-world meaning to the organization that is worth analyzing over time, that is by the process of trend analysis, and that it is multi-dimensional systems that facility the analysis of these trends, via OLAP (On-Line Analytical Processing). Indeed it has become evident that the process of management is greatly aided by information arranged by subject (dimension) rather than by operational applications [10,Baum 1996].

Features of Multi-Dimensional Database Systems

Rotation: Due to the layout of data in a multi-dimensional database, certain views of the data can be generated at ease by a multi-dimensional system. In fact, viewing a multi-dimensional view (or slice) is similar to viewing data on a spreadsheet table. To get a better understanding of this, consider the example given previously in Table 2, with a 3x3x3 array containing student exam results.

14

If we imagine a slice of a database being a view of one of the faces of the hypercube, then for this example we have 6 available slices. In fact, the number of possible slices increases exponentially with the number of dimensions [9,Kenan], so a two-dimensional array has two views, a three-dimensional has six, a four-dimensional has 24 and a five has 120 views.

The six available views for our student database in table 2 are:

Student Name by Exam. Exam by Student Name. Exam by Semester. Semester by Exam. Student Name by Semester. Semester by Exam.

The mechanism by which a view is selected is often referred to as data rotation. For example, if we can imagine that we are looking at the Student Name by Exam face (view) of the cube in Table 2, now if we rotate that view 90 degrees clockwise around the y-axis (i.e. the Student Name dimension), then we are now looking at a different view of the database, namely Student Name by Semester. In a multi-dimensional database system, it is possible to view the data from any such rotation.

Ranging: A well-designed multi-dimensional database allows users to range in on particular subsets of the database, to their specification. For example, an example of a range might be an array containing all results for semesters 1 and 2 for the subjects Databases and Programming. Ranging is comparable to complex queries in a rational system, and is often referred to as data dicing because it is scoped down to a subset of the overall array.

The performance of ranging in a multi-dimensional system is once again greater than the relational equivalent, as few overheads are incurred in the multi-dimensional system to obtain the required view of the data.

Hierarchies, Roll-Up and Drill-Down: As previously discussed, users may want to view data from several perspectives, although sometimes these views may be very similar. For example, a user might want to view exam results for a class or the entire school for a particular year. There is a natural relationship between this entities, it is simply a matter of scale that separates them apart. Multi-dimensional databases are designed with these natural relationships in mind. Although it would be possible to create a separate dimension for Class and School, a more powerful solution is to create two related aggregates on the same dimension, which can then be used as part of the same dimension.

15

Therefore, as all examples of a Class are contained within a School, School is a higher-level aggregation within the overall dimension we can now call College. When we relate each position along the Class aggregation to a position along the School aggregation, we have defined a hierarchy within the overall College dimension.

The ability to move up and down along these newly created hierarchies is referred to as roll-up and drill-down. The chosen level along each dimension now defines each view, which can also be rotated or ranged as previously described.

Conclusion

Finally if we conclude we have to see some of the main characteristics of the multi-dimensional database structure, and provided an analysis of its effectiveness when compared to that of more traditional entity relationship database systems. And also, concludes that multi-dimensional database systems are a complementary technology to entity relational systems, and in some circumstances it makes more sense to use relational tables rather than multi-dimensional arrays.

Where multi-dimensional systems excel over their relational system counterparts is in the area of data presentation and analysis, where the data in question lends itself to being suitable for multi-dimensional systems, such as where complex inter-relationships exist. The top-level views of data over many combinations of dimensions make multi-dimensional systems particularly useful for trend analysis over time by management staff of organizations, due to the ease of viewing the data in a more naturally intuitive way

16

References

[1]1993-1995 Kenan Systems Corporation

[2]Hasan Helen (1999) Effective Information for Managers: Using Multi-Dimensional Data Structures to Support Research Management, 10th Australian Conference on Information Systems, 1999.

[3]T.B. Pedersen, C.S. Jensen, and C.E. Dyreson, “A Foundation for Capturing and Querying Complex Multidimensional Data,” Information Systems, vol. 26, no. 5, 2001, pp. 383-423.

[4]P. Vassiliadis and T.K. Sellis, “A Survey of Logical Models for OLAP Databases,” ACM SIGMOD Record, vol. 28, no. 4, 1999, pp. 64-69.

[5]J. Gray et al., “Data Cube: A Relational Aggregation Operator Generalizing Group-By, Cross-Tab and Sub- Totals,” Data Mining and Knowledge Discovery, vol. 1, no. 1, 1997, pp. 29-54.

[6]A. Eisenberg and J. Melton, “SQL Standardization: The Next Steps,” ACM SIGMOD Record, vol. 29, no. 1, 2000, pp. 63-67.

[7]R. Kimball, The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses, John Wiley & Sons, New York, 1996.

[8] E. Thomsen, OLAP Solutions: Building Multidimensional Information Systems, John Wiley & Sons, New York, 1997.

[9] [10]Kenan Technologies, An Introduction to Multidimensional Database Technology, 1993-1995.

[10]Baum D. (1996) Data Warehouses, Building Blocks for the Next Millennium, Oracle Magazine, March/April, 34-43.

[11]Cover feature of multidimensional database technology: Torben Bach Pedersen Christian S.Jensen Aalborg University.

[12]An Assessment of Multi-Dimensional Databases and their Use: Author: John Collins

17