modifying data in thdw
2 posters
Page 1 of 1
modifying data in thdw
hi,
we built a dw for our marketing department and sometimes users go in and make changes to the dw from the back end. since we do incremental load of the dw, these changes are not over-written. how do we convince our business users that this a terrible method and that they should make changes in the data source?
we built a dw for our marketing department and sometimes users go in and make changes to the dw from the back end. since we do incremental load of the dw, these changes are not over-written. how do we convince our business users that this a terrible method and that they should make changes in the data source?
SnowShine429- Posts : 36
Join date : 2013-02-16
Re: modifying data in thdw
Well, chances are you probably need to find some middle ground.
First off, no user should have the ability to perform updates to the data at the database level (i.e. SQL UPDATE). All updates should be handled through an application and applied to the DW through established load processes. This gives you the ability to audit and control such activity.
In marketing it is not uncommon to have 3rd party or in-house data sources that are not covered by the enterprise systems. Sometimes its just stuff somebody has on a spreadsheet. So, you need to do some analysis. If the data is maintained on an enterprise system, find out why they are taking short cuts and develop solutions. One thing a data warehouse tends to expose are shortcomings in current processes. For external and spreadsheet type data, you need to put practices in place where the data is landed into a staging area then applied to the DW through a load process.
It really boils down to establishing a data governance process and empowering those on the business side to take ownership of the data and its quality. It's your job to see to it that processes and applications are in place to accommodate what they need to do.
First off, no user should have the ability to perform updates to the data at the database level (i.e. SQL UPDATE). All updates should be handled through an application and applied to the DW through established load processes. This gives you the ability to audit and control such activity.
In marketing it is not uncommon to have 3rd party or in-house data sources that are not covered by the enterprise systems. Sometimes its just stuff somebody has on a spreadsheet. So, you need to do some analysis. If the data is maintained on an enterprise system, find out why they are taking short cuts and develop solutions. One thing a data warehouse tends to expose are shortcomings in current processes. For external and spreadsheet type data, you need to put practices in place where the data is landed into a staging area then applied to the DW through a load process.
It really boils down to establishing a data governance process and empowering those on the business side to take ownership of the data and its quality. It's your job to see to it that processes and applications are in place to accommodate what they need to do.
Similar topics
» Looking for a Data Architect/Data Modeler for NYC Big Data Startup
» clickstream fact data coming in with different levels of dimensional geography data
» difference between data mart and data warehouse at logical/physical level
» Is it a best practice that Data warehouse follows the source system data type?
» Reporting table data repository vs. Dimensional data store
» clickstream fact data coming in with different levels of dimensional geography data
» difference between data mart and data warehouse at logical/physical level
» Is it a best practice that Data warehouse follows the source system data type?
» Reporting table data repository vs. Dimensional data store
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum
|
|