In most circumstances, calculated values do not need to be stored as to do so would introduce unnecessary redundancy in the stored data. For example, in a purchase order database it would be redundant to store the subtotal of the order line quantity and unit cost, as this can be calculated as necessary from its components.
In some cases additional information is needed (for example, the actual tax rate for an item prevailing at the time of sale, or the rate of any discount applied) which would have to be stored with the other data for that row in the table. This would still not require that the overall subtotal inclusive of tax or discount, say, be stored. There is simply no need as long as the components of the calculation are present and correct.
As Nico said, storing calculated values breaches normalisation rules - the calculated data represents a functional and possibly transitive relationship between two or more fields within the row concerned. The calculated field depends on the nature of the function and any transitive relationship involved; it is not determined entirely by the unique key of the row.
That is, the calculated value is a function of its components f(a, b, ..., n) where a, b, ..., n are the fields which feed into the function concerned. A simple function may involve just one variable (e.g. multiplication by a constant), but in the purchase order example there up to four variables (quantity, unit cost, tax rate, discount rate).
Whilst the value of the components of such a calculation are related to the unique key (as they represent real-life attributes of, say, the purchase order line concerned), the calculated field is dependent not on the key but on the values of the components. It therefore breaks normalisation rules, which require that the value stored be wholly dependent on the unique key for that row (i.e. that the value represents some real-life attribute that we must store in order to have sufficient information to model the item concerned).
Functional and transitive relationships between fields are normalised out as part of the process of database design to reach 3NF or higher forms.
-Stewart
3
