Temporality and database access

A key criterion in assesing the quality of a database is the time. Temporal validity, namely, the
inadequancy of the database schema on the changes that occurs later in the system, represent the
nigthmare of every database administrator or application developer.
Ideally, when designing the database schema, is good to know the trend in legislation and the
procedures of the module/system used for developing the an application, so the structure should
be flexible enough for future adoption.

1. Temporal validity of a database schema

The database dedicated for sales, more preciselly : PRODUCTS{Code, Name, UM, VAT,
Type}, INVOICE{Number, CodeClient, Date, Info} and INVOICE_LINES{Number, Line,
CodeProduct, Quantity, Price} is the most used.
The value of every invoice is the follow query:
SELECT SUM(Quantity*Price) AS ValueInvoiceWVAT,
SUM(Quantity*Price*(1*VAT)) AS ValueInvoice FROM INVOICE I
INNER JOIN INVOICE_LINES IL ON I.Number=IL.Number
INNER JOIN PRODUCTS P ON IL.CodeProduct=P.Code WHERE I.Number=1

The VAT, for every line in the invoice, is calculated starting from the VAT column from
PRODUCTS, but this percent indicates the current percent of VAT for a particular product. Lets
assume that a super market opened in 1998 and very well automatized sells and books. The VAT
percent was changed a lot of times during the last years. Then, if in february 2005, ve want to
analize the books sells in the last five years, the values returned by the query are relevant?
Solving this essential problem involves storing the VAT percent from the moment of introducing
the invoice in the database. The first solution is showed in the figure 1.1

Figura 1.1

Based on the figure the database schema is:

PRODUCTS{CodeProduct, Name, MU, Type}
VAT_PRODUCTS{CodeProduct, StoringDate, FinishDate, VAT} and INVOICE and
INVOICE_LINES are the same. Some problems with the speed appear when we save the
temporal validity, because is hard to calculate the value of a invoice.
On the other way, the insert/update/delete triggers need to search in the VAT_PRODUCT table
to found out the correct percent to update the calculated columns ValueInvoice and VATInvoice.