Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Скачиваний:
49
Добавлен:
05.03.2016
Размер:
1.28 Mб
Скачать

3.2.2 Складені запити

Складені запити створюються з простих, шляхом об’єднання їх між собою комами. Кожен простий запит називається підціллю. Для того, щоб складений запит виявився щирим, необхідно, щоб кожна з його підцілей була б щирою. Введемо складений запит, що буде відповідати запитанню: “Чи є такий відділ, де разом працюють Грищенко і Петренко?”

Goal: work(„Петренко”, X), work(„Грищенко”, X)

Х=101

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

Використання констант в аргументах запиту еквівалентно завданню вхідних параметрів програми. Використання змінних – еквівалентно вимозі одержати від програми вихідні дані.

3.2.3 Запити з анонімними змінними

Символ підкреслення (_) виступає в якості анонімної змінної, яка пропонує системі проігнорувати значення аргументу. Ця змінна уніфікується з чим завгодно, але не забезпечує вивід на екран даних. Кожна анонімна змінна, що входить в запит, відрізняється від інших змінних цього запиту.

Подивимося, що буде, якщо ввести запит work(Worker, _). При виконанні цього запиту будуть видані всі можливі значення першого аргументу предикату work(...), при ігноруванні значення другого аргументу. У такий спосіб даний запит відповідає питанню: “чи існує хоча б один службовець, що працює в якому-небудь з відділів?”. Сформований до програми запит аналогічний бажанню одержати дані про всіх службовців, що працюють у всіх відділах фірми.

Goal: work(Worker, _)

Worker =Грищенко

Worker =Кардаш”

Worker =Петренко”

3.3. Статичні і динамічні бази даних

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

Так, для вводу інформації про направлення на службу в 101 відділ Скрипки, необхідно ввійти в режим редагування програми і додати новий факт.

...........

clauses

...........

work(„Скрипка”, 101).

Якщо потім у режимі виконання, поставити запит про співробітників всіх відділів, то одержимо інформацію вже про чотирьох службовців. Причому у відповіді на запит дані про Скрипку будуть виводитися в тому ж рядку, яким по рахунку в програмі є факт про роботу Скрипки в 101 відділі.

Goal: work(Worker, _)

Worker =Грищенко”

Worker =Кардаш”

Worker =Петренко”

Worker =Скрипка”

Система знаходить відповіді в БД у тому порядку, як вони були введені в програму. Це ще одна особливість роботи зі статичними БД.

Динамічні бази даних – це БД, у яких факти можуть модифікуватися під час виконання програми або вибиратися з файлу. Для роботи з такими БД у тексті програми в секції database повинні бути задекларовані предикати для опису структури динамічної БД. Робота з такими БД буде описана наступних лабораторних роботах.

3.4. Явні і неявні бази даних. Правила логічного висновку

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

Так людина може назвати двох службовців колегами, якщо вони працюють у тому самому відділі. Разом з тим, працюючи з БД work(...), для визначення колег „Петренко” користувачеві системи необхідно:

– визначити номер відділу (N), у якому працює Петренко;

– знайти всіх співробітників, що працюють у відділі з номером N;

– виключити з отриманого списку самого Петренка;

– сформувати всі пари Петренка з особами із отриманого списку.

У такий спосіб у користувача з'являється можливість свої знання про поняття колеги сформувати у виді складеного запиту до БД і одержати відповідь на питання. І така ситуація буде повторюватися при кожному використанні поняття колега при формуванні запитів, таких як “Чи є Петренко і Павлов колегами?”, “Хто колега Петренка і Скрипки?” і т.д. Ясно, що така процедура тривала, вимагає від користувача системи належної кваліфікації по складанню складених запитів.

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

Для цього можна ввести нове відношення Колега(Службовець_1, Службовець_2), визначивши його як пари різних службовців, що працюють у тому самому відділі. Нове відношення необхідно описати в секції predicates двомісним предикатом зі структурою, аналогічною відношенню Колега(...).

Аргументи предикату повинні приймати значення з області символьних даних. А сам предикат у секції clauses визначається на підставі логічного правила висновку:

Будь-які два службовці Службовець_1 і Службовець_2 є колегами

ЯКЩО

існує такий відділ N, де працює Службовець_1

І

працює Службовець_2

І

службовці Службовець_1 і Службовець_2 різні.

Виконавши всі необхідні дії по модифікації вихідної програми, ми одержимо програму, що містить не тільки факти, але і знання, у вигляді правил маніпулювання цими фактами. Це дозволяє до правил застосовувати ті ж самі типи запитів, що і до фактів.

Якщо нас цікавлять усі колеги службовця Петренка, то запит треба задати у виді:

Goal: colleague („Петренко”, Who),

а якщо цікавлять загальні колеги Скрипки і Петренка, то запит буде мати вигляд:

Goal: colleague („Петренко”, Х), colleague („Скрипка”, Х)

і система знайде тільки одну відповідь про службовця на прізвище Грищенко, тому що саме він працює в одному відділі з Петренком і Скрипкою.

/* Програма 3.2 */

domains

name=string

office=integer

predicates

work(name, office )

colleague(name, name)

clauses

colleague(Man1, Man2) :- work(Man1, X), work(Man2, X), Маn1<>Маn2.

work(„Грищенко”, 101).

work(„Кардаш”, 111).

work(„Петренко”, 101).

work(„Скрипка”, 101).

З викладеного випливає, що якщо БД work(...) – це явна база даних, тому що складена з фактів, аргументи яких константи, то база colleague(...) – це неявна база даних, оскільки правило для її формування визначено з використанням змінних, значення яких залежать від підцілей цього правила. З погляду користувача, що формує запит, не має значення, є база явної чи неявної.