3.1.1.2. Процесор запитів
Наведемо приклад процесору запитів в реляційній СУБД. В ній процесор запитів (query processor) визначає продуктивність СУБД. На рис.3.2 він представлений двома компонентами:
Компілятор запитів (query compiler) транслює запит у внутрішній формат СУБД – план запиту (query plan), тобто послідовність інструкцій, що підлягає виконанню. Компілятору запитів складається з трьох частин:
Синтаксичного аналізатора запитів (query parser), що на основі тексту запиту створює деревовидну структуру даних;
Препроцесора запитів (query preprocessor), який виконує семантичний аналіз запиту (перевірку існування відношень та атрибутів у запиті), та перетворення дерева, побудованого аналізатором, у дерево алгебраїчних операторів (у сенсі реляційної алгебри), які відповідають плану запиту;
Оптимізатора запитів (query optimizer), який виконує перетворення плану запиту в найбільш ефективну послідовність операцій над даними.
Оптимізатор запитів для прийняття рішень користується метаданими та статистичною інформацією, що накопичена в СУБД. Наприклад, на його рішення суттєво впливає наявність індексу – спеціальної структури даних, яка зберігає певні значення (ключі або відносні адреси) для порцій даних.
Виконуюча машина (execution engine) відповідає за виконання кожної операції плану запиту. Під час роботи вона спілкується з більшістю інших компонентів СУБД – напряму або через буфери. Для обробки даних виконуюча машина читає дані в буфери. При цьому вона „спілкується” з планувальником завдань, уникаючи звернення до блокованої інформації, а також із менеджером протоколювання, для фіксації змін у протоколі.
Рис.3.3. Обробка запитів
Виконуюча машина направляє групу запитів на отримання невеликої порції даних (як правило, рядків (кортежів) таблиці (відношення) менеджеру ресурсів, який обізнаний в особливостях розміщення інформації в файлах даних, що містять таблиці, у форматах і розмірах записів у таблицях і у структурах індексів (indexes), які забезпечують суттєве прискорення пошуку даних.
3.1.1.3. Збереження файлів на диску
Інформація, що зберігається в БД, зазвичай розташовується на носіях вторинних пристроїв зберігання (secondary storage device). На цих пристроях «поверхня» розподілена на дискові блоки (disk blocks) – безперервні ділянки, здатні зберігати велику кількість байтів інформації, до 2**12 або 2**14 (4096 або 16384).
Рис.3.4. – Структура диску
Файл зберігається в кількох блоках. В кінці кожного блоку, крім останнього, записана адреса (№ сектора + № циліндра ) наступного блоку.
3.1.1.4. Менеджери буферів та зберігання даних
Корисна обробка інформації відбувається в оперативній пам’яті (ОП). Задача управління розміщенням інформації на диску і обміну нею між диском і ОП покладається на менеджер зберігання даних (storage manager).
У простій СУБД ці функції можуть бути покладені на файлову систему, яка обслуговується операційною системою. Задля ефективності СУБД зазвичай (у будь-якому разі, за певних обставин) самостійно управляє розміщенням даних на дисках.
У відповідь на запит менеджера буферів менеджер зберігання даних визначає розміщення файлів на диску та отримує набір блоків диска, які містять запитаний файл чи його частину.
Менеджер буферів (buffer manager) відповідальний за розбиття доступної оперативної пам’яті на буфери (buffers) – ділянки-сторінки(pages), куди може бути поміщений зміст блоків. Усі компоненти СУБД, які звертаються до дискової інформації, взаємодіють з буферами та менеджером буферів – або безпосередньо, або за допомогою виконуючої машини. Дані, необхідні компонентам системи, можуть відноситись до категорій:
Власне дані – зміст БД як такої.
Метадані – опис схеми (логічної структури) БД, введених обмежень і т.д.
Статистика – інформація, зібрана СУБД, про властивості даних, як-от розміри певних відношень, про імовірнісний розподіл збережених значень і т.д.
Індекси – структури даних для ефективного доступу до інформації в БД.
Рис.3.5. Діаграма послідовності звертання виконуючої машини до диску