Интеллектуальная система автоматизированного проектирования SQL запросов к базам данных

Содержание

1. Введение.

2. Постановка задачи проекта.

3. Технические требования к разрабатываемой  системе.

3.1.  Общие требования.

3.2. Требования к программному обеспечению оболочки интеллектуальных систем (ПОБ)

3.3.   Структура исходных  данных проекта. Цель проекта.

3.4. Правила формирования  цели проекта

4.  Структура системы управления  учебным процессом «Деканат»

5.  Теоретические основы  реализации поставленной задачи.

    5.1. Состав таблиц, полей  и связей.

5.2 Пользовательский интерфейс. Структура пользовательского представления знаний

5.3 структура внутреннего представления  знаний.

    5.4. Технологии проектирования  системы

6.Разработка алгоритма вывода решения.  Логика управления алгоритмом  вывода решения (пополнения знаний)

6.1.Доказательство истинности предлагаемого решения.

6.2  Алгоритм управления проектом

6.3  Алгоритм объяснения полученного решения

7.   Алгоритм проектирования пакета SQL запросов реализации поставленной цели.

7.1. Структурная схема системы МИРА

8.  Интеллектуальный Интерфейс системы

9. Заключение.

10. Список используемой литературы.

Интеллектуальная система  автоматизированного проектирования SQL запросов к базам данных.

 

Аннотация

В курсовой работе рассматривается  структура базы знаний предметной области  управления базами данных, алгоритма  вывода решений и проектирования пакета SQL запросов.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Введение.

 

База знаний

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

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

Иерархический способ представления в базе знаний набора понятий и их отношений называется онтологией. Онтологию некоторой области знаний вместе со сведениями о свойствах конкретных объектов также можно назвать базой знаний.

Применение баз  знаний

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

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

 Базы знаний  и интеллектуальные системы

Двумя наиболее важными  требованиями к информации, хранящейся в базе знаний интеллектуальной системы, являются:

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

Ниже перечислены  некоторые из особенностей, которые  могут (но не обязаны) быть у системы, оперирующей базами знаний.

• Автоматическое доказательство (вывод). Способность системы выводить новые знания из старых, находить закономерности в БЗ. Часто принимается, что база знаний отличается от базы данных именно наличием механизма вывода.
• Доказательство заключения. Способность системы после выдачи ответа «объяснить» ход её рассуждений, причем «по первому требованию».
• Машинное обучение. Превращение БЗ в гибкую систему, адаптация к проблемной области. Аналогична человеческой способности «набирать опыт».

 

 

2.Постановка задачи.

 

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

Разрабатываемая интеллектуальная система  проектирования запросов к локальным базам данных должна обеспечивать:

• Интеллектуальный интерфейс  с пользователями имеющих ограниченные  возможности по здоровью.
• Автоматизированное проектирование SQL запросов стандартных видов структуры которые оговорены ниже.
• Автоматическое пополнение знаний системы о предметной области проектирования в процессе эксплуатации системы
• Проектирование SQL запросов для заданной СУБД
• Операционных средств Windows Начиная с версии 2000.

 

 

 

 

 

3. Технические требования к разрабатываемой системе.

 

1. Класс сетевого управления – локальный
2. Уровень информационной безопасности – конфиденциальный
3. Интерфейс с глобальными сетями (INTERNET) – отсутствует
4. Время выполнения запроса произвольной сложности не должно превышать 5 сек.
5. Система должна обеспечивать только выполнение прогнозируемых запросов к базе данных в предметной области управления учебным процессом.
6. Функционирование системы должно происходить под управлением операционной системы WINDOWS XP и выше.

 

3. 1. Общие требования.

 

Разрабатываемая система после её реализации войдет в качестве составной части информационной системы управления учебным процессом -«Деканат».

По всем составным частям системы  ДЕКАНАТ предъявляются общие  требования по составу операционных и инструментальных средств:

1. ОС Windows XP, Windows Vista;
2. Инструментальная система проектирования баз данных- ErWin;
3. Модель физической базы данных- Microsoft Access 2007
4. Инструментальная система проектирования приложений – DELPHI 7.

 

 

 

3.2. Требования к программному  обеспечению оболочки интеллектуальных  систем (ПОБ)

 

Программное обеспечение  оболочки для использования в  системе МИРА должно обеспечивать:

• Поддержку фреймовой и продукционной модели базы знаний;
• Поддержку табличного представления знаний и их внутреннего (фреймового) представления;
• Реализацию алгоритмов поиска решений в глубину и ширину;
• Пошаговую регистрацию шагов алгоритма поиска решений.

 

3.3.   Структура исходных  данных проекта. Цель проекта.

В целях сокращения объемов  информации  в исходных  данных  на проектирование предлагается цель проекта представлять в виде структурных компонентов:

• Цель проекта проектирования содержащую идентификационное имя цели, структуру результата и вид его представления.
• Условия на выбор информации из базы данных с дополнительными функциями его обработки.

При этом цель проекта  в случае наличия  в базе знаний информации о поставленной цели может не содержать структуру  результата.

Раздел  условие формируется по правилам стандарта SQL 2003

 

 

 

 

 

 

3.4. Правила формирования  цели проекта

 

1. Цель проекта  задается в виде структуры, элементами которой являются:

• Идентификатор цели (например – экзаменационная ведомость)
• Идентификатор первой сущности (IS1)
• Список полей первой сущности (SP1)
• Идентификатор второй сущности (IS2) связанной с первой
• Список полей второй сущности (SP2)  из которой должна быть произведена выборка полей.

И.т.д.

2. Сущности в структуре цели  должны быть указаны в порядке  их обработки.

3. Из каждой сущности, указываемой  в структуре должно выбираться  хотя бы одно поле.

4.  Цель проекта уточняется  на  этапе формирования  раздела условия  while SQL запроса.

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

 

 

 

 

 

 

 

 

 

                                           Ключ

(ECZBEDO 1)  (экзамен- ведомость) (ECZBEDO 1)( курс, группа,                                                                 расписание. дисциплина,  семестр. Преподаватель, дата, студент.

                         № зачетной книжки, фамилия, оценки, оценка  15-балл., оценка  5-балл.,Группа = ‘   ’ ORDER BY фамилия)

                      

 

 

 

 

 

 

                                                              Результат выполнения запроса

SQL запрос

 

 

 

 

 

 

          Сущность поля     Плохо     Хорошо Сущность поля

 

 

 

 

 

 

 

 

Рис. 3.1  Организация интерфейсов  для пользовательского представления цели.

4.  Структура системы управления «Деканат»

 

 

 

 

Требуется уточнение 

      цели

                         нет                                 да

 

 

 

 

 

 

5.1. Состав таблиц, полей и связей

 

Состав  таблиц БЗ, требуемых для проектирования будем определять исходя из:

• Функциональной необходимости поля (атрибута) в документе;
• Объединение полей в таблице, исходя из правил нормализации;
• Минимальной избыточности данных в таблице;
• Возможности функциональных связей реализуется таблицами через вторичные ключи.

С учетом изложенного и выполненной нормализации, БЗ можно представить в виде следующих связанных таблиц, изображенных в виде ErWin - диаграммы:

 

Рисунок 5.1 «Логическая схема спроектированной базы данных»

 

Функциональное  назначение и имена этих таблиц приведены  в таблице 5.1:

Таблица 5.1 «Функциональное назначение и  имена таблиц»

 

 

1	Имя таблицы	Содержание
2	Студент	Анкетные данные студента.
3	Дисциплина	Распределение учетных дисциплин  по семестрам и специальностям.
4	Расписание	Расписание экзаменов
5	Оценки	Результаты зачетно - экзаменационной сессии студента.
6	Курс - группа	Данные о семестре обучения и специальности  студента

 

 

 

Уровень пользовательских интерфейсов с  системой должен быть ориентирован на пользователей без специальной  подготовки.

Структура спроектированной БД изображенном на рисунке 5.1  прошла моделирование в системе ERWin.

 

 

 

 

 

 

 

 

 

5.2 Пользовательский интерфейс. Структура пользовательского представления знаний

 

Пользовательский  интерфейс.

Основным требованием к разрабатываемому интерфейсу является  наличие интеллектуальной поддержки пользователя.

Определим  основные положения  и требования этой поддержки

Прежде всего этот интерфейс должен обеспечивать пользователю …--…

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

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

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

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

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

 

 

Структура БЗ (пользовательское  представление)

Номер элемент	ИД лев. табл	Список полей лев. Табл.	Имя правой табл.	Список полей правой табл.	Предикат	Операн.	Список полей	Оператор	Метка перехода	ИД Прогр. Обраб.
	Т1       T1	P1 P2     P1 P2	T2	P5 P6	=	JOIN       SELECT	P5 P6 P7 P8 P1 P2

 

<Номер элемента списка>:=<сквозной  номер  во все структуры>

<оператор>:=<BREAK>

<ИД программы обработки>:=<ИД  программы форм>

 

Кол-во структурных элементов:

• Цели, реализуемые системами
• Структуры выхода запроса
• Последовательность обработки
• Правила обработки
• Структуры входа SQL запросов
• Структуры условий запроса
• Дополнительные функции
• Структура таблиц БД

Структура Выход запроса заполнительной функции

№	Операция запроса обработки	ИД поля сортировки	Имя табл.
1	ORDER BY	P1 P2 P8 P9	T1 T1 T2 T3
2	GRUPP BY	P1 P8	T1 T2
3	HAVING

Структура Выход запроса

№	Имя поля	Имя табл.	Имя места рез-та	ИД цели (задачи)	СУБД
	P1 P2 P3 P8 P9	T1 T2 T1 T2 T3	REZ1	Экз.ведомость	FoxPro

 

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

