Microsoft Access Database Architecture: Taking into Account Time

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.

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.

One way to address this would be 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 would be 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.