Ю. А. Григорьев, Г. И. Ревунков - Банки данных

6. ПРОЕКТИРОВАНИЕ БАЗ ЗНАНИИ

Процесс проектирования баз знаний является слоэюным итеративным процессом решения таких задач, как определение состава представляемых знаний, решение вопросов их организации в базе, тестирование представ­ ленных знаний и др. В настоящей главе рассматриваются основные этапы и слооюившиеся на практике методы проектирования баз знаний, пример ав­ томатизации процесса проектирования БЗ.

6.1. Этапы проектирования баз знаний

Многие созданные к настоящему времени ЭС ориентированы на решение конкретных задач и сконструированы с использованием разно­ образных инструментальных средств. Однако к настоящему времени выделены основные принципы их построения, создаются технологии их построения.

Каждая конкретная ЭС является человеко-машинной системой. В ее разработке необходимо участие экспертов, инженеров по знаниям и конст­ рукторов.

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

Эксперт-профессионал обладает знаниями двух типов — вербализуе­ мые и невербализуемые. Вербализуемые знания выражаются словесно или письменно, с использованием различных графиков, схем; обобщаются в виде статей, монографий, научных отчетов.

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

Конструкторы — группа специалистов в области АС обработки дан­ ных, поддерживающих инструментальный пакет программ, и другие техно­ логические средства, на базе которых создается ЭС.

140

6.2. Методы проектирования баз знаний

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

Выделяют следующие основные технологические этапы разработки ЭС. 1. Этап взаимодействия инженеров по знаниям и экспертов. На этом

этапе формируется модель ПО, которая может включать в себя неформали­ зованные компоненты, однако в ней должны быть специфицированы:

все основные понятия ПО; атрибуты, их описывающие;

отношения, существующие между ними; множество правил, описывающих специфические знания в анализи­

руемой ПО (например, в форме продукции).

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

2.Этап взаимодействия инженера по знаниям и конструкторов. На этом этапе выполняется настройка инструментального пакета (так называе­ мой оболочки ЭС) на задачи ПО, выполняется загрузка собранных знаний в систему; создается макет экспертной системы и выполняется его тестирование.

3.Этап взаимодействия инженеров по знаниям, экспертов и конструк­ торов. На данном этапе создается промышленный образец ЭС.

4.Этап сопровождения и модификации ЭС.

От стадии макетирования до получения промышленного образца ЭС проходит следующие стадии.

1. Демонстрационный прототип (в базе знаний 50—100 правил). Сис­ тема решает часть задач, демонстрируя жизнеспособность подхода.

2.Исследовательский прототип (в базе знаний 200—500 правил). Сис­ тема решает все задачи, но неустойчива в работе.

3.Действующий прототип (в базе знаний 500—1000 правил). Система надежно решает все задачи на реальных примерах, но для сложных задач требуется много времени и памяти.

4.Промышленный образец (в базе знаний 500—1500 и даже до 3000 правил). Система обеспечивает высокое качество решений при минимиза­ ции требуемого времени и памяти.

6.2.Методы проектирования баз знаний

Внастоящее время основным «узким местом» при проектировании баз знаний ЭС является приобретение необходимых знаний для ЭС. Знания

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

141

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

ных знаний инженер по знаниям получает от эксперта. К настоящему вре­ мени уже сформировался ряд методов проектирования баз знаний, ориенти­ рованных на получение информации от экспертов. Рассмотрим их.

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

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

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

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

Описание задачи. Эксперт подготавливает описание типичных задач по ПО. Этот метод очень хорошо работает на задачах диагности­ ческого типа.

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

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

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

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

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

142

6.2.Методы проектировангт баз знаний

1.Цели и задачи разрабатываемой ЭС.

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

3.Специфицировать объекты (события) ПО, отношения и атрибуты.

4.Специфицировать причинно-следственные, родовидовые отноше­ ния, отношения типа часть—целое.

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

Отметим, что процесс концептуализации знаний — итерационный процесс.

После того, как концептуальные знания выявлены, выполняется про­ цесс их формализации. В результате получают формальное описание БЗ. Для этого инженер по знаниям, консультируясь с экспертами, выбирает модель представления знаний, соответствующую рассматриваемой пробле­ ме, и оболочку ЭС, поддерживающую эту модель. На входном языке систе­ мы выполняется описание концептуальных знаний. Однако полученная на этом этапе БЗ не гарантирует работоспособность системы (первый вариант является макетом будущей системы), поскольку обязательно будут иметь место различные несоответствия: между какими-либо правилами и страте­ гией управления процессом получения решения, между структурами дан­ ных. Эти противоречия и несоответствия должны быть устранены.

