Михаил БорПочему этим никто не воспользуется?Поэтому:
авторА как различать было сделано исправление ошибки оператора или произошло изменение данных?

--
Dik76
Запись <с 15го числа для Id=14 название ="баксы" >
также может редактироваться, - ой т.е. "мегабаксы" .

В свое время Snodgrass один из организаторов центра темпоральных БД ввел для темпоральных данных поняти двух осей времени - назовем их предметной и административной. Предметная отражает события внешнего мира, а административная отвечает на вопрос кто и когда сказал мяу.
Предметную ось естественно отрабатывать в приложении.
Например в документе ссылка на валюту Id=14. В одних отчетах требуется показывать наименование валюты на дату документа, в других на дату изменения статуса документа, в третьих на дату начала периода отчета и т.д. Поэтому в документе не делают еще одно поле дата валюты, а используют одну из уже имеющихся дат для динамической связи запросами с историей наименований валюты.
Административную можно логами, или полями в справочниках, в простейшем случае
<с 15го числа для Id=14 название ="баксы", последним правил USER 25числа >
Очень важно понять, с какой осью вы в том или ином случае имеете дело.

guest_20040621> А как различать было сделано исправление ошибки оператора или произошло
> изменение данных?

Легко.Спросить quot guest_20040621 :) guest_20040621

> В свое время Snodgrass ввел для темпоральных данных поняти двух осей
> времени - назовем их предметной и административной.

А почему две? Осей может быть столько, сколько используется внешних источников. Например, те же валюты. Ввели евро. Изменения в официальном классификаторе валют (логично пользоваться им, поскольку это официальный легко доступный документ) появились позже инструкции ЦБ, которая, в свою очередь, появилась позже документов ЕвроЦБ (или как там он называется?). Вопрос: какую дату в каких случаях считать датой начала обращения евро? Фишка в том, чтобы при регистрации данных или регистрации изменений однозначно идентифицировать источник данных. Это серьезная проблема. Накручивать можно много, в результате поля типа Дата могут составлять 90% полей. На упомянутом сайте полно статей по теме.

Ваш пример интересен, можно пофантазировать:
СправочникВалют(
Код,
ДатаАктуальностиДанных,
Наименование,
ДатаНачалаОбращения,
Основание,
ДатаОбновления,
КтоОбновил
)
UNIQUE (Код, ДатаАктуальностиДанных)

<приказом ... вступившим в силу с. 01-01. установлено, что обращение разрешено с 15-02.>
А затем <письмом ... , вступившим в силу с. 01-05. установлено, что обращение разрешено с 10-02.>
Товарищей, привлеченных к ответственности за нарушение приказа в период с 10-02 по 15-02 отпустить, но милиционеров, их арестовавших не наказывать.

Несомненно, обе даты нам нужны в прикладном смысле и находятся на прикладной оси.

Сорри, читать

Товарищей, привлеченных в период с 01-01по 01-05 к ответственности за нарушение приказа в период с 10-02 по 15-02 отпустить, но милиционеров, их арестовавших не наказывать.

guest_20040621> Несомненно, обе даты нам нужны в прикладном смысле и находятся на
> прикладной оси.

Конечно. Но в одном случае (ВЭД) дата создания будет одной, в другом (наличные) - другой, в третьем (банковские счета; если помните, их можно было открывать, когда наличного евро еще не было) - третьей. Сущность - одна (валюта), а вот регистрировать ее обращение для разных предметных областей придется по разному. Так что одной оси - маловато. И фиксированного количества дат - тоже. ;)Возможно я чего-то не понимаю в валютных делах, но эти даты - разные показатели (то ли атрибуты сущности Валюта, то ли экземпляры сущности СобытиеВалюты - разворачивать их по горизонтали или вертикали -отдельный вопрос). ДатаВЭД ведь не отменяет ДатуНаличных? Аналогично для документа дата регистрации не отменяет дату составления.
Вот если однажды ДатаВЭД для Евро меняется, то это темпоральные данные. Находясь на данной точке темпоральной оси система должна выдать единственное значение любого показателя. Все предшествующие отменены.