Дипломная (вкр): Таблицы принятия решений в СУБД с табличной моделью данных

Рисунок 11 - таблица metadata

Рисунок 12 - пример заполнения таблицы metadata

Таблица history (рисунок 13) - хранит историю работы каждого клиента. Содержит последовательность переходов между таблицами принятия решения, а также информацию о завершении работы с той или иной таблицей принятия решений. Помимо номера таблицы, к которой осуществляется переход, также хранится номер условия, с которого будет начата работа на следующем шаге (по умолчанию имеет значение 1), номер продукции, по которой был осуществлён переход, полученное при работе значение продукции и название базиса, в соответствии с которым это значение рассчитывалось. Также присутствует поле reason, в которое выводится информация о причинах принятого решения.

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

Рисунок 13 - таблица history

Поля: status - статус работы с таблицей, step - номер шага, на котором осуществлялась работа с таблицей.

Рисунок 14 - пример заполнения таблицы history(часть 1)

Рисунок 15 - пример заполнения таблицы history(часть 2)

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

Информацию об области и подобласти, с которыми работает клиент, можно извлечь из таблицы decision, используя суррогатный ключ из столбца sid.

Таблица bases (рисунок 16) - содержит формулы конъюнкции, дизъюнкции, отрицания и импликации в различных базисах, которые используются для вычисления значимости продукции.

Рисунок 16 - таблица bases

Поля: basis_id, formula_id - id базиса и одной из 4х формул, вместе образуют первичный ключ. Basis_name - название базиса, например «базис Вебера», formula_type - тип описываемой формулы, принимает одно из четырёх значений: «&»(and), «||»(or), «^»(not), «->»(implication). Поле formula содержит непосредственно формулы соответствующих операций. Для унарных операций в качестве обозначения переменной используется «А», для бинарных «А» и «В». Каждую операцию над двумя переменными следует выделять скобками, например, для операции импликации:

(min(A,B),(1-A))

2.2 Пакет pkg_ get_answer. Использование процедур и функций пакета

Рисунок 17 - схема пакета pkg_get_answer

Пакет pkg_get_answer (рисунок 17) содержит процедуры и функции, реализующие процессы, обеспечивающие создание, редактирование и работу с таблицами принятия решений

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

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

Пример поиска нужной продукции:

((p(1)=a(1)) OR (p(1)='_')) AND ((p(2)= a(2)) OR (p(2)='_')) AND

