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 SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Start doing datawarehousing 3
- Thread starter Jui
- Start date
Hi,
My opinion.
When the company has lot of data in the OLTP system and the Mgmt is asking lot of quiestions from that system and that resulting in a unsatisfied business user.
Quick Decision making is critical for the business to survive. There are lot of competetors for the business.
Last but not the least. The company has lot of money to invest in the project.
My opinion.
When the company has lot of data in the OLTP system and the Mgmt is asking lot of quiestions from that system and that resulting in a unsatisfied business user.
Quick Decision making is critical for the business to survive. There are lot of competetors for the business.
Last but not the least. The company has lot of money to invest in the project.
-
1
- #3
Data Warehousing technology covers a wide range of products, tools and techniques.
Probably more important than any of them though is to have a good understanding of why you're considering it, and what information is highest priority. As anand4all implies, unless your organisation has a lot of money, and more importantly time to be thorough, a traditional large-scale data warehouse containing many instances of data extracted from your OLTP systems is overkill, certainly as an initial goal.
A better approach, especially if your organisation hasn't used much in the way of Management Information tools previously, is probably to start with one or two priority areas (either business critical information, or areas where reporting load is interfering with OLTP operations), study these information requirements carefully, and extract the appropriate data from your OLTP systems out into targeted data marts. The tool selection for the reporting/analysis of this data should involve the end-users as much as possible, but bear in mind that once users actually start using it for real, this will affect their understanding of their own requirements considerably; try not to lock any future strategy into a particular tool-set's capabilities.
If you do start off with the data-mart route, try to ensure that where dimensions are shared between one business area and another (and hence one mart and another), e.g. time, or product hierarchies, that their implementation is compatible; this will mean that if there is a future need to merge this information (either in a larger data warehouse, or simply in a report needing information from >1 mart), it is as simple as possible. In jargon terms this could be described as having conforming dimensions across federated data marts
I hope the above rambling is of some use to you Jui.
Good luck, and happy warehousing
Probably more important than any of them though is to have a good understanding of why you're considering it, and what information is highest priority. As anand4all implies, unless your organisation has a lot of money, and more importantly time to be thorough, a traditional large-scale data warehouse containing many instances of data extracted from your OLTP systems is overkill, certainly as an initial goal.
A better approach, especially if your organisation hasn't used much in the way of Management Information tools previously, is probably to start with one or two priority areas (either business critical information, or areas where reporting load is interfering with OLTP operations), study these information requirements carefully, and extract the appropriate data from your OLTP systems out into targeted data marts. The tool selection for the reporting/analysis of this data should involve the end-users as much as possible, but bear in mind that once users actually start using it for real, this will affect their understanding of their own requirements considerably; try not to lock any future strategy into a particular tool-set's capabilities.
If you do start off with the data-mart route, try to ensure that where dimensions are shared between one business area and another (and hence one mart and another), e.g. time, or product hierarchies, that their implementation is compatible; this will mean that if there is a future need to merge this information (either in a larger data warehouse, or simply in a report needing information from >1 mart), it is as simple as possible. In jargon terms this could be described as having conforming dimensions across federated data marts
I hope the above rambling is of some use to you Jui.
Good luck, and happy warehousing
- Thread starter
- #4
Thank you Yaffle
. Does anyone think that a Database administrator would capable to manage datawarehousing?
I know that Data Warehousing is in a larger scale compared to basic database. Therefore a database administrator should have some basic knowledge to do data warehousing.
I know that Data Warehousing is in a larger scale compared to basic database. Therefore a database administrator should have some basic knowledge to do data warehousing.
- Thread starter
- #5
Thank you Yaffle . Does anyone think that a Database administrator would capable to manage datawarehousing?
I know that Data Warehousing is in a larger scale compared to basic database. Therefore a database administrator should have some basic knowledge to do data warehousing.
. Does anyone think that a Database administrator would capable to manage datawarehousing?I know that Data Warehousing is in a larger scale compared to basic database. Therefore a database administrator should have some basic knowledge to do data warehousing.
-
1
- #6
OLAPer
MIS
"To do Data Warehousing" !?
Well, the skills for physically creating the schema is one thing, the skills required to design and develop a schema that meets the business requirements is another.
There is also the consideration of whether or not there is a requirement for Multi-dimensional database structures, namely cubes. If there is, then this is another skill that your DBA would need to develop.
There are a number of courses available that your DBA might need to attend. If you choose to develop a small scale Data Mart in MS SQL Server for example, then there are Microsoft courses specifically targetted at creating DW solutions.
I think there is a large learning exercise needed in determing how your company wants to go forward. At this point is there a need for a dedicated DW "person", or can the DBA gain enough skills to at least start a small project, and potentially become that "dedicated DW person".
There is also the time consideration, how quickly does your company want to move on these type of projects? Is there enough slack in the timeline to allow for the learning curve for the DBA?
Lots of questions, lots of answers.......a balancing act really........
Regards
OLAPer
:
Well, the skills for physically creating the schema is one thing, the skills required to design and develop a schema that meets the business requirements is another.
There is also the consideration of whether or not there is a requirement for Multi-dimensional database structures, namely cubes. If there is, then this is another skill that your DBA would need to develop.
There are a number of courses available that your DBA might need to attend. If you choose to develop a small scale Data Mart in MS SQL Server for example, then there are Microsoft courses specifically targetted at creating DW solutions.
I think there is a large learning exercise needed in determing how your company wants to go forward. At this point is there a need for a dedicated DW "person", or can the DBA gain enough skills to at least start a small project, and potentially become that "dedicated DW person".
There is also the time consideration, how quickly does your company want to move on these type of projects? Is there enough slack in the timeline to allow for the learning curve for the DBA?
Lots of questions, lots of answers.......a balancing act really........
Regards
OLAPer
:
-
1
- #7
ponderworks
IS-IT--Management
Hi,
I agree with OLAPer and Jui. In addition, you will need someone (maybe a DBA) who is an expert (or can be) on optimizing the database for query. This would include index management, optimization strategies, special DB releases, db activity monitoring, etc. Depending on the type of decision support work (DSS) you are doing, you may want to consider a surveillance tool. There are many at various price levels (like BMC Patrol, HP Measureware, etc.)
By the way, you can start small. Building a star-schema and some indexes and testing the performance need not be a "big" operation. There is always some experimentation with this type of work. Some great books are available as well.
I agree with OLAPer and Jui. In addition, you will need someone (maybe a DBA) who is an expert (or can be) on optimizing the database for query. This would include index management, optimization strategies, special DB releases, db activity monitoring, etc. Depending on the type of decision support work (DSS) you are doing, you may want to consider a surveillance tool. There are many at various price levels (like BMC Patrol, HP Measureware, etc.)
By the way, you can start small. Building a star-schema and some indexes and testing the performance need not be a "big" operation. There is always some experimentation with this type of work. Some great books are available as well.
ponderworks
IS-IT--Management
Hi,
I agree with OLAPer and Jui. In addition, you will need someone (maybe a DBA) who is an expert (or can be) on optimizing the database for query. This would include index management, optimization strategies, special DB releases, db activity monitoring, etc. Depending on the type of decision support work (DSS) you are doing, you may want to consider a surveillance tool. There are many at various price levels (like BMC Patrol, HP Measureware, etc.)
By the way, you can start small. Building a star-schema and some indexes and testing the performance need not be a "big" operation. There is always some experimentation with this type of work. Some great books are available as well.
I agree with OLAPer and Jui. In addition, you will need someone (maybe a DBA) who is an expert (or can be) on optimizing the database for query. This would include index management, optimization strategies, special DB releases, db activity monitoring, etc. Depending on the type of decision support work (DSS) you are doing, you may want to consider a surveillance tool. There are many at various price levels (like BMC Patrol, HP Measureware, etc.)
By the way, you can start small. Building a star-schema and some indexes and testing the performance need not be a "big" operation. There is always some experimentation with this type of work. Some great books are available as well.
- Status
Similar threads
- Locked
- Question