Creating Universes with SAP BusinessObjects

By Taha M. Mahmoud
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Introduction to BI and the Semantic Layer

About this book

Creating a Universe using SAP BusinessObjects is your ultimate guide to mastering the development of BusinessObjects Universes using the SAP Information Design Tool. You will find many hands-on exercises as well as hints and best practices within this guide.

The book starts with an introduction to Business Intelligence and where BusinessObjects Universes fit into the big picture. Then, we will go through the Universe creation process. You will then learn how to create a Data Foundation (physical layer) and how to establish a new relational database and OLAP connection. Following this, you will learn how to create a Business layer. You will also learn how to handle security using user profiles and how to use functions such as @Aggregate_Aware(). This is a must-have book for any SAP BO Universe developer and will act as a reference for beginners and experts alike.

Publication date:
September 2014
Publisher
Packt
Pages
310
ISBN
9781782170907

 

Chapter 1. Introduction to BI and the Semantic Layer

Before getting started with SAP Business Object Universe, you need to first understand what Business Intelligence (BI) is and how SAP Business Objects (SAP BO) Universe fits in. It is very important to know the terms and language used in the BI world, and this is the aim of this chapter.

In this chapter, we will cover the following topics:

  • What Business Intelligence is and how it helps organizations and decision makers make the best use of the information they have

  • The important terms and concepts that everyone working in the BI field should be aware of

  • The BI reporting architecture models, starting with the basic and simple single-tier model until we reach the most matured three-tier model

  • Defining the semantic layer, and describing its functionality and main role in the BI reporting model

  • Introduction to the SAP BO Universe, which represents the semantic layer in SAP BO's reporting solution, and Information Design Tool, which is mainly used to create and publish Universes

 

What is Business Intelligence?


Business Intelligence (BI) is a complex term to describe. It is not a tool or a theory but a combination of methodologies, concepts, and technologies that enable you to get business value of raw data by transforming it into a format that can be used to do the required analysis and make decisions based on past trends.

To make it simple, let's start with a small example that illustrates the difference between using BI and not using it. We all know and play card games. Let's imagine that we have two players. Player number one is the smart BI guy, and player number two is the lazy, old-fashioned player. The old-fashioned player just plays cards based on his gut feeling, without trying to think or make use of the cards already played in the previous turns. He's actually not sure what the right card to play now is, or what cards he should play later on and in which sequence to win. He doesn't have the right tools and information to make his decision.

He is compared to the BI player who spends his time tracking all the cards played in the previous rounds. Then, he will try to predict and forecast the remaining cards for each player. He also spends time tracking the behavior of other players, their actions, and their impressions. This will help him predict their succeeding moves. He will start classifying the other players into categories such as a risky player who will rush to play his valuable cards in the early rounds, while other players will prefer to keep their valuable cards up to the end. The BI player simply uses historical information (past) to know what card to play now (current), and in the long run, he will build a strategy and vision on what cards he shall play in his upcoming turns to finally win the game.

Let's have a deeper look at our example to be able to define BI. BI means to extract historical information and then analyze it to help us decide what we shall do in the current situation and explore opportunities. In the long run, it will help build a strategy and vision by predicting and forecasting for the future.

 

Business Intelligence concepts


In this section, we will try to explain some of the most important BI concepts that you need to be familiar with. Before we start creating Universes, we need to make sure that we are talking the same language. The concepts, terms, and language used here are generic BI terminologies, and they are not related to specific BI reporting tools.

We will start with a knowledge pyramid that describes how data evolves from information to knowledge and finally, to wisdom. This is important because BI focuses on achieving knowledge and wisdom.

We will then talk about the difference between hindsight, insight, and foresight. After that, we will go through a fast overview of a data warehouse (DWH) and how it is related to BI.

The knowledge pyramid

