March 12, 2007 at 10:38 am
Comments posted here are about the content posted at http://www.sqlservercentral.com/columnists/rgardner/2913.asp
March 20, 2007 at 7:00 am
I disagree that you can't reach 100% accuracy of the known data. If the bottom line of the data warehouse doesn't match the inputing systems, then the data warehouse creator needs to be able to explain why. Every possible permutation can't be checked, but a good sampling can be, and should be.
We had a consultant who built us a warehouse and said that the data shouldn't be expected to match completely. After some investigation, however, it was discovered that he had violated the "level of granularity" rule which is crucial. In this case the data didn't match because of a flaw in the data warehouse.
Data warehouse designers should consider stored procedure groups to self-document the steps. They can only be created and edited in the analyzer (at least in 2K and earlier) but hopefully if someone is building a dw using the analyzer is not a big issue.
March 20, 2007 at 12:04 pm
This article hit the nail on its head. Data quality was the number one problem when we were building our data warehouse. I agree that your data warehouse can reach 100% accuracy of the known data (assume you meant user entries). But if the known data is not accurate, your reports are still off.
March 20, 2007 at 2:55 pm
I did wrote an article about data quality before I wrote the article Problems with data warehouse. But you are right, data quality is number one problem in building data warehouse. Nice Article.
http://www.sqlservercentral.com/columnists/jchan/2593.asp
Janet
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply