Microsoft Access Database
Architecture: Taking Time into Account and Shadow
Provided by: Luke Chung, President of FMS, Inc.
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.
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
- 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.
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