Структура системи баз знань

ПОНЯТТЯ СИСТЕМИ БАЗ ЗНАНЬ

БАЗИ ЗНАНЬ

Аналогічно СБД (система баз даних) існує поняття СБЗ - система баз знань. Близькими поняттями є: експертна система - система, що забезпечує створення і використання за допомогою комп'ютера баз знань експертів; система штучного інтелекту. Останнім часом, однак, перевага віддається термінам, що підкреслює знання, а не інтелект. Такі системи демонструють шаблонне використання знання, а не інтелекту, які передбачає творчий підхід, нешаблонность.

Це відповідає і точному перекладу англійської назви таких систем - Knowledge Based Systems (KBS) - система, що базується на знаннях.

Система баз знань - система, що дає можливість використовувати відповідним чином представлені знання за допомогою обчислювальної машини.

Компоненти Системи баз знань (СБЗ):

• база знань

• механізм отримання рішень

• інтерфейс

Механізмом отримання рішень (inference engine - машина виведення) - це пряме використання знань із бази знань для вирішення задач - тобто процедура пошуку, планування та вирішення. Механізм вирішення дає можливість витягати з бази знань відповіді на питання, отримувати рішення, формулируемого в термінах понять, що зберігаються в базі. Приклади запитів:

• знайти об'єкт, що задовольняє заданій умові;

• які дії потрібно виконати в такій ситуації і т.д.

Інтерфейс - забезпечує роботу з базою знань і механізмом отримання рішень на мові високого рівня, наближеному до професійного мові фахівців в тій прикладній області, до якої належить СБЗ.

Якщо уважно придивитися до того, що реально зберігається в базі даних, то можна помітити наявність трьох різних видів інформації. По-перше, це інформація, що характеризує структури користувальницьких даних (опис структурної частини схеми бази даних). Така інформація у випадку реляційної бази даних зберігається в системних відношеньах-каталогах і містить головним чином імена базових відношень і імена, і типи даних їх атрибутів. По-друге, це власне набори кортежів користувальницьких даних, що зберігаються в певних користувачами відношеньах. Нарешті, по-третє, це правила, що визначають обмеження цілісності бази даних, тригери бази даних і подаються (віртуальні) відношення. У реляційних системах правила знову ж зберігаються в системних таблицях-каталогах, хоча плоскі таблиці далеко не ідеально підходять для цієї мети.

Експоненціальна і інтенсіональна часини бази даних

Інформація першого і другого виду в сукупності явно описує об'єкти (сутності) реального світу, модельований в базі даних. Іншими словами, це явні факти, надані користувачами для зберігання в БД. Цю частину бази даних прийнято називати екстенсіональною.

Інформація третього виду служить для керівництва СУБД при виконанні різного роду операцій, що задаються користувачами. Обмеження цілісності можуть блокувати виконання операцій оновлення бази даних, тригери викликають автоматичне виконання специфікованих дій при виникненні специфікованих умов, визначення уявлень викликають явну або непряму матеріалізацію представляються таблиць при їх використанні. Цю частину бази даних прийнято називати інтенсіональною; вона містить не безпосередні факти, а інформацію, що характеризує семантику предметної області. Як видно, в реляційних базах даних найбільш важливе значення має екстенсіональна частина, а інтенсіональна частина відіграє в основному допоміжну роль. У системах баз даних, заснованих на правилах, ці дві частини як мінімум рівноправні.

10.3. АКТИВНІ БАЗИ ДАНИХ

За визначенням БД називається активною, якщо СУБД по відношенню до неї виконує не тільки ті дії, які явно вказує користувач, але і додаткові дії відповідно до правил, закладеними в саму БД.

Легко бачити, що основа цієї ідеї містилася в мові SQL часу System R. Насправді, що є визначення тригера або умовного впливу, як не введення в БД правила, відповідно до якого СУБД повинна виробляти додаткові дії? Погано лише те, що насправді тригери не були повністю реалізовані ні в одній з відомих систем, навіть і в System R. І це не випадково, тому що реалізація такого апарату в СУБД дуже складна, накладна і не повністю зрозуміла.

Серед питань, відповіді на які досі не отримано, наступні. Як ефективно визначити набір допоміжних дій, що викликаються прямою дією користувача? Яким чином розпізнавати цикли в ланцюжку "дія-умова-дія-..." і що робити при виникненні таких циклів? В рамках якої транзакції виконувати додаткові умовні дії і до бюджету якого користувача відносити виникають накладні витрати? Маса проблем не вирішена навіть для порівняно простого випадку реалізації тригерів SQL, а завдання ставиться вже набагато ширше. По сутності, пропонується мати у складі СУБД продукционную систему загального вигляду, умови та дії якої не обмежуються вмістом БД або прямими діями над нею з боку користувача. Наприклад, в умова може входити час доби, а дія може бути зовнішнім, наприклад, виведення інформації на екран оператора. Практично всі сучасні роботи по активним БД пов'язані з проблемою ефективної реалізації такої виробничої системи.

