2.7. Создание, загрузка и проверка бд

Реализация, загрузка и проверка БД зависит от возможностей выбранной для рализации СУБД и предоплагает последовательное выполнение следующих процессов:

1. Реализация БД

   1. Разработка текста программы структуры БД на языке SQL

   2. Создание БД

   3. Проверка структуры БД и таблиц.

2. Процесс загрузка и проверка БД

   1. Подготовка и описание массиваданныз для загрузки в БД (не менее четырёх записей для каждой таблицы). Вставляется в текст пояснительной записки в виде таблиц Excel.

   2. Написание скрипта загрузки БД

   3. Загрузка данных в БД

   4. Проверка содержимого БД после загрузки данных.

Созданные таблицы документируются и выводятся на экран либо с помощью средств СУБД, либо с помощью скриншотов.

2.8 Проверка бд на прецедентах

Решение с использованием физической БД разработанных ранее прецедентов с использованием языка запросов SQL. В данном разделе должны быть приведены SQL запросы к БД и скриншоты полученных результатов.

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

База знаний состоит из двух частей: экспертной системы и онтологии.

3.1. Прецеденты использования базы знаний предметной области

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

Для базы знаний прецеденты описывают вопросы к базе знаний и ответы базы знаний на них. Количество прецедентов не менее 7, упорядоченных по мере возрастания сложности вопросов.

3.2 Проектирование экспертной системы

Экспертная система проектируется как продукционная система описания правил в рамках предметной области. Продукционная система использует понятия предметной области выделенные в пером разделе для формирования множества правил вывода в рамках данной предметной области. Естественно, что разработанная ЭС должна покрывать прецеденты использования БЗ.

Экспертная система оценивается по следующим параметрам:

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

• Её непротиворечивость – отсутствие явно взаимоисключающих правил, не являющихся спецификой предметной области.

• Лаконичность описания – отсутствие дублирования и выделение наиболее значащих продукций.

• Целесообразность БЗ – возможность БЗ решить поставленную перед данным типом экспертной системы задачу. Например, способность БЗ решить задачу классификации.

Результатом проектирования экспетной системы должно быть множество правил вывода, записанных в форме ЕСЛИ-ТО.

См. следующие источники:

• Лабораторную работу №2 в качестве руководства для построения ЭС.

• Введение в технологию экспертных систем.pdf в папке с курсовой работой или онлайн (ссылка)

3.3 Разработка онтологии

Активная часть предметной области, используемая для решения поставленной задачи, служит основой для построения онтологии базы знаний. Под "онтологией" понимается множество терминов (понятий), используемых в предметной области; правила говорящие о том, как эти понятия могут быть скомбинированы и размещены в этой предметной области, чтобы отразить адекватное описание предметной области; и «санкционированные выводы», которые могут быть сделаны, когда такие утверждения использованы в домене. Т.е. онтология - формализованная и описанная часть предметной области, достаточная для построения базы знаний по задаче. Онтология не должна содержать ВСЕ возможные знания о предметной области, а только необходимые. Не требуется уточнять или обобщать более, чем необходимо. Не требуется включать все возможные свойства классов

Онтология проектируется в системе Protege в виде фреймовой модели и согласуется с моделью предметной области разработанной в разделе 1. Для построения модели знаний в Protege см. Лабораторную работу №4 и руководства по разработке онтологий в Protege.

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

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

Шаг 1. Определение области и масштаба онтологии

• Какую область будет охватывать онтология?

• Для чего мы собираемся использовать онтологию?

• На какие типы вопросов должна давать ответы информация в онтологии?

• Кто будет использовать и поддерживать онтологию?

• Онтология не должна содержать ВСЕ возможные знания о домене

  • o не требуется уточнять или обобщать более, чем необходимо

  • o не требуется включать все возможные свойства классов

Шаг 2. Определение классов и иерархии классов

• Нисходящая разработка

  • Начиная с общих понятий

• Восходящая разработка

  • Движение от конкретных классов

• Комбинированная разработка

• Организация классов в таксономию (установка отношений наследования)

  • Класс может иметь множество суперклассов (множественное наследование)

  • Все родственные понятия в иерархии классов должны быть на одном уровне иерархии

  • Имена классов должны быть или все в единственном числе или все в множественном числе (Animal is not a kind-of Animals).

• Документация классов

Шаг 3. Определение свойств классов – слотов

Шаг 4. Определение фацетов слотов (ограничений на слоты)

• Количество значений (кардинальность)

• Свойства значений

  • Минимум, максимум

  • Значение по умолчанию

Шаг 5. Создание экземпляров

• выбрать класс,

• создать отдельный экземпляр этого класса

• ввести значения слотов.

Построенная онтология должна служить базой знаний для разработанной экспертной системы. Другими словами, все правила ЕСЛИ-ТО сформированные в рамках экспертной системы должны быть выводимы на базе знаний, в Protege.