Perhaps you've seen or used a child's toy that includes a hammer of some sort. Kids just love hammer toys. They seem to have some pre-wired talent for hammering. Watching them learn the art of hammering can be entertaining, too--at least at first. Then comes the moment when they realize that it might be fun to hammer other things in their environment. Like the cat, the dog, the coffee table and their siblings. So, we teach them that hammers are good in some situations and not so good in others.

In this regard, the operational data store (ODS) has some remarkable similarities to the hammer. The ODS has been around for a while. It is gaining acceptance and credibility as a tool. But unfortunately, the ODS is being used where another tool would probably work better.

To get the most out of any tool, the user should understand its features. Experience using the tool is obviously a plus, as well. To help you optimize the performance of your ODS, this article includes the primary features of an ODS along with highlights of my experiences "hammering."

ODS Features

Every tool is defined by its features, and the ODS is no exception. Furthermore, similar tools are distinguished by their unique features. For example, mallets, hatchets, ball peens and rig axes are all hammers, but each has specific features and applications--especially to the experienced user.

When the tools being discussed are rather intangible, such as the ODS, differences may seem to be a matter of semantics, but they are differences nonetheless--again especially to the experienced user. (See sidebar for other terminology differences in the Corporate Information Factory.)

Here are the primary features of an ODS:

Subject-Oriented ODSs are designed and organized around the major data subjects of a corporation-- such as /"customer" or "product." They are not organized around specific applications or functions--such as "order entry" or "accounts receivable."

Integrated ODSs represent a collectively integrated image of subject-oriented data which is pulled in from potentially any operational system. If the "customer" subject is included, then all of the "customer" information in the enterprise is fair game for inclusion in the ODS.

Current-Valued. An ODS reflects the "current" content of its legacy source systems. "Current" may be defined in different ways for different ODSs depending on the requirements of the implementation (see Fryman and Norris-Montanari article also in this issue). An ODS should not contain multiple snapshots of whatever "current" is defined to be. That is, if "current" means one accounting period, then the ODS does not include more that one accounting period's data. The history is either archived or brought into the data warehouse for analysis.

Volatile. Since an ODS is current valued, it is subject to change on a frequency that supports the definition of "current." That is, it is updated to reflect the systems that feed it in the true OLTP sense. Therefore, identical queries made at different times will likely yield different results because the data has changed.

Detailed. The definition of "detailed" also depends on the business problem that is being solved by the ODS. The granularity of data in the ODS may or may not be the same as that of its source operational systems.

"Hammering" with the ODS

I view an enterprise's inventory of information systems as those contained within the Corporate Information Factory. The legacy environment is called "business operations." These include transaction-oriented, day-to-day application systems, grouped by business function or application, each addressing tactical business problems. The next environment is called "business management" and consists of the operational data store. The ODS integrates data from multiple business operations sources to address operational problems that span business functions. The final environment consists of the strategic or "business intelligence" systems. These contain the data warehouse and data marts, permitting the analysis of trends, patterns, exceptions, etc., over time.1

What's In a Name?

Eleven years ago, I was introduced to data warehousing when I attended a three-day class given by Bill Inmon. The architecture that Bill presented for strategic decision support has evolved into the Corporate Information Factory (CIF) through the intervening years. Just as the architecture evolved, so has the terminology used to describe its components. An undue amount of confusion, disagreement and energy has been expended on deciphering the nomenclature from various camps for the same components (data warehouse, data mart, operational data store, etc.).

My goal here is to reduce some of the confusion by giving you a Universal Translator (just like the communicators used in Star Trek) for the nomenclature of the Corporate Information Factory. Now, when you hear Bill Inmon or Ralph Kimball speak or read one of their columns, you can use this table as a reference to aid in your understanding.

