This isn’t the first time in recent history that new types of database products have emerged and overcome RDBMS inefficiencies. Back in the 1980s, a class of applications was identified in which RDBMS products ill-handled the data-management needs (especially the generation of RDBMSs available at that time).
These applications all needed user-specified data types that varied among different implementations. For example, computer-aided design/computer-aided manufacturing (CAD/CAM) applications had to be capable of specifying data types that related to product drawings, blueprints, and other related factors.
Computer-aided software engineering (CASE) needed data types to represent applications and systems, databases, graphical representations of entities and attributes, process and data flows, and other parts of the application-development process.
What resulted was object-oriented database management systems (ODBMSs), which eliminated the table-row-column structures of relational databases and instead introduced the concepts of classes and subclasses (or types and subtypes), objects, properties, methods, and the other parts of object-oriented technology directly into the database engine.
Because RDBMS technology wasn’t well-suited to multidimensional analysis, particularly in terms of performance, vendors set out to develop their own structures tuned and optimized for improved performance.
If you track happenings in the database management world, you’re probably familiar with the convergence of relational and object-oriented database technology. RDBMS products are being equipped with object-oriented extensions.
Arguably, this approach to handling complex data types (objects) has won out over non-relational products (pure ODBMSs), primarily because of the large installed base of relational products and applications running on top of them. Will the same thing happen in the data warehousing world — relational technology overtaking and then overwhelming specialized multidimensional products? Only time will tell.