На стадии отладки и тестирования полученного прототипа будущей системы выполняется проверка его работоспособности на разнородных примерах. Оценить работу ЭС трудно, так как в подавляющем большинстве случаев не существует формального способа доказательства полученного системой решения. Кроме того, часто пользователю требуются не самые точные решения, а наиболее полезные с его точки зрения. Поэтому при про­ ектировании системы необходимо учитывать интересы будущих пользова­ телей и включать их как экспертов в процессе проектирования системы. Далее, с ростом объема базы знаний (когда число правил достигает не­ скольких сотен) добавление новых правил или исправление существующих зачастую приводит к появлению новых ошибок, число которых сравнимо с устраняемыми ошибками. Отладка и тестирование выполняются с исполь­ зованием контрольного набора задач, который желательно «прогонять» по­ сле каждого вносимого важного изменения в БЗ и в стратегии управления процессом решения задач. Помимо отладки на контрольном наборе задач используется прием регистрации используемых правил, которые приводят к конкретным заключениям. Затем выполняется анализ результатов регистра­ ции. Неиспользуемые правила указывают либо на неверные предпосылки в правилах, либо на ошибки в используемых стратегиях управления процес­ сом решения задач.

143

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

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

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

6.3.Автоматизация проектирования баз знаний

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

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

Конструкции БЗ создают и просматривают с помощью средств языка инженера по знаниям.

Одним из наиболее широко распространенных способов экспертизы являются высказывания (сообщения) эксперта об объектах и событиях предметной области:

(имя объекта 1) (имя отношения) (имя объекта 2).

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

Ф] — а характерно для Ъ\ Ф2 — а наблюдается при Ь\ Фз — а отмечается при Ь\ Ф4 — а есть проявление Ъ\ Фз — а есть признак Ъ\ Фб — а сопровождает Ь\

Фп — ^ нередко сопровождается Ъ\ Фз — при а нередко присутствует Ъ\ Ф9 — а может наблюдаться при Ъ\ Фю — а обычно сопровождается Ъ\ Фп — при а, как правило, Ъ\ Фп — при а, обычно, Ъ\

Фп — а иногда сопровождается Ъ\ Фи — а часто сопровождается Ъ\ Ф\ь — а исключает Ъ\

144

6.3. Автоматизация проектирования баз знаний

Ф\в — а приводит к Ь; Фп — при а возникает Ь;

Oi8 — а может привести к Ь; Ф\д — а может развиваться в Ь; Ф20 — с (7 начинается Ь;

Ф21 — b развивается при а;

Ф22 — b может развиваться при а; Ф23 — b может начаться с а.

Этот список не окончательный и может дополняться.

Смысл высказываний уточняется построением конъюнкций форм. Каждая форма может иметь различный смысл, поэтому для уточнения смысла рассматривается прямое высказывание с обратным, т.е. если для некоторых значений а и b справедливо высказывание формы Ф,, то необхо­ димо попытаться установить, какое из высказываний форм Ф]—Ф23 спра­ ведливо при замене а на b и b на. а. Так выполняется построение конъюнк­ ций форм Ф1...Ф23. Такие конъюнкции форм названы типами сообщений. Возможны следующие типы сообщений:

Т] — а есть проявление Ь,и b может сопровождать а; Т2 — а есть проявление Ь,и b сопровождается а;

Тз — а может увеличивать возможность Ь,и b увеличивает возможность а; Т4 — а может сопровождаться Ь,нЬ может быть проявлением а;

Ts — а сопровождается Ь,и b может быть проявлением а; Тб — а есть проявление Ь,и b есть проявление а;

Ту — а может увеличивать возможность Ь, и b может увеличивать возмож­ ность а;

Tg — а может протекать с Ь,и b может протекать с а;

Тд — а увеличивает возможность Ь,н b увеличивает возможность а; Тю — ^ сопровождается Ь,и b может сопровождаться а;

Т\\ — а сопровождается Ь,и b сопровождается а; Ti2 — а приводит кЬ,и b исключает а;

Ti3 — а приводит к Ь',

Ti4 — а может привести к Ь;

Ti5 — а увеличивает возможность развития Ь;

Т|6 — а может увеличить возможность развития Ь; Ti7 — а исключает возможность развития Ь.

С каждым типом сообщения связывается бинарное отношение на множе­ стве объектов — формальная конструкция базы знаний — /?/(/ = 1, 17). С помощью этих отношений можно строить семантические сети.

