November 26, 2007 at 3:18 pm
Comments posted to this topic are about the item Savvy Managers
November 26, 2007 at 9:18 pm
My former manager was a saavy manager and he wrote all the ETL procedures before he became the manager. He attended the Microsoft BI conference too
but it did not mean he learned anything.
The data came from different sources. He built a database for every source. So the ETL system had at least over 20 databases. After that, there was a staging database to group all the data together to build the dimension tables and then another database to build the real dimension table. Since there was no DBA in the company, so he could do anything he wanted. 😀
November 26, 2007 at 9:53 pm
Steve, don't want to be picky, but as it's the title of your article ... I think the word you're looking for is 'savvy' 🙂
PP
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
November 27, 2007 at 7:37 am
Doh!
That one always gets me. Must be my accent 😉
November 27, 2007 at 10:18 am
Dear Bbo,
Thank you for your recent purchase of {invalid item name}.
As a reminder, we offer an extended warranty for $0.00 per 100 years.
Please cantact me for further information.
Sincerely,
sj
:Whistling:
November 27, 2007 at 10:43 am
That's data quality in Alaska for you!
Must be those cold data entry fingers that keep making mistakes. 😛
November 27, 2007 at 10:50 am
Sopmwtimes I wonder if data qualiuty is overrrated./
If e nd busers wer justa litle mor cargful tghen theere woulnd''t be sucha need for alll the work andepxpense that goes into dataquiality.
Anddd we coudl focus on more oimportant thing.s
November 27, 2007 at 11:10 am
Fingers are plenty warm.
It's the thick seal skin gloves we have to wear that makes it hard to type!
😀
Isn't data validation part of that old saying "garbage in, garbage out"?
Or is that just an Oracle saying...
November 7, 2012 at 7:16 am
I find myself in strong disagreement with the editorial.
Sales people:
A) shouldn't be allowed near a computer without at least 3 armed guards to make sure they don't touch anything :laugh:
B) NEED every error correction mechanism known to man
and
C) Need a dedicated team of error correction specialists to fix all the entry mistakes made by said sales people.
Lacking that (sigh) you must have strong editing controls at the front end to catch at least some of the bone-headed and (frankly) lazy mistakes and deliberate lack of data entry most sales people consider adequate.
Been there, done that, ate the tee-shirt from sheer frustration bordering on genocidal rage... (sales people are a seperate species, right? :hehe:)
Seriously though, the best time to correct any error is when it's made. Spell checking is the least of your problems when the sales force is allowed to enter data (shudder). Even having a DMZ and über-strong error checking won't help all that much because rejecting a record for data errors--even if you can find them (and most data errors aren't correctable since the data is either missing entirely or not verifiable without access to the actual paper records) isn't much less frustrating for the sales force than error messages at the front end.
November 7, 2012 at 7:40 am
When it comes to data quality in large enterprise organizations, what's essential is that the rules be formally documented (before development begins).
For example:
- If Col1 = 'A' then Col2 must be 1, 2, or 3.
- When Col3 is updated, then Col4 must also be updated with Date+Time EST.
The documentation must be continuously revised post-production as the business rules change, be published so that any user who queries the database has access to them, and be endorsed and promoted by mangement.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 7, 2012 at 7:44 am
roger.plowman (11/7/2012)
I find myself in strong disagreement with the editorial.Sales people:
A) shouldn't be allowed near a computer without at least 3 armed guards to make sure they don't touch anything :laugh:
B) NEED every error correction mechanism known to man
and
C) Need a dedicated team of error correction specialists to fix all the entry mistakes made by said sales people.
Lacking that (sigh) you must have strong editing controls at the front end to catch at least some of the bone-headed and (frankly) lazy mistakes and deliberate lack of data entry most sales people consider adequate.
Been there, done that, ate the tee-shirt from sheer frustration bordering on genocidal rage... (sales people are a seperate species, right? :hehe:)
Seriously though, the best time to correct any error is when it's made. Spell checking is the least of your problems when the sales force is allowed to enter data (shudder). Even having a DMZ and über-strong error checking won't help all that much because rejecting a record for data errors--even if you can find them (and most data errors aren't correctable since the data is either missing entirely or not verifiable without access to the actual paper records) isn't much less frustrating for the sales force than error messages at the front end.
Absolutely agree Roger. Sales people are sales people for a reason.:-D
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
November 7, 2012 at 8:03 am
Eric M Russell (11/7/2012)
When it comes to data quality in large enterprise organizations, what's essential is that the rules be formally documented (before development begins).For example:
- If Col1 = 'A' then Col2 must be 1, 2, or 3.
- When Col3 is updated, then Col4 must also be updated with Date+Time EST.
The documentation must be continuously revised post-production as the business rules change, be published so that any user who queries the database has access to them, and be endorsed and promoted by mangement.
Here is how data typically flows within a large enterprise organization. Even if data quality is enforced at one layer, it can get mangled, mis-interpreted, misplaced, etc. as it moves into the next layer. The weakest link in the chain are those users running ad-hoc queries who are far removed from inside knowledge about the true meaning of the data.
- Data injested from client or other 3rd party sources into OLTP / application database.
- Data extracted from application database into operational data store / warehouse.
- Data extracted from ODS into 3rd party or proprietary reporting datamart (PeopleSoft, Infomatics, OLAP, etc.).
- Data extracted from datamart into MS Excel, SSRS, dashboard, ad-hoc queries, etc.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 7, 2012 at 9:56 am
Working in Environmental areas you become aware of water, but the basics still apply. If you pollute a stream of water at the source every inch of the water down stream could suffer from the pollution at the source. To fix the problem say 15 miles downstream is to allow for 15 miles of stream to remain polluted. If you really want to solve the problem you solve it for all the miles of the stream not just for some of the stream. Are data streams that much different? Fix it at the source, fix it early, and fix it right, then at all points along the way, everything is great.
Sales people sell product, they are not producers of product. We hire them to sell not to be computer or database experts. We need their feedback and assistance defining the market, be we do not need them to architect or code systems. Do they take the high tech coders out to sell product? They cringe at the idea. So why do they feel they can do all things IT? Odd bunch of ducks those sales folks. 🙂
Not all gray hairs are Dinosaurs!
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply