Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

How many different Warehouses per one company ? 2

Status
Not open for further replies.

Recce

Programmer
Aug 28, 2002
425
ZA
Hi

I was thinking about what others may say about this question.

If you are working for a very large company then, would it be wrong or what would be wrong with having more than one Data Warehouse per company for i.e. the one big reason for maybe having more than one Data Warehouse would be for performance purposes. In other words if users from Finance demand more regular updates then users from HR then would it be wrong to create a Data Warehouse for Finance that run independently from the other departments.

I know that some of the responses here may be that where do you draw the line on how many there is in a company and that is a valid question but, is there any value in this approach ?

Regards

[pipe] "We know nothing but, that what we know is not the truth..." - Me
 
It depends on what definition you use for Data Warehouse. You would definitely be safe having different Data Marts for different areas of the business. However it would be best practice to utilize conformed dimensions if you are using dimensional modeling. This means that if you are storing information about Manufacturing Plants, for example, you would do so only once. If both HR and Finance needed that information, they would both utilize the same dimension.

 
Take a look at the latest approach towards corporate datawarehousing:


This is a 'best-of-both-worlds' approach using both relational and dimensional techniques.
The main aim is to have fast and clean loading of data into the corporate datawarehouse and use a second dimensionally modelled layer to report against.
The update rate would be the same for all departments, but you may select different frequencies in loading the 2nd layer. This approach is very scalable , so performance itself should not be an issue with the appropriate hardware.

Ties Blom
 
Hi everyone,

Thanks for the input and ideas. Yes,RiverGuy, Data marts and how you structure them is important and can be of more use then what one expext. Thanks for that.

Thanks Ties, the link has some interesting information in it. I will spend soem time on that.

Regards

[pipe] "We know nothing but, that what we know is not the truth..." - Me
 
this is kind of the situation that my company is in and we're attempting to resolve it throught a data warehousing solution (Teradata, Netezza, Greenplum, etc...). I believe teradata consolidates EVERYTHING into one gigantic data mart. Does anyone know how they accomplish this?
 
k1ng87,
I've not used teradata, but the important thing to remember is that you still have to get your data into the data warehouse. Unless you are using only completely canned systems--and the software provider has some sort of canned interface to the DW, then the logic and the design of how the company proprietary data is modeled and loaded falls back onto the implementer.
 
By the way Teradata doesnt supports dimensional modelling.
 
rajkonig: you can implement either a dimensional or relational model on Teradata, I don't see anything that prevents dimensional modeling on their system

 
Recce:

I would be very careful implementing several DWHs, at least if there is no way of making them consitent and/or sharing data between them. At the previous company I worked for we had two separate DWHs since a merger (8 years ago...) and this resulted in big big problems since the two warehouses were running on incompatible platforms, data could not be combined from the two and in some cases you got incosistent results between them.
 
I think it depends on how large your company is and what they do. I've worked for a few companies who were a thousand different companies within themselves. So each 'department' per say really was it's own little company. This happened because of growth as well as merging and buying other companies. Eventually they wanted to consolidate all the data into some kind of MDM and then an enterprise data warehouse. Nice theory but it was just not realistic to think they'd be able to consolidate down to 2 yet alone 1.

One of the biggest problems was they did multiple things relating to government contracts as well as commercial products. And that data and those systems were supposed to be separate or they'd get into a lot of trouble. So if they did consolidate everything down, they'd still need two different systems for legal reasons.

What I always try to do is look at the big picture. Many companies push the specialized data mart theories because it seems easier to them I guess. Even if they push that theory try to keep the big picture and dig deeper to get to know the data and see if any business processes and data sources are similar in nature. Build the big picture as best you can in the beginning and even if they continue to push specialized isolated data marts, you are still building a real enterprise data warehouse. It's just you are building it one process at a time and in the end it's a lot easier to sell that and build a successful one than to sell them some grand plan that nobody wants to buy.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top