The knowledge pyramid is also known as the data, information, knowledge, and wisdom model. Here is an example that describes each stage of the knowledge pyramid:

  • Data: This consists of scattered discrete facts that you can't understand alone, because they are not in a context. The following facts are an example of data:

    [is 200 Temperature C].

    These facts cannot be understood in the current order and format. This is because they are discrete, scattered, and without a context. This means that data alone is not useful and somehow needs to evolve to the other levels in the knowledge pyramid in order to gain some extra value.

  • Information: This consists of some discrete facts (data) evolved by putting them in a context. Context is a specific order of facts that will help us understand them and gain information. Let's check out the following example:

    [Temperature is 200 C].

    Now, we start having a context after reordering the discrete facts presented in the previous data example. We know that 200 is a number representing the temperature of something and that it is measured in Celsius.

  • Knowledge: This can be achieved by adding more context to the information. Let's check out the following example:

    [Car engine temperature is 200 C].

    [Car engine normal temperature is between 100 and 150].

    Now, you have more information grouped together in a context, and you know that your car engine's temperature is above the normal temperature. You might take an action, but you still need some more information to be able to take the right decision at the right time.

  • Wisdom: We will reach wisdom when we increase the context level by adding more knowledge and information together in the right order that can help us gain information and take actions. Let's check out the following example:

    [Car engine temperature is 200 C].

    [Car engine normal temperature is between 100 and 150].

    [Car engine temperature red zone starts from 200 C].

    [You need to stop your car if engine temperature reaches the red zone].

    Now, you can take a precise action based on the data, information, knowledge, and wisdom you have, and you will stop your car and go to check your engine. This is because you realized that your car temperature is higher than normal, and it is in the red (dangerous) zone.

The different stages of the knowledge pyramid are shown in the following diagram:

Now, after you have learned the knowledge pyramid, we need to find out what the relation between the pyramid and BI is. BI will evolve as data evolves. BI starts with raw data that will evolve into information after presenting it in a format that is suitable for analysis. Information will evolve to knowledge after doing the proper analysis on the information. Historical information and current knowledge will evolve and lead to future wisdom. It will help us take the right action in the current situation and make the right decisions in the future.

Note

More information on the knowledge pyramid is available at http://en.wikipedia.org/wiki/DIKW_Pyramid.

Hindsight, insight, and foresight

You will hear these three words, hindsight, insight, and foresight, many times if you work in BI field. They are strongly connected with BI because they simply describe what BI is. We've already explored these concepts in the What is Business Intelligence? section; now, we're going to discuss them in more detail:

  • Hindsight: This refers to focusing on the past and history. We learn from our past to avoid making the same mistakes and to explore new opportunities that we didn't catch.

  • Insight: This refers to the balance and start point for both hindsight and foresight. The action that we will take now will be history in a few moments and will shape our future. We can have a better present by learning from our history, and this will lead to a better future.

  • Foresight: This refers to what we expect in future, that is, how we will predict what will happen based on what has already happened.

BI is a mix of hindsight, insight, and foresight. As they are somehow related and connected, the main target of BI is to learn from our hindsight to take the right decision in our insight to have a better foresight.

Note

For more information, you can refer to http://www.learnthelessons.com/Ponderables/sights.htm.

BI and DWH

The data warehouse (DWH) is a central big repository to hold extracted data from multiple source systems across the organization. This is an important thing to think about before starting any BI initiative in your organization. The DWH will act as a single source for your BI reporting, and you will be able to integrate your isolated source systems and make your information available to top management and decision makers.

In the following diagram, you can see the data flow, which starts from source systems and ends at knowledge and wisdom, delivered to BI users in many formats:

DWH comes with many other concepts, which are given as follows:

  • Data Quality (DQ): This focuses on enhancing the quality of the data extracted from source systems to get more accurate information and build more valuable knowledge. Also, it takes care of enhancing source systems' user interfaces by doing the required data validation to make sure that the proper data is being entered and stored.

  • Master Data Management (MDM): This will focus on unifying the data to get the most accurate records. For example, let's take a customer's information. You might have a customer's mobile number and address stored in more than one system, but you know that a specific system contains the most accurate phone number of the customer, because it is used to perform transactions through calls. So, you will consider this system to get the most accurate phone number for your clients and other customer information such as address and name. This will help us get the most accurate and unified record for the customer from across our organization's source systems and also get what we call the customer golden record.

  • Metadata: Imagine that you have many source systems in your organization that you need to consider for data extraction. In some organizations, DWH contains thousands of tables and hundreds of thousands of columns and billions of records. For example, banking and telecommunication industries. For such huge DWH, you need to track what kind of information you have, where this information is stored, and how to access it. Metadata is data about data, and it will help you answer all questions raised earlier.

  • Data Governance: This is your DWH police. It will govern DWH by controlling the data flow between DWH and source systems. It will help unify business rules and criteria across the organization. Finally, it will control the process as well. Data Governance is the big umbrella that holds everything that we talked about in this section.

Besides data governance, there are many other types of governance that can run in your organization, such as IT governance, enterprise governance, and BI governance. In the following diagram, you can see just an example of multiple levels of governance:

DWH will act like the single point of truth, as everyone is accessing the same information that is stored in the same location with the same business logic and rules applied.

As you can see, there is a strong relation between BI and DWH as both of them complement each other. BI needs DWH to achieve its goals, and DWH needs BI to avail its data and make it utilized.

Note

For more information on data warehouse and BI, you can visit http://en.wikipedia.org/wiki/Data_warehouse and http://en.wikipedia.org/wiki/Business_intelligence.

 

BI reporting tools architecture


To achieve BI, we need tools. Some tools will be used to extract and transform data (ETL tools: extract, transform, and load) which is out of the scope of our book. We also need reporting tools to display the information and help us perform a proper analysis of the information that we have, to achieve the required knowledge and wisdom. Also, we might need some other tools to help us in data mining and forecasting. Here, we will concentrate on BI reporting tools as it is the entrance point to our main title. In this section, we will talk about the generic BI reporting tools architecture, and then, we will give special attention to SAP Business Objects.

The BI reporting architecture model evolved as BI evolved. It started as a one-tier model, client applications, that can access the data files directly. It then evolved into a two-tier model, by adding a database-server tier. The main purpose of the database-server tier is to enhance the security model for the previous model by isolating data access from the client tools. However, in this model, the client application will perform all the calculation and data processing before displaying the final results to the end user. This is why we call the client application in this model the thick client, as it will require high-standard hardware on the client machines.

Later on, the BI reporting architecture model evolved to the three-tier or multitier model, which is the most common architecture used nowadays. In this model, we added one extra business or BI tier to act as an intermediate layer between the client application and database-server tier. This layer will enhance the overall end user experience, because it will perform data calculation and processing after getting the data from the database server and before sending it to the client application. This is why we call the client in this model a thin client, because it will be used just to draw and display the results for the end user.

The following diagram displays the one-tier, two-tier, and three-tier models:

In the following sections, we will discuss the BI reporting architecture models in more detail.

The one-tier architecture model

In the one-tier architecture model, you have only one client application that connects directly to the data files. There is no authentication, and the user can modify, update, or even delete the master data files because he or she has complete access to data. The main characteristics of this model are:

  • We don't have a server, and we have only a client application

  • All calculations and processing are done by the client

  • The data is not secured, as the end user can access it directly using the client tools

  • You can't operate an efficient multiple user environment

  • It is a cheap and simple solution

  • The example tools are MS Excel, MS Access, and so on

The two-tier architecture model

In the two-tier architecture model, we have one extra tier, which is the database tier, besides a client-side application. This is why we call this model a client-server architecture model. To make it simple, let's just list the role of each component.

The database server is responsible for:

  • Receiving data queries from client applications

  • Communicating directly with the database and retrieving the required data

  • Sending it back to the client

The client-side application is responsible for:

  • Acting as an interface for the user

  • Sending user requests to the database server

  • Processing the data sent by the database server

The main characteristics of this model are:

  • It supports multiuser environment

  • It is more secured than the one-tier model

  • The client application is a thick client

A Java application (client) generates and submits SQL queries to the database server (server). Then, this application will process the retrieved data to display the final output as an example of the two-tier model.

The three-tier architecture model

The three-tier architecture model is the same as the previous model, but we will add one extra tier for business logic. This is also known as the application server, and the main purpose of this tier is to process the information before submitting it to the client application.

The main characteristics of this model are:

  • Data is more secured as end users don't have direct access to it

  • It supports multiuser environment

  • The semantic layer will isolate the physical layer from the Business layer

  • The application server will generate SQL queries using the semantic layer and then submit them to the database

  • Data calculation and processing are done on the application server

  • Client applications are thin clients and just used to display information

We will not go deep into this as it is out of the scope of our book and is related to server administration, but all that you should know for now is that SAP Business Objects platform 4.x is a multitier model. We can see a simple representation of the SAP BO 4 solution architecture in the following diagram. First, we have client tools (first tier) at the top of the graph. We have many client and reporting tools in SAP BO 4, such as Crystal Reports, Web Intelligence, and Dashboards. Then, we have the application server (second tier) in the middle. We have many modules in the application server, but our main concern here is the semantic layer, which will be managed and maintained by the Information Design Tool. Finally, we have the third tier represented in data sources and source systems at the bottom of the graph.

 

What is a semantic layer?


In this section, we will define the semantic layer and then describe the main role of semantic layers in BI reporting solutions.

The semantic layer acts like a translator. A translator is an expert in two languages at least. During a conversation, he or she will listen to the first person, understand what they said, and then translate the same message into a language that the other person can understand and vice versa.

