Multi-Dimensional Modeling with BI A background to the techniques used to create BI InfoCubes Version 1.0 May 16, 2006t-Dimensional Modsing wth Bl Table of Contents Table of Contents. 1 Introduction. 2 Theoretical Background: From Multi-Dimensional Model to InfoCube .. 2.4 The goals of multi-dimensional data models.. 2.2 Basie Modeling Steps.. 2.3 Star Schema Basics and Modeling Issues. 10 3 Multi-Dimensional Data Models in BI Technology. 3.4 BI Terminology... 3.2 Overview. 13 3.3 Connecting Master Tables to InfoCube: 3.4 Dimensions in a BI data model.. 3.5 Fact table 22 4 Data Modeling Guidelines for InfoCubes. 4.4 MultiProvider as Abstraction of the InfoCube 23 4.2 Granularity and Volume Estimat 4.3 Location of dependent (parent) attributes in the BI data model 4.4 Tracking history in the BI data model, 26 4.5 M:N relationships (Multi-value Attributes) 4.6 Frequently Changing Attributes (Status Attributes) 47 Inflation of dimensions. 37 4.8 Multiple process reporting scenarios. 38 4.9 Attribute or fact (key figure). 4.10 Big dimensions... 4.11 Hierarchies in the BI data model {22000 SAP AG and SAP America, Ine Table of Contents1 Introduction This document provides background information on the techniques used to design InfoCubes, the multi- dimensional structures within Bl, and provides suggestions to help the Bl Content developer in Understanding when to apply the various techniques availabe. ‘The Bl architecture graphic (see figure 1) illustrates that InfoCubes, which build up the Architected Data Mart layer, should be founded on the Data Warehouse layer for transactional data built up by DataStore objects. Furthermore the InfoCubes are linked to common master reference data located in master data tables, text lables, and (external) hierarchy tables. Thus the Bl infrastructure provides the structure for building InfoCubes founded on a common integrated basis. This approach allows for partial solutions based on a blueprint for an enterprise-wide data warehouse. [iE conceptual Layers of Data Warehousing Operational §— |_| Data Store ' r Archi- Ware. ~ teed 1 house ate Marts Operational Data Store. Data Warehouse Architected Data Marts ™ Operational Reporting = Non-volatile = Represent a function, = Near Real-Time / Volatile = Granular department or business area = Granular = Historical foundation ™ Aggregated view = Built with DataStore = Integrated a Integrated objects = Typically built with ™ Typically built with Info- DataStore objects Cubes or separate SAP BW’s (figure 1) The focus of this paper is how to support Online Analytical Processing (OLAP) in Bl. OLAP functionality is ‘one of the major requirements in data warehousing. In short, OLAP offers business analysts the capability to ‘analyze business process data (KPIs) in terms of the business lines involved. Normally this is done in stages, starting with business terms showing the KPIs on an aggregate level, and proceeding to business terms on a more detailed level. Pages