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.

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.

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 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.

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.

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:

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:

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.