The semantic layer does exactly the same thing. The end user can understand it and communicate with it, because it talks the same business language. Then, the other part translates the request into a technical language that can be submitted to the database. After that, it does the opposite by receiving the data from the database in a raw format and then translates it in a format that can be interpreted by the end user. So, it is like a man with two faces. One face is the technical face (evil one), which talks to the database, and the other one is the business user face (good one), which talks to the business end users.

The main idea of the semantic layer is to translate and simplify complex technical information in a way that business people can understand and utilize. The information is stored in a database, and it requires many technical skills to access it directly and do the required analysis. The semantic layer will isolate all technical staff from the actual business information needed, and it provides an easy way to understand and use a business model that can be accessed directly by the business to do their own reports and on-the-fly analysis.

The semantic layer will consist of two layers at least. The first one is the physical layer that will contain the technical part. In this layer, you will set up your data model by adding the required tables/views and create the proper joins between them. Usually, technical experts will be responsible for building this part as it requires technical skills. The second layer is the business model, which will be visible to the business users. This layer will contain attributes that business users can understand. Every attribute will have its own mapping to the physical layer either directly or it will be a driven attribute (calculated from other physical database columns). This will hide and isolate the complex technical part behind the frontend business model.

Note

For more information on the semantic layer, you can visit http://en.wikipedia.org/wiki/Semantic_layer.

 

Introduction to Universes and the Information Design Tool


All reporting tools use semantic layers for the same purpose. However, they just give it different names such as Framework in IBM Cognos, Project in Oracle BI, and Universe in SAP Business Objects. All semantic layers have exactly the same functionality: isolation of the technical part from the end business user by acting like a translator. They will translate the business requests into technical SQL queries submitted to the database. Also, they interpret the data returned into a format that can be understood by the end user.

SAP BO introduced a new tool to create your Universe (SAP BO semantic layer) in SAP BO 4.1; this is the Information Design Tool. They are still supporting the old Universe designer tool for compatibility purposes, but they clearly mention that they will stop supporting the Universe designer soon, and you will be able to create your Universes using the Information Design Tool only.

Before we conclude this chapter, let's have a look at the main components of Universe:

  • Connection: Every Universe should have at least one data connection. The data connection will define how Universe will access the data based on the connection type. If you have an Oracle connection, for example, you will need to define your Oracle database and set your connection parameters. We will talk about this in detail later on.

  • The Data Foundation layer: This is the physical layer in the Universe.

  • The Business layer: We define our business model in this layer. We might have more than one Business layer that shares the same Data Foundation.

 

History of SAP Business Objects


Business Objects is one of the leading companies in the BI and reporting field. The company was created in 1990 and finally taken over by SAP in 2007. There were many products offered by Business Objects, but the most famous one is Business Objects XI. The first official SAP release was SAP Business Objects XI3. The last available version of SAP Business Objects is BO 4.x, and the framework was completely changed in this version to comply with the Microsoft Ribbon technology. The integration between Business Objects and other SAP products was dramatically enhanced in this version, as shown in the following table:

Release name

Number of the service pack

Release date

BusinessObjects 3.x

NA

1995

BusinessObjects 5

11

1999

BusinessObjects Enterprise 6.x

9

2003

BusinessObjects Enterprise XIR2

5

2005

SAP BusinessObjects Enterprise XI3

5

2008

SAP BusinessObjects BI4

NA

2011

 

Summary


This concludes our first chapter. After reading this chapter, you should be able to describe what BI is and how this will help your organization achieve its goals. Then, we went through some of the most important aspects of BI such as the knowledge pyramid and the difference between foresight, insight, and hindsight. We also had an introduction to DWH and how BI can benefit from it. We also had an overview of the BI reporting tiers and how the BI architecture model evolved as BI evolved. Then, we talked about the semantic layer as our entrance to Universe building. Finally, we had a brief introduction to Universes and the Information Design Tool.

Now that we've been introduced to BI and SAP Business Objects Universe, in the next chapter, we will talk about the data model for the Universe that we will build together in the remaining chapters.

About the Author

  • Taha M. Mahmoud

    Taha M. Mahmoud (PMP, TOGAF, ITIL, and CSM) is a senior BI consultant, BI project manager, and solution architect. He has a BS degree in computer science and automatic control from Alexandria University, Egypt. He has a great passion for new technologies, especially those related to business intelligence. Taha has more than 9 years of experience in working on, consulting for, and deploying successful BusinessObjects projects in the banking and telecom industries. He is the author of Creating Universes with SAP BusinessObjects. You can contact him on Twitter at @tahama_2000 or visit his blog (http://business-objects-xi.blogspot.com/).

    Browse publications by this author
Book Title
Access this book, plus 7,500 other titles for FREE
Access now