-
Marketplace
-
Channel Resources
Articles from this Site
Emerging Trends in the World of BI, Part 1
Pentaho Brings BI Suite to iPhone
Brotherhood Mutual Selects Information Builders BI
CN Moves Forward with Netezza
Matalan To Increase Profits With SAS' Enterprise Intelligence Platform
White Papers
HP ERP Business Intelligence
Business Intelligence for Tax Planning: Value, Strategy, and Vision
Single Sign-On for Webintelligence
A Structured Method for Specifying Business Intelligence Reporting Systems
Business Intelligence in a Real-Time World
Web Seminars
Looking for speed and accuracy in your financial planning and budgeting?
Hyperion Visual Explorer: Improve Visibility into Performance Management
Reducing the Cost of Deploying and Managing Data
Combining Microsoft Business Intelligence with the Teradata Warehouse
Espresso Shot Web Seminar: Uncorking the Data Bottleneck with Operational BI
Books
Real-Time Decision Support Systems?
Information Management
Occasionally the notion arises that decision support system (DSS) processing should be real time. Real time means that response time should be in the three-to-five-second range from the moment that a query is formulated and initiated in the processor. The rationale for real-time processing is that with good response time, the decision-maker can make better decisions. In many regards, this is akin to the notion that if we made online transactional processing (OLTP) happen, why can't there be real-time DSS?
OLTP is not like DSS. The queries in OLTP processing are predetermined and are not heuristic or intuitive at all. The queries must be carefully formulated and programmed before the user ever gets to execute a query. In OLTP, the data is designed for optimal passage through the system. As a result, in OLTP each query accesses only a few units of data. All of this structure is needed in order for the OLTP system to provide fast and consistent response time. In order to get fast and consistent response time, the requirements for OLTP processing must be known before any processing occurs, and the system needs to be finely tuned and designed.
The very nature of DSS processing is the opposite of OLTP processing. In the world of DSS processing, the requirements for processing are not known before the processing begins, and the queries are not predetermined. As a result, many queries are formulated, executed once and never run again. Many queries access huge amounts of data; as a result, DSS processing yields response time that is irregular. Some queries execute quickly and other queries execute in a matter of hours. Complicating the DSS environment is the fact that the environment has many different types of queries executing within its boundaries. The DSS environment is a decidedly mixed workload with some queries doing simple data access and other queries doing massive statistical analysis of data. For these reasons, there is no such thing as real-time processing in the DSS environment.
There is a form of real-time DSS processing that occurs in the operational data store (ODS) environment. The ODS environment is designed for the purpose of satisfying online real-time demands for DSS data. However, in order to do this, the ODS environment must find structure and discipline in processing. This means that at least part of the ODS environment must be disciplined in the same way as the OLTP environment. The fact that part of the ODS environment is structured one way and other parts are structured otherwise means that the ODS environment is one of the most difficult environments to construct.
These are good reasons why real-time DSS is a questionable idea in any case - but there is another reason. Fast, operational decisions are made on small amounts of data, and long-term strategic decisions are made on sweeping amounts of data. It takes a computer only a few microseconds to process a few amounts of data and a little longer to process even larger amounts of data. For example, suppose a person goes into a bank and asks to cash a check. The bank teller (human or ATM) checks the person's bank balance. The person receives verification one way or the other and the check can be cashed. All of this occurs in a flash and requires access to a very small amount of data. The decision is operational in nature and fast response time is achieved.
Now consider a different type of decision. The bank wants to know whether more ATM machines should be placed in Berkeley, California. The bank has many factors to consider, such as:
- How many ATM machines does the bank already have there?
- How many other banks have ATM machines?
- How many people are there for each current ATM machine?
- What are the demographics of the people that are being served?
- What demographic changes are occurring?
- What would be the most propitious place to put the ATM machines?
- What type of cards should be honored?
Many factors need to be considered before making the investment for the placement of new ATM machines in various locales. The decision is not one that a bank makes in an afternoon. Furthermore, the consequences of making the decision at 10:05 a.m. versus 10:35 a.m. are inconsequential. Response time is simply not an issue when it comes to making this sort of decision. Having complete, accurate and integrated internal and external information is all that is needed. Access and availability to information at any reasonable response time is the issue.
Bill Inmon is universally recognized as the father of the data warehouse. He has more than 35 years of database technology management experience and data warehouse design expertise. His books have been translated into nine languages. He is known globally for his seminars on developing data warehouses and has been a keynote speaker for many major computing associations. For more information, visit www.inmongif.com and www.inmoncif.com. Inmon may be reached at (303) 681-6772.
For more information on related topics, visit the following channels:


