Модификация данных

Моделирование обработки данных сопряжено с действиями СУБД по внесению информации в базу данных в форме операций добавления, изменения или удаления данных. При этом любой запрос но модификации данных всегда соответствует некоторой функциональной операции пользователя информационной системы.

Пример

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

Рассматриваемый пример содержит в своей формулировке несколько операций, которые должны быть выполнены в комплексе. При этом формулировка содержит указание на выполнение операции корректировки хранилища данных^[1] об общем количестве товаров на складе (рис. 5.66). Эта операция может быть выполнена в виде триггерного действия, что также найдет отражение в процессе моделирования. ^{* V}

Рис. 5.66. Описание структуры исходных данных

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

Изначально необходимо определить начало и конец будущей процедуры (рис. 5.67).

Рис. 5.67. Определение начала и конца процедуры

В качестве исходных данных определен бизнес-элемент, описывающий параметры процедуры. В качестве результативных данных специальный бизнес-элемент не создавался, поскольку результатом является простой текст ошибки либо пустая строка, если ошибка отсутствует. Это определило вариант указания результата в виде простых текстовых данных.

Согласно условию в примере оприходование товара на складе может выполняться только в случае, когда товар будет найден в базе данных. Поэтому первой задачей будет проверка наличия товара в базе данных (рис. 5.68), используя таблицу С ргобисХ, что в модели можно представить комбинацией глобального процесса выборки товаров по заданному параметру и простого решения по определению успешности выполнения операции.

Рис. 5.68. Проверка существования указанного товара

Для того, чтобы проверить наличие товара, нужно выполнить простую выборку данных по идентификатору товара, который присутствует в исходных данных процедуры. Ввиду того что этот параметр нужен в каче-

стве самостоятельного бизнес-элемента, он создается отдельно и вносится в описание параметров исходных данных процедуры вместо существующего атрибута (рис. 5.69).

Рис. 5.69. Изменение структуры параметров процедуры

Для выборки формируется отдельная модель реализации, которая демонстрирует правильную организацию запроса к базе данных и наложения ограничений па результат выбранных данных (рис. 5.70).

В результате выборки запрос вернет одну или ноль записей из таблицы товаров, что потом проверяется простым решением, где "Да" означает, что запись существует, а "Нет" — что записей не возвращено и товар в базе данных отсутствует.

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

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

Для того чтобы в модели представить возврат сообщения об ошибке, необходимо создать уведомление, что можно сделать, выбрав в контекстном меню бизнес-элементов пункт "Создать/Уведомление" (рис. 5.72). В соответствующем диалоговом окне описывается нужное сообщение.

Рис. 5.70. Выборка товаров по идентификатору

Рис. 5.71. Добавление сообщения об ошибке

Рис. 5.72. Описание сообщения об ошибке

В дальнейшем это уведомление привязывается к элементу "Передатчик уведомлений", что отражает отправку сообщения пользователю.

Последующее моделирование связано с непосредственными операциями внесения данных в базу данных, для чего необходимо выполнить ряд действий, а именно: создать новую запись в таблице "Получение товара" и изменить общее количество товара на складе в хранилище "Количество товаров". Эти две операции выполняются последовательно друг за другом, но перед второй операцией необходимо определить, как ее выполнить, поскольку товар может поступить первый раз и в хранилище количества товаров па складе может не быть соответствующей записи.

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

Параллельно с добавлением необходимых задач в модель процедуры вносятся хранилища, которые характеризуют взаимодействие задач с таблицами данных (рис. 5.74), учитывая, что обязательным является операция сохранения данных в хранилище данных.

Теперь эта модель может считаться законченной, описывающей полный процесс хранимой процедуры, учитывая, что некоторые операции: выборка данных для проверки, триггер на добавление товара, являются глобальными процессами и описываются дополнительно. Именно поэтому при добавлении этих глобальных процессов в модель процедуры обработки данных не были включены соответствующие указания на использование таблиц.

Рис. 5.73. Модель реализации процедуры

Рис. 5.74. Добавление таблиц для сохранения данных