Разом з тим, на нашу думку, набагато важливіше в практичних цілях реалізувати в реляційних СУБД апарат тригерів. Зауважимо, що в проекті стандарту SQL3 передбачається існування мовних засобів визначення умовних впливів. Їх реалізація і буде першим практичним кроком до активних БД (вже з'явилися відповідні комерційні реалізації).

10.4. ДЕДУКТИВНІ БАЗИ ДАНИХ

За визначенням, дедуктивна БД складається з двох частин: екстенціональної, що містить факти, і інтенціональної, що містить правила для логічного висновку нових фактів на основі екстенціональної частини і запиту користувача.

Легко бачити, що при такому загальному визначенні SQL-орієнтовану реляційну СУБД можна віднести до дедуктивних систем. Дійсно, що є певні в схемі реляційної БД уявлення, як не інтенціональна частина БД. Зрештою не так вже важливо, який конкретний механізм використовується для виведення нових фактів на основі існуючих. У разі SQL основним елементом визначення уявлення є оператор вибірки мови SQL, що цілком природно, оскільки результатом оператора вибірки є породжувана таблиця. Забезпечується і необхідна розширюваність, оскільки уявлення можуть визначатися не тільки над базовими таблицями, але і над виставами.

Основною відмінністю реальної дедуктивної СУБД від реляційної є те, що і правила інтенциональної частини БД, і запити користувачів можуть містити рекурсію. Можливість визначення рекурсивних правил і запитів дає можливість простого рішення у дедуктивних базах даних проблем, які викликають великі проблеми в реляційних системах (наприклад, проблеми розбирання складної деталі на примітивні складові). З іншого боку, саме можливість рекурсії робить реалізацію дедуктивної СУБД дуже складною і в багатьох випадках нерозв'язною ефективно проблемою.

Відзначимо, що зазвичай мови запитів і визначення інтенциональної частини БД є логічними (тому дедуктивні БД часто називають логічними). Є прямий зв'язок дедуктивних БД з базами знань (інтенціональна частина БД можна розглядати як БЗ). Яка ж зв'язок дедуктивних БД з реляційними СУБД, крім того, що реляційна БД є виродженим окремим випадком дедуктивної? Основним є те, що для реалізації дедуктивної СУБД зазвичай застосовується реляційна система. Така система виступає в ролі хранителя фактів і виконавця запитів, що надходять з рівня дедуктивної СУБД. Таке використання реляційних СУБД різко актуалізує завдання глобальної оптимізації запитів.

При звичайному застосуванні реляційної СУБД запити зазвичай надходять на обробку по одному, тому немає приводу для їх глобальної (межзапросной) оптимізації. Дедуктивна ж СУБД при виконанні одного запиту користувача в загальному випадку генерує пакет запитів до реляційної СУБД, які можуть оптимізуватися спільно.

Звичайно, у випадку, коли набір правил дедуктивної БД стає великий, і їх неможливо розмістити в оперативній пам'яті, виникає проблема управління їх зберіганням і доступом до них у зовнішній пам'яті. Тут знову ж таки може бути застосована реляційна система, але вже не дуже ефективно. Потрібні більш складні структури даних та інші умови вибірки. Відомі приватні спроби вирішити цю проблему, але спільного рішення поки немає.

10.5. ІНСТРУМЕНТАЛЬНІ ЗАСОБИ ПОБУДОВИ СИСТЕМ БАЗ ЗНАНЬ

Для створення СБЗ можуть використовуватися такі засоби:

• Традиційні мови програмування - С, Basic, Pascal, Lisp і ін Особливо в цьому ряду стоїть виділить мову функціонального програмування Lisp. Його основні властивості: дані представляються у вигляді списків, для отримання рішень використовується рекурсія.

• Мови представлення знань (такі як Prolog) - мають специфічні засоби опису знань і вбудований механізм пошуку виводу.

• Порожні оболонки експертних систем - містять реалізації деякої мови представлення знань і засобу організації інтерфейсу користувача. Дозволяють практично повністю виключити звичайне програмування при створенні прикладної експертної системи.

Приклад: Створимо експертну систему, за допомогою якої можна відрізнити птицю від літака. У наступній таблиці представлений масив факти, який фактично є в нашому випадку базою знань. У ньому перераховані деякі характеристики об'єктів "птах" і "літак", наявність даної характеристики і об'єкта зазначено цифрою 1, відсутність - 0.

Таблиця 10.1. Масив факти

Характеристика	Птах	Літак	RULES
Крила
Хвіст
Дзьоб
Двигун			-1
Пір’я
Шасі			-1

Сформуємо тепер правило виводу. Для цього тим характеристикам, які властиві обом об'єктам, привласнимо нульові вагові коефіцієнти. Характеристикам властивим тільки "птаху" поставимо у відповідність ваговий коефіцієнт 1, властивим тільки об'єкту "літак" - 1. Масив RULES, що містить правило висновку представлений в крайньому правому стовпчику таблиці. Тоді механізм отримання рішень буде мати вигляд:

Масив FACTS заповнюється при опитуванні користувача. Неважко переконатися, що при повному і правильному вказівці всіх характеристик об'єктів механізм отримання рішень дає 2 для "птахи" і -2 для "літака".

Дата добавления: 2014-01-11