Examples of Business Dimensions

Examples of Business Dimensions

The concept of business dimensions-is fundamental to the requirements definition for a data warehouse. Therefore, we want to look at some more examples of business dimensions in a few other cases. Figure 5-3 displays the business dimensions in four different cases.

Let us quickly look at each of these examples. For the supermarket chain, the measurements that are analyzed are the sales units. These are analyzed along four business dimensions. When you are looking for the hypercube, the sides of such cubes are time, Promotion, product, and store. If you are the Marketing Manager for the supermarket chain, you would want your sales broken down by product, at each store, in 'laic sequence, and in relation to the promotions that take place.

For the insurance company, the business dimensions are different and appropriate for that business. Here you would want to analyze the claims data by agent, individual claim, time, insured party, individual policy, and status of the claim. The example of the airlines company shows the dimensions for analysis of frequent flyer data. Here the business dimensions are Mile, customer, specific flight, fare class, airport, and frequent flyer status.

The example analyzing shipments for a manufacturing company show some other business dimensions. In this case, the business dimensions used for the analysis of shipments are the ones relevant to that business and the subject of the analysis. I tem you see the dimensions of lime, ship-to and ship-from locations, shipping mode, product, and any special deals. 

What we find from these examples is that the business dimensions are different and relevant to the industry and to the subject for analysis. We also find the time dimension to be a common dimension in all examples. Almost all business analyses arc performed over time.

Dimensional Nature of Business

Dimensional Nature of Business

Data fortunately, the situation is not as hopeless as it seems. Even though the users cannot fully describe what they want in a data warehouse, they can provide you with very important insights into how they think about the business. They can tell you what measurement units are important for them. Each user department can let you know how they measure success in that particular department. The users can give you insights into how they combine the various pieces of information for strategic decision making.

Managers think of the business in terms of business dimensions. Figure 5-1 shows the kinds of questions managers are likely to ask for decision making. The figure shows what questions a typical Marketing Vice President, a Marketing Manager, and a Financial Consulter may ask.

Figure 5-1 Managers think in Business Dimensional

Let us briefly examine these questions. The Marketing Vice President is interested in the revenue generated by her new product, but she is not interested in a single number. She is interested in the revenue numbers by month, in a certain division, by demographic, by sales office relative to the previous product version, and compared to plan. So the Marketing Vice President wants the revenue numbers broken down by month, division, customers demographic, sales office, product version, and idin. These are her business dimensions along which she wants to analyze her numbers.

Similarly, for the Marketing Manager, his business dimensions arc product, product category, time (day, week, month), sale district and distribution channel. For the Financial Controller, the business dimensions are budget line, time (month, quarter and years), district, and division.

If your users of the data warehouse think in terms of business dimensions for decision making, you should also think of business dimensions while collecting requirements. Although the actual proposed usage of a data warehouse could be unclear, the business dimensions used by the managers for decision making are not nebulous at all. The users will be able to describe these business dimensions to you. You are not totally lost iii the process of requirements definition. YOU can find out about the business dimensions.

Let us try to get a good grasp of the dimensional nature of' business data. Figure 5-2 shows the analysis of sales units along the three business dimensions of product, time, and geography. These three dimensions arc plotted against three axes of coordinates. You will see that the three dimensions form a collection of cubes. In each of the small dimensional cubes, you will find the sales units for that particular slice of time product and geographical division. In this case, the business data of sales units is three dimensional because there are just three dimensions used in this analysis. 

Figure 5-2 Dimensional nature of business data 

If there are inure than three dimensions, we extend the concept to multiple dimensions and visualize multidimensional cubes, also called hypercube.

Usage of Information Unpredictable

Usage of Information Unpredictable

Let us imagine you are building an operational system for order processing in your company. For gathering requirements, you interview the users in the Order Processing department. The users will list all the functions that need to be performed. They will inform you how they receive the orders, check stock, verify customers' credit arrangements, price the order determine the shipping arrangements. and route the order to the appropriate ware-house. They will show you how they %mild like the various data elements to be presented on the GUI (graphical user interface) screen for the application. The users will also give you a list of reports they would need from the order processing application. They writ be able to let you know how and when they would use the application daily.

In providing inhumation about the requirements hr an operational 'system, the users are able to give you precise details of the required functions, information content, and us-age patterns. In striking contrast, roc a data warehousing system, the users are generally unable to define their requirements clearly. They cannot define precisely what information they really want from the data warehouse, nor can they express they would like to use the information or process it.

For most or the users, this could be the very first data warehouse they are being exposed to. The users are familiar with operational systems because they use these in their daily work, so they are able to visualize the requirements for other new operational systems. They cannot relate a data warehouse system to anything they have used before.

If therefore, the whole process of defining requirements for a data warehouse is so nebulous, how can you proceed as one or the analysts in the data warehouse project'? You are in a quandary. To be on the safe side, do you then include every piece of data you think the users will be able to use? How can you build something the users are unable to define clearly and precisely'?

Initially, you may collect data on the overall business of the organization. You may cheek on the industry's best practices. You may gather some business rules guiding the day-to-day decision making. You may find out how products are developed and marketed. But these arc generalities and are not sufficient to determine detailed requirements.

DEFINING THE BUSINESS REQUIREMENTS

CHAPTER 5  DEFINING THE BUSINESS REQUIREMENTS
CHAPTER OBJECTIVES

• Discuss how and why defining requirements is different for data warehouse
• Understand the rote of business dimensions
• Learn about information packages and the use in defining requirements
• Review methods for gathering requirements
• Grasp the significance of a formal requirements definition document

A data warehouse is an information delivery system. It is not about technology, but about solving users' problems and providing strategic information to the user. In the phase of defining requirements, you need to concentrate on what information the users need not so much on how you are going to provide the required 'information. The actual methods for providing information will come later, not while you are collecting requirements.

Most of the developers of data warehouses come from a background of developing operational or OLTP (online transactions processing) systems. OLTP systems are primarily data capture systems. On the other hand, data warehouse systems arc information delivery systems. When you begin to collect requirements for your proposed data warehouse, your mindset will have to be different. You have to go front a data capture model to an information delivery model. This difference will have to show through all phases of the data ware-home project.

The users also have a different perspective about a data warehouse system. Unlike an OLTP system which is needed to run the day-to-day business, no immediate payout is seen in a decision support system. The users do not sec a compelling need to use a decision supports system whereas they cannot refrain from using an operational system. Without which they cannot run their business.

DIMENSIONAL ANALYSIS

In several ways, building a data warehouse is very different from building an operational system. This becomes notable especially in the requirements gathering phase. Because of this difference, the traditional methods of collecting requirements that work well for operational systems cannot be applied to data warehouses.

70-342 Question 2

70-342 Question 2

The Internet link in the Tampa office will be unavailable during the weekend. You need to ensure that all outbound email messages are sent from the Charlotte office during the planned outage. What should you do? 

70-342

A. Modify the cost of the Tampa SMTP Send connector.
B. Create a new mail exchanger (MX) record named SMTP2.fabrikam.com in the internal DNS zone.
C. Modify the smart host of the Tampa SMTP Send connector.
D. Modify the preference value of the fabrikam.com mail exchanger (MX) records.

Answer: C