Chapter 17: The Operational Data Store in SAP BW 2.0

Team-Fly

What is an Operational Data Store (ODS)?

The term ODS is confusing. Is it a data warehouse, part of a data warehouse, or something else? ODS has several academic definitions in the data warehouse industry. However, the definition varies based on usage.

In Building the Operations Data Store, (see Appendix A), William H. Inmon, Claudia Imhoff, and Greg Battas define ODS as a

subject oriented, integrated, volatile, current valued data store containing only corporate detailed data

to support tactical decisions. At a conceptual level, just about everyone agrees with this definition. However, many differ in defining usage boundaries of ODS and implementation.

History of Operational Data Store

Initially, the ODS was introduced to integrate legacy and transactional applications to increase customer satisfaction, not to make tactical decisions. It had a customer focus in mind. For example, in the banking industry, customers want to see one view of all their accounts, regardless of the individual systems in which they are stored. Here, the role of ODS is to keep an up-to-date summary of all such accounts in the ODS to provide consolidated accounts information to support transactional applications as well as customers outside the company boundaries.

Here, one can value-add the account information from a partnering advertising company to promote a product, hence merging corporate and non-corporate information. Merging company and non-company information in ODS contradicts the definition previously stated.

There are three classes of ODS layers, most commonly known as Class I, Class II, and Class II. The ODS Objects in each class have special characteristics, as listed in Table 17-1.

Table 17-1: Characteristics of Operational Data Store Classes and Their Usage

Functionality

Class I

Class II

Class III

Data refresh rate from its data sources

Synchronous; almost in real time

Asynchronous; Near real time-few minutes to an hour

Asynchronous; Based on analytical application usage and the infrastructure operational requirements

Data volume

Packets

Small-medium

Large

Data Content

Transaction-centric

Business Event-Centric-a mix of transaction and supporting workflow information

Very much; Subject-centric at the atomic level detail

Persistence

Low

Medium

High

Data Transformations

Very little just to conform to data interchange format

Moderate-compose data structures by combining transaction and value-added information for DSS

Extensive-Cleansing, extraction, and transformation to construct atomic level data sets

Availability

High

Medium

Low

Performance

High-at the speed of intra-application interconnect requirements

Medium-at the speed of business work flow rules requirement

Medium-Low, based on business value and operation costs requirements

Intended usage

Customer facing; Staff; Intra-application interconnect services

Customers; Customer facing and operations staff

Operations management; Data analysis; Customer problem resolution and operations

Technical Infrastructure

Fast and reliable data interchange and data storage technologies-hardware, software-OLTP-centric

Mostly application or database specific store and forward data management technologies

Mostly batch, database, or large data handling technologies to optimize infrastructure resources

Operations Staff

OLTP operations staff-highly visible

OLTP operations staff-less visible

OLTP and data warehouse staff

Business Sponsors

Corporate senior business management

Division or line of business management team

Operations management team

Example

Airline reservation; Critical care medical records

Bank accounts management; supply-chain management

Call center; Manufacturing shop floor operations

The Class I ODS serves mostly as a real-time intra-application interconnect bus. Classes II and III are mostly to support near-real-time business operations. Due to specific time-critical ODS object-usage requirements, use robust flexible technologies to implement ODS objects. The question is then how one can deploy such a diverse ODS environment and the data warehouses under one framework to support e-business and business intelligence. This is where SAP BW technical framework plays a critical role in constructing, delivering, and managing all information objects, including ODS, OLAP, data marts, data warehouse, document warehouse, and extraprise data warehouse to support CIF under one umbrella.

In BW, 2.0 you can implement an enterprise data warehouse using the ODS objects. This extended ODS capability in SAP BW completely goes against the ODS definition. Imhoff, an authority on the Operation Data Store, states ("Understanding the Role of Operations Data Store, DCI conference, June 28, 1998") that:

  • The ODS is not the lowest level of detail in the data warehouse architecture.

  • The ODS is not a staging area for the data warehouse.

  • The ODS is not a department-specific application.

The SAP BW ODS implementation is quite the opposite of these three points. Most customers will store the lowest level of detail in the ODS objects, blurring the ODS and data warehouse boundaries. In doing so, one has to stage data in the ODS objects to construct non-multidimensional department-specific applications. Though SAP calls this new functionality the ODS, in reality, it is a framework to build traditional ODS and data warehouse objects along with its ROLAP implementation to complete the CIF. For this reason, I call SAP BW ODS eODS-extended ODS.

Several examples-each providing a different concept of ODS primarily based on its usage and implementation architecture-can be cited. Today, due to heavy use of ERP applications and intense focus on customer satisfaction, the lines between ODS and traditional data warehouse are blurring. A new vision for ODS is warranted. This bring us to the SAP view of ODS-how it has evolved and what it really means.

Let's look at ERP packaged applications and the scope of traditional ODS. The ERP applications provide an integrated suite of business applications, such as SAP R/3. Here, information is already integrated among several individual applications. Data from all such applications is easily available. Because the fundamental role of an ODS in a corporation is to provide almost real-time data interconnects for an integrated view of information among business applications, the role of ODS as previously defined is very limited. For an ERP environment, the role of ODS still has to be defined where ODS plays an active role in the corporate information supply chain.

After the release of SAP BW 1.2A, customers found that the ODS implementation was not what they thought an ODS ought to be. It only housed the incoming data. American SAP User Group (ASUG) members worked with SAP to form a subcommittee to define an ODS architecture in the SAP BW product. This subcommittee consisted of ASUG members representing a broad range of industries (Dan Spaulding, Halliburton; Charlene Mathias, Eli Lilly; Naeem Hashmi, Compaq; Ryan Uda, Hewlett-Packard; Marilyn Jones, Dow Corning; Mary Heaner, Intel; Dave Smith, Phillips Petroleum; Kay Black, Sabre; and Xuan Pham, Equistar).

After long and intense discussions among team members and Laurie Nolan and Dr. Heinz Haefner, both of SAP AG, a white paper on SAP BW ODS was published. This white paper became the foundation of ODS architecture in SAP BW 2.0. This team focused its analysis of ODS requirements on the eight key areas: diverse data source, environment management, extraction-transform-load, metadata management, data management, archival management, data access, and data requestors.

The proposed ODS functionality is planned for partial implementation in SAP BW 2.0A for the pilot customers, Hewlett-Packard and Eli Lilly, and in SAP BW 2.0B for general availability. The ODS pilot was launched from December 1999 to February 2000. The SAP BW ODS pilot results were presented at the BW Congress in February 2000 in San Francisco, California.


Team-Fly


Business Information Warehouse for SAP
Business Information Warehouse for SAP (Prima Techs SAP Book Series)
ISBN: 0761523359
EAN: 2147483647
Year: 1999
Pages: 174
Authors: Naeem Hashmi

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net