Summary_05

advertisement
Summary
Data Warehouse Definitions
A data warehouse has the following properties:
 Read only access: End users have read-only access, meaning that the data is
primarily loaded into the data warehouse via the Extraction, Transformation and
Loading (ELT) process.
 Cross-organizational focus: Data sources from the entire organization
(production, sales and distribution, controlling) and possibly external sources too
make up the basis of the system.
 Data warehouse data is stored persistently over a particular time period.
 Historization: Data is stored by time on a long-term basis.
 Designed for efficient query processing: The technical environment and data
structures are optimized for answering business questions – not transaction
processing.
Data Warehouse Objectives






Standardized structures and representation for all enterprise information
Easy-to-use access, single-point of access to all enterprise information
Self-service, high quality business reporting and analysis on all levels
Fast and cost-effective to deploy
High performance environment fed from heterogeneous sources
Freed-up systems and IT resources in OLTP environment
OLTP versus OLAP
OLTP environments are fundamentally different to OLAP environments:
 Level of detail: The OLTP layer stores data with a very high level of detail,
whereas data in the data warehouse is compressed for high-performance access
(aggregation).
 History: Archiving data in the OLTP area means it is stored with minimal history.
The data warehouse area requires comprehensive historical data.
 Changeability: Frequent data changes is a feature of the operative area, while the
data is “frozen” after a certain point for analysis.
 Integration: In contrast to the OLTP environment, requests for comprehensive,
integrated information is very high for analysis.
 Normalization: Due to the reduction in data redundancy, normalization is very
high for operative use. Data staging and lower performance are the reasons why
one finds less normalization in the data warehouse.
 An OLAP environment is optimized for read access. Operative applications also
need to carry out additional functions effectively, including change, insert and
delete.
SAP BW Architecture
In principle, SAP BW architecture can be divided into three layers:
The Administrator Workbench (transaction RSA1) is the central administration tool of a BW system.
A BW system has only one productive client.
Terminology and Objects in BW
InfoCube
Objects that can function both as data targets as well as InfoProviders.
An InfoCube describes a self-contained dataset (from the reporting view), for example,
for a business-oriented area. This dataset can be evaluated with a BEx query.
An InfoCube is a quantity of relational tables that are created according to the SAP BW
star schema: two large fact tables in the center, with several dimension tables surrounding
it.
SAP BW star schema





The center of a multidimensional schema in BW are the two fact tables (E-fact
table and F-fact table).
The fact tables are surrounded by dimensions.
In the fact tables the key figure values are stored.
Dimension Table
 In BW the attributes of the dimension tables are called characteristics
(e.g. material).
 The meta data object in BW that describes characteristics and also key
figures (facts) is called InfoObject.
 There can be up to16 dimensions
 3 dimensions exist with each InfoCube (whether they are used and thus
visible or not)
 Time dimension
 Unit/ currency dimension
 Packet dimension
 The remaining 13 dimensions are for individual schema design
 Each dimension table may be up to 248 characteristics.
Master Data Tables:
 AttributeTable
 Dependent attributes of a characteristic can be stored in a separate
attribute table.
 Text Tables
 Textual descriptions of a characteristic are stored in a separate text
table.
 External Hierarchy Tables
 Hierarchies of characteristics or attributes may be stored in
separate hierarchy tables.
InfoCube compression


Compression finds records which are identical except for Request ID, then
summarizes all these records.
The summarized records are moved from the F to the E fact table
An InfoCube compression is therefore important for query performance. It also
helps manage Fact table size.
Drawback: Requests can no longer be deleted from the InfoCube selectively.
Operational Data Store
The Operational Data Store (ODS) allows detailed data to be stored. Often line item
detail is stored in the ODS and then summarized when updated into InfoCubes.
It is possible to report against an ODS; however the ODS is not optimized for query
performance like InfoCubes.
InfoObject
Business evaluation objects (for example, customers or sales) are called InfoObjects in
BW.
InfoObjects are subdivided into characteristics and key figures.
InfoProvider
An InfoProvider is an object using which queries can be defined and evaluated.
InfoProviders are the objects or views relevant to reporting. For this reason it does not
matter if these objects contain data or not. Examples for InfoProviders are:
 InfoCubes
 ODS Objects
 InfoObjects
 MultiProviders