Процесс выявления знаний связан с целым рядом трудностей. Прежде всего, это связано с существованием «когнитивной защиты», понятие кото­ рой основано на теории личностных конструкторов, выдвинутой Келли (G.A. Kelly). Чем выше когнитивная сложность субъекта (т.е. чем шире его

145

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

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

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

Стратегия «разбиения на ступени» выявляет структурные и классифи­ кационные свойства понятий (объектов, событий) ПО и реализуется одним из двух сценариев диалога, который выбирается экспертом:

1)сценарий «имя — свойство»;

2)сценарий «множество имен — свойство». Схема сценария «имя — свойство» следующая:

1)вопрос об имени объекта (события);

2)вопрос об имени свойства;

3)вопрос о существовании множества значений для данного свойства (ответ, типа «да — нет»);

4)вопрос о типе множества значений по данному свойству (дискрет­ ное или непрерывное);

5)вопрос о единице измерения по данному свойству;

6)вопрос о множестве значений по данному свойству;

7)вопрос о характерном подмножестве значений по данному свойству для описываемого события.

Если ответ на вопрос 3 отрицательный (нет), то имя свойства воспри­ нимается как имя события, и если событие с таким именем в БЗ отсутствует, то оно рассматривается как новое, и для него выполняется опрос по вопро­ сам 2—7.

После получения ответов на вопросы 2—7 создаются глобальный объект «имя свойства» и область его значений. Совокупность таких объек­ тов образует базис свойств ПО.

После получения ответа на вопрос 7 один из элементов базиса свойств связывается с описываемым событием.

Схема сценария «множество имен — свойство» заключается в много­ кратном повторении вопроса 1, а затем в получении ответов на вопросы 2—7 для каждого имени события.

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

146

7. ДАТОЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ

Рассмотрение приемов датологического проектирования БД выполне но на примере СУБД MS ACCES 97, Материал этой главы моэюно исполь­ зовать в качестве методических указаний к лабораторному практикуму п данному курсу. Однако при проведении практикума моэюно использовать другие имеющиеся в распоряэюении версии СУБД MS ACCESS. Пред­ полагается такэюе, что студенты свободно владеют приемами работы операционными системами Windows 98 или Windows 95.

7.1. Модель данных СУБД MS ACCESS

Microsoft Access является одной из популярных систем проектирова­ ния и сопровождения БД, она представляет собой полнофункциональную СУБД, в которую входят таблицы данных, экранные формы для ввода данных в эти таблицы, запросы и отчеты для получения новой информации по данным из таблиц, макросы и модули для дополнительного програм­ мирования (рис. 7.1).

148

7. /. Модель данных СУБД на примере MS ACCESS

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

Механизм ссылочной целостности в настоящее время является обще­ признанным для использования в реляционных моделях для реализации функциональных бинарных связей типа 1:1 или 1 :М между связанными таб­ лицами. Он соответствует бинарному групповому отношению при опреде­ лении БД в терминах групп и групповых отношений (см. п. 2.3). Этот меха­ низм основан на методе представления бинарной связи между сущностями через атрибут: первичный атрибут схемы исходной (родительской) сущно­ сти включается как вторичный атрибут в схемы атрибутов подчиненной (дочерней) сущности.

В системе управления БД MS ACCESS в рамках таблиц действуют механизмы определения и организации контроля стандартных правил цело­ стности данных в реляционных моделях (см. выше). Между таблицами дей­ ствует механизм описания и контроля ограничений ссылочной целостности для бинарных функциональных связей. В таблицах действуют также меха­ низмы определения и организации контроля явных ограничений целостно­ сти данных, таких, как форматы данных, допустимые диапазоны значений данных при вводе.

. Таким образом, сущности в базе моделируют таблицами. Свойства объектов (атрибуты) моделируют полями (столбцами таблиц). Один из ат­ рибутов сущности должен быть идентификатором — первичным ключом (например, табельный номер у сотрудника). Связи между сущностями мож­ но моделировать двояко: либо таблицей, либо с атрибутом (ссылочная це­ лостность). При этом обе таблицы, между которыми должна быть создана связь, должны иметь один и тот же атрибут, который эту связь и реализует. Только в одной из таблиц (родительской) он будет идентифицирующим атрибутом — первичным ключом, а в другой (подчиненной) — обычным атрибутом (в этом случае его называют вторичным ключом). И в обеих таблицах он должен иметь один и тот же тип данных (имя может разнится). Для представления бинарных связей типа М:М можно использовать либо таблицу, либо две функциональные связи: \:М и МЛ с промежуточной таблицей (прием описан выше в сетевой модели).

Схему БД для СУБД MS ACCESS проектируют с учетом перечислен­ ных особенностей, т.е. реализуют этап отображения схемы инфологической

149