Here’s a working definition of an ODS (it’s a long one): an informational and analytical environment that reflects at any point the current operational state of its subject matter, even though data that makes up that operational state is managed in different applications elsewhere in the enterprise. This list explains each part of the preceding definition:

  • Informational and analytical environment: The user interface and behavior of an ODS look and feel like a data warehouse. So, an ODS user has a querying and reporting tool, an OLAP tool, or possibly other business intelligence tools through which he or she can request and receive information and analysis.

  • Reflects at any time the current operational state: Okay, sit down at your query tool and ask the ODS a question. The answer you get back must reflect data as it’s currently stored in whatever operational system it came from.

    If an update occurs in an operational system to a customer’s checking account balance, the ODS must make that same change in real-time or almost real-time (meaning very quickly). In almost all situations, therefore, extracting batch-oriented data for inclusion in an ODS doesn’t work.

  • Subject matter: Like with a data warehouse, create an ODS with a specific business mission in mind for a manageable set of subject areas.

  • Data managed in different applications elsewhere in the enterprise: An ODS isn’t a single unified database that a number of applications use. Rather, it’s a separate database that receives information from various sources through the appropriate transformations, quality assurance, and other processes.

Some folks declare that an ODS can’t contain historical data — only the current values for all its data elements. They say that if the environment has historical data, it’s a data warehouse, not an ODS.