MultiProvider
MultiProvider is a special InfoProvider that combines data from several InfoProviders,
providing it for reporting. The MultiProvider itself does not contain any data. Its data
comes exclusively from the InfoProviders on which it is based.
A MultiProvider can be made up of various combinations of the following InfoProviders:
 InfoCubes
 ODS object
 InfoObject
MultiProviders are required if a query has to access more than one InfoCube or ODS
objects. The InfoCube and ODs objects are combined in one MultiProvider, which the
query then can access.
Queries
A query is a collection of a selection of characteristics and key figures (InfoObjects) for
the analysis of the data of an InfoProvider.
A query always refers exactly to one InfoProvider, whereas you can define as many
queries as you like for each InfoProvider. Therefore you have to create a MultiProvider
if you want to access the data of several InfoCubes or ODS objects in one query.^
Process chains
Sequence of processes that are scheduled in the background to wait for a particular event.
Some of these processes trigger an additional event, which in turn can start other
processes. Process chains can be used for data loading.
Transfer Rules
Transfer rules transfer data from the DataSource into the InfoSource and transform or
modify the data where necessary. Transfer rules are specific to the DataSource
Update Rules
The update rules specify how the data (key figures, time characteristics, characteristics) is
updated from the communication structure in an InfoSource into a data target. Update
rules are specific to the data target
Extractor
Program used to fill the extraction structure of a DataSource with data from datasets in
the SAP source system.
DataTarget
Data load-relevant view of a BW object with a physical data store. DataTargets are e.g.:
 InfoCubes
 ODS objects
 InfoObjects
Reporting
To satisfy the different user requirements different front-ends for displaying the queries
are available. Always available are the Business Explorer Analyzer (BEx Analyzer, i.e.
an Excel Plug-in) and Web Reporting, i.e. displaying the query results in a web browser.
But there are also third party tools like Crystal Reports.
Query Designer
The BEx query designer is a tool for defining queries that are based on a selection of
characteristics and key figures (InfoObjects) or on reusable InfoProvider structures.
You can use the queries that you define in the BEx Query Designer in all front-ends.
Information Broadcasting
Information Broadcasting allows the distribution of BW information
... via different channels ...
 E-Mail (works independently from an EP installation)
 Enterprise Portal
... in different formats ...
 HTML, MHTML
 BEx Analyzer Workbooks
 ZIP Files
… of different sources …
 BI Web Applications - Dashboards, cockpits
 BEx Analyzer Workbooks
 Queries
… in different modes…
 Online
 pre-calculated
Business Content
Business Content contains SAP delivered objects that enable you to structure your
reporting quickly, from data extraction from SAP source systems, to roles that supply
employees in a company with information they need to complete their work. These
information models include:
 Roles
 Queries and workbooks (BW reports, and particular views of them)
 InfoProviders that the reports are based on
 InfoObjects that provide the characteristics and key figure
 Update rules and extractors for SAP R/3, mySAP.com business applications, and
other selected applications
Data loading
DataSource and InfoSource
Business Information
Warehouse Server
Staging Engine
InfoCubes
Update Rules
Communication
Communication structure
structure
Transfer Rules
(Replicated)
Transfer Rules
Transfer
Transfer Structure
Structure
Transfer
Transfer Structure
Structure
InfoSource
Transfer Rules
Transfer
Transfer Structure
Structure
DataSource
Transfer
Transfer Structure
Structure
Extract
Extract Source
Source Structure
Structure
Transfer
Transfer Structure
Structure
Extract
Extract Source
Source Structure
Structure
OLTP System 1
 SAP AG 2003, Title of Presentation, Speaker Name / 2
Transfer
Transfer Structure
Structure
Extract
Extract Source
Source Structure
Structure
OLTP System 2
Possible types of Source systems:






Other SAP systems (e.g. R/3)
Universal Data Connector
3rd party systems (via BAPI)
flatfiles (ASCII and CSV)
SOAP
DBconnect
Aggregates





... are like InfoCubes,
... are always based on InfoCubes
... summarize ("aggregate") data of the originating InfoCube,
... contain redundant information, but
... accelerate the access to that information,
BW BPS
Since BW Release 3.5, the Planning functionality from SEM (SEM-BPS Business
Planning and Simulation) is included in BW, named BW-BPS. There are several
functions available for performing the planning:
 Predefined planning functions (such as copy, revaluation,
distribution,…)
 Fox-formulas
 Exits
 Manual planning
Download