ЛЕКЦІЯ 3.

Внутрішня організація СУБД

1. Общие положения

2. Линейный список

3. Инвертированный список

4. Индексы

5. Хеширование

6. Кластеризация

Загальні положення

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

Обробка файлів операційною системою на логічному рівні виконується за допомогою файлової системи, на фізичному рівні - системи управління файлами.

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

Дані в процесі роботи зчитуються і записуються сторінками - блоками фіксованих розмірів (в залежності від використовуваної системи зазвичай 2, 4 або 8 кілобайт). Кожна сторінка, яка зберігається на диску, має свій унікальний ідентифікатор, який вказує на фізичне місце її зберігання. Цей ідентифікатор використовується системою управління файлами для читання сторінки і її запису після зміни розміщених на ній даних в те ж місце на диску, звідки сторінка була лічена.

Файл бази даних являє собою набір сторінок. При створенні файлу за запитом файлової системи система управління файлами виділяє йому необхідну кількість сторінок.

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

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

У різних СУБД розглянута загальна схема може бути реалізована за різними принципами.

Наприклад, у СУБД Paradox кожна таблиця або інший об'єкт бази даних являють собою окремий файл, у СУБД MS Access всі таблиці, запити, звіти, схема бази даних і т.д. зберігаються в одному файлі з розширенням .mdb

СУБД

 

Обращения к файлам

 

Файловая система

 

Обращения к логическим страницам

 

Система управления файлами

 

Доступ к физическим страницам

 

Рис. 4. Обращение СУБД к данным на диске

Лінійний список

Лінійний (послідовний) список - послідовність записів бази даних, сформований за деякими логічним принципам. Наприклад, у таблиці, що містить інформацію про надходження товарів у магазин, відомості про кожну поставку являють собою записи, що вводяться в базу даних у хронологічному порядку і розміщуються у фізичній пам'яті послідовно один за одним (табл. 3.1):

Таблица 3.1 Сведения о поставках товаров в магазин

Номер накладной	Название товара	Артикул	Количество	Дата поставки
37	Костюм	500	50	10.12.05
54	Сапоги	200	75	10.12.05
18	Туфли	100	120	11.12.05
60	Костюм	500	35	11.12.05
28	Костюм	300	20	12.12.05
74	Костюм	400	50	12.12.05
80	Туфли	100	100	12.12.05

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

Інвертований список

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

Припустимо, що значення номерів накладних в полі Номер накладної таблиці Відомості про поставки товарів в магазин (див. табл. 3.1) є унікальними, тобто дане поле є первинним ключем таблиці. Інвертований список по полю Артикул буде виглядати наступним чином (табл. 3.2):

Таблица 3.2 Сведения о поставках товаров в магазин

Номер накладной	Название товара	Артикул	Количество	Дата поставки
18	Туфли	100	120	11.12.05
80	Туфли	100	100	12.12.05
54	Сапоги	200	75	10.12.05
28	Костюм	300	20	12.12.05
74	Костюм	400	50	12.12.05
37	Костюм	500	50	10.12.05
60	Костюм	500	35	11.12.05

Отриманий інвертований список дозволяє виконувати швидкий пошук інформації за даними в полі Артикул, не вимагаючи перегляду всіх записів (наприклад, при пошуку відомостей про товари, артикули яких менше 300, достатньо витягти і розглянути тільки перші чотири записи).

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

Індекси

Індекси застосовуються для прискорення доступу до записів бази даних. Їх можна порівняти з предметним покажчиком книги - впорядкованої послідовністю слів (словосполучень) з переліком номерів сторінок, на яких зустрічається це слово (словосполучення).

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

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

