[Table of Contents] [Previous Section] [Next Section]

Problem/Solution Statement

The Problem

Data processing requirements will continue to grow for the foreseeable future, yet staff and financial resources for DBMS applications and support will continue to be stretched thin. Managers are awash in data that they need to use in a variety of ways to maintain their competitive advantage. DBMS systems and tools must quickly evolve to manage the forthcoming data explosion.

The Solution

The obvious solution to the problems facing today's DBMS managers is to use a central "industrial strength" data storage facility such as that provided by a relational DBMS (RDBMS), but one which extends the relational model to incorporate additional data types and operators. This is precisely what THOR has implemented in its Object Relational Database (ORDBMS) model.

The Major Issues

THOR™ addresses four major issues currently facing DBMS managers and administrators:

Overcoming performance barriers

Current OLTP implementations are reaching performance barriers. Systems cannot scale beyond a certain point, and performance barriers are being reached.

Controlling costs

Achieving maximum value for money spent is critical. Budgets are not growing as fast as performance requirements. As data processing requirements expand, systems need to scale appropriately.

Supporting new data types

New and more complex data types are becoming increasingly important in data processing environments. Managers need to query and report on non-traditional data using the same management tools available to work with traditional data types.

The changing data processing trend

The competitive power of complex query applications is no longer in doubt. Though they go by many names, including DSS (Decision Support System), Data Warehousing, Data Marts, OLAP (Online Application Processing), Data Mining, etc., these applications are rapidly becoming indispensable to any world-class enterprise. Data sets are growing significantly, requiring more processing power than many current OLTP implementations.

OLTP and DSS/OLAP differences

Introduction

There are three fundamental differences between OLTP and DSS/OLAP systems:

Larger databases

Some data warehouses are far larger than the databases common in OLTP, and the data to be analyzed are growing faster than processor power is increasing. Symmetric Multi-Processing (SMP) systems that easily handle large OLTP applications cannot scale fast enough to grow as data warehouse applications will, and are reaching performance limits.

More complex queries

OLAP consists of queries that are more complex than OLTP queries. Complex queries are much harder to parallelize than the simple atomic transactions of OLTP. Parallel systems engineered for OLTP and SMP systems can falter under the load imposed by complex queries.

Non-traditional data types and operators

Not all forms of data fit neatly into the SQL tables common in OLTP applications. Today's vastly increased system capability has made possible a broad range of business applications. Data warehouses must increasingly house data that doesn't fit the traditional models of numbers or text, such as: time series data in the finance industry; geographic data in many industries; and pictures, images, video and sound in Intranet and Internet applications.

The limitations of the relational model have become a significant problem for a new generation of applications. Work is underway in the SQL language standards community to address these market requirements in the SQL3 standard, but this will not be ratified before 1998 at the earliest. Customers are demanding relief before then.

THOR's Object-Relation model meets the criteria for a real solution

Introduction

THOR's unique ORDBMS design addresses all the issues discussed to this point. But no matter how elegantly designed or how highly optimized for speed, a solution isn't a solution if it doesn't meet other basic criteria. Specifically, DBMS managers and administrators need a solution that is easy to administer, scaleable, extensible, and open.

Easy to administer

THOR reduces the system administrator's burdens of tuning the databases, optimizing queries, and partitioning distributed data, performing these tasks with significantly less manual intervention than current systems require. THOR also incorporates a number of RAS (Reliability, Availability, and Serviceability) features to ensure minimal down time and rapid recovery from system problems.

Scaleable

THOR lets you "rightsize" your hardware as your processing requirements grow, increasing processing speed almost linearly as new processors are added.

Extensible

THOR has an object-oriented foundation, making it easy to support new data types and data operators. At the same time, THOR works with your existing SQL-based RDBMS, enabling you to build object support on top of (rather than in place of) your current implementation.

Open

THOR uses existing tools and applications and leverages current RDBMS investment to the greatest extent possible.

Only one database system meets all these criteria - THOR

THOR Tower configuration
[Table of Contents] [Previous Section] [Next Section]