Глава 3. Общая схема интеллектуальной информационной системы

3.1. Основные компоненты интеллектуальной информационной системы (иис)

Архитектура ИИС представлена на рис. 3 1

Архитектура интеллектуальной информационной системы

Рис 3 1. Архитектура интеллектуальной информационной системы

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

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

На начальном этапе применения методов искусственного интеллекта к ИС наибольшее распространение получили экспертные системы (ЭС), т.е. компьютерные программы, имеющие дело с проблемами, для которых не существует непосредственно аналитических методов, но в которых они позволяют получить результаты. Первые экспертные системы разработаны для некоторых устоявшихся, хорошо определенных приложений, например, помощи химикам-органикам (ЭС ДЕНДРАЛ); в области медицины (например, MYCIN, INTERNIST/CADUCEUS, PUFF). На рис. 3.2 представлена типичная организация экспертной системы.

Логические выводы, возможности получения логических следствий и возможности решения проблем обычно бывают встроены в машину вывода ЭС. В литературе по искусственному интеллекту термин «решение проблем» относится к методологии поиска пути из начального состояния в целевое состояние. Техника решения проблем включает общий решатель проблем и поисковый алгоритм. Некоторые из таких алгоритмов имеют имена (например, А* алгоритм).

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

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

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

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

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

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

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

СЕЯИ, занимающая в этом арсенале средств особое место, позволяет пользователю общаться с ИС на естественном языке, т.е. реализует дружественный к пользователю интерфейс.

Рис. 3.2. Типичная организация экспертной системы

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

Развитие ЭС идет по следующим направлениям:

• связь ЭС с большими базами данных,

• перевод при помощи ЭС команд пользователя в запросы к базам данных,

• интеграция правил и самой базы данных в ИИС.

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

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

Рис 3.3. Схема интеллектуальной информационной системы

Для хранения данных в ИИС используются либо реляционные, либо для интегрированного хранения данных и знаний— объектно-ориентированные базы данных. На рис. 3.4 показана схема интеграции базы данных и базы знаний

Рис. 3.4. Интеграция базы данных и базы знаний

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

