Hi Erik,

Hmmm...No, it is denormalized data. Both entities have an attribute called "rate". If we maintained date dependent rate history in the billing rates table, then we could still maintain a key relationship. But we do not, so we have to store the same piece of information (not necessarily the same data), duplicated (in some cases) in two tables.


>>However, rates may change but these changes should not be reflected in callhist. How would you like it if rate changes affected calls you made a year ago? In this case, a denormalized relationship is needed.
>>
>
>
>I could be way off base here, but I don't consider this denormalization at all. Denormalization is when the same piece of information is stored in two places. IN the example you showed, the effective rate for the call, and the current rate are not the same piece of information, but two distinctly different concepts. If the values can vary independently, you have not denormalized, you have only created as many fields as you need to accurately reflect the state of things.