Page 54 - 4800
P. 54
У програмі 6_3 визначені два предикати для читання і додавання фактів у файл
БД. Це предикати my_read і my_append. Предикат next_rec по структурі схожий на
предикат repeat і служить для переходу від одного запису файлу до іншого, поки не
буде знайдено кінець файлу.
У процедурі place() два перші правила, в якості другої підцілі викликають
предикат my_read(R), який зв’язує терм R з поточним записом файлу БД.
Третя підмета вказаних правил уніфікує поточний запис з структурою address(F,
S, N, G). Якщо уніфікація неможлива, відбувається відкат до предиката my_read(R),
який зв’язує змінну R з наступним записом файлу. І так продовжуватиметься до тих
пір, поки уніфікація не буде успішною, або поки не буде досягнуто кінець файлу.
Якщо уніфікація завершиться успішно, то змінні F, S, N, G матимуть ті ж
значення, що і поля поточного запису БД, а все правило, як і процедура в цілому, буде
успішно доведеним. Якщо уніфікація як першого, так і другого правила завершилася
невдачею при досягненні кінця файлу, то система перейде до доведення третього
правила процедури place().
У процедурі my read() перша підмета зв’язує логічне ім’я file_db з дисковим
файлом „adres.dba” і відкриває його для читання.
Друга підмета об’являє файл з логічним ім’ям file_db стандартним пристроєм
вводу. Це означає, що всі предикати типу read, що описані в програмі, виконуватимуть
ввід даних з файлу, а не з клавіатури, яка за замовчуванням, є стандартним пристроєм
вводу.
Третя підмета служить для організації повторного виконання, наступних
підзадач при відкатах. Слід зазначити, що предикат next_rec() істинний завжди, якщо не
досягнуто кінця (eof()) записів у файлі на диску.
Оскільки стандартним пристроєм вводу попереднім предикатом встановлено
дисковий файл, то саме з нього четверта підмета прочитує в змінну Record терм,
структура якого відповідає структурі домена бази даних. Інакше кажучи, виконується
читання в змінну Record вмісту поточного запису файлу, структура якого повинна
відповідати описаній в програмі структурі БД.
У процедурі my арpend() перша підмета зв’язує логічне ім’я file_db з дисковим
файлом „adres.dba” і відкриває його для запису.
Друга підмета призначає файл з логічним ім’ям file_db стандартним пристроєм
виводу. Це означає, що всі предикати типу write, що зустрічаються далі,
виконуватимуть вивід даних у файл, а не на екран дисплея, який є стандартним
пристроєм виводу за замовчуванням.
Третя підмета виводить (додає в кінець файлу) новий запис, значення якого
вводиться в дану процедуру через змінну Record.
Після виконання цих дій четверта підмета закриває відкритий для запису файл.
Основним режимом роботи даної програми є режим відповідей на запити, який
вимагає постійного доступу до файлу на диску. При цьому за пристрій вводу програма
назначає файл БД. Проте за відсутності в БД потрібних даних, програма переходить в
режим навчання і вимагає від користувача введення з клавіатури нових даних.
У третьому правилі процедури place() для того, щоб забезпечити можливість
вводу даних з клавіатури, використовується предикат readdevice(keyboard) який
встановлює як стандартний пристрій вводу клавіатуру. Після цього виконується запит
на ввід нових даних. Закривається робочий файл, який був відкритий для читання та
виконується додавання нового запису в кінець дискового файлу.
Слід зазначити, що в даному прикладі розглянутий простий випадок доступу до
файлових даних. Він приведений з метою ілюстрації принципу побудови динамічних
БД і їх розширення у файлові структури.
6.6. Організації файлових БД на основі файлів прямого доступу
У попередньому прикладі використовувалися файли послідовного доступу.
Складність роботи з ними виникає вже при виконанні таких простих дій як видалення
даних. Ця операція вимагає реорганізації початкового файлу БД, що приводить до
непродуктивних витрат часу. Тому, при побудові файлових БД використовуються
файли прямого доступу з індексними файлами. Замість індексних файлів, у ряді
54