Re: OT: Validation of end-user reports

From: Ryan January <>
Date: Wed, 19 Feb 2014 13:54:08 -0600
Message-ID: <>

I read Maris' question as one geared toward what context you're using when referring to "data".

If this is BI data, I feel it's out of my realm to enforce data integrity for all user reports. If I have reason to suspect a user is providing incorrect reports, or see something written less than optimally, I'll bring it up to someone within that business unit on a case by case basis.
To ensure integrity implies you completely understand their business requirements and have the time to review each report yourself. If this process is performed on all reports you become a serialization point for report development and get little else done.

When a user has the ability to provide actionable reports I assume the business trusts the user's level of competency. This person should understand the data well enough to write the report and also provide proof to why it's correct or defend it in a peer review process. This holds true regardless of business unit.
Data integrity is the result of a methodology which starts with proper training and ends with independent review. Too often users are turned loose on data they don't truly understand or the business doesn't provide the requirement for process review. Avoiding this situation may be why you're asking the question.
In past lives I've helped steer the business toward a process built around the collective user group "blessing" the results prior to deployment. If the results are found inaccurate this is a learning opportunity for the user.
The important thing to stress here is that it has to be driven and supported by the business. Without their buy in any process is doomed to fail. My biggest task in that process has been driving home the dangers of incorrect data and facilitate the discussion.

The other way to read your question would be data concerning performance trends or profiles. I'll occasionally have a developer or business unit reach out to the DBA team with an incorrect analysis of their performance problem based on invalid assumptions. In those situations all we can do is provide a simplified view of their processes performance issues, note where we're seeing the actual problem, and provide data on how/why we determined it to be the true bottleneck. I find these issues generally sort themselves out as the user learns to create better reports through a number of performance analysis iterations or involves the DBA team earlier in the process.


On 02/19/2014 10:31 AM, Jeffrey Beckstrom wrote:
> I am referring to the validity of the data being reported. In a
> report developed by IT, results are checked for accuracy. For an
> end-user developed report, what are some ways to force the user to
> verify the information they are getting is accurate. We do not want
> decisions being made from bad reporting.
> >>> Maris Elsins <> 2/19/14 10:41 AM >>>
> Hi Jeffrey,
> What do you mean with "the integrity of the user's reports"?
> If you're referencing to performance impact (to make sure users don't
> kill the system by running huge reports that never complete) We have
> partially addressed this by implementing the resource manager plan to
> limit the number of total active sessions for users connection, the
> degree of parallelism and max amount of CPU % they can utilize. And I
> say "partially" because we're not able to control how much IO they
> cause. no Exadata here ;(
> ---
> Maris Elsins
> _at_MarisElsins <>
> <>
> On Wed, Feb 19, 2014 at 3:54 PM, Jeffrey Beckstrom
> < <>> wrote:
> For those of you that allow your users to create their own
> reports, what procedure is followed to validate the integrity of
> the user's reports?
> Jeffrey Beckstrom
> Database Administrator
> Information Systems
> Greater Cleveland Regional Transit Authority
> 1240 W. 6th Street
> Cleveland, Ohio 44113
> .
> .


This email is intended solely for the use of the addressee and may
contain information that is confidential, proprietary, or both.
If you receive this email in error please immediately notify the
sender and delete the email..

Received on Wed Feb 19 2014 - 20:54:08 CET

Original text of this message