Slide1 l.jpg
Sponsored Links
This presentation is the property of its rightful owner.
1 / 20

Data Warehouse Considerations PowerPoint PPT Presentation


  • 210 Views
  • Uploaded on
  • Presentation posted in: Music / Video

Data Warehouse Considerations. Monty Bieber Teradata National Practice Partner October 28, 2005. Data Warehouse Considerations. Monty Bieber Teradata National Practice Partner October 28, 2005. The Classic Rock Guide to Data Warehousing. Monty Bieber Teradata National Practice Partner

Download Presentation

Data Warehouse Considerations

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Data Warehouse Considerations

Monty Bieber

Teradata National Practice Partner

October 28, 2005


Data Warehouse Considerations

Monty Bieber

Teradata National Practice Partner

October 28, 2005


The Classic Rock Guide to Data Warehousing

Monty Bieber

Teradata National Practice Partner

October 28, 2005


Monty R, BieberNational Practice Partner

National Accounts Division

2837 Dell Ridge Dr.

Holt, MI 48842-8718

Phone: 517-882-5521

Cell: 517-203-8417

[email protected]

Introduction

  • Professional Services Partner

  • Teradata Presales specialist for 8 years

  • Teradata DBA and project manager

  • Former State employee

  • Former music teacher

  • Even more former bass player in a completely unknown (thank goodness) band


Ten Points to Ponder

  • Integration

  • Dirty data

  • Building the perfect beast

  • Who’s paying for this?

  • The organization

  • Who needs it?

  • Tools

  • It’s not a mainframe

  • Great expectations

  • Data marts


Who Needs It?

  • A project of this scope needs a sponsor

    • Someone high up needs to care and commit

  • Who really benefits from the work?

    • The users may not be the ones to benefit most

  • Are you designing for the right people?

    • What problems is the warehouse supposed to solve?


Tools

  • All users are not alike

  • Many business questions require more than a simple query

  • Different tasks require different tools

  • Different demands call for different approaches


It’s Not a Mainframe

  • A data warehouse can’t and shouldn’t be run like a mainframe

  • Administrative concerns are very different

  • Space and use allocations are different, and always unpredictable

  • Restrictions should be applied sparingly


Great Expectations

  • It’s possible to oversell the value or performance of a data warehouse

  • User expectations can be set so high that they can never be fulfilled

  • Demos make everything look easy

  • Not all queries take3 seconds or less


Data Marts

  • Outside your warehouse

    • No matter what you read, it’s VERY difficult to bring together data from separate platforms

      • Different sources have different data issues

      • The web is a VERY poor place to bring data together

  • Inside your warehouse

    • Depending on why you do it, this is not necessarily a bad idea

    • Virtual data marts can be more effective than physical ones


Integration

  • It’s very tough to build an entire enterprise warehouse

  • It’s a major project with high probability of failure

  • Requirements will change

  • Just because you can’t do it all at once doesn’t mean it’s a bad idea

  • A solid and extensible model is the key


Dirty Data

  • The quality of your data is worse than you think

  • Bad data leads to bad answers

  • Cleaning up the data is a much larger task than you expect

  • The warehouse itself is often the most powerful data cleansing platform


Building the Perfect Beast

  • It’s possible to get caught up in the design and never deliver anything useful

    • Don’t try to model or build it all at once

    • Don’t try to capture every entity and attribute

    • Start with a self-contained area with high payback

  • “Good” now is better than “perfect” later


Who’s Paying for This?

  • The enterprise warehouse is a corporate asset

  • How do you charge it back?

    • Storage locker?

    • Taxi?

    • Make it an overhead cost?

  • Consider other factors

    • Active vs. dormant data

    • “Data velocity”


The Organization

  • A data warehouse has major organizational impacts

  • Job responsibilities will change

  • Labor issues may arise

  • Power bases will shift

  • Bad politics will defeat great technology any day

  • Encourage, don’t force

  • Demonstrate benefits for skeptics

  • Help power users find new power base


We’re Doomed, Aren’t We?

It may seem fiendishly difficult, but data warehousing projects can succeed!


Management Support

DILBERT reprinted by permission of United Feature Syndicate, Inc.


Conclusion (Happy Ending)

  • Solve a visible business problem that has high priority

  • Include business experts, knowledge workers, users on your project team

  • Architect the warehouse to enable an enterprise view of data

  • Deliver some new magic regularly


Questions?


™ Nipper is a Trademark of the RCA Division of Thompson Consumer Electronics, Inc.

Thanks for listening!


  • Login