The operational data store (ODS) is the original stealth structure. While there are conferences and seminars for everything under the sun ­ from e- commerce to data warehouses to ERP ­ there are no conferences, seminars or classes on the ODS and its supporting technology. (Or if there are, they are certainly low profile.)

The ODS has been around as long as the data warehouse but has never gained the notoriety or prominence of its more famous brother, the data warehouse.

Different Classes

From the beginning, it was predicted that there would be different classes of ODSs based on how fast data was loaded into the ODS and the source of the load. It was predicted that there would be four classes of ODSs:

  • Class I. Transactions were moved to th e ODS in an immediate manner from applications ­ in a range of one to two seconds from the moment the transaction was executed in the operational environment until the transaction arrived at the ODS. In this case, the end user could hardly tell the difference between an activity that had occurred in the operational environment and the same activity as it was transmitted in the ODS environment.
  • Class II. Activities that occurred in the operational environment were stored and forwarded to the ODS every four hours or so. In this case, there was a noticeable lag between the original execution of the transaction and the reflection of that transaction in the ODS environment. However, this class of ODS was much easier to build and to operate than a Class I ODS.
  • Class III. The time lag between execution in the operational environment and reflection in the ODS is overnight. In a Class III ODS there is a noticeable time lag between the execution of the transaction in the operational environment and the reflection of the transaction in the ODS environment. This type of ODS is relatively easy to build.
  • Class IV. A Class IV ODS is one that is fed from the data warehouse from analysis created by the DSS analyst in the data warehouse environment and condensed down to a point where the results of the analytical processing fit comfortably in the ODS. The input to the ODS can be either regular or irregular. This class of ODS is very easy to build as long as the data warehouse has already been constructed.

As a rule, Class I ODSs are rare. The normal case for an ODS is a type II, III or IV. Class I ODSs are difficult to construct and even more difficult to operate. There needs to be a very strong business case for a Class I ODS.

Figure 1: Types of Operational Data Stores

The notions of different classes of ODSs have been around since ODSs were first recognized as a separate architectural entity. But now that the world has built lots of ODSs, it is interesting to revisit the ODS from the pe rspective of what has been built and what really works.

Prediction Meets Reality

The first type of an ODS built, shown at the top of Figure 1, is an ODS where whole tables are copied on a wholesale basis from the operational environment. While this is a form of an ODS, it is a very weak form. The only thing to recommend this form is that it is easy to build. It cannot be used where there are large operational tables. Data starts to age immediately from the moment that replication is done. Even for modest-sized tables, it requires many machine resources. There is absolutely no integration of data in this form of an ODS. In short, not many advantages of the ODS are apparent here. This form of ODS tends to have a very short life. This form of ODS is not a class I, II, III or IV. If anything, it is a Class 0 ODS.

The second form of an ODS is one where transactions are shipped to the ODS in a quick and wholesale manner. In this case, the transaction execute s in the operational environment, and then quickly passes over to the ODS. Data is not integrated along the way. Because there is no integration, it is easy to build this style of ODS. The data is not fit to place in the data warehouse, but at least the data enters the ODS quickly. This is a classical Class I ODS.

The third form of an ODS that has been created is the kind where data indeed passes through an integration and transformation layer. In this case, data is truly integrated. Because data must be integrated, there is a time lag from the moment when the transaction is executed in the operational environment until such time as the results of the transaction are reflected in the ODS. This type of ODS is difficult to build because the integration and transformation programs must be built. However, data is fit for entering the data warehouse after passing through the integration and transformation layer. This is a classical Class II or III ODS.

The fourth type of an ODS is fed aggregated analytical data from the data warehouse. The DSS analyst looks over a body of data in the data warehouse and decides that the data might be useful as the company interacts with its customer base. The DSS analyst packages up the analytical data and passes it to the ODS. In such a manner, a corporation has access to analytical data in an online, real-time fashion. This interface is easy to build, assuming the data warehouse has already been constructed. This is a Class IV ODS.

The fifth type of ODS is one where there is a combination of integrated data from the operational environment and aggregated data from the analytical environment. This is the most powerful ODS and is the most difficult to construct. This is a combination of a Class II, III and IV ODS. While this form of ODS is difficult to construct, it is easily the most powerful form of ODS.

The Votes are In

Reality has shown that different forms of ODSs have been built. Some of the ODS forms have a short life span in terms of user satisfaction. Other forms of the ODS have a much longer life span. As a rule, the easier the ODS is to build, the shorter the life span. The real worth of the ODS appears in the ability to hold integrated data. The integrated data is always difficult to build ­ but once built has real corporate worth.

Another place where the ODS has found real worth is as a vehicle to apply analytical data against the customer in a real-time mode. There has always been a dilemma facing the data warehouse administrator with the data warehouse environment in that upon doing an incisive analysis, the DSS analyst was frustrated that there was no direct or easy way to apply the analytical findings to the day-to-day operations of the corporation. By placing the results of analysis into an ODS, the DSS analyst now has a convenient way to take the discoveries made in the data warehouse and deliver them to the customer firsthand.

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