Структура УСЛОВИЕ определяется из пользовательского  интерфейса (вводит сам пользователь).

Система  поиска формирует список возможных  вариантов полей ввода.

Список  дополнительных функций  определяется системой из базы знаний.

 

Структура БД

-содержит  функциональные связи таблиц  и условия этих связей во  всей БД

 

Функции обработки  БЗ

• SELECT – проектирует запросы на поиск строк с заданным условием им без в одной таблице
• SELECT-JOIN – проектирует раздел вход запроса на соединение двух или нескольких таблиц без предварит. Поиска строк от первой таблицы
• DOPFUNC –проектирует дополнит. Функции к разделу УСЛОВИЕ (ORDER BY;GRUPP BY;HAVING)
• SELJOIN – проектирует составляет запрос с предварительным поиском строк из первой таблицы по условиям  соединения рез-та с одной или несколькими таблицами.
• PROREL – проектирует фрибс  «послед.  Обработки». На основании заданий структуры док-т и исходных табл.БД
• PROOUT – проектирует фрибс  «структур выход» на основании заданий структуры док-та и структуры SQL-запроса (простой, составной)

 

 

 

 

 

Технология создания и пополнения базы знаний.

• В предлагаемой системе определено следующее распределение обязанностей среди персонала, задействованного в процессе эксплуатации системы:
• Пользователь – определяет цели в виде названия проектируемого документа, его структуры, условий на обработку и дополнительных функций по преобразованию документа
• Проектировщик БЗ – определяет и разрабатывает алгоритмы-функции (процедуры обработки фреймов) фреймы-правила и структуру БД-фрейм.
• Фреймы 2,3,5,6,7 (Выход, последовательность, вход, УСЛОВИЕ, дополнительные функции) формируются             БЗ с помощью процедур обработки фреймов. Исходные данные для реализации  этапа подготавливает аппарат логического вывода БЗ, использующий алгоритмы  поиска в ширину и глубину.
• Таким образом, технология создания БЗ можно определить как последовательность шагов обучения, в процессе которых проектирующая и пополняющая разделы фреймов по мере поступления от пользователей все новых и новых целей.

 

 

 

 

 

 

 

 

 

5.3 структура внутреннего  представления знаний.

 

 

              ключ

 Курс, расписание.           Join , группа, группа.

Расписание, студент       Join , группа, группа.

Студент, оценки               Join , № зачетной книжки, № зачетной книжки

 

 

                      

 

 

 

 

 

 

                                                              Результат выполнения запроса

SQL запрос

 

 

 

 

 

 

 

 

 

 

 

Рисунок 5.3. Схема взаимодействия с  системой.

 

 

5.4. Технология проектирования системы

 

 

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

• невозможность точного (формального) описания процесса управления;
• значительное количество приложений базы данных (≥ 30);
• постоянный ввод новых приложений (>5 в год).

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

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

• программное обеспечение приложений - заменяется их упрощенными моделями при отсутствии на данный момент;
• программное обеспечение диспетчера (или любой программы верхнего уровня) - не корректируется, а производится только замена упрощенной модели на реальное ПО.

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

 

 

 

Спиральная модель жизненного цикла информационной системы

 

 

 

 

Преимущества спиральной модели

 

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

Рассмотрим преимущества итерационного  подхода более подробно.

-    Итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика.

 

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

 

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

 

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

 

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

 

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

 

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

 

 

 

 

 

 

 

 

Недостатки спиральной модели

 

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

6.  Разработка алгоритма вывода решения. Логика управления алгоритмом  вывода решения (пополнения знаний).

 

Разработка алгоритма  вывода решения.

Представим предложенную структуру  в виде входящих в нее элементов  и определим действия системы  по её анализу.

Анализ необходим для разработки правил принятия решения о структуре  проектируемого запроса.

Цель : = IS1,SP1, IS2,SP2….. ISi,SPi.

Выполняемый анализ дал следующие  результаты:

Правило 1

If  (IS1 UIS2)=R. AND (SP1 ∩ SP2)= to execute uniIn else execute правило 2

Правило 2.

If  (IS1 UNULL )=R. AND (IS2=NULL)= to execute select else execute правило 3

Правило3.

If  (IS1 UIS2)=R1. AND (SP1 ∩ SP2)=0 to execute join IS3 ≠ NULL to execute правило 4

Правило4.

If  (IS2UIS3)=R2. AND: (SP2 U SP3)=0 to execute join  else execute правило 5

Правило5.

If  (IS1 UIS2)=R. AND (SP2 U SP1)=0 to execute join else execute  выводсообщенияпользователя – «Уточнитеструктуруцели»

Правило6. 

‹Идентификатор  цели› execute  Э ‹фрейм целей› elseexecute   переход и обработка фрейма типовое решение вывод сообщения «база знаний не содержит сведений о заданной цели. Вам необходимо  задать структуру цели.»

 

 

Логика управления алгоритмом  вывода решения (пополнения знаний).

 

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