Re: Normalization and Derived Information

From: Laconic2 <laconic2_at_comcast.net>
Date: Tue, 12 Oct 2004 10:30:56 -0400
Message-ID: <UIednTgiwvcvd_bcRVn-jw_at_comcast.com>


"Tony Andrews" <andrewst_at_onetel.com> wrote in message news:1097583889.867434.43460_at_c13g2000cwb.googlegroups.com...

> I never quite "get" the accounting and audit mind-set. In this example
> we have 2 choices:

I'll leave a detailed discussion of auditing to people who have done more accounting than I have.

But let me just comment that the "audit mind set" and the "data normalization mind set" are at least philosophically opposed to each other, if not always strictly contrary.

One of the things an auditor looks for in financial records is internal inconsistency. Auditors do many other tests on the records, but internal consistency is one of them.

One of the things normalization seeks to uncover, and perhaps eliminate, is "harmful redundancy". Not all redundancy is "harmful" in this context, but each normal form (beyond 1NF) shows some harmful redundancy. One of the things that makes certain kinds of redundancy harmful is that the database can contradict itself. It can assert some fact at one place in the database and assert a contrary fact in a different place.

When you have this kind of redundancy, a transaction that looks perfectly innocent to the RDBMS can leave the data in the database in an inconsistent state.

A body of data that stores every fact once, and only once, is an auditor's nightmare. Because if, through error or fraud, somebody manages to store an incorrect fact in the database, and that incorrect fact damages one person and benefits another, there isn't any way (without stepping outside the database) to determine that the fact is incorrect. Received on Tue Oct 12 2004 - 16:30:56 CEST

Original text of this message