Выбор стратегий ограничения целостности

Обеспечение целостности базы данных также осуществляется при помощи стандартных триггеров, встроенных в СУБД. Целостность поддерживается во-первых на уровне контроля уникальности первичных ключей и автоматической генерации значений суррогатных ключей «Номер факта» сущности «Факт» и «Номер правила» сущности «Правило». Во-вторых, обеспечивается целостность базы данных с точки зрения корректности внешних ключей. Это подразумевает с одной стороны контроль того, чтобы значения внешних ключей в дочерней сущности всегда соответствовали некоторым записям в родительской сущности, либо имели значение NULL, если связь разрешает его использование. С другой стороны обеспечивается поддержание целостности при помощи стратегий RESTRICT, CASCADE, SET NULL и NO ACTIONЮ которые определяют набор действий, совершаемых при добавлении, удалении или изменении записей в двух сущностях, связанных через внешний ключ. При использовании стратегии RESTRICT для родительской сущности, удаление или изменение записи, имеющей связанные с ней записи в дочерней сущности, будут заблокированы, т. е. запрос завершится с сообщением об ошибке. Стратегия CASCADE при удалении записей в родительской сущности удаляет также все связанные записи в дочерней сущности, а при обновлении, соответственно, обновляет значения полей. Использование стратегии SET NULL, при удалении записи в родительской сущности обнуляет (устанавливает значение NULL) соответствующее поле в дочерней сущности. Задание NO ACTION отключает использование каких-либо проверок для данной связи. Рассмотрим использование данных стратегий для каждой из связей рассматриваемой базы данных.

Связь между сущностями «Датчик» и «ПоказаниеДатчикаФакт» имеет стратегии RESTRICT на удаление, и CASCADE на обновление. Удаление запрещено, т.к. таблица «Показание датчика — факт» содержит введенные пользователем данные, и удаление их автоматически является недопустимым. В случае если необходимо действительно удалить всю информацию, связанную с датчиком, необходимо сделать это явным образом. В тоже время, обновление идентификатора датчика возможно в связи проведением инвентаризации на предприятии или в связи с исправлением опечатки, допущенной при вводе.

Суррогатный ключ «НомерФакта» в сущности «Факт» генерируется автоматически при добавлении записей в таблицу, поэтому для каждого факта он имеет постоянное значение и не может быть изменен. Поэтому для связей между сущностью «Факт» и сущностями «ПоказаниеДатчикаФакт», «ФактАнтецендента», «ФактКонсеквента», «ПроведенноеМероприятие», «ЗафиксированныйСбой» на обновление имеет стратегию RESTRICT. На удаление записей, данные связи также используют стратегию RESTRICT, поскольку сущности «ФактАнтецендента» и «ФактКонсеквента» содержат информацию о правилах, вводимую пользователем, и ее удаление должно осуществляться только явно. Сущности «ПроведенноеМероприятие» и «ЗафиксированныйСбой» в свою очередь содержат историю функционирования нефтестанции, которая имеет большое значение для технических специалистов и руководства, поэтому ее удаление также должно осуществляться только специальными запросами.

Связи между сущностью «Правило» и сущностями «ФактАнтецендента» и «ФактКонсеквента» по сути связывают составные части правила — атецендент, консеквент и информацию о самом правиле. Поэтому, при удалении записей из таблица «Правило» согласно стратегии CASCADE приводит к удалению соответствующих записей из таблиц «ФактАнтецендента» и «ФактКонсеквента». С другой стороны, значения суррогатного ключа «НомерПродукции» генерируется автоматически, при добавлении правил в базу данных, и не может измениться. Поэтому на обновление данные связи используют стратегию RESTRICT.

Связи сущности «Пользователь» с сущностями «Правило», «ПроведенноеМероприятие» и «ЗафиксированныйСбой» на обновление имеют стратегию CASCADE, поскольку возможна ситуация, когда пользователь захочет изменить свой логин в системе. На удаление данные связи используют стратегию RESTRICT, поскольку в сущности «Правило» содержится информация введенная пользователем, и ее удаление должно быть только явным, а в сущностях «ПроведенноеМероприятие» и «ЗафиксированныйСбой» содержится история функционирования станции, которая также не должна быть удалена случайно.

Алгоритм работы приложения

В процессе разработки диалога с пользователем, как правило, выделяют ряд состояний системы, в которых она остается неизменной и пользователь может выполнять некоторые действия.

Работа в программе происходит следующим образом. Пользователю предлагается ввести логин и пароль. После регистрации пользователь попадает в одну из подсетей, согласно введенным идентификаторам. Логику диалога с пользователем целесообразно описать с использованием транзитивной сети.

Рисунок 10 — Транзитивная сеть, описывающая логику диалога с пользователем Если произошел ввод идентификатора оператор, то система переходит в режим подсети оператора. Логика диалога оператора с программой отражена на рисунке Здесь доступны переходы на:

Проектирование пользовательского интерфейса

Разрабатываемая программа поддержки принятия решений автоматически запускается после загрузки операционной системы. На панели задач находится иконка, щелкнув по которой можно развернуть окно приложения полностью (рисунок 11).

Рисунок 11 ;