Web-enabled OLAP Tutorial

- DW Overview

--------Back-end Tools

- Intro to OLAP

--------Codd's 12 Rules

- MD Data Structures

- OLAP Server

- OLAP Operations

- OLAP Architectures

--------MOLAP: Part I
--------MOLAP: Part II
--------ROLAP: Part I
--------ROLAP: Part II

- Data Explosion

- OLAP Criteria

- Glossary

- References

Intro to OLAP: Codd defined 12 Rules

The term OLAP was first introduced by E. F. Codd, who pioneered Relational Database Management Systems (RDBMS). Below are the twelve rules defined by Codd that OLAP technology must support.

Multidimensional conceptual view
Supports EIS (Executive Information System) slice and dice operations and is usually required in financial modeling.
Is part of an open system that supports heterogeneous data sources. Furthermore, the end user should not be concerned about the details of data access or conversions.
Presents the user with a single logical schema of the data. OLAP engines act as middleware, sitting between heterogeneous data sources and an OLAP front-end.
Consistent reporting performance
Performance should not degrade as the number of dimensions in the model increases.
Client/server architecture
Requires open, modular systems. Not only the product should be client/server but the server component of an OLAP product should allow that various clients could be attached with minimum effort and programming for integration.
Generic dimensionality
Not limited to 3-D and not biased toward any particular dimension. A function applied to one dimension should also be able to be applied to another.
Dynamic sparse-matrix handling
Related both to the idea of nulls in relational databases and to the notion of compressing large files, a sparse matrix is one in which not every cell contains data. OLAP systems should accommodate varying storage and data-handling options.
Multiuser support
Supports multiple concurrent users, including their individual views or slices of a common database.
Unrestricted cross-dimensional operations
All dimensions are created equal, so all forms of calculation must be allowed across all dimensions, not just the measures dimension.
Intuitive data manipulation
Users shouldn't have to use menus or perform complex multiple step operations when an intuitive drag and drop action will do.
Flexible reporting
Users should be able to print just what they need, and any changes to the underlying model should be automatically reflected in reports.
Unlimited dimensional and aggregation levels
Supports at least 15, and preferably 20, dimensions.