В общем случае схема реляционной базы данных — это пара R = (S, С), где S = {R₁(U₁),.., R,_n(U_n, множество схем отношений; С — множество функциональных зависимостей над S.

База данных над R — это множество отношений по одному для каждой схемы d = {г_1, ..,г_n} Функциональная зависимость (FD) над R есть предложение вида: R_i: X —> Y, где X и Y упорядоченные множества атрибутов из U_i. Если X и Y — упорядоченные множества, утверждения «=» (равно), «» (содержится в) справедливы, если они выполняются для соответствующих неупорядоченных множеств. FD — справедлива (валидна) в d, если и только если для любого кортежа t,s  r_i, если t[X] = u[X], тогда выполняется t[Y] = u[Y]

Зависимость включения идентификатора (ID) над S есть утверждение вида R_i[X]  R_j[Y], где 1≤ i,j ≤ n, где X и Y - последовательности атрибутов из R_i, и R_j соответственно такие, что X = Y. ID валидно в d, если и только если r_i,[X] есть подмножество r_j[Y]. Реляционная схема R находится в BCNF (нормальной форме Бойса—Кодда), если и только если для каждой FD :

X —>Y над R, X является суперключом R.

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

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

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

Классификация объединяет сущности, являющиеся абстракциями реальных объектов мира с общими характеристиками, в типы сущностей. Агрегация относится к абстракции, в которой отношения между компонентами-сущностями (на уровне экземпляров) или типов рассматриваются как единый тип сущности высшего уровня, например, агрегирование типов сущностей WORKER и MACHINE в тип сущности WORK-ASSIGNMENT или агрегирование типа сущности WORK-ASSIGNMENT и PART в тип сущности PRODUCTION.

Генерализация означает абстракцию, в которой множество аналогичных типов сущностей рассматривается как родовой тип сущности, например сущность EMPLOYEE есть генерализация типов сущностей SECRETARY и WORKER. Ассоциация (покрытие, группировка) — это форма абстракции, в которой отношение между множеством сущностей более высокого уровня, например, группировка рабочих мест в проектную группу моделируется группировкой типа сущности PROJECT-TEAM, экземпляры которой — множества сущностей, извлеченные из набора данных EMPLOYEE. В распределенных информационных системах пользователи не только заинтересованы в значении данных универсума дискурса, т.е. семантике данных, но и в операциях, которые могут быть произведены над этими данными. Абстрактные типы данных, описьшающие структуры данных специфического типа вместе с множеством видимых извне операций (действий), определенном на этом типе сущностей, называются классом объектов. Логические формулы используют пре- и пост- условные клозы из множества действий над базой данных, определяя условия, при которых действия будут выполнены успешно.

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

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

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

Мы называем схему базы данных R объектно-ориентированной, если и только если для каждой схемы отношения R множество всех FD, относящихся к R эквивалентно одной единственной FD.

К —> R, т.е. факт, что К есть уникальный ключ R. Атрибуты, которые являются (не являются частью) ключа, называются первичными (непервичными).

Объектно-ориентированная схема базы данных может быть записана как множество пар (К_i, Р_i,), где К_i — множество первичных атрибутов; Р_i — множество непервичных атрибутов реляционной схемы R_j. Такую схему базы данных можно рассматривать как множество объектов, идентифицированных их ключами.

В случае если множество ограничений С не содержит зависимости включения, С пополняется ID, которые вновь экстрагируются из словаря данных и знаний администратора базы данных. Зависимость включения R_i [x] с R_i[Y] называется основанной на ключе, если Y = К_j, т.е. Y есть ключ R_i. Зависимости включения формируют утверждения относительно зависимостей между классами объектов. Следовательно, они являются основой для генерации иерархии, агрегации, генерализации и группировки, которые определяют отношения между классами в ООБД. С другой стороны, неключевые зависимости включения устанавливают произвольные ограничения целостности, которые мы должны усилить пре- и постусловиями базовых действий, связанных с ООБД-классами объектов.

Основанные на ключах зависимости включения могут быть далее классифицированы согласно отношения X по отношению к ключу К_j из R_i.

Тип 1:Х=К_i

{х есть ключ R_i}

Тип 2: ХР_i

{X состоит из непервичных атрибутов R_i}

Тип 3:ХК_j, ХК_i

{X состоит из первичных атрибутов R_i, но не является ключом}

Тип 4: все остальное.

Пример реляционной базы данных.

parts I (Р#, Name, Price)

parts2 (P#, Number-ordered, Number-instock)

employees (E#, Name, Address, Salary, Job-Type)

secretaries (E#, Typing-Speed)

workers (E#)

machines (M#, Value, Mach-Name, Bought-from)

dealers (D#, Name, Address)

work-assignments (E#, M#, Hours)

production (E#, M#, P#, Quantity)

project-team (E#, J#)

Ключевые атрибуты подчеркнуты. Множество функциональных зависимостей равно множеству ключевых зависимостей.

Определение класса объектов и их организация в пределах иерархии генерализации вытекает из анализа идентификаторов класса типа 1 (IDS): все схемы отношения, среди которых идентичность класса объектов может быть выведена, отображаются в один ООБД класс объектов. Идентичность класса объектов может быть выведена между схемами отношений R₁ и R₂ если и только если два идентификатора класса типа 1 IDS вида R_i[K_i]R_j[K_j] и R_j[K_j]  R_i [K_i] выполняются, в этом случае R_i и R_j, отображаются в тот же самый ООБД-класс объектов О_1. В нашем случае при данных идентификаторах ID#1 и #2, реляционные схемы «parts 1» и «parts 2» отображаются в класс объектов PARTS.

Таблица 3.1