University of Houston-Clear Lake

Benchmark Financial Brokers

A Case Study on Building a Data Warehouse

Prepared by:Terry LeeTran Ngo

Sandeep UdhaniNavin Negi

Prepared for:Dr. Rob

ISAM 5332

5/5/2010

University of Houston-Clear LakeISAM 5332

Dr. Rob

Benchmark Financial Brokers: A Case Study on Building a Data Warehouse

Terry LeeTran Ngo

Sandeep UdhaniNavin Negi

Abstract

The purpose of this paper is to discuss how we approached building a data warehouse for Benchmark Financial Brokers (Benchmark), starting with taking the wrong approach and ending up with a functioning project.

Introduction Benchmark is involved in the securities trading business and as such has to maintain multiple transactional systems. These systems are adequate to run the day to day operations of the business, however they do not allow for timely access to strategic information. This is information that will help the owner and managers maintain the long-term health of the organization. The purpose of a data warehouse is to collect desired data from various transactional systems, convert it into a common format, cleanse it, and allow it to be queried for useful strategic information in the future. While the concept of a data warehouse sounds quite simple, in reality it is almost completely opposite. Data must be continually collected, transformed, and cleansed from each of the different transactional systems in order to keep the warehouse properly maintained.

Case Study: Benchmark Financial Brokers

1. Business ScenarioBenchmark started with a single location in Texas and has now expanded to forty five locations throughout Texas, Louisiana, and Florida. The business owner plans on expanding to include more locations throughout the country. The problem that the owner and the managers of this business face is that with their continual expansion it is becoming increasingly difficult for them to conduct timely visits to each of the locations in order to monitor employee performance, track revenue, and ensure sound financial advice is being offered to the customer. Benchmark has operational systems that allow the advisors to monitor the constantly fluctuating stock markets, as well as transactional systems that allow them to buy or sell various financial instruments for their customers. These various systems prevent a challenge when it comes to generating useful reports that provide the information that the owner is looking for. The owner is convinced that if he can find a way to extract the data that he needs from each of these systems he will be able to maintain greater control over his business.

2. Why a Data Warehouse?Benchmark’s owner needs better strategic information about his business. This is what a data warehouse is perfect for. The concept of a data warehouse is to be able to collect data

from multiple operational and transactional systems, combine them in some manner, store them in a central location, and provide Online Analytical Processing abilities in the future. This is exactly what the owner of Benchmark has been looking for. He needs the ability to collect and query this data in order to obtain reports that will provide him with the strategic information that he needs. This can include reports such as revenue for each location by state, revenue by investment type, customers who have money in high risk investment, and employees who may be purposely selling these investments. The ability to query this kind of system online from his office is the perfect solution to his problem.

3. MethodologyBeginning this project as a group, we did not have a very clear picture of how we needed to go about designing a data warehouse. We began with designing what was essentially a transactional database. One of our primary concerns when we started the process was how to track the price of the securities that are being sold, as the stock market is constantly fluctuating. Even though it made complete sense to us, our initial approach proved to be wrong. A data warehouse is not meant to be a transactional database; it is a database that warehouses historical data about the organization. This is important because the stored data will be used strictly for designing the reports that management needs to help them make strategic decisions about the future. Approaching the project a second time we realized that instead of trying to figure out how to collect the data, we needed to figure out how to present the data that we already had. When designing the data warehouse, probably the best method to employ is to approach it from a reporting aspect. Approaching the project this way means that you must be thinking about the information that is ultimately desired by the end user. Once we realized that we needed to look at the project from this aspect, it led us to completely rethink our

strategy, and led us to completely redesign our dimensional models.

