When designing an application and its tables, it's very important to capture the time dimension and determine how data should be stored with the expectation that it will change over time. While there's a natural tendency to keep data normalized so that the same information is stored in only one place, the time dimension also needs to be considered.

What Needs to be Preserved Over Time?

A common example is the use of a Customer table where a Customer ID field identifies the record, which contains the person's name, address, etc. An invoice table could include a Customer ID that identifies the customer. While this approach works if the address changes; the Customer record is updated and all his/her invoices reflect the new address; a problem arises if there's a need to go back and find out where a previous shipment was sent. If a backup of the original customer record or the original customer data is not maintained with the original invoice, that information is lost.

While some information may not be worth keeping, old phone numbers for example, other pieces could be critical. For instance, a list of products and prices can be used for new sales, but a copy of the data needs to be kept in the invoice's line items so that a change in the prices does not cause old invoices to change. Thinking about what is important and is not is a crucial part of the design process, and very difficult to fix later.

Making Sure Data Normalization Doesn't Lose Historical Data

One way to address this is to make a copy of the original customer record in the invoice table. This essentially takes a snapshot of the data and preserves it, making it easy to access the old invoice and see exactly what data was used at the time of creation or shipment.

Another approach is to presume the data does not change that often and when you reprint the invoice you want to show the new address, not the old one. If that's the case, this could be solved by simply keeping a shadow Customer table, so that any changes to the customer record (or relevant fields) are documented along with the time and user who did it. If historic information is required, it would be a simple search in the table to find it.

Shadow Tables

A shadow table is essentially the same as the original table with some small differences:

It has a it's own primary key field (AutoNumber). This allows it to store multiple versions of the same record ID from your master table without creating a unique primary key violation.
All secondary indexes that require uniqueness need to have that constraint removed
Any extra fields you may want to add to track the activity (e.g. the action performed, who and when it occurred).
Eliminate any field validation requirements, null prevention, etc. that would prevent a new record from being saved in this table. We want to save all changes here. We don't care about validation in this table. That's something that needs to be handled where the user makes their edits

One can then create a simple parameterized query that takes all the fields from the master table and inserts it into the shadow table for a particular record (e.g. InvoiceID).

Then, but adding VBA code to form's AfterUpdate event, the query can be invoked with the current record's ID to copy the record to the shadow table.

In SQL Server, a trigger can be created for each table to automatically store a copy in another table. This is more robust since any time the data is modified, this audit record is created. In Access using Jet tables, this is less robust since people may be able to edit the records without going through your data entry form.

Additional Resources

Contact Us l Web questions: Webmaster l Copyright © FMS, Inc., Vienna, Virginia
Celebrating our 26th Year of Software Excellence