Разработка программного
обеспечения для систем управления бизнес процессами с использованием
искусственного интеллекта
Д.О. Гринько,
асп., denis_grinko@mail.ru
РУДН, Москва
Статья содержит краткое описание особенностей организации
структуры данных в базах данных (БД) систем управления бизнес процессами. Классифицированы
типы отношений между таблицами БД. Описана специфика внедрения информационных
систем в отечественных компаниях. Рассмотрены основные ошибки, вызванные человеческим
фактором при проектировании систем. Предлагается алгоритм анализа базы данных
для генерации продукционных правил для оперативного контроля входных данных и
поддержания целостности системы.
The
article contains a brief description of the peculiarities of the organization
of the data structures in the database (DB) management systems of business
processes.. Classified the types of relationships between database tables.
Describes the specifics of the implementation of information systems in
domestic companies. Describes the basic errors associated with the human factor
at the design of systems. It is proposed algorithm of database analyzing for generation the
production rules for operational control of the input data and maintain the
consistency of the system.
Введение
Проблемы проектирования и внедрении информационных
систем (ИС), рассматриваемые в рамках данной работы, связанны с особенностями
применения ИС для систем управления бизнес процессами в России и учета человеческого
фактора. Особенно это актуально при использовании и расширении функционала зарубежных
ИС под специфику отечественных компаний. При этом, в мире известны единичные
случаи, когда системы автоматизации и оптимизации деятельности крупных компаний
были установлены и сконфигурированы без необходимости выполнении дополнительных
разработок и тестирования. В данной работе рассматривается подход к созданию более
эффективного программного обеспечения для систем управления бизнес-процессами с
использованием методов искусственного интеллекта. Рассматриваются способы улучшения
организации и анализа связей структур баз данных на основе разработки
продукционных правил для обеспечения более надежной автоматизации бизнес-процессов.
Структура организации данных в БД
Существуют различные подходы к физическому хранению
отношений. Наиболее распространенным является покортежное хранение отношений
(кортеж является единицей физического хранения). Это
обеспечивает быстрый доступ к целому кортежу, но при этом во внешней памяти
дублируются общие значения разных кортежей одного отношения и, вообще говоря,
могут потребоваться лишние обмены с внешней памятью, если нужна часть кортежа.
Альтернативным (менее распространенным) подходом
является хранение отношения по столбцам, т.е. единицей хранения является
столбец отношения с исключенными дубликатами. Естественно, что при такой
организации суммарно в среднем тратится меньше внешней памяти, поскольку дубликаты
значений не хранятся; за один обмен с внешней памятью в общем случае
считывается больше полезной информации. Дополнительным преимуществом является
возможность использования значений столбца отношения для оптимизации выполнения
операций соединения. Но при этом требуются существенные дополнительные действия
для сборки целого кортежа (или его части).
Поскольку гораздо более распространено хранение по
строкам (покортежное), будет рассматриваться этот способ хранения отношений.
Типовой структурой страницы данных является следующая:
рис. 1 Типовая структура страницы данных
В данной работе рассмотрены базы данных с
построчным способом хранения данных, в виде электронных таблиц, наиболее часто
встречающиеся средства для обеспечения взаимосвязей между электронными документами
в случае использования плоских таблиц баз данных.
В основном, связь между таблицами осуществляется с
помощью указания в полях одной таблицы полей другой.
В данной работе предлагается разделить поля таблиц
на следующие типы (и в случае необходимости, сводить остальные типы к ним):
1. Текстовые
поля – произвольный текст заданной длины (в общем случае 255)
2. Целочисленные
поля. По большей части – идентификационные номера в системе
3. Числовые
дробные поля. В частности, поля содержащие суммы и показатели измерений
4. Поля
даты и времени
Как известно, таблицы баз данных содержат в себе
кроме обычный полей, также ключевые поля и индексы.
Ключевые поля обеспечивают уникальность каждой
записи таблицы. Совокупность всех ключевых полей таблицы являются её уникальным
идентификатором.
Индексы используются для оптимизации механизмов
поиска по таблице.
В рамках текущей работы рассмотрены следующие виды
связей между таблицами:
1.
Ключевое
расширение: если ключевые поля одной таблицы равны ключевым поля другой таблицы
2.
Ключевая
детализация: если ключевые поля одной таблицы включают в себя все ключевые поля
другой таблицы при разном количестве ключевых полей
3.
Расширение:
если набор полей одной таблицы равны набору полей другой таблицы, при том, что
из полей, связывающих таблицы не все являются ключевыми
4.
Детализация:
набор полей одной таблицы включают в себя набор полей другой таблицы, при том,
что из полей, связывающих таблицы не все являются ключевыми
5.
Прямая
связь: если набор полей одной таблицы равен ключевым полям другой таблицы
6.
Косвенная
(не преобразованная связь): если набор полей одной таблицы равен ключевым полям
другой таблицы после преобразования
В современных
информационных системах обычно присутствует
начальный набор данных для каждой таблицы, набор связей между таблицами и
проверок для каждого элемента данных. Их здесь и далее будем называть стандартными данным/связями/проверками.
В реальных информационных системах связи используются
для:
1.
Обеспечения
взаимосвязями между электронными документами в рамках одного процесса.
Это
позволяет обеспечить сквозную обработку процесса и хранить все промежуточные
данные. Найти первоисточник того или иного документа.
Например,
платежное поручение, которое отправляет компания в банк для перевода
собственных денежных средств другой компании за оказание тех или иных услуг
обязательно должно иметь основание: счет на оплату от контрагента, оказавшего
эту услугу. В данной ситуации к платежное поручение в информационной системе
должно иметь ссылку на документ счета от контрагента.
2.
Расширения
перечня стандартных полей.
Поскольку
некоторым компаниям для принятия верного оперативного решения требуются
дополнительные данные (в виду специфики процесса, внутренних регламентов и др.)
Например,
в компаниях, которые производят расчеты с контрагентами по факту осуществления
какого-либо действия (отгрузка товара с промежуточной станции, установка
оборудования, окончание строительных работ) часто добавляют в документы счета
данные о текущем статусе указанного выше действия.
Специфика использования информационных систем в отечественных компаниях
В случае необходимости расширения функциональности ИС обычно это делается следующим
образом:
1.
Формулировка
пользователем начальных требований.
2.
Анализ
требований и формализация задачи специалистом по работе с системой с учетом анализа текущих возможностей системы.
3.
Реализация
задачи программистом.
Успешность выполнения всех трех этапов зависит от
квалификации конкретных людей. Например, если специалист по внедряемому
программному обеспечению не идеально знает все тонкости системы, то он может выставить
программисту задачу, уже решенную в системе. Специалист по системе обычно обладает
довольно узкой специализаций (ввиду широких возможностей ИС и наличию
огромнейшего функционала по самым различным направлениям) и не всегда может
точно формализовать задачу, касающуюся смежных направлений. Специалист по финансам редко знает особенности настройки модулей,
связанных с логистикой, хотя их интеграция между собой
используется практически в каждом проекте по автоматизации бизнес-процессов.
Операторы при работе с ИС при продуктивной
эксплуатации системы производят ежедневно большое количество операций. При
этом, с увеличением темпа их работы растут риски введения неверных данных. Для
минимизации подобных ошибок в системах обычно накладываются ограничения на ввод
тех или иных данных в конкретных электронных документах. Стоит отметить, что
чрезмерный контроль данных повлечет за собой невозможность работы с системой,
поскольку может ограничить выполнение даже
крайне необходимых функций. Из-за этого ограничения делаются с «округлением» в
меньшую сторону – пользователям дают чуть больше возможностей, чем необходимо,
а после старта системы накладывают всё больше оперативных проверок. Кроме того,
далеко не все проверки предусматриваются при проектировании ИС, часть из них приходится
добавлять только спустя некоторое время после начала продуктивной эксплуатации.
Целью данной работы является поиск основных закономерностей
и текущих правил взаимодействия электронных документов между собой. Для этого
предполагается произвести поэтапный анализ таблиц БД для попытки нахождения
закономерностей между различными таблицами.
Объем базы данных крупной информационной системы
может достигать сотен миллионов записей в одной таблице и поиск всех возможных
взаимосвязей может сильно загрузить серверы системы. В связи с этим техническим
специалистам необходимо предоставить
возможность ограничить выборку данных для анализа, а также ограничить типы
искомых связей.
Предлагается использовать следующий алгоритм поиска:
1.
Определение
фильтров поиска по классам связей и типам данных.
2.
Определение
обработчика для результатов поиска.
3.
Выборка
данных из таблицы-приемника для анализа.
4.
Группировка
и преобразование данных.
5.
Выборка
из предполагаемой таблицы-источника.
6.
Осуществление
заданных действий.
Фильтры в поиске связей
необходимы для сокращения времени работы программного анализатора и облегчения
нагрузки на сервер приложений. Для фильтрации поиска предлагается использовать
следующие данные:
1.
Код программ. Зачастую, в кодах
программ содержится краткое предназначение самой программы или области, где она
будет использоваться. При этом должны быть проанализированы все таблицы, обращение
к которым происходит во время выполнения программы. Специалисту требуется понимать,
в какой примерно момент времени осуществляется запись взаимосвязи.
2. Пакеты программ. Группы программ объединяют в пакеты (термин
"Пакеты" может меняться в зависимости от информационной системы). Эти
данные обеспечивают возможность учета более общих
ограничений. Специалисту требуется понимать, в какой области должны формироваться
связи.
3.
Таблицы. Ограничение по перечню
таблиц. Обычно, в ИС нестандартные таблицы именуются с различными префиксами.
Например, в системе SAP ERP
имена нестандартных таблиц могут начинаться только с символов X,
Y, Z. Соответственно,
если требуется осуществить поиск взаимосвязей между нестандартными таблицами,
то можно задать автомаскирование с указанием первого символа.
4.
Пакеты таблиц. Аналогичным образом
можно ограничить и группу таблиц БД, если у специалиста есть предположения об
области хранения данных и используемых искомых связях.
5.
Типы связывающих
полей (входящих и исходящих). К типам связывающих полей относятся следующие
типы данных:
a.
Текстовые
поля.
b.
Целочисленные
поля.
c.
Численные
поля.
d.
Поля
даты и времени.
Стоит отметить, что для
ведения ключевых полей и индексов обычно используются целочисленные поля со
стандартным счетчиком (как наиболее простой способ обеспечения уникальности
каждого ключа и удобства поиска по индексам таблицы). По ним в первую очередь стоит запускать анализатор
связей.
Не стандартные связи часто задаются с помощью текстовых полей. При
использовании текстовых полей в качестве ключей легче создать «говорящие» ключи
с именем, указанным на естественном языке.
6. Типы связей:
a.
Ключевое
расширение.
b.
Ключевая
детализация.
c.
Расширение.
d.
Детализация.
e.
Прямая
связь.
f.
Косвенная связь.
В общем случае, специалист
по внедряемой информационной системе должен четко понимать между какими
электронными документами, возможно, утеряна или не описана в документации
связь.
Проведение анализа таблиц БД для формирования продукционных правил
Рассмотрим алгоритм проведения анализа таблиц БД
для последующего формирования продукционных правил, описывающих связи. В
начальной таблице выделяется k записей, далее,
поочередно, по каждому столбцу производится выборка из таблицы-источника,
содержащей M записей. После каждого шага оценивается число
найденных записей в таблице-источнике, m записей. Специалисту также
требуется задать величину числа m, при которой будет
считаться, что между таблицами источника и приемника установлена связь.
рис. 2 Выборка данных из
таблицы источника по данным таблицы-приемника
Алгоритм поиска делится на следующие шаги:
1.
Определение
начальной выборки (k записей) и параметров для
осуществления этой выборки.
2.
Выполнение
поочередной выборки из таблицы-источника по столбцами таблицы-приемника.
3.
Оценка
числа найденных записей.
Второй шаг, в данном случае, должен быть повторен (N1*(N2!)) раз (число столбцов
таблицы-источника и таблицы приемника соответственно). Наличие факториала связано
с необходимостью поиска связей, осуществляемых за счет нескольких полей одновременно.
Таким образом, в результате проведения поиска
должны быть известны:
1. Найденная группа записей в таблице источнике – m
2. Число связующих полей
После нахождения
взаимосвязи требуется определить критерии, при выполнении которых происходит
сцепление таблиц. Для этого требуется произвести анализ найденных записей на
наличие идентичных или схожих полей. Т.е. если в найденной группе в поле Х
всегда содержится одно значение, то логично предположить, что данное поле
должно быть включено в перечень критериев.
Кроме равенства значений в
поле Х можно, также рассматривать поля схожие по значениям. Например, когда в
поле Y для всех найденных значений первые S символов идентичны.
В результате проведения анализа можно сформировать
наборы продукционных правил, описывающих текущие ситуации. В общем случае, по результатам
анализа формируются правила вида:
Если P,
В случае R.
Правило для R = R1
выполняется:
То реакция 1,
…
Правило для R = Rn выполняется:
То реакция n,
Где P – набор критериев для
записей таблицы-приемника, что в текущей записи должна присутствовать ссылка на
другую таблицу.
R – значение в ссылочных
полях. В простом случае, если R = пусто, то выдать пользователю
сообщение об ошибке, что требуется заполнить значение.
Заключение
В данной работе рассмотрен подход к разработке
программного обеспечения для систем управления бизнес процессами с
использованием продукционных правил. Рассмотрены способы организации связей
структур баз данных для обеспечения надежной интеграции бизнес-процессов и
автоматизации конфигурирования ПО и выполнения всех операций. Описана специфика
внедрения информационных систем в отечественных компаниях и устранения ошибок, возникших
при внедрении ИС, связанных с человеческим фактором.
Литература
1. Рыбина Г.В. Основы
построения интеллектуальных систем: учебное пособие: - М.: ИНФРА-М, 2010.
2. Разработка приложений SAP
R/3 на языке АВАР/4: Рюдигер К., Вольфганг В. – Москва, Лори, 1998 г.
3. Гринько Д.О., Чинакал В.О.
Разработка адаптивного интерфейса интегрированной системы имитационного моделирования
коллективного пользования // Материалы 5-ой междунар. конф. «Инженерные системы
– 2012». – М.: РУДН, 2012.
4. С.Д. Кузнецов. Основы
современных баз данных. http://www.citforum.ru/database/osbd/contents.shtml
5.
Production Planning and
Control with SAP ERP: Dickersbach J.T., Keller G. – Bonn, Galileo Press, 2010.