Всем, доброго времени суток!

Прошу помощи в решении на первый взгляд простой задачи:
На предприятии имеется некоторое количество единиц оборудования. Каждая единица оборудования находится в каком-либо состоянии («в работе», «в ремонте», «в резерве» и т.п.) и соответственно в некоторые моменты времени оно может переходить из одного состояния в другое. Смена состояний осуществляется по принципу «из любого в любое другое отличное от текущего» (т.е. «из ремонта в работу» и «из ремонта в резерв» – допустимо, «из ремонта в ремонт» – запрещено). Собственно в проектируемой БД требуется вести учёт работы оборудования фиксируя моменты перехода оборудования из одного состояния в другое. Далее по этой информации требуется получать отчёты по наработке оборудования, т.е. сколько часов данная единица оборудования находилась «в работе», «в ремонте» и т.п. Наработку требуется получать либо за конкретный период (например, за месяц), либо суммарно на конкретную дату (например, сколько данное оборудование провело времени в ремонте за всю «свою жизнь»).
В результате моих размышлений над этой задачкой родилась такая предварительная схема БД (реализовано на FireBird 1.5).

Описание таблиц:
1) «DEVICE» – справочник оборудования. Предполагается порядка 300-500 записей.
2) «DEVICESTATE» – справочник состояний оборудования. Около 10 записей.
3) «DEVICE2DEVICESTATE» – табличка для организации связи M:N оборудования и его состояний. Наверное, получиться около 2000 записей.
4) «DEPART» – справочник подразделений. Вспомогательная табличка. Около 10 записей.
5) «WORKEVENT» – таблица «событий». В неё операторами заноситься информация о смене состояний оборудования. Ожидается порядка 500 записей в месяц.
6) «WORKTIME» – таблица «приращений». В эту таблицу заносятся приращения наработок. Т.е. при регистрации смены состояния оборудования сюда заноситься длительность пребывания единицы оборудования в предыдущем состоянии (например, произошла смена состояния «работа->ремонт», в таблицу записалась длительность пребывания оборудования в состоянии «работа»). Количество записей равно количеству событий.
7) «WORKTIMEACC» – таблица «накопления». В неё будут заноситься итоговые наработки оборудования на определённые даты (скорее всего на начало каждого месяца). Кроме того, в эту же таблицу будут введены начальные наработки (многие единицы оборудования эксплуатируются с 60-х годов и «исторические данных» по сменам их состояний просто нет). Число записей равно 12*кол-во единиц оборудования.

Всё бы ничего, но что-то очень смущает меня взаимосвязь между таблицами «WORKEVENT» и «WORKTIME». Суть проблемы можно увидеть на простом примере.
Допустим, для некой единицы оборудования оператор последовательно вводит информацию о следующих событиях:
A) в момент времени Т1 произошла смена состояния «резерв->работа»
B) в момент времени Т2 произошла смена состояния «работа->резерв»
Соответственно в таблицу «приращений» для события B заносится длительность пребывания оборудования в состоянии «работа» (Т2-Т1). Теперь если вдруг потребуется (от человеческого фактора никуда не денешься) вклинить между событиями A и B ещё одно или несколько событий начинаются неприятности. Во-первых, длительность пребывания оборудования в состоянии «работа» нужно пересчитать (это в принципе решаемо). Во-вторых, вклинившееся событие может нарушить логическую последовательность следования событий (может получиться два идущих подряд события «работа->резерв»).
Мне приходят в голову два варианта решения этой проблемы:
1) Ввести в таблицу «WORKEVENT» дополнительное поле для указания статуса события («актуально/неактуально»). И в случае вклиниваний выставлять соответствующему событию статус неактуальности и настойчиво предлагать пользователю поправить ситуацию. Вроде приемлемый вариант.
2) В принципе можно избавиться от таблицы «приращений» и рассчитывать длительности по таблице «событий» непосредственно в момент формирования отчётов. И в случае нарушений логической последовательности выдавать предупреждения либо отказываться формировать отчёт. Этот вариант мне совсем не нравиться.

Возможно кто-то сможет предложить другие более приемлемые варианты?
Может быть можно как-то модифицировать структуру БД?
В общем, приветствуется любая конструктивная критика.

ModelRDEVICE2DEVICESTATE - ограничитель сочетаний оборудования и состояний?
тогда логично все пары (DEVICEID,DEVICESTATEID) в разных таблицах связать внешним ключом с ограничителем."Оборудование" и "Состояния" состоят в отношениях много-ко-многим. Т.е., например у оборудования "насос" допустимые состояния "в работе", "в горячем резерве", в "холодном резерве" и "в ремонте", а у оборудования "нагревательный элемент" состояний всего два "в резерве" и "в работе" (типа если сломался, его просто выбросят).

ФЗП1) 500 записей в месяц = 6000 в год. Денормализованную таблицу накопления на таких объёмах не стоит делать. Начальную наработку можно ввести как дополнительное состояние. Я думал о чём-то подобном. Но меня смущает такое смешение двух разных сущностей: состояния и суммарной наработки по этому состоянию.

ФЗП2) Если состояний много, то надо бы сделать матрицу разрешённых переходов из одного состояния в другое.Согласен. Я отложил это на будущее. Пока в постановке задачи разрешены любые переходы кроме как "в тоже самое".

ФЗП3) WORKTIME лишняя, длительность ввести в WORKEVENT, проверять перекрытие времени триггером в момент ввода. Действительно:)
Связь между "WORKTIME" и "WORKEVENT" получается как один-к-одному! Спасибо

ФЗПВместо дополнительного флажка в момент "вклинивания" можно ввести ещё один статус ("ввод данных не завершен"), для которого повторение допустимо."Статус" - это в смысле ещё одно состояние?