Requested: Tutorial Data Warehousing with Yukon

Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

All Forums

Old Forums

CLOSED - SQL Server 2005/Yukon

Requested: Tutorial Data Warehousing with Yukon

Author

Topic

SQLsearcher
Starting Member

47 Posts

Posted - 2006-10-03 : 09:58:02

Dear All

My company wants to use Sql Server 2005 Enterprise Edition as a data warehouse. I allready ordered the books below. They are very detailed. I need a book (or tutorial) that gives me a good overview. From there on I can use the books or MicroSoft's Virtual labs to figure out the details. Thanks in advance

Kind regards, Sql Searcher

Microsoft SQL Server 2005 Implementation and Maintenance (ISBN: 073562271X)
Microsoft SQL Server 2005 Analysis Services Step by Step (ISBN: 0735621993)

Page47
Master Smack Fu Yak Hacker

2878 Posts

Posted - 2006-10-03 : 12:13:08

Look for just about anything the Kimball Group has written. I've read most of the Microsoft Data Warehouse toolkit. It is pretty tutorial-like.

I've never seen an inexperienced DW team succeed. In my experience the technology and lines of code is only about 5% of a DW project. Your team would be best suited not focusing on SQL Server or whatever, but rather on requirements analysis and design.

Jay White

SQLsearcher
Starting Member

47 Posts

Posted - 2006-10-04 : 04:44:35

Hello Jay

Thanks for your quick response.

The good news is I also have Kimball's 'The Data Webhouse Toolkit: Building the Web-Enabled Data Warehouse' and I am ordering Kimball's 'The Microsoft Data Warehouse Toolkit: With SQL Server 2005 and the Microsoft Business Intelligence Toolset'.

The bad news is, I am the DW team and I am not very experienced. The reason I have to focus on Sql Server 2005, is because management told me so.

I don't want to spend my time and energy complaining (except about the coffee), that's why I want a clear overview. A kind of 'Data warehousing with Sql Server 2005 for Dummies'. If it doesn't exist, I have to go to follow a course. Any ideas?

Thanks for any support.

Kind regards, Sql Searcher

Page47
Master Smack Fu Yak Hacker

2878 Posts

Posted - 2006-10-05 : 13:10:25

I guess my point is subtle. DW w/ SQL2K5 for dummies = "The Microsoft Data Warehouse Toolkit: With SQL Server 2005 and the Microsoft Business Intelligence Toolset". But see, the dummies descriptor is in reference to SQL2K5 tools, not in reference to DW. Anyone who understands DW, can read that book and begin implementing in SQL2K5. Someone who doesn't understand DW can also read that book and begin implementing in SQL2K5. Only the first guy will have a system work a damn at the end of the day. Kimball has a brief intro into DW in that book with some good tips and tools. Start there and maybe that will open your eyes to the "things you didn't know that you didn't know" and from there you can seek other resources to fill in those blanks.

Jay White

SQLsearcher
Starting Member

47 Posts

Posted - 2006-10-06 : 06:04:32

Hello Jay

I think your point is I have to read 'Data Warehouse for Dummies' and 'Data Warehouse for Experts' before I start reading 'DW w/ SQL2K5 for dummies'. And I think you're right.

I will carefully read Kimballs intro.

Thanks, Sql Searcher

mwjdavidson
Aged Yak Warrior

735 Posts

Posted - 2006-10-06 : 06:32:53

Kimball's web site is also a great resource [url]www.ralphkimball.com[/url]. It sounds like you're going to have your work cut out for you! What's the purpose of the warehouse, and what sort of timescales do you have to work to? Does your management understand that these things are normally done by large teams - not a single person!?

Mark

SQLsearcher
Starting Member

47 Posts

Posted - 2006-10-10 : 10:37:20

Hello Mark

I already bookmarked RalphKimball.com. You're right, there is a lot of information. In fact there is too much information. I convinced my manager to hire a consultant to help me. My manager understands it has to be done by a large team. All we have to do is convince his manager ;-)

Kind regards, Sql Searcher

mwjdavidson
Aged Yak Warrior

735 Posts

Posted - 2006-10-10 : 10:59:03

Good luck!

Mark

blindman
Master Smack Fu Yak Hacker

2365 Posts

Posted - 2006-10-10 : 11:10:57

If you want to learn how to create datamarts, read Kimball.

If you want to learn how to create enterprise data warehouses, read Inmon.

"Once you establish possibility, all that remains are desire and determination."

SQLsearcher
Starting Member

47 Posts

Posted - 2006-10-13 : 05:14:04

Hello BlindMan

Can you lead this criple to more information about Inmon; what should I read, why should I read it, what did s/he write.

Thanks, Sql Searcher

