(ebook - english) SAP and Data Warehousing.pdf - SAP_ADMINISTRACJA - wydra66

Kiva

Productions

SAP AND D ATA W AREHOUSING

by W. H. Inmon

SAP and Data Warehousing

In the beginning were applications. Then these applications were maintained. And

the maintained applications were merged with another company and had to interface

with their maintained applications that were never before imagined or designed for

working with other applications. And these applications aged and were maintained

some more. Then application packages appeared and were added to the collection

of applications. Soon there was a complex mess of epic proportions.

More maintenance, more requirements, more time passing, more mergers, more

small applications and trying to get information out of the stockpile of applications

was an impossibility.

Into this arena came ERP applications such as SAP, BAAN, J D Edwards, and a

host of other players. The ERP applications offered to take the Gordian approach

and smite the applications stockpile a mighty blow by creating new applications

sensitive to current requirements which were also integrated. The appeal to the

business person was enormous and soon ERP applications were everywhere. Indeed,

as time passed, ERP applications began to make a dent in the older applications

stockpile.

Figure 1 shows the appeal of unifying older applications into an ERP framework.

appls

ERP

Individual transaction applications are

consolidated into ERP.

Figure 1

The appeal was such that many corporations around the world began to buy into

the ERP application solution, even when it was known that the ERP solution was

not cheap or fast. The odor of the older legacy applications stockpile was such that,

coupled with the threat of the year 2000, many organizations could not resist the

appeal of ERP, whatever the cost.

SAP and Data Warehousing

The Corporate Information Factory

At the same time that applications were evolving into ERP, the larger body of

information systems was evolving into a framework known as the corporate

information factory. The corporate information factory accommodates many

different kinds of processing. Like other forms of information processing, the ERP

solution fits very conveniently into the corporate information factory. Figure 2

shows the relationship between the corporate information factory and ERP.

data marts

DSS appls

crm

operational

applications

i/t

eComm

edw

Bus Int

ODS

ex wh dm wh

near line

storage

Where ERP fits into the corporate information factory.

ERP

Figure 2

ERP fits into the corporate information factory as either another application and/

or as an ODS. In the corporate information factory, ERP executes transactions

which then generate data to feed the ODS and/or the data warehouse. The detailed

data comes from the ERP application and is integrated with data coming from

other applications. The integrated data then finds its way to and through the different

part of the corporate information factory. (For an in depth explanation and

description of the various components of the corporate information factory, please

refer to THE CORPORATE INFORMATION FACTORY, W H Inmon, Claudia

Imhoff, John Wiley, 1998.)

The advent of ERP was spawned by the inadequacies and the lack of

integration of the early applications. But after implementing part or all

of ERP, organizations discovered something about ERP. Organizations

discovered that getting information out of ERP was difficult. Simply

implementing ERP was not enough.

SAP and Data Warehousing

Frustration With ERP

Figure 3 shows the frustration of organizations with ERP after it was

implemented.

ERP

Getting information out of ERP is difficult.

Figure 3

Many organizations had spent huge amounts of money implementing ERP

with the expectation that ERP was going to solve the information systems

problems of the organization. Indeed ERP solved SOME of the problems

of information systems, but ERP hardly solved ALL of the problems of

information systems.

Organization after organization found that ERP was good for gathering

data, executing transactions, and storing data. But ERP had no idea how

the data was to be used once it was gathered.

Of all of the ERP vendors, SAP was undoubtedly the leader.

Why was it that ERP/SAP did not allow organizations to do easy and smooth

analysis on the data contained inside its boundaries? There are many answers

to that question, all of which combine together to create a very unstable

and uncomfortable information processing environment surrounding ERP/

SAP.

The first reason why information is hard to get out of SAP is that data is

stored in normalized tables inside of SAP. There are not a few tables. There

are a lot of tables. In some case there are 9,000 or more tables that contain

various pieces of data in the SAP environment. In future releases of SAP

we are told that there will be even more normalized tables.

The problem with 9,000 (or more!) tables storing data in small physically

separate units is that in order to make the many units of scattered data

meaningful, the small units of data need to be regrouped together. And the

work the system must do to regroup the data together is tremendous. Fig

4 shows that in order to get information out of an SAP implementation, that

many “joins” of small units of data need to be done.

SAP and Data Warehousing

The performance implications of doing joins on 9,000 or more tables

is tremendous.

The system resources alone required to manage and execute the join of 9,000 tables

is mind boggling. But there are other problems with the contemplation of joining

9,000 tables. Some of the considerations are:

• are the right tables being joined?

• do the tables that are being joined specify the proper fields on which to join the

data?,

• should an intermediate join result be saved for future reference?

• what if a join is to be done and all the data that is needed to complete the join

is not present?

• what about data that is entered incorrectly that participates in a join?

• how can the data be reconstructed so that it will make sense to the user?

In short, there are many considerations to the task of joining 9,000 tables. While

performance is a big consideration, the integrity of the data and the mere

management of so many tables is its own large task.

But performance and integrity are not the only considerations. Life and the access

and usage of information found in SAP’s 9,000+ tables is made more difficult when

there is either:

• no documentation, or

• significant portions of the documentation that exists is in a foreign language.

While it is true that some documentation of SAP exists in English, major important

aspects of SAP do not exist in English. For example, the table and column names of

SAP exist in what best can be described as “cryptic German”. The table and column

names are mnemonics and abbreviations (which makes life difficult). And there are

thousands of table and column names (which makes life very difficult). But the

mnemonics and abbreviations of the thousands of table and column names are of

German origin (which makes life impossible, unless you are a German application

programmer). Trying to work with, read and understand cryptic German table and

column names in SAP is very difficult to do.

Figure 4

(ebook - english) SAP and Data Warehousing.pdf

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: