Модификация это в информатике

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

Пример

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

Рассматриваемый пример содержит в своей формулировке несколько операций, которые должны быть выполнены в комплексе. При этом формулировка содержит указание на выполнение операции корректировки хранилища данных об общем количестве товаров на складе (рис. 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. Добавление таблиц для сохранения данных

  • терминологии нотации ВРМN.

Если необходимо что-то изменить в схеме базы данных, можно воспользоваться оператором ALTERTABLE. Он используется с тем, чтобы изменять определение существующей таблицы: т. е. добавлять, удалять или изменять столбцы в таблицах.

Типичный синтаксис для добавления столбца к таблице:

ALTER TABLE <имя таблицы>

ADD <имя столбца> <тип данных> <размер> NULL

Столбец будет добавлен со значением NULLдля всех строк таблицы. Новый столбец станет последним по порядку столбцом таблицы.

Также имеется возможность удалять или изменять столбцы, например оператором:

ALTER TABLE <имя таблицы>

DROP <имя столбца> <тип данных>

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

        1. Выбор варианта сетевого решения субд.

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

    1. Проектирование базы знаний.

      1. Данные и знания.

При обработке на ВМ данные трансформируются условно проходя следующие этапы:

  1. данные как результат измерений и наблюдений;

  2. данные на материальных носителях информации (таблицы, протоколы, справочники);

  3. модели (структуры) данных в виде диаграмм, графиков, функций;

  4. данные в компьютере на языке описания данных;

  5. базы данных на машинных носителях информации.

Знания основаны на данных, полученных эмпирическим путем. Они представляют собой результат мыслительной деятельности человека, направленной на обобщение опыта, полученного в результате практической деятельности. Наиболее распространенное определение знания следующее: знание – это закономерности предметной области (принципы, связи, законы), полученные в результате практической деятельности и профессионального опыта, позволяющие специалистам ставить и решать задачи в проблемной области. При обработке на ВМ знания трансформируются аналогично данным:

  1. знания в памяти человека как результат мышления;

  2. материальные носители знаний ( книги, методические пособия и т.п.);

  3. поле знаний — условное описание основных объектов проблемной области, их атрибутов и закономерностей, их связывающих;

  4. знания, описанные на языках представления знаний (продукционные языки, семантические сети, фреймы и др.);

  5. база знаний на машинных носителях.

Существуют десятки моделей (или языков) представления знаний для различных проблемных областей. Большинство из них может быть представлено следующими классами:

  1. продукционные модели;

  2. семантические сети;

  3. фреймы;

  4. формальные логические модели.

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

  1. большая гибкость по сравнению с традиционными четкими методами, так как они позволяют описывать знания и опыт человека в привычной для него форме;

  2. нечеткие модели более адекватны реальному миру, поскольку позволяют получить решение с учетом индивидуальных особенностей, свойственных не классу объектов исследования, а отдельному объекту этого класса;

  3. возможность в ряде случаев более оперативного получения окончательного результата, чем на «точных» моделях, в силу активного использования знаний и опыта человека при построении нечетких операций.

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

Эти модели используются для решения задач:

  1. интерпретации данных;

  2. диагностики;

  3. прогнозирования;

  4. проектирования;

  5. управления;

  6. поддержки принятия решений.

Интерпретация данных.

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

Диагностика.

Под диагностикой принято понимать процесс соотнесения объекта с некоторым классом объектов и/или обнаружение неисправности в некоторой системе. В курсовой работе предусматривается диагностика программных, информационных, технических средств СУ. К этому классу задач отнесена оценка уровня морального старения средств вычислительной техники, используемой в СУ. Для решения этих задач используется ГНС.

Прогнозирование.

Прогнозирование позволяет предсказывать последствие событий, явлений, реализации принятых решений в проблемной области на основании имеющихся данных. Для прогнозирования рекомендуется использовать ГНС. Так, например, прогнозирование уровня морального старения средств вычислительной техники, используемой в СУ.

Проектирование.

Основная проблема – получение четкого описания знаний о проектируемом объекте, его свойствах. Для организации эффективного проектирования и в еще большей степени перепроектирования необходимо формировать не только сами проектные решения, и мотивы их принятия. Таким образом, в задачах этого класса тесно связаны два основных процесса: процесс вывода решения и процесс объяснения. В этих задачах используется система нечеткого вывода и гибридные нейронные сети.

Управление.

Под управлением будем понимать функцию СУ, автоматически (в САУ) и автоматизировано (в АИУС) поддерживающую определенный режим функционирования управляющей и управляемой систем. Для решения этой задачи используется СНВ и ГНС.

Поддержка решений.

Поддержка принятия решений – это совокупность процедур, обеспечивающее лицо, принимающее решения(ЛПР), необходимой информацией и рекомендациями, облегчающими процесс принятия решений в проблемной области. В этом классе задач используются СНВ и ГНС.