Таблицы принятия решений в СУБД с табличной моделью данных. Дипломная (ВКР). Информационное обеспечение, программирование.
⚡ 👉🏻👉🏻👉🏻 ИНФОРМАЦИЯ ДОСТУПНА ЗДЕСЬ ЖМИТЕ 👈🏻👈🏻👈🏻
Информационное обеспечение, программирование
Вы можете узнать стоимость помощи в написании студенческой работы.
Помощь в написании работы, которую точно примут!
Похожие работы на - Таблицы принятия решений в СУБД с табличной моделью данных
Скачать Скачать документ
Информация о работе Информация о работе
Скачать Скачать документ
Информация о работе Информация о работе
Скачать Скачать документ
Информация о работе Информация о работе
Скачать Скачать документ
Информация о работе Информация о работе
Нужна качественная работа без плагиата?
Не нашел материал для своей работы?
Поможем написать качественную работу Без плагиата!
ММИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное бюджетное образовательное учреждение
высшего профессионального образования
«КУБАНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»
Кафедра математического моделирования
ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ
(ДИПЛОМНАЯ) РАБОТА
«ТАБЛИЦЫ ПРИНЯТИЯ РЕШЕНИЙ В СУБД С
ТАБЛИЧНОЙ МОДЕЛЬЮ ДАННЫХ»
Факультет
компьютерных технологий и прикладной математики
Специальность
прикладная информатика и математика
канд. тех.
наук, доцент Бессарабов Н.В
Объектом исследования является встроенное в базу данных интеллектуальное
расширение СУБД, использующее таблицы принятия решений.
Цели работы: создать систему ТПР, встроенную в СУБД Oracle. Провести экспериментальные
исследования быстродействия.
- создать базу данных для инструментального средства,
предназначенного для работы с таблицами принятия решений, встроенными в СУБД Oracle,
- создать пакет процедур и функций, реализующий процессы,
обеспечивающие создание, редактирование и работу с таблицами принятия решений,
- доработать интерфейсы, разработанные в курсовой работе
Дербеневой Е. «Адаптивный интерфейс для работы с таблицами принятия решений»,
выполнить экспериментальную проверку инструментального средства.
Исследования проводились с помощью СУБД Oracle.
Адаптивный WEB-интерфейс
пользователя был реализован с использованием технологий HTML5, CSS3, JavaScript, JSON, PHP.
Искусственный интеллект - это один из разделов информатики, в котором
рассматриваются задачи аппаратного и программного моделирования тех видов
человеческой деятельности, которые считаются интеллектуальными [1].
Экспертные системы являются одним из основных направлений искусственного
интеллекта. Как правило, экспертные системы создаются для решения практических
задач в некоторых узкоспециализированных областях, где большую роль играют
знания и опыт специалистов. Фундаментом экспертной системы любого типа является
база знаний, которая составляется на основе знаний специалистов [2].
Второе направление - интеллектуальное управление - методы управления,
которые используют различные подходы искусственного интеллекта, такие как
искусственные нейронные сети, нечеткая логика, машинное обучение, эволюционные
вычисления и генетические алгоритмы.
Одно из важнейших отличий интеллектуального управления от экспертной
системы в том, что входные данные могут поступать не от человека, а от программных
модулей и, поэтому, нуждаются в более тщательных проверках. Возможно прерывание
процесса с целью получения решения пользователя. В этом случае, необходимо
предоставить ему корректные данные и, насколько возможно, проконтролировать
последовательность действий по принятию решения. Тем не менее, основная
нагрузка по контролю корректности данных всё так же остаётся на плечах
пользователей и экспертов, предоставляющих данные системе.
Таблицы принятия решений (ТПР) - способ компактного представления модели
со сложной логикой. ТПР возникли в деловой практике еще в 60-ых годах прошлого
века, зарекомендовав себя как удобное средство для быстрого, простого описания
сложных процессов, структур и задач.
Аналогично условным операторам в языках программирования, они устанавливают
связь между условиями и действиями. Но, в отличие от традиционных языков
программирования, таблицы решений в простой форме могут представлять связь
между множеством независимых условий и действий.
Высокая эффективность работы с таблицами решений позволяет строить
сложные системы искусственного интеллекта. Их преимущества по сравнению с
обычными экспертными системами - простота эксплуатации, встраивание в базу
данных и, вытекающая из этого обстоятельства, возможность использования
индексов базы для ускорения доступа к большому объёму фактов, представленных
таблицами базы данных.
Также, таблицы принятия решений могут представляться деревьями принятия
решений, которые в настоящее время широко используются в области статистики и
анализа данных: на ребрах дерева записываются атрибуты, от которых зависит
целевая функция, в «листьях» - значения целевой функции, а в остальных узлах -
атрибуты, по которым различаются случаи.
В представленной работе используются таблицы принятия решений, встроенные
в СУБД Oracle, которые не требуют инсталяции
Oracle Fusion Middleware и потому могут работать в любой комплектации СУБД, в
частности в бесплатной для коммерческого использования версии Oracle XE.
В общем виде под продукцией понимают выражение вида
Импликация,
чаще всего, может истолковываться в обычном логическом смысле, как знак логического
следования B из А. Но классическая продукционная система Поста с продукциями
общего вида слишком ограниченна. Имеется гораздо более широкое определение.
По
Поспелову Д.А. [10] продукционная модель знаний основывается на правилах,
имеющих в общем случае вид:
Более
точно, ядро продукции А К для
предлагаемого проекта следовало бы записать в виде:
где
x,y {БД, РС, БЗ} и через БД обозначен внешний мир,
которым в нашем случае является база данных, РС это рассуждающая система, БЗ -
база знаний.
Имеется
в виду, что информация может поступать из внешнего мира (АБД), из базы знаний
(АБЗ) и из самой рассуждающей системы (АРС), а следствие представляет изменения
в базе данных (КБД), в базе знаний (КБЗ) или в рассуждающей системе (КРС).
Поясним
на примере, как ядро продукции можно реализовать с помощью SQL-запроса. Любую
таблицу можно воспринимать как набор фактов описываемых предикатом, полученным
взаимно однозначным отображением схемы таблицы в предикат.
В
качестве примера возьмём таблицы employees, departmets и locations из многим известной учебной схемы HR в
СУБД Oracle. Используем продукцию, определяющую отношение
«Работает в городе», то есть «город, в котором находится отдел, в котором
работает сотрудник»:
Работает_в_отделе(employee,
department)
Отдел_находится_в_городе(department, city)
Сотрудник_работет_в_городе(employee,city)
В
языке SQL этой продукции соответствует запрос:
SELECT e.employee_id, l.cityemployees e, departments
d, locations le.department_id = d.department_idd.location_id = l.location_id
Заметим,
что подобная реализация через запросы с соединениями таблиц для практики из-за
плохих планов исполнения, приемлема только в том случае, когда в ядре продукции
используются предикаты, представленные таблицами базы данных.
В
общем случае таблица принятия решений, предназначенная для восприятия
человеком, разделяется на четыре области (таблица 1).
Таблица 1 - Таблица принятия решений
Каждое правило таблица принятия решений состоит из посылки (условия) и заключения
(действия). В древовидном представлении, предпосылки и заключении являются
узлами, а ветви дерева являются связями между посылками и заключениями.
Пример таблицы решений, для ситуации «Вода в гостинной» приведён в
таблице 2.
Таблица 2 - Пример таблицы принятия решений
Четыре верхних строки относятся к условиям, остальные четыре - к
действиям. Такая структура таблиц удобна для восприятия человеком, поэтому
таблицы принятия решений просты для изучения и понимания специалистами
различных профессий, довольно легко модифицируемы и имеют более универсальную,
в сравнении с блок-схемами, форму.
В некоторых случаях разделение на условие и действие может оказаться
довольно затруднительным, так как некоторые действия могут быть связаны с
условием, подразумевая, что они должны быть выполнены перед проверкой условия.
В то время как другие могут быть выполнены уже после проверки одного или
нескольких условий. Кроме того, комбинации условий или действий сами по себе могут
ссылаться на другие таблицы решений. Например, действие может включать в себя
вызов процедуры для выполнения некоторой задачи, обращение к базе, для
получения каких-либо данных или для выполнения той же задачи может быть
определено условие в другой таблице решения.
Таблицу решения, вызванную другой таблицей решения, называют
подтаблицей-действием или подтаблицей-условием. Эти подтаблицы играют важную
роль в структурировании решения и позволяют производить более тщательный и
детальный анализ.
Как частный случай перехода от одной таблицы к другой можно рассматривать
переходы внутри таблицы, что позволяет работать с исключениями из правил.
Например, представим, что таблица принятия решений содержит 7 условий, первые 2
из которых являются исключением из правил, и, если истинно хотя бы одно из них,
проверка остальных 5 условий не имеет смысла. В том случае, если мы хотим
обойти рассмотрение этих исключений, можно осуществить переход не к началу
таблицы, а к какой-либо её части. А затем, при необходимости, вернуться к
началу для проверки истинности условий-исключений (рисунок 1).
Рисунок 1 - схема работы с исключениями
Механизм логического вывода выполняет функции поиска в базе правил, последовательного
выполнения операций над знаниями и получения заключений. Существует два способа
проведения таких заключений: прямой и обратный выводы.
Формирование рассуждений в стиле обратного логического вывода может
осуществляться следующим образом. Работа по поиску причин появления воды на
полу в гостиной начинается с выдвижения гипотезы. Например, в рассмотренном
выше примере это «утечка в кухне». После этого цепочка рассуждений в сети
логического вывода формируется в обратном направлении. Для подтверждения этой
гипотезы необходимо, чтобы утверждения «неисправность в кухне», «вода не капает
с потолка» и «вода не поступает снаружи» были истинными [7].
В обратном механизме логического вывода работа начинается от поставленной
цели. Если цель A согласуется с консеквентом (заключением) продукции, то
антецедент (посылка) принимается за подцель и делается попытка подтверждения
истинности этого факта. Процесс повторяется до тех пор, пока не будут
просмотрены все правила, имеющие в качестве заключения требуемый факт.
Прямой логический вывод начинается не с гипотез, а с некоторых
подтвержденных фактов. Обнаружив, что в гостиной вода, а в ванной сухо, можно
сделать вывод, что неисправность в кухне. Кроме того, заметив, что окно кухни
закрыто и потолок сухой можно сделать заключение, что вода не поступает извне.
Это ведет к окончательному выводу, что утечка в кухне.
На практике, для решения довольно большого класса задач естественным
является прямой логический вывод. Прямой логический вывод начинается не с
гипотез, а с некоторых подтвержденных фактов [2]. Обнаружив, что в гостиной
вода, а в ванной сухо, можно сделать вывод, что неисправность в кухне; кроме
того, заметив, что окно кухни закрыто, можно сделать заключение, что вода не
поступает снаружи; это ведет к окончательному выводу, что утечка в кухне.
В представленной работе использован прямой вывод.
Для хранения таблицы решений в базе данных реляционного типа (см. табл.
3), транспонируем представляющую матрицу.
Таблица 3 - реляционное представление таблицы принятия решений для
ситуации «вода на полу»
Каждой строке этой таблицы соответствует продукция. Например, для первой
строки:
В
ванной сухо (Да) В кухне сухо (нет) Утечка в
кухне
Преобразование
транспонированием известно давно. Оно же было использовано в предыдущих
разработках [9].
Ситуации,
в которых консеквент относится к одной или нескольким столбцам, не
повторяющимся в разных продукциях, крайне неудобны. Поэтому используется
таблица вида:
Таблица 4 - реляционное представление таблицы принятия решений
Например, при работе с правилами, имеющими исключения, действий при одних
и тех же условиях может быть больше одного. Поэтому, в реализованном варианте
для каждого действия предусмотрена своя строка (т. е. продукция). Возможен
вариант продукций со списком действий в столбце «Действие».
В столбце «Последействия» записываются возможные переходы к другим
строкам таблицы (это позволяет работать с исключениями из правил) или к другим
таблицам.
Поскольку в данной работе используется прямой логический вывод, то для
выбора антецедента в экспертной системе используется ответ пользователя на
поставленные вопросы, консеквентном - соответствующее действие.
Прямой вывод в ТПР экспертной системы легко реализуется простым запросом
к единственной таблице решений, когда выбирается одна или несколько продукций.
Множественный выбор должен появляться только в ТПР с нечёткостями.
Как упоминалось выше, возможность использования запросов SQL с соединениями в качестве
эквивалентов простых продукций вида AK известна. В предлагаемой дипломной работе применяется более
эффективное решение, в котором одной продукции соответствует единственный
простой запрос к одной таблице. Этот подход распространён на таблицы принятия
решений (с ограниченным и расширенными вводами), основанными на продукциях
общего вида (с выбором области и подобласти, условий применения и заданием
последействия). Для хранения этих таблиц и работы с любыми таблицами решения
была использована универсальная модель данных (УМД).
УМД состоит из фиксированного набора таблиц. Она может хранить в себе и
данные, и метаданные нескольких виртуальных схем базы. В простейшем варианте
УМД представляет собой набор из четырех таблиц изображённый на рисунке 2.
Этот набор таблиц остаётся неизменным. Для добавления имени таблицы в
виртуальную схему необходимо добавить одну строку в таблицу «Таблица», а для
добавления столбца - добавить одну строку в таблицу «Столбец». Количество строк
в таблице «Данные», определяющих одну строку таблицы, равно числу столбцов у
этой таблицы. Заметим, что тип столбца может быть описан в колонке «Описание»
таблицы «Столбец», но может быть добавлен в дополнительном столбце [6].
Универсальность расширения обеспечивается, прежде всего, хранением
множества систем таблиц принятия решений, или продукций в универсальной модели
данных. При добавлении любого количества интеллектуальных подсистем структура
хранения не меняется. При добавлении новых таблиц принятии решений, условия и
действия записываются в таблицу metadata, а содержимое таблиц - в decision.
Таким образом, одной продукции соответствует единственный простой запрос к
одной таблице.
Особенности УМД - низкая скорость. Но в наших задачах для экспертных
систем малые объёмы данных.
Высокая эффективность работы с таблицами решений позволяет строить
сложные системы искусственного интеллекта. Их преимущества по сравнению с
обычными экспертными системами - простота эксплуатации, легкость встраивания в
базу данных и вытекающая из этого обстоятельства возможность использования
индексов базы для ускорения доступа к большому объёму фактов, представленных
таблицами базы данных.
Хранение таблиц решений в универсальной модели данных позволяет
осуществлять работу с таблицами при помощи однотипных запросов, состоящих из
трёх базовых фраз языка SQL: SELECT, FROM, WHERE
в стандарте SQL-2, что обеспечивает встраиваемость в
различные СУБД с табличной моделью данных.
Универсальность построения запросов обеспечивается использованием
технологии динамических SQL-запросов,
что позволяет избегать соединения нескольких таблиц, для получения каких-либо
вспомогательных данных и обеспечивает работу с любым количеством условий.
Например, для поиска нужных продукций, заполнения таблицы с историей
работы пользователя, может потребоваться получить дополнительную информацию,
такую как ответы пользователя, информация о предыдущем шаге работе и др.
Запросы с соединением таблиц, внешних для ТПР может иметь невыгодный план
запроса. Намного выгодней выполнить несколько простых запросов к одиночным
таблицам с временным сохранением результатов и последующей генерацией
динамического запроса, на основе этих данных.
Приведём пример сгенерированного запроса, для поиска продукции,
соответствующей комбинации ответов пользователя, где ответы заранее извлечены в
одномерный массив:
actions, aftereffect FROM decisionsysname = 'Medicine' AND
Domain = 'Diagnostics'Subdomain ='Breathing System' AND table_id = 1( (
('yes'='yes') OR 'yes'='_') AND( ('no'='no') OR 'no'='_')( ('yes'='yes') OR
'yes'='_') );
Здесь подчёркнутые «yes» и
«no» - элементы массива, содержащего
ответы пользователя на поставленные условия, хранящиеся в отдельной таблице
базы и извлечённые заранее.
Классическая логика, по определению, не может оперировать с нечетко
очерченными понятиями, поскольку все высказывания в формальных логических
системах могут иметь только два взаимоисключающих состояния: «истина» со
значением истинности «1» и «ложь» со значением истинности «0».
Одной из попыток уйти от двузначной бинарной логики для описания
неопределенности было введение Лукашевичем трехзначной логики с третьим
состоянием «возможно» со значением истинности «0,5». Введя в рассмотрение
нечеткие множества, Заде предложил обобщить классическую бинарную логику на
основе рассмотрения бесконечного множества значений истинности. В предложенном
Заде варианте нечеткой логики множество значений истинности высказываний
обобщается до интервала [0;1] , т.е. включает как частные случаи классическую
бинарную логику и трехзначную логику Лукашевича. Такой подход позволяет
рассматривать высказывания с различными значениями истинности и выполнять рассуждения
с неопределенностью.
Нечеткое высказывание - это законченная мысль, об истинности или ложности
которой можно судить только с некоторой степенью уверенности [0;1]: «возможно
истинно», «возможно ложно» и т.п. Чем выше уверенность в истинности высказывания,
тем ближе значение степени истинности к 1. В предельных случаях 0, если мы
абсолютно уверены в ложности высказывания, и 1, если мы абсолютно уверены в
истинности высказывания, что соответствует классической бинарной логике. В
нечеткой логике нечеткие высказывания обозначаются так же, как и нечеткие
множества: A, B, C … . Введем нечеткое отображение T: Ω→[0 ; 1] , которое действует на
множестве нечетких высказываний Ω=A, B, C… . В этом случае значение
истинности высказывания A∈Ω определяется как TA∈[0;1] и является количественной
оценкой нечеткости, неопределенности, содержащейся в высказывании A .
Логическое отрицание нечеткого высказывания A обозначается ¬A - это
унарная (т.е. производимая над одним аргументом) логическая операция, результат
которой является нечетким высказыванием «не A », «неверно, что A », значение
истинности которого:
Логическая конъюнкция нечетких высказываний A и B обозначается A∩B-
это бинарная (т.е. производимая над двумя аргументами) логическая операция,
результат которой является нечетким высказыванием «A и B», значение истинности
которого:
Помимо приведенного выше исторически принятого основного определения
логической конъюнкции (нечеткого «И»), введенного Заде, могут использоваться альтернативные
формулы, например:
A ∩ B = max (T A + T B − 1 ; 0) - в базисе Лукашевича-Гилеса;
Логическая дизъюнкция нечетких высказываний A и B обозначается A B - это
бинарная логическая операция, результат которой является нечетким высказыванием
«A или B», значение истинности которого:
Могут использоваться альтернативные формулы, например:
A B = min ( T A + T B ; 1) - в базисе Лукашевича-Гилеса;
Нечеткая импликация нечетких высказываний A и B обозначается A ⊃ B - это бинарная логическая
операция, результат которой является нечетким высказыванием «из A следует B »,
«если A , то B », значение истинности которого:
A B = max( (min T A ; T B) ; 1 − T A)
Помимо приведенного выше исторически принятого основного определения
нечеткой импликации, введенного Заде, могут использоваться следующие
альтернативные определения нечеткой импликации, предложенные различными
исследователями в области теории нечетких множеств:
A B = max (1 − T A ; T B) - Гедель;A B = min (T A ; T B) - Мамдани;A B = min (1 ; 1 − T A + T B)
- Лукашевич;A B = min (T A + T B ; 1)
- Лукашевич-Гилес.
Общее число введенных определений нечеткой импликации не ограничивается
приведенными выше. Большое количество работ по изучению различных вариантов
нечеткой импликации обусловлено тем, что понятие нечеткой импликации является
ключевым при нечетких выводах и принятии решений в нечетких условиях.
Наибольшее применение при решении прикладных задач нечеткого управления находит
нечеткая импликация Заде.
Так же, как в классической бинарной логике, в нечеткой логике с помощью
рассмотренных выше логических связок можно формировать достаточно сложные
логические высказывания [9].
В представленной работе нечёткие логики используются для нахождения
значимости полученного решения и определения приоритета в случае нескольких
решений: пусть, необходимо работать с предикатами, атрибуты которых имеют
разные значимости. На каждый основной атрибут вводится по одному
дополнительному атрибуту, хранящему его вес. Взвешенная сумма произведений весов
на признаки наличия атрибута (0 или 1), даёт значимость продукции, позволяющую
выбирать наиболее существенные из выделенных, обычно, нескольких продукций и
«отсекать» продукции, значимость которых ниже какого-либо установленного
порога.
Например, пусть исходная комбинация условий имеет вид:
условие_1&( условие_2|| ^условие_3),
где значимость первого условия равна 0.2, второго - 0.7, третьего - 0.6.
С учётом весов комбинация примет вид:
При условии, что & есть min(A;B), || - max(A;B), а ^ есть (1-A),
получим значение продукции равное 0.2.
Для более точного анализа можно применить расширенный ввод, использование
которого, позволит пользователю отвечать на поставленные условия не строго
«да»/«нет», но выставлять «показатель выраженности» условия, значения которого
также могут находиться в интервале [0;1].
Введём для предыдущего примера дополнительные показатели для 3х условий:
0.7, 0.8 и 0.2 соответственно. Тогда получим:
(0.2*0.7) & ( (0.7*0.8) || (0.6*0.2) ),
где значение продукции будет равно 0.14.
Общая схема приложения для СУБД Oracle приведена на рисунке 3.
Рисунок 3 - схема приложения для Oracle
Для хранения таблиц решения в УМД используются 2 таблицы: decision и
metadata. То есть, при добавлении новых таблиц принятия решений не требуется
создание новых таблиц для их хранения.
Таблицы data_users и data_clients содержат данные о пользователях и
«привязанных» к ним клиентах и служат для поддержки работы интерфейса.
Схема модели данных в Oracle приведена на рисунке 4. Условные обозначения
на рисунке: P - превичный ключ, F - внешний ключ.
Рисунок 4 - Схема базы данных в Oracle
Таблица data (рисунок 5) - хранит ответы клиента
на условия, пройденных таблиц решения. Также содержит имя системы, область,
подобласть, в которых работает клиент, его идентификационный номер. Данные в
таблицу заносятся в процессе работы клиента с системой: на соответствующей
странице интерфейса клиент отвечает на поставленные вопросы (условия в
соответствующей таблице принятия решений), после чего ответ автоматически
заносится в таблицу и обрабатывается системой для получения «ответа» (действия)
и возможного перехода на следующую таблицу.
Здесь:
sysname - название системы, domain - название области, subdomain - название подобласти, table_id - номер таблицы принятия решений, tablename - название этой таблицы, client_id - номер клиента,
condition_id - номер условия, condition_name - само условие, answer - ответ клиента на заданное условие, sid - суррогатный ключ. В случае ограниченного ввода ответы клиента имеют вид «yes», «no» или «_» (безразлично). На рисунке 6 приведён пример заполнения таблицы data с расширенным вводом, где значения поля answer характеризуют степень выраженности
условия.
Рисунок 6 - пример заполнения таблицы data
Таблица data_clients (рисунок 7) - содержит личную информацию о клиентах,
данные об областях в которых он работает, а также номер пользователя (является
уникальным), к которому он «привязан». Например, в случае постановки
медицинского диагноза, клиентом является пациент, а пользователем - доктор.
Таким образом, каждый клиент должен быть привязан к какому-либо пользователю.
Клиент в каждый момент времени может находиться только в одной системе,
области и подобласти. Учётная запись клиента создаётся пользователем, данные в
таблицу так же добавляются пользователем. При этом пользователь имеет право
редактировать данные только своих клиентов.
Данные о текущей таблице решения и номере продукции заносятся
автоматически в процессе работы с системой.
Здесь:
current_progress - номер текущей
таблицы решения
и номер продукции, dob - дата рождения,
home_city - город проживания, home_state - штат/область, home_street - улица, marital_status - семейное положение, name - имя,
next_visit - дата последнего посещения, sex - пол, user_id - номер пользователя, к которому привязан клиент, visit - первичный визит, basis_id и basis_name - id и название базиса
с которым
работает клиент. Базис
для каждого клиента устанавливается пользователем перед началом работы системы
и сохраняется до её окончания.
Таблица data_users (рисунок 8) - содержит личную информацию о всех
пользователях, работающих с системой: имя, адрес, id, названия системы, области
и подобласти, с которыми работает данный пользователь, а также логин и пароль
для входа в систему. Причём логин является уникальным и не может быть
одинаковым у разных пользователей. Данные пользователя заносятся в таблицу
автоматически при регистрации пользователя в системе. При этом пользователь
может находиться только в одной области и подобласти.
Таблица decision (рисунок 9) - хранит все таблицы
принятия решений, т.е. при добавлении новых таблиц решений не требуется
создание новых таблиц в базе для их хранения. Наборам ответов на условия,
хранящимся в столбце conditions, соответствуют наборы действий и последействий (actions и aftereffects).
Здесь: prod_id - номер соответствующей продукции, sid - суррогатный ключ, генерирующийся автоматически при
помощи триггера, conditions -
комбинация ответов на условия, actions
- содержит комбинацию действий, соединенные между собой логическим «И», aftereffect - последействие (переход на другую
таблицу/продукцию). Для столбца conditions допустимы логические операции: and
(&) и or (||).
Рисунок 10 - пример заполнения таблицы decision
Данные в таблицу decision заносятся администратором и не могут редактироваться пользователями и
клиентами.
Таблица metadata (рисунок 11) - содержит списки всех
условий и действий, соответствующих данной таблице принятия решений, названия
системы, области и подобласти, к которым принадлежит эта таблица, а также
вспомогательные поля для верного построения логического условия, такие как: type, определяющее «вид» ответа клиента: checkbox, в случае ограниченного ввода, и text, в случае расширенного ввода
(например, значение температуры); connection - определяет тип соединения данного условия с последующим («AND» или «OR»); brackets - наличие открывающей или закрывающей скобок. Для поддержки нечётких
логик используются следующий поля: condition_weight и action_weight - вес условий и действий, значения от 0 до 1; prod_limit - «порог» значения продукции, т.е. продукции,
значение которых ниже этого порога, не рассматриваются в дальнейшей работе
системы. Данные в таблицу также заносятся администратором и недоступны
пользователям и клиентам для редактирования.
Рисунок 12 - пример заполнения таблицы metadata
Таблица history (рисунок 13) - хранит историю работы
каждого клиента. Содержит последовательность переходов между таблицами принятия
решения, а также информацию о завершении работы с той или иной таблицей
принятия решений. Помимо номера таблицы, к которой осуществляется переход,
также хранится номер условия, с которого будет начата работа на следующем шаге
(по умолчанию имеет значение 1), номер продукции, по которой был осуществлён
переход, полученное при работе значение продукции и название базиса, в
соответствии с которым это значение рассчитывалось. Также присутствует поле reason, в которое выводится информация о
причинах принятого решения.
Последовательность шагов пользователя с системой может разветвляться и
принимать древовидную структуру, некоторые ветки могут «обрезаться» в
соответствии с порогом значимости, установленным для продукции.
Поля: status - статус работы с таблицей, step - номер шага, на котором
осуществлялась работа с таблицей.
Рисунок 14 - пример заполнения таблицы history(часть 1)
Рисунок 15 - пример заполнения таблицы history(часть 2)
Данные в таблицу заносятся автоматически, после нахождения набора действий,
соответствующего ответам клиента на заданные условия. Изначально статус работы
с таблицей имеет значение «nostarted». По завершении работы принимает значение «complete».
Информацию об области и подобласти, с которыми работает клиент, можно
извлечь из таблицы decision,
используя суррогатный ключ из столбца sid.
Таблица bases (рисунок 16) - содержит формулы
конъюнкции, дизъюнкции, отрицания и импликации в различных базисах, которые
используются для вычисления значимости продукции.
Поля: basis_id, formula_id - id базиса и одной из 4х формул, вместе образуют первичный ключ.
Basis_name - название базиса, например «базис Вебера», formula_type - тип описываемой формулы, принимает одно из четырёх
значений: «&»(and), «||»(or), «^»(not), «->»(implication). Поле formula
содержит непосредственно формулы соответствующих операций. Для унарных операций
в качестве обозначения переменной используется «А», для бинарных «А» и «В».
Каждую операцию над
Похожие работы на - Таблицы принятия решений в СУБД с табличной моделью данных Дипломная (ВКР). Информационное обеспечение, программирование.
Реферат: Некоторые особенности расследования преступлений связанных с дорожно-транспортными происшествиями
Реферат: Бишоп, Морис Руперт
Реферат по теме Понятие качества и организация системы управления качеством
Реферат: Развитие познавательной активности учащихся на уроках математики. Скачать бесплатно и без регистрации
Реферат по теме Минимальные социальные гарантии для работников в Украине
Отчет По Практике Месторождение
Курсовая Работа На Тему Деловой Этикет
Дипломная работа по теме Подготовка слабослышащих дошкольников к обучению в школе
Эпидемиология И Профилактика Аскаридоза Реферат
Реферат по теме Перспективы агропромышленного реформирования в РФ
Курсовая работа по теме Модель ефективності рекламної кампанії (на прикладі підприємства ЗАТ ВО 'Конті')
Реферат: Инновации и инвестиции в кинопроизводстве
Реферат: Новые признаки подлинности денег
Реферат: Сущность современной политической традиции
Отчет по практике: Бухгалтерский учет и его принципы на предприятии
Творческая Работа На Тему Великая Отечественная Война 1941-1945 Гг.
Реферат: Основной капитал: методы, способы и приемы натуральной и стоимостной оценки
Эссе Дар Бораи Модар
Проблемы Современного Образования В Рф Сочинение
Контрольная работа по теме Что такое пособие по временной нетрудоспособности и в каких случаях оно назначается. Как определяетс...
Похожие работы на - Термидорианский переворот
Реферат: Отклоняющееся поведение 2