Доповнимо табл. 3.1 відомостями про номери сторінок, на яких зберігаються записи з даними (для простоти будемо вважати, що кожен запис зберігається на окремій сторінці зовнішньої пам'яті) (табл. 3.3):

Таблица 3.3 Сведения о поставках товаров в магазин

Номер накладной	Название товара	Артикул	Количество	Дата поставки	Номер страницы
37	Костюм	500	50	10.12.05	1
54	Сапоги	200	75	10.12.05	2
18	Туфли	100	120	11.12.05	3
60	Костюм	500	35	11.12.05	4
28	Костюм	300	20	12.12.05	5
74	Костюм	400	50	12.12.05	6
80	Туфли	100	100	12.12.05	7

Індекс, створений для поля Назва товару, що забезпечує швидкий пошук даних в цьому полі, буде мати вигляд (табл. 3.4):

Таблица 3.4 Индекс Товар

Название товара	Номера страниц
Костюм	1, 4, 5, 6
Сапоги	2
Туфли	3, 7

Пошук і вибірка потрібних записів в базі даних здійснюються в наступній послідовності: 1. Вибирається індекс, відповідний умові пошуку (наприклад Товар, якщо в запиті виконується пошук товару з конкретною назвою). 2. В індексі знаходиться рядок із заданим умовою пошуку (наприклад Туфлі). 3. Зі знайденого рядку вибираються номери сторінок, де зберігаються шукані записи. 4. Отримані номери сторінок використовуються для читання необхідної інформації.

Більшість СУБД реалізує цей процес автоматично, без участі користувача.

Якщо для таблиці визначені кілька індексів по окремих полях, при пошуку записів у цій таблиці по умовам пошуку, заданим в цих полях, відповідні індекси використовуються спільно. Наприклад, для поля Дата поставки табл. 3.3 створений також індекс Дата (табл. 3.5):

Таблица 3.5 Индекс Дата

Дата поставки	Номера страниц
10.12.05	1, 2
11.12.05	3, 4
12.12.05	5, 6, 7

При виконанні запиту «Знайти відомості про туфлях, які надійшли 11 грудня 2005», номери сторінок в індексі Товар для значення даних Туфлі будуть порівнюватися з номерами сторінок значення 11.12.05 в індексі Дата. В результаті буде обраний номер сторінки, що зустрічається в обох індексах, рівний 3.

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

Проілюструємо процес створення індексів на прикладі MS Access.

Якщо індекс створюється по одному полю, необхідно виконати дії: 1. Відкрити таблицю в режимі Конструктора. 2. Активізувати поле, для якого створюється індекс. 3. Вибрати властивість поля Індексовані поле. 4. Обрати для даної властивості одне із значень:

Так (Допускаються збіги);

Так (Збіги не допускаються).

Для ключового поля індекс в MS Access створюється автоматично. Для створення складеного індексу слід відкрити таблицю в режимі Конструктора, натиснути кнопку Індекси на панелі інструментів або виконати дії Вид ® Індекси, потім в діалоговому вікні ввести ім'я індексу та вказати імена полів, за якими він створюється.

У MS Access є наступні обмеження: • в таблиці не може бути більше 32 індексів; • в складеному індексі не може бути більше 10 полів.

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

Детальна характеристика і приклади зазначених понять наводяться в роботах [2, 4]. Для великих таблиць самі індекси можуть займати кілька сторінок у зовнішній пам'яті. У таких ситуаціях створюються багаторівневі індекси, наприклад, у вигляді збалансованих дерев (B-дерево або Balanced-tree), що мають ієрархічну структуру [2, 4]. Метою створення B-дерева є прискорення пошуку, прагнення уникнути перегляду всього індексу.

Розглянемо процес побудови B-дерева на простому прикладі. Припустимо, таблиця відомостей про поставки товарів в магазин включає 18 записів і індексується за номерами накладних: 18, 28, 37, 54, 59, 60, 61, 67, 68, 70, 77, 80, 83, 91, 93, 96, 98, 99. На кожній сторінці у пам'яті містяться тільки дві адреси (фактично їх може бути більше).

Розміщуємо на кореневій сторінці дерева значення даних у полі Номер накладної, рівні 60 і 82, і три покажчика (рис. 5). Дані зі значеннями в полі Номер накладної, менші або рівні 60, можуть бути знайдені за допомогою лівого покажчика; більші 60 і менші або рівні 82 - за допомогою середнього покажчика; більші 82 - за допомогою правого покажчика (див. рис. 5). Інші сторінки індексу інтерпретуються аналогічним чином.

На нижньому рівні B-дерева знаходиться безліч сторінок з покажчиками на сторінки, де зберігаються дані (див. рис. 5).

Для знаходження за допомогою B-дерева адреси розміщення в зовнішній пам'яті будь-якої сторінки з даними, достатньо послідовно розглянути тільки три сторінки індексу (на рис. 5 жирними стрілками вказано маршрут пошуку сторінки з номером накладної 77), що істотно менше загальної кількості сторінок з даними.

 

указатели на страницы, где находятся данные

Рис. 5.  Индекс в виде B-дерева

Реальні дані, для яких будується багаторівневий індекс, часто не дозволяють безпосередньо отримати збалансоване дерево, побудоване на рис. 5. У таких випадках для його створення застосовуються спеціальні алгоритми, розглянуті, наприклад, в роботі [2].

Недоліком індексування є необхідність виділення у зовнішній пам'яті додаткового місця для зберігання індексів. Існують оцінки, що файл, в якому створені індекси для всіх полів розміщеної в ньому таблиці, займає практично вдвічі більше місця на зовнішньому носії порівняно з вихідним файлом. Крім того, наявність індексів ускладнює оновлення інформації, що зберігається в базі даних, і вимагає додаткових витрат часу на даний процес.

Тому не рекомендується індексувати всі поля таблиць або поля, дані в яких часто змінюються. Найбільш ефективним є створення індексів для первинних і зовнішніх ключів, для полів, за якими в основному виконуються запити.