((p(3)= a(3)') OR ( p(3)='_')) AND ((p(4)= a(4)) OR (p(4)='_')) AND

((p(5)= a(5)) OR (p(5)='_'))

где p(i) - массив элементов продукции, a(i) - массив ответов пользователя.

Входными параметрами являются имя системы (p_sysname), область (p_domain), подобласть (p_subdomain), номер таблицы (p_table_id), id клиента (p_client_id).

Пример вызова процедуры:

_answer.go('Medicine','Diagnostics','Skin',1,1);

end;

Процедура add_history - добавляет данные о новом шаге работы пользователя в таблицу history: id таблицы, с которой пользователь завершил работу, полученный список действий и последействий, номер шага. В столбце последействия записывается номер таблицы и условия, к которому будет осуществлён переход. Если последействие имеет значение null, то процедура записывает шаг в таблицу history (рисунок 21) без перехода на другие таблицы и выдаёт сообщение о завершении работы с системой. В этом случае, в поле current_progress таблицы data_clients будет записано значение null.Помимо этого процедура сравнивает значение продукции с порогом значимости и, в случае, если значение ниже этого порога, ставит статус «abort», означающий, что с данной веткой дальнейшая работа невозможна. В поле reason выводится обоснование принятого решения: исходные условия, по которым была выбрана эта продукция, значение продукции, значение порога

Перед добавлением данных процедура проверяет: работал ли клиент с таблицей, к которой мы собираемся перейти. Если работа с этой таблицей уже была закончена, то данное последействие игнорируется и не заносится в таблицу. В случае успешного перехода к новой таблице, её номер записывается в поле current_progress таблицы data_clients.

Входными параметрами процедуры add_history являются суррогатный ключ (p_sid), id клиента (p_client), id пользователя (p_user), номер продукции, по которому будет осуществлён переход (p_prod_id), номер условия, с которого начата работа с таблицей (p_position) и значение данной продукции (p_prod_value). Вызывается только в процессе работы другой процедуры prc_go.

Процедура trans - осуществляет преобразование заданной таблицы решения в вид, понятный пользователю. Результат записывается в соответствующую временную таблицу.

Входными параметрами являются имя системы (sysname), область (domain), подобласть (subdomain), номер таблицы (tableno).

Пример работы процедуры trans для одной из таблиц учебной базы приведен на рисунках 22 и 23.

Пример вызова процедуры:

_answer.trans('Medicine','Diagnostics','Skin',1);;

Функция fnc_get_value - вычисляет значение необходимой продукции в указанном базисе, в своей работе использует вспомогательную функцию fnc_calculation. На основе продукции составляются 2 формулы, учитывающие все логические операции и значимости: отдельно для условий, отдельно для действий. Например, для ограниченного ввода, исходная комбинация условий

&(yes||no),

где значимость первого условия равна 0.2, второго - 0.7, третьего - 0.6, примет вид:

.2&(0.7||^0.6)

Унарная операция отрицания уже на этом этапе вычисляется при помощи функции fnc_calculation, в соответствии с выбранным базисом. Например, ^A = 1-A. Тогда ^0.6 = 0.4 Далее, используя принцип обратной польской нотации, формула приводится к виду, удобному для вычисления системой:

.2 ; 0.7 ; 0.4 ; || ; &.

После нахождения значений комбинации условий и действий, вычисляется значений самой продукции:

вес комбинации условий -> вес комбинации действий.

В ситуации с расширенным вводом помимо значимости условий, учитываются ещё и степень «выраженности». Например, если есть всего два условия, соединённых &, и значимость первого равна 0.3, степень 0.6, второго - 0.7 и 1, тогда значение продукции будет вычислено как:

(0.3*0.6)&(0.7*1).

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

Пример вызова:

:= pkg_get_answer.fnc_get_value(1, 1, 1);

Для вычисления операций &, ||, ^, -> используется функция fnc_calculation, которая выбирает необходимую формулу из таблицы bases, подставляет в неё значения, полученные в качестве входных параметров и вычисляет её, также используя обратную польскую нотацию. Работает как с унарными, так и бинарными операторами. Входные параметры: id базиса, тип логической операции, 2 числовых параметра. Пример вызова:

:= pkg_get_answer.fnc_calculation(0.1, 0.9, '&', 1);

Обе функции возвращают числовые значения.

2.3 Контроль корректности данных

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

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

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

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

В представленной работе, «эталонной» таблицей считается metadata. Подразумевается, что в ней хранятся верная информация о системах, областях, подобластях, таблицах, условиях и действиях. При добавлении данных в таблицы decision, data, data_users, data_clients проверяется наличие таковых данных в metadata и, в случае их отсутствия, выдаётся ошибка. Это позволит сохранить «согласованность» данных не только при сбоях в работе интерфейса, но и в случае заполнения таблиц непосредственно из СУБД.

Также, ведётся контроль за форматом хранения комбинации условий (поле conditions в таблице decision). Комбинация должна содержать только ответы «yes», «no» и символы «& || _». Например

&(no||yes)

Ошибки вида «yesno&&yes» помогает исключить использование регулярных выражений.

Аналогичным образом контролируются ответы пользователя: допустимы значения «yes» и «no», в случае ограниченного ввода, и числовые значения в интервале от 0 до 1 в случае расширенного.

Помимо триггеров, контролировать данные помогают ограничения целостности, например ограничение CHECK(formula_type IN ('&', '||', '^', '->')) в комбинации с UNIQUE(basis_id, formula_type) в таблице bases позволяет хранить лишь 4 различных типа формул на каждый базис. Внешние ключи позволяют контролировать привязку клиентов к пользователям.

Примеры используемых триггеров можно посмотреть в приложении.

2.4 Адаптивный интерфейс пользователя

В представленной работе был доработан адаптивный web-интерфейс, основная часть которого была разработана в курсовой работе «Адаптивный интерфейс для работы с таблицами принятия решений», автор - Дербенева Е.Е.

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

Обмен данными с пользовательским интерфейсом осуществляется с помощью технологии Ajax, с использованием формата JSON. На стороне клиента создаётся подключение к СУБД и формируются SQL-запросы.

Для работы с таблицами принятия решений пользователь вызывает необходимые ему процедуры и функции, находящиеся в пакете PKG_GET_ANSWER. При вызове, пользователь указывает, в общем случае, название системы, области и подобласти, номер таблицы, с которыми работает пользователь, а также id клиента. Результат выводится во временные таблицы, данные из которых можно извлечь соответствующим SQL-запросом.

Главная страница интерфейса (рисунки 18-20) представляет собой меню, с помощью которого пользователь может войти в систему и выбрать соответствующие область и подобласть знаний. Новые пользователи имеют возможность зарегистрироваться. При желании пользователь может загрузить обучающие материалы и по таблицам принятия решений, и работе интерфейса.

Рисунок 18 - главная страница интерфейса

Рисунок 19 - Главная страница интерфейса

Рисунок 10 - главная страница

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

Рисунок 20 - аутентификация

Так выглядит регистрационная форма (рисунок 21). Обязательными являются только три поля: имя, логин и пароль.

Рисунок 21 - регистрация пользователя

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

Рисунок 22 - база клиентов

При необходимости пользователь может добавлять и удалять клиентов (рисунок 23). Данные манипуляции проводятся с таблицей Data_Clients.

Рисунок 23 - регистрация клиентов

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

Рисунок 24 - страница с базисами

На странице с данными о клиентах столбцы ANS и HIS содержат ссылки на страницы, отображающие данные обо всех ответах конкретного клиента и историю его работы с системой соответственно (рисунки 25-26).

Рисунок 25 - страница с ответами клиента

Рисунок 26 - страница с историей клиента

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

В столбце CURRENT_PROGRESS находится номер следующей таблицы решений. И при нажатии на ссылку происходит переход на страницу заполнения (рисунки 27-28). В качестве параметров выступают: имя системы, область, подобласть знаний, номер таблицы и идентификатор клиента.

Рисунок 27 - опрос клиента (вариант с ограниченным вводом)

Рисунок 28 - опрос клиента (вариант с ограниченным вводом)

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