Ships from: Pleasant View, TN
Usually ships in 1-2 business days
Ships from: fallbrook, CA
Usually ships in 1-2 business days
Ships from: acton, MA
Usually ships in 1-2 business days
Why I Wrote This Book.
How to Use This Book.
PART I: The Data Warehouse: Home for Your Secondhand Data.
PART II: Data Warehousing Technology.
PART III: Business Intelligence and Data Warehousing: Not a Contradiction in Terms.
PART IV: Data Warehousing Projects: How to Do Them Right.
PART V: Data Warehousing: The Big Picture.
PART VI: Data Warehousing in the Not-Too-Distant Future.
PART VII: The Part of Tens.
Icons Used in This Book.
A Word about the Product References in This Book.
PART I: The Data Warehouse: Home for your Secondhand Data.
Chapter 1: What's in a Data Warehouse?
The Data Warehouse: A Place for Your Used Data.
More Formal Definitions.
Today's data warehousing defined.
A broader, forward-looking definition.
A Brief History of Data Warehousing.
The 1970s.
The 1980s.
The 1990s.
Is a Bigger Data Warehouse a Better Data Warehouse?
Realizing That a Data Warehouse (Usually) Has a Historical Perspective.
It's Data Warehouse, Not Data Dump.
Chapter 2: What Should You Expect from Your Data Warehouse?
Using the Data Warehouse to Make Better Business Decisions.
Finding Data at Your Fingertips.
Facilitating Communications with Data Warehousing.
IT-to-business-organization communications.
Communications across business organizations.
Facilitating Business Change with Data Warehousing.
Chapter 3: Have It Your Way: The Structure of a Data Warehouse.
Ensuring That Your Implementations Are Unique.
Classifying the Data Warehouse.
The data warehouse lite.
Subject areas.
Data sources.
Database.
Data content.
Tools.
Data extraction, movement, and loading.
Architecture.
The data warehouse deluxe.
Subject areas.
Data sources.
Database.
Data content.
Tools.
Data extraction, movement, and loading.
Architecture.
The data warehouse supreme.
Subject areas.
Data sources.
Database.
Data content.
Tools.
Data extraction, movement, and loading.
Architecture.
Double data warehouse with cheese.
To Centralize or Distribute, That Is the Question.
Chapter 4: Data Marts: Your Retail Data Outlet.
The Idea behind Data Marts.
Architectural Approaches to Data Marts.
Data marts sourced by a data warehouse.
Tactical, quick-strike data marts.
Bottom-up, integration-oriented data marts.
What Should Be in a Data Mart.
Geography-bounded data.
Organization-bounded data.
Function-bounded data.
Competitor-bounded data.
Answers to specific business questions.
Anything!
Implementing a Data Mart — Quickly.
PART II: Data Warehousing Technology.
Chapter 5: Relational Databases and Data Warehousing.
The Old Way of Thinking.
A technology-based discussion: The roots of relational database technology.
The OLAP-only fallacy.
The New Way of Thinking.
Understanding how RDBMSs were enhanced to support data warehousing.
Handling the very large database (VLDB) problem — and getting the RDBMS answer.
Designing Your Relational Database for Data Warehouse Usage.
Looking at why traditional relational design techniques don't work well.
Explaining normalization in plain language (or trying to).
The side effect of normalization.
Exploring new ways to design a relational-based data warehouse.
Relational Products and Data Warehousing.
IBM DB2 family.
Informix.
Microsoft SQL Server.
Oracle.
Red Brick.
Sybase.
Chapter 6: You're Entering a New Dimension: Multidimensional Databases.
The Idea behind Multidimensional Databases.
Facts.
Dimensions.
The basics.
"Is there a limit to the number of dimensions?".
"How should I choose the levels in a hierarchy?".
Physical database structures in an MDDB.
Are Multidimensional Databases Still Worth Looking At?
Other Specialized Database Technology for Data Warehousing.
Sybase IQ.
In-memory databases: Is anything really there?
Chapter 7: Stuck in the Middle with You: Data Warehousing Middleware.
What Is Middleware?
Middleware for Data Warehousing.
The services.
Should you use tools or custom code?
What Each Middleware Service Does for You.
Data selection and extractions.
Data quality assurance (QA), Part I.
Data movement, Part I.
Data mapping and transformation.
Data quality assurance (QA), Part II.
Data movement, Part II.
Data loading.
Replication Services for Data Warehousing.
Vendors with Middleware Products for Data Warehousing.
Carleton Corporation.
Evolutionary Technologies International (ETI).
Informatica.
Platinum Technology.
Praxis International.
Prism Solutions.
Reliant Data Systems.
Sagent Technology.
VMARK.
PART III: Business Intelligence and Data Warehousing.
Chapter 8: An Intelligent Look at Business Intelligence.
The Four Main Categories.
Querying and reporting.
OLAP.
Data mining.
Executive Information Systems (ELS).
Other Types of Business Intelligence.
Statistical processing.
Geographical information systems.
Business Intelligence Architecture and Data Warehousing.
Chapter 9: Simple Database Querying and Reporting.
What Functionality Does a Querying and Reporting Tool Provide?
The role of SQL.
The idea of managed queries and reports.
Is This All You Need?
Designing a Relational Database for Querying and Reporting Support.
Vendors with Querying and Reporting Products for Data Warehousing.
Andyne.
Business Objects.
Cognos Corporation.
Information Builders.
Microsoft Corporation.
Seagate Software.
Chapter 10: Online Analytical Processing (OLAP).
What Is OLAP?
The OLAP Acronym Parade.
First, an Editorial.
OLAP Features: An Overview.
Drill-down.
Drill-up.
Drill-across.
Drill-through.
Drill-bit.
Pivoting.
Trending.
Vendors with OLAP Products for Data Warehousing.
Arbor Software.
Brio Technology.
Gentia.
Information Advantage.
Informix.
MicroStrategy.
Oracle Corporation.
Seagate Software.
Chapter 11: Data Mining: Hi-Ho, Hi-Ho, It's Off to Mine We Go.
Data Mining without the Hype.
The "Tell me what may happen" role.
The "Tell me something interesting" role.
Data Mining in Specific Business Missions.
Haven't I Heard This Before?
Data Mining and Artificial Intelligence.
Data Mining and Statistics.
Some Vendors with Data Mining Products.
CrossZ Software.
DataMind Corporation.
HNC Software.
IBM.
NeoVista Solutions.
Thinking Machines Corporation.
Chapter 12: Executive Information Systems (ELS).
ElS Principles.
The Relationship between ElS and the Other Parts of Business Intelligence.
ElS and Key Indicators.
The Briefing Book.
The Command Center.
Who Produces EIS Products.
PART IV: Data Warehousing Projects: How to Do Them Right.
Chapter 13: Data Warehousing and Other IT Projects: The Same but Different.
Why a Data Warehousing Project Is (Almost) Like Any Other Development Project.
How to Apply Your Company's Best Development Practices to Your Project.
How to Handle the Uniqueness of Secondhand Data.
Why Your Data Warehousing Project Must Have Top-Level Buy-In.
How Do I Conduct a Large, Enterprise-Scale Data Warehousing Initiative?
Top-down.
Bottom-up.
Mixed-mode.
Chapter 14: Building a Winning Data Warehousing Project Team.
Don't Make This Mistake!
The Roles You Have to Fill on Your Project.
Project manager.
Technical leader.
Chief architect.
Business requirements analyst.
Data modeler and conceptual/logical database designer.
Database administrator and physical database designer.
Front-end tools specialist and developer.
Middleware specialist.
Quality assurance (QA) specialist.
Source data analyst.
User community interaction manager.
Technical executive sponsor.
User community executive sponsor.
And Now, the People.
Chapter 15: Analyzing Data Sources.
Begin with Source Data Structures, but Don't Stop There.
Identify What Data You Need to Analyze.
Line Up the Help You'll Need.
Techniques for Analyzing Data Sources and Their Content.
Analyze What's Not There: Data Gap Analysis.
Determine Mapping and Transformation Logic.
Chapter 16: User Testing, Feedback, and Acceptance.
Recognizing That Early User Involvement Is Critical to Data Warehousing Success.
Using Real Business Situations.
Ensuring That Users Provide Necessary Feedback.
After the Scope: Involving Users during Design and Development.
Understanding What Determines User Acceptance.
PART V: Data Warehousing: The Big Picture.
Chapter 17: Dealing with External Data.
Identifying Data You Need from Other People.
Recognizing Why External Data Is Important.
Viewing External Data from a User's Perspective.
Determining What External Data You Really Need.
Ensuring the Quality of Incoming External Data.
Filtering and Reorganizing Data after It Arrives.
Restocking Your External Data.
Acquiring External Data.
Finding this type of information.
Gathering general information.
Cruising the Internet.
Maintaining Control over External Data.
Staying on Top of Changes.
Knowing What to Do with Historical External Data.
Determining When New External Data Sources Are Available.
Switching from One External Data Provider to Another.
Chapter 18: Data Warehousing and the Rest of Your Information Systems.
A Data Warehouse Does Not Stand Alone.
The Infrastructure Challenge.
Strategic Initiatives: Watch Out!
Internal Standards and How They Affect Your Data Warehousing Environment.
Dealing with Conflict: Special Challenges to Your Data Warehousing Environment.
Chapter 19: The View from the Executive Boardroom.
What Does Top Management Need to Know?
Tell them this.
Keep selling the data warehousing project.
Data Warehousing and the Business Trends Bandwagon.
Data Warehousing in a Cross-Company Setting.
Chapter 20: Surviving in the Computer Industry (and Handling Vendors).
Help — I'm Up to My Armpits in Hype!
How to Be a Smart Shopper at Conferences and Trade Shows.
Do your homework first.
Ask lots of questions.
Be skeptical.
Don't get rushed into a purchase.
Dealing with Data Warehousing Product Vendors.
Check out the product and the company before you begin discussions.
Take the lead during the meeting.
Be skeptical — again.
Be a cautious buyer.
A Look Ahead: Mainstream Technologies and Vendors.
Chapter 21: Existing Sort-of Data Warehouses: Upgrade or Replace?
What's Out There?
The first step: Cataloguing the extract files, who uses them, and why.
And then, the review.
Decisions, Decisions.
Choice 1: Get rid of it.
Choice 2: Replace it.
Choice 3: Retain it.
Caution: Migration Is Not Development — It's Much More Difficult.
Beware: Don't Take Away Valued Functionality.
Chapter 22: Working with Data Warehousing Consultants.
Do You Really Need Consultants to Help Build a Data Warehouse?
Watch Out, Though!
A Final Word about Data Warehousing Consultants.
PART VI: Data Warehousing in the Not-too-Distant Future.
Chapter 23: The Operational Data Store (I" Need Information Now!").
The ODS Defined.
An ODS Example.
The complications.
The ODS solution.
ODS Architectural Challenges.
The basics: Warehouse-enabled applications.
Messaging.
Feedback loops.
Data message hubs.
Chapter 24: Show Me the Pictures: Incorporating Multimedia.
Traditional Data Warehousing Means Analyzing Traditional Data Types.
"It's a Multimedia World, after All ".
How Will Multimedia Business Intelligence Work?
An Alternative Path: From Unstructured Information to Structured Data.
Chapter 25: Virtual Data Warehousing: Hype or Trend?
Looking at the Basics of Virtual Data Warehousing.
Background.
Market repositioning.
Challenges.
Examining Why Traditional Virtual Data Warehousing Doesn't Work.
The architecture.
The synthesis service.
Other services.
Facing the Infrastructure Challenge.
Making Virtual Data Warehousing a Reality in Your Organization.
PART VII: The Part of Tens.
Chapter 26: Ten Vital "Deliverables" for the End of Your Project Scope.
A Complete, Prioritized List of Functionality to Be Provided.
A Complete List of All Candidate Data Sources.
A Design-Phase Project Plan.
The Names and Respective Roles of Your Design-Phase Project Team.
A Complete Budgetary Estimate.
Consensus about the Mission.
Risk Assessment and a Plan to Manage Risk.
A Gap Analysis.
Tentative Executive-Level Support.
Logistical Requirements and Support Plans.
Chapter 27: Ten Questions to Consider When You're Selecting User Tools.
Can Users Easily Build Their Own Query and Report Screens?
Can a User Stop a Runaway Query or Report?
How Does Performance Differ with Varying Amounts of Data?
Can Users Access Different Databases?
Can Data Definitions Be Easily Changed?
Does the Tool Fit into Your Organization's Standard Desktop Configuration?
How Does Performance Change with a Large Number of Users?
What Online Help and Assistance Is Available, and How Good Is It?
Does the Tool Support Interfaces to Other Products?
What Happens When You Pull the Plug?
Chapter 28: Ten Secrets to Managing a Project Successfully.
Tell It Like It Is.
Put the Right People in the Right Roles.
Be a Tough but Fair Negotiator.
Deal Carefully with Product Vendors.
Watch the Project Plan.
Don't Micromanage.
Use a Project Notebook.
Don't Overlook the Effect of Organizational Culture.
Don't Forget about Deployment and Operations.
Take a Breather Occasionally.
Chapter 29: Ten Sources of Up-to-Date Information about Data Warehousing.
The Data Warehousing Institute.
The Data Warehousing Information Center.
The OLAP Report.
Datamation.
data-warehouse.com.
Data Warehousing on the World Wide Web.
The International Data Warehousing Association.
Industry Analysts' Web Sites.
Cambridge Technology Partners.
Product Vendors' Web Sites.
Chapter 30: Ten Mandatory Skills for a Data Warehousing Consultant.
Broad Vision.
Deep Technical Expertise in One or Two Areas.
Communications Skills.
The Ability to Analyze Data Sources.
The Ability to Distinguish between Requirements and Wishes.
Conflict-Resolution Skills.
An Early-Warning System.
General Systems and Application Development Knowledge.
The Know-How to Find Up-to-Date Information.
A Hypefree Vocabulary.
Chapter 31: Ten Signs of a Data Warehousing Project in Trouble.
The Project's Scope Phase Ends with No General Consensus.
The Mission Statement Gets Questioned after the Scope Phase Ends.
Tools Are Selected without Adequate Research.
People Get Pulled from Your Team for "Just a Few Days".
You're Overruled When You Attempt to Handle Scope Creep.
Your Executive Sponsor Leaves the Company.
You Overhear, "This Will Never Work, but I'm Not Saying Anything".
You Find a Major "Uh-Oh" in One of the Products You're Using.
The IT Organization Responsible for Supporting the Project Pulls Its Support.
Resignations Begin.
Chapter 32: Ten Signs of a Successful Data Warehousing Project.
The Executive Sponsor Says, "This Thing Works — It Really Works!".
You Receive a Flood of Suggested Enhancements and Additional Capabilities.
User Group Meetings Are Almost Full.
The User Base Keeps Growing and Growing and Growing.
The Executive Sponsor Cheerfully Volunteers Your Company As a Reference Site.
The Company CEO Asks, "How Can I Get One of Those Things?".
The Response to Your Next Funding Request Is "Whatever You Need — It's Yours".
You Get Promoted — and So Do Some of Your Team Members.
You Achieve Celebrity Status in the Company.
You Get Your Picture on the Cover of Rolling Stone.
Chapter 33: Ten Subject Areas to Cover with Product Vendors.
The Product's Chief Architect.
The Development Team.
Customer Feedback.
Employee Retention.
The Marketplace.
Product Uniqueness.
Clients.
The Future.
Internet Approach.
Integrity.
Index.
Book Registration Information.
In This Chapter
About two weeks before writing this chapter, I was on a business trip to Los Angeles and driving down the Ventura freeway on a nice summer day. (I always call it the Ventura highway, after the America song from the 1970s: "Ventura highway, in the sunshine; where the days are longer...." Oops, I got a little carried away there.) An ad was on the radio for a regional (I think) hardware chain based on this premise: "Shop at our stores because we have fewer products than the big warehouse-like competition. It's much easier to get in and out of here more quickly with what you need."
Interestingly, another hardware chain on the east coast ran ads a few years ago with almost the identical theme. This chain used to make fun of the warehouse-size competition by featuring radio ads with helicopter search parties looking for shoppers lost in a distant department and references to shuttle buses having to take shoppers between departments in the warehouse-size stores. The premise was the same: "We have less merchandise than the other guy, so shop with us because it's easier."
That's the idea of the data mart.
Forget all the hype. The idea of a data mart is hardly revolutionary, despite what you may read in the computer trade press and hear at conferences and seminars.
A data mart is simply a scaled-down data warehouse, that's all.
No official, standard definition exists for a data mart, just as no official, standard definition exists for a data warehouse or operational data store or data mining or virtually any other concept in this realm of the technology landscape. Vendors do their best to define data marts in the context of their products; consultants and analysts usually define data marts in a way that's advantageous to their particular offerings and specialties. That's the way this business goes, and there's nothing wrong with it; be prepared, however, to ask the tough questions.
You can take one of three main approaches to creating a data mart:
Many data warehousing experts would argue (and I'm one of them, in this case) that a true data mart is a "retail outlet" with its contents provided from a data warehouse, as shown in Figure 4-1.
In an environment like the one shown in Figure 4-1, look at the relationship between the data sources, the data warehouse, the data mart, and the user in this way:
Before moving on to the next approach, though, I want to show you a variation of the sourced-from-the-warehouse model. Sometimes the data warehouse that serves as the source for the data mart does not have all the information the data mart's users need. You can solve this problem in one of two ways:
If your data mart needs data that's not in the data warehouse, which of these two approaches should you choose? If your data mart is the only one within your company that needs that additional data (be sure to ask around), leave the warehouse alone and bring the supplemental data directly into your data mart. If other data marts or other projects served by the data warehouse can use the additional information, you should add it to the data warehouse first and then send it, along with the other contents you need, to your data mart.
Sometimes you just don't have a data warehouse from which to get data for your data mart, so you have to do it yourself. In many (probably most) of these situations, you create a tactical, quick-strike data mart that is, in effect, a miniature data warehouse. You follow the same methodology and complete the same processes of data extraction, transformation, quality assurance, and loading. The difference is that you're doing it on a smaller scale than with a full-blown data warehouse.
What does a smaller scale mean? As shown in Figure 4-4, data brought into a tactical data mart is often necessary to answer a specific set of business questions within relatively narrow confines. Some examples are a specific region or territory within a company, a subset of a company's overall product line, or some other subsetting model.
So the question must be asked: If you have to start from scratch and don't have a data warehouse to provide data to your data mart, why not build a full-scale data warehouse instead? Here are three reasons to go the data mart route:
What happens, though, if pressing business needs steer you toward a tactical data mart and you have a longer-term vision of its contents being integrated with other data? Have you created an architectural dead end? Will you have to throw away your data mart at some point and start over with a "real" data warehousing effort? Will Batman arrive in time to save Robin from the Riddler? (Sorry about that -- the reruns are getting to me.)
Theoretically, you can design data marts so that they're eventually integrated in a bottom-up manner, by building a data warehousing environment (in contrast to a single, monolithic data warehouse).
Pay close attention to the word theoretically. Bottom-up integration of data marts isn't for the fainthearted. You can do it, but it's more difficult than creating a tactical data mart that will always remain stand-alone. Can this approach be successful? The answer is a definite maybe.
If a data mart is a smaller-scale version of a data warehouse, the question comes up again: What does "smaller scale" mean in reference to the contents of a data mart?
This section describes some ways you can select subsets of information for a data mart and the circumstances under which you may want to try each approach.
A data mart may contain only the information relevant to a certain geographical area, such as a region or territory within your company. Figure 4-5 illustrates an example of geography-bounded data.
Although the use of a geography-bounded data mart is technically feasible and relatively straightforward, it's often not such a good idea. Why? Because a cross-geography comparison (for example, "How are our Arizona stores doing versus our Pennsylvania stores?") is a natural use of any data warehouse environment. When you create separate data marts for various geographical reasons, you make it much more difficult to make these types of comparisons.
Another approach to deciding what should be in your data mart is to base decisions on what information a specific organization needs when it's the sole (or at least primary) user of the data mart. As shown in Figure 4-6, a bank may create one data mart for consumer checking-account analysis and another data mart for commercial checking accounts.
This approach works well when the overwhelming majority of inquiries and reports are organization-oriented. That is, the commercial checking group has no need whatsoever to analyze consumer checking accounts and vice versa. It pays to dig into the business needs during the scope phase of a data warehousing or data mart project. Outsiders, for example, may think, "Okay, put all checking-account information, both consumer and commercial, into the same environment because, this way, reports can be run comparing average balances and other information for the entire checking-account portfolio at the bank." After additional analysis, though, you may notice that the bank doesn't do this type of comparison, so why not keep the two areas separate and avoid unnecessary complexity?
Using another approach, one that crosses organizational boundaries, you establish a data mart's contents based on a specific function (or set of related functions) within the company. A multinational chemical company, for example, may create a data mart exclusively for the sales and marketing functions across all organizations and across all product lines, as shown in Figure 4-7.
A company may occasionally be so focused on a specific competitor that it may make sense to create a data mart oriented toward that particular competitor. As shown in Figure 4-8, this type of environment may include competitive sales, all available public information about the competitor (particularly if the information is available over the Internet), and industry analysts' reports, for example.
To truly provide the business intelligence that's necessary in a competitor-driven situation, you should construct the data mart to include multimedia information in addition to the traditional data types typically found in a data warehouse. (Chapter 24 describes multimedia data and data warehousing.)
An organization's operations occasionally are driven by the answers to a selected number (often a handful) of business questions. Based on the answers, a company may speed up or slow down production lines, start up extra shifts to increase production or initiate layoffs, or, possibly, choose to acquire or not acquire other companies.
Business questions with this degree of weighty importance have traditionally caused nightmares for the in-house employees chartered with digging out data and reports, consolidating and checking the information, and reporting the results to executive management. Sounds like a job for a data warehouse, you say? Before constructing a full-scale data warehouse that can answer these (and many other) business questions, however, it's probably worth considering that the answer may be a small-scale data mart designed specifically to answer those high-impact, high-value "How are we doing?" type of questions.
Later, this type of environment may grow into a larger-scale data warehouse. It often makes more sense, however, to concentrate your efforts on supporting a data mart with known business value instead of on supplementing it with volumes of additional data that may provide business value (but can also slow response time or significantly complicate the end-to-end architecture). Again, the job you do up-front, in the early phases of your project, make a big difference in the direction you take and your level of success.
Any set of criteria you can dream up can determine a data mart's contents. Some make sense; others don't. Some take you into an architectural dead end because you get only limited value and have to start all over to expand your capabilities.
|
Data mart or data warehouse? Now that you (presumably) have read an entire chapter about the concept of data marts, I want to make one important point. If you start a project from the outset with either of the following premises, you already have two strikes against you:
By labeling your project as one or the other of these terms, you already have made some preconceived notions about the work you will do, before you have even begun to dig into the business problem. Until you understand the following three issues, you have no foundation on which to classify your impending project as either a data mart or a data warehouse:
As mentioned at the beginning of this chapter, what's more important is that no formal definitions distinguish a data mart from a data warehouse. If you're extracting and rehosting a subset of data from an existing application into another environment, you can accurately deem what you're building as a data mart. If you're starting from scratch, however, and extracting data from one or more source systems, handling the quality assurance and transformation, and copying that data into a separate environment, what determines whether you're building a data warehouse or a data mart? Although some guidelines exist, such as number of subject areas and volumes of data, it all comes down to this statement: As soon as you start labeling your environment as one or the other, you're adding preconceived notions and beliefs about its characteristics that may not fit your business needs. Here's the answer: Forget about the terms data warehouse and data mart. Concentrate instead on your business problem and its possible solution: What data do you need in order to perform certain informational and analytical functions; where is that data now and in what form; and what do you have to do to make it available to your users? Leave the terminology wars to the vendors and analysts. Don't get caught up in the hype. |
No matter how you decide to divide the universe of possible contents into some subset for your data mart, it's important to remember that in order to obtain maximum business value from your data mart, you must implement it quickly.
Here are the three keys to speedy implementation:
Overview