blindman
Master Smack Fu Yak Hacker

2365 Posts

Posted - 2006-10-13 : 10:54:29

http://www.1keydata.com/datawarehousing/inmon-kimball.html

Bill Inmon espouses the idea of a comprehensive enterprise data warehouse relating information from many different business areas.
Kimball espouses the idea of separate datamarts for each business area, and then terms this collection of datamarts a "data warehouse". It is not. It is still just a collection of datamarts, which are basically glorified pivot tables.
Kimball's methodology has become popular simply because he markets it as the quick and easy way to create a datawarehouse. The problem is that when you start creating many of these separate datamarts within your organization you end up with a much larger administrative hassle trying to make sure that all the duplicated data between the marts is consistent, or you end up with reports from different datamarts giving different answers to similar queries. It also becomes problematic to create cross-disciplinary OLAP queries because no one datamart holds all the information you need.
Inmon's approach is more difficult at first, because it requires a true understanding of your business and how all the organizations within it relate to one another, but often the knowledge gained by going through this analysis is as valuable as the datawarehouse itself. Inmon then encourages both the direct querying of the data warehouse, as well as the creation of datamarts (often star schemas) from the datawarehouse for targeted analysis. The point is, with Inmon's method you have a single record of authority for your data, which Kimball's method lacks.

"Once you establish possibility, all that remains are desire and determination."

blindman
Master Smack Fu Yak Hacker

2365 Posts

Posted - 2006-10-13 : 10:56:35

Inmon's website:
http://www.inmoncif.com/home/

STAR SCHEMAS ARE NOT DATA WAREHOUSES!

blindman
Master Smack Fu Yak Hacker

2365 Posts

Posted - 2006-10-13 : 11:01:35

Oh, and this discussion does an excellent job of contrasting the two approaches:
http://www.dmreview.com/article_sub.cfm?articleId=4575

STAR SCHEMAS ARE NOT DATA WAREHOUSES!

SQLsearcher
Starting Member

47 Posts

Posted - 2006-10-20 : 08:04:01

Hello BlindMan

Thanks for the elaboration. I think I go for Kimball for the first (quick and dirty) phase of the project. I will use this knowledge for the second phase to choose between Kimball and Inmon.
When I'm done, I intend to write the overview I wanted to have.

Kind regards, Sql Server

blindman
Master Smack Fu Yak Hacker

2365 Posts

Posted - 2006-10-20 : 12:57:59

quote:
Originally posted by SQLsearcher

I think I go for Kimball for the first (quick and dirty) phase of the project. I will use this knowledge for the second phase to choose between Kimball and Inmon.

Then you still do not understand the differences in the two philosophies.

Kimball:
1) Build a datamart.
2) Build more datamarts and call the collection a data warehouse.

Inmon:
1) Build a a data warehouse.
2) Generate datamarts from the data warehouse.

The two philophies approach data wareshousing from opposite and opposing directions. How you start determines the result that you will get.

STAR SCHEMAS ARE NOT DATA WAREHOUSES!

SQLsearcher
Starting Member

47 Posts

Posted - 2006-10-21 : 07:57:11

Hello Blindman

I haven't read all books from, on and about Kimball and Inmon, yet ;-) I have only read summaries, reviews and blogs. So please forgive me my ignorance.

There are several differences between Kimball and Inmon. The difference you focus on (from datamart(s) to data warehouse or the other way around), is not very important in my situation, yet. Our project managers want facts and dimensions. They don't care if the data come from a datamart or a data warehouse. As a matter of fact, they don't really know what they want. That's why we started a two phase project. In the first phase I build a datamart (and call it a data warehouse) and generate reports. The purpose of this phase is to
1) identify the needs of our project managers;
2 & 3) write out our business rules and business processes;
4) identify bottle necks (conformed facts and dimensions, size of databases, processing time, hardware requirements and so on).

In phase two I will build a new (more solid) datamart (and call it a data warehouse again). I am sure that when other managers see the reports from the project managers, they also want such reports. This will lead to more datamarts and finally a data warehouse (Kimball). Or I can anticipate this growth and build a data warehouse and give every (type of ) manager its own datamart (Inmon).

So BlindMan, you are right. These are two different approaches. This means that after phase one, I have to sit down with management to determine which path to choose. Personally I prefere Inmon; it enables cross-disciplinary OLAP queries and single record of authority. However, I don't think there is a "true understanding of [our] business and how all the organizations within it relate to one another". The purpose of phase one is to get this understanding.

Kind regards, Sql Searcher

Subscribe to SQLTeam.com

SQLTeam.com Articles via RSS

SQLTeam.com Weblog via RSS

- Advertisement -

Resources