Bottom-Up Approach the advantages

Bottom-Up Approach the advantages of this approach are:

• Faster and easier implementation-of a cable pieces
• Favorable return on investment and proof of concept
• Less risk of failure
• Inherently incremental; can schedule important dal, marts first
• Allows project team to learn and grow

The disadvantages are:

• Each data 'mart has Us own narrow view of data
• Permeates redundant data in every data mart
• Perpetuates inconsistent and irreconcilable data
• Proliferates unmanageable interfaces

In this bottom-up approach, you build your departmental data marts one by one. You would set a priority scheme to determine which data marls you must build first. The most severe drawback of this approach is data fragmentation. Each independent data mart will be blind to the overall requirements of the entire organization.

A Practical Approach In order to formulate an approach for your organization, you need to examine what exact-ly your organization wants. Is your organization looking for long-term results or fast data marts for only a few subjects for now'? Does your organization want quick, proof-of-concept, throw-away Implementations? Or. do you want to look into sonic other practical approach?

Although both the top-down and the bottom-up approaches each have their own advantages and drawbacks’ a compromise approach accommodating both views appears to be practical. The chief proponent °inns practical approach is Ralph Kimball, an eminent author and data warehouse „expert. 

The steps in this practical approach are as follows:

I. Plan and define requirements at the overall corporate level
2. Create a surrounding architecture for a complete warehouse
3. Conform and standardize the data content
4. Implement the data warehouse as a series of super-marts: one at a time

In this practical approach, you go to the basics and determine what exactly your organization wants in the long term. The key to this approach is that you first plan at the enterprise level. You gather requirements at the overall level. You establish the architecture for the complete warehouse.1 hen you determine the data content for each super-mart. Super-marts are carefully architected data marts. You implement these super-marts, one at a time. Before implementation, you make sure that the data content among the various super-marts are conformed in terms of data types, field lengths, precision, and semantics. A certain data clement must mean the same thing in every super mart. This will avoid spread of disparate data across several data marts…

A data mart, in this practical approach, is a logical subset of the complete data ware-house, a sort of pie-wedge or the whole data warehouse. A data Warehouse, therefore, is a conformed union of all data marts. Individual data marts are targeted to particular business groups in the enterprise but the collection of all data marts from an integrated whole called the enterprise data warehouse. When we refer to data warehouses and data marts in our discussions here, we use the meanings as understood in this practical approach. For us, a data warehouse means a collection or the constituent data marts.  

How are They Different

How are They Different?

Let us take a dose look at Figure 2-5. here are the two different basic approaches: (I) overall data warehouse feeding dependent data marts, and (2) several departmental or local data marts combining into a data warehouse. In die first approach, you extract data from the operational systems; you then transform, clean, integrate, and keep the data in the data warehouse. So, which approach is best in your case, the top-down or the bottom-up approach'? Let us examine these two approaches carefully. 

Figure 2-5 Data wart /muse versus data mart.

Top-Down Various Bottoms-Up Approach
Top-Down Approach

The advantages of this approach are:

• A truly corporate effort, an enterprise view of data
• Inherently architecture --not a union of disparate data marts
• Single, central storage of data about the content
• Centralized rules and control
• May see quick results if imp1emerftd with iterations 

The disadvantages are:

• Takes longer to build even with an iterative method
• High exposure/risk to failure
• Needs high level of cross-functional skills
• High outlay without proof of concept

This is the big-picture approach in which you build the overall, big, enterprise-wide data warehouse. Here you do not have a collection of fragmented islands of information. The data warehouse is large and integrated. This approach, however, would take longer to build and has a high risk of failure. If you do not have experienced professionals on your team. This approach could be dangerous. Also, it will be difficult to sell this approach to senior management and sponsors.

DATA WAREHOUSES AND DATA MARTS

DATA WAREHOUSES AND DATA MARTS
If you have been following the literature on data warehouses for the past few years. you would, no doubt, have come across the terms "data warehouse" and "data mart." Many who are new to this paradigm are confused about these terms. Some authors and vendors use the two terms synonymously. Some make distinctions that are not clear enough. At this point, it would be worthwhile for us to examine these two terms and take our position.

Writing in a leading trade Magazine in 1.998, Rill button stated. "The single most important issue lacing the IT manager this year is whether to build the data warehouse first or the data mart first." This statement is true even today. Let us examine this statement and take a stand.

THREE DATA LEVELS IN A BANKING DATA WAREHOUSE 

Data granularity refers to the level of detail. Depending on the requirements, multiple levels of detail may be present. Many data warehouses have at least dual levels of granularity.

Figure 2-4 Data granularity.

Before deciding to build a data warehouse for your organization, you need to ask the following basic and fundamental questions and address the relevant issues:

• Top-down or bottom-up approach'?
• Enterprise-wide or departmental'?
• Which first, ----data warehouse or data mart?
• Build pilot or go with a full-fledged implemental ion?
• Dependent or independent data marts?

These are critical issues requiring careful examination and planning. Should you look at the big picture of your organization, take a top-down approach, and build a mammoth data warehouse'? Or, should you adopt a bottom-up approach, look at the individual local and departmental requirements, and build bite-size departmental data marts?

Should y01,1 build a large data warehouse and then let that repository feed data into lo-cal. departmental data marts'? On the other hand, should you build individual local data marts, and combine them to form your overall data warehouse? Should these local data tunits bc independent of one another? Or, should they be dependent on the overall data warehouse for data feed? Should you build a pilot data mart'? These arc crucial questions.