Jeff Moden wrote:
What I've found is that "Data" is always correct. "Information" derived from the data is not. And even if the "Data" is skewed, it is still correct but incomplete.
I love one of my Grandmother's old sayings... "Figures can be made to lie... and liars figure".
Jeff, I have to disagree. I've had experiences that convince me otherwise. About a year ago my single credit card account was somehow compromised in a central Indiana city on a day I was travelling across Nebraska, which was evident by other charges made at various geographical points. Essentially, the 'data' indicated I was in two states at the same time, thus obviously invalid. The compromised data consisted of nearly $1500.00 of charges over about three days before the card company fortunately detected the problem. handled it, and made good on every cent of the fraud.
That underlying 'data' was presented as 'information' on my statement. In this situation the 'information' was technically correct in it's content, while the underlying 'data' was not valid. While it correctly recorded a transaction, the content of the transaction was not accurate.
Our version of the saying was "Figures don't lie but liars figure". Unfortunately, that is not always the whole picture.
Seems to me that the real world is that:
Data may or may not be valid. Information based on invalid data can NEVER be valid.
In the case of your credit card, it actually proves my point. The "data" was not only absolutely correct, but fairly well obvious. It said that your credit card was used in India and the rest of the data said that's not normal. The person using your credit card was a liar. The people with the data did actually interpret it correctly and so saved you a problem.
To be sure, though, when humans get involved with interpretation of "BI", it easily becomes a train wreck. I worked for a large DOD company way back when PCs were a new thing. I interfaced some very large mainframe data with the PCs on demand to be able to produce some rather important reports that were due each month. It's wasn't my job to analyze the data but you can't help but do so when you have to analyze the data for correctness.
I noticed some things in the data and ended up making a summary of the whole business plan... it basically said that it was a "going out of business" plan and that we'd have to lay off about half the people in two years and some number of months. To make a really long story much shorter, I took my findings up the chain of command all the way to the GM and was told, every step of the way, that "it wasn't your concern" and "you don't have a degree" and "you're not an accountant".
On the month I predicted and in spite of all the "company-wide town halls" where they told us how good things were going, they had to lay off half the people in the very month I predicted.
Some people actually died because of it. Either they could no longer afford their own medication or someone that lived with them couldn't. It was totally preventable but liars were figuring just to make themselves look good.
I've seen it in a lot of other places, as well, and it has driven me to the point where I've deemed "BI" to be mostly an oxymoron. As with your credit card problem, there are exceptions.
is pronounced "ree-bar
" and is a "Modenism
" for R
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
"Change is inevitable... change for the better is not".
"Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)