Проверка модели на выполнение транзакций пользователя (фаза4).

Целью этой фазы является проверка того, что данная ЛЛМД позволяет выполнить все транзакции, необходимые пользователям.

Перечень транзакций определяется теми действиями, которые выполняют те или иные пользователи. Если использовать построенные ER-Диаграммы, а так же установленные связи между первичными и внешними ключами, указанными в описании отношений, то можно попытаться вручную выполнить все необходимые операции для данной транзакции. Если т.о. удается найти способ выполнения всех требований транзакций, то проверка ЛЛМД будет завершена. Если какую-либо транзакцию выполнить вручную не удается, то ЛЛМД является неадекватной, т.е. содержит ошибки, которые необходимо устранить.

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

Рис. 3.4.2.2.5.

Первичным ключом является номер преподавателя(НП). Прежде всего работник кадрового управления должен убедиться, что номер преподавателя является уникальным. Если это не так, то ввод данных запрещается и выполнение операции транзакции завершается. Иначе ввод данных о новом сотруднике разрешается, но далее проверяется, чтобы для каждого элемента сведений о новом сотруднике имелись бы соответствующие атрибуты в отношении. Если это так, то проверка имеет положительный результат. Если нет, то необходимо изменение либо ЛЛМД, либо операции транзакций.

Определение требований поддержки целостности данных

(фаза 5).

Цель этой фазы – формирование ограничений, налагаемых для данной ЛЛМД исходя из требований пользователей, а так же исходя из необходимости обеспечения целостности(правильности, корректности) данных.

Ограничения целостности данных представляет собой такие ограничения, которые вводятся в данную АИС для предотвращения появления противоречивых(явно неправильных) данных.

К ним относятся следующие типы:

1. обязательность данных

2. ограничение для доменов атрибутов

3. целостность сущности и т.д.

1. Обязанность данных – некоторые атрибуты всегда должны содержать одно из допустимых значений, т.е. этот атрибут не может иметь пустого значения. Так, например, каждый сотрудник университета в БД должен иметь конкретное значение атрибута «должность».

Эти ограничения должны фиксироваться при занесении сведений об атрибуте в БД. Если же по данному сотруднику этот атрибут пуст, то система должна фиксировать ошибку и извещать об этом пользователя.

2. Ограничение для доменов атрибутов. Для такого рода атрибутов значение его представлены в домене и этот набор значений ограничен. Например, атрибут «пол сотрудника» может содержать только 2 допустимых значения «мужской» или «женский» этого атрибута. Если же значение атрибута либо пустое, либо какое-либо другое, то система должна фиксировать ошибку и сообщать об этом персоналу.

3. Целостность сущности – первичный ключ любого отношения (сущности) должен быть: во-первых, уникальным, а во-вторых не может иметь «пустого» значения. Например, каждая строка отношения «сотрудник» должна содержать уникальное значение первичного ключа – табельный номер сотрудника. Если же ошибочно будет введен табельный номер, совпадающий с уже существующим, то система должна фиксировать ошибку и сообщать об этом персоналу.

 

Создание и проверка ГЛМД.

Цель этого подэтапа – объединение ЛЛМД в единую ГЛМД, представляющую собой либо всю предметную область, либо ту часть ПО, которая охватывается данным приложением.

Этот подэтап имеет следующие фазы:

1. слияние ЛЛМД в ГЛМД(ф.1)

2. проверка ГЛМД (ф.2)

3. создание окончательного варианта диаграммы «Сущность-Связь»(фаза 3).

Рассмотрим коротко эти фазы.