Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Day-2 SAP BI Modeling
  2. 2. 2 SAP BW Foundation Virtual Training Schedule Day – Session name Date Session Timings Trainer Name Day 1 – SAP BW Overview 19-May-14 2:00 PM – 4:00 PM vemuluri, Murali Day 2 – SAP BW Data modeling 20-May-14 2:00 PM – 4:00 PM chukkala, Saritha Day 3 – SAP BW ETL 21-May-14 2:00 PM – 4:00 PM Patra, Biswajit Day 5 – SAP BW Administration 22-May-14 2:00 PM – 4:00 PM Gunasekar, Vinodh Day 4 – SAP Reporting 23-May-14 2:00 PM – 4:00 PM Raj, C V Vijay
  3. 3. 3 Master Data / Transactional Data InfoArea  InfoObject Catalog  Application Component  InfoObject  DataSource  InfoCube  DataStore Objects (DSO)  Characteristics  Key Figures  Dimension Table  Fact Table  SID Table SAP BW TERMINOLOGY
  4. 4. 4 TERMINOLOGY - 2 Attributes  Text  Hierarchy  InfoProvider  Source System  Data Targets  Transformation  Data Transfer Process  Query Designer  BEX Analyzer
  5. 5. 5 SAP BW/BI Version History Name Version Release BIW 1.2A Oct-98 BW 3.0A Oct-01 BW 3.0B May-02 BW 3.1 Nov-02 BW 3.1C Apr-04 BW 3.3 Apr-04 BW 3.5 Apr-04 BI 7 Jul-05 BW 7.3 BW 7.4
  6. 6. 6 Simple Data Modeling Flow: Data Reporting Data Modeling Data Extraction
  7. 7. 7 Purpose and Use of Data Modeling in BW Data modeling is the “backbone” of the BI system. It is a staging area helps to maintain large amount of operational and historical data and the main purpose of data modeling is to structure and organize the necessary data for Business users for data analysis. Data Modeling serves as the tool for managing the middle phase of data warehousing i.e. it helps managing the staging and transforming the data for reporting. It provides more flexibility in terms of data transformation as compared to the source system due to availability of various methods of data transformation.
  8. 8. 8 Info Objects
  9. 9. 9 InfoObjects  InfoObjects are the basic information providers of BI and the smallest information units in BI.  They structure the information needed to create InfoCubes/DSO Objects.  InfoObject types:  Characteristics  Key figures  Characteristics bear master data (i.e. attributes, texts or hierarchies) in BI. Attributes are InfoObjects that are logically subordinate to a characteristic. Types of Attributes: Display Attribute and Navigational Attribute Key Figures InfoObjects provide values to be evaluated such as quantity, amount, or number of items.
  10. 10. 10 Use of Info-Objects
  11. 11. 11 InfoObject Catalog An InfoObject catalog is a collection of InfoObjects grouped according to application-specific criteria/It is a directory of Infoobjects. You can group Info Objects together in InfoObject Catalogs to provide both a better overview to them and to arrange them logically. Types of InfoObject catalog: Characteristic: This is the collection of Characteristics InfoObjects Key figure: This is the collection of Key figures InfoObjects
  12. 12. 12 Info Providers
  13. 13. 13 Info Providers – Business Purpose An InfoProvider is an object for which queries can be created or executed in BEx. InfoProvider can be either physical storage of data or virtual collection of data Basic InfoProviders: 1. InfoCube 2. Data Store Objects (DSO) InfoProviders can be displayed, created, and maintained in transaction RSA1
  14. 14. 14 It is a multidimensional Structure/ Data Container used for Analysis & Reporting Purpose. An InfoCube can have maximum of 16 dimensions (3 dimensions are provided by SAP i.e. Time, Data Package and Unit). A maximum of 256 characteristics can be included in each dimension. A cube has 2 fact tables - E and F. When the requests in the cube are not compressed the data exists in the F fact table and when the requests are compressed the data lies in the E fact table. InfoCubes
  15. 15. 15 InfoCube
  16. 16. 16 Extended Star Schema
  17. 17. 17 ODS—Operational data store DSO---Data store Object It acts as a storage location for consolidated and clean-up transaction data . DSO object contains:  key fields data fields and  key figures. Data Store Object (DSO/ODS)
  18. 18. 18 Data Store Object (DSO)
  19. 19. 19 Data Store Object (DSO) Every DSO object is represented on the database by three transparent tables: Active data table: latest data, current status of the data and used for reporting.  Activation queue/New data table : Data stored before activation, delete after activation. Change log: Contains the complete history of the changes.
  20. 20. 20 Data Store Objects There are three different types of DSO’s in BI 7.0 Standard DSO Direct Update DSO Write Optimized DSO DSO for Direct Update is same as Transactional ODS in 3.x Write Optimized DSO is a completely new type of DSO.
  21. 21. 21 Write Optimized DSO Consists of only one table of active data Reporting is possible on the basis of these DataStore objects. However, we recommend that you use them as a consolidation layer, and update the data to additional InfoProviders, standard DataStore objects, or InfoCubes. It also can be used as EDW layer for saving data. Business rules are only applied when the data is updated to additional InfoProviders.
  22. 22. 22 Direct Update DSO A direct update DSO object differs from a standard DSO object in the way it prepares data. Data Store object type is filled using APIs and can be read via a BAPI.
  23. 23. 23 Differences between Data Store Object Types Type Structure Data Supply SID Generation Are BEx Queries Possible? Standard Consists of three tables: activation queue, table of active data, change log From data transfer process Yes Yes For direct update Consists of the table of active data only From APIs No Yes Write- optimized Consists of the table of active data only From data transfer process No Yes
  24. 24. 24 MultiProvider A MultiProviders is a type of InfoProvider that combines data from a number of InfoProviders and makes it available for analysis purposes. The MultiProviders itself does not contain any data. Its data comes entirely from the InfoProviders on which it is based. MultiProviders only exist as a logical definition. These InfoProviders are connected to one another by a union operation. A query based on a MultiProvider is divided internally into subqueries. There is a subquery for each Info Provider included in the MultiProvider. These subqueries are usually processed in parallel.
  25. 25. 25 MultiProvider • One can combine InfoCube, DSO objects, InfoObjects and InfoSets in a MultiProvider. • A union operation is used to combine the data from these objects into a MultiProvider. • Here, the system constructs the union set of the data sets involved. In other words, all values of these data sets are combined.
  26. 26. 26 Data Targets
  27. 27. 27 Data Targets A data target is an object into which data is loaded. Data targets are the physical objects that are relevant during data modeling and when loading the data. Data targets are: InfoObjects (characteristics with attributes or texts) InfoCube DSO Objects
  28. 28. 28 Data Targets vs InfoProvider Data targets physically store data in the underlying database tables. InfoProviders not necessarily store data. Data can be populated on the fly via infoproviders by the reports. All data targets are infoproviders but vice versa is not always true.
  29. 29. 29 InfoProviders An InfoProvider is an object for which queries can be created or executed in BEx. InfoProviders are the objects or views that are relevant for reporting. Types of InfoProviders: MultiProviders InfoSets Virtual Providers DSO InfoCube InfoObject
  33. 33. 33 DATA FLOW DSO
  34. 34. 34 INFOSET DATA FLOW
  35. 35. 35 Data Flow:
  36. 36. 36 Data Flow
  37. 37. 37 Process Chain
  38. 38. 38 Introduction Process chain is defined as a sequence of interdependent processes, it is required to perform a complete task in BW Process chains are graphical scheduling & monitoring tool to maintain automation, visualization & monitoring of tasks/processes.
  39. 39. 39 Introduction Transaction code for Process Chain Maintenance: RSPC. Different Process Chain Views: Planning View: Use to check the Plan status of the Process chain. Checking View: Use to check the consistency of the process chain  Log View: The results of each run are monitored.. Types Of Processes Start Process Application Process Collection Process
  40. 40. 40 Start Process Defines the start of a Process Chain Special features of a Start process: Only the start process can be scheduled without a predecessor process. The start process cannot be a successor of another process. Only one start process is allowed for each process chain. A start process can only be used in a single process chain.
  41. 41. 41 Application Processes Application process represent BW activities that are typically performed as part of BW operations. Sample Application Processes: 1. Create Index 2. Delete Index 3. ODS Activation 4. Build DB Statistics 5. Compress InfoCube
  42. 42. 42 Collection Processes Used to manage multiple predecessor processes that feed into the same subsequent process Collection processes available in BW AND OR EXOR
  43. 43. 43 Process Control in BW Data Load Monitor Data Target Maintenance Start 1 Load into PSA 3 Load into ODS 4 Activate Data in ODS 5 Further update 6 Build Indices 7 Build DB Statistics 8 Roll up Aggregate 9 Drop Indices 2
  44. 44. 44 Process Control 1. ‘Start Process’ starts the process chain. It is triggered when process chain is scheduled to run. 2. ‘Drop index’ is recommended by SAP prior to data load. 3. ‘Execute Infopackage’ is then executed to extract data from the source system into the PSA. 4. Data is pushed from PSA to ODS after required staging. 5. ODS is activated as data is transferred from new data table to active data and the change log tables. 6. Data is then updated to further Datatargets. 7. Indexes are rebuild at this stage to improve Database access and the query performance, in turn. 8. In the next step, the system generates data on the performance of the BW architecture and stores it as BW statistics. 9. The data thus updated is rolled into the aggregates (if any).
  45. 45. 45 Process Chain - Functionalities Used to monitor Process Chains Logs.
  46. 46. 46 Process Chain – General Services
  47. 47. 47 Process Chain – Load Process
  48. 48. 48 Process Chain – Administration
  49. 49. 49 Process Chain – Scheduling • There are multiple modes to schedule a process chain: o Immediate – Process Chain(PC) run starts immediately once triggered. o Date/time: PC is scheduled to run on specific date and time. Using this, PC can be scheduled Hourly, Daily, Weekly, Monthly. o After Job : PC would be triggered after completion of the specified job. o After Event: PC would be executed once specified event is triggered. o At Operation mode: PC is triggered to run during the specified mode of operation.
  50. 50. 50 Process Chain – Monitoring • Process Chain logs can be viewed for different time periods i.e.: o Same Day. o Same day and Previous Day. o One week ago. o Current month and Previous month. o Free Date: any timeframe starting 01/01/1000 to 31/12/9999. • Symbols display the status of the runs of the individual process within the chain: o Yellow indicates that the chain is active. o Green that the chain ended successfully. o Red that the chain ended with errors or was terminated. o Unknown is displayed if the status is unknown
  51. 51. 51
  52. 52. 52 Transactions Used RSPC : Create, Maintain and Monitor Process Chains. RSPCM : Monitor Process Chains. SM37 : Display/Maintenance of batch Job. RSMO : Infopackage monitor. RSA1: Administrator workbench
  53. 53. 53 Query Designer View
  54. 54. 54 BEX Query
  55. 55. 55 BEX ANALYZER
  56. 56. 56 HelpMe Browse through the below links for Self Study 1. 0138fede083de10000009b38f8cf/frameset.htm 2.
  57. 57. Thank You.