4. Dimensional Modeling and defining data structure Dimensional modeling incorporates the business dimensions into the logical data model. (Ponniah 206) After defining requirements from the business needs, data structures are designed within the logical model. When defining requirements, users may not be able to precisely describe what they want in a data warehouse, they can provide you with very important insights into how they think about the business, as well as tell us what measurement units are important for them. Managers think of the business in terms of how they want to measure it. These measurements are the facts that indicate to the users how their departments are doing in fulfilling their objectives. We can say business metrics or facts are what managers want to analyze in order to know the current situation of their business. These are important when making decisions that will affect the future of their organization. When designing dimensions for a data warehouse it is extremely important to pay attention the hierarchies that are contained within each of the dimensions. These dimensional hierarchies are the various levels of detail contained within a business dimension. Managers can use the dimensional hierarchies as the paths for drilling down or rolling up in analysis. Dimensional modeling is the technique that is in designing a data warehouse. Many software vendors have expanded their modeling case tools to include dimensional modeling. Modern software is very useful when designing fact tables, dimension tables, and establishing the relationships between them. When you have finished modeling the dimensions and establishing the relationships, you end up with a database schema. The two types of schemas that are generally used in a data warehouse are the STAR schema and the snowflake schema. The STAR schema is a simple database schema for data design using a dimensional model. This schema consists of a

fact table in the center that is directly related to the dimension tables that surround it. Although the STAR schema is a relational model, it is not a normalized model. The snowflake method normalizes the dimension tables in a STAR schema. As mentioned earlier, it is very important to employ the correct approach when designing the schema for a data warehouse. This is where we made our first mistake. As a result of this, we have two different database schemas. The first schema that we designed was a complex snowflake schema which is depicted in figure 1.1.

Figure 1.1

When the dimensions in a STAR schema are completely normalized the resulting structure resembles a snowflake with the fact table in the middle. In the case of Benchmark, the most important fact to analyze is the sales commission which is the revenue for the company. The transaction table is the fact table which contains commission as an attribute. Transactions are analyzed base on dimensions such as Customer, Employee, Investment, Time, Date, and the Commission collected. At first, we approached this project from the wrong direction, and because of that we normalized the tables in our schema. This was done because we were thinking in terms of a transactional system where we would need to track changes in the price of stocks, bonds, and other marketable securities. We stored detail information about employees such as position, and salary. After we realized that we weren’t looking at project correctly, we recognized that this information was not necessary for the data

warehouse. Although a data warehouse is based on a relational database like one that would be used in an operational system what we were building was a decision-support system. The important component to the entire project is the ability to track and analyze the commission. We do not need to worry about the price of investments or employee salary. In order to correct our error, we redesigned our database schema and arrived at a Star schema which is depicted in figure 1.2. In this schema, we have the Transaction as the fact table with four dimension tables: Employee, Customer, Investment and Date_Time. We kept these dimensions because we needed to analyze commission by state, by employee, by customer, by investment type, and by investment risk class.

Figure 1.2

From our new Star schema, we were able to define the data format that we need for the warehouse. We defined table name, attribute name, data type of each attribute in each table, and relationship among tables. From Benchmark’s operational system, we extracted data into an excel file that is depicted in figure 1.3. Many of the fields that were extracted are necessary for an operational system, but were not needed in the data warehouse. This is where cleansing data becomes important. In order to keep the warehouse efficient, we used Excel to remove the extraneous data before it

was imported. After cleansing the data, we had attributes that were important to the structure of our system. An example of the cleansed data is found in figure 1.4. When we were satisfied that are data was formatted and cleansed correctly, we moved to our next step which was to implement our database schema in Microsoft Access. This schema is displayed in figure 1.5.

We used Access to define our relationships and make sure that the system functioned before importing the database into SQL Server 2008.

Figure 1.3

Figure 1.4

Figure 1.5

5. Implementation in SQL Server 2008In order to browse the data that is contained within the data warehouse, you must design a data structure called a cube. Constructing the cube is done in SQL Server Analysis Services. A cube is comprised of the fact table and all of the data that is directly related to it. The cube organizes the data into a format that can be easily queried, rolled up, drilled down, and sliced and diced based on the measures and hierarchies that are applicable to your particular data set. Importing a database from Access to SQL Server is supposed to be an easy process, but trust us it is anything but. Trying to figure out how to get the program to accept your data and process it turned out to be one of the biggest challenges of the whole project. According to Scott Cameron’s SQL Server 2008 Analysis Services: Step by Step, if you have an existing relational database such as Access, Teradata, Oracle, IBM DB2, as well as some others, you should be able to select the appropriate driver and connect to your data source without any difficulties.(Cameron 39) If