CIF Name Definition Bill Inmon Ralph Kimball
Data Warehouse Snapshots of data extracted from operational sources that are integrated, cleansed and loaded in a readily accessible format for strategic decision support. Data Warehouse or Atomic Level Detail Staging Area or Operational Data Store
Data Mart A subset of data warehouse data used for a specific business function whose format may be a star schema, hypercube or statistical sample Departmental Database or Data Mart Data Warehouse (virtual) or Data Mart
Operational Data Store An updatable set of integrated operational data used for enterprise- wide tactical decision making.Contains live data, not snapshots,and has minimal history retained. Operational Data Store None Available
Data Acquisition The process of extracting operational sources of data, integrating it, cleansing it and then either loading snapshots (for the data warehouse) or updating (for the operational data store). Integration and Transformation Extraction or Integration and Transformation
Data Delivery The process of filtering, formatting and delivering data to specific data marts. Used only in the strategic decision support part of the architecture. Summarization and Aggregation Extraction or Integration and Transformation
Understanding this is the key to cutting through the confusion about when and how to use an ODS.

Here are few examples of when and when not to use an ODS.

Good Application of an ODS #1: Subject-area reporting. "It would be great if I didn't have to look at a credit report from accounting, a demographic report from marketing, a sales report from finance and an open order report from order entry just to get a complete picture for this customer." This is a very common requirement. Getting back to the features, it is going to require subject-oriented, integrated, current and detailed information, which will require a transaction-based update mechanism in order to retain integrity and currency.

Good Application of an ODS #2: Functional integration. "We could really increase sub-component inventory turnover at the Dallas final assembly plant if we just could synchronize the Charlotte production line with the one in Atlanta." Again, the solution will require subject-oriented, integrated, current and detailed information, which will require a transaction-based update mechanism in order to retain integrity and currency.

Bad Application of an ODS #1: Single source for all data warehouse data. First, the semantic issues. Is the data subject oriented? Yes. Is it integrated? Yes. Is it detailed? Maybe. Is it current? No. Is it volatile? No. In addition, the business problem is not operational. So, the construct is not an ODS. That does not make it wrong, it just is not an ODS. Next, the practical issues. Staging data warehouse data is not a bad idea, and some of the requisite data may exist only in an ODS, but it is very unlikely that you will be able to efficiently place all of the DW source data in one ODS for staging into the DW.

Bad Application of an ODS #2: The operational data store is used as a department-specific application.

There is a lot of confusion surrounding how the ODS is different from the legacy or operational systems environment. The best way to explain the difference is to look upon the ODS as a corporate-wide system, whereas a legacy or business operations system is quite specific to a particular department or function.

For example, if you build a customer management ODS focusing upon creating an integrated view of all customer information, there will be many departments or functions requesting access to that database. Marketing, sales, billing and even financial people have a need to see this integrated customer record.

Compare that to something like an order entry system that has just enough information to support the creation and processing of an order. This is a very specific set of data for a very specific function for a very specific set of users. You would never think of trying to capture unnecessary data in this system, nor would you allow just anyone access to this data.

Once you know that you need an ODS:

Make sure you have a good enterprise data model before you start. By definition, you will be integrating data from multiple functional business areas and applications. A high-quality, enterprise data model will make the job of understanding and mapping the source data from different areas a whole lot easier.

Do not include every attribute of a subject area in your ODS simply because the data warehouse may need that data. Use only the attributes that are relevant to solving the operational business problem at hand. Remember that every field takes "x" amount of time to extract, integrate, cleanse, verify, etc. If your update mechanism calls for immediate or near-immediate updates, then your success will dictate that you extract fewer fields, each having simpler data acquisition processing. Don't slow the process by including fields that you don't need.

Use an iterative approach. Identify one or more related operational business problems. Prioritize them. Start with one that you can "get your arms around" and that has a strong return on your investment. Then, tackle the rest of the list in phases, in a way that makes the most sense given your situation.


We are still working through many of the implementation issues concerning this new architecture, and I am sure that certain characteristics, technologies and definitions will continue to evolve as we learn more from building these important and critical systems. I hope this article has helped you to understand more about the operational data store, when to build it, when not to and when to determine whether you have an ODS in your Corporate Information Factory future.

1 Imhoff, Claudia. Inmon, W.H. and Sousa, Ryan. Corporate Information Factory. John Wiley & Sons, 1998.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access