only this were true. Due to not having sufficient security clearance to upload our database onto the University of Houston-Clear Lake (UHCL) server, we decided to use a personal laptop to run the software. Operating system compatibility was one of the first problems that we encountered. The solution to this problem was to download the applicable service pack from Microsoft Update. Once the software was installed we attempted to import the database from Access. The next attempt to import the database resulted in being able to import the data, but this time we could not build or deploy our cube. Do not get frustrated when you encounter this problem. We have chosen not to outline the steps that we took to get the program to function correctly as they will be different for each application. Once we had the database imported and functioning properly, we commenced building our cube. The ability to roll up, and drill down your data is based on the hierarchies that are defined within your dimensions. This very important step is depicted in figure 1.6.

Figure 1.6

Without defining the hierarchies in each of your dimensions, you will not have access to all of the data. When a manager is looking for information, he may want a very high level of granularity, or a very low level of granularity. These types of details are very important when deciding how to define the dimensions that are contained within your data warehouse. When all of the hierarchies are defined, you must set up the relationships that are contained within the dimensions. An example of these relationships can be seen in figure 1.7.

Figure 1.7

When all of hierarchies and relationships are set up, the cube can be launched. A fully implemented cube will look something like figure 1.8.

Figure 1.8

6. Browsing the CubeKeeping in mind that the ultimate goal of the data warehouse is to provide strategic information to managers and business owners, it is now time to browse the cube that you have created. This is the process where you are actually designing the queries that will provide the reports the end user is looking for. The Benchmark project is concerned primarily with commission that is collected from each transaction. In order to get a picture of the business as a whole it is more reasonable to query the data for commission from a particular region, or in our case, by each state. In figure 1.9, we have shown commission by state as it is presented in the cube browser.

Figure 1.9

This is a very high level of detail. If you were to add all of the hierarchies that are available to this query, you can drill the data down to provide commission for each employee in each

zip code, as it relates to each type and name of investment. This is shown in figure 1.10.

Figure 1.10

7. Generating useful reportsBeing able to browse the cube and design queries is a very powerful and useful tool. Unfortunately, to the end user of the system, some of these queries are almost unreadable within in the cube browser. Remember that the final result of this project is to provide strategic information that will be useful to management in making decisions that will affect the future health of the organization. These reports are not going to be provided to a member of the IT staff who would be comfortable viewing the format in the browser. Management will want a report that can be read and interpreted easily. Providing these kinds of reports is easily done once you have a functional cube. The cube that was initially created within Analysis Services can also be accessed with Reports Service which is another very powerful tool that is included in SQL Server 2008. By creating a Reports Services project, we were able to generate reports from the Benchmark warehouse that will be useful to the owner and management. The same information that is depicted in figure 1.9 is again displayed in figure 1.11 in a much easier to read format.

Figure 1.11

Another report that the Benchmark management wanted was Customers with High Risk Investments, figure 1.12, which would allow them to find customers who have money in an investment that is now considered to be high risk.

Figure 1.12

Even though this particular report does not directly track commission, it is directly related to the amount of commission that the company collects. The goal of Benchmark is help grow the retirement funds of their customers, and if they were to ignore these risky investments, they would lose money, ruin the reputation they have strived to build, and drive new and existing customers away. When there are no customers, there is no commission to keep track.

ConclusionEntering into the process of constructing a data warehouse with no prior knowledge of the subject proved to be quite a challenge. It also turned into an exceptional learning experience. We learned to carefully analyze the project that has been presented before diving into it head first. It is essential to do this so that you can be sure that the correct approach is being taken in regards to the end result. Starting with the desired result and working backwards turned out to be the direction that we ultimately took with this project, and is probably a viable approach to take when designing a data warehouse. A data warehouse is a report centric system, so beginning with an understanding of the desired output will lead to a much more efficient design plan. We believe that we have constructed a system that Benchmark will be able to rely on for their reporting needs for the foreseeable future.

Works Cited

Cameron, Scott. (2009) Microsoft SQL Server 2008 Analysis Services Step by Step. Redmund, Washington: Microsoft Press.

Ponniah, Paulraj. (2001) Data WarehousingFundamentals: A Comprehensive Guide for IT Professionals.New York, New York: John Wiley & Sons.